Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-19 📝 Original message:> currently, a miner ...
📅 Original date posted:2022-10-19
📝 Original message:> 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.
reduced settlement speed is a desirable feature and isn't something we need
to fix
the focus should be on layer 2 protocols that allow the ability to hold &
transfer, uncommitted transactions as pools / joins, so that layer 1's
decentralization and incentives can remain undisturbed
protocols like mweb, for example
On Wed, Oct 19, 2022 at 7:34 AM mm-studios via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 Mayorga
> https://twitter.com/KatlasC
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/8928d1f7/attachment-0001.html>;
📝 Original message:> 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.
reduced settlement speed is a desirable feature and isn't something we need
to fix
the focus should be on layer 2 protocols that allow the ability to hold &
transfer, uncommitted transactions as pools / joins, so that layer 1's
decentralization and incentives can remain undisturbed
protocols like mweb, for example
On Wed, Oct 19, 2022 at 7:34 AM mm-studios via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 Mayorga
> https://twitter.com/KatlasC
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/8928d1f7/attachment-0001.html>;