mm-studios [ARCHIVE] on Nostr: š Original date posted:2022-10-19 š Original message:Hi Bitcoin devs, I'd like ...
š
Original date posted:2022-10-19
š Original message:Hi Bitcoin devs,
I'd like to share an idea of a method to increase throughput in the bitcoin network.
Currently, a miner produce blocks with a limited capacity of transactions that ultimately limits the global settlement throughput to a reduced number of tx/s.
Big-blockers proposed the removal of limits but this didn't come with undesirable effects that have been widely discussed and rejected.
The main feature we wanted to preserve is 'small blocks', providing 'better network effects' I won't focus on them.
The problem with small blocks is that, once a block is filled transactions, they are kept back in the mempool, waiting for their turn in future blocks.
The following changes in the protocol aim to let all transactions go in the current block, while keeping the block size small. It requires changes in the PoW algorithm.
Currently, the PoW algorithm consists on finding a valid hash for the block. Its validity is determined by comparing the numeric value of the block hash with a protocol-defined value difficulty.
Once a miner finds a nonce for the block that satisfies the condition the new block becomes valid and can be propagated. All nodes would update their blockchains with it. (assuming no conflict resolution (orphan blocks, ...) for clarity).
This process is meant to happen every 10 minutes in average.
With this background information (we all already know) I go on to describe the idea:
Let's allow a miner to include transactions until the block is filled, let's call this structure (coining a new term 'Brick'), B0. [brick=block that doesn't meet the difficulty rule and is filled of tx to its full capacity]
Since PoW hashing is continuously active, Brick B0 would have a nonce corresponding to a minimum numeric value of its hash found until it got filled.
Fully filled brick B0, with a hash that doesn't meet the difficulty rule, would be broadcasted and nodes would have it on in a separate fork as usual.
At this point, instead of discarding transactions, our miner would start working on a new brick B1, linked with B0 as usual.
Nodes would allow incoming regular blocks and bricks with hashes that don't satisfy the difficulty rule, provided the brick is fully filled of transactions. Bricks not fully filled would be rejected as invalid to prevent spam (except if constitutes the last brick of a brickchain, explained below).
Let's assume that 10 minutes have elapsed and our miner is in a state where N bricks have been produced and the accumulated PoW calculated using mathematics (every brick contains a 'minimum hash found', when a series of 'minimum hashes' is computationally equivalent to the network difficulty is then the full 'brickchain' is valid as a Block.
This calculus shall be better defined, but I hope that this idea can serve as a seed to a BIP, or otherwise deemed absurd, which might be possible and I'd be delighted to discover why a scheme like this wouldn't work.
If it finally worked, it could completely flush mempools, keep transactions fees low and increase throughput without an increase in the block size that would raise other concerns related to propagation.
Thank you.
I look forward to your responses.
--
Marcos Mayorgahttps://twitter.com/KatlasC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/928d0cde/attachment-0001.html>;
š Original message:Hi Bitcoin devs,
I'd like to share an idea of a method to increase throughput in the bitcoin network.
Currently, a miner produce blocks with a limited capacity of transactions that ultimately limits the global settlement throughput to a reduced number of tx/s.
Big-blockers proposed the removal of limits but this didn't come with undesirable effects that have been widely discussed and rejected.
The main feature we wanted to preserve is 'small blocks', providing 'better network effects' I won't focus on them.
The problem with small blocks is that, once a block is filled transactions, they are kept back in the mempool, waiting for their turn in future blocks.
The following changes in the protocol aim to let all transactions go in the current block, while keeping the block size small. It requires changes in the PoW algorithm.
Currently, the PoW algorithm consists on finding a valid hash for the block. Its validity is determined by comparing the numeric value of the block hash with a protocol-defined value difficulty.
Once a miner finds a nonce for the block that satisfies the condition the new block becomes valid and can be propagated. All nodes would update their blockchains with it. (assuming no conflict resolution (orphan blocks, ...) for clarity).
This process is meant to happen every 10 minutes in average.
With this background information (we all already know) I go on to describe the idea:
Let's allow a miner to include transactions until the block is filled, let's call this structure (coining a new term 'Brick'), B0. [brick=block that doesn't meet the difficulty rule and is filled of tx to its full capacity]
Since PoW hashing is continuously active, Brick B0 would have a nonce corresponding to a minimum numeric value of its hash found until it got filled.
Fully filled brick B0, with a hash that doesn't meet the difficulty rule, would be broadcasted and nodes would have it on in a separate fork as usual.
At this point, instead of discarding transactions, our miner would start working on a new brick B1, linked with B0 as usual.
Nodes would allow incoming regular blocks and bricks with hashes that don't satisfy the difficulty rule, provided the brick is fully filled of transactions. Bricks not fully filled would be rejected as invalid to prevent spam (except if constitutes the last brick of a brickchain, explained below).
Let's assume that 10 minutes have elapsed and our miner is in a state where N bricks have been produced and the accumulated PoW calculated using mathematics (every brick contains a 'minimum hash found', when a series of 'minimum hashes' is computationally equivalent to the network difficulty is then the full 'brickchain' is valid as a Block.
This calculus shall be better defined, but I hope that this idea can serve as a seed to a BIP, or otherwise deemed absurd, which might be possible and I'd be delighted to discover why a scheme like this wouldn't work.
If it finally worked, it could completely flush mempools, keep transactions fees low and increase throughput without an increase in the block size that would raise other concerns related to propagation.
Thank you.
I look forward to your responses.
--
Marcos Mayorgahttps://twitter.com/KatlasC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/928d0cde/attachment-0001.html>;