{"type":"rich","version":"1.0","author_name":"npub1cnrnujx86le38yu2jrt3la0yhewsrh2p2lucakv6mu28x7lm0rsq9qyeq0","author_url":"https://nostr.ae/npub1cnrnujx86le38yu2jrt3la0yhewsrh2p2lucakv6mu28x7lm0rsq9qyeq0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-08-21\n🗒️ Summary of this message: Ryan envisions a system where there is no cryptographic proof involved in validating transactions, which contradicts the idea of fraud proof. This reliance on trusted entities and the ability to choose different sets of validators could lead to consensus failures. Ruben raises concerns about data availability and the potential issues it may cause.\n📝 Original message:\nHi Ryan,\n\n\u003eAs I envision it, there is no cryptographic proof involved at all.\n\nThat seems to directly contradict your previous message where you stated\n\"[t]hey transmit invalid transactions or blocks\". This transmission you\nalluded to is basically a (non-optimized) fraud proof, and it assumes that\nthis data is actually available (unsafe assumption).\n\nIf you envision that this step is not actually needed, then users are\nessentially never validating and merely relying on a set of trusted\nentities. Furthermore, the idea that everyone can just pick their own set\nof validators is antithetical to consensus. What if my set of validators\ndisagrees with your set of validators? Now one of us will reject the\nBitcoin block with the peg-out while the other will not, causing sidechain\nconsensus failure to directly affect the mainchain.\n\nCheers,\nRuben\n\n\n\nOn Sat, Aug 19, 2023 at 8:58 PM \u003cryan at breen.xyz\u003e wrote:\n\n\u003e Thank you for the feedback, Ruben. I have a question.\n\u003e\n\u003e Could you please clarify what qualifies as a fraud proof in this concept?\n\u003e As I envision it, there is no cryptographic proof involved at all.\n\u003e\n\u003e In the context of a Sentinel chain, the sidechain's full nodes monitor\n\u003e Bitcoin mempools and blocks for withdrawals that violate the rules of the\n\u003e sidechain's consensus (such as thefts or incorrect balances). When the\n\u003e sidechain's full nodes detect an invalid withdrawal on Bitcoin, they\n\u003e publish a signed attestation to a public broadcast network (Nostr in this\n\u003e case). Participating Bitcoin full nodes and miners monitor the network for\n\u003e these attestations and subsequently reject the offending transactions. The\n\u003e process doesn't involve the presentation of proof because it's a\n\u003e distributed trust relationship.\n\u003e\n\u003e While Bitcoin full nodes could decide to operate their own sidechain\n\u003e nodes, we aim not to make this a requirement (addressing the long-standing\n\u003e sidechain dilemma). Bitcoin full nodes and miners wishing to participate\n\u003e can instead choose a distributed trust network comprising operators of\n\u003e sidechain full nodes that they trust. For instance, if they decide to\n\u003e follow 100 well-respected sidechain node operators, they might collectively\n\u003e agree that if 75 of them issue an attestation indicating that a transaction\n\u003e violates sidechain withdrawal rules, then that transaction should be deemed\n\u003e invalid by their node. Withdrawals are assumed valid if no public\n\u003e attestations are present.\n\u003e\n\u003e Furthermore, I'm uncertain about what potential data availability issue\n\u003e that might arise from this. Since there are no alterations to Bitcoin\n\u003e Core's validation logic, when a full node operator starts a new node from\n\u003e the genesis block, they will validate the proof of work of the longest\n\u003e chain and remain blissfully unaware that the transactions within the blocks\n\u003e are even associated with a sidechain.\n\u003e\n\u003e On Aug 19, 2023, at 10:35 AM, Ruben Somsen \u003crsomsen at gmail.com\u003e wrote:\n\u003e\n\u003e Hi Ryan,\n\u003e\n\u003e Thanks for taking the time to write a proposal. As is often the case,\n\u003e these ideas aren't actually as novel as you might think. What you describe\n\u003e here is known as \"fraud proofs\". The crucial problem it doesn't address is\n\u003e \"data availability\".\n\u003e\n\u003e The general idea behind fraud proofs is that if you commit to every\n\u003e computational step (note Bitcoin currently doesn't, but could), anyone can\n\u003e succinctly reveal erroneous steps (e.g. 1+1=3), thus convincing everyone\n\u003e the state transition (i.e. block) is invalid. This works if a bunch of\n\u003e people have all the data and are willing to construct and spread the fraud\n\u003e proofs, but what if nobody has the data?\n\u003e\n\u003e When someone claims data is unavailable, the only way to verify this claim\n\u003e is by downloading the data. You can't just ban this peer for false claims\n\u003e either, since the data might have actually been unavailable when the claim\n\u003e was made but then became available. In essence this means malicious peers\n\u003e can cause you to download all data, meaning you effectively haven't saved\n\u003e any bandwidth.\n\u003e\n\u003e It should be noted that fraud proofs could still reduce the need for\n\u003e computation (i.e. you download all data, but only verify the parts for\n\u003e which you receive fraud notifications), so it can still provide some form\n\u003e of scaling.\n\u003e\n\u003e As a bit of history, fraud proofs were actually briefly considered for\n\u003e inclusion into segwit, but were abandoned due to the data availability\n\u003e issue:\n\u003e https://bitcoincore.org/en/2016/01/26/segwit-benefits/#update-2016-10-19\n\u003e\n\u003e And finally, there is a way to address the data availability issue, which\n\u003e I describe here (PoW fraud proofs/softchains, though note I am currently of\n\u003e the opinion it's better used for low-bandwidth mainchain nodes instead of\n\u003e for sidechains):\n\u003e https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1\n\u003e\n\u003e In theory you can also do data availability sampling through the use of\n\u003e erasure codes, but that gets very complex and brittle.\n\u003e\n\u003e Hope this helps.\n\u003e\n\u003e Cheers,\n\u003e Ruben\n\u003e\n\u003e On Sat, Aug 19, 2023 at 4:29 PM Ryan Breen via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Recent discussions on social media regarding drivechains have prompted me\n\u003e\u003e to consider the implementation of a two-way sidechain peg within the\n\u003e\u003e Bitcoin protocol. I would like to propose what I believe may be a novel\n\u003e\u003e solution to this issue.\n\u003e\u003e\n\u003e\u003e I have previously written about here on my blog:\n\u003e\u003e https://ursus.camp/bitcoin/2023/08/10/sidechains.html\n\u003e\u003e And here is the Stacker News discussion:\n\u003e\u003e https://stacker.news/items/222480\n\u003e\u003e\n\u003e\u003e Nevertheless, I will hit the high points of the concept here:\n\u003e\u003e\n\u003e\u003e The most challenging problem that BIP-300 aims to address is how to\n\u003e\u003e establish a two-way peg without involving a multisig federation and without\n\u003e\u003e requiring miners and full nodes to possess knowledge about the sidechain or\n\u003e\u003e run a sidechain node. This is, in fact, a very difficult nut to crack.\n\u003e\u003e\n\u003e\u003e The method adopted by BIP-300 involves conducting sidechain withdrawals\n\u003e\u003e directly through the miners. To prevent miners from engaging in theft, the\n\u003e\u003e proposal mandates a three-month period for peg-outs, during which all\n\u003e\u003e miners vote on the peg-out. The intention here is to allow the community to\n\u003e\u003e respond in the event of an incorrect peg-out or theft. The miners are\n\u003e\u003e expected to be responsive to community pressure and make the correct\n\u003e\u003e decisions. To streamline this process of social consensus, withdrawals are\n\u003e\u003e grouped into one large bundle per three month period.\n\u003e\u003e\n\u003e\u003e Despite criticisms of this proposal, I find it to be a viable and likely\n\u003e\u003e effective solution. After all, Bitcoin's underlying mechanism is\n\u003e\u003e fundamentally rooted in social consensus, with the only question being the\n\u003e\u003e extent of automation. Nonetheless, I believe we now possess tools that can\n\u003e\u003e improve this process, leading to the concept of Sentinel chains.\n\u003e\u003e\n\u003e\u003e The core idea is that sidechain nodes function as Sentinels, notifying\n\u003e\u003e full nodes of thefts via a secondary network. These sidechain nodes monitor\n\u003e\u003e the current state of Bitcoin blocks and mempool transactions, actively\n\u003e\u003e searching for peg-outs that contravene sidechain consensus in order to\n\u003e\u003e steal funds. They transmit invalid transactions or blocks to public Nostr\n\u003e\u003e servers. Bitcoin full nodes wishing to partake in sidechain consensus can\n\u003e\u003e run a small daemon alongside Bitcoin Core. This daemon can monitor public\n\u003e\u003e Nostr nodes for messages about invalid transactions and then instruct\n\u003e\u003e Bitcoin Core, via RPC calls, to ignore and not forward those invalid\n\u003e\u003e transactions.\n\u003e\u003e\n\u003e\u003e Full nodes can choose any group of individuals or organizations to\n\u003e\u003e receive updates from Nostr. For instance, a full node might choose to trust\n\u003e\u003e a collective of 100 sidechain nodes consisting of a mix of prominent\n\u003e\u003e companies and individuals in the sidechain's sphere. Rather than relying on\n\u003e\u003e a single trusted group, full nodes form their own decentralized web of\n\u003e\u003e trust.\n\u003e\u003e\n\u003e\u003e This reverses the conventional model of two-way pegged sidechains.\n\u003e\u003e Instead of requiring nodes to monitor sidechains, sidechains now monitor\n\u003e\u003e nodes. In this sense, it is akin to drivechains, with the difference being\n\u003e\u003e that peg-outs could be instantaneous and individual, without the need for\n\u003e\u003e the three-month gradual social consensus. Furthermore, a single daemon can\n\u003e\u003e be configured to monitor notifications from any number of Sentinel chains,\n\u003e\u003e rendering this solution highly scalable for numerous sidechains.\n\u003e\u003e\n\u003e\u003e In summary, drivechains:\n\u003e\u003e\n\u003e\u003e - Require an initial consensus soft fork\n\u003e\u003e - Treat each new sidechain as a miner-activated soft fork (easier to\n\u003e\u003e deploy but more centralized)\n\u003e\u003e - Feature withdrawals occurring in three-month periods\n\u003e\u003e - Involve withdrawals in bundles\n\u003e\u003e - Exclude Bitcoin full nodes from participation in sidechain consensus\n\u003e\u003e - Are currently production-ready\n\u003e\u003e\n\u003e\u003e Sentinel chains:\n\u003e\u003e\n\u003e\u003e - Require no initial soft fork of any kind\n\u003e\u003e - Permit each new sidechain to be miner-activated OR user-activated (more\n\u003e\u003e challenging to deploy but more decentralized)\n\u003e\u003e - Allow instantaneous withdrawals\n\u003e\u003e - Facilitate individual withdrawals\n\u003e\u003e - Enable Bitcoin full nodes to engage in consensus\n\u003e\u003e - Are only at the concept stage\n\u003e\u003e\n\u003e\u003e Sentinel chains could potentially offer substantial advantages over other\n\u003e\u003e forms of two-way pegs, primarily in terms of speed and efficiency of\n\u003e\u003e consensus. Moreover, they align more closely with Bitcoin's principles by\n\u003e\u003e ensuring that power remains within the realm of full nodes. Lastly, they\n\u003e\u003e shield Core-only users from potential bug consequences stemming from\n\u003e\u003e consensus changes directly implemented in Bitcoin Core, possibly fulfilling\n\u003e\u003e the long-awaited promise of a fully opt-in soft fork.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Ryan Breen\n\u003e\u003e Twitter: ursuscamp\n\u003e\u003e Email: ryan @ breen.xyz\n\u003e\u003e Web: https://ursus.camp\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230822/c7aa16d5/attachment-0001.html\u003e"}