Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id DB53DC002D for ; 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 ; 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 ; 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 ; Wed, 19 Oct 2022 14:25:02 +0000 (UTC) Received: by mail-ua1-x935.google.com with SMTP id e22so7309235uar.5 for ; 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: In-Reply-To: From: Erik Aronesty Date: Wed, 19 Oct 2022 10:24:48 -0400 Message-ID: To: mm-studios , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
> 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.

reduced settlement speed is a desirable f= eature 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 re= main undisturbed

protocols like mweb, for example




<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 19, 2022 at 7:34 AM mm-stu= dios 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=20 ultimately limits the global settlement throughput to a reduced number=20 of tx/s.

Big-blockers proposed the removal of limits but this=20 didn't come with undesirable effects that have been widely discussed an= d rejected.

The main feature we wanted to preserve is 'small bloc= ks', providing 'better network effects' I won't focus on th= em.

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

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.

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

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 incl= ude transactions until the block is filled, let's call this structure (= coining a new term 'Brick'), B0. [brick=3Dblock that doesn't me= et the difficulty rule and is filled of tx to its full capacity]
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.

= Fully filled brick B0, with a hash that doesn't meet the difficulty rule,=20 would be broadcasted and nodes would have it on in a separate fork as=20 usual.

At this point, instead of discarding transactions, our miner= would start working on a new brick B1, linked with B0 as usual.

Nod= es would allow incoming regular blocks and bricks with hashes that don'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).

Let'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 'minimum hash found', when a series of 'minimum hashes' is= =20 computationally equivalent to the network difficulty is then the full=20 'brickchain' is valid as a Block.

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'd be delighted t= o discover why a scheme like this wouldn't work.

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.

Thank you.
I look f= orward to your responses.

--
Marcos Mayorga
https://twitter.com/KatlasC

=20
=20
=20
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000054f8e805eb63f973--