Re: [Lightning-dev] Stateless invoices with proof-of-payment
Hi Joost, > The conventional approach is to create a lightning invoice on a node and > store the invoice together with order details in a database. If the order > then goes unfulfilled, cleaning processes remove the data from the node > and database again. > The problem with this setup is that it needs protection against unbounded > generation of payment requests. There are solutions for that such as rate > limiting, but wouldn't it be nice if invoices can be generated without the > need to keep any state at all? Isn't this ultimately an engineering issue? How much exactly is "too much" in this case? Invoices are relatively small, and also don't even necessarily need to be ever written to disk assuming a slim expiration window. It's likely the case that a service can just throw everything in Redis and call it a day. In terms of rate limiting a service would likely already need to implement that on the API/service level to mitigate app level DoS attacks. As far as pre-images go, this can already be "stateless" by generating a single random seed (storing that somewhere w/ a counter likely) and then using shachain or elkrem to deterministically generate payment hashes. You can then either use the payment_addr/secret to index into the hash chain, or have the user send some counter extracted from the invoice as a custom record. Similar schemes have been proposed in the past to support "offline" vending machine payments. Taking it one step further, the service could maintain a unique elkrem/shachain state for each unique user, which would then allow them to also collapse the pre-image into the hash chain, which lets them save space and be able to reproduce a given "proof that someone in the world paid" (that no service/wallet seems to accept/generate in an automated/standardized manner) statement dynamically. -- Laolu On Tue, Sep 21, 2021 at 3:08 AM Joost Jager wrote: > Problem > > One of the qualities of lightning is that it can provide light-weight, > no-login payments with minimal friction. Games, paywalls, podcasts, etc can > immediately present a QR code that is ready for scan and pay. > > Optimistically presenting payment requests does lead to many of those > payment requests going unused. A user visits a news site and decides not to > buy the article. The conventional approach is to create a lightning invoice > on a node and store the invoice together with order details in a database. > If the order then goes unfulfilled, cleaning processes remove the data from > the node and database again. > > The problem with this setup is that it needs protection against unbounded > generation of payment requests. There are solutions for that such as rate > limiting, but wouldn't it be nice if invoices can be generated without the > need to keep any state at all? > > Stateless invoices > > What would happen if a lightning invoice is only generated and stored > nowhere on the recipient side? To the user, it won't make a difference. > They would still scan and pay the invoice. When the payment arrives at the > recipient though, two problems arise: > > 1. Recipient doesn't know whom or what the payment is for. > > This can be solved by attaching additional custom tlv records to the htlc. > On the wire, this is all arranged for. The only missing piece is the > ability to specify additional data for that custom tlv record in a bolt11 > invoice. One way would be to define a new tagged field for this in which > the recipient can encode the order details. > > An alternative is to use the existing invoice description field and simply > always pass that along with the htlc as a custom tlv record. > > A second alternative that already works today is to use part (for example > 16 out of 32 bytes) of the payment_secret (aka payment address) to encode > the order details in. This assumes that the secret is still secret enough > with reduced entropy. Also there may not be enough space for every > application. > > 2. Recipient doesn't know the preimage that is needed to settle the > htlc(s). > > One option is to use a keysend payment or AMP payment. In that case, the > sender includes the preimage with the htlc. Unfortunately this doesn't > provide the sender with a proof of payment that they'd get with a regular > lightning payment. > > An alternative solution is to use a deterministic preimage based on a > (recipient node key-derived) secret, the payment secret and other relevant > properties. This allows the recipient to derive the same preimage twice: > Once when the lightning invoice is generated and again when a payment > arrives. > > It could be something like this: > > payment_secret = random > preimage = H(node_secret | payment_secret | payment_amount | > encoded_order_details) > invoice_hash = H(preimage) > > The sender sends an htlc locked to invoice_hash for payment_amount and > passes along payment_secret and encoded_order_details in a custom tlv > record. > > When the recipient receives the htlc, they
Re: [Lightning-dev] Opening balanced channels using PSBT
Hi Ole,
It's generally known that one can use out of band transaction construction,
and the push_amt feature in the base funding protocol to simulate dual
funded channels.
The popular 'balanceofsatoshis' tool has a command that packages up the
interaction (`open-balanced-channel`) into an easier to use format, IIRC it
uses key send to ask a peer if they'll accept one and negotiate some of the
params.
The one thing you need to take mind of when doing this manually is that by
default lnd will only lock the UTXOs allocated for the funding attempt for a
few minutes. As a result, you need to make sure the process is finalized
during that interval or the UTXOs will be unlocked and you risk accidentally
double spending yourself.
Lightning Pool also uses this little trick to allows users to purchase
channels that are 50/50 balanced, and also purchase channel leases _for_ a
third party (called sidecar channels) to help on board them onto Lightning:
https://lightning.engineering/posts/2021-05-26-sidecar-channels/. Compared
to the above approaches, the process can be automatically batched w/ other
channels created in that epoch, and uses traits of the Pool account system
to make things atomic.
Ultimately, the balanced-ness of a channel is a transitory state (for
routing nodes, it's great for on-boarding end-users) and opening channels
like these only serves to allow the channel to _start_ in the state. If your
fees and channel policies aren't set accordingly, then it's possible that a
normal payment or balance flow shifts the channel away from equilibrium
shortly after the channel is open.
-- Laolu
On Tue, Sep 21, 2021 at 10:30 PM Ole Henrik Skogstrøm <
oleskogst...@gmail.com> wrote:
> Hi
>
> I have found a way of opening balanced channels using LND's psbt option
> when opening channels. What I'm doing is essentially just joining funded
> PSBTs before signing and submitting them. This makes it possible to open a
> balanced channel between two nodes or open a ring of balanced channels
> between multiple nodes (ROF).
>
> I found this interesting, however I don't know if this is somehow unsafe
> or for some other reason a bad idea. If not, then it could be an
> interesting alternative to only being able to open unbalanced channels.
>
> To do this efficiently, nodes need to collaborate by sending PSBTs back
> and forth to each other and doing this manually is a pain, so if this makes
> sense to do, it would be best to automate it through a client.
>
> --
> --- Here is an example of the complete flow for a single channel:
> --
>
> ** Node A: generates a new address and sends address to Node B *(lncli
> newaddress p2wkh)
>
> ** Node A starts an Interactive channel **open** to Node B* *using psbt*
> (lncli openchannel --psbt 200 100)
>
> ** Node A funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"":0.02}]')
>
> ** Node B funds the refund transaction to Node A and sends PSBT back to
> Node A (*bitcoin-cli walletcreatefundedpsbt []
> '[{"":0.01}]')
>
> * *Node A joins the two PSBTs and sends it back to Node B (*bitcoin-cli
> joinpsbts '["", ""]')
>
> ** Node B verifies the content and signs the joined PSBT before sending it
> back to Node A *(bitcoin-cli walletprocesspsbt )
>
> ** Node A: Verifies the content and signs the joined PSBT *(bitcoin-cli
> walletprocesspsbt )
>
> ** Node A: Completes channel open by publishing the fully signed PSBT*
>
>
> --
> --- Here is an example of the complete flow for a ring of channels between
> multiple nodes:
> --
>
> ** Node A starts an Interactive open channel to Node B using psbt* (lncli
> openchannel --psbt --no_publish 200 100)
> ** Node A funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"":0.02}]')
>
> ** Node B starts an Interactive open channel to Node C using psbt* (lncli
> openchannel --psbt --no_publish 200 100)
> ** Node B funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"":0.02}]')
>
> ** Node C starts an Interactive open channel to Node A using psbt* (lncli
> openchannel --psbt 200 100)
> ** Node C funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"":0.02}]')
>
> ** Node B and C sends Node A their PSBTs*
>
> ** Node A joins all the PSBTs* (bitcoin-cli joinpsbts
> '["", "",
> ""]')
>
> Using (bitcoin-cli walletprocesspsbt ):
>
>
>
> ** Node A verifies and signs the PSBT and sends it to Node B (1/3
> signatures)* Node B verifies and signs the PSBT and sends it to Node C (2/3
> signatures)* Node C verifies and signs the PSBT (3/3 signatures) before
> sending it to Node A and B.*
>
>
> ** Node A completes channel open (no_publish)* Node B completes channel
> open (no_publish)* Node C completes channel open and publishes the
> transaction.*
>
> --
> Ole Henrik Skogstrøm
>
> ___
> Lightning-dev mailing list
>
Re: [Lightning-dev] Dropping Tor v2 onion services from node_announcement
Earlier this week I was helping a user debug a Tor related issue, and realized (from the logs) that some newer Tor clients are already refusing to connect out to v2 onion services. On the lnd side, I think we'll move to disallow users creating a v2 onion service in our next major release (0.14), and also possibly "upgrade" them to a v3 onion service if their node supports it. I've made a tracking issue here: https://github.com/lightningnetwork/lnd/issues/5771 I ran a naive script to gauge how much of the network is using Tor generally, and also v2 onion services extract the following stats: ``` num nodes: 12844 num tor: 8793 num num v2: 66 num num v3: 8777 ``` This counts advertised addresses total, so it likely over estimates, so you can treat this as an upper bound. Thankfully only 60 or so v2 addresses seem to be even _advertised_ on the network, so I don't think this'll cause much disruption. Another interesting tidbit here is that: _over half_ of all advertised addresses on the network today are onion services. I wonder how the rise of onion service usage (many nodes being tor-only) has affected: e2e payment latency, general connection stability, and gossip announcement propagation. In terms of actions we need to take at the spec level, it's likely enough to amend the section on addrs in the node_announcement message to advise implementations to _ignore_ the v2 addr type. -- Laolu On Tue, Jun 1, 2021 at 3:19 PM darosior via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Hi all, > > It's been almost 9 months since Tor v2 hidden services have been > deprecated. > The Tor project will drop v2 support in about a month in the latest > release. It will then be entirely be dropped from all supported releases by > October. > More at https://blog.torproject.org/v2-deprecation-timeline . > > Bitcoin Core defaults to v3 since 0.21.0 ( > https://bitcoincore.org/en/releases/0.21.0/) and is planning to drop the > v2 support for 0.22 (https://github.com/bitcoin/bitcoin/pull/22050), > which means that v2 onions will gradually stop being gossiped on the > Bitcoin network. > > I think we should do the same for the Lightning network, and the timeline > is rather tight. Also, the configuration is user-facing (as opposed to > Bitcoin Core, which generates ephemeral services) which i expect to make > the transition trickier. > C-lightning is deprecating the configuration of Tor v2 services starting > next release, according to our deprecation policy we should be able to > entirely drop its support 3 releases after this one, which should be not so > far from the October deadline. > > Opinions? What is the state of other implementations with regard to Tor v2 > support? > > Antoine > ___ > 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] Opening balanced channels using PSBT
Hi,
This is exactly what the dual funding proposal provides:
https://github.com/lightningnetwork/lightning-rfc/pull/851
Cheers,
Bastien
Le mer. 22 sept. 2021 à 07:29, Ole Henrik Skogstrøm
a écrit :
> Hi
>
> I have found a way of opening balanced channels using LND's psbt option
> when opening channels. What I'm doing is essentially just joining funded
> PSBTs before signing and submitting them. This makes it possible to open a
> balanced channel between two nodes or open a ring of balanced channels
> between multiple nodes (ROF).
>
> I found this interesting, however I don't know if this is somehow unsafe
> or for some other reason a bad idea. If not, then it could be an
> interesting alternative to only being able to open unbalanced channels.
>
> To do this efficiently, nodes need to collaborate by sending PSBTs back
> and forth to each other and doing this manually is a pain, so if this makes
> sense to do, it would be best to automate it through a client.
>
> --
> --- Here is an example of the complete flow for a single channel:
> --
>
> ** Node A: generates a new address and sends address to Node B *(lncli
> newaddress p2wkh)
>
> ** Node A starts an Interactive channel **open** to Node B* *using psbt*
> (lncli openchannel --psbt 200 100)
>
> ** Node A funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"":0.02}]')
>
> ** Node B funds the refund transaction to Node A and sends PSBT back to
> Node A (*bitcoin-cli walletcreatefundedpsbt []
> '[{"":0.01}]')
>
> * *Node A joins the two PSBTs and sends it back to Node B (*bitcoin-cli
> joinpsbts '["", ""]')
>
> ** Node B verifies the content and signs the joined PSBT before sending it
> back to Node A *(bitcoin-cli walletprocesspsbt )
>
> ** Node A: Verifies the content and signs the joined PSBT *(bitcoin-cli
> walletprocesspsbt )
>
> ** Node A: Completes channel open by publishing the fully signed PSBT*
>
>
> --
> --- Here is an example of the complete flow for a ring of channels between
> multiple nodes:
> --
>
> ** Node A starts an Interactive open channel to Node B using psbt* (lncli
> openchannel --psbt --no_publish 200 100)
> ** Node A funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"":0.02}]')
>
> ** Node B starts an Interactive open channel to Node C using psbt* (lncli
> openchannel --psbt --no_publish 200 100)
> ** Node B funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"":0.02}]')
>
> ** Node C starts an Interactive open channel to Node A using psbt* (lncli
> openchannel --psbt 200 100)
> ** Node C funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"":0.02}]')
>
> ** Node B and C sends Node A their PSBTs*
>
> ** Node A joins all the PSBTs* (bitcoin-cli joinpsbts
> '["", "",
> ""]')
>
> Using (bitcoin-cli walletprocesspsbt ):
>
>
>
> ** Node A verifies and signs the PSBT and sends it to Node B (1/3
> signatures)* Node B verifies and signs the PSBT and sends it to Node C (2/3
> signatures)* Node C verifies and signs the PSBT (3/3 signatures) before
> sending it to Node A and B.*
>
>
> ** Node A completes channel open (no_publish)* Node B completes channel
> open (no_publish)* Node C completes channel open and publishes the
> transaction.*
>
> --
> Ole Henrik Skogstrøm
>
> ___
> 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
