Nostr notes by fiatjaf [ARCHIVE]

📅 Original date posted:2023-07-13 🗒️ Summary of this ...

2023-07-15T18:58:04Z

In reply to nevent1q…zwzh
_________________________

📅 Original date posted:2023-07-13
🗒️ Summary of this message: The author suggests asking developers of Lightning Network node implementations to support self-payment of invoices, which is currently not possible but would be a valuable feature for custodial Lightning service providers.
📝 Original message:
On Thu, Jul 13, 2023 at 3:47 AM David A. Harding <dave at dtrt.org> wrote:
> My question is whether you think it would be worthwhile to ask
> developers of the underlying LN node implementations you use to support
> self-payment of their own invoices (if they don't already).

As far as I know no Lightning node has this ability, which is very unfortunate.
If possible this should definitely be implemented. It would be the
biggest feature for custodial Lightning service providers of all kinds
since always.

📅 Original date posted:2021-12-20 📝 Original message: Hi ...

2023-06-09T13:04:55Z

In reply to nevent1q…kgw3
_________________________

📅 Original date posted:2021-12-20
📝 Original message:
Hi Joost,

On Mon, Dec 20, 2021 at 5:02 AM Joost Jager <joost.jager at gmail.com> wrote:

> Hi fiatjaf and peter,
>
> On Sat, Dec 18, 2021 at 2:08 PM fiatjaf <fiatjaf at gmail.com> wrote:
>
>> As a temporary solution, I suggest taking a look at
>> https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that
>> you can either provide
>> - a lone pubkey (to be used for manually identifying the payer later if
>> necessary);
>> - a domain-specific pubkey along with a signature of a challenge
>> provided by the receiver; or
>> - an unauthenticated name or email (for light things like donations for
>> which one may not care very much about cryptographic authentication).
>> And then you commit these things, whatever they are, inside the BOLT11
>> payment request using the 'h' tag.
>>
>
> Interesting read. I see it uses a signature, but is that a good idea? It
> could allow the receiver to prove to a 3rd party that the payment was made.
> I guess it depends on the application if that is desired or not. The more
> privacy conscious users would probably try to avoid committing to data via
> a signature.
>

Just to clarify:

For the lone pubkey method there are no privacy implications I think, since
it's just a random pubkey and can be used later only if needed in some
custom way.

For the signature method the privacy implications are close to none (unless
I'm missing something) because the key used to sign is (supposed to be)
generated by a method that makes it specific to the DNS domain of the
service being paid. Since this assumes an LNURL request that has a domain,
the key will be generated with something like `HMAC(domain, seed_key)` (the
specifics don't matter) so it will not be possible for anyone to relate
that signature to anyone. Only the receiver service will be able to relate
it to other payments (or logins) to that same exact service -- which can
prove quite handy in many cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211220/d98a888e/attachment.html>;

📅 Original date posted:2021-12-18 📝 Original message: Good ...

2023-06-09T13:04:54Z

In reply to nevent1q…wm3n
_________________________

📅 Original date posted:2021-12-18
📝 Original message:
Good morning, Joost.

As a temporary solution, I suggest taking a look at
https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that you
can either provide
- a lone pubkey (to be used for manually identifying the payer later if
necessary);
- a domain-specific pubkey along with a signature of a challenge provided
by the receiver; or
- an unauthenticated name or email (for light things like donations for
which one may not care very much about cryptographic authentication).
And then you commit these things, whatever they are, inside the BOLT11
payment request using the 'h' tag.

fiatjaf

On Fri, Dec 17, 2021 at 7:37 AM Joost Jager <joost.jager at gmail.com> wrote:

> Hello list,
>
> In Lightning we have a great scheme to protect the identity of the sender
> of a payment. This is awesome, but there are also use cases where opt-in
> sender authentication is desired.
>
> An example of such a use case is chat over lightning. If you receive a
> text message, you generally want to know whom it originates from. For
> whatsat [1], I added a custom record containing an ECDSA signature over
> `sender | recipient | timestamp | msg`. I believe other chat protocols on
> lightning use a similar construction.
>
> For regular payments however, sender authentication can be useful too. A
> donation for example doesn't always need to be anonymous. A donor may want
> to reveal themselves. In other cases, sender authentication can add a layer
> of protection against payments getting lost. It provides the receiver with
> another field that they can use to retrieve lost payment information.
>
> On the receiver side, sender authentication also creates new
> possibilities. A receiver could for example create an invoice that is
> locked to a specific source node.
>
> Also wanted to note that the sender identity doesn't need to be the actual
> node identity. It can also be an unrelated key that could for example be
> specific to the service that is being paid to. For example, one registers
> the public part of a dedicated key pair with an exchange and the exchange
> then only accepts deposits authenticated with that key.
>
> The reason for bringing this up on the list is that I wanted to see what
> people think is the best way to do it technically. The whatsat approach
> with an ECDSA signature doesn't look ideal to me because of the
> non-repudiation property. Also care needs to be taken that whatever data
> the sender includes, cannot be reused.
>
> Another option that I can think of is to derive a shared secret using ECDH
> with the sender and receiver node keys and then attach a custom record to
> the payment containing the sender node key and an HMAC of the payment hash
> using the shared secret as a key.
>
> I am sure there people better versed in cryptography than me who have an
> opinion on this. Thoughts?
>
> Joost
>
> [1] https://github.com/joostjager/whatsat
> _______________________________________________
> 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/20211218/014f1a00/attachment.html>;

📅 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:2021-09-12 📝 Original message: I ...

2023-06-09T13:03:43Z

In reply to nevent1q…eyes
_________________________

📅 Original date posted:2021-09-12
📝 Original message:
I think this is a good idea. A very simple change that can improve
usability.

Anyone can already do this today if they want, by just shoving data into
DNS records and telling people to confirm from there, but it would be nice
if it was standardized in a bLIP[0] just so everybody does it in the same
way.

Additionally there could be the reverse link in which nodes publish their
domain names as their alias and that is confirmed with the DNS record. Then
we'll finally be able to identify and trust the payee pubkeys in invoices!

[0]: https://github.com/lightningnetwork/lightning-rfc/pull/884

On Sun, Sep 12, 2021 at 8:02 PM Andy Schroder <info at andyschroder.com> wrote:

> Hello,
>
> We have the <pubkey>@host format for defining a connection to a LN node.
>
> I'm wondering if it makes any sense to create DNS records that apply to LN
> nodes to serve this same information? For example:
>
> - example.com. IN LN ln.example.com.
> - Allows assigning an alternate host name for the ln node for a
> domain, like an mail server has an MX record
> - example.com. IN TXT "LNpubkey=ybRK9h6OYmB3I4VroZBQogIadciFTw"
> - Allows storing the pubkey for the LN node in a DNS record
>
>
> If one didn't know the LN node for example.com, they could query the LN
> and TXT records and then find the information and make a connection using
> the familiar ybRK9h6OYmB3I4VroZBQogIadciFTw at ln.example.com format. This
> may be of interest because if someone wants to open a channel in advance to
> a company's LN node because they know they will be receiving an invoice
> from them in the future, and they want open a channel directly in order to
> ensure a good route (and they want the channel to be fully confirmed/opened
> by the time they receive the invoice). This could be particularly useful
> when dealing with machines in the physical world where you want an easy way
> to make a connection and channel to with a human readable string that is
> printed on the machine, but don't even want to deal with QR codes or NFC
> (for example, your desktop computer likely doesn't have either of those
> capabilities).
>
> Right now, the host names associated with LN nodes that are found using
> the peer to peer gossip are more on the honor system as I understand it. If
> these records existed, one could also validate the information found using
> the peer to peer gossip protocol.
>
> I do realize that the DNS root servers are governed by a centralized
> entity, so this approach has it's flaws, but we could consider it sort of
> complimentary to the peer to peer gossip protocol. DNS does have a nice
> scaling property in that it is hierarchically distributed, so it may be
> more efficient long term than every user having a full view of the LN via
> the gossip protocol in order to find the information needed, especially
> when we can replace the DNS root servers with something that is under
> decentralized control.
>
> lnurl-rfc seems to be doing a good job at creating workflows for payers
> and payees. However, I'm not sure if a definition like I've suggested above
> fits better in lnurl-rfc or as part of a BOLT.
>
>
> Let me know of your thoughts,
>
> --
> Andy Schroder
>
> _______________________________________________
> 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/20210912/5baf424b/attachment.html>;

📅 Original date posted:2021-08-28 📝 Original message: Good ...

2023-06-09T13:03:37Z

In reply to nevent1q…lg88
_________________________

📅 Original date posted:2021-08-28
📝 Original message:
Good morning,

I think we must stop closing channels to redeem trimmed HTLCs. It makes no
sense at all. It's bad for everybody, there is not a single upside to
closing a channel to redeem a trimmed HTLC.

(Please let me know if you don't agree with the above and what are the
things I'm missing.)

Now I understand this is not trivial, because if we just decide to stop
closing, what do we do? It's not obvious -- and actually it may not even be
possible to come up with a decent course of action.

I've written two or more blog posts trying to explain the issue (mostly to
myself)(see https://fiatjaf.com/401367e9.html and links), but skipping the
problem and going to the solutions directly, I see three possible
approaches (and they can all be implemented, in sequence, gradually):

0. Never have stalled HTLCs again (just kidding, this will never happen).
1. Just don't close. The channel keeps working. It's bad but at least you
don't have to close and open again (this is probably not safe against evil
people, but Lightning itself isn't anyway, right?).
2. Try to negotiate: if a peer knows it is at fault (for having been
offline while the HTLC expired, for example) it can eat the costs of that
HTLC just so the other side doesn't close the channel, and vice-versa (this
will probably not work in most situations, but may work in some, I don't
know enough to say).
3. Use an arbiter (this is my favorite): the two peers can agree on an
arbiter when creating the channel. The arbiter can act as a proxy for when
peers can't establish connection with each other; revoke/fulfill messages
can be sent to the arbiter if the other peer is unresponsive; the arbiter
has authority to say who sent each message at each time and therefore who
must get the sats in that HTLC. If a peer doesn't obey the arbiter's
decision the other must blacklist it forever. The arbiter can be anything:
another Lightning node, a set of Lightning nodes, Twitter or any
established internet service that allows arbitrary content to be published
in public, this mailing list etc.

(The arbiter idea may be sounding silly to you, but anything is better than
what we have now. In all the suggestions above, the fallback, worst case
scenario, is closing the channel. Today we live in the worst case scenario.)

Thank you for reading.

---
fiatjaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210828/96ce8ff9/attachment.html>;

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

2023-06-09T13:03:13Z

In reply to nevent1q…d0r8
_________________________

📅 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-07-01 📝 Original message: ...

2023-06-09T13:02:55Z

In reply to nevent1q…q67c
_________________________

📅 Original date posted:2021-07-01
📝 Original message:
Here's another feature which just appeared and would benefit from a
bLIP for compatibility:
https://twitter.com/SimpleBtcWallet/status/1410506889545359365

Atomic splitting of bills. A very small thing, but also very cool. I
can't imagine it fitting in the BOLTs at all.

2021-06-30 09:10 (GMT-05:00), Ryan Gentry via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> said:
> 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
>

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

2023-06-09T13:02:49Z

In reply to nevent1q…5hfs
_________________________

📅 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
>

📅 Original date posted:2019-11-14 📝 Original message: ...

2023-06-09T12:57:27Z

In reply to nevent1q…5n03
_________________________

📅 Original date posted:2019-11-14
📝 Original message:
Hello,

What happens between two peers is no business of others. They can do what
you said if they're cooperating, and many other dirty tricks. And that's
not a problem at all for other nodes.

The only thing they can't do for not is advertise a channel without telling
others where it was funded on the chain, but that's just for antispam
reasons (as other nodes must keep track of all announced channels) as far
as I know.

On Thursday, November 14, 2019, Subhra Mazumdar <
subhra.mazumdar1993 at gmail.com> wrote:
> Hello everyone,
> My doubt might be silly and apologies for the same. Suppose in a
payment channel network say 2 parties B and C are malicious, controlled by
same adversary. They had initially opened a channel of 1 BTC. But suppose
they get 3 transaction request will flow value of 0.4 BTC each. After 1st 2
transaction, B and C has capacity of 0.2 BTC. But what if BC reports an
incorrect residual balance thereby accepting the 3rd transaction. Who will
keep track of this capacity violation since no one is keeping track of this
residual value ? If this case is true, then parties might resort to such a
strategy opening a low value channel but still accepting multiple
transactions where the total payment value of all transaction exceeds
channel capacity. Please correct me if I am wrong.
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191114/2ebb3c12/attachment.html>;

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

2023-06-09T12:55:50Z

In reply to nevent1q…jq9f
_________________________

📅 Original date posted:2019-08-05
📝 Original message:
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.

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?

Anyway, I'm probably missing something, but another way of putting my
question would be: why does your example use 2 trampolines instead of 1?

On Monday, August 5, 2019, Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Good morning fiatjaf,
> This is a good question, I'm glad you asked.
> As:m ZmnSCPxj points out, Alice doesn't know. By not syncing the full
network graph, Alice has to accept
> "being in the dark" for some decisions. She is merely hoping that RT2 can
find a route to Bob. Note that
> it's quite easy to help Alice make informed decision by proving routing
hints in the invoice and in gossip
> messages (which we already do for "normal" routing).
> The graph today is strongly connected, so it's quite a reasonable
assumption (and Alice can easily retry
> with another choice of trampoline node if the first one fails - just like
we do today with normal payments).
> I fully agree with ZmnSCPxj though that in the future this might not be
true anymore. When/if the network
> becomes too large we will likely lose its strongly connected nature. When
that happens, the Lightning
> Network will need some kind of hierarchical / packet switched routing
architecture and we won't require
> trampoline nodes to know the whole network graph and be able to route to
mostly anyone.
> I argue that trampoline routing is a first step towards enabling that.
It's a good engineering trade-off between
> ease of implementation and deployment, fixing a problem we have today and
enabling future scaling for
> problems we'll have tomorrow. It's somewhat easy once we have trampoline
payments to evolve that to a
> system closer to the internet's packet switching infrastructure, so we'll
deal with that once the need for it
> becomes obvious.
> Does that answer your question?
> Cheers,
> Bastien
> Le sam. 3 août 2019 à 05:48, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
>>
>> Good morning fiatjaf,
>>
>> I proposed before that we could institute a rule where nodes are mapped
to some virtual space, and nodes should preferably retain the part of the
network graph that connects itself to those nodes near to it in this
virtual space (and possibly prefer to channel to those nodes).
>>
>>
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001959.html
>>
>> Thus Alice might **not** know that some route exists between T1 and T2.
>>
>> T1 itself might not know of a route from itself to T2.
>> But if T1 knows a route to T1.5, and it knows that T1.5 is nearer to T2
than to itself in the virtual space, it can **try** to route through T1.5
in the hope T1.5 knows a route from itself to T2.
>> This can be done if T1 can remove itself from the trampoline route and
replace itself with T1.5, offerring in exchange some of the fee to T1.5.
>>
>> Other ways of knowing some distillation of the public network without
remembering the channel level details are also possible.
>> My recent pointlessly long spam email for example has a section on
Hierarchical Maps.
>>
>>
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002095.html
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with ProtonMail Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Saturday, August 3, 2019 12:29 AM, fiatjaf <fiatjaf at alhur.es> wrote:
>>
>> > Ok, since you seem to imply each question is valuable, here's mine:
how does Alice know RT2 has a route to Bob? If she knows that, can she also
know T1 has a route to Bob? In any case, why can't she just build her small
onion with Alice -> T1 -> Bob? I would expect that to be the most common
case, am I right?
>> >
>> > On Friday, August 2, 2019, Bastien TEINTURIER <bastien at acinq.fr> wrote:
>> >
>> > > Good morning list,
>> > >
>> > > I realized that trampoline routing has only been briefly described
to this list (credits to cdecker and pm47 for laying
>> > > out the foundations). I just published an updated PR [1] and want to
take this opportunity to present the high level
>> > > view here and the parts that need a concept ACK and more feedback.
>> > >
>> > > Trampoline routing is conceptually quite simple. Alice wants to send
a payment to Bob, but she doesn't know a
>> > > route to get there because Alice only keeps a small area of the
routing table locally (Alice has a crappy phone,
>> > > damn it Alice sell some satoshis and buy a real phone). However,
Alice has a few trampoline nodes in her
>> > > friends-of-friends and knows some trampoline nodes outside of her
local area (but she doesn't know how to reach
>> > > them). Alice would like to send a payment to a trampoline node she
can reach and defer calculation of the rest of
>> > > the route to that node.
>> > >
>> > > The onion routing part is very simple now that we have
variable-length onion payloads (thanks again cdecker!).
>> > > Just like russian dolls, we simply put a small onion inside a big
onion. And the HTLC management forwards very
>> > > naturally.
>> > >
>> > > It's always simpler with an example. Let's imagine that Alice can
reach three trampoline nodes: T1, T2 and T3.
>> > > She also knows the details of many remote trampoline nodes that she
cannot reach: RT1, RT2, RT3 and RT4.
>> > > Alice selects T1 and RT2 to use as trampoline hops. She builds a
small onion that describes the following route:
>> > >
>> > > Alice -> T1 -> RT2 -> Bob
>> > >
>> > > She finds a route to T1 and builds a normal onion to send a payment
to T1:
>> > >
>> > > Alice -> N1 -> N2 -> T1
>> > >
>> > > In the payload for T1, Alice puts the small trampoline onion.
>> > > When T1 receives the payment, he is able to peel one layer of the
trampoline onion and discover that he must
>> > > forward the payment to RT2. T1 finds a route to RT2 and builds a
normal onion to send a payment to RT2:
>> > >
>> > > T1 -> N3 -> RT2
>> > >
>> > > In the payload for RT2, T1 puts the peeled small trampoline onion.
>> > > When RT2 receives the payment, he is able to peel one layer of the
trampoline onion and discover that he must
>> > > forward the payment to Bob. RT2 finds a route to Bob and builds a
normal onion to send a payment:
>> > >
>> > > RT2 -> N4 -> N5 -> Bob
>> > >
>> > > In the payload for Bob, RT2 puts the peeled small trampoline onion.
>> > > When Bob receives the payment, he is able to peel the last layer of
the trampoline onion and discover that he is
>> > > the final recipient, and fulfills the payment.
>> > >
>> > > Alice has successfully sent a payment to Bob deferring route
calculation to some chosen trampoline nodes.
>> > > That part was simple and (hopefully) not controversial, but it left
out some important details:
>> > >
>> > > 1. How do trampoline nodes specify their fees and cltv requirements?
>> > > 2. How does Alice sync the fees and cltv requirements for her
remote trampoline nodes?
>> > >
>> > > To answer 1., trampoline nodes needs to estimate a fee and cltv that
allows them to route to (almost) any other
>> > > trampoline node. This is likely going to increase the fees paid by
end-users, but they can't eat their cake and
>> > > have it too: by not syncing the whole network, users are trading
fees for ease of use and payment reliability.
>> > >
>> > > To answer 2., we can re-use the existing gossip infrastructure to
exchange a new node_update message that
>> > > contains the trampoline fees and cltv. However Alice doesn't want to
receive every network update because she
>> > > doesn't have the bandwidth to support it (damn it again Alice,
upgrade your mobile plan). My suggestion is to
>> > > create a filter system (similiar to BIP37) where Alice sends gossip
filters to her peers, and peers only forward to
>> > > Alice updates that match these filters. This doesn't have the issues
BIP37 has for Bitcoin because it has a cost
>> > > for Alice: she has to open a channel (and thus lock funds) to get a
connection to a peer. Peers can refuse to serve
>> > > filters if they are too expensive to compute, but the filters I
propose in the PR are very cheap (a simple xor or a
>> > > node distance comparison).
>> > >
>> > > If you're interested in the technical details, head over to [1].
>> > > I would really like to get feedback from this list on the concept
itself, and especially on the gossip and fee estimation
>> > > parts. If you made it that far, I'm sure you have many questions and
suggestions ;).
>> > >
>> > > Cheers,
>> > > Bastien
>> > >
>> > > [1] https://github.com/lightningnetwork/lightning-rfc/pull/654
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190805/7c8c7c1b/attachment-0001.html>;

📅 Original date posted:2019-08-08 📝 Original message: Ok, ...

2023-06-09T12:55:48Z

In reply to nevent1q…cq20
_________________________

📅 Original date posted:2019-08-08
📝 Original message:
Ok, here's another question/probably-bad-idea: how feasible is it for these
trampoline nodes to return the route they've calculated somehow to the
original caller so it can cache the route and use it without trampolines
the next time? I don't know if caching routes is a good way improve routing
overall in larger networks, but it seems to be working well for BLW[1]
currently and overall it does make sense: in day-to-day payments we tend to
pay the same people and stores over and over, rarely paying someone else
(but of course these rare cases are still very common to be ignored).

Anyway, I don't enough even to ask the question, but I guess it's
theoretically possible for some information to be returned along with the
preimage in the payment route, right?

There remains a question of if and why the trampoline nodes would be or not
interested in cheating Alice, sending back a bad route that favors them, or
not returning any route at all as that would undermine their profits as
trampolines.

[1]: https://lightning-wallet.com/what-does-olympus-server-do

On Friday, August 2, 2019, Bastien TEINTURIER <bastien at acinq.fr> wrote:

> Good morning list,
>
> I realized that trampoline routing has only been briefly described to this
> list (credits to cdecker and pm47 for laying
> out the foundations). I just published an updated PR [1] and want to take
> this opportunity to present the high level
> view here and the parts that need a concept ACK and more feedback.
>
> Trampoline routing is conceptually quite simple. Alice wants to send a
> payment to Bob, but she doesn't know a
> route to get there because Alice only keeps a small area of the routing
> table locally (Alice has a crappy phone,
> damn it Alice sell some satoshis and buy a real phone). However, Alice has
> a few trampoline nodes in her
> friends-of-friends and knows some trampoline nodes outside of her local
> area (but she doesn't know how to reach
> them). Alice would like to send a payment to a trampoline node she can
> reach and defer calculation of the rest of
> the route to that node.
>
> The onion routing part is very simple now that we have variable-length
> onion payloads (thanks again cdecker!).
> Just like russian dolls, we simply put a small onion inside a big onion.
> And the HTLC management forwards very
> naturally.
>
> It's always simpler with an example. Let's imagine that Alice can reach
> three trampoline nodes: T1, T2 and T3.
> She also knows the details of many remote trampoline nodes that she cannot
> reach: RT1, RT2, RT3 and RT4.
> Alice selects T1 and RT2 to use as trampoline hops. She builds a small
> onion that describes the following route:
>
> *Alice -> T1 -> RT2 -> Bob*
>
> She finds a route to T1 and builds a normal onion to send a payment to T1:
>
> *Alice -> N1 -> N2 -> T1*
>
> In the payload for T1, Alice puts the small trampoline onion.
> When T1 receives the payment, he is able to peel one layer of the
> trampoline onion and discover that he must
> forward the payment to RT2. T1 finds a route to RT2 and builds a normal
> onion to send a payment to RT2:
>
> *T1 -> N3 -> RT2*
>
> In the payload for RT2, T1 puts the peeled small trampoline onion.
> When RT2 receives the payment, he is able to peel one layer of the
> trampoline onion and discover that he must
> forward the payment to Bob. RT2 finds a route to Bob and builds a normal
> onion to send a payment:
>
> *RT2 -> N4 -> N5 -> Bob*
>
> In the payload for Bob, RT2 puts the peeled small trampoline onion.
> When Bob receives the payment, he is able to peel the last layer of the
> trampoline onion and discover that he is
> the final recipient, and fulfills the payment.
>
> Alice has successfully sent a payment to Bob deferring route calculation
> to some chosen trampoline nodes.
> That part was simple and (hopefully) not controversial, but it left out
> some important details:
>
> 1. How do trampoline nodes specify their fees and cltv requirements?
> 2. How does Alice sync the fees and cltv requirements for her remote
> trampoline nodes?
>
> To answer 1., trampoline nodes needs to estimate a fee and cltv that
> allows them to route to (almost) any other
> trampoline node. This is likely going to increase the fees paid by
> end-users, but they can't eat their cake and
> have it too: by not syncing the whole network, users are trading fees for
> ease of use and payment reliability.
>
> To answer 2., we can re-use the existing gossip infrastructure to exchange
> a new *node_update *message that
> contains the trampoline fees and cltv. However Alice doesn't want to
> receive every network update because she
> doesn't have the bandwidth to support it (damn it again Alice, upgrade
> your mobile plan). My suggestion is to
> create a filter system (similiar to BIP37) where Alice sends gossip
> filters to her peers, and peers only forward to
> Alice updates that match these filters. This doesn't have the issues BIP37
> has for Bitcoin because it has a cost
> for Alice: she has to open a channel (and thus lock funds) to get a
> connection to a peer. Peers can refuse to serve
> filters if they are too expensive to compute, but the filters I propose in
> the PR are very cheap (a simple xor or a
> node distance comparison).
>
> If you're interested in the technical details, head over to [1].
> I would really like to get feedback from this list on the concept itself,
> and especially on the gossip and fee estimation
> parts. If you made it that far, I'm sure you have many questions and
> suggestions ;).
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightningnetwork/lightning-rfc/pull/654
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190808/7986db4c/attachment.html>;

📅 Original date posted:2019-08-02 📝 Original message: Ok, ...

2023-06-09T12:55:47Z

In reply to nevent1q…dp20
_________________________

📅 Original date posted:2019-08-02
📝 Original message:
Ok, since you seem to imply each question is valuable, here's mine: how
does Alice know RT2 has a route to Bob? If she knows that, can she also
know T1 has a route to Bob? In any case, why can't she just build her small
onion with Alice -> T1 -> Bob? I would expect that to be the most common
case, am I right?

On Friday, August 2, 2019, Bastien TEINTURIER <bastien at acinq.fr> wrote:

> Good morning list,
>
> I realized that trampoline routing has only been briefly described to this
> list (credits to cdecker and pm47 for laying
> out the foundations). I just published an updated PR [1] and want to take
> this opportunity to present the high level
> view here and the parts that need a concept ACK and more feedback.
>
> Trampoline routing is conceptually quite simple. Alice wants to send a
> payment to Bob, but she doesn't know a
> route to get there because Alice only keeps a small area of the routing
> table locally (Alice has a crappy phone,
> damn it Alice sell some satoshis and buy a real phone). However, Alice has
> a few trampoline nodes in her
> friends-of-friends and knows some trampoline nodes outside of her local
> area (but she doesn't know how to reach
> them). Alice would like to send a payment to a trampoline node she can
> reach and defer calculation of the rest of
> the route to that node.
>
> The onion routing part is very simple now that we have variable-length
> onion payloads (thanks again cdecker!).
> Just like russian dolls, we simply put a small onion inside a big onion.
> And the HTLC management forwards very
> naturally.
>
> It's always simpler with an example. Let's imagine that Alice can reach
> three trampoline nodes: T1, T2 and T3.
> She also knows the details of many remote trampoline nodes that she cannot
> reach: RT1, RT2, RT3 and RT4.
> Alice selects T1 and RT2 to use as trampoline hops. She builds a small
> onion that describes the following route:
>
> *Alice -> T1 -> RT2 -> Bob*
>
> She finds a route to T1 and builds a normal onion to send a payment to T1:
>
> *Alice -> N1 -> N2 -> T1*
>
> In the payload for T1, Alice puts the small trampoline onion.
> When T1 receives the payment, he is able to peel one layer of the
> trampoline onion and discover that he must
> forward the payment to RT2. T1 finds a route to RT2 and builds a normal
> onion to send a payment to RT2:
>
> *T1 -> N3 -> RT2*
>
> In the payload for RT2, T1 puts the peeled small trampoline onion.
> When RT2 receives the payment, he is able to peel one layer of the
> trampoline onion and discover that he must
> forward the payment to Bob. RT2 finds a route to Bob and builds a normal
> onion to send a payment:
>
> *RT2 -> N4 -> N5 -> Bob*
>
> In the payload for Bob, RT2 puts the peeled small trampoline onion.
> When Bob receives the payment, he is able to peel the last layer of the
> trampoline onion and discover that he is
> the final recipient, and fulfills the payment.
>
> Alice has successfully sent a payment to Bob deferring route calculation
> to some chosen trampoline nodes.
> That part was simple and (hopefully) not controversial, but it left out
> some important details:
>
> 1. How do trampoline nodes specify their fees and cltv requirements?
> 2. How does Alice sync the fees and cltv requirements for her remote
> trampoline nodes?
>
> To answer 1., trampoline nodes needs to estimate a fee and cltv that
> allows them to route to (almost) any other
> trampoline node. This is likely going to increase the fees paid by
> end-users, but they can't eat their cake and
> have it too: by not syncing the whole network, users are trading fees for
> ease of use and payment reliability.
>
> To answer 2., we can re-use the existing gossip infrastructure to exchange
> a new *node_update *message that
> contains the trampoline fees and cltv. However Alice doesn't want to
> receive every network update because she
> doesn't have the bandwidth to support it (damn it again Alice, upgrade
> your mobile plan). My suggestion is to
> create a filter system (similiar to BIP37) where Alice sends gossip
> filters to her peers, and peers only forward to
> Alice updates that match these filters. This doesn't have the issues BIP37
> has for Bitcoin because it has a cost
> for Alice: she has to open a channel (and thus lock funds) to get a
> connection to a peer. Peers can refuse to serve
> filters if they are too expensive to compute, but the filters I propose in
> the PR are very cheap (a simple xor or a
> node distance comparison).
>
> If you're interested in the technical details, head over to [1].
> I would really like to get feedback from this list on the concept itself,
> and especially on the gossip and fee estimation
> parts. If you made it that far, I'm sure you have many questions and
> suggestions ;).
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightningnetwork/lightning-rfc/pull/654
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190802/305c6328/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-07-02 📝 Original message: If ...

2023-06-09T12:40:32Z

In reply to nevent1q…fujt
_________________________

📅 Original date posted:2021-07-02
📝 Original message:
If the BIPs can allow very small standards related to a small niche of
Lightning usage, then I think they are the place for everything indeed. I'm
convinced.

Thinking about proposing the LNURL specs as BIPs now, but then I don't know
if it will be weird for them to exist alone there, without the basis of the
lightning technology to support them. I hope the BOLT authors investigate
moving them there too so the other Lightning BIPs can add the BOLT BIPs as
"Required".

The only question to me is this: should each BOLT be a BIP? Or all BOLTs be
mashed together as a single BIP? Then what happens when Taproot-based
channels, PTLCs or Eltoo-based channels get implemented? They are added as
new BIPs that inherit and modify the previous?

I also went through
https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist and to me they
seem to be all good proposals (specially the list of projects/services
implementing the BIP). Except BIP versioning. I like that BIPs have
meaningless numbers, just add another BIP and refer to it by a number. For
that reason I also don't like prepending an "L" to Lightning-related BIPs
(more so because some of these may be reused later in non-Lightning
contexts, who knows?). Anyway I'm fine with anything.

On Fri, Jul 2, 2021 at 4:32 PM Luke Dashjr <luke at dashjr.org> wrote:

> Yes, many systems doesn't really make sense. We can add editors and revise
> the
> BIP process as needed (BOLTs might prefer to use markdown?). Even aside
> from
> Lightning BIPs, there are several improvements that can be made, so it
> makes
> sense to address everything at once.
>
> https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist
>
> The BIP 2xx range has been set aside for Lightning years ago, and we can
> do
> similar things to help keep things organized within BIPs. Kalle suggested
> maybe it'd be better to do BIP "L###" instead, and perhaps that would work
> better if there's likely to be several sub-namespaces.
>
> Luke
>
>
> On Friday 02 July 2021 12:02:28 Dan Gershony wrote:
> > Hi,
> > There will be many layer 2 (and probably layer 3) protocols (BOLT, RGB,
> > Volts etc...) does it really make sense to merge them all into the BIPs
> > system?
> >
> >
> > On Fri, Jul 2, 2021 at 10:03 AM nathanael via Lightning-dev <
> >
> > lightning-dev at lists.linuxfoundation.org> wrote:
> > > Michael Folkson <michaelfolkson at gmail.com> wrote:
> > > > > Adding a third BIP editor more involved with Lightning sounds like
> a
> > >
> > > good idea.
> > >
> > > > Or alternatively if BOLTs were subsumed into BIPs I think Bastien
> > > > would be a great additional BIP editor to cover Lightning related
> BIPs
> > > >
> > > > :) I think BOLTs being subsumed into BIPs would be nice but I'm
> > > >
> > > > pessimistic it will happen. Like legislation and regulation in the
> > > > legacy financial system alphabet soups only expand they never get
> > > > simplified. Let's at least resist alphabet soup expansion here.
> > >
> > > arent lightning improvements in the end bitcoin improvements too?
> > > i am thinking of bips like the rfcs of the internet
> > >
> > > --
> > > nathanael
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> 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/20210702/abb5b479/attachment.html>;

📅 Original date posted:2021-07-01 📝 Original message: ...

2023-06-09T12:40:29Z

In reply to nevent1q…s807
_________________________

📅 Original date posted:2021-07-01
📝 Original message:
Here's another feature which just appeared and would benefit from a
bLIP for compatibility:
https://twitter.com/SimpleBtcWallet/status/1410506889545359365

Atomic splitting of bills. A very small thing, but also very cool. I
can't imagine it fitting in the BOLTs at all.

2021-06-30 09:10 (GMT-05:00), Ryan Gentry via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> said:
> 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
>

📅 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
>

📅 Original date posted:2020-12-23 📝 Original message:Hi ...

2023-06-07T18:27:45Z

In reply to nevent1q…c72a
_________________________

📅 Original date posted:2020-12-23
📝 Original message:Hi Andrew.

I'm just a lurker here and I have not much experience with PSBTs, but still let me pose this very obvious question and concern: isn't this change going to create a compatibility nightmare, with some software supporting version 1, others supporting version 2, and the ones that care enough about UX and are still maintained being forced to support both versions -- and for no very important reason except some improvements in the way data is structured?

Ultimately I don't think it should matter if some data is structured in not-the-best-possible way, as long as it is clear enough for the computer and for the libraries already written to deal with it. Backwards-compatibility and general interoperability is worth much more than anything else in these cases.

Also let me leave this article here, which I find very important (even if for some reason it ends up not being relevant to this specific case): http://scripting.com/2017/05/09/rulesForStandardsmakers.html

---- On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote ----
> Hi All,
>
> I have some updates on this after speaking with some people off-list.
>
> Firstly, the version number will be set to 2. In most discussions, this
> proposal was being referred to as PSBT version 2, so it'll be easier and
> clearer to set the version number to 2.
>
> For lock times, instead of a single PSBT_IN_REQUIRED_LOCKTIME field,
> there will be 2 of them, one for a time based lock time, and the other
> for height based. These will be:
> * PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x10
> * Key: empty
> * Value: 32 bit unsigned little endian integer greater than or equal
> to 500000000 representing the minimum Unix timestamp that this input
> requires to be set as the transaction's lock time. Must be omitted in
> PSBTv0, and may be omitted in PSBTv2
> * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x11
> * Key: empty
> * Value: 32 bit unsigned little endian integer less than 500000000
> representing the minimum block height that this input requires to be set
> as the transaction's lock time. Must be omitted in PSBTv0, and may be
> omitted in PSBTv2.
>
> Having two lock time fields is necessary due to the behavior where all
> inputs must use the same type of lock time (height or time). Thus if an
> input requires a particular type of lock time, it must set the requisite
> field. Any new inputs being added must be able to accommodate all
> existing inputs' lock time type. This means they either must not have a
> lock time specified (i.e. no OP_CLTV involved), or have branches that
> allow the acceptance of either type. If an input has a lock time type
> that is incompatible with the rest of the transaction, it must not be added.
>
> PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback
> option if no input lock time fields are present. If there are input lock
> times, all lock time calculations must ignore it.
>
> Any role which does lock time calculation will first check if there are
> input lock time fields. If there are not, it must then check for a
> PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is the
> transaction's lock time. If it does not, the lock time is 0. If there
> are input lock time fields, it must choose the type which does not
> invalidate any inputs. The lock time is then determined to be the
> maximum value of all of the lock time fields for the chosen type.
>
>
> Additionally, I would like to add a new global field:
> * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05
> * Key: empty
> * Value: A single byte as a boolean. 0 for False, 1 for True. All
> other values ore prohibited. Must be omitted for PSBTv0, may be omitted
> in PSBTv2.
>
> PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and
> outputs can be added to the PSBT. This flag may be set to True when
> inputs and outputs are being updated, signed, and finalized. However
> care must be taken when there are existing signatures. If this field is
> omitted or set to False, no further inputs and outputs may be added to
> the PSBT.
>
> Several rules must be followed to ensure that adding additional inputs
> and outputs will not invalidate existing signatures. First, an input or
> output adder must check for any existing signatures in all of the other
> inputs. If there are none, the input or output may be added in any
> position. If there are one or more signatures, each signature's sighash
> type must be examined. Inputs may only be added if all existing
> signatures use SIGHASH_ANYONECANPAY. Outputs may only be added if all
> existing signatures use SIGHASH_NONE. If an input has a signature using
> SIGHASH_SINGLE, the same number of inputs and outputs must be added
> before that input and it's corresponding output. For all other sighash
> types (i.e. SIGHASH_ALL and any future sighash types), no inputs or
> outputs may be added to the PSBT. Specific exceptions can be made in the
> future for additional sighash types.
>
> Furthermore, these newly added inputs must follow additional lock time
> rules. Because all signatures, regardless of sighash type, sign the
> transaction lock time, newly added inputs when there are existing
> signatures must have the same type of lock time used in the transaction,
> and must be less than or equal to the transaction lock time. It must not
> cause the transaction lock time to change, otherwise the signatures will
> be invalidated.
>
>
> Lastly, to uniquely identify transactions for combiners, a txid can be
> computed from the information present in the PSBT. Internally, combiners
> can create an unsigned transaction given the transaction version, the
> input prevouts, the outputs, and the computed locktime. This can then be
> used to calculate a txid and thus used as a way to identify PSBTs.
> Combiners will need to do this for all version 2 PSBTs in order to avoid
> combining distinct transactions.
>
>
> Andrew Chow
>
> On 12/9/20 5:25 PM, Andrew Chow wrote:
> > Hi All,
> >
> > I would like to propose a new PSBT version that addresses a few
> > deficiencies in the current PSBT v0. As this will be backwards
> > incompatible, a new PSBT version will be used, v1.
> >
> > The primary change is to truly have all input and output data for each
> > in their respective maps. Instead of having to parse an unsigned
> > transaction and lookup some data from there, and other data from the
> > correct map, all of the data for an input will be contained in its map.
> > Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX in this new version.
> > Thus I propose that the following fields be added:
> >
> > Global:
> > * PSBT_GLOBAL_TX_VERSION = 0x02
> > * Key: empty
> > * Value: 32-bit little endian unsigned integer for the transaction
> > version number. Must be provided in PSBT v1 and omitted in v0.
> > * PSBT_GLOBAL_PREFERRED_LOCKTIME = 0x03
> > * Key: empty
> > * Value: 32 bit little endian unsigned integer for the preferred
> > transaction lock time. Must be omitted in PSBT v0. May be provided in
> > PSBT v1, assumed to be 0 if not provided.
> > * PSBT_GLOBAL_INPUT_COUNT = 0x04
> > * Key: empty
> > * Value: Compact size unsigned integer. Number of inputs in this
> > PSBT. Must be provided in PSBT v1 and omitted in v0.
> > * PSBT_GLOBAL_OUTPUT_COUNT = 0x05
> > * Key: empty
> > * Value: Compact size unsigned integer. Number of outputs in this
> > PSBT. Must be provided in PSBT v1 and omitted in v0.
> >
> > Input:
> > * PSBT_IN_PREVIOUS_TXID = 0x0e
> > * Key: empty
> > * Value: 32 byte txid of the previous transaction whose output at
> > PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1 and
> > omitted in v0.
> > * PSBT_IN_OUTPUT_INDEX = 0x0f
> > * Key: empty
> > * Value: 32 bit little endian integer for the index of the output
> > being spent. Must be provided in PSBT v1 and omitted in v0.
> > * PSBT_IN_SEQUENCE = 0x0f
> > * Key: empty
> > * Value: 32 bit unsigned little endian integer for the sequence
> > number. Must be omitted in PSBT v0. May be provided in PSBT v1 assumed
> > to be max sequence (0xffffffff) if not provided.
> > * PSBT_IN_REQUIRED_LOCKTIME = 0x10
> > * Key: empty
> > * Value: 32 bit unsigned little endian integer for the lock time that
> > this input requires. Must be omitted in PSBT v0. May be provided in PSBT
> > v1, assumed to be 0 if not provided.
> >
> > Output:
> > * PSBT_OUT_VALUE = 0x03
> > * Key: empty
> > * Value: 64-bit unsigned little endian integer for the output's
> > amount in satoshis. Must be provided in PSBT v1 and omitted in v0.
> > * PSBT_OUT_OUTPUT_SCRIPT = 0x04
> > * Key: empty
> > * Value: The script for this output. Otherwise known as the
> > scriptPubKey. Must be provided in PSBT v1 and omitted in v0.
> >
> > This change allows for PSBT to be used in the construction of
> > transactions. With these new fields, inputs and outputs can be added as
> > needed. One caveat is that there is no longer a unique transaction
> > identifier so more care must be taken when combining PSBTs.
> > Additionally, adding new inputs and outputs must be done such that
> > signatures are not invalidated. This may be harder to specify.
> >
> > An important thing to note in this proposal are the fields
> > PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUIRED_LOCKTIME. A Bitcoin
> > transaction only has a single locktime yet a PSBT may have multiple
> > locktimes. To choose the locktime for the transaction, finalizers must
> > choose the maximum of all of the *_LOCKTIME fields.
> > PSBT_IN_REQUIRED_LOCKTIME is added because some inputs, such as those
> > involving OP_CHECKLOCKTIMEVERIFY, require a specific minimum locktime to
> > be set. This field allows finalizers to choose a locktime that is high
> > enough for all inputs without needing to understand the scripts
> > involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is the locktime to use if
> > no inputs require a particular locktime.
> >
> > As these changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1
> > needs the version number bump to enforce backwards incompatibility.
> > However once the inputs and outputs of a PSBT are decided, a PSBT could
> > be "downgraded" back to v0 by creating the unsigned transaction from the
> > above fields, and then dropping these new fields.
> >
> > If the list finds that these changes are reasonable, I will write a PR
> > to modify BIP 174 to incorporate them.
> >
> > Thanks,
> > Andrew Chow
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>