Here is a brief overview of a way to use something like the lightning network, or another multi-hop payment channel network, to handle more transactions per second.
These ideas were mentioned yesterday in #bitcoin-wizards and my email does not significantly elaborate on any of it (search for "cross-chain"): http://gnusha.org/bitcoin-wizards/2015-09-01.log http://gnusha.org/bitcoin-wizards/2015-09-02.log Mailing list discussion of this can be found at [6] and on the forum at [7]. Summary ======= Payment channel network nodes could operate on multiple chains or ledgers, especially if those ledgers are 2-way-peg compatible with BTC. Payment network users may have a variety of different preferences about security models or fees or any other number of system properties, and this method can be more accomodating than only offering mainnet UTXOs. Terminology =========== During the IRC monologue I was using the word "hub" and "cross-chain hubs" to describe a payment channel network node. Rusty Russell later brought to my attention a good argument from Joseph Poon to prefer to call them nodes, namely that "hub" implies centralization which isn't really necessary to implicate in these designs. So I'll stick with "node". Vague requirements and scenario speculation =========================================== - bip70-like payment-channel-compatible wallet-to-wallet communication protocol; useful for sender and receiver to negotiate how payment should be routed over the payment channel network. - assume existence of other ledgers with working 2-way-peg. - lightning network[1], amiko pay[2], or some other payment channel network with multi-hop payment routing - (at least some) payment channel nodes which access more than one blockchain or ledger system - can be more than two chains or ledgers that the node opens channels on or operate on (octoledger nodes?) - node can eventually setup 2-way-pegs through moxiebox code embedded in some opcode for a specification of an alternative federated ledger (just kidding, there be dragons here) Implication: Chain or ledger UTXO ambivalence ============================================= The sender (receiver) doesn't need to be concerned with which chain the receiver (sender) wishes to transact with, as long as both parties have wallets that can communicate with each other for fee negotiation while payment channel routing happens. Implication: UTXO preferences informed by fee pressures ======================================================= An earlier identified implication by others has been that transaction fee trends may influence when payment channel users choose to settle on the main chain, because fees may be too high to make the tradeoffs worthwhile for the user. Transaction fee pressure on the bitcoin mainnet chain may influence receivers, otherwise busy negotiating their payment channel payments, to negotiate receipt of their UTXOs on alternative chains which might be charging lower fees. Users that wish to settle to a ledger for a lower fee can do so without paying for main chain transaction prioritization. (Concerns about market exchange rate of BTC even with the presence of 2-way-pegs could be alleviated by multi-chain nodes that practice arbitrage. However, perhaps the financial markets will not bother assigning different values to BTC-compatible UTXOs on different sidechains? High mainnet fees may be reflected in market price differences, maybe....) Minor lightning network protocol change ======================================= Add chain parameter to onion routing protocol message. Receipt of this message was acknowledged by Rusty Russell yesterday. However, this change alone may be insufficient to enable this described usage. Also while I hope that onion routing continues to be the direction there's no guarantee of course. Other: Centralized ledgers ========================== Centralized ledger operators, such as companies running spot exchanges, could run payment channel nodes, allowing their users to deposit and withdraw funds "immediately" subject to whether the service provider is operating anything resembling a hot wallet. A centralized ledger operator could be considered a valid multi-chain destination in the above-mentioned imaginary lightning-compatible payment protocol. Payment channel network programmers should not be burdened with a thousand different standards for this ability, and instead there should be an attempt at general compatibility, although trustless implementations should be preferred if available. Luke-Jr mentions that the same (currently imaginary) payment protocol could also provide for user-to-user transfers on the same centralized services, skipping the payment channels entirely. Other ===== Here are some things that I have been meaning to look at, but haven't looked at: - can we do probabilistic payments[3][4] over payment channels? does it require all payments to be probabilistic payments? - is lightning network + multi-chain compatible with terminating on a chain like zerocash? or inside coinjoin/coinshuffle schemes? mixing implications? - are payment channel networks compatible with confidential transactions[5], and what about in the multi-chain regime? - should work if 2-way-peg between multiple assets on same chain, like in elements alpha? References ========== [1] http://lightning.network/lightning-network-paper.pdf [2] https://github.com/cornwarecjp/amiko-pay [3] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-May/002564.html [4] https://bitcointalk.org/index.php?topic=62558.0 [5] https://bitcointalk.org/index.php?topic=1085273.0 [6] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010797.html [7] https://bitcointalk.org/index.php?topic=1170303.0 - 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
