Re: [Lightning-dev] Base AMP
This shouldn't be problem, as the invoice will already indicate that the node supports BaseAMP. If you have a reason to not reveal that you support BAMP for certain invoices, you'll just not specify it in the invoice, and act non-BAMPy when receiving payments to this payment hash. Of course, this will also be opt-in for both sides and won't affect existing nodes in any way. Cheers, Johan On Wed, Nov 21, 2018 at 11:54 PM Rusty Russell wrote: > Johan Torås Halseth writes: > > Seems like we can restrict the changes to BOLT11 by having the receiver > > assume NAMP for incoming payments < invoice_amount. (with some timeout of > > course, but that would need to be the case even when the sender is > > signalling NAMP). > > This would effectively become a probe for Base AMP; if you get a partial > payment error, it's because the recipient didn't support Base AMP. > > Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then > it's explicitly opt-in for both sides and doesn't affect existing nodes > in any way. > > Cheers, > Rusty. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] lookupinvoice
Sarat G writes: > Hi, > > I'm been working on the LN repo for a while now. I would like to know if > there is any way that a payee can lookup the invoice it gets paid, i.e > similar to the 'lookupinvoice' command as provided by the lnd(Golang). Hi Sarat, I'm confused; "the LN repo" is ambigious, as there are several, each with their own places to ask questions: https://github.com/ACINQ/eclair-wallet/ https://github.com/ElementsProject/lightning https://github.com/LightningNetwork/lnd/ https://github.com/nayutaco/ptarmigan https://github.com/rust-bitcoin/rust-lightning Then of course there's the spec repo as well, which guides us all: https://github.com/lightningnetwork/lightning-rfc But AFAICT (though your question is off-topic for this list): lnd has lookupinvoice which looks up by hash[1] eclair has checkpayment which looks up by hash or bolt11[2] c-lightning has listinvoices which can lookup by label[3], or wait(any)invoice[4] which is used for polling. Would love someone to write a rosetta stone for the different APIs! Cheers, Rusty. [1] https://api.lightning.community/#lookupinvoice [2] https://github.com/ACINQ/eclair/wiki/API [3] https://github.com/ElementsProject/lightning/blob/master/doc/lightning-listinvoices.7.txt [4] https://github.com/ElementsProject/lightning/blob/master/doc/lightning-waitanyinvoice.7.txt ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
Matt Corallo writes: > Hmm, are we willing to consider CLTV sufficient? In case you have two > HTLCs, one of medium-small value that has a low CLTV and one of high > value that has a higher CLTV, you could potentially use the soon-CLTV to > delay the commitment transaction somewhat further if you broadcast it > right as the sooner HTLC expires. I think you haven't got the commitment tx onchain by the time the HTLC expires, you're already in trouble. But since there's no script length difference, it *is* simpler to prepend `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the start of each script. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
Indeed, this change assumes (a) the change in relay policy around CPFP that is discussed on this thread, and (b) some kind of (at least very basic) package relay in Bitcoin Core. (a) requires some discussion, but people seem at least not entirely against it when I've discussed it with people, and should be easy to implement, (b) requires a bunch more work, but has been a longstanding goal for a while. Matt On 11/25/18 6:47 PM, David A. Harding wrote: On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote: I'm also starting to implement this, to see what I missed! - Feerate is fixed at 253 [satoshis per 1,000 weight] IIUC, this is just over Bitcoin Core's default minimum relay fee of 0.1000 BTC/vByte. That works right now, as mempools are nowhere near full, but if they fill up again and the BIP133 feefilters are increased by any amount, nodes will no longer relay transactions with minimum feerates. In that case, how does the commitment transaction get relayed in order for its `to_*_pushme` outputs to be spent for CPFP fee bumping?[1] There's currently some text in the PR about using sighash_single|sighash_anyonecanpay for use with RBF, but I don't think that can apply to spending the commitment transaction, as that would allow not just adding new inputs and outputs, but also removing all but the 'singled' output (allowing theft of its value). -Dave [1] I don't think Bitcoin Core currently relays transaction packages consisting of parents below the relay fee limit and children sufficiently above the limit to pay for their parents. This has certainly been discussed, so maybe I'm wrong and it is available or maybe it'll be available in the future. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote: > I'm also starting to implement this, to see what I missed! > > - Feerate is fixed at 253 [satoshis per 1,000 weight] IIUC, this is just over Bitcoin Core's default minimum relay fee of 0.1000 BTC/vByte. That works right now, as mempools are nowhere near full, but if they fill up again and the BIP133 feefilters are increased by any amount, nodes will no longer relay transactions with minimum feerates. In that case, how does the commitment transaction get relayed in order for its `to_*_pushme` outputs to be spent for CPFP fee bumping?[1] There's currently some text in the PR about using sighash_single|sighash_anyonecanpay for use with RBF, but I don't think that can apply to spending the commitment transaction, as that would allow not just adding new inputs and outputs, but also removing all but the 'singled' output (allowing theft of its value). -Dave [1] I don't think Bitcoin Core currently relays transaction packages consisting of parents below the relay fee limit and children sufficiently above the limit to pay for their parents. This has certainly been discussed, so maybe I'm wrong and it is available or maybe it'll be available in the future. signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
