10 sats \ 13 replies \ @ursuscamp 10 Aug 2023 \ on: deleted by author bitcoin
Hey, I wrote this! If you have any questions (or general insults to hurl my way), feel free to chime in.
It reminds me of two things.
One is the Ripple Consensus protocol, with its use of a trusted "Unique Node List" in its consensus. This comparison makes me wonder: why limit the Sentinal mechanism to only determining consensus on peg-outs? Why not other aspects of consensus, maybe even replacing proof of work? (I am not proposing to do so, of course, I am just thinking out loud about how far out the thought experiment could be extended.)
Another thing it reminds me of is Bitcoin Unlimited's configurable block size limit. The BU example might be the closest comparison for this design. And it has the same problem: that different users who have different configurations could end up on different chains for extended periods of time, maybe forever.
if Blockstream and their partners decided to transition Liquid from a federated sidechain to a Sentinel chain, they might make sure they have a majority of miners watching for thefts before they even made their transition active.
This is like a less-good drivechain. Less-good because it isn't guaranteed to be enforced by the broader full node network and because the majority of miners today may not be the majority of miners tomorrow, so Blockstream could find their security model drastically change overnight (think about how quickly the hashrate distribution changed when China banned mining in 2021, for example).
Overall I would agree that the design has some novelty to it because I haven't seen anything like it proposed before specifically in the context of a two-way peg, but I do not consider it a good replacement for BIP-300 and wouldn't use a two-way peg secured by this mechanism myself.
reply
The roles of Sentinels are not to enforce sidechain consensus but Bitcoin consensus. Specifically, the exact difference between Bitcoin Core consensus and the consensus rules necessary for the Sentinel chain to operate peg-outs on Bitcoin.
Another way to think about it is that it is a unique way of deploying a soft fork. In a Sentinel chain, this ONE specific address goes from “spendable by anyone” to “spendable only certain individuals in a sidechain peg out.” This a strict tightening of consensus rules that allow un-upgraded Bitcoin nodes to remain in agreement with the longest chain.
The difference is that instead of deploying a soft fork via a change in Bitcoin Core, we are deploying the soft fork OUTSIDE of Core. The implications for that are pretty enormous, when you consider that if we deployed other soft fork changes (not just side chains) through sentinels we could actually fully deliver on the promise of soft forks being truly opt-in. Core could crystallize and enter maintenance mode, and anyone not interested in the sidechain would never have to adopt bug risk from changes in Core. Bitcoin mountain men, rejoice!
The issue you describe about “maybe miners will leave and new ones will not care about the sidechain” is strictly a soft fork deployment coordination issue, when you think about it. No different than any other soft fork. How did we know that miners would actually run taproot once they signaled? And once we activated it, how did we know they wouldn’t back out? The answer is the same for Sentinel chains: they are incentivized to stay in consensus with the economic majority.
As for how this compares to BIP-300, I think it is better in a few significant ways:
- There is no hard requirement for long withdrawal times.
- There is no need for withdrawals in bundles. Withdrawals can be done by individuals doing spends directly on UTXOs.
Withdrawal times and withdrawal bundles, as I understand BIP-300, are a way to allow miners to construct withdrawals without needing to be aware of sidechain consensus rules. Instead of forcing them to understand sidechain consensus, they are being given 3 months for social feedback to get them to change their behavior to the correct one, and hopefully ACKs average out to the correct answer.
Sentinel chains replace those requirements by allowing miners to receive INSTANT feedback from as large a group of trusted nodes as they wish to help they stay in consensus with the economic majority. Nothing is stopping miners from running sidechain nodes and acting as their own sentinels. But a supplementary sentinel network allows us to eliminate the slow feedback issue of BIP-300 without requiring miners to run every sidechain node.
reply
But a supplementary sentinel network allows us to eliminate the slow feedback issue of BIP-300 without requiring miners to run every sidechain node.
This does seem like it could be a useful add-on for Drivechain. Although I think validity proof verification of drivechains would be even better, good to have this kind of setup as an option.
reply
Here's the rub there: If you're willing to accept a sentinel network as a signaling system for invalid peg-outs with Drivechain, that means... what? That miners will use the signaling system to ACK peg-outs? That seems pointless. They're both social consensus systems, but one is strictly slower and less efficient.
If you're willing to use a sentinel network, then you may as well eliminate the 3 month wait and bundles since it seems redundant. And once you eliminate those, you realize there's no need to use the blockchain to declare new sidechains and there's no need to have an elaborate peg-in, we can just a simple transaction + OP_RETURN. Now you've arrived at Sentinel chains again.
reply
The roles of Sentinels are not to enforce sidechain consensus but Bitcoin consensus. Specifically, the exact difference between Bitcoin Core consensus and the consensus rules necessary for the Sentinel chain to operate peg-outs on Bitcoin.
I realize that, so you can read my comments with that understanding :)
The difference is that instead of deploying a soft fork via a change in Bitcoin Core, we are deploying the soft fork OUTSIDE of Core.
Stated this way, it seems safer that the kind of "emergent consensus"-like process I pictured in my head before, but also in practice, for it to be safe, the rollout would have to be quite similar to how soft forks have historically been done, which to me makes the Sentinal and WoT concept somewhat (if not entirely) redundant. Will have to think about it some more though.
How did we know that miners would actually run taproot once they signaled? And once we activated it, how did we know they wouldn’t back out? The answer is the same for Sentinel chains: they are incentivized to stay in consensus with the economic majority.
Ah, well in that case Blockstream should not only look for hashpower majority support but also economic majority support. In which case as I said above, this looks like any other soft fork, just a different delivery mechanism (which has been discussed in the past in various venues).
reply
As a thought experiment, I suppose you could:
- Create a sidechain which is a Bitcoin clone, but with an entirely different consensus system.
- Peg all BTC into the Sentinel chain.
- On the sidechain, create a soft fork that makes peg-outs impossible (peg-out transactions on the sidechain go from valid -> invalid).
- All economic activity moves to Sentinel chain and old Bitcoin fades away.
You've really made me think today, John. Thank you 😆
reply
Ah yes, thanks. I must have misread your comment.
In that case, it sounds like you're asking about whether a hard forking consensus change could be deployed through sentinels. It's a very interesting question, actually! I had considered deploying a fork through the method of sentinels to be safer in some ways, because it removes the risk of soft fork bugs creating problems for Core users. But I think that if a fork is deployed through sentinels, it's only possible to be a soft fork and couldn't possibly be a hard fork. I consider this to be a feature.
The more I consider it, the more I think it would be impossible to outright change the consensus methodology to something other than PoW via sentinels. The reason being that sentinels can only tell nodes which previously valid transactions are now invalid. There's no way to make Core accept previously invalid transactions that are now valid.
I would be interested in other places a soft fork method like this has been discussed, if you have any references (no pressure, I'm sure that's a very deep cut).
reply
I'm sure that's a very deep cut
Yeah. Of the ones I distinctly remember, I recall some reddit posts by Greg Maxwell back during the segwit activation days, which I cannot find because because reddit search sucks and I neglected to favorite them at the time. So they might be lost to history. But Greg was discussing how miners could run some soft fork software next to Bitcoin Core, and it would use the soft fork software to validate incoming blocks, and use Bitcoin Core to validate outgoing blocks (to ensure that the blocks would be accepted by non-upgraded miners).
More recently, there was related discussion prompted by the CTV activation debate in 2021. That might be easier to find, and more diverse discussion since many people took part in it. Jeremy had proposed using an alt-client to activate CTV, which was controversial in and of itself, aside from the proposed Speedy Trial activation mechanism.
reply
Can you send this to PaulStorcz and update me/us with his comment ?
(maybe never mind, looks like lightcoin replied, the guy behind spacechains, i think)
reply
I'm a bit of a drivechain noob, but this seems kinda like Liquid Network in that it's federated trust.
It's just via Sentinels as opposed to Liquid's set of ~15 trusted entities.
Is the idea that this strikes a balance between: On the one hand have miners being the authority that can allow illegal peg outs with a 51% attack (like most side chain proposals I've seen), and on the other hand having 15 assigned authorities (like Liquid)?
I think it could be better than other proposals, but I wanna make sure I understand.
reply
Haven't read up on this proposal yet, but on your observation on the similarities with Liquid, there is a bit of history.... https://www.drivechain.info/blog/liquid/
reply
I can see how you might think it is a kind of distributed federation, but I would argue that it is not.
Sidechain nodes still determine consensus and can be as permissionless as you want. You can still run a sidechain node just like Bitcoin. The sidechain node acts as your personal Sentinel, telling your Bitcoin node which transactions and blocks are valid.
The “federation-sounding” part is that Sentinels can also broadcast invalid transactions via Nostr. Instead of running a full sidechain node, miners and users can trust their own PERSONAL “federation” of users of any size and makeup, and trust the other nodes to tell them the bitcoin transactions to ignore.
This is fully optional for all parties and merely serves as a way for people to on board to a sidechain and participate without running a node for every chain.
reply
deleted by author
reply