From: Gavin Andresen <gavinandresen@gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
Date: Mon, 9 Nov 2015 11:27:22 -0500 [thread overview]
Message-ID: <CABsx9T081xkFgwGQ-vrnm_yDAVpZunQFxAEbBBJXXaSxOOoXcA@mail.gmail.com> (raw)
In-Reply-To: <CABaSBaxKQe2SnMuwHq-7482BmY+vvD4SefKjXxEPhxZTOoyHrA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Sun, Nov 8, 2015 at 12:19 PM, Bryan Bishop <kanzure@gmail.com> 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
[-- Attachment #2: Type: text/html, Size: 2226 bytes --]
prev parent reply other threads:[~2015-11-09 16:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 23:03 [bitcoin-dev] summarising security assumptions (re cost metrics) Adam Back
2015-11-05 23:33 ` Eric Voskuil
2015-11-06 1:56 ` Jeremy
2015-11-06 8:05 ` Chris Priest
2015-11-06 14:08 ` Adam Back
2015-11-06 23:41 ` Chris Priest
2015-11-07 0:44 ` Eric Voskuil
2015-11-08 14:54 ` Gavin Andresen
2015-11-08 17:19 ` Bryan Bishop
2015-11-09 16:27 ` Gavin Andresen [this message]
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=CABsx9T081xkFgwGQ-vrnm_yDAVpZunQFxAEbBBJXXaSxOOoXcA@mail.gmail.com \
--to=gavinandresen@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=kanzure@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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