Re: [bitcoin-dev] summarising security assumptions (re cost metrics)

[Bryan Bishop <kanzure@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 --]