Actually, we don't need to determine how long it has been in a miner's mempool.

The idea is that transaction must get into the most nodes' mempools and stay there for some time before it can be included into the block. Thus miners are unable to include their own transactions for free and have to broadcast them over the network as all do.

So nodes should simply reject blocks that include these undesirable transactions:
- full nodes should temporarily reject blocks that consists more than 5% of transactions considered as undesirable (received less than 15 seconds ago | with a fee below 20 satoshies/byte)
- miners should follow the same rules, but in addition they need to hold transactions at least for 15-20 seconds before including them into the block

Nodes check that every transaction in a new received block presents in their mempool at least for 15 seconds. If the block contains too much undesirable transactions, most of nodes simply reject it. Thus miners have to relay transactions(their own too) and then hold them at least 15-20 seconds before including into the block. That's all.

It is a very good question.
I propose to reject all transactions that conflicting any other transaction in node's mempool. But we have to keep original transaction and reset time when it was received. So it cannot be included into the block another 15 seconds. In addition we need to keep the transaction's size and update it every time when we are rejecting a conflicting transaction that larger then all previous such transactions.

For example. If node receives a transaction "A" which size is 400 bytes, it should keep this transaction and two additional values: { tx_A, 400, time }. If then after 10 seconds it receives a conflicting transaction "B" which size is 500 bytes, it should update these values as follows: { tx_A, 500, time+10 }. If it receives another conflicting transaction "C" after another 5 seconds which size is 550 bytes, it should update the values: { tx_A, 550, time+15 }.

When node is validating the block and found some transaction that conflicts with a transaction in it's mempool, it should check that size of this transaction is not more then stored size. If it is so, the transaction shouldn't be considered as spam. Thus miners cannot include their own transactions into the block for free and cannot spam nodes' mempools with conflicting transactions.

Your thoughts have meaning under my proposal as well.

I have another similar idea but only in Russian so far: https://bitcointalk.org/index.php?topic=1840975.msg18325913#msg18325913

Ok. Node requires to be connected at least with one honest node (that relays all desireable transactions and blocks).

Ok. That makes sense.

BTW, I have an alternative proposal. Just an idea:

In the future, size of block can reach several hundred megabytes, that imminently cause unacceptable large delays from the moment of block generation until it is completely propagated over the network. At the same time, everybody has a large part of transactions in mempool, so there is no need to transfer them again. It is sufficient to transmit only the header, missing transactions (usually it is coinbase TX) and to define a standard algorithm to construct the block from existing transactions. For example, miner could relay just an array of TxIds.

Yes. But security is reduced very insignificant. Similarly, node can receive a regular orphan block and consider it valid.

Why?

This behavior for the case if nothing is done at start. What the problem? Just wait a few blocks and rejected chain becomes valid.

How often? Miners have to relay transactions before including them into the block.

I don't propose to allowing invalid blocks. Undesirable blocks are valid but they simply becomes orphan because most of nodes reject them.

Initially, I called it "temporarily rejected block that consists transactions considered as non-standard"
Sorry, if misled. Now changed this to "undesirable" or "block with spam". But I've never said that chain is selected only by amount of work in it.

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

Мое предложение скорее из второй категории. Но и с SegWit оно, разумеется, не конфликтует.

Вообще-то, SegWit не решает проблему масштабируемости. Блок в любом случае придется увеличивать, вопрос только когда и насколько...

1й блок - следующий, который будет сгенерирован. Почему майнеры не будут спамить? В первом посте есть разъяснение:

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

Мне тоже интересно услышать, какие имеются аргументы против увеличения до 2МБ?

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

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

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

Конесенсус достигается просто. Майнеры ретранслируют транзакции, ждут 20 секунд, добавляют их в блок. Полные ноды получают блоки, проверяют, что 95% транзакций присутствуют в их мемпуле, и если это не так, то временно отклоняют блок.

Нет. Транзакции должны присутствовать в mempool не менее 15 секунд на момент получения блока. Майнер же обязан был их ретранслировать, как минимум, 20 секунд назад + время пока до нас дошел блок.

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

Минимальный - это единственная coinbase транзакция. На всякий случай, можно устанавливать лимит, как max(1000000, average_size*2).

Actually, node requires to be connected at least with one node that relays all desireable transactions.

They would not be able to temporarily reject undesirable (possibly orphan) block but still can receive, validate and relay it.

They still can use their wallets in blocksonly mode. But what's the point if it doesn't receive transactions?

It's not a problem. Miners could keep and rebroadcast these transactions shortly before including them into the block.

The chain becomes valid anyway, when it receives two or three valid blocks. Also we can simply bypass this rule for some time after the launch. Also we can add a new type of message for the purpose of mempool synchronization between the nodes.

Yes. But it is not a miners' problem. Actually, I doubt whether node even without additional delay can receive full block before small transaction. Furthermore, given that transactions are relayed before.

Malicious miner will generate a lot of orphan blocks before that happens.

Anyway, the worst possible thing that could occur is acceptance the undesirable block consisting of spam. The best chain is selected only when it meets the consensus rules.

In your opinion, node is still full node even if it doesn't relay anything.

Don't want to argue but I wouldn't call them full nodes. Because the system is not designed to operate on such nodes.

I'm not sure that we need it. How does it related to the topic? My proposal does not imply that all existing nodes relay transactions. Similarly, miners does not imply that all existing nodes relay blocks.

They can do. I just don't call them full nodes. They give a little advantage for the network.

Good point. This problem can be solved in different ways.
First of all, nodes aren't required to keep full transactions (TxID will be enough). Also we don't need to keep them forever. I propose that nodes can forget about transactions received over an hour ago. Miners should be careful to include these transactions in block.

This parameter is a consensus rule:
  full nodes should temporarily reject* blocks that consists more than 5% of transactions considered as undesirable (being in the mempool less than 15 seconds | with a fee below 20 satoshies/byte)

This parameter is adjustable by miners and not a consensus rule:
  miners should follow the same rules, but in addition they need to hold transactions at least for 15-20 seconds before including them into the block

What for? My proposal does not imply that all existing nodes will follow the rules. Do we need to enforce that the MAX_BLOCK_BASE_SIZE is no lower or higher than 1MB?

All honest nodes will reject it because the best chain is selected only when it meets the consensus rules.

How will it happen?

Yes. But they couldn't be redeemed until soft-fork is performed and they become considered as standard.
However, I think you're right, we may not limit non-standard transactions. I've removed this part from my proposal to keep things simple.

What's wrong with SPV mining?

How will it happen?

These people aren't running full nodes. They would not be able to temporarily reject undesirable block but still can validate it.
In a good way this node should be considered as misbehaving node unless it reported to all connected nodes that have an intention to evict transactions.

I don't assume that. I've proposed to make them required to keep and relay all transactions.

I don't assume that. Miners can adjust their delay parameter as much as needed.

minTxRelayFee parameter becomes part of the consensus and cannot be higher than 20 satoshies/byte

The chain becomes valid anyway, when it receives two or three valid blocks. Also we can bypass this rule for some time after the launch.

Not invalid, just undesirable.

No. The worst possible thing that could occur is acceptance the undesirable block consisting of spam.

Nothing serious. Besides, nobody will mine on top of invalid (or undesirable) block unless 51% attack is performed...

Why do you think so? What about 1MB block size limit rule?

If node violates some mandatory rule and for example sets minTxRelayFee parameter to 30 sat/byte it should be considered as misbehaving node, unless it reported to all connected nodes that have an intention to evict transactions.

It is enough to always come to consensus. Miners just need to adjust their delay parameter.

My proposal assumes hard fork, so miners/pools/SPV servers will have to update their soft.

No. The worst possible thing that could occur is acceptance the undesirable block consisting of spam.

Ok. You just misunderstood me. I've changed "rejected blocks potentially could be included" to "temporary rejected blocks ..." in my first post.
Actually my solution doesn't solve the 51% attack problem. But of course the best chain is selected only when it meets the consensus rules.

I don't think that full nodes have any significant power. But they can try to continue to reject undesirable blocks more than after 2-3 following blocks.

Obviously, miners as well as other full nodes must relay all standard transactions before including them into the block. Do you think that small transaction can propagate over the network 5 seconds slower than full block does? Not a problem - miners can adjust this delay as much as needed.

Reject invalid block "A", and therefore reject valid block "B". But if afterwards it also receives valid block "C" which builds on block "B", the chain becomes valid. But this situation is possible only in case of 51% attack because honest miners will do their work on block preceding "A".

I suggest to define which transactions should be considered as standard and tighten the protocol rules to make nodes required to relay all these transactions.

As we know, the 1MB limit on the block size was set to counter spam. I want to suggest an alternative solution to this problem.

Let's consider all transactions with a fee below some fixed value (say, 20 satoshis/byte) as spam. In this case, the problem can be solved very easily. Just remove the limit on the block size and prevent miners to include transactions(their own too) with a fee below this value into the block… Actually, let's not prohibit all these transactions, but give some space for them (let it be 5%, tentatively):

• the limit on the block size should be removed^*
• full nodes should temporarily reject^* blocks that consist more than 5% of transactions considered as undesirable (received less than 15 seconds ago | with a fee below 20 satoshis/byte)
• miners should follow the same rules, but in addition, they have to relay and then hold transactions at least for 15-20 seconds before including them into the block
• minTxRelayFee parameter becomes part of the consensus and cannot be higher than 20 satoshis/byte, otherwise, nodes won't be able to check the block for spam

The main idea is that transaction must get into the most nodes mempools and stay there for some time before it can be included in the block. Thus miners are unable to include their own transactions for free and have to broadcast them over the network as all do.

By reserving 5% of space for undesirable transactions we make the condition softer. This is a very large reserve to ensure that nodes always come to consensus. Even if mined block obtained before some transactions that included to it.

* Anyway, the best chain is selected by the amount of work in it. Thus rejected undesirable blocks potentially could be included into the blockchain, but only if most of the miners (>50%) break the rules and accept these blocks with spam. Therefore, during the evaluation of PoW for a chain, nodes and miners shouldn't count these undesirable blocks until they are followed by two or three normal blocks. For the same reason, it makes sense to limit one-time increase of block size in comparison to the average size of the previous several blocks, say not more than twice.

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

Если мы увеличиваем лимит на размер блока, то это уже в любом случае хард-форк. А раз уж мы все-равно изменяем протокол, то можем закрепить и правила формирования mempool как обязательные, и для всех они будут одинаковые. Что касается параметра minRelayTxFee, то логично его поднять до значения 10-20 sat/byte. Все транзакции с меньшей комиссией мы считаем нестандартными и в mempool их включать необязательно. А вот выше 20 sat/byte minRelayTxFee узлам устанавливать нельзя, это да.

Вы не поняли. Нам не нужен полный консенсус по содержимому мемпула. Консенсус нужен только по тому, какие транзакции следует считать стандартными. Полные ноды не должны отбрасывать их, иначе просто не смогут проверить блок на валидность. Такой консенсус уже имеется, и я предлагаю добавить к нему еще два условия:
1) транзакция должна попасть в мемпулы большинства полных нод и пробыть там какое-то время до того, как будет включена в блок;
2) комиссия за транзакцию должна быть не менее 20 sat/byte

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

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

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

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

Давайте попробуем усложнять постепенно.

Забудем на время об идее регулирования комиссии / размера блока рыночным путем. Найдем для начала совсем простое решение - будем считать спамом все транзакции с комиссией ниже некоторой фиксированной величины (допустим, 20 Satoshies/Byte). В таком случае, проблема масштабируемости Биткоина решается предельно просто - снимаем ограничение на размер блока и запрещаем майнерам включать в блоки транзакции с комиссией ниже этой величины, а также бесплатно включать собственные транзакции. Вернее, не совсем запрещаем, а все же оставим немного места (пусть будет 5%) для любых нестандартных транзакций:

Вариант решения №1
- лимит на размер блока отменяется
- полные узлы отклоняют блоки, если в них включено более 5% нестандартных транзакций (использующие нестандатные скрипты | находившихся в очереди mempool менее 15 секунд | с комиссией ниже 20 сат/байт)
- майнеры, в свою очередь, контролируют минимальную комиссию, а также задерживают транзакции в своей очереди, и не пропускают их в блок, как минимум 20 секунд (для надежности) с момента получения
- правила формирования очереди mempool можно не изменять, но, очевидно, что они становятся неотъемлемой частью консенсуса

По сути, это альтернативное решение для проблемы спама, которую, собственно и решает ограничение блока в 1MB. Недостаток его в том, что мы привязываемся к фиксированной величине, номинированной в биткоинах. Если стоимость BTC значительно возрастет, то блокчейн станет менее доступным для рядовых пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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