[bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[ryan]

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

Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[Ruben Somsen]

[-- Attachment #1: Type: text/plain, Size: 7057 bytes --]

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=3), 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 PM Ryan Breen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.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/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 8059 bytes --]

Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[ryan]

[-- Attachment #1: Type: text/plain, Size: 9105 bytes --]

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=3), 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 PM Ryan Breen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.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 <http://breen.xyz/>
>> Web: https://ursus.camp <https://ursus.camp/>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 10395 bytes --]

Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[Ruben Somsen]

[-- Attachment #1: Type: text/plain, Size: 10237 bytes --]

Hi Ryan,

>As I envision it, there is no cryptographic proof involved at all.

That seems to directly contradict your previous message where you stated
"[t]hey transmit invalid transactions or blocks". This transmission you
alluded to is basically a (non-optimized) fraud proof, and it assumes that
this data is actually available (unsafe assumption).

If you envision that this step is not actually needed, then users are
essentially never validating and merely relying on a set of trusted
entities. Furthermore, the idea that everyone can just pick their own set
of validators is antithetical to consensus. What if my set of validators
disagrees with your set of validators? Now one of us will reject the
Bitcoin block with the peg-out while the other will not, causing sidechain
consensus failure to directly affect the mainchain.

Cheers,
Ruben



On Sat, Aug 19, 2023 at 8:58 PM <ryan@breen.xyz> wrote:

> 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=3), 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 PM Ryan Breen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.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/bitcoin-dev
>>
>
>

[-- Attachment #2: Type: text/html, Size: 11704 bytes --]

Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[ZmnSCPxj]

Good morning Ryan,

If I modify your Sentinel Chain open-source software so that it is honest for 999 sidechain blocks, then lies and says that the 1000th block is invalid even though it actually is, what happens?

Do mainchain nodes need to download the previous 999 sidechain blocks, run the sidechain rules on them, and then validate the 1000th sidechain block itself?

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[ryan]

I appreciate your questions, ZmnSCPxj.

I will answer your second question first: Mainchain nodes do not ever validate sidechain blocks. Sidechain nodes watch Bitcoin for invalid withdrawals, and publish signed attestations to a public broadcast network (such as Nostr) that a transaction is making an invalid withdrawal. These sidechain nodes are the so-called sentinels.

Bitcoin full nodes wishing to participate in holding miners accountable for stealing will watch the public broadcast network for attestations of improper withdrawals and treat those transactions as de facto invalid, thus forking violating miners off the network. In this way, launching a Sentinel chain mimics a user-activated soft fork, but without any changes to Bitcoin Core consensus logic.

Bitcoin full nodes would choose their own limited set of sidechain validators to trust. They might run their own sidechain node and trust that result exclusively. They might instead choose to trust a set of high quality community members such as companies, etc.

A downside to this method are the same as the difficulties of launching a soft fork. Making sure enough nodes (or miners) are on board to enforce the new rules prior to launch of a sidechain, or a minority of users will fork off the network. Additionally, maintaining a healthy network of sentinels for a sidechain is an additional angle to consider. 

The upside of this method is that sidechains can be user-activated, not just miner-activated like under the BIP-300 framework. And it allows Bitcoin full nodes to hold miners accountable for obeying the sidechain withdrawal rules.

--------------------

To answer your first question: When you say the sentinel chain software, are you asking what would happen if the sidechain developers create malicious code in sidechain node software? I suppose that would depend on the upgrade process of the sidechain, but the maximum fallout from malicious Sentinel chains is the exact same as any other sidechain proposal: the sidechain users get rugged.

The concept behind Sentinel chains puts no restriction on how sentinel chains may operate, only how the “difficult” part of launching a 2WP sidechain, peg-outs from sidechain to mainchain, may work without advanced cryptographic techniques such a ZKPs.

Thanks,
Ryan (ursuscamp on twitter)

> On Aug 28, 2023, at 9:48 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> 
> Good morning Ryan,
> 
> If I modify your Sentinel Chain open-source software so that it is honest for 999 sidechain blocks, then lies and says that the 1000th block is invalid even though it actually is, what happens?
> 
> Do mainchain nodes need to download the previous 999 sidechain blocks, run the sidechain rules on them, and then validate the 1000th sidechain block itself?
> 
> Regards,
> ZmnSCPxj

Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[ZmnSCPxj]

Good morning Ryan,


> I appreciate your questions, ZmnSCPxj.
> 
> I will answer your second question first: Mainchain nodes do not ever validate sidechain blocks. Sidechain nodes watch Bitcoin for invalid withdrawals, and publish signed attestations to a public broadcast network (such as Nostr) that a transaction is making an invalid withdrawal. These sidechain nodes are the so-called sentinels.

Let me reiterate my question:

Suppose I trust some sidechain node that is publishing such an attestation.

Then the sidechain node is hacked or otherwise wishes to disrupt the network for its own purposes.
And it attests that a valid sidechain withdrawal is actually invalid.

What happens then?

To the point, suppose that the attestation private key is somehow leaked or determined by a third party that has incentive to disrupt the mainchain network.

And it seems to me that this can be used to force some number of nodes to fork themselves off the network.

This is dangerous as nodes may be monitoring the blockchain for time-sensitive events, such as Lightning Network theft attempts.

Making "fork off bad miners!" a regular occurrence seems dangerous to me.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[ZmnSCPxj]

Good morning Ryan, et al.,

My long-ago interest in sidechains was the hope that they would be a scaling solution.

However, at some point I thought "the problem is that blockchains cannot scale, sidechains means MORE blockchains that cannot scale, what was I thinking???"
This is why I turned my attention to Lightning, which is a non-blockchain mechanism for scaling blockchains.

The only other reason for sidechains is to develop new features.

However, any actually useful features should at some point get onto the "real" Bitcoin.
In that case, a sidechain would "only" be useful as a proof-of-concept.
And in that case, a federated sidechain among people who can slap the back of the heads of each other in case of bad behavior would be sufficient to develop and prototype a feature.

--

In any case, if you want to consider a "user-activated" sidechain feature, you may be interested in an old idea, "mainstake", by some obscure random with an unpronouncable name: https://zmnscpxj.github.io/sidechain/mainstake/index.html

Here are some differences compared to e.g. drivechains:

* Mainchain miners cannot select the builder of the next sidechain block, without increasing their required work (possibly dropping them below profitability).
  More specifically:
  * If they want to select a minority (< 50%) sidechain block builder, then their difficulty increases by at least one additional bit.
    The number of bits added is basically the negative log2 of the share of the sidechain block builder they want to select.
  * The intent is to make it very much more unpalatable for a sidechain block builder to pay fees to the mainchain miner to get its version of the sidechain block confirmed.
    A minority sidechain block builder that wants to lie to the mainchain about a withdrawal will find that the fees necessary to convince a miner to select them are much higher than the total fees of a block.
    This better isolates sidechain conflicts away from mainchain miners.
* Miners can censor the addition of new mainstakes or the renewal of existing mainstakes.
  However, the same argument of censorship-resistance should still apply here (< 51% cannot reliably censor, and >=51% *can* censor but that creates an increasing feerate for censored transactions that encourages other potential miners to evict the censor).
  * In particular, miners cannot censor sidechain blocks easily (part of the isolation above), though they *can* censor new mainstakers that are attempting to evict mainstakers that are hostile to a sidechain.

There are still some similarities.
Essentially, all sidechain funds are custodied by a set of anonymous people.

One can consider as well that fund distribution is unlikely to be well-distributed, and thus it is possible that a small number of very large whales can simply take over some sidechain with small mainstakers and outright steal the funds in it, making them even richer.
(Consider how the linked write-up mentions "PoW change" much, much too often, I am embarassed for this foolish pseudonymous writer)

Regards,
ZmnSCPxj