[bitcoin-dev] Multi-chain payment channel nodes

[Bryan Bishop <kanzure@gmail.com>]

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