From: Bryan Bishop <kanzure@gmail•com>
To: Gavin Andresen <gavinandresen@gmail•com>,
Bryan Bishop <kanzure@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
Date: Sun, 8 Nov 2015 11:19:15 -0600 [thread overview]
Message-ID: <CABaSBaxKQe2SnMuwHq-7482BmY+vvD4SefKjXxEPhxZTOoyHrA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0T6QuYRmNyF_F124GyQ2EX5w93HCPLvrd4L5P6=xj_Xw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4372 bytes --]
next prev parent reply other threads:[~2015-11-08 17:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 23:03 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 [this message]
2015-11-09 16:27 ` Gavin Andresen
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=CABaSBaxKQe2SnMuwHq-7482BmY+vvD4SefKjXxEPhxZTOoyHrA@mail.gmail.com \
--to=kanzure@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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