From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9F488B2B for ; Tue, 23 May 2017 14:22:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 15E82134 for ; Tue, 23 May 2017 14:22:46 +0000 (UTC) Received: by mail-oi0-f54.google.com with SMTP id h4so203089954oib.3 for ; Tue, 23 May 2017 07:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Pfw4IlOu+iAc2zYW5iMBtMHb/C4ZpYn+jIGUS/uEo8A=; b=Y3L53FSFq0CZBh0FadnfTVrCBTjIq9hrnE37ThPy9hgcYQGOFJ2nU4ZvDq+yo5Z3gr oOHvv5dAlYu600lkxwECja/ziswm4EOY2AYwsG/jh+HnYADMa8zZ1w2wzQobYN0gtJoY 76y1LYaAJUWwoYFGzIieejhWWGSLigsDb/wsyVpcV0YayPLAfaZRm9WEB1JdWaJsqEb5 t+Pf/cEfCst5K4xklAHh5rl8aWgTsjgD8pIMSRpRR7iVNJIg/v9T1mc9HDwhXXwyf2/i JGJ6gVHbYzzpvip3gOnW/AASViXIwwneR4Oel8/beFk9DYZtlCoTKSWPSKhoSWsDNGJ3 Z1uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Pfw4IlOu+iAc2zYW5iMBtMHb/C4ZpYn+jIGUS/uEo8A=; b=bvoFuOqKMM+Rd16OSFm0GWuiCmkzfI/Kt+5r/6sqaFrtJdG71c2lsSFrpPiH1UEeLD 128kixdKuet5CeXhRC+Dy5SsQ12hwXJbDX9acSqv2Z+4rULlfxR8Bo/4awLSavDil4gw rm6pEr4U3J3hsAl+FSUWtNGHgfCGdhvUdO6uQNRYi8I+8bCidALCfKUs7h/lsphCRFo8 kf/rI/7xt4tZ9DzBlGoWR0cHCCOX1BwlIOS0glLsZ0/lTu78bcCGdqL1tYU15eHCuQXM kCIhHMhcRTbdVOlaxVNbOg3OyVrzpSXU8e5noqW//fU79AH/qcMdMowvwFAP/H8WN02Z j3lQ== X-Gm-Message-State: AODbwcC5AvdAlZ7VWBHua2AGF1iqFsvV2tVpyIFtpgEu59J4Kec5TdLe oI6drtxfo3baZXFV1/o= X-Received: by 10.157.28.130 with SMTP id l2mr1729922ota.256.1495549364971; Tue, 23 May 2017 07:22:44 -0700 (PDT) Received: from [192.168.44.223] ([172.56.28.28]) by smtp.googlemail.com with ESMTPSA id n187sm314937oia.33.2017.05.23.07.22.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 07:22:44 -0700 (PDT) To: Tier Nolan References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> From: Paul Sztorc Message-ID: <141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com> Date: Tue, 23 May 2017 10:22:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 Cc: Bitcoin Dev 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 14:22:46 -0000 On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote: > 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). I'm not sure it makes much of a difference. First of all, in point of fact, the miners themselves own the coins from the coinbase. But more importantly, even if miners did not explicitly own the coins, they might profit by being bribed -- these bribes would come from people who did own the coins. The principle is that value "v' has been taken from A and given to B. This is effectively coercive activity, and therefore itself has value proportional to 'v'. > > 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. Yes. The more value _on_ the sidechain, the more abhorrent the malfeasance. > > 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. What do you think of my argument, that we already labor under such an assumption? An attacker could pay fees today equal to greater than sum(blockreward_(last N block)). According to you this would force a reorg, even on mainchain (pre-sidechain) Bitcoin. Yet this has never happened. It seems that this argument fully reduces to the "what will happen when the block subsidy falls to zero" question. > > 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. See above (?) for why I still feel they are comparable, if not identical. > > 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. Yes. Sidechains have newer, more interesting features, and simultaneously more risk. > > My concern is that you could have a situation where an attack is > possible and only need to assume that the miners are indifferent. Again, I think that we _already_ need to eliminate any assumption of "charitable miners". > > 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. Yes, we may see interesting behavior where people buy up these liabilities using the LN. In my original post, I mention that miners themselves may purchase these liabilities (at competitive rates, even if these arent the idealized 1:1). At this point, miners would be paying themselves and there would be no agency problem. > > 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? If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is probably the most human-readable description. Cheers, Paul