Максимальная компрессия blockchain ж / доверие свободного облегченных узлов | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
Максимальная компрессия blockchain ж / доверие свободного облегченных узлов

17 июня 2012, 6:33:40 PM	# 1
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Эта идея была разбросана по всем некоторым другим потокам, но нет ни одного места, которое полностью объясняет идею с фотографиями. Я считаю, что это снимает две основные проблемы, связанные с сетью сразу - сжатие / обрезку и безопасность легкий узел - и делает это без прерывания пути. Я не уверен, что это правильный путь, но это, безусловно, заслуживает обсуждения. Резюме: [Смотрите иллюстрации ниже] Используйте специальную структуру дерева данных, чтобы организовать весь неизрасходованный-TxOuts в сети, и использовать корень этого дерева, чтобы сообщить о своем "подпись" между узлами. Листья этого дерева действительно соответствуют адресам / сценариев, и данные на листе на самом деле корень списка неизрасходованные-TxOut для этого адреса / сценария. Для обеспечения безопасности подписей дерев, он будет включен в заголовке альтернативного blockchain, который будет обеспечен путем объединенном добычи. Это обеспечивает такое же сжатие, как простое неизрасходованной-TxOut Merkle дерево, но также дает узлам способ загрузить только неизрасходованный-TxOut список для каждого адреса в бумажнике, и убедитесь, что список непосредственно против blockheaders. Поэтому, даже облегченные узлы могут получить полную информацию об адресах, от любого ненадежного партнера, и лишь ничтожное количество загруженных данных (несколько килобайт). (Примечание: я иллюстрировал все, как с помощью прямых Merkle-деревьев, но, как отмечено в разделе МИНУСЫ / неопределенностей:. Один из вариантов Merkle дерева придется быть использованы, что гарантирует эффективное обновление дерева) (1) Основные преимущества: (1a) Около оптимального сжатия blockchain: Теоретически, размер обрезанной blockchain будет пропорционален объему сделки (таким образом, может идти вверх или вниз), вместо всей глобальной истории, которая всегда увеличивается в размерах. На практике, это не будет так чисто, но вы действительно не будете делать лучше, чем это. Упс! Перед тем как эта идея была полностью разработана, я упустил из виду тот факт, что полные узлы будут по-прежнему должны поддерживать базу данных транзакций индексированные. Этот адрес индексированных DB не является заменой, но должен быть к тому же на что. Поэтому обязательно увеличивает объем работы и хранения данных полного узла. Но это может быть просто "добавить" к существующим "ultraprune" реализация. (В любом случае, это должно быть на самом деле обратная сторона). (1b) ненадежный Поддержка легкий-узел: Новые узлы, входящие в сеть в первый раз, нужно будут только скачать небольшое количество данных, чтобы получить полные, поддающиеся проверке знаний о балансе и как провести его (большую часть которых может храниться между нагрузками). Один честные сверстники из тысяч гарантируют вы получите, и признать, хорошую данные. (1c) Совершенно без прерывания работы: Там нет протокола главной сети или blockchain изменения вообще. Вся информация баланса дерева сохраняется и проверяется в отдельном blockchain через объединенную добычу. На самом деле, это так не прерывает работу, она может быть реализована без поддержки ядра-DEV вообще (хотя я / мы хотели бы их участие) (1d) Эффективное дерево выполнение запроса&обновление: Полные-но-обрезают узлы сети будут иметь возможность эффективно поддерживать эту структуру данных. Новые блоки просто добавить или удалить неизрасходованные монеты из дерева, и все операции "постоянное время и пространство" (Существует верхний предел того, сколько времени и пространства требуется доказать включение, вставить или удалить часть данных, независимо от того, насколько велика сеть) (Не 1е) Нет пользователем настройки или опции: В отличие от сетей с перекрытиями, достижение полного доверия не требует нахождения доверенного узла или подписки на услугу. Так же, как и основной blockchain - вы найдете кучу случайных сверстников и получить самую длинную цепочку. Это может быть бутстрапированным таким же образом, как основная сеть. (2) и Погрешность Недостатков: (1a) См пересмотренного (1а) выше (2a) Сложность концепции: Это не просто. Это второй blockchain, требующее совмещенная добычу - хотя, если она успешна и поддерживаются сообществом, то можно было бы добавить к сети, требуя, чтобы шахтеры вычислить и включают корневой хеш этой структуры данных в coinbase сценария (так же, как с высота блока). Это вполне возможно, но это может быть медведь для его реализации. (2b) Погрешность о начальных загрузках данных облегченного-узле: В зависимости от того, как структурированы данных, там еще может быть немного данных для узла облегченного для загрузки, чтобы получить полную защиту полного узла. Это, несомненно, будет гораздо меньше, чем загружать всю цепочку. Но, очевидно, есть последствия, если эта безопасность достигается за счет 1 МБ / бумажника, или 100 Мб / кошелька (еще лучше, чем 4 Гб, с этим письмом). ОБНОВИТЬ: Моя первоначальная оценка на основе "Гибридный PATRICIA / Brandais Tree" (Ака Райнер-Tree), является то, что кошелек с 100 адресов может проверить свой баланс около 250 кбайт. (2c) [см UPDATE в нижнем] Меркло дереве Альтернативного Необходимые: Vanilla Меркл дерева не будут работать, так как добавление или удаление одиночных ветвей могут привести к полному перерасчету дерева. Но это должно быть возможно создать альтернативу со следующими свойствами: Коммутативное вычисление: узел должен быть в состоянии получить тот же ответ, независимо от того, является ли дерево вычислено с нуля, или основано на обновление предыдущего дерева. O (журнал (N)) обновление: удаление или добавление одного узла лист должен быть в состоянии сделать в O (журнал (N)) времени. С ванильным Merkle дерева, это верно, только если удалить узел и добавить узел в том же месте листа. (3) Допущения:: (3а) нужно проверяемые корни деревьев: Я утверждаю, что регулярная сеть оверлея не будет достаточно, только потому, что это слишком легко для вредоносных узлов распространять неверные данные и испоганить сеть. Если есть достаточное количество вредоносных узлов в сети с перекрытиями, он может сделать облегчённые узлы, которые зависят от него непригодных для использования. Я предполагаю, что это необходимо иметь проверяемый источник для обрезанных-заголовков - отдельный blockchain успешно, так как правильность данных требуется быть приняты. (3б) Объединенная добыча делает то, что мы думаем, что он делает: Это безопасный способ поддерживать отдельный blockchain, используя существующие добычи энергии. (3с) Эффективная сортировка: Листовые узлы главного дерева должны быть отсортированы так, что все узлы могут получить тот же ответ. Тем не менее, это может быть сделано с помощью ковша-то в O (N) времени, поскольку листовые узлы хэши, которые должны быть равномерно распределены. Alt-Chain Merkle Tree конструкция: -- Для каждого адреса / скрипта, собрать все неизрасходованные-TxOuts -- Compute Merkle корень каждого дерева TxOut -- Сортировка корней, использование в качестве листовых узлов для мастер-Merkle дерева. -- Включите Merkle-корень дерева мастеров в заголовке альтернативной цепи. https://dl.dropboxusercontent.com/u/1139081/BitcoinImg/ReinerAltChain/reinercompression.png Как ваш баланс: -- Скачать заголовки обеих цепей -- Запросить список неизрасходованного-TxOut-хэша. -- Вычислить корень суб-Merkle для этого адреса -- Запрос вторично-узлы ветвления (O (журнал (N)) -- Вычисление мастер-корень; сравнить блок заголовка -- Запрос полного TxOuts для каждого неиспользованного-TxOut-хэш выше https://dl.dropboxusercontent.com/u/1139081/BitcoinImg/ReinerAltChain/reinercompression2.png Альтернативные цепи: Все данные включены в альтернативном blockchain, которая поддерживается за счетом объединенной добычи на главной цепи. Это только один дополнительный ТХ для каждого блока на главной цепи. Это в полной мере его влияние на основной цепи, и любые узлы, не обращая внимания / не знают о альте-цепи. https://dl.dropboxusercontent.com/u/1139081/BitcoinImg/ReinerAltChain/reinerchain.png Да, это огромная задача. Да, есть много неопределенностей. Да, мне нужна новая структура Merkle дерева. Но эта идея будет убить два массивных заяц (убить два альбатрос с одного блоком?) Хорошо, разорвать его! ОБНОВИТЬ: После того, как много и много обсуждений и дискуссий, я считаю, что индекс адреса должен быть сохранен в качестве TRIE-подобной структуры. Другие выразили заинтересованность в двоичном дереве поиска (BST). В любом случае, структура может быть приспособлена, чтобы иметь то же свойство, мы желаем из Merkle дерева, но с гораздо большей гибкостью, такие как очень быстрой вставка, удаление, обновление поиска информации и т.д. Я предпочитаю это крем-де-ла -creme попыток - гибрид PATRICIA дерева (уровень сжатого TRIE) и де-ла-Braindais дерева (узел-сжатый). Это выглядит примерно так: https://dl.dropboxusercontent.com/u/1139081/BitcoinImg/ReinerAltChain/DataStructures_Values.png Структура будет индексироваться TxOut сценария ("получатель"), А каждый узел рекурсивно проверки подлинности узлов под ним. Уникальность структуры TRIE гарантирует, что существует ровно одно решение для данного набора TxOuts, что также означает, что только существующий набор TxOuts должен быть получен в целях создания синтаксического дерева (БСТ требует переигрывая все транзакции, для того, чтобы иметь хорошо определенную внутреннюю структуру). Для образования на TRIE структур, увидеть мои красивые картинки в этом посте.

Как заработать Биткоины?
Без вложений. Не майнинг.

17 июня 2012, 6:43:53 PM	# 2
hazek Сообщения: 1078 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Получил 1806 Биткоинов Реальная история. Прежде чем я прочитал это, я просто хочу, чтобы быстро опубликовать, что я лично, независимо от того, является ли оправданно или неоправданно, лично я не чувствую, что это является наиболее острой проблемой, когда дело доходит до успешного будущего Bitcoin, и я действительно надеюсь, что основная команда погонаж порядок приоритеты.

17 июня 2012, 6:47:49 PM	# 3
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: hazek от 17 июня 2012 года, 6:43:53 PM Прежде чем я прочитал это, я просто хочу, чтобы быстро опубликовать, что я лично, независимо от того, является ли оправданно или неоправданно, лично я не чувствую, что это является наиболее острой проблемой, когда дело доходит до успешного будущего Bitcoin, и я действительно надеюсь, что основная группа имеет порядок приоритетов планируется соответствующим образом. Я тоже считаю, что это очень важный вопрос для Bitcoin, в целом. Я выдвинул идею, что обработка blockchain размер имеет решающее значение, в прошлом, но и другие вопросы, казалось, более актуальным для разработчиков в то время - у меня не было твердой идеей продвижения, и размер blockchain не был так вне от руки еще. Одна хорошая выгода этого решения заключается в том, потому что это альт-цепь, технически не основные разработчики не должны быть на борту. Это может быть сделано полностью indepedently и работает полностью без прерывания, даже только с поддержкой Другие Разработчики, которые верят в него. Я бы, конечно, хотел бы получить основные разработчики заинтересованы в нем, так как они очень умные люди, которые, вероятно, имеют много хороших идей, чтобы добавить. Но один из самых больших расквитаться здесь является то, что это может быть сделано полностью indepdently.

17 июня 2012, 7:22:01 PM	# 4
socrates1024 Сообщения: 125 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Позвольте мне попытаться объяснить решение «альтернативного Merkle дерева» вам требуется. Основная идея заключается в использовании сбалансированного двоичного дерева поиска, такие как красно-черное дерево или 2-3 дерева. Обновление такой структуры данных, в том числе изменения баланса, только требует доступ O (журнал N) узлы дерева. Клиент облегченный сможет проверить такое обновление, получив только соответствующие узлы. Там никогда не нужно пересчитывать все дерево с нуля. Балансировка строга, в том, что в худшем случае длина от корня до листа не превышает O (журнал N). Там была куча научных исследований на эту тему, где он известен как "Структуры данных идентифицированных" [1,2,3]. Хотя идея была вокруг в течение почти 15 лет, я не знаю ни одной реализации. Так что я сделал реализацию игрушки доступна на https://github.com/amiller/redblackmerkle Я надеюсь, что для распространения информации об этой технике, так как это довольно ясно, что какое-то умное использование Merkle дерев будет иметь важное значение в будущем Bitcoin в. Давайте обсудим это! Постскриптум Большинство из этих структур требуют только столкновения устойчивые хеш-функции. Тем не менее, если вы хотите использовать фантазии хэш-функции со специальными (гомоморфными) свойства, можно сделать еще более эффективные структуры, например, Merkle 'Фильтр Блума' [4]. [1] отозванные сертификаты и обновление сертификатов Ноар и Нисим, 1998. USENIX https://www.usenix.net/publications/library/proceedings/sec98/full_papers/nissim/nissim.pdf [2] Структуры данных идентифицированных Роберто Тамассия, 2003. http://cs.brown.edu/research/pubs/pdfs/2003/Tamassia-2003-ADS.pdf [3] Стойкие структуры данных идентифицированных и их приложение Anagnostopoulos, Goodrich, и Tamassia http://cs.brown.edu/people/aris/pubs/pad.pdf [4] Криптография для эффективности: Структуры данных идентифицированных на основе решеток и Parallel Online Проверки памяти Papamanthao и Tamassia, 2011 http://www.cse.msstate.edu/~ramkumar/gw-102.pdf

17 июня 2012, 7:33:39 PM	# 5
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: socrates1024 от 17 июня 2012 года, 7:22:01 PM Позвольте мне попытаться объяснить решение «альтернативного Merkle дерева» вам требуется. Основная идея заключается в использовании сбалансированного двоичного дерева поиска, такие как красно-черное дерево или 2-3 дерева. Обновление такой структуры данных, в том числе изменения баланса, только требует доступ O (журнал N) узлы дерева. Клиент облегченный сможет проверить такое обновление, получив только соответствующие узлы. Там никогда не нужно пересчитывать все дерево с нуля. Балансировка строга, в том, что в худшем случае длина от корня до листа не превышает O (журнал N). Там была куча научных исследований на эту тему, где он известен как "Структуры данных идентифицированных" [1,2,3]. Хотя идея была вокруг в течение почти 15 лет, я не знаю ни одной реализации. Так что я сделал реализацию игрушки доступна на https://github.com/amiller/redblackmerkle Я надеюсь, что распространение понимания этой техники, так как это довольно ясно, что какое-то умное использование Merkle дерев будут иметь важное значение в будущем Bitcoin в. Давайте обсудим это! Постскриптум Большинство из этих структур требуют только столкновения устойчивые хеш-функции. Тем не менее, если вы хотите использовать фантазии хэш-функции со специальными (гомоморфными) свойства, можно сделать еще более эффективные структуры, например, Merkle 'Фильтр Блума' [4]. [1] отозванные сертификаты и обновление сертификатов Ноар и Нисим, 1998. USENIX https://www.usenix.net/publications/library/proceedings/sec98/full_papers/nissim/nissim.pdf [2] Структуры данных идентифицированных Роберто Тамассия, 2003. http://cs.brown.edu/research/pubs/pdfs/2003/Tamassia-2003-ADS.pdf [3] Стойкие структуры данных идентифицированных и их приложение Anagnostopoulos, Goodrich, и Tamassia http://cs.brown.edu/people/aris/pubs/pad.pdf [4] Криптография для эффективности: Структуры данных идентифицированных на основе решеток и Parallel Online Проверки памяти Papamanthao и Tamassia, 2011 http://www.cse.msstate.edu/~ramkumar/gw-102.pdf Вау, спасибо Сократа! Это отличное место, чтобы начать. Конечно, я уже думал о том, что с самого начала, так как я адепт со структурами данных, и особенно деревьев / нах сортов. Я даже закодированы красно-черное дерево, прежде чем ... Мой мозг застрял на том, как изменить базовую концепцию Merkle-дерево в то, что я хотел, и не считал вернуться к структуре данных разные (хотя и связаны). Существует одна проблема, хотя это может быть часть материалов вы уже упомянутых: дерево должно быть построены одинаково всеми сторонами, и из любого государства. И все двоичное дерево структуры вставки порядка зависит, если вы не хранить их в каком-то синтаксического дерева. Указание порядка вставки не работает, потому что кто-то строить с нуля, не знаю, как кто-то обновление с предыдущего дерева будет вставлять их. Но я не хотел бы, чтобы перейти к основному синтаксическому дереву, из-за космическую неэффективность. Что-то вроде Патрисии дерева / синтаксического дерева вероятно, будет работать, но это очень сложно реализовать (правильно) и там не много существующих, надежные реализации там. Я буду копаться в свои материалы немного. Благодаря!

17 июня 2012, 7:50:25 PM	# 6
2112 Сообщения: 1988 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: etotheipi от 17 июня 2012 года, 6:33:40 PM (2с) Merkle-дерево Альтернатива Нужен Я думаю, что это важно наблюдение. Bitcoin не действительно имеет один непрерывный поток битов, которые должны были бы в защиту хэш дерева. Он имеет набор операций, которые слабо упорядоченных в решетке моды. Чем лучше структура данных будет, вероятно, некоторые классические представлениями базы данных, как B-дерево с криптографический подписанным журналом транзакций. Чтобы разрешить проверку целостности с trucated протоколирования блоки журнала должен содержать что-то вроде хэш заказовМои обхода содержимого базы данных до обновление. Это позволит для быстрой проверки новых журнальных блоков, полученных из сети. Для обеспечения обратной совместимости с прямым треугольником блока-цепью протоколу Bitcoin потребуется дополнительное ограничение на упорядочении операций в блоках.

17 июня 2012, 8:12:00 PM	# 7
socrates1024 Сообщения: 125 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Есть два вида порядков здесь. Во-первое это порядок, в котором обновление сделаны дерева Merkle. Каждый блок заказан, и в блоке транзакции упорядочены, и в течение транзакции txIns и txOuts упорядочена. Чтобы обновить деревья Merkle в результате сделки Bitcoin, вы удалите все входы и вставить все новые выходы. Каждый человек должен быть в состоянии сделать это в том же порядке, верно? Теперь в дереве Merkle, порядок определяется ключом. Подумайте о каждом дереве Merkle в качестве индекса базы данных. Мы хотели бы иметь по крайней мере два вида индексов, что означает сохранение двух экземпляров дерева Merkle: 1) TxOuts идентифицируются хэш транзакции и индекс в пределах этой транзакции. Таким образом, мы должны искать (txhash, IDX), чтобы увидеть, если выход был проведен. Когда выходы вставляются в это дерево, они хранятся в отсортированном порядке в соответствии с (txhash, IDX). 2) Также желательно, чтобы найти все доступные txouts для конкретного адреса. Пусть второй Merkle дерева содержат ключи вида (scriptpubkey). Теперь, учитывая корневой хэш, вы можете обратиться за проверяемый список всех ваших расходуемых монет. С другой стороны, вместо того, чтобы думать о нем, как другое дерево для каждого индекса, вы можете думать об этом как составной структуры. Общий вид является поиск DAG (ориентированный ациклический граф), но идея точно так же [5]. (Это включает в себя B-деревья). [5] Общая модель для структур данных идентифицированных Martel, Nuckolls, Devanbu, Герц, Квон, Stubblebine, 2004. http://truthsayer.cs.ucdavis.edu/algorithmica.pdf

17 июня 2012, 8:41:15 PM	# 8
Прудон Сообщения: 1260 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Понятия не имею ни о какой из этого материала, но спасибо, ребята, за работу над этим. Я думаю, что это очень важно, чтобы это разобрали до принятия и использования становится очень тяжелым.

17 июня 2012, 9:32:27 PM	# 9
unclescrooge Сообщения: 868 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Я согласен с другими, это горячая тема. И так же, как я не люблю авантюры, я благодарен Satoshidice оказать давление на blockchain как это.

17 июня 2012, 9:35:40 PM	# 10
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: socrates1024 от 17 июня 2012 года, 8:12:00 PM Есть два вида порядков здесь. Во-первое это порядок, в котором обновление сделаны дерева Merkle. Каждый блок заказан, и в блоке транзакции упорядочены, и в течение транзакции txIns и txOuts упорядочена. Чтобы обновить деревья Merkle в результате сделки Bitcoin, вы удалите все входы и вставить все новые выходы. Каждый человек должен быть в состоянии сделать это в том же порядке, верно? Теперь в дереве Merkle, порядок определяется ключом. Подумайте о каждом дереве Merkle в качестве индекса базы данных. Мы хотели бы иметь по крайней мере два вида индексов, что означает сохранение двух экземпляров дерева Merkle: Рассмотрим 10 неизрасходованные-TxOuts, {0,1,2,3,4,5,6,7,8,9}. Вы и я оба построения тот же двоичный / красный задний дерево, за исключением того, что вы начинаете с нуля, и я начинаю с дерева, где элементы {0,1,2,5,6,9,13} являются частью дерево. я нужно добавить {3,4,7,8} и удалить {13} из моего дерева. Вы просто добавить все 10 элементов в определенном порядке. Мы собираемся, чтобы получить разные корни. Я технически знаю, как бы я был построен ваше дерево, но я, возможно, придется начать все сначала и заново установите все с нуля, если бы я хотел, чтобы убедиться, что моя структура дерева соответствует вашим. Вот что я имею в виду "коммутативное вычисление" - мы должны убедиться, что независимо от того, вы начинаете с нуля, или обновления существующего дерева с любой точки в прошлом, что вы получите тот же ответ. Как я уже говорил ранее, Trie будет работать, но, как правило, очень неэффективен пространство, и что здесь имеет значение.

17 июня 2012, 10:04:31 PM	# 11
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Вопрос: так как пользователи скачать этот альт-цепь, они не всегда скачать альт-цепь из ее генезиса блока (представьте namecoin), или же они всегда только загружать определенное количество блоков назад, после чего все предыдущие блоки отбрасываются? (Представьте p2pool). Я бы себе представить, это был второй. Если бы это были первым, значение альта-цепи стремится к нулю с течением времени: это было бы полезно только для обрезки, проведенных операций, которые существовали на момент создания альта-цепи, так как все блоки представляющие посмотреть различие в альт цепь была бы такой же, как (в пропорции), чтобы и переформатирование на главной цепи. То есть, по крайней мере, как я понял. Если бы это был второй, я бы себе представить, что было бы более целесообразно создать суперблок (скажем, каждые 1000 блоков), которые издают совершенно новое дерево, а затем все не суперблоки, которые следуют (до следующего суперблоке) будут обновления к этому дереву. Любой загрузив альт-цепь никогда не потребуется более 1000 блоков: один суперблок и все добавочные блоки, так как Суперблок была создана. Все, что старше суперблоке будет просто ненужным.

17 июня 2012, 10:07:29 PM	# 12
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: etotheipi от 17 июня 2012 года, 6:33:40 PM Я предполагаю, что это необходимо иметь проверяемый источник для обрезанных-заголовков - отдельный blockchain успешно, так как правильность данных требуется быть приняты. Я считаю, что вы могли бы обеспечить это путем публикации как ваш "генезис блок" а также исходный код для единовременной утилиты вы делаете, чтобы произвести его. Один держит полную копию блока цепи Bitcoin должен быть в состоянии запустить программу и создать бит-в-бит копию генеза блока. Получить несколько человек, чтобы сделать это, и GPG подписать хэш полученного вывода. Вуаля.

17 июня 2012, 10:23:04 PM	# 13
DiThi Сообщения: 157 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: etotheipi от 17 июня 2012 года, 6:33:40 PM Эта идея была разбросана по всем некоторым другим потокам, но нет ни одного места, которое полностью объясняет идею с фотографиями. Я сделал. Ну, не совсем картинки, но ASCII рисунки: https://en.bitcoin.it/wiki/User:DiThi/MTUT Я хотел сделать прототип, но я был очень занят другими проектами с тех пор.

17 июня 2012, 10:35:28 PM	# 14
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: casascius 17 июня 2012, 10:04:31 PM Вопрос: так как пользователи скачать этот альт-цепь, они не всегда скачать альт-цепь из ее генезиса блока (представьте namecoin), или же они всегда только загружать определенное количество блоков назад, после чего все предыдущие блоки отбрасываются? (Представьте p2pool). Я бы себе представить, это был второй. Если бы это были первым, значение альта-цепи стремится к нулю с течением времени: это было бы полезно только для обрезки, проведенных операций, которые существовали на момент создания альта-цепи, так как все блоки представляющие посмотреть различие в альт цепь была бы такой же, как (в пропорции), чтобы и переформатирование на главной цепи. То есть, по крайней мере, как я понял. Если бы это был второй, я бы себе представить, что было бы более целесообразно создать суперблок (скажем, каждые 1000 блоков), которые издают совершенно новое дерево, а затем все не суперблоки, которые следуют (до следующего суперблоке) будут обновления к этому дереву. Любой загрузив альт-цепь никогда не потребуется более 1000 блоков: один суперблок и все добавочные блоки, так как Суперблок была создана. Все, что старше суперблоке будет просто ненужным. Второй blockchain фактически не будет иметь никакого вещества к этому. Он будет состоять исключительно из заголовков, которые будут содержать корни мастер-Merkle. В Меркле-корни создаются из основных данных цепи, так что вы идете получить данные из этой сети. Там не было бы никакого вознаграждения блока - ваша награда на главной цепи, которую вы добывали в то же время. Так что да, все скачивает всю альт-цепь. Но цельность этой дополнительной цепи сами заголовки: так что только около 4-5 МБ в год. Цитата: casascius 17 июня 2012, 10:07:29 PM Цитата: etotheipi от 17 июня 2012 года, 6:33:40 PM Я предполагаю, что это необходимо иметь проверяемый источник для обрезанных-заголовков - отдельный blockchain успешно, так как правильность данных требуется быть приняты. Я считаю, что вы могли бы обеспечить это путем публикации как ваш "генезис блок" а также исходный код для единовременной утилиты вы делаете, чтобы произвести его. Один держит полную копию блока цепи Bitcoin должен быть в состоянии запустить программу и создать бит-в-бит копию генеза блока. Получить несколько человек, чтобы сделать это, и GPG подписать хэш полученного вывода. Вуаля. См (1й) в исходном сообщении: точка этого упражнения не должна доверять конкретные узлам, GPG подписи / PGP, добавить централизацию и т.д. Вы доверяете доказательству правильности работы. Merkle-корень с самой работой за ним на альт-цепи является Merkle-корнем, которому вы доверяете, чтобы быть правильными, так же, как вы делаете с главной сетью заголовками. Мы не хотим, чтобы пользователи должны установить список доверенных. Тогда у вас есть списки отозванных. И сохранить список обновляется. И поддерживать GPG ключи таких органов. И политика о том, кто должен доверять власти. И, конечно же, централизация. Или настроить альтернативный blockchain, и доверять данным, которые имеют большую часть работы за ним. Вуаля.

17 июня 2012, 11:32:21 PM	# 15
maaku Сообщения: 905 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Как уже упоминалось, самобалансировку бинарное дерево поиска будет решить только реальную техническую проблему здесь. Красно-черные дерева будут работать нормально, или их обобщенная родительская структура в 2-3-4 дерева (B + дерево порядка 4), которая обеспечивала бы концептуально более чистую реализацию и сериализацию формат. В целом, большая работа. Я могу помочь вам в его реализации. Цитата: etotheipi от 17 июня 2012 года, 7:33:39 PM Существует одна проблема, хотя это может быть часть материалов вы уже упомянутых: дерево должно быть построены одинаково всеми сторонами, и из любого государства. И все двоичное дерево структуры вставки порядка зависит, если вы не хранить их в каком-то синтаксического дерева. Указание порядка вставки не работает, потому что кто-то строить с нуля, не знаю, как кто-то обновление с предыдущего дерева будет вставлять их. Но я не хотел бы, чтобы перейти к основному синтаксическому дереву, из-за космическую неэффективность. Что-то вроде Патрисии дерева / синтаксического дерева вероятно, будет работать, но это очень сложно реализовать (правильно) и там не много существующих, надежные реализации там. (EDIT:. К сожалению, это в основном то, что Сократ выше, я должен сначала прочитать всю нить 🙂 Это не проблема; просто указать порядок вставки / удаления. Например: «Process блоков в порядке; для каждого процесса блок операций в порядке; и для каждой транзакции сначала удалить все входы (в указанном порядке) из, а затем вставить все выходы (по порядку) в альт-цепи Merkle дерева». Вы, возможно, придется бросить частный случай там сделок, которые в качестве входных данных выходных данных транзакции, которая происходит позже в том же блоке (в том, что даже разрешено?). Почему (и как) вы бы создавать дерево с нуля без любого доступа к blockchain или дерева в последней альт-цепи контрольно-пропускной пункт? Цитата: etotheipi Рассмотрим 10 неизрасходованные-TxOuts, {0,1,2,3,4,5,6,7,8,9}. Вы и я оба построения тот же двоичный / красный задний дерево, за исключением того, что вы начинаете с нуля, и я начинаю с дерева, где элементы {0,1,2,5,6,9,13} являются частью дерево. Я должен добавить {3,4,7,8} и удалить {13} из моего дерева. Вы просто добавить все 10 элементов в определенном порядке. Мы собираемся, чтобы получить разные корни. Я технически знаю, как бы я был построен ваше дерево, но я, возможно, придется начать все сначала и заново установите все с нуля, если бы я хотел, чтобы убедиться, что моя структура дерева соответствует вашим. Вот что я имею в виду "коммутативное вычисление" - мы должны убедиться, что независимо от того, вы начинаете с нуля, или обновления существующего дерева с любой точки в прошлом, что вы получите тот же ответ. Нет, это происходит в неправильном направлении. Обновления blockchain происходят в атомарных операций: блоки. Просто мандат, что деревья построены / обновлены в соответствии с каноническим упорядочением предоставленной blockchain. Если вы настаиваете на создание дерева поиска с нуля, просто повторит blockchain вставки и удаления в порядке, указанном в нем. Или вы можете начать с дерева последнего найденного альт-цепи контрольно-пропускной пункт, и переигрывать вставки & делеции с этого момента. Да, порядок операций вопросов, так стандартизировать порядок операций.

18 июня 2012, 12:03:41 AM	# 16
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Две большие вопросы, доведенные до сих пор, в вне обсуждения: (1): Я в настоящее время в почтительном несогласии с Сократом о возможности построения лиц без неизрасходованных-txout дерев. Резюме: Если бы можно были использовать красно-черное дерево, чтобы хранить эту информацию, то точная структура этого дерева будет зависеть от целого, а точнее, инкрементальная история дополнений и удалений в дерево, начиная с блока генеза. Для того, чтобы построить дерево с нуля, я должен повторить всю историю в том же порядке каждый раз. Я придерживаюсь мнения, что вы должны быть в состоянии начать с текущим списком неизрасходованных-TxOuts, однако в том, что вы получили их, и должны быть в состоянии построить правильный дерево без зная ничего об истории, как добавили элементы и удалены. При использовании ванили красно-черных дерева, если я начну только с текущим списком неизрасходованного TxOuts, у меня есть все узлы в дереве - но мне нужен вся история уже отработанного TxOuts просто, чтобы иметь возможность повторить эту историю построить дерево правильно. Это, кажется, безвкусное и опасно. Но я не могу понять, почему, кроме кишечника инстинкт. Контраргумент в том, что вы никогда не окажетесь в этом положении: вы либо загрузки и обработки всей цепочки, в этом случае у вас нет проблемы Воспроизводятся добавочные обновления. Или вы загружаете с некоторой контрольной точки, в этом случае вы можете переигрывать вставки и удаления от этой контрольной точки с минимальными усилиями. (2)Я понял первоначальное предложение DiThi, поскольку гораздо более простая структура дерева, которая не может обеспечить поведение облегченной узла ненадежной, что мои дерева делают. Однако, как я перечитал его, я понял, что я думаю, что он прав - более простое дерево неизрасходованного TxOuts на самом деле даст вам такую возможность. Это правильно? Пару месяцев назад, когда я впервые предположил эту идею, у меня был очень хороший хороший повод полагать, что вам нужно агрегировать неизрасходованный-TxOuts (UTXOs) по адресу / скрипте. Если вы не сделали этого, плохое случится. К сожалению, я не помню, что эти плохие вещи были! Это вполне разумно, что я неправильно применил некоторые логики в моей голове, и решил, что мне нужен unnecesssarily-сложную структуру данных для обеспечения безопасности. Так что, я не права? Я не уверен. Каковы недостатки и преимущества структуры дерева DiThi в сравнении шахтное (его листьев узлы UTXOs, мои корни из UTXO подразделам деревьев). Одна вещь, которую я могу думать о том: как вы знаете, что равноправный дал вам полный список UTXOs и не скрывает остальные? Хотя, я уже сделал предположение, что у вас есть по крайней мере один честный пэр, так что, вероятно, не проблема ... это?

18 июня 2012, 12:09:42 AM	# 17
BrightAnarchist Сообщения: 853 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов слушать ... очень хорошие идеи здесь, подобно моей концепции баланса цепи, но гораздо более конкретизированы

18 июня 2012, 12:17:43 AM	# 18
maaku Сообщения: 905 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов котировка Контраргумент в том, что вы никогда не окажетесь в этом положении: вы либо загрузки и обработки всей цепочки, в этом случае у вас нет проблемы Воспроизводятся добавочные обновления. Или вы загружаете с некоторой контрольной точки, в этом случае вы можете переигрывать вставки и удаления от этой контрольной точки с минимальными усилиями. Верный. Так почему это важно? Я не уверен, почему это «безвкусная» либо, так как Вы отмечаете нет случая использования для воссоздания дерева только из несортированного списка выходов в любом случае. котировка Пару месяцев назад, когда я впервые предположил эту идею, у меня был очень хороший хороший повод полагать, что вам нужно агрегировать неизрасходованный-TxOuts (UTXOs) по адресу / скрипте. Если вы не сделали этого, плохое случится. К сожалению, я не помню, что эти плохие вещи были! Это вполне разумно, что я неправильно применил некоторые логики в моей голове, и решил, что мне нужен unnecesssarily-сложную структуру данных для обеспечения безопасности. Если ничего другого, это, безусловно, удобно тянуть во всех неизрасходованных выходах для адреса без необходимости идти по всему дереву, как вы можете в соответствии с вашим подходом. Это очень распространенный случай использования, поэтому было бы целесообразно, чтобы оптимизировать его.

18 июня 2012, 12:27:37 AM	# 19
etotheipi Сообщения: 1428 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: maaku 18 июня 2012, 12:17:43 AM котировка Контраргумент в том, что вы никогда не окажетесь в этом положении: вы либо загрузки и обработки всей цепочки, в этом случае у вас нет проблемы Воспроизводятся добавочные обновления. Или вы загружаете с некоторой контрольной точки, в этом случае вы можете переигрывать вставки и удаления от этой контрольной точки с минимальными усилиями. Верный. Так почему это важно? Я не уверен, почему это «безвкусная» либо, так как Вы отмечаете нет случая использования для воссоздания дерева только из несортированного списка выходов в любом случае. Я не указывал, что, потому что я не думаю, что я согласен с этим. Это контраргумент, что, в то время как я не могу оспаривать его непосредственно в данный момент, делает меня очень неудобно. Какое будущее Прецедент уже не считается, что бы чахлыми этим решением? Я только соглашаясь, что у меня нет прямого счетчика аргумент для него (и, следовательно, не может полностью защитить свою позицию). Но я с трудом верю, что я единственный, кто будет беспокоить: я думаю, что это очень безвкусное, что если у меня есть каждый узел в дереве, что я до сих пор загрузки GB больше данных просто знать, как организовать (или, вернее, я мог бы также просто повторно загрузить дерево непосредственно, в этой точке).

18 июня 2012, 12:51:42 AM	# 20
socrates1024 Сообщения: 125 Цитировать по имени цитировать ответ	Re: Окончательные сжатия blockchain Вт / траст свободного облегченных узлов Цитата: etotheipi 18 июня 2012, 12:03:41 AM У меня был очень хороший хороший повод полагать, что вам нужно агрегировать неизрасходованный-TxOuts (UTXOs) по адресу / скрипте. Если вы не сделали этого, плохое случится. К сожалению, я не помню, что эти плохие вещи были! Одна из приятных вещей о структуре поиска Merkle, а не просто произвольно упорядоченной Merkle дерева, является то, что вы можете доказать, что ключ не является в базе данных. Даже с типичным Merkle дерева, как и нынешний blockchain, это потребует линейного усилия, чтобы доказать, что сделка не существуют - если у вас есть все это O (1) корень хэш, и вы не доверяете никому! Даже в более общем случае, вы можете сделать подтвержденный диапазон запрос "для только O (M журнал N) усилия (где М числа результатов, N является размером дерева). Если вы храните каждую неизрасходованную-монетку в бинарном дереве поиска, упорядоченном по адресу, то вы можете попросить ненадежный сервер, чтобы дать вам снимок всех расходуемых монет, связанные с этим адресом. Там нет никакого способа для них, чтобы опустить любую. Попробую описать ситуацию, как я предпочитаю, так как трудно следить за условиями иначе. Есть две стороны, облегченная-Client (Клиент) и помощник (Server). Цель состоит в том, Клиенту не нужно доверять серверу, но для сервера, чтобы хранить все данные. Клиент только когда нужно хранить (например, на диске) постоянную O (1) количество состояний - корневой хэш. Для того, чтобы решить, что корень хэш для использования, Клиент должен будет опираться на доказательства правильности работы признать последний блок. Если клиент запрашивает у сервера для списка неизрасходованных-монет, соответствующих целевой адрес, он получает два или более O (N журнала) путь через дерево Merkle. Первый путь к элементу с наибольшими адресами (лексическим упорядочением), который меньше, чем целевой адрес. Последняя представляет собой путь к наименьшему элементу с большим адресом. Если бы не было никаких операций, соответствующие цели, то эти два элемента будут находиться рядом. В любом случае, клиент перебирает пути он получает на каждом шаге проверки, что пути примыкают в дереве (и, конечно же, что хэши последовательны и привести к корню). [Править] Я надеюсь, что это превращается в Merkle деревьев megathread! [/ Править]

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW