Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
We went ahead with this idea and implemented it in muun wallet as an experiment: you can scan an invoice, and if there isn't a route with enough capacity to the destination node, we'll open a channel directly and, once it's locked, fulfill the payment using that channel. The initial idea was to improve the UX of not being able to route a payment. However, since we have to wait until the channel is locked to make the final hop of the payment, the full process might take about an hour, depending on the block times. That generates a couple of UX challenges: * The user is expecting lightning payments to be completed instantly, so it might be preferable to fail the payment rather than locking it for an hour until the channel is opened. * Most invoices in the wild have 10/15 minute expirations, so they don't even qualify for doing something like this. * Even if the user generates the invoice manually, most interfaces default to 1 hour expiration, which might be too little time. Given these constrains, we decided that the best application for this flow is to top-up your own node. That is, add outbound capacity to your node in a non-custodial manner. We'd love to hear if you have some idea as to how to make this use case better, or apply this concept to other use cases. On Fri, Aug 16, 2019 at 12:58 AM ZmnSCPxj wrote: > Good morning Dario, > > > Having said that, if the usability of the scheme "open channel, wait > until it's locked, then send HTLC payment" were deemed good enough, then > routing nodes could implement this idea to route payments "just in time", > even if there aren't any pre-existing routes to the destination. > > This is a good idea, but one with some difficulties in implementation. > > * The current onion route format contains the next short-channel-id (and > in particular not the node-id of the next hop in the route). > Indeed, short-channel-ids were invented to reduce the size of the onion > route format. > If a channel used to exist between nodes, then the payer might have > gotten this short-channel-id in the past via gossip. > Then later, if the channel is closed, most implementations will forget > the short-channel-id (and thus would probably also forget *which* node the > short-channel-id used to be connected to, so determining the next node for > the just-in-time channel opening would be difficult). > * C-Lightning retains this information for some blocks but will forget > it at some point. > * Implementations that do this "just-in-time" channel-opening will need > to remember this short-channel-id for longer. > * The final HTLC going to the payee has the tightest time schedule. > If this HTLC has a timeout that is too near, the payee will reject the > payment. > Since channel opening requires blocks to pass in order to confirm the > funding transaction, by the time the HTLC reaches the payee, the timeout > might now be judged too near and the payee will reject the payment anyway. > * The spec itself recommends the use of "shadow routing". > Briefly, the payer obscures who the payee is by adding a greater > timeout to the payee than the minimum required by the payee. > (since timeouts decrease at each hop, an intermediate node can guess > who the payee is by determining how small the remaining timeout looks.) > This can mitigate the above effect. > C-Lightning implements shadow routing. > > However, this same idea would be greatly helped by trampoline routing: > > * The planned trampoline routing indicates the node id of the next > trampoline hop, thus not requiring implementations to remember who a closed > short-channel-id used to be connected to. > * Trampoline nodes will generally require a much larger fee and timelock > budget, because they also have to build routes. > If the fee and timelock budgets are big enough, then the trampoline node > might decide to open a direct channel to the next trampoline node > "just-in-time" for the next trampoline hop. > > Regards, > ZmnSCPxj > > > > > On Wed, Aug 14, 2019 at 8:42 PM ZmnSCPxj via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > > > > > Good morning Ecurrencyhodler, > > > > > > It seems to me a trusted model then. > > > Regardless of who makes the channel (the payee cannot determine who > the payer is anyway) the payee cannot trustlessly release the product until > the channel is deeply confirmed, else your security is only 0-conf, not > off-chain. > > > > > > Further, `push_msat` has the drawback of not providing > proof-of-payment, thus an intermediate hop node may be unable to claim > funds. > > > (I believe `push_msat` was a mistake: you should simply make a normal > HTLC payment (that provides proof-of-payment) after the channel is deeply > confirmed, and `push_msat`, if you read lightning-rfc, does have this > warning that you cannot trust money you receive that way until the channel > is deeply confirmed.) > > > > > > Regards, > > > ZmnSCPxj > > > > > > Sent with Proton
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
Hello Ecurrencyhodler, We've been considering this flow for muun wallet, which has native submarine swap functionality, so it wouldn't be too difficult to implement. However, there's some problems with the idea: * As ZmnSCPxj notes, the push_msat functionality doesn't work for non-custodial setups, like a submarine swap. It does work for Bitrefill's Thor (ie. turbo channels) because you are trusting them to hold your money until the channel fully confirms. Per the RFC, "push_msat is an amount of initial funds that the sender is *unconditionally* giving to the receiver". * You *can* use an HTLC payment once the channel is deep enough, but you'll have to wait until the channel is locked to receive the money and be able to spend it. While this might be good enough for some use cases, like charging your own node, it doesn't provide the seamless UX for lightning payments you're looking for. Having said that, if the usability of the scheme "open channel, wait until it's locked, then send HTLC payment" were deemed good enough, then routing nodes could implement this idea to route payments "just in time", even if there aren't any pre-existing routes to the destination. On Wed, Aug 14, 2019 at 8:42 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Ecurrencyhodler, > > It seems to me a trusted model then. > Regardless of who makes the channel (the payee cannot determine who the > payer is anyway) the payee cannot trustlessly release the product until the > channel is deeply confirmed, else your security is only 0-conf, not > off-chain. > > Further, `push_msat` has the drawback of not providing proof-of-payment, > thus an intermediate hop node may be unable to claim funds. > (I believe `push_msat` was a mistake: you should simply make a normal HTLC > payment (that provides proof-of-payment) after the channel is deeply > confirmed, and `push_msat`, if you read lightning-rfc, does have this > warning that you cannot trust money you receive that way until the channel > is deeply confirmed.) > > Regards, > ZmnSCPxj > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, August 15, 2019 2:05 AM, ecurrencyhodler < > ecurrencyhod...@gmail.com> wrote: > > > >So would `push_msat`; until confirmed deeply the channel opening can > still be cancelled by double-spending and it would be foolhardy to deliver > the product until the channel is deeply confirmed to be opened. > > > > Okay so there's 2 situations here I'd like to explore: > > > > 1. Bob -> routing node -> Me > > > > 2. Bob -> Me > > > > Scenario 1 > > If Bob pays the invoice and the routing node opens a payment channel and > pushes sats to me, you could stipulate that the routing node isn't able to > fully take ownership of the sats until 6 confirmations potentially via Hodl > Invoices (by the time the routing nodes channel with pushed payments > confirms with mine). But I could still make LN payments instantly through > the routing node because the routing node just needs to wait until the 6 > confirmations and settle all accounts after the fact. > > > > Scenario 2 > > Bob and I know each other so if channel disappears, it's basically the > same situation with Thor's instant channel. But we could completely remove > scenario 2 and only allow routing nodes to open channels to me as long as > Bob makes the payment. > > > > On Wed, Aug 14, 2019 at 12:03 AM ZmnSCPxj > wrote: > > > > > Good morning Ecurrencyhodler, > > > > > > > Hi ZmnSCPxj! > > > > > > > > Submarine swaps are a great current solution, but we still have to > wait for confirmations. > > > > > > So would `push_msat`; until confirmed deeply the channel opening can > still be cancelled by double-spending and it would be foolhardy to deliver > the product until the channel is deeply confirmed to be opened. > > > At least this way, you can perform the preparation in parallel to your > other startup operations for starting your business before actual launch of > your merchant website. > > > > > > > > > > > >Further, while it involves fees, it does give you control over what > nodes you make channels with, and would be a good investment in your future > accessibility over the Lightning Network. > > > > > > > > What disadvantages do you see over this proposal and say something > like autopilot? Or do you just prefer manual channel management overall? > > > > > > This should eventually be implementable by some kind of auto-system. > > > It is still early days and a lot of infrastructure is yet to be > written. > > > > > > Regards, > > > ZmnSCPxj > > > > > > > > > > > On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj > wrote: > > > > > > > > > Good morning Ecurrencyhodler, > > > > > > > > > > A current and practical way to set up incoming liquidity would be > to take some onchain funds, create a channel to a high-uptime node on the > network (just run an autopilot), then use a submarine swap (i.e. pay > offchain funds to buy onchain fun
Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput
Something like this might also be useful for several use cases related to RBF. For example: Alice sends Bob an RBF-activated transaction T1 with the intention of bumping its fee if necessary. Bob wants to send these funds to Carol, but cannot wait until T1 confirms, so he crafts a transaction T2 that spends T1 using SIGHASH_NOINPUT, and pays Carol. Carol can now make sure she receives the money even if Alice fee-bumps T1, as long as the outputs of the replaced transactions are compatible. Extra care should be taken to avoid rebinding, maybe by including an extra input in T2 that doesn't use SIGHASH_NOINPUT. On Mon, Apr 30, 2018 at 1:29 PM, Christian Decker via bitcoin-dev < bitcoin-...@lists.linuxfoundation.org> wrote: > Hi all, > > I'd like to pick up the discussion from a few months ago, and propose a new > sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the > previous > output. This was previously mentioned on the list by Joseph Poon [1], but > was > never formally proposed, so I wrote a proposal [2]. > > We have long known that `SIGHASH_NOINPUT` would be a great fit for > Lightning. > They enable simple watch-towers, i.e., outsource the need to watch the > blockchain for channel closures, and react appropriately if our > counterparty > misbehaves. In addition to this we just released the eltoo [3,4] paper > which > describes a simplified update mechanism that can be used in Lightning, and > other > off-chain contracts, with any number of participants. > > By not committing to the previous output being spent by the transaction, > we can > rebind an input to point to any outpoint with a matching output script and > value. The binding therefore is no longer explicit through a reference, but > through script compatibility, and the transaction ID reference in the > input is a > hint to validators. The sighash flag is meant to enable some off-chain > use-cases > and should not be used unless the tradeoffs are well-known. In particular > we > suggest using contract specific key-pairs, in order to avoid having any > unwanted > rebinding opportunities. > > The proposal is very minimalistic, and simple. However, there are a few > things > where we'd like to hear the input of the wider community with regards to > the > implementation details though. We had some discussions internally on > whether to > use a separate opcode or a sighash flag, some feeling that the sighash flag > could lead to some confusion with existing wallets, but given that we have > `SIGHASH_NONE`, and that existing wallets will not sign things with unknown > flags, we decided to go the sighash way. Another thing is that we still > commit > to the amount of the outpoint being spent. The rationale behind this is > that, > while rebinding to outpoints with the same value maintains the value > relationship between input and output, we will probably not want to bind to > something with a different value and suddenly pay a gigantic fee. > > The deployment part of the proposal is left vague on purpose in order not > to > collide with any other proposals. It should be possible to introduce it by > bumping the segwit script version and adding the new behavior. > > I hope the proposal is well received, and I'm looking forward to discussing > variants and tradeoffs here. I think the applications we proposed so far > are > quite interesting, and I'm sure there are many more we can enable with this > change. > > Cheers, > Christian > > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2016-February/012460.html > [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki > [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html > [4] https://blockstream.com/eltoo.pdf > ___ > bitcoin-dev mailing list > bitcoin-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] reducing the number of blockchain transactions used by the LN, and the fees paid to confirm them
This operation is called splice in/out, or clopen transaction. There's some information here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000696.html Cheers, Dario On Wed, Dec 20, 2017 at 9:52 PM, Jim Renkel wrote: > Hello, all! > > I'm a long-time computer networking developer, but a newbie to > cryptocurrency, and am interested in contributing to its development. > > While looking at the lightning network design and code, I've come up with > an idea the would reduce the number of blockchain transactions used by the > LN, and the fees paid to confirm them, in a common LN use case. > > I did a quick search and couldn't find this idea presented previously, but > I may have missed it. If so, or if the idea is faulty, I'm sure you guys > will let me know. :-) > > And forgive me if I don't have the terminology quite right yet. > > The use case I am referring to is the frequent, repeated purchases by a > customer from the same merchant over an extended period of time. I think > this will be a common use case. > > For example: Alice buys a cup of coffee from Bob's Coffee Shoppe every > day, has done so for years, will do so for years. > > To use the LN to pay for these purchases, Alice opens and funds an LN > channel to Bob. This takes one blockchain transaction. > > As coffees are purchased every day, funds are transferred from Alice to > Bob in the channel without any blockchain transactions. > > Alice cannot afford to fund the channel for an extended period of time, > and Bob is unwilling to wait an extended period of time to be paid for the > coffees Alice has purchased. > > So every week or so, Alice and Bob close the channel, Alice gets back any > unspent funds, and Bob gets the funds that have been transferred to him for > Alice's purchases. Then Alice and Bob re-open the channel with new funding > from Alice. Closing and re-opening the channel each take one blockchain > transaction. > > Over the life of the channel, if there are n close/re-open cycles, 2*n > blockchain transactions are required: 1 to open the channel initially, 2 > each time the channel is closed and re-opened (n-1 times), and 1 to close > the channel finally. > > If the LN were enhanced with an operation to deposit and withdraw funding > in the channel to and from the blockchain without closing the channel, this > could be done with a single blockchain transaction that is essentially the > merge of the closing and re-opening blockchain transactions. > > In this example, each adjustment will only pay Bob his accumulated but as > yet unpaid funds and charge Alice for the new funds she places into the > channel, but leave Alice's unspent funds in the channel. The channel could > continue to operate between the launching and confirmation of the > adjustment transaction if Alice has unspent funds in the channel. > > Then the n cycles would only require n+1 blockchain transactions: 1 to > initially open the channel, 1 each time the channel funding is adjusted > (total n-1), and 1 to finally close the channel. This is a significant > reduction in the number of blockchain transactions required, approaching > 50% in the limit as n approaches infinity. > > What about blockchain transaction fees? I've done the analysis, but it's > quite long (several conditions and dozens of combinations of conditions to > consider), so I won't include it here now. I will included it in another > post if anyone is interested and doesn't do the analysis for themselves. > > The bottom line of the analysis is that the number of inputs and the > number of outputs in the funding adjustment transaction are each never > greater than the sum of the number of inputs and the number of outputs, > respectively, in the channel opening and closing transactions that the > adjustment transaction replaces. > > Thus the adjustment transaction is: > - never bigger than the closing and re-opening transactions put together, > - sometimes smaller, and > - occasionally significantly smaller. > > And there's only one transaction instead of two, so ya always save on the > transaction header! :-) > > Thus, the fee paid for the adjustment transaction, assuming the same fee > rate for all the transactions, is: > - never more than the sum of the fees paid for the closing and re-opening > transactions, > - sometimes less, and > - occasionally significantly less. > > This reduction in fees is by an additive amount. > > Because the channel remains open while waiting for the adjustment > transaction to confirm, there may be less urgency in having it confirm. So > it's fee rate can be reduced, reducing the fee paid by a multiplicative > amount. > > Combined, these two effects lead to a reduction in total fees paid for > operating the channel, sometimes a significant reduction. > > Comments expected and welcome. > > If this high-level, bare-bones idea to seen to be worthy of further > consideration, I would like to work with the community to flesh out a > detailed specifi
