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 98D5E405 for ; Mon, 9 Nov 2015 16:27:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D510317A for ; Mon, 9 Nov 2015 16:27:24 +0000 (UTC) Received: by lbbkw15 with SMTP id kw15so96560553lbb.0 for ; Mon, 09 Nov 2015 08:27:23 -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=1PrdxDLrmftCMId5c1Aea38Z/uDv6wEsbgaQ0DJakfc=; b=1IXKY1lLkV5hkf3EqAtXPzE/Oc+B14otZu4yXtsEzPpiTu+P+zkczmgAU69A1/LNHF 9s/qOYCSUiP23/+K5fblzrbss+H9/0AF/wT9oOTJUNg+d43+QfhAp6rnPlvj43uBMnM+ 4PullScJgQkEKJQrpbniCA6vPDgCvWFA6K9+amUCPH4DlGQJYbgt5QdphupbvwNnVxVT WDdDXiIu0SRhdDftO6SWwzzsj5rvyC0yg4/zjX2MV8/Q4gtluTSRgndI2acAtscyjeWb SgqTVg8hY78zDoFoty9/ni4y5X1FIj679v3ykMClUOPxNeFFF6cBID9ZAoAjZwMHfFn3 FiDw== MIME-Version: 1.0 X-Received: by 10.112.141.201 with SMTP id rq9mr8108338lbb.4.1447086442902; Mon, 09 Nov 2015 08:27:22 -0800 (PST) Received: by 10.25.22.95 with HTTP; Mon, 9 Nov 2015 08:27:22 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Nov 2015 11:27:22 -0500 Message-ID: From: Gavin Andresen To: Bryan Bishop Content-Type: multipart/alternative; boundary=001a11c38b5a637ab405241e11bc 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 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: Mon, 09 Nov 2015 16:27:25 -0000 --001a11c38b5a637ab405241e11bc Content-Type: text/plain; charset=UTF-8 On Sun, Nov 8, 2015 at 12:19 PM, Bryan Bishop wrote: > 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? > Both. If few transactions are possible, then that limits the number of key-holders who can participate in the system. Imagine the max block size was really small, and stretch your imagination and just assume there would be enough demand that those small number of transactions pay enough transaction fees to secure the network. Each transaction must, therefore, pay a high fee. That limits the number of keyholders to institutions with very-large-value transactions-- it is the "Bitcoin as a clearing network for big financial players" model. Using the Lightning Network doesn't help, since every Lightning Network transaction IS a set of Bitcoin transactions, ready to be dropped onto the main chain. If those Lightning Network transactions don't have enough fees, then the whole security of the Lightning Protocol falls apart (since it relies on being able to get timelocked transactions confirmed on the main chain in case your trading partner cheats). There is video of the Poon/Dryja talk: https://youtu.be/TgjrS-BPWDQ?t=41m58s -- -- Gavin Andresen --001a11c38b5a637ab405241e11bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Nov 8, 2015 at 12:19 PM, Bryan Bishop <kanzure@gmail.com> wrote:
Gavin, could you pl= ease provide some clarity around the definition and meaning of "key-ho= lder [decentralization]"? Is this about the absolute number of key-hol= ders? or rather about the number of transactions (per unit time?) that key-= holders make? Both/other?

Both.=C2=A0 If few transaction= s are possible, then that limits the number of key-holders who can particip= ate in the system.

Imagine the max block size was really small, and stretch your = imagination and just assume there would be enough demand that those small n= umber of transactions pay enough transaction fees to secure the network. Ea= ch transaction must, therefore, pay a high fee. That limits the number of k= eyholders to institutions with very-large-value transactions-- it is the &q= uot;Bitcoin as a clearing network for big financial players" model.

Using th= e Lightning Network doesn't help, since every Lightning Network transac= tion IS a set of Bitcoin transactions, ready to be dropped onto the main ch= ain. If those Lightning Network transactions don't have enough fees, th= en the whole security of the Lightning Protocol falls apart (since it relie= s on being able to get timelocked transactions confirmed on the main chain = in case your trading partner cheats).

<= /div>
There is video of the Poon/Dryja talk: =C2= =A0https://youtu.be/Tgj= rS-BPWDQ?t=3D41m58s

--
--
Gavin Andresen

--001a11c38b5a637ab405241e11bc--