Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7D6D58EF for ; Sun, 8 Nov 2015 17:19:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 99F4C179 for ; Sun, 8 Nov 2015 17:19:15 +0000 (UTC) Received: by iody8 with SMTP id y8so165699485iod.1 for ; Sun, 08 Nov 2015 09:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NKaSVZH3Im4DOpePiG/+6V+DSIvtQKfARNEpC9hM8eM=; b=fjAQ6gXrKhWGsI8YtEflE62DC0i3Lv7j1Fe4s8JKNeAIhRxwOHQKKSBpT+/w0E3Oph KgJNEeAnXgSJQXj9VbDwi1j7eGZDCA2EzE68TZXSEu9UvlGx9umrXVYlJn0k9Aztd7U/ E5KDMlL2nvStumHMURCsmKaKEH1suLV59T/t6d/jCtv3rAlUNw51zFfjz2UB5hZx4VEE wvV2H+t9viM/jsvXk5NJtVNVrokpELQjAO37sxT41PlGonq8myxkxZ/44S0kFzQDBBEx T6SeJoDF4HMz9mOTa/7SXtZLBTKxF/FCwE52MVCNU7K35VpFOwmRbuUWl1fvI2aG4d7S FRaQ== MIME-Version: 1.0 X-Received: by 10.107.17.160 with SMTP id 32mr15066628ior.28.1447003155097; Sun, 08 Nov 2015 09:19:15 -0800 (PST) Received: by 10.36.66.65 with HTTP; Sun, 8 Nov 2015 09:19:15 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Nov 2015 11:19:15 -0600 Message-ID: From: Bryan Bishop To: Gavin Andresen , Bryan Bishop Content-Type: multipart/alternative; boundary=001a113ed6780c74b005240aad2f X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 08 Nov 2015 17:20:33 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] summarising security assumptions (re cost metrics) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 17:19:16 -0000 --001a113ed6780c74b005240aad2f Content-Type: text/plain; charset=UTF-8 On Sun, Nov 8, 2015 at 8:54 AM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm very disappointed you don't mention the tradeoff at "the other end of > the bathtub" -- Key-holder versus Validator decentralization balance Gavin, could you please provide some clarity around the definition and meaning of "key-holder [decentralization]"? Is this about the absolute number of key-holders? or rather about the number of transactions (per unit time?) that key-holders make? Both/other? Anyone can generate a private key, and anyone can sign a transaction spending to a new commitment. Child-pays-for-parent could be used when transaction fees are too high. Perhaps more interesting would be something like lightning network payment channels, where only the commitment transaction needs to be in the blockchain history; does that count as key-holder decentralization at all? Also, consider the following scenario. Suppose there's a bunch of merge-mined sidechains that are mainnet BTC-pegged, and these sidechains are accessible by the lightning network protocol (multi-chain payments). Suppose also that on the different sidechains there are different transaction fee trends because of various technical differences underlying consensus or a different blockchain implementation (who knows). When someone routes payments to one of those different sidechains, because UTXOs could be cheaper over there due to different fee pressures, ... would that count as key-holder decentralization? Some of this scenario is described here, although not in more detail: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html Previously there has been the suggestion to use BTC-pegged merge-mined chains to handle excess transaction demand: http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/ https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004797.html I notice that in the Poon file there is a concern regarding "only 10 key holders", but how does that scenario really work? I think the actual scenario they mean to describe is "there's always a transaction backlog where the fees are so high that lower fee transactions can never get confirmations". So, more specifically, the scenario would have to be "lightning network exists and is working, and no lightning node can ever route enough different payments to commit to the blockchain under any circumstance". How would that be possible? Wouldn't most participants prefer the relatively instantaneous transactions of lightning, even if they can afford extremely high fees? Seems like the settlements have all necessary reason to actually happen, don't know what your concern is, please send help. I don't mean to put words in anyone's mouth, everything above is mostly asking for clarification around definitions. Some of these questions are repeats from: http://gnusha.org/bitcoin-wizards/2015-11-08.log Thank you. - Bryan http://heybryan.org/ 1 512 203 0507 --001a113ed6780c74b005240aad2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Nov 8, 2015 at 8:54 AM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I'm very disappointed you don't mention the tradeoff at = "the other end of the bathtub" -- Key-holder versus Validator dec= entralization balance

Gavin, could you please provide= some clarity around the definition and meaning of "key-holder [decent= ralization]"? Is this about the absolute number of key-holders? or rat= her about the number of transactions (per unit time?) that key-holders make= ? Both/other?

Anyone can generate a private key, and anyone can sign a transactio= n spending to a new commitment. Child-pays-for-parent could be used when tr= ansaction fees are too high. Perhaps more interesting would be something li= ke lightning network payment channels, where only the commitment transactio= n needs to be in the blockchain history; does that count as key-holder dece= ntralization at all?

Also, consider the following scenario. Suppose there's= a bunch of merge-mined sidechains that are mainnet BTC-pegged, and these s= idechains are accessible by the lightning network protocol (multi-chain pay= ments). Suppose also that on the different sidechains there are different t= ransaction fee trends because of various technical differences underlying c= onsensus or a different blockchain implementation (who knows). When someone= routes payments to one of those different sidechains, because UTXOs could = be cheaper over there due to different fee pressures, ... would that count = as key-holder decentralization? Some of this scenario is described here, al= though not in more detail:=C2=A0https://lists.linuxfoun= dation.org/pipermail/bitcoin-dev/2015-September/010909.html

Previously there has been the sugg= estion to use BTC-pegged merge-mined chains to handle excess transaction de= mand:

I notice that in the Poon f= ile there is a concern regarding "only 10 key holders", but how d= oes that scenario really work? I think the actual scenario they mean to des= cribe is "there's always a transaction backlog where the fees are = so high that lower fee transactions can never get confirmations". So, = more specifically, the scenario would have to be "lightning network ex= ists and is working, and no lightning node can ever route enough different = payments to commit to the blockchain under any circumstance". How woul= d that be possible? Wouldn't most participants prefer the relatively in= stantaneous transactions of lightning, even if they can afford extremely hi= gh fees? Seems like the settlements have all necessary reason to actually h= appen, don't know what your concern is, please send help.
I don't mean to put words in anyone's mouth, everything= above is mostly asking for clarification around definitions. Some of these= questions are repeats from:


- Bryan
http://heybryan.org/
1 512 203 0507
--001a113ed6780c74b005240aad2f--