From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Paul Sztorc <truthcoin@gmail•com>, Chris Stewart <chris@suredbits•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Two Drivechain BIPs
Date: Thu, 07 Dec 2017 02:28:03 -0500 [thread overview]
Message-ID: <4iTYKa7LCe7_wN9neyumkheFrN7lPcmE8tbeD8if5SiobaBCeJUb3jpkwwrxi2-lL6q67TPLEAef43c7w-BRoFs21PUzUK8EOyTgaPCUZpA=@protonmail.com> (raw)
In-Reply-To: <b0c3f0f9-72f4-b73e-f5b1-e5590f9456aa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3528 bytes --]
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.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 4021 bytes --]
next prev parent reply other threads:[~2017-12-07 7:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 18:38 Paul Sztorc
2017-12-03 21:32 ` Matt Corallo
2017-12-04 19:05 ` Paul Sztorc
2017-12-04 19:36 ` Chris Pacia
2017-12-04 20:11 ` Chris Stewart
2017-12-05 19:55 ` Paul Sztorc
2017-12-07 7:28 ` ZmnSCPxj [this message]
2017-12-12 22:16 ` Paul Sztorc
2017-12-05 18:05 ` Paul Sztorc
2017-12-05 18:20 ` AJ West
2017-12-06 4:49 ` ZmnSCPxj
2017-12-06 20:51 ` CryptAxe
2017-12-08 15:40 ` ZmnSCPxj
2017-12-12 22:29 ` Paul Sztorc
2017-12-14 3:24 ` ZmnSCPxj
2017-12-05 7:41 ` Luke Dashjr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='4iTYKa7LCe7_wN9neyumkheFrN7lPcmE8tbeD8if5SiobaBCeJUb3jpkwwrxi2-lL6q67TPLEAef43c7w-BRoFs21PUzUK8EOyTgaPCUZpA=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=chris@suredbits$(echo .)com \
--cc=truthcoin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox