Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id DCE22C002D for ; Tue, 8 Nov 2022 14:16:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B7974410E8 for ; Tue, 8 Nov 2022 14:16:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B7974410E8 Authentication-Results: smtp4.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=m8dVKt0J 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-OJXha6wYBa for ; Tue, 8 Nov 2022 14:16:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DC51940940 Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) by smtp4.osuosl.org (Postfix) with ESMTPS id DC51940940 for ; Tue, 8 Nov 2022 14:16:53 +0000 (UTC) Received: by mail-ua1-x930.google.com with SMTP id c31so4785944uae.10 for ; Tue, 08 Nov 2022 06:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.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=Vw0Pav+Pob/6P4jSnpHpRxDyhhS5Uz55Xne1kRwnFGk=; b=m8dVKt0J7VJ6aSkGBaD9zD/I9cpdGNfr+Nhbz1MpOkZ9Fsb6cDTDZ1MRY5A61BPWk4 ta45etOrjFEF+bSFe+8ElkVdEmzL9QviorvajjKwPBhhLPa+5+S+u9Jz7mI9vf2n/f5T YNBZCczAkP9icGZPd4YkGrACf3SgYgz4pmt0mBTiva0PzkucRG5svrFQdTWc9juMS0lS XcaAthBe7EW3ARbhbB1g0ZRgrSrmvasyA91RWP8uihs1CuyfcmrYzHcCaK0U4klTQ9TH NvMYTfT9wLxER6ovJwX4B1GKe9ZBVQEFeeJ3wTAbLLCCcaEaO9RoeeLtz4zdl0rXDMe/ w8zA== 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=Vw0Pav+Pob/6P4jSnpHpRxDyhhS5Uz55Xne1kRwnFGk=; b=RkyLOM8I7axZzLxyttmTGUAFWRueY/5v21SFifEfZ3mgTad3uMw/CxF6mYknAV4QRF 92DwAmTjksoMJKCXw5mLZMYSbzA6q3YPtt7TSubyDJCCHW38ogHs+d9D0go6T3mPEoRl qRQHHCfPS2LmjaoYH78Kome5LMEkVC/kSFa7v3DitrB/5L6K3rT2rJIJJRwZsdaKb+WB kozEk15U6eNk3o2nSyUhuM2/IJLZ/pnyFS7/G5vLcS7gXrvqgz46x3l52MYA0OVPhWir yRYOj1vHLA/txPq6fg/KSdcI6PDBplyunnRVTIiwCbv7z7Hn1FiUAC48bP14wYOtk5a+ jA7g== X-Gm-Message-State: ACrzQf0CpgpPCAxobsyc4mt+2cMAVzVADmgdAmbFFTmlcBtbpRxHiriE KBibi/3/lWhp015PR1csTp6P28rUTxJcI1K9BH2qCToDMUfiGgE= X-Google-Smtp-Source: AMsMyM5Tdiz/8Bkc1ux8oJMsvRhN5S6YRjxWShV85nyvKOP2gzD4ABNLdwuhaoF+ONhLX1yhmzr31WmtkBrcqQAH2WU= X-Received: by 2002:ab0:26cd:0:b0:404:3611:fb13 with SMTP id b13-20020ab026cd000000b004043611fb13mr16574364uap.54.1667917012491; Tue, 08 Nov 2022 06:16:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Tue, 8 Nov 2022 09:16:41 -0500 Message-ID: To: mm-studios Content-Type: multipart/alternative; boundary="0000000000000b639905ecf631ab" X-Mailman-Approved-At: Tue, 08 Nov 2022 21:49:46 +0000 Cc: Bitcoin Protocol Discussion 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: Tue, 08 Nov 2022 14:16:55 -0000 --0000000000000b639905ecf631ab Content-Type: text/plain; charset="UTF-8" > A) to not increase the workload of full-nodes yes, this is critical > given the competitive nature of PoW itself validating nodes do not compete with PoW, i think maybe you are not sure of the difference between a miner and a node nodes do validation of transactions, they do this for free, and many of them provide essential services, like SPV validation for mobile B) to not undermine L2 systems like LN. yes, as a general rule, layered financial systems are vastly superior. so that risks incurred by edge layers are not propagated fully to the inner layers. For example L3 projects like TARO and RGB are building on lightning with less risk On Wed, Oct 19, 2022 at 12:04 PM mm-studios 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 > 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 >> > > --0000000000000b639905ecf631ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> A) t= o not increase the workload of full-nodes

yes, this is critical

>=C2=A0 given the competitive nature o= f PoW itself

validating nodes do not compete with PoW, i think maybe you are= not sure of the=C2=A0difference between a miner and a node

nodes do validation of trans= actions, they do this for free, and many of them provide essential services= , like SPV validation for mobile

=C2=A0
B) to not undermine L2 systems like L= N.

yes, as a general rule, layered finan= cial systems are vastly superior.=C2=A0 so that risks incurred by edge laye= rs are not propagated fully to the inner layers.=C2=A0 For example L3 proje= cts like TARO and RGB are building on lightning with less risk
=
= On Wed, Oct 19, 2022 at 12:04 PM mm-studios <mm@mm-studios.com> wrote:
= Thanks all for your responses.
so is it a no-go is because "r= educed settlement speed is a desirable feature"?

I don&#= 39;;t know what weights more in this consideration:
A) to not increase t= he 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 neg= ative centralization effect. (a bit cumbersome reasoning in my opinion, giv= en the competitive nature of PoW itself, which introduce an accepted centra= lization, forcing some miners to give up). In this case the fact is accepte= d because is decentralized enough.
B) to not undermine L2 systems like L= N.

in any case it is a major no-go reason, if there is not intention= to speed up L1.
Thank= s
M
=20
=20
=20
------- 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 transa= ctions 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
<= span style=3D"font-family:Arial;font-size:14px">
the focus should be on layer 2 = protocols that allow the ability to hold & transfer, uncommitted transa= ctions as pools / joins, so that layer 1's decentralization and incenti= ves can remain undisturbed

protocols like mweb, for example




On Wed, Oct 19, 2022 at 7:34= AM mm-studios via bitcoin-dev <bit= coin-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 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 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 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, 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.

Nod= es 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, explain= ed 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 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'd be delighted t= o 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 f= orward to your responses.

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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<= /a>
https://lists.linuxf= oundation.org/mailman/listinfo/bitcoin-dev

--0000000000000b639905ecf631ab--