|
14 мая 2016, 3:15:05 AM | # 1 |
Сообщения: 840
цитировать ответ |
Re: Пусть размер блока был не вопрос. Будет ли это решить проблему масштабирования?
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Примечание: Модерируемая тема. Воспалительные или воспаленные сообщения аргументируя за или против увеличения размера блока, или быть Butthurt о действии / бездействии, принятом по этому вопросу, или оскорблению любого на основе принятия по обе стороны от этой дискуссии, или утверждая, или обвиняя о заговорах на эту тему, или троллинг или травля людей, которые могли бы пойти нелинейную о теме, будут удалены. Это должно быть чисто технической дискуссии, а не политический. Capisce? Было бы относительно легко сделать блоки содержат хэш от цепи пучков, которые записывают дополнительные операции. Эти пучки могли бы быть любого размера, или же они могут быть один мегабайта и не может быть десятки или сотни, как это необходимо. Узлы получать только те блоки, то легко убедиться в том, что блок-цепь превратилась из блока генеза и посмотреть, сколько доказательство правильности работы он содержит, что позволяет им выбрать действительную длинную-цепь без отслеживания основного объема сделок. Потратива txOut потребует передач как Merkle ветви txOut в текущем наборе txOut (чтобы показать, что это не было потрачено) и пучок, содержащий запись ОЙ, где что txOut берет свое начало (так что клиент может проверить старую транзакцию ). Принимающий клиент может затем проверить правильность txOut. И, пуф. Вы можете создать еще один уровень "легкий клиент" который проверяет сам блок цепь, но не проверяет отдельные сделки для тех операций, которые непосредственно влияют на его исключение. И не размер блока больше не ограничивает скорость транзакций. Поэтому было бы лучше масштабируется, или, по крайней мере, это не будет выпадать с жестким ограничением при скорости транзакций увеличится. Но будет ли это лучше масштабируются * * достаточно? Независимо от того, как это делается, поднимая ограничение скорости ТХ означает увеличение пропускной способности / предел хранения для всех, кто, кто, загрузка и проверка на полную запись транзакции - на ту же сумму, если вы увеличили размер блока ограничивается. Потому что, в конечном счете, они же предел. Одно из преимуществ шахтеров более просто увеличить размер блока: вам нужно только скачать сам блок, чтобы получить возможность сформировать новый действующий блок, так что вы все равно получите время распространения и т.д. из одного мегабайта блоков максимального размера. Вы не особенно нарушает полосы пропускания, при условии, вы можете использовать полосу пропускания FIRST, чтобы получить блок, а затем начать загрузку сверток. Недостаток заключается в том, что шахтеры, которые еще не закончили загрузку свертка транзакций рискнут бесхозные блоки, если они включают в себя какую-либо сделку, которые были доступны до предыдущей пачки, потому что они еще не знают ли те, ОЕ были в комплекте. Так что, если ТХ не превратить его в самый первый блок он мог бы быть в, это может быть долгим иш времени, прежде чем кто-нибудь рискнул бы включить его в новый блок. |
14 мая 2016, 3:47:59 AM | # 2 |
Сообщения: 421
цитировать ответ |
Re: Пусть размер блока был не вопрос. Будет ли это решить проблему масштабирования?
Получил 1806 Биткоинов
Реальная история. Я хотел бы отметить, что в этом случае, шахтер, который принимает блок с пачкой рисков добычи блока на недопустимом сиротский блоке, если этот шахтер первого и не загружает пакет. Возможно, это не большая проблема только с долларовыми миллионерами в игре.
SDP |
14 мая 2016, 4:13:30 AM | # 3 |
Сообщения: 840
цитировать ответ |
Re: Пусть размер блока был не вопрос. Будет ли это решить проблему масштабирования?
Вл. Да это правда. И шахтеры будут иметь стимул, чтобы их конкуренты тратить время на добычу фиктивных блоков.
Так. Нет улучшения для шахтеров, на всех. |
14 мая 2016, 9:14:29 AM | # 4 |
Сообщения: 139
цитировать ответ |
Re: Пусть размер блока был не вопрос. Будет ли это решить проблему масштабирования?
Размер блока увеличение активации не является технической проблемой. Это управление, политическая проблема. В настоящее время климат можно охарактеризовать как отсутствие консенсуса, гражданской войны внутри общины Bitcoin. Никогда сообщество Bitcoin страдает от такого серьезного разрыва, как сегодня. По этой причине очень важно, что мы получаем утка в ряде, или как видный технолог бы сказать, чтобы достичь консенсуса.
|
14 мая 2016, 1:11:49 PM | # 5 |
Сообщения: 1246
цитировать ответ |
Re: Пусть размер блока был не вопрос. Будет ли это решить проблему масштабирования?
Примечание: Модерируемая тема. Я думаю, что вы забыли ударить, что сама умеренную кнопку.Было бы относительно легко сделать блоки содержат хэш от цепи пучков, которые записывают дополнительные операции. Эти пучки могли бы быть любого размера, или же они могут быть один мегабайта и не может быть десятки или сотни, как это необходимо. Я не совсем понимаю. Вы говорите о полных узлах здесь? Если это так, то полный узел все равно придется загрузить все эти связки, проверить все транзакции, чтобы убедиться, что они хэш хэшей в блоке, и проверьте, что хэши к корню Merkle. Требования к пропускной способности по-прежнему та же, и накладные расходы процессора немного выше, за счет более хэширования. Полный узел должен сделать это в противном случае злоумышленник шахтер может производить вредоносные блоки или просто добавляя в произвольных хэш.Узлы получать только те блоки, то легко убедиться в том, что блок-цепь превратилась из блока генеза и посмотреть, сколько доказательство правильности работы он содержит, что позволяет им выбрать действительную длинную-цепь без отслеживания основного объема сделок. Потратива txOut потребует передач как Merkle ветви txOut в текущем наборе txOut (чтобы показать, что это не было потрачено) и пучок, содержащий запись ОЙ, где что txOut берет свое начало (так что клиент может проверить старую транзакцию ). Принимающий клиент может затем проверить правильность txOut. Что это "Merkle филиал txOut"?И, пуф. Вы можете создать еще один уровень "легкий клиент" который проверяет сам блок цепь, но не проверяет отдельные сделки для тех операций, которые непосредственно влияют на его исключение. Это не очень легкое, если вы все еще скачивания 60+ Гб blockchain, хотя я предполагаю, что это легче, чем требования полного узла.И не размер блока больше не ограничивает скорость транзакций. Да, но тогда, что происходит, когда кто-то решает спам сети, как мы уже видели в прошлом? Это возвращает старый аргумент против имеющих неограниченного размера блока, который является то, что вы по сути предложили.Поэтому было бы лучше масштабируется, или, по крайней мере, это не будет выпадать с жестким ограничением при скорости транзакций увеличится. Но будет ли это лучше масштабируются * * достаточно? Независимо от того, как это делается, поднимая ограничение скорости ТХ означает увеличение пропускной способности / предел хранения для всех, кто, кто, загрузка и проверка на полную запись транзакции - на ту же сумму, Это позволило бы несколько сделок, но в конечном итоге столкнуться с аппаратными ограничениями и потенциально остановить многие пользователь запуска полных узлов из-за требования к пропускной способности и хранения. Это фактор централизации.если вы увеличили размер блока ограничивается. Потому что, в конечном счете, они же предел. Одно из преимуществ шахтеров более просто увеличить размер блока: вам нужно только скачать сам блок, чтобы получить возможность сформировать новый действующий блок, так что вы все равно получите время распространения и т.д. из одного мегабайта блоков максимального размера. Вы не особенно нарушает полосы пропускания, при условии, вы можете использовать полосу пропускания FIRST, чтобы получить блок, а затем начать загрузку сверток. Как SDP, шахтер все равно придется загрузить пакеты и проверить, прежде чем добыча в противном случае блок он строит на может быть недействительным. Тем не менее, многие шахтеры SPV добыча, поэтому они не проверки блока в любом случае или делают это параллельно. Это не повлияет на них, но это плохая практика, чтобы сделать это.Недостаток заключается в том, что шахтеры, которые еще не закончили загрузку свертка транзакций рискнут бесхозные блоки, если они включают в себя какую-либо сделку, которые были доступны до предыдущей пачки, потому что они еще не знают ли те, ОЕ были в комплекте. Так что, если ТХ не превратить его в самый первый блок он мог бы быть в, это может быть долгим иш времени, прежде чем кто-нибудь рискнул бы включить его в новый блок. Я хотел бы также отметить, что изменение блочной структуры, чтобы сделать это потребует жесткую вилки в любом случае. |
14 мая 2016, 2:56:29 PM | # 6 |
Сообщения: 840
цитировать ответ |
Re: Пусть размер блока был не вопрос. Будет ли это решить проблему масштабирования?
Примечание: Модерируемая тема. Размер блока увеличение активации не является технической проблемой. Это управление, политическая проблема. Я думаю, что вы забыли ударить, что сама умеренную кнопку. Aw, дерьмо, вы совершенно правы. Я ударил его, когда я сделал эту тему, но потом я вернулся, чтобы изменить тему (как ни странно, чтобы добавить умеренности примечания) и не понял, что мне нужно еще раз нажать на кнопку. Так ... Хм, у нас уже есть некоторые нетехническое дерьмо в этой теме, и я не могу удалить сообщение. Я предполагаю, что я собираюсь запереть нить, таким образом это не способствует пламенным, что люди не могут, кажется, сопротивляться. Кроме того, оба из людей, которые откликнулись на тему указали на проблему; шахтеры будут иметь стимул публиковать фиктивные блоки для того, чтобы заставить свои конкурент тратить время. Таким образом, на самом деле, дискуссия закончена. Он плыл, как идея, и она получила надлежащее опровержение. Было бы относительно легко сделать блоки содержат хэш от цепи пучков, которые записывают дополнительные операции. ... Узлы получать только те блоки, то легко убедиться в том, что блок-цепь превратилась из блока генеза и посмотреть, сколько доказательство правильности работы он содержит, что позволяет им выбрать действительную длинную-цепь без отслеживания основного объема сделок. Я не совсем понимаю. Вы говорите о полных узлах здесь? Если это так, то полный узел все равно придется загрузить все эти связки, проверить все транзакции, чтобы убедиться, что они хэш хэшей в блоке, и проверьте, что хэши к корню Merkle. Требования к пропускной способности по-прежнему та же, и накладные расходы процессора немного выше, за счет более хэширования. Полный узел должен сделать это в противном случае злоумышленник шахтер может производить вредоносные блоки или просто добавляя в произвольных хэш. Да, вы правы. Я говорил о новом типе узла где-то между полным и легким. Это может проверить всю цепочку блоков переходит к блоку генеза, и показать, что он имеет больше, чем POW фиктивный цепь может иметь. И это может проверить ОЕ в любом котрое сводит это происходит, чтобы загрузить (потому что он получает платеж или проверив, что один он послал меня в пачку). Но она не будет пытаться проверить всю запись транзакции. Было бы немного меньше бесполезной, чем обычный легкий клиент, в том, способность делать "точечная проверка" жгутов сделки, но не так хорошо для безопасности, как полный узел. Потратива txOut потребует передач как Merkle ветви txOut в текущем наборе txOut (чтобы показать, что это не было потрачено) и пучок, содержащий запись ОЙ, где что txOut берет свое начало (так что клиент может проверить старую транзакцию ). Принимающий клиент может затем проверить правильность txOut. Что это "Merkle филиал txOut"? Шахтеры положить Merkle корень - хэш корня дерева, где листья дерева неизрасходованные txOuts - в каждом блоке. Merkle ветвь достаточно информации для обхода дерева в txOut в вопросе - демонстрируя, что txOut является частью этих данных означает, демонстрируя, что до сих пор не проводилось. Во всяком случае, благодаря мне забыть нажать кнопку самостоятельной умеренными, а затем 2code делать точно, что я намеревался смягчить против, я запру эту тему. Это была плохая идея, так или иначе, как вы указали. |