path: root/9d/57c9d7bd217d98f86ee9c59fcd8c9024087227

Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DB53DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:25:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 916FC40C99
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:25:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 916FC40C99
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
 header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=K2wVqurg
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 81AEDGAELhhL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:25:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 477D84052C
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com
 [IPv6:2607:f8b0:4864:20::935])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 477D84052C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:25:02 +0000 (UTC)
Received: by mail-ua1-x935.google.com with SMTP id e22so7309235uar.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 07:25:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=MPInMqdpEUPtTis6u0C/3VviqA2WQkSP8Iy/rrbc4/4=;
 b=K2wVqurgY6cJupw44GhVVSBf8gD4CzxeN8teBCSpkN8BwXbJFk0MUdBs/cS0mkGC29
 5xKxUzplva6fKfOjRXM4f6wbFuJfCN8WL3cSoCD0MCSFeDfZCZSy0xpaVPzHcdj9HOIx
 /YF+DgMzyjljx2OtkgTJGAKh/V8qOqhJAV3j0WBjHR3TShw80fr5tGtOwnCaMVsTc4Nx
 hjZLj5uISbDOeVykaYASI5CYwvPEm3Tj4rCm13Qy87V4W/dJDl0qWLq+fnkRpo8UfswH
 /ySYWRnFOuCLkZKzjjdBmVeHPtfX7mdhfcnW0Lhg3FUarzIe1yC1Fq9yYQ+sM1jp2KYl
 Hmjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=MPInMqdpEUPtTis6u0C/3VviqA2WQkSP8Iy/rrbc4/4=;
 b=bREMO3auL1tMZWSc2L845HM+v5BJvCP0WgrZu87qb4DKj3klYtyIaNuSiSODKVO9P+
 bJNkdVL3V5P2uUqKvJBjHM0N2X/LcFUwDqwHOh+FK6IevEHIbR93l/gMTspujN82ZpGc
 BaGN/s/FmOLsN3cpNl5VzYt7XCB8aV+hVTPyYnFIOQPm+77JDPlmscPlryg7MDx64eyu
 Y685LklaKEVkAt2yxLWjNoKmzuM3hi3QH6KqQaTHRMdivWPhhzZEOg5PWQyMxthcvuvK
 U/p+ekgEvpXGQyPa2VRYkSSybV/f5vQ1JHChLL13+jV00nJePXqq8jTUA7M1MVoVVkaO
 6GrQ==
X-Gm-Message-State: ACrzQf1sYTRtHVJk1yc6j/MxpFmgCRYLxJvUPE3fCEYb4TdDBnuo1xS7
 02ZMY7X+RuaRlRw6zrEoCw/ZTynnTdcTwA64MvMkVbwLJz/ppls=
X-Google-Smtp-Source: AMsMyM6u3+GdGd0iWEGLe5I9ecWCOjNWEGdv4oDzVH6KIg4VulyDew2Gn92plWTQaEflxAOrElnlksf0+GcRHgb5/Nk=
X-Received: by 2002:ab0:5711:0:b0:3b5:13e0:23b4 with SMTP id
 s17-20020ab05711000000b003b513e023b4mr4236059uaa.101.1666189500936; Wed, 19
 Oct 2022 07:25:00 -0700 (PDT)
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"
X-Mailman-Approved-At: Wed, 19 Oct 2022 14:26:54 +0000
Subject: Re: [bitcoin-dev] brickchain
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2022 14:25:04 -0000

--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--