MIME-Version: 1.0
References: <mOBAWIbHTgkSrCJ9IEBJgArqUNYcNSDQawhUzaiYyliaPDQT_YDfI5CLoDPZgEt43mePJof-CJfxzFxgXMUe6ONDJ4j5Bzk1QGjd50S9gb8=@mm-studios.com>
In-Reply-To: <mOBAWIbHTgkSrCJ9IEBJgArqUNYcNSDQawhUzaiYyliaPDQT_YDfI5CLoDPZgEt43mePJof-CJfxzFxgXMUe6ONDJ4j5Bzk1QGjd50S9gb8=@mm-studios.com>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 19 Oct 2022 10:24:48 -0400
Message-ID: <CAJowKgKvtRXoLuA0kS5QhAVbhDi0k+3KZqfo+rBr+dbCCS2R5A@mail.gmail.com>
To: mm-studios <mm@mm-studios.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000054f8e805eb63f973"
Subject: Re: [bitcoin-dev] brickchain
Precedence: list

--00000000000054f8e805eb63f973
Content-Type: text/plain; charset="UTF-8"

> 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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000054f8e805eb63f973
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-family:Arial;font-size:14px">&gt; curr=
ently, a miner produce blocks with a limited capacity of transactions that =
ultimately limits the global settlement throughput to a reduced number of t=
x/s.</span><br style=3D"font-family:Arial;font-size:14px"><div><span style=
=3D"font-family:Arial;font-size:14px"><br></span></div><div><span style=3D"=
font-family:Arial;font-size:14px">reduced settlement speed is a desirable f=
eature and isn&#39;t something we need to fix</span></div><div><span style=
=3D"font-family:Arial;font-size:14px"><br></span></div><div><span style=3D"=
font-family:Arial;font-size:14px">the focus should be on layer 2 protocols =
that allow the ability to hold &amp; transfer, uncommitted transactions as =
pools / joins, so that layer 1&#39;s decentralization and incentives can re=
main undisturbed</span></div><div><span style=3D"font-family:Arial;font-siz=
e:14px"><br></span></div><div><span style=3D"font-family:Arial;font-size:14=
px">protocols like mweb, for example</span></div><div><span style=3D"font-f=
amily:Arial;font-size:14px"><br></span></div><div><span style=3D"font-famil=
y:Arial;font-size:14px"><br></span></div><div><span style=3D"font-family:Ar=
ial;font-size:14px"><br></span></div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 19, 2022 at 7:34 AM mm-stu=
dios via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial=
;font-size:14px"><span>Hi Bitcoin devs,</span><div>I&#39;d like to share an=
 idea of a method to increase throughput in the bitcoin network.</div><div>=
<br></div><div>Currently,
 a miner produce blocks with a limited capacity of transactions that=20
ultimately limits the global settlement throughput to a reduced number=20
of tx/s.<br><br>Big-blockers proposed the removal of limits but this=20
didn&#39;t come with undesirable effects that have been widely discussed an=
d
 rejected.<br><br>The main feature we wanted to preserve is &#39;small bloc=
ks&#39;, providing &#39;better network effects&#39; I won&#39;t focus on th=
em.</div><div><br></div><div>The
 problem with small blocks is that, once a block is filled transactions, th=
ey
are kept back in the mempool, waiting for their turn in future blocks.<br><=
br>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=20
in the PoW algorithm.</div><div><br></div><div>Currently,
 the PoW algorithm consists on finding a valid hash for the block. Its=20
validity is determined by comparing the numeric value of the block hash=20
with a protocol-defined value difficulty.<br></div><div><br>Once
 a miner finds a nonce for the block that satisfies the condition the new=
=20
block becomes valid and can be propagated. All nodes would update=20
their blockchains with it. (assuming no conflict resolution (orphan=20
blocks, ...) for clarity).<br><br>This process is meant to happen every 10 =
minutes in average.<br><br>With this background information (we all already=
 know) I go on to describe the idea:<br><br>Let&#39;s allow a miner to incl=
ude transactions until the block is filled, let&#39;s call this structure (=
coining a new term &#39;Brick&#39;), B0. [brick=3Dblock that doesn&#39;t me=
et the difficulty rule and is filled of tx to its full capacity]<br>Since P=
oW hashing is continuously active, Brick B0 would have a nonce correspondin=
g to a minimum numeric value of its hash found until it got filled.<br><br>=
Fully
 filled brick B0, with a hash that doesn&#39;t meet the difficulty rule,=20
would be broadcasted and nodes would have it on in a separate fork as=20
usual.<br><br> At this point, instead of discarding transactions, our miner=
 would start working on a new brick B1, linked with B0 as usual.<br><br>Nod=
es
 would allow incoming regular blocks and bricks with hashes that don&#39;t=
=20
satisfy the difficulty rule, provided the brick is fully filled of=20
transactions. Bricks not fully filled would be rejected as invalid to=20
prevent spam (except if constitutes the last brick of a brickchain, explain=
ed below).<br><br>Let&#39;s assume that 10 minutes have elapsed and our=20
miner is in a state where N bricks have been produced and the=20
accumulated PoW calculated using mathematics (every brick contains a=20
&#39;minimum hash found&#39;, when a series of &#39;minimum hashes&#39; is=
=20
computationally equivalent to the network difficulty is then the full=20
&#39;brickchain&#39; is valid as a Block.<br><br>This calculus shall be bet=
ter=20
defined, but I hope that this idea can serve as a seed to a BIP, or=20
otherwise deemed absurd, which might be possible and I&#39;d be delighted t=
o
 discover why a scheme like this wouldn&#39;t work.<br><br>If it finally=20
worked, it could completely flush mempools, keep transactions fees low=20
and increase throughput without an increase in the block size that would
 raise other concerns related to propagation.<br><br>Thank you.<br>I look f=
orward to your responses.<br><br>--<br>Marcos Mayorga<br></div><span><a rel=
=3D"noreferrer nofollow noopener" href=3D"https://twitter.com/KatlasC" targ=
et=3D"_blank">https://twitter.com/KatlasC</a></span><br><br></div>
<div style=3D"font-family:Arial;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
       =20
            </div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000054f8e805eb63f973--