From decker.christian at gmail.com Sat Sep 10 21:36:12 2016 From: decker.christian at gmail.com (Christian Decker) Date: Sat, 10 Sep 2016 23:36:12 +0200 Subject: [Lightning-dev] Payment presentation strawmen. In-Reply-To: References: <87shtd7syz.fsf@rustcorp.com.au> Message-ID: <20160910213612.GA15435@nex> On Sat, Sep 10, 2016 at 06:16:07AM -0500, Ryan Grant wrote: > Payments unexpectedly fragmented into multiple LN channels are > trickier than transactions spending multiple UTXOs. If Alice pays Bob > using multiple channels to fund one payment, then Bob's accounting > procedures might need time-based heuristics to join separate LN > transactions. > > Wherever payments might fragment, some reassembly protocol support, > like BIP 70's merchant_data field, should be available. Every wallet > should be assisting with this accounting. > At least for the implementation using the r-hash to condition the release of funds there is nothing special about splitting a payment. As long as the recipient knows the total amount it should be receiving it can delay the release of the secret until it is guaranteed all funds. Collating the partial payments is done with the r-hash. I'm pretty sure that the private key release would also work the same way. A timeout might be sensible though just to be able to safely retry should a partial payment get stuck. In theory Lightning would also support arbitrary splitting and merging along the paths of the payment. Not sure if this is still possible (or desirable) when adding Onion Routing to the mix though :-) Cheers, Christian