From: Paul Sztorc <truthcoin@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>, Chris Stewart <chris@suredbits•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Two Drivechain BIPs
Date: Tue, 12 Dec 2017 17:29:39 -0500 [thread overview]
Message-ID: <a29e72dd-f401-387b-6f54-473adf065166@gmail.com> (raw)
In-Reply-To: <XiOYlqnc-qXA7EdhRL5FyNeLDM6D5HissnTjnmuLlRrh8K2upymkEcnZb3drGUafY8CKkWjRbVQauYyUfA5cZrnIpNs5UAqWkcpahibEBpc=@protonmail.com>
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,
>
> >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
next prev parent reply other threads:[~2017-12-12 22:29 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
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 [this message]
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=a29e72dd-f401-387b-6f54-473adf065166@gmail.com \
--to=truthcoin@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=chris@suredbits$(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