Hi Zmn,
I'm actually not sure that the existence of these tools makes the
attacker's collective action problem that much easier to solve.
As I said: "...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."
But even under your scheme, there is someone who has to seek out the
Accomplices, and has to try to figure out what is acceptable to pay
them. This sparks a tiresome negotiation that drains both parties of
time and effort and might potentially last forever. Problematically,
there is a Market for Lemons problem with respect to how many blocks an
Accomplice "will" mine. If many people try to be Thieves at once, then
each individual Thief has less of an incentive to bother trying to steal
in the first place.
And so, even if your scheme does work, the improvement seems small. And
even if the improvement is very great, the remaining collective action
problem is still more difficult than the one in the comparative "reorg
case" (in which the problem is just to "pick the block number from which
to start the reorg").
Paul
On 12/5/2017 11:49 PM, ZmnSCPxj wrote:
Good morning Paul and Chris,
- 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).