path: root/71/ee0be011727d5951e2c9e818e21cea9c11db31

Return-Path: <g.andrew.stone@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 80AA5C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 21:34:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 521C54016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 21:34:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 521C54016F
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=XvcM0UNr
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham 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 r1-otufle1nS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 21:34:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8AF874013E
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com
 [IPv6:2607:f8b0:4864:20::22a])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8AF874013E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 21:34:54 +0000 (UTC)
Received: by mail-oi1-x22a.google.com with SMTP id j188so20768853oih.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:34:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=thCNz7enJIOExvueIAUoVnmMKubhiXkaUzPQCD2vi7w=;
 b=XvcM0UNr8Bq/0JyuDh+i4qgFMy8sE9gOWXZhS2sFnJl2S+MNnK9x/s6x8Qv3THNtC5
 FAXTko9mhN39+acgNb5L6TIPKyrIU/iM0eb7i+tUaV1HLIl4vFDnp9w1Kdab3CugiowN
 p170asRN3rcVmA1aiz9tb9rvJcsBIXwXm+o5524ZzHiB5QL6CxRTTKo+qCNfpIv8iIi2
 7rpWFSzW9d1TrSFlnkkOoY5nPD1eFo3yquvnfN1ZEpmtbm1Q7JzYAnWv9U/2DDW3aR/g
 PVCPMUwV4jo2TjxpVB75XbHnbJUqkZ3hEfAX26QqwZS7t1horSpzdxdO/cswiArrpftG
 MO9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc: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=thCNz7enJIOExvueIAUoVnmMKubhiXkaUzPQCD2vi7w=;
 b=7CoR3eWmojRHdPi/D3TfuGRawbZgBPTJH04oNhGNWrZ2dith99Ii635EYUUXTRMEMT
 3Op6ecYlag7m8URY+3y5m2CoGINWLnI8iBM2Kp4KBHJqS2rE6v2IygcAjncKkXlJcKAp
 8u0lVj8mkbWN5lfPe/IIPhJHPLfNCHJNWs8NeVvs/mEZmyFKMoEWURmmiatkaYwz7lYN
 G2JoI4+UcsWpYCjVbNJkwYDNi9y5a3qq8WgkAZgO2+4mzUR6fbgttcmLTVqSSVr+FZBB
 x42nUsjMpg9Z5iydB9XZL4MFQHZM6+gwOBb+aFCKZAA7VyY1G41Vmu7G27+Y4PtwpTNT
 i+bQ==
X-Gm-Message-State: ACrzQf3XmILtKFxrzw3Kn4zKLCtYKXYWm0qiH6fxEz/XQeNJqq0/cWEa
 ElVzwBPShgj1NOgldSA1bzSA9TlvcbmAI6+oBW0=
X-Google-Smtp-Source: AMsMyM6+u2RuF35C5E5gRbeTvRxIqyWwsa4kiUznXyCwL2GdubZrYEPXxDR9CJM82jGjCeHgD6F57oK+l08G35nwWZk=
X-Received: by 2002:aca:bc06:0:b0:354:cf3a:b81a with SMTP id
 m6-20020acabc06000000b00354cf3ab81amr19910071oif.53.1666215293547; Wed, 19
 Oct 2022 14:34:53 -0700 (PDT)
MIME-Version: 1.0
References: <mOBAWIbHTgkSrCJ9IEBJgArqUNYcNSDQawhUzaiYyliaPDQT_YDfI5CLoDPZgEt43mePJof-CJfxzFxgXMUe6ONDJ4j5Bzk1QGjd50S9gb8=@mm-studios.com>
 <CAJowKgKvtRXoLuA0kS5QhAVbhDi0k+3KZqfo+rBr+dbCCS2R5A@mail.gmail.com>
 <lS-eB0uZHRjuHUG6HAyn4_Ponw4ysOCkY_J4cfqBjJ1eOK3PqC0hQ6Ov3XOIofmMC9D_Za3k9Px0OZPa2ayT4dd7wXKEMR910EfrSjlAfQw=@mm-studios.com>
In-Reply-To: <lS-eB0uZHRjuHUG6HAyn4_Ponw4ysOCkY_J4cfqBjJ1eOK3PqC0hQ6Ov3XOIofmMC9D_Za3k9Px0OZPa2ayT4dd7wXKEMR910EfrSjlAfQw=@mm-studios.com>
From: "G. Andrew Stone" <g.andrew.stone@gmail.com>
Date: Wed, 19 Oct 2022 17:34:43 -0400
Message-ID: <CAHUwRvt7706xzOXDEYHYNXiHAfNJ1b8axZ_EDjpPb=_o8ys1AQ@mail.gmail.com>
To: mm-studios <mm@mm-studios.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b0f97605eb69fa43"
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 21:34:58 -0000

--000000000000b0f97605eb69fa43
Content-Type: text/plain; charset="UTF-8"

Consider that a miner can also produce transactions.  So every miner would
produce spam tx to fill their bricks at the minimum allowed difficulty to
reap the brick coinbase reward.

You might quickly respond with a modification that changes or eliminates
the brick coinbase reward, but perhaps that exact reward and the major
negative consequence of miners creating spam tx needs careful thought.

See "bobtail" for a weak block proposal that produces a more consistent
discovery time, and "tailstorm" for a proposal that uses the content of
those weak blocks as commitment to what transactions miners are working on
(which will allow more trustworthy (but still not foolproof) use of
transactions before confirmation)... neither of which have a snowball's
chance in hell (along with any other hard forking change) of being put into
bitcoin :-).

Andrew

On Wed, Oct 19, 2022 at 12:05 PM mm-studios via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thanks all for your responses.
> so is it a no-go is because "reduced settlement speed is a desirable
> feature"?
>
> I don';t know what weights more in this consideration:
> A) to not increase the workload of full-nodes, being "less difficult to
> operate" and hence reduce the chance of some of them giving up which would
> lead to a negative centralization effect. (a bit cumbersome reasoning in my
> opinion, given the competitive nature of PoW itself, which introduce an
> accepted centralization, forcing some miners to give up). In this case the
> fact is accepted because is decentralized enough.
> B) to not undermine L2 systems like LN.
>
> in any case it is a major no-go reason, if there is not intention to speed
> up L1.
> Thanks
> M
> ------- Original Message -------
> On Wednesday, October 19th, 2022 at 3:24 PM, Erik Aronesty <erik@q32.com>
> wrote:
>
> > 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div><br></div><div dir=3D"ltr"><div>Consider that a miner=
 can also produce transactions.=C2=A0 So every miner would produce spam tx =
to fill their bricks at the minimum allowed difficulty to reap the brick co=
inbase reward.=C2=A0 <br></div><div><br></div><div>You might quickly respon=
d with a modification that changes or eliminates the brick coinbase reward,=
 but perhaps that exact reward and the major negative consequence of miners=
 creating spam tx needs careful thought.=C2=A0 <br></div><div><br></div><di=
v>See &quot;bobtail&quot; for a weak block proposal that produces a more co=
nsistent discovery time, and &quot;tailstorm&quot; for a proposal that uses=
 the content of those weak blocks as commitment to what transactions miners=
 are working on (which will allow more trustworthy (but still not foolproof=
) use of transactions before confirmation)... neither of which have a snowb=
all&#39;s chance in hell (along with any other hard forking change) of bein=
g put into bitcoin :-).</div><div><br></div><div>Andrew<br></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oc=
t 19, 2022 at 12:05 PM mm-studios via bitcoin-dev &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv style=3D"font-family:Arial;font-size:14px">Thanks all for your responses=
.<br>so is it a no-go is because &quot;r<span>educed settlement speed is a =
desirable feature</span>&quot;?<br><br>I don&#39;;t know what weights more =
in this consideration:<br>A) to not increase the workload of full-nodes, be=
ing &quot;less difficult to operate&quot; and hence reduce the chance of so=
me of them giving up which would lead to a negative centralization effect. =
(a bit cumbersome reasoning in my opinion, given the competitive nature of =
PoW itself, which introduce an accepted centralization, forcing some miners=
 to give up). In this case the fact is accepted because is decentralized en=
ough.<br>B) to not undermine L2 systems like LN.<br><br>in any case it is a=
 major no-go reason, if there is not intention to speed up L1.</div><div st=
yle=3D"font-family:Arial;font-size:14px">Thanks<br>M<br></div><div style=3D=
"font-family:Arial;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
       =20
            </div>
</div>
<div>
        ------- Original Message -------<br>
        On Wednesday, October 19th, 2022 at 3:24 PM, Erik Aronesty &lt;<a h=
ref=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:<b=
r><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><span style=3D"font-family:Arial;font-size:14p=
x">&gt; currently, a miner produce blocks with a limited capacity of transa=
ctions that ultimately limits the global settlement throughput to a reduced=
 number of tx/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><spa=
n style=3D"font-family:Arial;font-size:14px">reduced settlement speed is a =
desirable feature 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 transa=
ctions as pools / joins, so that layer 1&#39;s decentralization and incenti=
ves can remain undisturbed</span></div><div><span style=3D"font-family:Aria=
l;font-size:14px"><br></span></div><div><span style=3D"font-family:Arial;fo=
nt-size:14px">protocols like mweb, for example</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"><br></span></div><div><span style=3D"font=
-family:Arial;font-size:14px"><br></span></div></div><br><div class=3D"gmai=
l_quote"><div class=3D"gmail_attr" dir=3D"ltr">On Wed, Oct 19, 2022 at 7:34=
 AM mm-studios via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" rel=3D"noreferrer nofollow noopener" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex" class=3D"gmail_quote"><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
ultimately limits the global settlement throughput to a reduced number
of tx/s.<br><br>Big-blockers proposed the removal of limits but this
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
in the PoW algorithm.</div><div><br></div><div>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.<br></div><div><br>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).<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,
would be broadcasted and nodes would have it on in a separate fork as
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
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, explain=
ed below).<br><br>Let&#39;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
&#39;minimum hash found&#39;, when a series of &#39;minimum hashes&#39; is
computationally equivalent to the network difficulty is then the full
&#39;brickchain&#39; is valid as a Block.<br><br>This calculus shall be bet=
ter
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&#39;d be delighted t=
o
 discover why a scheme like this wouldn&#39;t work.<br><br>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.<br><br>Thank you.<br>I look f=
orward to your responses.<br><br>--<br>Marcos Mayorga<br></div><span><a hre=
f=3D"https://twitter.com/KatlasC" rel=3D"noreferrer nofollow noopener" targ=
et=3D"_blank">https://twitter.com/KatlasC</a></span><br><br></div>
<div style=3D"font-family:Arial;font-size:14px">
    <div>

            </div>

            <div>

            </div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
nofollow noopener" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a><br>
<a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

        </blockquote><br>
    </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></div>

--000000000000b0f97605eb69fa43--