Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
10 декабря 2017, 5:48:02 PM   # 1
 
 
Сообщений: 57
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Есть ли причина, почему Bitcoin не имеет реализации динамического масштабирования так, как это имеет динамические параметры сложностей? Например, вместо того, чтобы спорить, насколько большой блок должен быть каждые несколько лет, почему бы нам не позволить сеть сама решить? Оттуда, возможно, компенсировать повышенную пропускную способность операторов узла с какой-то награды за запуск самого узла?

Это только мне кажется, что такой подход позволил бы размеру блока, чтобы увеличить или уменьшить в соответствии с реальными потребностями сети, поэтому было бы больше во время крупных расходов, и меньше в периоды относительной бездеятельности, ведущее к более низкому среднему использованию полосы пропускания, чем просто увеличивая его. Даже если есть причина, чтобы сохранить его от перехода выше определенной точки, не было больше смысла использовать произвольный потолок, так что блок может сокращаться до уровня ниже этого размера, но не подняться над ним - по крайней мере на начальном этапе - и, возможно, реализовать своего рода сообщество согласованных протокола, устанавливающего конкретные правила, если и при каких обстоятельствах потолок поднятым, а затем делает так как некоторые вторичной динамической системы после периода первоначального тестирования?

Так, например, одно динамическое правило будет увеличивать или уменьшать размер блока в соответствии с фактическими потребностями сети, в то время как второе динамическое правило будет установить значение пол и потолок, что первое правило должно работать в пределах, даже если это вызывает узкое место. Оттуда это второе правило будет корректировать значение потолка в соответствии со средними возможностями людей, работающих узлов, так что если достаточное количество людей хотят, чтобы потолок идти вверх, они просто должны модернизировать свое оборудование, чтобы справиться с этим, и вознаграждая людей, которые управляют узлы (возможно, на основе сетевой активности), что дает им стимул помогать расширять сеть.

У меня была эта мысль долгое время на самом деле. На первом взгляде, казалось бы пользу шахтеров больше иметь больше сборов, но я считаю, что шахтеры больно, потому что с более высокими гонорарами людьми менее готовы совершать сделки, а затем Bitcoin сам становится средством сохранения стоимости, а не передача значения, Я чувствую, что это должно быть. С улучшенной сетью, операционные сборы идут вниз и больше людей делают больше сделок и так шахтеры могут выжить на операционных издержках в одиночку, когда последняя монета добываются.

В то время как вторичные монеты также могут быть использованы для совершения покупок, не было бы биржевых сборов, участвующих, и что также влияет на цены каждой монеты и другие монеты имеют те же проблемы. По моим расчетам, для того, чтобы Bitcoin (или любой криптовалюта с таким же количеством монет), чтобы получить статус мировой резервной валюты, то ему необходимо будет стоить около миллиона долларов монет, что делает один Сатоши стоит около пенни , Оттуда, максимальные цифры прошлых ноль должны быть увеличены на значение для увеличения гораздо больше, и по-прежнему быть функциональным в том же порядке. Я бы утверждать, что также должно быть согласовано, что говорит набор правил, когда цифра добавляется, заранее потребности в нем, на основе какой-то прогнозируемое значение, чтобы иметь место в сети автоматически.

Есть ли реальная причина, почему-то, как это не может работать, или как-то менее предпочтительно, чем сценарий людей споря над мелкими деталями каждый так часто бессрочно?
Elliander сейчас офлайн Пожаловаться на Elliander   Ответить с цитированием Мультицитирование сообщения от Elliander Быстрый ответ на сообщение Elliander


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


13 декабря 2017, 6:24:28 AM   # 2
 
 
Сообщений: 57
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Получил 1806 Биткоинов
Реальная история.





Я хотел бы добавить, что я не верю, что Lightning Network является лучшим решением для масштабируемости. Хотя это, безусловно, может обратиться в настоящее время высокие гонорары, у меня есть некоторые долгосрочные опасения по поводу полагаться на него. Дело в том, сеть Bitcoin была разработана таким образом, что меньше монеты чеканятся в течение долгого времени, так что шахтеры могут постепенно перейти к выплачивается в тарифах. В конечном счете, только шахтеры финансовые стимулы будут иметь это операционные издержки, что означает больше сделок приведет к улучшению добычи стимулов.

Используя сеть молнии, чтобы открыть каналы, через которые несколько сделок может протекать без платы, что и обходит фактически может привести к повышению средней платы для всех остальных. В настоящее время он будет работать большим, потому что бы удалить из сети Bitcoin большого количества операций, которые могли бы перегружать сеть и повышают удобство использования для небольших сделок, но это не подножки необходимости решения сетевых проблем масштабируемости. Во всяком случае, кажется, что сеть молнии будет лучше использовать в качестве инструмента для децентрализованного обмена между cryptocurrencies, но не должно заменять способность какой-либо конкретной монеты, чтобы действовать как обмен ценности.

Если операторы узла были вознаграждены сетями то, как шахтеры в настоящее время в соответствии с их пропускной способностью они будут иметь финансовые стимулы для расширения масштабов их возможностей, ведущих к сети в целом масштабирование вверх, если динамическое масштабирование было реализовано. Это будет гарантировать, что сделки везде подтвердить дешево, а сеть молнии все еще может быть полезным для более быстрого в человеко-операциях в магазинах, где вы не хотите ждать больше, чем несколько моментов для транзакции, чтобы подтвердить.

Если мы пойдем по пути, опираясь на вторичной сеть для меновой стоимости, как именно шахтеры будут оплачены, когда нет монеты в мятый и нет на блок операциях для подтверждения?
Elliander сейчас офлайн Пожаловаться на Elliander   Ответить с цитированием Мультицитирование сообщения от Elliander Быстрый ответ на сообщение Elliander

13 декабря 2017, 6:37:37 AM   # 3
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Я вроде понравилось ваше предложение на первый взгляд, но потом я понял, что это уже реализовано.

Вы видите размер блока уже "динамический", Код определяет только максимальный размер блока, так как шахтер вы можете создавать блоки любой длиной до этого размера. Теоретически вы могли бы сделать неограниченный размер блока и пусть одного шахтера опорожнить mempool в следующем блоке, но это будет в конечном итоге в blockchain спама и безумной цепи вздутии живота (до точки Bitcoin становится непригодным для использования absoletely). Поэтому вам необходимо указать определенный разумный предел для каждого блока. И это то, что было сделано. Некоторые люди утверждают, что этот предел должен быть выше, и все это означает, что может быть выше, но это не решение, так как большие блоки означают большую blockchain, использование полосы пропускания и навороты. Молния (возможно, не в его нынешнем состоянии) совершенно иная - она ​​позволяет отправлять заграждения действительных сделок фактически не размещение большинства из них в blockchain, так blockchain останется это функция "банка", Сохраняя ваши деньги в безопасности, в то время как молния позволит вам эффективно использовать свои деньги небольшими порциями.

Colorblind сейчас офлайн Пожаловаться на Colorblind   Ответить с цитированием Мультицитирование сообщения от Colorblind Быстрый ответ на сообщение Colorblind

13 декабря 2017, 11:16:37 AM   # 4
 
 
Сообщений: 57
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Я понимаю, что блок может быть пустым - без операций - но не операторы узла до сих пор, чтобы загрузить полные размеры файлов? Я знаю, что блок всегда имеет следующие значения:

не Волшебное нет (значение всегда 0xD9B4BEF9) - 4 байта
BLOCKSIZE - 4 байта
Blockheader - 80 байт
Счетчик транзакций - 9 байт

Это означает, что пустой блок требует, как минимум, 97 байт. Однако, если размер блока установлен в 1 Мб, позволяющих этому быть заполнены данными транзакций, вопрос в том, если узлы в конечном итоге, чтобы загрузить размер блока файла 1 Мб, если пустой, или 97 байт, если пусто. Мол, разница между файл изображения, который содержит мягкие нули и один, который был обрезается. Если они не загружайте больше, чем они должны, это будет означать, что они масштабироваться вниз по мере необходимости. Если нет, то он действительно должен работать таким образом ОСОБЕННО, если люди говорят об увеличении размера блока.

Вторая часть предложения, хотя - имея максимальный блок увеличение размера динамически в соответствии с возможностями сети и обеспечить стимул к узлу операторов, чтобы сделать необходимые обновления, чтобы стоимость потолка блока должна быть увеличены динамически, как насчет этого?

Я полностью согласен, что безграничный размер может вызвать проблемы, и там должен быть разумным установленным значением потолка, но я до сих пор не понимаю, почему этот предел не может быть установлен по правилам, а не мнению. Вместо длинных задержек в принятии необходимых изменений в сети, это может произойти в тот момент, большинство операторов узлов готовы справиться с этим. При блокировке операторов узлов, которые не масштабируются с большинством, а также предоставлением финансовых стимулов для операторов узлов для более высокой пропускной способности канала, было бы создать подобную гонку вооружений к СБИС шахтерам, чтобы гарантировать, что сеть может быстро расширяться без необходимости аргументов над каждым небольшим увеличением размера блока.
Elliander сейчас офлайн Пожаловаться на Elliander   Ответить с цитированием Мультицитирование сообщения от Elliander Быстрый ответ на сообщение Elliander

14 декабря 2017, 8:40:35 AM   # 5
 
 
Сообщений: 56
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Вы имеете в виду, как в Monero?
Или Flexcap в Bitcoin безлимитный?
https://bitcoinmagazine.com/articles/can-flexcaps-settle-bitcoin-s-block-size-dispute-1446747479/
Xynerise сейчас офлайн Пожаловаться на Xynerise   Ответить с цитированием Мультицитирование сообщения от Xynerise Быстрый ответ на сообщение Xynerise

14 декабря 2017, 3:30:08 PM   # 6
 
 
Сообщений: 12
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

скажите мне, если есть хорошие материалы, возможно, текст или видео, где вы можете узнать тему скальпинга? Извините, если не по теме, дико извиняюсь. просто не могу найти хорошие материалы.
Shu1llerr сейчас офлайн Пожаловаться на Shu1llerr   Ответить с цитированием Мультицитирование сообщения от Shu1llerr Быстрый ответ на сообщение Shu1llerr

14 декабря 2017, 7:11:00 PM   # 7
 
 
Сообщений: 57
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Вы имеете в виду, как в Monero?
Или Flexcap в Bitcoin безлимитный?
https://bitcoinmagazine.com/articles/can-flexcaps-settle-bitcoin-s-block-size-dispute-1446747479/

Аналогичный. В этом случае, хотя размер устанавливаются исключительно на шахтере, тровый блок, так что все еще может привести к раздуваться, что потенциально может нанести вред пропускной способности оператора узла. Я имею в виду, в основном это создаст стимул для майнинг принимать все больше и больше сделок, но в какой-то момент было бы узкое место, которое может вызвать проблемы в работе сети. Для меня это больше похоже, не имеющие значения потолка на всех, в то время как я придерживаюсь мнения, что нам нужен потолок, только один, который масштабируется с сетевыми возможностями.

Это, как говорится, система требует пулы отказаться кусок вознаграждения сделать это интересное решение. Интересно, насколько хорошо это будет работать на практике, хотя. Для того, чтобы быть стоит отказаться от X% от вознаграждения блока, то операционные издержки должны более чем компенсировать это. С тяжелой перегруженностью было бы, безусловно, поможет мотивировать шахтер, чтобы облегчить, но не он также создает риск не завершить блок все вместе? Я имею в виду, как я понимаю, там никогда не бывает какой-либо прогресса в завершении блока. Это более или менее лотерея, где больше хеширования скорость просто означает больше попыток в секунду, но принимая более высокую трудность обработки больше сделок фактически означает шансы "угадывание" правильно идет вниз. Работая весь пул без такого риска вполне может уменьшить количество операций, они могут подтвердить, потому что это увеличивает шанс кто-то будет бить их к нему.

Еще одна проблема, как и ваша ссылка указывает, что было бы ввести инвестиционную атаку. Предоставление большого пула шахтеров возможность искусственно раздувать рейтинг трудности долгосрочной перспективе позволит другим горнякам быть вытеснены полностью - а именно те, которые используют менее эффективное оборудование, или живущие в районах с более высокой электрической стоимости. Было бы в корне изменить минимальную цену продукции, а также.

Например, я подсчитал, что если цена Bitcoin упала до $ 3k USD с нынешних людей уровня трудности платят 10 центов за киловатт-часов будет только заработать около $ 100 в месяц на Antminer S9, 20 центов за киловатт-часов будет просто разорвать даже, 30 центов киловатт-часов будет означать полную потерю. Для тех, кто работает Шахтеры Avalon, которые имеют больше электроэнергии, затрат на скорость хеширования, такая цена не будет означать никаких прибыли вообще. Вот почему я помещаю минимальную цену Bitcoin вокруг этой цены - потому что, когда сеть начинает разрушаться без шахтеров, идущих в автономном режиме.

Как она стоит уже не хватает конкуренции в рудничной сцене СИС, но есть некоторая конкуренция. не поэтому польза бы компании, как Bitmain использовать их шахтер раздувать сеть трудности на долгий срок, чтобы сделать их конкуренция не выгодно вообще? Для того, чтобы изгнать их из бизнеса? Точно так же, не будет приносить пользу страны, которая хочет уничтожить Bitcoin скупать (или захватить) большое количество шахтеров, чтобы создать свой собственный бассейн, а затем раздувают трудности таким образом, что они ни делают или теряют деньги на операции , так что никто не может сделать или потерять деньги, тем самым заставляя всех шахтеров, а потом они просто переверните переключатель, чтобы закрыть всю оставшуюся сеть?

Похоже, давая шахтеров, что большая сила мощности слишком много.
Elliander сейчас офлайн Пожаловаться на Elliander   Ответить с цитированием Мультицитирование сообщения от Elliander Быстрый ответ на сообщение Elliander

15 декабря 2017, 8:43:01 AM   # 8
 
 
Сообщений: 32
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Я вроде понравилось ваше предложение на первый взгляд, но потом я понял, что это уже реализовано.

Вы видите размер блока уже "динамический", Код определяет только максимальный размер блока, так как шахтер вы можете создавать блоки любой длиной до этого размера. Теоретически вы могли бы сделать неограниченный размер блока и пусть одного шахтера опорожнить mempool в следующем блоке, но это будет в конечном итоге в blockchain спама и безумной цепи вздутии живота (до точки Bitcoin становится непригодным для использования absoletely). Поэтому вам необходимо указать определенный разумный предел для каждого блока. И это то, что было сделано. Некоторые люди утверждают, что этот предел должен быть выше, и все это означает, что может быть выше, но это не решение, так как большие блоки означают большую blockchain, использование полосы пропускания и навороты. Молния (возможно, не в его нынешнем состоянии) совершенно иная - она ​​позволяет отправлять заграждения действительных сделок фактически не размещение большинства из них в blockchain, так blockchain останется это функция "банка", Сохраняя ваши деньги в безопасности, в то время как молния позволит вам эффективно использовать свои деньги небольшими порциями.
Я ненавижу быть все думы-у, но что, если молния сеть не является эффективной, или слишком громоздким или сложным? Я не вижу проблемы с поднимая крышку размера блока по мере необходимости. молния сеть кажется, что это будет так же, как централизованная (или более) в качестве "большой блок" Bitcoin.

Я чувствую, что мы бросились в слишком много изменений в этом году.
cryptodontus сейчас офлайн Пожаловаться на cryptodontus   Ответить с цитированием Мультицитирование сообщения от cryptodontus Быстрый ответ на сообщение cryptodontus

15 декабря 2017, 6:32:08 PM   # 9
 
 
Сообщения: 1456
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

С тех пор BIP106 впервые был предложен, я был поклонником идеи динамического масштабирования. Хотя вскоре после этого, я решил, что первоначальная концепция была слишком unrestrictive и имел возможность привести к опасному значительному увеличению размера, если она была оскорблена. Поэтому в течение долгого времени, я смотрел на различных настроек и регулировок, частично сократить любые чрезмерный рост, но и включать SegWit, ограничивают потенциал для игр системы и даже предотвратить резкие перепады давления плату. Так далеко, вот где я должен.  Все еще надеясь некоторые кодеры поинтересуется и получить его на следующий уровень, где он может фактически быть практичным для реализации.
DooMAD сейчас офлайн Пожаловаться на DooMAD   Ответить с цитированием Мультицитирование сообщения от DooMAD Быстрый ответ на сообщение DooMAD

16 декабря 2017, 12:49:42 AM   # 10
 
 
Сообщения: 980
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Я хотел бы добавить, что я не верю, что Lightning Network является лучшим решением для масштабируемости. Хотя это, безусловно, может обратиться в настоящее время высокие гонорары, у меня есть некоторые долгосрочные опасения по поводу полагаться на него. Дело в том, сеть Bitcoin была разработана таким образом, что меньше монеты чеканятся в течение долгого времени, так что шахтеры могут постепенно перейти к выплачивается в тарифах. В итоге единственный финансовый стимул шахтеры будут иметь это операционные издержки, что означает больше сделок приведет к улучшению добычи стимулов.

Используя сеть молнии, чтобы открыть каналы, через которые несколько сделок может протекать без платы, что и обходит фактически может привести к повышению средней платы для всех остальных. В настоящее время он будет работать большим, потому что бы удалить из сети Bitcoin большого количества операций, которые могли бы перегружать сеть и повышают удобство использования для небольших сделок, но это не подножки необходимости решения сетевых проблем масштабируемости. Во всяком случае, кажется, что сеть молнии будет лучше использовать в качестве инструмента для децентрализованного обмена между cryptocurrencies, но не должно заменять способность какой-либо конкретной монеты, чтобы действовать как обмен ценности.

Если операторы узла были вознаграждены сетями то, как шахтеры в настоящее время в соответствии с их пропускной способностью они будут иметь финансовые стимулы для расширения масштабов их возможностей, ведущих к сети в целом масштабирование вверх, если динамическое масштабирование было реализовано. Это будет гарантировать, что сделки везде подтвердить дешево, а сеть молнии все еще может быть полезным для более быстрого в человеко-операциях в магазинах, где вы не хотите ждать больше, чем несколько моментов для транзакции, чтобы подтвердить.

Если мы пойдем по пути, опираясь на вторичной сеть для меновой стоимости, как именно шахтеры будут оплачены, когда нет монеты в мятый и нет на блок операциях для подтверждения?
Для ответа на первый жирный текст: В то время как вы не ошиблись о характере уменьшения вознаграждения блока для того, чтобы поставить акцент на операционные издержки как вознаграждение за горняками, проблема масштабирования сборов сделки на самом деле не относятся к этому. Важно то, где награда лежит, а не количество. Сумма всегда будет связана с предложением и спросом имеющегося оборудования в сети. Если операционные издержки уменьшаются, шахтеры платят меньше, и поэтому мой меньше, что снижает общую сложность добычи и делает его более выгодным для остальных шахтеров, которые до сих пор в нем. Если они увеличивают количество шахтеров увеличится с ним, как будет трудность, чтобы сбалансировать все из.

Для ответа на второй жирный текст: Там всегда будут монеты помоему. Lightning сеть все еще зависит от шахтеров. Все это делает выполнить сверку, возможно, более отдельных операций внедорожных цепи в единую окончательную запись, которая когда-то "закрыто" получает положенную в blockchain. Чтобы поместить в blockchain, шахтеры все равно придется выбирать сделки и до сих пор платят гонорар. Разница заключается в том, что плата будет гораздо меньше, чем это было бы со всеми отдельными сделками, который прекрасно рассматривают поставку (шахтер) число будет внести соответствующие коррективы.
btcton сейчас офлайн Пожаловаться на btcton   Ответить с цитированием Мультицитирование сообщения от btcton Быстрый ответ на сообщение btcton

16 декабря 2017, 5:57:51 PM   # 11
 
 
Сообщений: 57
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Для ответа на первый жирный текст: В то время как вы не ошиблись о характере уменьшения вознаграждения блока для того, чтобы поставить акцент на операционные издержки как вознаграждение за горняками, проблема масштабирования сборов сделки на самом деле не относятся к этому. Важно то, где награда лежит, а не количество. Сумма всегда будет связана с предложением и спросом имеющегося оборудования в сети. Если операционные издержки уменьшаются, шахтеры платят меньше, и поэтому мой меньше, что снижает общую сложность добычи и делает его более выгодным для остальных шахтеров, которые до сих пор в нем. Если они увеличивают количество шахтеров увеличится с ним, как будет трудность, чтобы сбалансировать все из.

Для ответа на второй жирный текст: Там всегда будут монеты помоему. Lightning сеть все еще зависит от шахтеров. Все это делает выполнить сверку, возможно, более отдельных операций внедорожных цепи в единую окончательную запись, которая когда-то "закрыто" получает положенную в blockchain. Чтобы поместить в blockchain, шахтеры все равно придется выбирать сделки и до сих пор платят гонорар. Разница заключается в том, что плата будет гораздо меньше, чем это было бы со всеми отдельными сделками, который прекрасно рассматривают поставку (шахтер) число будет внести соответствующие коррективы.

Этот сценарий будет еще видеть, чтобы уменьшить удобство использования прямых сделок Bitcoin. Это означает, что каждый должен платить больше сборов полностью в пользу небольшой группы централизованных компаний платят меньше сборов в целом.

Для примера предположим, что мы в будущем, где шахтеры платят только в операционные издержки и сеть молнии сильно полагаться на компенсацию за то, что никогда не реализуется динамическое масштабирование. Онлайн продавцов, которые хотят обрабатывать миллионы транзакций в день во всем мире используют систему, в которой один на блок транзакции открывает канал в течение дня, а другой на блок транзакции закрывает канал в течение дня. Все операции, которые проходят через их платежную систему позаботятся на одном дыхании, удерживающего низкие комиссионных сборы за каждую отправку сделки между двумя компаниями. Тем не менее, люди, которые изначально отправить монету в этих централизованных кошельках будут платить очень высокие суммы, которые будут препятствовать независимое использованию бумажника (и увеличивают риск того, что происходит, когда централизованные компании выйти из бизнеса). Между тем, люди, которые просто хотят, чтобы отправить деньги кому-то по всему миру, не выиграют от сети освещения на всех, так как они имеют дело только с одной транзакцией, поэтому они должны платить больше, а также.

Причина, почему все застряли платить больше, потому что кто-то с несколькими транзакциями просто обрабатывает один, что означает, что стоимость должна быть распределена по меньшему количеству плательщиков, и те, с меньшим количеством сделок, в конечном счете, платят больше всего.


Я ненавижу быть все думы-у, но что, если молния сеть не является эффективной, или слишком громоздким или сложным? Я не вижу проблемы с поднимая крышку размера блока по мере необходимости. молния сеть кажется, что это будет так же, как централизованная (или более) в качестве "большой блок" Bitcoin.

Я чувствую, что мы бросились в слишком много изменений в этом году.

Я согласен с этим утверждением. Даже если сама молния сеть децентрализована, это только значение (что я могу видеть) находится в разрешении два централизованных систем для связи в общей сложности 2 сделок - один, чтобы открыть поток общения, и один, чтобы закрыть поток коммуникации. Это означает, что, например, два обмены могут использовать сеть молнии, чтобы недорогая операцию течь между практически мгновенно, но это не позволит два частным лицам через децентрализованную платформу для отправки что-либо в какой-либо увеличенной скорости или снижении стоимости. В то время как я на самом деле, как сеть молнии в качестве инструмента для уменьшения заторов (почему я должен ждать, потому что крупная компания имеет миллиона сделок он хочет обрабатывать?), Мне не нравится идея вся сеть в зависимости от это для избежания всех заторов. Нам все еще нужно решение, чтобы сохранить сеть работает гладко для всех остальных.

Как она стоит прямо сейчас, я перестал посылать Bitcoin все вместе. Это слишком дорого и занимает слишком много времени. Когда я хочу, чтобы послать кого-нибудь, я либо с помощью Litecoin или Dashcoin. Мое мнение таково, что, как она становится все легче и легче переносить между монетами - особенно если полностью децентрализованные платформы произойти - Bitcoin станет менее полезным для среднего человека без динамического масштабирования.  

С тех пор BIP106 впервые был предложен, я был поклонником идеи динамического масштабирования. Хотя вскоре после этого, я решил, что первоначальная концепция была слишком unrestrictive и имел возможность привести к опасному значительному увеличению размера, если она была оскорблена. Поэтому в течение долгого времени, я смотрел на различных настроек и регулировок, частично сократить любые чрезмерный рост, но и включать SegWit, ограничивают потенциал для игр системы и даже предотвратить резкие перепады давления плату. Так далеко, вот где я должен.  Все еще надеясь некоторые кодеры поинтересуется и получить его на следующий уровень, где он может фактически быть практичным для реализации.

Мое мнение таково, что открытая крышка слишком unrestrictive, но твердый колпачок слишком ограничительный. Вот почему я думаю, что нам нужен способ для сети, чтобы поднять крышку на его собственном в наборе ограничений, так что он не может раздуваться.

РЕДАКТИРОВАТЬ: Я посмотрел на свою нить, которая выглядит аналогично первой части того, что я предложил здесь, но что остановить размер блока от увеличения слишком быстро для сети справиться? Я думаю, что динамическое масштабирование необходимо сосредоточить внимание на как потребности сети, а также возможностях сетей с двумя различными решениями масштабирования, используемых вместе. Первая настройка сети в соответствии с потребностями сети, а второй настроить сеть в соответствии с возможностями сети. Вместе это обеспечивает гибкость, но должен быть какой-то стимул для операторов узлов быть готовы расширить для обработки возросшего трафика.
Elliander сейчас офлайн Пожаловаться на Elliander   Ответить с цитированием Мультицитирование сообщения от Elliander Быстрый ответ на сообщение Elliander

16 декабря 2017, 6:32:18 PM   # 12
 
 
Сообщения: 2002
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Я понимаю, что блок может быть пустым - без операций - но не операторы узла до сих пор, чтобы загрузить полные размеры файлов? Я знаю, что блок всегда имеет следующие значения:

не Волшебное нет (значение всегда 0xD9B4BEF9) - 4 байта
BLOCKSIZE - 4 байта
Blockheader - 80 байт
Счетчик транзакций - 9 байт

Это означает, что пустой блок требует, как минимум, 97 байт. Однако, если размер блока установлен в 1 Мб, позволяющих этому быть заполнены данными транзакций, вопрос в том, если узлы в конечном итоге, чтобы загрузить размер блока файла 1 Мб, если пустой, или 97 байт, если пусто.


97 байт.

Там нет необходимого размера блока.

Существует размер блока LIMIT. Это означает, что блоки не могут быть больше, чем предел. Блоки меньше, чем предел вполне справедливы и происходят все время.

Я до сих пор не понимаю, почему этот предел не может быть установлен по правилам, а не мнения.

Лимит устанавливается по правилам.

Изменение этих правил в настоящее время требует жесткого вилы. Жесткие вилки требуют подавляющего большинства пользователей согласны. Получение согласия требует покачиваясь мнений.

Консенсус трудно.

Вместо длинных задержек в принятии необходимых изменений в сети, это может произойти в тот момент, большинство операторов узлов готовы справиться с этим.

И как вы считаете "большинство операторов узлов"? Там нет никакого надежного способа узнать, сколько узлов операторов есть, и это дешево и легко установить миллионы программ все делая вид, что узлы для того, чтобы "вбросить в урну для голосования",

При блокировке операторов узлов, которые не масштабируются с большинством, а также предоставлением финансовых стимулов для операторов узлов для более высокой пропускной способности канала, было бы создать подобную гонку вооружений к СБИС шахтерам, чтобы гарантировать, что сеть может быстро расширяться без необходимости аргументов над каждым небольшим увеличением размера блока.

Проблема с автомасштабирования является то, что не является надежным показателем, может быть использован для определения того, когда размер должен расширять.

Трудность можно масштабировать в зависимости от времени между блоками. Это надежный показатель. Злоумышленник не может изменить время между блоками без фактического завершения доказательства-из-работы (в этом случае, если они в состоянии сделать это, то трудности нужно увеличить).
DannyHamilton сейчас офлайн Пожаловаться на DannyHamilton   Ответить с цитированием Мультицитирование сообщения от DannyHamilton Быстрый ответ на сообщение DannyHamilton

16 декабря 2017, 6:36:50 PM   # 13
 
 
Сообщения: 980
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Для ответа на первый жирный текст: В то время как вы не ошиблись о характере уменьшения вознаграждения блока для того, чтобы поставить акцент на операционные издержки как вознаграждение за горняками, проблема масштабирования сборов сделки на самом деле не относятся к этому. Важно то, где награда лежит, а не количество. Сумма всегда будет связана с предложением и спросом имеющегося оборудования в сети. Если операционные издержки уменьшаются, шахтеры платят меньше, и поэтому мой меньше, что снижает общую сложность добычи и делает его более выгодным для остальных шахтеров, которые до сих пор в нем. Если они увеличивают количество шахтеров увеличится с ним, как будет трудность, чтобы сбалансировать все из.

Для ответа на второй жирный текст: Там всегда будут монеты помоему. Lightning сеть все еще зависит от шахтеров. Все это делает выполнить сверку, возможно, более отдельных операций внедорожных цепи в единую окончательную запись, которая когда-то "закрыто" получает положенную в blockchain. Чтобы поместить в blockchain, шахтеры все равно придется выбирать сделки и до сих пор платят гонорар. Разница заключается в том, что плата будет гораздо меньше, чем это было бы со всеми отдельными сделками, который прекрасно рассматривают поставку (шахтер) число будет внести соответствующие коррективы.

Этот сценарий будет еще видеть, чтобы уменьшить удобство использования прямых сделок Bitcoin. Это означает, что каждый должен платить больше сборов полностью в пользу небольшой группы централизованных компаний платят меньше сборов в целом.

Для примера предположим, что мы в будущем, где шахтеры платят только в операционные издержки и сеть молнии сильно полагаться на компенсацию за то, что никогда не реализуется динамическое масштабирование. Онлайн продавцов, которые хотят обрабатывать миллионы транзакций в день во всем мире используют систему, в которой один на блок транзакции открывает канал в течение дня, а другой на блок транзакции закрывает канал в течение дня. Все операции, которые проходят через их платежную систему позаботятся на одном дыхании, удерживающего низкие комиссионных сборы за каждую отправку сделки между двумя компаниями. Тем не менее, люди, которые изначально отправить монету в этих централизованных кошельках будут платить очень высокие суммы, которые будут препятствовать независимое использованию бумажника (и увеличивают риск того, что происходит, когда централизованные компании выйти из бизнеса). Между тем, люди, которые просто хотят, чтобы отправить деньги кому-то по всему миру, не выиграют от сети освещения на всех, так как они имеют дело только с одной транзакцией, поэтому они должны платить больше, а также.

Причина, почему все застряли платить больше, потому что кто-то с несколькими транзакциями просто обрабатывает один, что означает, что стоимость должна быть распределена по меньшему количеству плательщиков, и те, с меньшим количеством сделок, в конечном счете, платят больше всего.


В вакууме, вы правы. Тем не менее, важно отметить, как много сетевого трафика, в самом деле, подхватили эти небольшой группой централизованных компаний. Например, прямо сейчас, как объем торгов Bitcoin увеличивается, много сделок, отправленных и полученных через сеть, связаны с какой-то обмен несоразмерно. Управление всех эти операций внедорожных цепи, а затем завершаете их на цепи поможет освободить место для прямых сделок, вы говорите о том, кто будет в конечном итоге платить меньше сборов из-за меньшую перегрузку сети. Централизованные компании делать прямая выгода от этого изменения, как вы говорите, но это также косвенно помогает пользователям с использованием независимых кошельков, которые я предполагаю, что буду включать в себя большинство из нас здесь.

Что же касается того, что произойдет, если заторы в сети на самом деле вызвана большим отрывом прямых сделок, я признаю, что я не знаю, как молния сеть может помочь в этом отношении. Это, как говорится, я, конечно, не знаю, все особенности Молнии сети, но вы принести хороший момент.

--

В качестве примечания: Если только большинство обсуждение темы может быть, как этот, где люди могут реально обсудить без спамеров повторяющимися то же самое, другие уже сказали, что было бы здорово.
btcton сейчас офлайн Пожаловаться на btcton   Ответить с цитированием Мультицитирование сообщения от btcton Быстрый ответ на сообщение btcton

16 декабря 2017, 8:41:24 PM   # 14
 
 
Сообщения: 1848
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Предположим, что мы в будущем, где шахтеры платят только в операционные издержки и сеть молнии сильно полагаться на компенсацию за то, что никогда не реализуется динамическое масштабирование. Онлайн продавцов, которые хотят обрабатывать миллионы транзакций в день во всем мире используют систему, в которой один на блок транзакции открывает канал в течение дня, а другой на блок транзакции закрывает канал в течение дня. Все операции, которые проходят через их платежную систему позаботятся на одном дыхании, удерживающего низкие комиссионных сборы за каждую отправку сделки между двумя компаниями. Тем не менее, люди, которые изначально отправить монету в этих централизованных кошельках будут платить очень высокие суммы, которые будут препятствовать независимое использованию бумажника (и увеличивают риск того, что происходит, когда централизованные компании выйти из бизнеса). Между тем, люди, которые просто хотят, чтобы отправить деньги кому-то по всему миру, не выиграют от сети освещения на всех, так как они имеют дело только с одной транзакцией, поэтому они должны платить больше, а также.

Причина, почему все застряли платить больше, потому что кто-то с несколькими транзакциями просто обрабатывает один, что означает, что стоимость должна быть распределена по меньшему количеству плательщиков, и те, с меньшим количеством сделок, в конечном счете, платят больше всего.

Это не работает так. Люди могут оплатить непосредственно друг с другом, и нет необходимости закрывать каналы ("в конце дня" или иначе, лол)

Пожалуйста, прекратите тратить свое время (и все ELSES): узнать, как концепция Молния работает первый, а затем снова начать говорить.
Carlton банков сейчас офлайн Пожаловаться на Карлтон Банки   Ответить с цитированием Мультицитирование сообщения от Carlton Банки Быстрый ответ на сообщение Carlton Банки

16 декабря 2017, 10:12:49 PM   # 15
 
 
Сообщений: 57
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Я понимаю, что блок может быть пустым - без операций - но не операторы узла до сих пор, чтобы загрузить полные размеры файлов? Я знаю, что блок всегда имеет следующие значения:

не Волшебное нет (значение всегда 0xD9B4BEF9) - 4 байта
BLOCKSIZE - 4 байта
Blockheader - 80 байт
Счетчик транзакций - 9 байт

Это означает, что пустой блок требует, как минимум, 97 байт. Однако, если размер блока установлен в 1 Мб, позволяющих этому быть заполнены данными транзакций, вопрос в том, если узлы в конечном итоге, чтобы загрузить размер блока файла 1 Мб, если пустой, или 97 байт, если пусто.

97 байт.

Там нет необходимого размера блока.

Существует размер блока LIMIT. Это означает, что блоки не могут быть больше, чем предел. Блоки меньше, чем предел вполне справедливы и происходят все время.


Приятно слышать.


котировка


Вместо длинных задержек в принятии необходимых изменений в сети, это может произойти в тот момент, большинство операторов узлов готовы справиться с этим.

И как вы считаете "большинство операторов узлов"? Там нет никакого надежного способа узнать, сколько узлов операторов есть, и это дешево и легко установить миллионы программ все делая вид, что узлы для того, чтобы "вбросить в урну для голосования",

При блокировке операторов узлов, которые не масштабируются с большинством, а также предоставлением финансовых стимулов для операторов узлов для более высокой пропускной способности канала, было бы создать подобную гонку вооружений к СБИС шахтерам, чтобы гарантировать, что сеть может быстро расширяться без необходимости аргументов над каждым небольшим увеличением размера блока.

Проблема с автомасштабирования является то, что не является надежным показателем, может быть использован для определения того, когда размер должен расширять.

Трудность можно масштабировать в зависимости от времени между блоками. Это надежный показатель. Злоумышленник не может изменить время между блоками без фактического завершения доказательства-из-работы (в этом случае, если они в состоянии сделать это, то трудности нужно увеличить).


Хороший вопрос, и хорошие моменты. К примеру, в последний раз, когда я написал алгоритм сортировки для класса CS я измерил показатели, установив целое приращение каждый раз, когда были выполнены какие-либо проверки. Таким образом, я был в состоянии получить достоверную информацию отдельно от вычислительной мощности данной машины. Все, что я сосредоточился на была основной суть того, что делает программа.

Так что делает узел? В чем суть суть его функциональность, которая действует, чтобы ограничить возможности сетей?

котировка
"для того, чтобы подтвердить и ретранслировать сделки, Bitcoin требует более сетей шахтеров обработки транзакций, он должен транслировать сообщения в сеть с помощью «узлов». Это первый шаг в процессе транзакции, что приводит к подтверждению блока." - https://www.coindesk.com/bitcoin-nodes-need/

Итак, надежная метрика для работы узла является сохранение дорожки информации транслируется в сети. Поскольку это возможность сети, мы заботимся о том, может быть, было бы простое число приложенного к передаваемой информации в сеть, указывающей, если узел находится ниже или вблизи его пиковые? Если каждый узел прикреплен эта информация сообщения, которые он передает в сеть, а затем он был прочитан как совокупность из законченных блоков, было бы добавить только 2 байта до минимального размера для блока, а затем блок в целом может быть считан для определения среднего значения. Информация, передаваемая также совокупность различных факторов, применяемых к машине, чтобы дать в среднем, который заканчивается тем, что больше голосов.

Так, в качестве примера: Предположим, что мы имеем 10 узлов, участвующих в конкретном блоке. 6 из них сообщают о 0 - о том, что они значительно ниже мощности. 3 сообщает 1, чтобы указать, что находится вблизи емкость. 1 сообщает 2, указывающие именно на это предел. Это означает, что у нас есть 6 голосов, чтобы увеличить крышку и 4 голоса против, но только если текущий размер блока равен текущему пределу размера блока. Если они заполнены, следующий блок имеет немного более высокий потолок. Сумма, которая может быть основана на дополнительной цифре в пределах этого целое, как некоторый сигнал к сети, насколько больше он может работать. Следствием этого является то, что узел, который на полную мощность не будет иметь возможность участвовать в так много сделок, поэтому получит меньше голосов.

Это упрощенный пример, поскольку данный узел может иметь тысячи сделок, которые он принимал участие в, но это нормально. Если она обрабатывает больше транзакций имеет больше голосов, а это означает, что более мелкие узлы, которые не способны, как могли бы участвовать в менее сделок учитывая его самостоятельно определили рейтинг возможностей. Предоставление операторов узлов, которые имеют бумажник, прикрепленный к узлу часть платы за транзакцию для участия в этом процессе даст стимул для оператора узла для высококлассного обрабатывать больше транзакций.

Теперь, если происходит обратная, где большинство операторов узлов голосуют за то, что они находятся в емкости, сеть может ограничить там, или если голос склоняется к ней слишком много сети может масштабироваться обратно - даже если блок не заполнен , Формула может решить, сколько масштабировать его обратно, а также.

Я не вижу никаких причин, почему мы не можем сделать это.
Elliander сейчас офлайн Пожаловаться на Elliander   Ответить с цитированием Мультицитирование сообщения от Elliander Быстрый ответ на сообщение Elliander

16 декабря 2017, 10:15:01 PM   # 16
 
 
Сообщений: 57
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Предположим, что мы в будущем, где шахтеры платят только в операционные издержки и сеть молнии сильно полагаться на компенсацию за то, что никогда не реализуется динамическое масштабирование. Онлайн продавцов, которые хотят обрабатывать миллионы транзакций в день во всем мире используют систему, в которой один на блок транзакции открывает канал в течение дня, а другой на блок транзакции закрывает канал в течение дня. Все операции, которые проходят через их платежную систему позаботятся на одном дыхании, удерживающего низкие комиссионных сборы за каждую отправку сделки между двумя компаниями. Тем не менее, люди, которые изначально отправить монету в этих централизованных кошельках будут платить очень высокие суммы, которые будут препятствовать независимое использованию бумажника (и увеличивают риск того, что происходит, когда централизованные компании выйти из бизнеса). Между тем, люди, которые просто хотят, чтобы отправить деньги кому-то по всему миру, не выиграют от сети освещения на всех, так как они имеют дело только с одной транзакцией, поэтому они должны платить больше, а также.

Причина, почему все застряли платить больше, потому что кто-то с несколькими транзакциями просто обрабатывает один, что означает, что стоимость должна быть распределена по меньшему количеству плательщиков, и те, с меньшим количеством сделок, в конечном счете, платят больше всего.

Это не работает так. Люди могут оплатить непосредственно друг с другом, и нет необходимости закрывать каналы ("в конце дня" или иначе, лол)

Согласно Lightning сети FAQ:

котировка

Система использует двунаправленные каналы оплаты, которые состоят из нескольких сигнатур адресов.
Один на цепочке транзакций необходимы, чтобы открыть канал, а другая транзакция на цепочке может закрыть канал.

После того, как канал открыт, значение может быть передано мгновенно между контрагентами, которые обмениваются реальный Bitcoin сделок, но не передавать их в сеть Bitcoin.

- https://medium.com/@AudunGulbrands1/lightning-faq-67bd2b957d70

Это означает, что да, одна сделка необходима, чтобы открыть канал, а другой нужен, чтобы закрыть канал, но на цепи. Это вовсе не означает, что есть предел тому, как долго канал может оставаться открытым, хотя, так что в случае людей, которые оставляют его открытым на неопределенный срок, который заканчивается тем, что еще хуже для всех остальных, кто использует на цепи сделок по сравнению с теми, кто иногда закрывает канал ,

Кроме того, я никогда не говорил, что люди не могут платить напрямую. Я сказал, что люди, которые не отправляли большое количество сделок, не выиграют от использования молний сети самого. (Хотя я делал это ясно, что в краткосрочной перспективе это имеет преимущество за счет облегчения заторов)

Пожалуйста, прекратите тратить свое время (и все ELSES): узнать, как концепция Молния работает первый, а затем снова начать говорить.

Пожалуйста, не отвечайте на резьбу с снисходительным отношением, особенно с неточной информацией, чтобы вы не видели, как троллинг. Это последние, как был ненужным и умаляет поток разговора. Даже если бы я был неправ (и я не был), нет ничего плохого в том, неправильно и исправляется.
Elliander сейчас офлайн Пожаловаться на Elliander   Ответить с цитированием Мультицитирование сообщения от Elliander Быстрый ответ на сообщение Elliander

16 декабря 2017, 10:29:46 PM   # 17
 
 
Сообщений: 57
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?


В вакууме, вы правы. Тем не менее, важно отметить, как много сетевого трафика, в самом деле, подхватили эти небольшой группой централизованных компаний. Например, прямо сейчас, как объем торгов Bitcoin увеличивается, много сделок, отправленных и полученных через сеть, связаны с какой-то обмен несоразмерно. Управление всех эти операций внедорожных цепи, а затем завершаете их на цепи поможет освободить место для прямых сделок, вы говорите о том, кто будет в конечном итоге платить меньше сборов из-за меньшую перегрузку сети. Централизованные компании делать прямая выгода от этого изменения, как вы говорите, но это также косвенно помогает пользователям с использованием независимых кошельков, которые я предполагаю, что буду включать в себя большинство из нас здесь.

Что же касается того, что произойдет, если заторы в сети на самом деле вызвана большим отрывом прямых сделок, я признаю, что я не знаю, как молния сеть может помочь в этом отношении. Это, как говорится, я, конечно, не знаю, все особенности Молнии сети, но вы принести хороший момент.


Я полностью согласен. В краткосрочной перспективе, по крайней мере, сеть Lightning явно необходима как решение для перегрузки путем выгрузки транзакций из крупных централизованных компаний с большим количеством сделок, так что было бы меньше заторов, и, следовательно, более низкие сборов и быстрее подтверждений для всех остальных. Я полностью на борту с этим прецедентом.

Однако мои опасения более в долгосрочной перспективе. С того, что происходит, когда шахтеры должны быть оплачены в операционных издержках, чтобы оставаться в эксплуатации на всех. Для того, чтобы сеть, чтобы быть выгодным для шахтеров, когда последняя монета добывается (и, на самом деле, задолго до этого) мы должны были бы иметь сдвиг в сторону платят в операционные издержки, что означает сеть сама должна и расширить для обработки больше сделок и также увеличение количества сделок в целом. Если мы держали блок потолок, где она есть, или даже просто немного над ним, не будет действительно достаточно сделок для шахтеров, чтобы принести пользу достаточно, чтобы оставаться в эксплуатации.

Моя точка зрения состоит в основном, что мы не должны полагаться на сети молнии, как серебряная пуля, и мы должны также план для одного изменения для учета всех изменений размеров блока, которые будут необходимы, а не решения этих проблем каждый несколько лет на повторение.

В качестве примечания: Если только большинство обсуждение темы может быть, как этот, где люди могут реально обсудить без спамеров повторяющимися то же самое, другие уже сказали, что было бы здорово.

Я надеюсь, что он может оставаться таким образом
Elliander сейчас офлайн Пожаловаться на Elliander   Ответить с цитированием Мультицитирование сообщения от Elliander Быстрый ответ на сообщение Elliander

17 декабря 2017, 12:52:39 AM   # 18
 
 
Сообщения: 1246
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Итак, надежная метрика для работы узла является сохранение дорожки информации транслируется в сети. Поскольку это возможность сети, мы заботимся о том, может быть, было бы простое число приложенного к передаваемой информации в сеть, указывающей, если узел находится ниже или вблизи его пиковые? Если каждый узел прикреплен эта информация сообщения, которые он передает в сеть, а затем он был прочитан как совокупность из законченных блоков, было бы добавить только 2 байта до минимального размера для блока, а затем блок в целом может быть считан для определения среднего значения. Информация, передаваемая также совокупность различных факторов, применяемых к машине, чтобы дать в среднем, который заканчивается тем, что больше голосов.

Так, в качестве примера: Предположим, что мы имеем 10 узлов, участвующих в конкретном блоке. 6 из них сообщают о 0 - о том, что они значительно ниже мощности. 3 сообщает 1, чтобы указать, что находится вблизи емкость. 1 сообщает 2, указывающие именно на это предел. Это означает, что у нас есть 6 голосов, чтобы увеличить крышку и 4 голоса против, но только если текущий размер блока равен текущему пределу размера блока. Если они заполнены, следующий блок имеет немного более высокий потолок. Сумма, которая может быть основана на дополнительной цифре в пределах этого целое, как некоторый сигнал к сети, насколько больше он может работать. Следствием этого является то, что узел, который на полную мощность не будет иметь возможность участвовать в так много сделок, поэтому получит меньше голосов.

Это упрощенный пример, поскольку данный узел может иметь тысячи сделок, которые он принимал участие в, но это нормально. Если она обрабатывает больше транзакций имеет больше голосов, а это означает, что более мелкие узлы, которые не способны, как могли бы участвовать в менее сделок учитывая его самостоятельно определили рейтинг возможностей. Предоставление операторов узлов, которые имеют бумажник, прикрепленный к узлу часть платы за транзакцию для участия в этом процессе даст стимул для оператора узла для высококлассного обрабатывать больше транзакций.

Теперь, если происходит обратная, где большинство операторов узлов голосуют за то, что они находятся в емкости, сеть может ограничить там, или если голос склоняется к ней слишком много сети может масштабироваться обратно - даже если блок не заполнен , Формула может решить, сколько масштабировать его обратно, а также.

Я не вижу никаких причин, почему мы не можем сделать это.
Любой показатель, который требует самостоятельной отчетности и не могут быть независимо проверены, чтобы быть правдой легко gameable. Предположим, что я действительно хочу больших блоков. Что мешает мне раскручивается несколько тысяч поддельных узлов (вы не можете сказать, что они являются поддельными, всеми они выглядят реальными, как это только природа узлов), а затем с каждым узлом голос о том, что это супер перегружено и нам нужно Gigabyte размеров блоков в настоящее время? Что мешает мне от лжи? Что делать, если я не буду на самом деле испытываю без нагрузки на всех, но я требую, чтобы все остальное, что я абсолютно перегружен? Там нет никакого способа для вас, чтобы убедиться, что то, что я говорю, это правда или прямо сейчас, не имея прямой доступ к моей машине. Вы действительно собираетесь доверять тому, что я говорю, и принять его за чистую монету?



Это вовсе не означает, что есть предел тому, как долго канал может оставаться открытым, хотя, так что в случае людей, которые оставляют его открытым на неопределенный срок, который заканчивается тем, что еще хуже для всех остальных, кто использует на цепи сделок по сравнению с теми, кто иногда закрывает канал ,
Почему это было бы хуже для всех остальных? Они не делают операции по цепочке, так что никто не осуществляется.



В общем, изменить то, что предельный размер блока требует проведения более, чем просто операционные издержки и мощности. Вы также должны учитывать такие вещи, как потенциал для увеличения темпов бесхозных, потенциал платы снайперов, могут ли узлы поддержки большего размера блока, любые потенциальные поверхности атаки или способы, что различные размеры блоков могут обострить существующие проблемы (например, квадратичная sighashing), и т.д. ,



Наконец, мета записка. Пожалуйста, не делайте так много последовательных сообщений, чтобы ответить на каждую должность в индивидуальном порядке. У них все в одном посте. Вы можете отделить каждый ответ, используя горизонтальное положение, как я сделал здесь.
achow101 сейчас офлайн Пожаловаться на achow101   Ответить с цитированием Мультицитирование сообщения от achow101 Быстрый ответ на сообщение achow101

17 декабря 2017, 2:29:48 AM   # 19
 
 
Сообщения: 2002
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

Итак, надежная метрика для работы узла является сохранение дорожки информации транслируется в сети. Поскольку это возможность сети, мы заботимся о том, может быть. , ,
Любой показатель, который требует самостоятельной отчетности и не могут быть независимо проверены, чтобы быть правдой легко gameable. , ,

Как вы, надеюсь, заметили с поста achow101 в ...

При попытке придумать решение, вы должны предположить, что значительная часть сети активно пытается воспользоваться вашей системы, чтобы сделать вещи хуже для всех остальных. Вы либо должны сделать это слишком дорого для них, чтобы беспокоить (что доказательство правильности работы выполняет), или вам нужно сделать метрическое то, что является независимой проверкой (который, как работает регулировка сложности).

Имейте в виду, что вы не можете предположить, что пользователи будут работать то же программное обеспечение, как вы. В отличие от вашей системы сортировки класса CS, где вы точно знали, что он собирается делать, и может рассчитывать на это, так как вы написали программу, в распределенной системе вы должны предположить, что противники будут писать свое собственное программное обеспечение, что будет пытаться участвовать в вашем сети без вашего ведома.
DannyHamilton сейчас офлайн Пожаловаться на DannyHamilton   Ответить с цитированием Мультицитирование сообщения от DannyHamilton Быстрый ответ на сообщение DannyHamilton

17 декабря 2017, 11:38:16 AM   # 20
 
 
Сообщения: 1456
Цитировать по имени
цитировать ответ
по умолчанию Re: Динамическое масштабирование?

С тех пор BIP106 впервые был предложен, я был поклонником идеи динамического масштабирования. Хотя вскоре после этого, я решил, что первоначальная концепция была слишком unrestrictive и имел возможность привести к опасному значительному увеличению размера, если она была оскорблена. Поэтому в течение долгого времени, я смотрел на различных настроек и регулировок, частично сократить любые чрезмерный рост, но и включать SegWit, ограничивают потенциал для игр системы и даже предотвратить резкие перепады давления плату. Так далеко, вот где я должен.  Все еще надеясь некоторые кодеры поинтересуется и получить его на следующий уровень, где он может фактически быть практичным для реализации.

Мое мнение таково, что открытая крышка слишком unrestrictive, но твердый колпачок слишком ограничительный. Вот почему я думаю, что нам нужен способ для сети, чтобы поднять крышку на его собственном в наборе ограничений, так что он не может раздуваться.

РЕДАКТИРОВАТЬ: Я посмотрел на свою нить, которая выглядит аналогично первой части того, что я предложил здесь, но что остановить размер блока от увеличения слишком быстро для сети справиться? Я думаю, что динамическое масштабирование необходимо сосредоточить внимание на как потребности сети, а также возможностях сетей с двумя различными решениями масштабирования, используемых вместе. Первая настройка сети в соответствии с потребностями сети, а второй настроить сеть в соответствии с возможностями сети. Вместе это обеспечивает гибкость, но должен быть какой-то стимул для операторов узлов быть готовы расширить для обработки возросшего трафика.

И в этом-то и загвоздка, там в настоящее время нет способа предсказать или определить пределы, когда речь идет о способности сети, кроме задавать узлы непосредственно устанавливать свои собственные индивидуальные предпочтительные шапки. Как-то я сомневаюсь, что много людей на этих досках бы рассмотреть возможность реализации идеи, заимствованные из Bitcoin Unlimited.  

Шутки в сторону, сочетая алгоритмические blockweight корректировки с учетом каждого узла, чтобы установить верхний предел размера они были бы готовы принять бы работать, если бы не тот факт, что он может легко заставить узлы из сети в hardfork, если они устанавливают свои собственные личные ограничения ниже, чем у большинства других участников, так что даже если люди были готовы принять идеи Б, она все еще имеет некоторые довольно серьезные недостатки. Если кто-то может придумать решение этой головоломке, я готов его услышать. До тех пор, это не точка слипания. Именно поэтому все, что я мог бы реально сделать, это любое повышение как можно меньше и позволить сети, чтобы отменить увеличение, если и когда спрос не там больше.

По сути, любая попытка поместить любой жесткий верхний предел неизбежно приводит к hardforks в какой-то момент в будущем, если вы не абсолютный гений и сумел найти обходной путь или взломать реализовать его как отказ в мягкой вилкой.


Пожалуйста, прекратите тратить свое время (и все ELSES): узнать, как концепция Молния работает первый, а затем снова начать говорить.

Пожалуйста, не отвечайте на резьбу с снисходительным отношением, особенно с неточной информацией, чтобы вы не видели, как троллинг. Это последние, как был ненужным и умаляет поток разговора. Даже если бы я был неправ (и я не был), нет ничего плохого в том, неправильно и исправляется.

Если вы решитесь обсудить на-цепи масштабирование, Карлтон прыгнет вниз горло для даже малейшей воспринимаемой трансгрессии. Не то, чтобы я оправдывающие поведение, это просто, что я не могу себе представить, что изменения в ближайшее время. Это только кажется, что в порядке вещей. Не позволяйте этому откладывать Вас.
DooMAD сейчас офлайн Пожаловаться на DooMAD   Ответить с цитированием Мультицитирование сообщения от DooMAD Быстрый ответ на сообщение DooMAD



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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW