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).
As a thought experiment, I suppose you could:
  1. Create a sidechain which is a Bitcoin clone, but with an entirely different consensus system.
  2. Peg all BTC into the Sentinel chain.
  3. On the sidechain, create a soft fork that makes peg-outs impossible (peg-out transactions on the sidechain go from valid -> invalid).
  4. 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