Решаем проблему с размером блока

[Schnibble]

Всем привет!

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

Для начала предложу простое решение, альтернативное ограничению блока в 1MB. Так как этот лимит был введен в качестве защиты от спама, то можно просто сделать это другим способом. Допустим, мы считаем спамом все транзакции с комиссией ниже некоторой фиксированной величины (скажем, 20 satoshies/byte). В таком случае, проблема решается предельно просто - снимаем ограничение на размер блока и запрещаем майнерам включать в блоки транзакции с комиссией ниже этой величины, а также бесплатно включать собственные транзакции. Вернее, не совсем запрещаем, а все же оставим немного места (пусть будет 5%) для спорных транзакций:

Вариант решения №1

• лимит на размер блока отменяется^*
• полные узлы временно отклоняют блоки^*, если в них включены транзакции с комиссией ниже 20 сат/байт, или более 5% спорных транзакций (находившиеся в локальной очереди mempool менее 15 секунд)
• майнеры следуют тем же правилам, но кроме этого, они вынуждены передавать транзакции в сеть (в том числе собственные), как минимум за 15-20 секунд до включения их в блок
• minTxRelayFee параметр становится частью консенсуса и не может превышать 20 satoshies/byte, иначе ноды просто не смогут проверить блок на валидность

Основная идея в том, что транзакция должна попасть в мемпулы большинства полных нод и пробыть там какое-то время до того, как будет включена в блок. Это необходимо, чтобы майнеры не могли бесплатно включать собственные транзакции - теперь они, наравне со всеми, вынуждены сначала разослать их по сети.
 
5% спорных транзакций - смягчающее условие, это очень большой запас для того, чтобы ноды всегда приходили к консенсусу. Даже в том случае, если готовый блок каким-то образом будет получен раньше, чем некоторые включенные в него транзакции (что на практике почти невозможно).
 
* В любом случае, самая длинная цепочка в конечном итоге строится на PoW, и временно отбракованные блоки теоретически могут быть включены в блокчейн, но только если большинство майнеров (>50%) нарушат правила и согласятся их принять. Поэтому, во время оценки PoW для цепочки, ноды и майнеры не должны считать такие блоки, пока за ними не будет построено хотябы 2-3 нормальных блока. По этой же причине имеет смысл ограничить единовременное увеличение блока по сравнению со средним размером нескольких предыдущих, скажем не более чем вдвое.

Тема в англоязычной ветке: https://bitcointalk.org/index.php?topic=1851018.0
Некоторые выдержки из обсуждений: https://bitcointalk.org/index.php?topic=1840975.msg18465662#msg18465662

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

[1714809650]

1714809650

[1714809650]

1714809650

[1714809650]

1714809650

[1714809650]

1714809650

[1714809650]

1714809650

[Schnibble]

Начну с постановки проблемы. К сожалению, на данный момент мировое сообщество эту проблему решить не в состоянии. Но рано или поздно размер блока придется увеличивать - это очевидно. Даже в случае активации SegWit 1MB блока может быть недостаточно для создания каналов, а решения вроде XT или Unlimited имеют серьезные изъяны и влекут собой трудно предсказуемые последствия, следовательно необходимо найти лучшее решение.

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

[neiros]

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

Если они и есть, в чём я немного сомневаюсь, то очень капитально скрываются и шифруются, никак себя не проявляя.

Начну с постановки проблемы. К сожалению, на данный момент мировое сообщество эту проблему решить не в состоянии. Но рано или поздно размер блока придется увеличивать - это очевидно. Даже в случае активации SegWit 1MB блока может быть недостаточно для создания каналов, а решения вроде XT или Unlimited имеют серьезные изъяны и влекут собой трудно предсказуемые последствия, следовательно необходимо найти лучшее решение.

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

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

Есть у меня некоторые идеи и даже наработки, но с кем их обсуждать? - ещё одна проблема.

[Schnibble]

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

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

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

[Schnibble]

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

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

Есть у меня некоторые идеи и даже наработки, но с кем их обсуждать? - ещё одна проблема.

Я надеюсь, что эта тема хоть немного поможет решить данную проблему

[kzv]

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

[kcaterpillar]

Есть биткоин классик, есть анлимитед.
... Майнеры видят у кого какой клиент и кого больше. ...

А как майнеры видят, у кого какой клиент?

[Schnibble]

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

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

[Schnibble]

Не вижу предмета для обсуждения.

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

Если очень коротко, то я предлагаю увеличивать размер блока тогда, когда в этом появляется необходимость. То есть изменить правила консенсуса, так, чтобы майнеры могли увеличивать блок, когда очередь mempool транзакций (с достаточной комиссией) переполняется.

[neiros]

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

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

Есть у меня некоторые идеи и даже наработки, но с кем их обсуждать? - ещё одна проблема.

Я надеюсь, что эта тема хоть немного поможет решить данную проблему

Вариант решения некоторого количества проблем - http://ss-iq.blogspot.ru/2016/10/bip-rc001xx.html
Обсуждение - https://bitcointalk.org/index.php?topic=1724780.0

[Schnibble]

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

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

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

[neiros]

Какое то здесь своеобразное, что то вроде дежавю, имеет место быть, как мне кажется.

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

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

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

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

[Schnibble]

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

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

Вы имеете ввиду в текущей ситуации с блоком 1MB? Диапазон комиссии то можем выбрать какой угодно вплоть до (0;+∞).

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

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

[kzv]

Есть биткоин классик, есть анлимитед.
... Майнеры видят у кого какой клиент и кого больше. ...

А как майнеры видят, у кого какой клиент?

https://en.bitcoin.it/wiki/Protocol_documentation#Common_structures

Code:

Field Size 	Description 	Data type 	Comments
4 	version 	int32_t 	Identifies protocol version being used by the node
8 	services 	uint64_t 	bitfield of features to be enabled for this connection
8 	timestamp 	int64_t 	standard UNIX timestamp in seconds
26 	addr_recv 	net_addr 	The network address of the node receiving this message
Fields below require version ≥ 106
26 	addr_from 	net_addr 	The network address of the node emitting this message
8 	nonce 	uint64_t 	Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
? 	user_agent 	var_str 	User Agent (0x00 if string is 0 bytes long)
4 	start_height 	int32_t 	The last block received by the emitting node
Fields below require version ≥ 70001
1 	relay 	bool 	Whether the remote peer should announce relayed transactions or not, see BIP 0037

Code:

0000   f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00  ....version.....
0010   64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00  d...5.I2b.......
0020   00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00  .......P........
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff  ................
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050   00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00  ................
0060   3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68  ;..]...e./Satosh
0070   69 3a 30 2e 37 2e 32 2f c0 3e 03 00              i:0.7.2/.>..

[neiros]

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

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

Вы имеете ввиду в текущей ситуации с блоком 1MB?

В какой то мере, относительно всего остального возможного.

Диапазон комиссии то можем выбрать какой угодно вплоть до (0;+∞).

Пользователи для себя выбирают самое наилучшее.

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

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

Чего то я не совсем улавливаю какую проблему вы хотите решить. (очередными "костылями и подпорками" - условиями и ограничениями)

На текущий момент мы имеем:

• в блок 1MB помещается ~ 2000 транзакций
• интервал между блоками 10 мин.
• пропускная способность сети 2000 / 600 ~ 3 транзакции в секунду
• награда за блок - 12.5 BTC
• транзакционные комиссии в блоке ~ 1 BTC
• курс ~ $1000 за BTC
• рост блокчейна, текущий размер > 110 ГБ

https://bitcointalk.org/index.php?topic=1777210.msg17786072#msg17786072 - неважно какого размера будет хобот у слона, главное что бы все конечности, отверстия и всё остальное было на своих местах, и что бы этот слон мог самостоятельно ходить, бегать и вести полноценный образ жизни среди таких же как он и подобных ему существ.

[Schnibble]

В какой то мере, относительно всего остального возможного.

Если я правильно понял, то вы опасаетесь, что при изменении размера блока могут возникнуть какие-то проблемы? Поясните.

Чего то я не совсем улавливаю какую проблему вы хотите решить. (очередными "костылями и подпорками" - условиями и ограничениями)

Проблему ограниченной пропускной способности и высокой пользовательской комиссии.

[neiros]

В какой то мере, относительно всего остального возможного.

Если я правильно понял, то вы опасаетесь, что при изменении размера блока могут возникнуть какие-то проблемы? Поясните.

Честно говоря меня больше волнует один битый зелёный пиксель на совсем недавно приобретённом мониторе с разрешением 2560x1440, чем решение чужих, всё более монополизирующихся и централизирующихся проблем "потенциальных монополистов и диктаторов(императоров и патриархов) - вымогателей и тунеядцев, асикостроителей и их распространителей,.." Кроме потери времени ничего больше это на даёт.

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

Как разработчик чего-либо своего, в меру своих сил, возможностей и знаний, проблема размера блока передо мной вообще не стоит. Какой необходим будет размер, такой и будет, с учётом пожеланий кого бы то ни было. И если будет, и неизвестно когда.

Чего то я не совсем улавливаю какую проблему вы хотите решить. (очередными "костылями и подпорками" - условиями и ограничениями)

Проблему ограниченной пропускной способности и высокой пользовательской комиссии.

Каким образом?

[Schnibble]

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

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

Как разработчик чего-либо своего, в меру своих сил, возможностей и знаний, проблема размера блока передо мной вообще не стоит. Какой необходим будет размер, такой и будет, с учётом пожеланий кого бы то ни было.

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

Проблему ограниченной пропускной способности и высокой пользовательской комиссии.

Каким образом?

Чтобы ответить на этот вопрос, по сути, мне нужно сразу оформить предложение, как готорое решение в виде BIP. Скорее всего, когда найду время, то так и поступлю. Тогда можно будет обсудить детали.

Хотя, может быть, вы имеете ввиду другой вопрос: "Каким образом внедрить это решение?". У меня есть одна идея, как принудить всех майнеров перейти на новую цепочку. Но я не сторонник радикальных методов, и думаю, что лучший путь - это сделать очень хорошее обоснование, и привести все аргументы, что данное решение является оптимальным. Без политики.

[nyncuk]

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

Если они и есть, в чём я немного сомневаюсь, то очень капитально скрываются и шифруются, никак себя не проявляя.

Какая такая проблема!? Нет проблемы, сказали же вам: догами за розницу раскидаетесь как-нибудь 

[neiros]

Проблему ограниченной пропускной способности и высокой пользовательской комиссии.

Каким образом?

Чтобы ответить на этот вопрос, по сути, мне нужно сразу оформить предложение, как готорое решение в виде BIP. Скорее всего, когда найду время, то так и поступлю. Тогда можно будет обсудить детали.

Давайте обсудим сейчас. К чему такие сложности. У вас, по-моему, есть неплохие шансы получить решение не виде BIP, а сразу в виде коина...

Хотя, может быть, вы имеете ввиду другой вопрос: "Каким образом внедрить это решение?". У меня есть одна идея, как принудить всех майнеров перейти на новую цепочку. Но я не сторонник радикальных методов, и думаю, что лучший путь - это сделать очень хорошее обоснование, и привести все аргументы, что данное решение является самым оптимальным. Без политики.

Политика это концентрированное выражение экономики, сказал кое-кто когда то.
Затрагивая краеугольный камень экономики вы от политики никуда не спрячетесь.
https://bitcointalk.org/index.php?topic=577885.msg15150205#msg15150205