[bitcoin-dev] Two Drivechain BIPs

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Dec 7 07:28:03 UTC 2017

Good morning Paul and Chris,

>I don't agree with the conclusion (that the optimal policy is "always downvoting", see above), but even if this analysis turns out to be correct, it isn't a total disaster. The result (which is in the original Nov
>2015 specification) is that miners are the ones who perform the atomic swaps. Then they walk the coins side-to-main (which, at this point, are *their* coins). As long as there are a few large mining groups,
>competition will drive the atomic swap fees down to negligible levels.

Assuming there are three large mining groups who will ruthlessly want to undercut their competition, and with roughly 33% of total hashpower each (with the remaining 1% being some negligible hoi polloi), then one strategy to undercut your competitors would be to upvote only your own withdrawals and downvote that of your competitors.  A miner using this strategy hopes that the other miners will give up on withdrawing their own coin and trade their sidecoins at a discount to the undercutting miner.  That is, it is a hostage attempt of the sidecoin funds of the other miners.

In the case of three large mining pools that mistrust one another, then, no withdrawal would ever push through and drivechains stabilize to one-way pegs.

Now suppose that two of the mining pools collude.  They join their withdrawals into a single withdrawal proposal and upvote that, while downvoting the withdrawal of the third miner.  I observe that this is an opposite disaster: the 66% colluding miners can instead decide to simply outright make an invalid withdrawal of all funds, split up in half between themselves.


But three exactly equal mining pools is unnatural, for that matter

Suppose that there are three mining pools: A with 34%, B with 33%, C with 32%, and the hoi polloi making up the remaining 1%.  Those three pools cannot safely let the others withdraw funds.

Suppose A colludes with C to join their withdrawal proposals and their hashpower to withdraw.  This means that B can be pressured to sell its sidecoins for a discount to the joint coalition of A and C, since B cannot withdraw its own coins.  This lowers the profitability of B, causing grinders to leave them in favor of either A or C.  Since A is slightly larger than C, it is slightly more preferable, so it grows in size slightly more than C does.  Eventually B dies due to the coalition of A and C.  A and C are the only remaining pools, with A slightly larger than C.  In this case, A can break from the coalition and squeeze C of its sidecoins, since only A can withdraw (as it has more hashpower than C).  Again, grinders will leave C for A.  A rational C that is capable of considering this possible future path will thus never ally with A in a coalition to crush B, as it will then be next in line for being destroyed.

Similar analyses for coalitions of (B, C) and (A, B).

Knowing this, and knowing that they will end up sidecoin bagholders if they cannot withdraw coins, all miners decide to collude together and put all their withdrawals into a single withdrawal proposal.  But this removes any check-and-balance that the single withdrawal proposal is truthful to the sidechain: that is, the single coalition of A,B, and C can decide to just steal all sidechain funds and reassign them in proportion to their hashpower.  This might be stable at end-of-life for the sidechain where all ordinary users of the sidechain have exited it, but is otherwise a theft risk if the sidechain is operating normally.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171207/61cd76b3/attachment.html>

More information about the bitcoin-dev mailing list