Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DC0725AC for ; Tue, 23 May 2017 09:51:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 25A5B1AE for ; Tue, 23 May 2017 09:51:28 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id l18so194192379oig.2 for ; Tue, 23 May 2017 02:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=FeT23f45sWePAECppDhpruhanB8FI/XAQeMe1ib0tO8=; b=t+7YgvFP5eq/R8fuYmkzUcFmLeXwDmXQz6spKw1NuuCmapCHekcvVXjWDQF4VBCH/q K0kPcp7uoUPhoIxtlP1TyfV2eWtaPeQplmu7QZ8EkYJCTDlzVKZuuSxrDvyjjOtR9IT2 aU4T40XxRtEArfwqTHo1fGaJyTnGjBmhHco/pw7mY8wv4wWl3RCNrwbFvEXbANbfImxO RnoaQ8Kuv39mrezTLxvGaxzqT9q3XvHXFBx4F2Vwy5AuELtb5a6MEplrA6WSp08c1MG6 4Twpi89LZULZ4Eno3Kh5e9gh0JQzc5x+pcY7AHQrq2FBMbIi/Oj9o3aF8N6bV/xtksat NGdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=FeT23f45sWePAECppDhpruhanB8FI/XAQeMe1ib0tO8=; b=Kfw61QtejyMy+L/d+4OM5U21EkBlnu8RzGvB86vNuX8rCV9R5FEBvvqu47DrK/wagf 4oRnvZTt+xhot+jBR6QdPANy9u0I4maMxPhK/7JZDTB0mjYv10kYLxHpa3/5BmLTKyBD 7AG718TdGO6mKSGeCepdQGKuatfrMEEIGdrBxdNJnR/k7JKpFFS2L9gDZ/EcSyOb+Jxu qKDUZfqe0KAgpY0cJkJn3ItKMFCE4pPlm66lDi9zkjI277FAGTvUiz1dBoJLe2oL/CCg 2fk4jEdvFyZTTzudha7HDXrz7Kwbf2imGayvBSIRHVrK8BVpRl9CHJQkl0/t3K8zEADa OdcA== X-Gm-Message-State: AODbwcBgONDZRY4qTsmxLI3VHMSydGpW5nJfsljZXAppGxlGe1F9o6us 1bUlJ6Y/cttzUKc5PLoZIHb1EyVlyw== X-Received: by 10.157.19.67 with SMTP id q3mr1385204otq.110.1495533087107; Tue, 23 May 2017 02:51:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.100.89 with HTTP; Tue, 23 May 2017 02:51:26 -0700 (PDT) In-Reply-To: References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> From: Tier Nolan Date: Tue, 23 May 2017 10:51:26 +0100 Message-ID: Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary="001a113919b0682ff805502deef6" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 09:51:29 -0000 --001a113919b0682ff805502deef6 Content-Type: text/plain; charset="UTF-8" On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc wrote: > I would replace "Bitcoins you manage to steal" with "Bitcoins you manage > to double-spend". Then, it still seems the same to me. > > With double spending, you can only get ownership of coins that you owned at some point in the past. Coins that are owned by someone else from coinbase to their current owners cannot be stolen by a re-org (though they can be moved around). With BMM, you can take the entire reserve. Creating a group of double spenders can help increase the reward. > > It may destroy great value if it shakes confidence in the sidechain > infrastructure. Thus, the value of the stolen BTC may decrease, in addition > to the lost future tx fee revenues of the attacked chain. > > http://www.truthcoin.info/blog/drivechain/#drivechains-security > > That is a fair point. If sidechains are how Bitcoin is scaled, then shaking confidence in a side-chain would shake confidence in Bitcoin's future. I wasn't thinking of a direct miner 51% attack. It is enough to assume that a majority of the miners go with the highest bidder each time. If (average fees) * (timeout) is less than the total reserves, then it is worth it for a 3rd party to just bid for his theft fork. Miners don't have to be assumed to be coordinating, they just have to be assumed to take the highest bid. Again, I don't really think it is that different. One could interchange > "recent txns" (those which could be double-spent within 2-3 weeks) with > "sidechain deposit tnxs". > It is not "recent txns", it is recent txns that you (or your group) have the key for. No coordination is required to steal the entire reserve from the sidechain. Recent txns and money on the sidechain have the property that they are riskier than money deep on the main chain. This is the inherent point about sidechains, so maybe not that big a deal. My concern is that you could have a situation where an attack is possible and only need to assume that the miners are indifferent. If the first attacker who tries it fails (say after creating a fork that is 90% of the length required, so losing a lot of money), then it would discourage others. If he succeeds, then it weakens sidechains as a concept and that creates the incentive for miners to see that he fails. I wonder how the incentives work out. If a group had 25% of the money on the sidechain, they could try to outbid the attacker. In fact, since the attacker, by definition, creates an illegal fork, the effect is that he reduces the block rate for the side chain (possibly to zero, if he wins every auction). This means that there are more transactions per block, if there is space, or more fees per transaction, if the blocks are full. In both cases, this pushes up the total fees per block, so he has to pay more per block, weakening his attack. This is similar to where transaction spam on Bitcoin is self-correcting by increasing the fees required to keep the spam going. Is there a description of the actual implementation you decided to go with, other than the code? --001a113919b0682ff805502deef6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
I wou= ld replace "Bitcoins you manage to steal" with "Bitcoins you= manage to double-spend". Then, it still seems the same to me.<= br>


With double spe= nding, you can only get ownership of coins that you owned at some point in = the past.=C2=A0 Coins that are owned by someone else from coinbase to their= current owners cannot be stolen by a re-org (though they can be moved arou= nd).=C2=A0

With BMM, you can take the entire reserve.=C2= =A0 Creating a group of double spenders can help increase the reward.
=C2=A0

It may des= troy great value if it shakes confidence in the sidechain infrastructure. T= hus, the value of the stolen BTC may decrease, in addition to the lost futu= re tx fee revenues of the attacked chain.

=


That is a fair point.=C2=A0 If sid= echains are how Bitcoin is scaled, then shaking confidence in a side-chain = would shake confidence in Bitcoin's future.

I wasn= 9;t thinking of a direct miner 51% attack.=C2=A0 It is enough to assume tha= t a majority of the miners go with the highest bidder each time.

If (average fees) * (timeout) is less than the total reserves, then= it is worth it for a 3rd party to just bid for his theft fork.=C2=A0 Miner= s don't have to be assumed to be coordinating, they just have to be ass= umed to take the highest bid.

Again= , I don't really think it is that different. One could interchange &quo= t;recent txns" (those which could be double-spent within 2-3 weeks) wi= th "sidechain deposit tnxs".

It is not "recent txns", it is recent txns that you (or y= our group) have the key for.=C2=A0 No coordination is required to steal the= entire reserve from the sidechain.

Recent txns and money= on the sidechain have the property that they are riskier than money deep o= n the main chain.=C2=A0 This is the inherent point about sidechains, so may= be not that big a deal.=C2=A0

My concern is that you cou= ld have a situation where an attack is possible and only need to assume tha= t the miners are indifferent.

If the first att= acker who tries it fails (say after creating a fork that is 90% of the leng= th required, so losing a lot of money), then it would discourage others.=C2= =A0=C2=A0 If he succeeds, then it weakens sidechains as a concept and that = creates the incentive for miners to see that he fails.

I = wonder how the incentives work out.=C2=A0 If a group had 25% of the money o= n the sidechain, they could try to outbid the attacker.

I= n fact, since the attacker, by definition, creates an illegal fork, the eff= ect is that he reduces the block rate for the side chain (possibly to zero,= if he wins every auction).=C2=A0 This means that there are more transactio= ns per block, if there is space, or more fees per transaction, if the block= s are full.=C2=A0

In both cases, this pushes up the total fees per = block, so he has to pay more per block, weakening his attack.=C2=A0 This is= similar to where transaction spam on Bitcoin is self-correcting by increas= ing the fees required to keep the spam going.

Is there a = description of the actual implementation you decided to go with, other than= the code?
--001a113919b0682ff805502deef6--