Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 21DECC0032 for ; Sat, 19 Aug 2023 18:58:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id F0D8780BE4 for ; Sat, 19 Aug 2023 18:58:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F0D8780BE4 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=breen.xyz header.i=@breen.xyz header.a=rsa-sha256 header.s=sig1 header.b=SGcs0BPD X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 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, FROM_SUSPICIOUS_NTLD=0.499, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqBULcO3ih3f for ; Sat, 19 Aug 2023 18:58:30 +0000 (UTC) Received: from st43p00im-ztbu10063601.me.com (st43p00im-ztbu10063601.me.com [17.58.63.174]) by smtp1.osuosl.org (Postfix) with ESMTPS id CFE6081EF1 for ; Sat, 19 Aug 2023 18:58:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CFE6081EF1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=breen.xyz; s=sig1; t=1692471508; bh=UMz/uYWcXo9hHZMcRsWqJSlDA4r5PJDxFVOrZz7mVKU=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=SGcs0BPDxenI72kx2OjC0SoVvldSNGQBl/9R913jfxJ1304B/y713Ni2xwh5QzY3M 9S2uaO4BLZ29Vp/gpc9gYBpTzsrW0KHKbA3KDT8XcMcJdb6biArUsdhCE3eaHOz+ZT yiWEv+paO1AgctAbWPAClYoOpg9hTA1401JkVnuUuQzrGRTycDuvNYROa/yuEcOmgN uwX2zMSZQqo+G7HWPVo0UTJDctum7CmEyysqHuovVRk6a7io86FLfDajgGgApPrk8d sa+aFH0BCaGkf1kn6nlhr4cbYnvD6LButYXig5nzQzLM+T3EJCIrTYXe2DBSPEBzON cdbLbOCfbBv+A== Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com [17.42.251.41]) by st43p00im-ztbu10063601.me.com (Postfix) with ESMTPSA id 75C508C01A1; Sat, 19 Aug 2023 18:58:26 +0000 (UTC) From: ryan@breen.xyz Message-Id: <2BFA7EE8-2E0E-45A3-AC11-8E57F99EC775@breen.xyz> Content-Type: multipart/alternative; boundary="Apple-Mail=_DDEFEF4B-4917-4102-9B0E-203650F3A744" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Date: Sat, 19 Aug 2023 14:58:15 -0400 In-Reply-To: To: Ruben Somsen References: X-Mailer: Apple Mail (2.3731.700.6) X-Proofpoint-ORIG-GUID: gTaK1JYy2A0-1-klAlmcRusdlntXFLU4 X-Proofpoint-GUID: gTaK1JYy2A0-1-klAlmcRusdlntXFLU4 X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.591,18.0.572,17.11.176.26.0000000_definitions?= =?UTF-8?Q?=3D2023-07-31=5F02:2023-07-31=5F02,2020-02-14=5F11,2023-05-22?= =?UTF-8?Q?=5F02_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 clxscore=1030 suspectscore=0 mlxscore=0 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2308190183 X-Mailman-Approved-At: Mon, 21 Aug 2023 00:12:25 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg 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: Sat, 19 Aug 2023 18:58:32 -0000 --Apple-Mail=_DDEFEF4B-4917-4102-9B0E-203650F3A744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for the feedback, Ruben. I have a question. Could you please clarify what qualifies as a fraud proof in this = concept? As I envision it, there is no cryptographic proof involved at = all. In the context of a Sentinel chain, the sidechain's full nodes monitor = Bitcoin mempools and blocks for withdrawals that violate the rules of = the sidechain's consensus (such as thefts or incorrect balances). When = the sidechain's full nodes detect an invalid withdrawal on Bitcoin, they = publish a signed attestation to a public broadcast network (Nostr in = this case). Participating Bitcoin full nodes and miners monitor the = network for these attestations and subsequently reject the offending = transactions. The process doesn't involve the presentation of proof = because it's a distributed trust relationship. While Bitcoin full nodes could decide to operate their own sidechain = nodes, we aim not to make this a requirement (addressing the = long-standing sidechain dilemma). Bitcoin full nodes and miners wishing = to participate can instead choose a distributed trust network comprising = operators of sidechain full nodes that they trust. For instance, if they = decide to follow 100 well-respected sidechain node operators, they might = collectively agree that if 75 of them issue an attestation indicating = that a transaction violates sidechain withdrawal rules, then that = transaction should be deemed invalid by their node. Withdrawals are = assumed valid if no public attestations are present. Furthermore, I'm uncertain about what potential data availability issue = that might arise from this. Since there are no alterations to Bitcoin = Core's validation logic, when a full node operator starts a new node = from the genesis block, they will validate the proof of work of the = longest chain and remain blissfully unaware that the transactions within = the blocks are even associated with a sidechain. > On Aug 19, 2023, at 10:35 AM, Ruben Somsen wrote: >=20 > Hi Ryan, >=20 > Thanks for taking the time to write a proposal. As is often the case, = these ideas aren't actually as novel as you might think. What you = describe here is known as "fraud proofs". The crucial problem it doesn't = address is "data availability". >=20 > The general idea behind fraud proofs is that if you commit to every = computational step (note Bitcoin currently doesn't, but could), anyone = can succinctly reveal erroneous steps (e.g. 1+1=3D3), thus convincing = everyone the state transition (i.e. block) is invalid. This works if a = bunch of people have all the data and are willing to construct and = spread the fraud proofs, but what if nobody has the data? >=20 > When someone claims data is unavailable, the only way to verify this = claim is by downloading the data. You can't just ban this peer for false = claims either, since the data might have actually been unavailable when = the claim was made but then became available. In essence this means = malicious peers can cause you to download all data, meaning you = effectively haven't saved any bandwidth. >=20 > It should be noted that fraud proofs could still reduce the need for = computation (i.e. you download all data, but only verify the parts for = which you receive fraud notifications), so it can still provide some = form of scaling. >=20 > As a bit of history, fraud proofs were actually briefly considered for = inclusion into segwit, but were abandoned due to the data availability = issue: = https://bitcoincore.org/en/2016/01/26/segwit-benefits/#update-2016-10-19 >=20 > And finally, there is a way to address the data availability issue, = which I describe here (PoW fraud proofs/softchains, though note I am = currently of the opinion it's better used for low-bandwidth mainchain = nodes instead of for sidechains): = https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1 >=20 > In theory you can also do data availability sampling through the use = of erasure codes, but that gets very complex and brittle. >=20 > Hope this helps. >=20 > Cheers, > Ruben >=20 > On Sat, Aug 19, 2023 at 4:29=E2=80=AFPM Ryan Breen via bitcoin-dev = > wrote: >> Recent discussions on social media regarding drivechains have = prompted me to consider the implementation of a two-way sidechain peg = within the Bitcoin protocol. I would like to propose what I believe may = be a novel solution to this issue. >>=20 >> I have previously written about here on my blog: = https://ursus.camp/bitcoin/2023/08/10/sidechains.html >> And here is the Stacker News discussion: = https://stacker.news/items/222480 >>=20 >> Nevertheless, I will hit the high points of the concept here: >>=20 >> The most challenging problem that BIP-300 aims to address is how to = establish a two-way peg without involving a multisig federation and = without requiring miners and full nodes to possess knowledge about the = sidechain or run a sidechain node. This is, in fact, a very difficult = nut to crack. >>=20 >> The method adopted by BIP-300 involves conducting sidechain = withdrawals directly through the miners. To prevent miners from engaging = in theft, the proposal mandates a three-month period for peg-outs, = during which all miners vote on the peg-out. The intention here is to = allow the community to respond in the event of an incorrect peg-out or = theft. The miners are expected to be responsive to community pressure = and make the correct decisions. To streamline this process of social = consensus, withdrawals are grouped into one large bundle per three month = period. >>=20 >> Despite criticisms of this proposal, I find it to be a viable and = likely effective solution. After all, Bitcoin's underlying mechanism is = fundamentally rooted in social consensus, with the only question being = the extent of automation. Nonetheless, I believe we now possess tools = that can improve this process, leading to the concept of Sentinel = chains. >>=20 >> The core idea is that sidechain nodes function as Sentinels, = notifying full nodes of thefts via a secondary network. These sidechain = nodes monitor the current state of Bitcoin blocks and mempool = transactions, actively searching for peg-outs that contravene sidechain = consensus in order to steal funds. They transmit invalid transactions or = blocks to public Nostr servers. Bitcoin full nodes wishing to partake in = sidechain consensus can run a small daemon alongside Bitcoin Core. This = daemon can monitor public Nostr nodes for messages about invalid = transactions and then instruct Bitcoin Core, via RPC calls, to ignore = and not forward those invalid transactions. >>=20 >> Full nodes can choose any group of individuals or organizations to = receive updates from Nostr. For instance, a full node might choose to = trust a collective of 100 sidechain nodes consisting of a mix of = prominent companies and individuals in the sidechain's sphere. Rather = than relying on a single trusted group, full nodes form their own = decentralized web of trust. >>=20 >> This reverses the conventional model of two-way pegged sidechains. = Instead of requiring nodes to monitor sidechains, sidechains now monitor = nodes. In this sense, it is akin to drivechains, with the difference = being that peg-outs could be instantaneous and individual, without the = need for the three-month gradual social consensus. Furthermore, a single = daemon can be configured to monitor notifications from any number of = Sentinel chains, rendering this solution highly scalable for numerous = sidechains. >>=20 >> In summary, drivechains: >>=20 >> - Require an initial consensus soft fork >> - Treat each new sidechain as a miner-activated soft fork (easier to = deploy but more centralized) >> - Feature withdrawals occurring in three-month periods >> - Involve withdrawals in bundles >> - Exclude Bitcoin full nodes from participation in sidechain = consensus >> - Are currently production-ready >>=20 >> Sentinel chains: >>=20 >> - Require no initial soft fork of any kind >> - Permit each new sidechain to be miner-activated OR user-activated = (more challenging to deploy but more decentralized) >> - Allow instantaneous withdrawals >> - Facilitate individual withdrawals >> - Enable Bitcoin full nodes to engage in consensus >> - Are only at the concept stage >>=20 >> Sentinel chains could potentially offer substantial advantages over = other forms of two-way pegs, primarily in terms of speed and efficiency = of consensus. Moreover, they align more closely with Bitcoin's = principles by ensuring that power remains within the realm of full = nodes. Lastly, they shield Core-only users from potential bug = consequences stemming from consensus changes directly implemented in = Bitcoin Core, possibly fulfilling the long-awaited promise of a fully = opt-in soft fork. >>=20 >>=20 >> Ryan Breen >> Twitter: ursuscamp >> Email: ryan @ breen.xyz >> Web: https://ursus.camp >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org = >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_DDEFEF4B-4917-4102-9B0E-203650F3A744 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thank you for the feedback, Ruben. I have = a question.

Could you please clarify what = qualifies as a fraud proof in this concept? As I envision it, there is = no cryptographic proof involved at all.

In the = context of a Sentinel chain, the sidechain's full nodes monitor Bitcoin = mempools and blocks for withdrawals that violate the rules of the = sidechain's consensus (such as thefts or incorrect balances). When the = sidechain's full nodes detect an invalid withdrawal on Bitcoin, they = publish a signed attestation to a public broadcast network (Nostr in = this case). Participating Bitcoin full nodes and miners monitor the = network for these attestations and subsequently reject the offending = transactions. The process doesn't involve the presentation of proof = because it's a distributed trust = relationship.

While Bitcoin full nodes could = decide to operate their own sidechain nodes, we aim not to make this a = requirement (addressing the long-standing sidechain dilemma). Bitcoin = full nodes and miners wishing to participate can instead choose a = distributed trust network comprising operators of sidechain full nodes = that they trust. For instance, if they decide to follow 100 = well-respected sidechain node operators, they might collectively agree = that if 75 of them issue an attestation indicating that a transaction = violates sidechain withdrawal rules, then that transaction should be = deemed invalid by their node. Withdrawals are assumed valid if no public = attestations are present.

Furthermore, I'm = uncertain about what potential data availability issue that might arise = from this. Since there are no alterations to Bitcoin Core's validation = logic, when a full node operator starts a new node from the genesis = block, they will validate the proof of work of the longest chain and = remain blissfully unaware that the transactions within the blocks are = even associated with a sidechain.

On Aug 19, 2023, at 10:35 AM, Ruben Somsen = <rsomsen@gmail.com> wrote:

Hi = Ryan,

Thanks for taking the time to write a proposal. As is often = the case, these ideas aren't actually as novel as you might think. What = you describe here is known as "fraud proofs". The crucial problem it = doesn't address is "data availability".

The general idea behind = fraud proofs is that if you commit to every computational step (note = Bitcoin currently doesn't, but could), anyone can succinctly reveal = erroneous steps (e.g. 1+1=3D3), thus convincing everyone the state = transition (i.e. block) is invalid. This works if a bunch of people have = all the data and are willing to construct and spread the fraud proofs, = but what if nobody has the data?

When someone claims data is = unavailable, the only way to verify this claim is by downloading the = data. You can't just ban this peer for false claims either, since the = data might have actually been unavailable when the claim was made but = then became available. In essence this means malicious peers can cause = you to download all data, meaning you effectively haven't saved any = bandwidth.

It should be noted that fraud proofs could still = reduce the need for computation (i.e. you download all data, but only = verify the parts for which you receive fraud notifications), so it can = still provide some form of scaling.

As a bit of history, fraud = proofs were actually briefly considered for inclusion into segwit, but = were abandoned due to the data availability issue: https://bitcoincore.org/en/2016/01/26/segwit-benefits/#update-2016= -10-19

And finally, there is a way to address the data = availability issue, which I describe here (PoW fraud proofs/softchains, = though note I am currently of the opinion it's better used for = low-bandwidth mainchain nodes instead of for sidechains): https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1

In theory you can also do data availability sampling through = the use of erasure codes, but that gets very complex and = brittle.

Hope this = helps.

Cheers,
Ruben

On Sat, Aug = 19, 2023 at 4:29=E2=80=AFPM Ryan Breen via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
Recent discussions on social = media regarding drivechains have prompted me to consider the = implementation of a two-way sidechain peg within the Bitcoin protocol. I = would like to propose what I believe may be a novel solution to this = issue.

I have previously written about here on my blog: https://ursus.camp/bitcoin/2023/08/10/sidechains.html
And here is the Stacker News discussion: https://stacker.news/items/222480

Nevertheless, I will hit the high points of the concept here:

The most challenging problem that BIP-300 aims to address is how to = establish a two-way peg without involving a multisig federation and = without requiring miners and full nodes to possess knowledge about the = sidechain or run a sidechain node. This is, in fact, a very difficult = nut to crack.

The method adopted by BIP-300 involves conducting sidechain withdrawals = directly through the miners. To prevent miners from engaging in theft, = the proposal mandates a three-month period for peg-outs, during which = all miners vote on the peg-out. The intention here is to allow the = community to respond in the event of an incorrect peg-out or theft. The = miners are expected to be responsive to community pressure and make the = correct decisions. To streamline this process of social consensus, = withdrawals are grouped into one large bundle per three month = period.

Despite criticisms of this proposal, I find it to be a viable and likely = effective solution. After all, Bitcoin's underlying mechanism is = fundamentally rooted in social consensus, with the only question being = the extent of automation. Nonetheless, I believe we now possess tools = that can improve this process, leading to the concept of Sentinel = chains.

The core idea is that sidechain nodes function as Sentinels, notifying = full nodes of thefts via a secondary network. These sidechain nodes = monitor the current state of Bitcoin blocks and mempool transactions, = actively searching for peg-outs that contravene sidechain consensus in = order to steal funds. They transmit invalid transactions or blocks to = public Nostr servers. Bitcoin full nodes wishing to partake in sidechain = consensus can run a small daemon alongside Bitcoin Core. This daemon can = monitor public Nostr nodes for messages about invalid transactions and = then instruct Bitcoin Core, via RPC calls, to ignore and not forward = those invalid transactions.

Full nodes can choose any group of individuals or organizations to = receive updates from Nostr. For instance, a full node might choose to = trust a collective of 100 sidechain nodes consisting of a mix of = prominent companies and individuals in the sidechain's sphere. Rather = than relying on a single trusted group, full nodes form their own = decentralized web of trust.

This reverses the conventional model of two-way pegged sidechains. = Instead of requiring nodes to monitor sidechains, sidechains now monitor = nodes. In this sense, it is akin to drivechains, with the difference = being that peg-outs could be instantaneous and individual, without the = need for the three-month gradual social consensus. Furthermore, a single = daemon can be configured to monitor notifications from any number of = Sentinel chains, rendering this solution highly scalable for numerous = sidechains.

In summary, drivechains:

- Require an initial consensus soft fork
- Treat each new sidechain as a miner-activated soft fork (easier to = deploy but more centralized)
- Feature withdrawals occurring in three-month periods
- Involve withdrawals in bundles
- Exclude Bitcoin full nodes from participation in sidechain = consensus
- Are currently production-ready

Sentinel chains:

- Require no initial soft fork of any kind
- Permit each new sidechain to be miner-activated OR user-activated = (more challenging to deploy but more decentralized)
- Allow instantaneous withdrawals
- Facilitate individual withdrawals
- Enable Bitcoin full nodes to engage in consensus
- Are only at the concept stage

Sentinel chains could potentially offer substantial advantages over = other forms of two-way pegs, primarily in terms of speed and efficiency = of consensus. Moreover, they align more closely with Bitcoin's = principles by ensuring that power remains within the realm of full = nodes. Lastly, they shield Core-only users from potential bug = consequences stemming from consensus changes directly implemented in = Bitcoin Core, possibly fulfilling the long-awaited promise of a fully = opt-in soft fork.


Ryan Breen
Twitter: ursuscamp
Email: ryan @ breen.xyz
Web: https://ursus.camp
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitco= in-dev

= --Apple-Mail=_DDEFEF4B-4917-4102-9B0E-203650F3A744--