Re: [bitcoin-dev] Two Drivechain BIPs

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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

Good morning Paul and Chris,

>3. Collective Action Problem
>
>There actually is a collective action problem inherent to fraudulent withdrawals.
>
>If miners wish to fraudulently withdraw from the sidechain, they need to choose the destination addresses (on mainchain Bitcoin Core) months in advance. Then they need to upvote/downvote this
>destination, despite that fact that --during this time-- new hashpower might be coming online/offline, and/or hashers might be joining/leaving specific pools. I bring this up to demonstrate that even the most
>straightforward attack (of "a 51% hashrate group attacks a sidechain and distributes the proceeds to the group proportional to hashpower") is actually one that contains a difficult (and potentially
>interminable) negotiation. The effort required to initiate the negotiation is the source of the collective action problem here.
>
>I think that this collective action problem is actually more burdensome than Bitcoin's -- for mainchain Bitcoin miners merely need to decide which block height they intend to reorganize from.

I actually devised a way to work around this collective action problem, and discussed it obliquely in a private e-mail with Chris, while I was preparing my article on sidechain weaknesses.  I removed it before publication of the sidechain weaknesses article, but perhaps I should not have.

Collective action can be ensured by contract.  In a world where some system can enforce certain actions programmatically, it is possible to ensure collective action via a program, i.e. a "smart contract".

The thief pays out to the destination address that is a P2SH of the below script:

OP_IF
  OP_HASH160 <hash> OP_EQUALVERIFY
  OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
  <withdrawTime+1week> OP_CHECKLOCKTIMEVERIFY OP_DROP
  OP_TRUE
OP_ENDIF

If the thief does not publish the preimage of the hash within 1 week of the withdrawal time, then it becomes possible for anyone to spend the above script; basically, some lucky miner who wins the first block past the specified time will get the entire winnings.  Let us call the above script, the Theft Contract.

The thief then recruits accomplices to the theft.  Note that the attack can be prepared and initiated before the accomplices are even recruited.

The thief locks some coins (the "cut" the accomplice gets), to the below script, for each accomplice it tries to entice:

OP_IF
  OP_HASH160 <hash> OP_EQUALVERIFY
  OP_DUP OP_HASH160 <accomplicePubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
  <withdrawTime+2week> OP_CHECKLOCKTIMEVERIFY OP_DROP
  OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

Let us call the above script, the Accomplice Contract.  If the accomplice accepts, he or she then starts to vote for the invalid withdrawal.

If the invalid withdrawal succeeds, the thief acquires the entire theft price from the Theft Contract by publishing the preimage to the <hash>.  (If he or she does not, then, some randomly-selected miner will acquire the money after the timeout, so the thief needs to publish the hash, before the timeout in the Theft Contract).

This publishes the preimage on the blockchain.  Each accomplice can then acquire their "cut" of the theft by copying the preimage and claiming from the Accomplice Contract.

If the theft never succeeds, then there is no reason for the thief to ever publish the preimage, and after the timeout on the Accomplice Contract, the thief can recover his or her offered funds at no loss (minus transaction fees),  This incentivizes accomplices to actually cooperate with the thief, as they will not get paid if the theft does not push through.

All that is necessary is for a single "mastermind" thief to begin this process.  Accomplices can be recruited later, with the "cut" they get negotiated according to how much hashpower they can bring to bear on theft.

Newly-created miners and mining pools can be enticed at the time they arise by offering an Accomplice Contract to them.  Thus, newly-created miners and mining pools can be brought into cooperation with the thief as soon as they make a presence on the blockchain.

Even if some mining pool makes a public statement that they will not assist in the theft, the thief may still commit an Accomplice Contract for them on-chain anyway, and publicize it, in order to put the integrity of that mining pool in question and drive out support from that mining pool.  True accomplices may pretend to initially be honest and then signal dishonestly later, in order to make it more plausible that a pool that "committed" to not support the theft is not trustable since they have an Accomplice Contract that will compensate them if they support the theft, creating further confusion and discord among honest miners.  The thief may also use the existence of such an Accomplice Contract while negotiating with more minor miners and mining pools, in order to entice those also to join, and thus gain additional buffer against the stochastic process of miner voting.

With the Theft Contract and the Accomplice Contract, negotiation can be done in parallel with the theft attempt, reducing the cost of organizing collective action, as we have all hoped "smart contracts" would do.

----

While it is true, that this requires that the thief have significant funds in reserve prior to theft (in order to fund the Accomplice Contracts he or she will have to offer to potential accomplices), we have always been assured that theft can be initiated by miners only, and that miners already have a significant amount of money they control.  So it will be no problem for a potential thief to reserve some funds for paying to Accomplice Contracts.

This vulnerability can be fixed if withdrawals are restricted to simple P2PKH or P2WPKH only, but in the presence of Scriptless Script and Bellare-Neven signatures, that may be sufficient to create the Theft Contract and the Accomplice Contract (but I know too little of Scriptless Script to be sure).

Regards,
ZmnSCPxj

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