Turn majority hashrate from defacto to dejure soft fork?

RSK-BTC Bridge Features and Security
1

Rootstock has > 70% of the hashrate of Bitcoin, that is more miners commitment than for any or even all soft forks signaling combined lately.

Participating miners, presumably don’t want to see their rewards threatened, so we don’t know for sure that they didn’t patch their Bitcoin Core, or use a CUSF enforcer to prevent the federation from publishing any invalid pegout transactions in their blocks, but they might have done so.

We don’t know if they would reject blocks that include an invalid pegout transactions, but they might have done so.

I wonder if there is some value in encouraging Rootstock miners to signal that if they are ready to enforce that. The political risk of “malicious fork” is always there, but you can’t control hostile narratives, on the other hand such signal would significantly increase the value of Rootstock.

A more general and friendly approach, is to expect the federation to create transactions that includes the SPV proof that validates the pegout transaction. Then suggest that Rootstock miners don’t enforce that proof as an extra requirement to mine pegout transactions no top of the multisig. Allowing Rootstock in the future, but any other sidechain to use the same predicate to create their own trustless merge mining based bridge.

I wanted to float the idea, because I think bitcoin could benefit from a more assertive approach, as you can see from the eCash fork, bip110 fork, bip54, and even the controversial OP_RETURN relay rules, it is clear that nothing ever happens without a serious unapologetic push.

2

I propose adding the following at the beginning of the federation locking script:

<sah256("ROOTSTOCK")> OP_NOP10 OP_DROP

// Rest of existing locking script
OP_NOTIF
...
OP_ENDIF

The purpose of OP_NOP10 is to warn uninterested miners that this is an “opt-in covenant hook”, and be advised to not mine any transaction containing it, same as they avoid OP_SUCCESS, but if they (or full nodes) find it in a block, they don’t invalidate the block.

As Rootstock miners opt in this enforcement, they start signaling (on Rootstock) that they are ready to enforce this with an external software like CUSF suggests, once most of them suggest that, the federation can consider moving the funds to a pure <sah256("ROOTSTOCK")> OP_NOP10 OP_DROP script.

If the federation never upgrades to full miners enforcement, we still get an extra gatekeeping against fraudulent withdrawals.

3

More detailed writeup that I might share on Bitcoin mailing list, about an upgrade hook similar to OP_SUCCESS that aims to make miner activated upgrades as optional and minimize externalities as humanly possible.

1 Like
4

Since the genesis of Rootstock we’ve been very cautious not to push for any soft-fork and try to use Bitcoin as-is. After the Bitcoin block-size wars, pushing for a new soft-fork has become too politicized. If the bitcoin community accepts such a soft-fork and activates it, then obviously the Roostock community will try to make use of it. Our strategy regarding the Powpeg has alwas been defense-in-depth: if we have a new tool to protect the peg, we add a new layer of protection. We don’t replace one layer with another less-tested security layer.
So the way we would integrate such hashrate escrow mechanism would be, as you suggest, to add it as a new check to the current script.

2 Likes
5

Hey @SergioDemianLerner thank you for the reply, I know you haven’t been active here for a while so I appreciate it.

I agree that the best we can do is do a progressive incremental improvement to what we already have (I still wish for some changes on Rootstock side that can be done unilaterally like Syncchain or just checkpoints in the pegout transaction as OP_RETURN).

To that end, I am trying to work out a new form of covenant emulation on Bitcoin that I call HandoffCovenant that can look something like this:

<COVENANT_ID>           # 32-byte covenant identity — push
OP_DROP                 # pop it; NOP today, covenant-verify after upgrade

OP_IF

    # Branch A: Primary multisig — spendable immediately
    OP_11
    <pk_1> ... <pk_15>
    OP_15
    OP_CHECKMULTISIG

OP_ELSE

    <seq_3_months>      # ~13140 blocks; set on input nSequence
    OP_CHECKSEQUENCEVERIFY
    OP_DROP

    OP_IF

        # Branch B: Fallback multisig — spendable after 3 months of inactivity
        OP_3
        <pk_A> <pk_B> <pk_C> <pk_D> <pk_E>
        OP_5
        OP_CHECKMULTISIG

    OP_ELSE

        # Branch C: Anyone-can-spend — spendable after 1 year of inactivity
        <seq_1_year>    # ~52560 blocks; set on input nSequence
        OP_CHECKSEQUENCEVERIFY

    OP_ENDIF

OP_ENDIF

Basically an invitation to miners, when they care to, to take control from the federation, either in case of liveness failure, or in case a true MASF if the federation isn’t cooperating with the handoff.

This is the closest I got to something similar to Bip300 in the publicity of it, that hold miners accountable… I have a work in progress draft here if you care to read more about it as I refine it.

But I also want to say, I believe it is time to stop worrying about old taboos, especially when an upgrade like this goes out of its way to be explicit, consensual, trying to limit externalities and not consume any common goods.