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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
