Nostr notes by fiatjaf [ARCHIVE]

📅 Original date posted:2021-09-21 📝 Original message: ...

2023-06-09T13:03:49Z

In reply to nevent1q…n4fv
_________________________

📅 Original date posted:2021-09-21
📝 Original message:
Indeed, sorry, I misunderstood it because I read AMP/keysend and assumed
you were talking about payer-generated preimage.
It doesn't help that "payer" and "payee" are so similar words.

So yes, I agree very much.

I also think the part about including the order details inside the TLV
would be very good to have.

I would say, however, that these are two separate proposals:

1. implementations should expose a "stateless invoice" API for receiving
using the payment_secret;
2. when sending, implementations should attach a TLV record with encoded
order details.

Of these, 1 is very simple to do and do not require anyone to cooperate, it
just works.

2 requires full network compatibility, so it's harder. But 2 is also very
much needed otherwise the payee has to keep track of all the invoice ids
related to the orders they refer to, right? But I think just having 1
already improves the situation a lot, and there are application-specific
workarounds that can be applied for 2 (having a fixed, hardcoded set of
possible orders, encoding the order very minimally in the payment secret or
route hint, storing order details on redis for only 3 minutes and using
lnurlpay to reduce the delay between invoice issuance and user confirmation
to zero, and so on).

On Tue, Sep 21, 2021 at 9:41 AM Joost Jager <joost.jager at gmail.com> wrote:

> On Tue, Sep 21, 2021 at 2:05 PM fiatjaf <fiatjaf at gmail.com> wrote:
>
>> What if instead of the payer generating the preimage the payee could
>> generate stateless invoices? Basically just use some secret to compute the
>> preimage upon receiving the HTLC, for example:
>>
>
> Maybe my explanation wasn't clear enough, but this is exactly what I am
> proposing. The payee generates a stateless invoice and gives it to the
> payer.
>
>
>> 1. Payer requests an invoice.
>> 2. Payee computes hash = sha256(hmac(local_secret,
>> arbitrary_invoice_id)), then encodes arbitrary_invoice_id into the invoice
>> somehow.
>> 3. Payer sends payment with arbitrary_invoice_id as tlv_record_a.
>> 4. Upon receiving the HTLC, payee computes preimage = hmac(local_secret,
>> tlv_record_a) and resolves it.
>>
>
> One way to do this that I tried to describe in the initial post is via the
> payment_secret. This is already an arbitrary invoice id that is already
> sent as a tlv record.
>
>
>> I've implemented such a scheme on @lntxbot, but it required low level
>> code in a c-lightning plugin and a hack with route hints: since TLV
>> payloads were not an option (as payers wouldn't know how to send them) I've
>> used a "shadow" route hint to a private channel that didn't exist, so
>> preimage was generated on the payee using preimage = hmac(local_secret,
>> next_channel_scid).
>>
>
> Clever workaround.
>
> Joost
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/5b0b8328/attachment-0001.html>;

📅 Original date posted:2021-09-21 📝 Original message: What ...

2023-06-09T13:03:49Z

In reply to nevent1q…dsk9
_________________________

📅 Original date posted:2021-09-21
📝 Original message:
What if instead of the payer generating the preimage the payee could
generate stateless invoices? Basically just use some secret to compute the
preimage upon receiving the HTLC, for example:

1. Payer requests an invoice.
2. Payee computes hash = sha256(hmac(local_secret, arbitrary_invoice_id)),
then encodes arbitrary_invoice_id into the invoice somehow.
3. Payer sends payment with arbitrary_invoice_id as tlv_record_a.
4. Upon receiving the HTLC, payee computes preimage = hmac(local_secret,
tlv_record_a) and resolves it.

I've implemented such a scheme on @lntxbot, but it required low level code
in a c-lightning plugin and a hack with route hints: since TLV payloads
were not an option (as payers wouldn't know how to send them) I've used a
"shadow" route hint to a private channel that didn't exist, so preimage was
generated on the payee using preimage = hmac(local_secret,
next_channel_scid).

If however node implementations could provide such a thing it would reduce
database requirements and improve the lives of application developers very
much.

On Tue, Sep 21, 2021 at 7:09 AM Joost Jager <joost.jager at gmail.com> 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 reconstruct the preimage
> according to the formula above. At this point, all data is available to do
> so. When H(preimage) indeed matches the htlc hash, they can settle the
> payment knowing that this is an order that they committed to earlier.
> Settling could be implemented as a just-in-time inserted invoice to keep
> the diff small.
>
> The preimage is returned to the sender and serves as a proof of payment.
>
> Resilience
>
> To me it seems that stateless invoices can be a relatively simple way to
> improve the resiliency of systems that deal with lightning invoices.
> Unlimited amounts of invoices can be generated without worrying about
> storage or memory, no matter if the requests are due to popularity of a
> service or a deliberate dos attack.
>
> Interested to hear your thoughts.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/997189bc/attachment.html>;

📅 Original date posted:2019-08-05 📝 Original message: Thank ...

2023-06-09T12:55:49Z

In reply to nevent1q…a66k
_________________________

📅 Original date posted:2019-08-05
📝 Original message:
Thank you very much. These were very clarifying answers and ramblings.

On Monday, August 5, 2019, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning fiatjaf,
>
>> No. My question was more like why does Alice decide to build a route
that for through T1 and RT2 and not only through one trampoline router she
knows.
>
> If Alice only always used one trampoline node, then the trampoline node
can assume the next hop is always the payee, and thus record who the payee
is (eroding privacy).
> If Alice uses two, then a trampoline node would have a 50/50 chance of
knowing who the final payee is, reducing the privacy erosion.
>
> Similarly, onion routing over Tor typically passes through 3 "trampoline"
nodes before going to the actual site being accessed.
>
>>
>> That makes sense you me in the context of ZmnSCPxj's virtual space idea,
but not necessarily in the current network conditions. You also said we're
going to need some hierarchy, but what it's that? Is it required?
>
> I believe in the future we will see a public network that is too large to
fit on most devices available to most people.
> We may or may not want to have such an enormous network, but the cost of
advertising a public channel is the same as the cost of creating a
non-public channel, thus there is no incentive for random end-user nodes to
*not* publish their channels, and incentive to publish (there is a tiny but
non-zero chance of being routed through, especially as local-area
specializations like JIT-Routing get implemented).
>
> Thus, I believe it is eventually required that we hierarchicalize how we
store information, with a "myopic" detailed channel map and a "rough"
global map with just trampoline-payee association mappings.
> I think it is best for each payer to define its own hierarchy or split,
preferentially with some random component.
>
> One might consider, however, that my ramblings are too indefinite and it
would be better to see the network as it evolves.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190805/85da457a/attachment.html>;

📅 Original date posted:2021-08-08 📝 Original message: For ...

2023-06-09T12:40:45Z

In reply to nevent1q…gcwh
_________________________

📅 Original date posted:2021-08-08
📝 Original message:
For the Lightning point, even if the dust limit was removed Lightning
would still be trimming any HTLCs below the amount they cost to redeem
in fees, so that wouldn't make any difference.

Nonetheless I think reason 1 should be enough.

2021-08-08 11:52 (GMT-07:00), Jeremy <jlrubin at mit.edu> said:
> We should remove the dust limit from Bitcoin. Five reasons:
> 1) it's not our business what outputs people want to create
> 2) dust outputs can be used in various authentication/delegation smart
> contracts
> 3) dust sized htlcs in lightning (
> https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light
> ) force channels to operate in a semi-trusted mode which has implications
> (AFAIU) for the regulatory classification of channels in various jurisdictions;
> agnostic treatment of fund transfers would simplify this (like getting a 0.01
> cent dividend check in the mail)
> 4) thinly divisible colored coin protocols might make use of sats as value
> markers for transactions.
> 5) should we ever do confidential transactions we can't prevent it without
> compromising privacy / allowed transfers
> The main reasons I'm aware of not allow dust creation is that:
> 1) dust is spam
> 2) dust fingerprinting attacks
> 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by well
> behaved wallets to not redeem outputs that cost more in fees than they are
> worth.
> cheers,
> jeremy
> --
> @JeremyRubin_______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

📅 Original date posted:2021-06-30 📝 Original message: hello ...

2023-06-09T12:40:23Z

In reply to nevent1q…k3wk
_________________________

📅 Original date posted:2021-06-30
📝 Original message:
hello René,

I think the idea of having separate standards is good because we can
keep the core spec mandatory and other things optional.

Since the core spec, defined by the BOLTs, is mandatory, it's better
if it's as small as possible, basically barely enough to allow peers
to talk to each other and open a channel, then define what an HTLC is
and the basic payment flow.

All the rest is optional. The BOLTs themselves encourage
experimentation by having TLVs, rules for optional and experimental
message type numbers and so on.

And then it doesn't make sense to put optional things in the BOLTs
otherwise no one will be spec-compliant anymore and it will cause
confusion.

Some things, like splicing and dual-funded channels could be created
as blips and after everybody had implemented them moved to the BOLTs,
other things, like the podcast tipping protocol, cannot.

Still, it is better to have a spec for the podcast tipping protocol
than to not have, or to have it hidden somewhere. It makes it more
open and easier for everyone.

Ultimately I think dual-funded channels, trampoline routing and other
lower level things should still be kept out of the BOLTs as long as
they are optional. While things like splicing and blinded paths seem
to be more like things that should enforced. This is my opinion, but I
think it's good to have this clear distinction.

Finally, a list of other things that deserve a spec so they are made
standard and interoperable across wallets and services:

1. keysend
2. AMP
3. hosted channels
4. trampoline routing v1
5. trampoline routing v2
6. turbo channels
7. podcast tipping protocol
8. dual-funding
9. on-demand channels
10. sphinx chat messaging thing
11. private routing as done by immortan
12. alternative graph for unannounced channels as done by immortan
13. lnurl-withdraw
14. lnurl-pay
15. lnurl-channel
16. bitcoin-liquid lightning bridge
17. I thought I had more but apparently I forgot

So we have to hunt these people down and make them submit specs.

---
fiatjaf

2021-06-30 16:35 (GMT+02:00), "René Pickhardt via Lightning-dev"
<lightning-dev at lists.linuxfoundation.org> said:
> Hey everyone,
> just for reference when I was new here (and did not understand the processes
> well enough) I proposed a similar idea (called LIP) in 2018 c.f.:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
> I wonder what exactly has changed in the reasoning by roasbeef which I will
> repeat here:
> We already have the equiv of improvement proposals: BOLTs. Historically new
> standardization documents are proposed initially as issues or PR's when
> ultimately accepted. Why do we need another repo?
> As far as I can tell there was always some form of (invisible?) barrier to
> participate in the BOLTs but there are also new BOLTs being offered:
> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
> and topics to be included like:
> * dual funding
> * splicing
> * the examples given by Ryan
> I don't see how a new repo would reduce that barrier - Actually I think it
> would even create more confusion as I for example would not know where
> something belongs. That being said I think all the points that are addressed in
> Ryan's mail could very well be formalized into BOLTs but maybe we just need to
> rethink the current process of the BOLTs to make it more accessible for new
> ideas to find their way into the BOLTs? One thing that I can say from answering
> lightning-network questions on stackexchange is that it would certainly help if
> the BOLTs where referenced on lightning.network web page and in the whitepaper
> as the place to be if one wants to learn about the Lightning Network
> with kind regards Rene
> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev wrote:
>
>
>
> Hi all,
>
>
>
>
> The recent thread around zero-conf channels [1] provides an opportunity to
> discuss how the BOLT process handles features and best practices that
> arise in the wild vs. originating within the process itself. Zero-conf
> channels are one of many LN innovations on the app layer that have
> struggled to make their way into the spec. John Carvalho and Bitrefill
> launched Turbo channels in April 2019 [2], Breez posted their solution to
> the mailing list for feedback in August 2020 [3], and we know at least
> ACINQ and Muun (amongst others) have their own implementations. In an
> ideal world there would be a descriptive design document that the app
> layer implementers had collaborated on over the years that the spec group
> could then pick up and merge into the BOLTs now that the feature is deemed
> spec-worthy.
>
>
>
>
> Over the last couple of months, we have discussed the idea of adding a
> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
> members of the community, and have received positive feedback from both
> app layer and protocol devs. This would not affect the existing BOLT
> process at all, but simply add a place for app layer best practices to be
> succinctly described and organized, especially those that require
> coordination. These features are being built outside of the BOLT process
> today anyways, so ideally a bLIP process would bring them into the fold
> instead of leaving them buried in old ML posts or not documented at all.
>
>
>
>
> Some potential bLIP ideas that people have mentioned include: each lnurl
> variant, on-the-fly channel opens, AMP, dynamic commitments, podcast
> payment metadata, p2p messaging formats, new pathfinding heuristics,
> remote node connection standards, etc.
>
>
>
>
> If the community is interested in moving forward, we've started a branch
> [5] describing such a process. It's based on BIP-0002, so not trying to
> reinvent any wheels. It would be great to have developers from various
> implementations and from the broader app layer ecosystem volunteer to be
> listed as editors (basically the same role as in the BIPs).
>
>
>
>
> Looking forward to hearing your thoughts!
>
>
>
>
> Best,
> Ryan
>
>
>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>
>
>
>
> [2]
> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>
>
>
>
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>
>
>
>
> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =
> Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>
>
>
>
> [5]
> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> --
> https://www.rene-pickhardt.de_______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>