Re: [Lightning-dev] Proposal: Bundled payments

[Steve Lee]

On Tue, Jun 20, 2023 at 6:17 AM Thomas Voegtlin 
wrote:

>
>
> We have not implemented BOLT-12 yet in Electrum. Would you care to
> describe whether bundled payments already would work with the current
> specification, or whether they would require changes to BOLT-12? We
> are going to implement BOLT-12 support in Electrum in the coming
> months, and I would be happy to help here.
>
>
Fantastic news!


> I believe that it will take years *after it is merged*, until BOLT-12
> actually becomes the dominant payment method on Lightning. OTOH, if
> this feature was adopted in BOLT-11, I think it could be deployed much
> faster.
>
>
Why do you think it will be adopted faster? History has shown that any
upgrade requiring wallets to change takes years even if it is a small
change to an existing design. For example, despite only requiring a tiny
change, there is still not widespread bech32m support [1]. Bech32/native
segwit support also took years.

[1] http://whentaproot.com/


>
> cheers,
>
> Thomas
>
>
>
>
>
> On 15.06.23 11:01, Bastien TEINTURIER wrote:
> > Hi Thomas,
> >
> > First of all, I'd like to highlight something that may not be obvious
> > from your email, and is actually pretty important: your proposal
> > requires *senders* to be aware that the payment will lead to a channel
> > creation (or a splice) on the *receiver* end. In particular, it requires
> > all existing software used by senders to be updated. For this reason, I
> > think extending Bolt 12 (which requires new sender code anyway) makes
> > more sense than updating Bolt 11.
> >
> > I see only three strategies to provide JIT liquidity (by opening a new
> > channel or making a splice, I'll only use the open channel case below
> > for simplicity):
> >
> > 1. Ask receiver for the preimage and a fee, then open a channel and
> > push the HTLC amount minus the fee
> > 2. Open a channel, then forward the HTLC amount minus a fee
> > 3. Pre-pay fee, then open a channel and forward the whole HTLC amount
> > on that channel
> >
> > What is currently deployed on the network is 1) and 2), while you're
> > proposing 3). Both 1) and 2) have the advantages that the sender doesn't
> > need to be aware that JIT liquidity is happening, and doesn't need to do
> > anything special for that payment, which is the main reason those
> > strategies were chosen.
> >
> > If all you're concerned about is trust and regulation, solution 2) works
> > fine as long as the mempool isn't empty: if the user doesn't release the
> > preimage after you've opened the channel, you should just blacklist that
> > channel, reject payments made to it, and double-spend it whenever you
> > have another on-chain transaction to make (and use 1 sat/byte for JIT
> > liquidity transactions). Even if the mempool is empty, if your LSP has
> > transactions to make at every block, it's likely that it will succeed
> > at double-spending the faulty channel, and thus won't lose anything.
> >
> > But I agree that this only works when coupled with 0-conf. If we're not
> > using 0-conf anymore, pre-paying fees would make more sense. But we will
> > likely keep on using 0-conf at least until Bolt 12 is deployed, so it
> > seems more reasonable to include this new feature in Bolt 12 rather than
> > Bolt 11, since all implementations are actively working on this?
> >
> > Cheers,
> > Bastien
> >
> > Le jeu. 15 juin 2023 à 10:52, Thomas Voegtlin  a
> > écrit :
> >
> >> Hello Matt,
> >>
> >> I think it is not too late to add a new feature to BOLT-11. In any
> >> case, the belief that BOLT-11 is ossified should not be a reason to
> >> make interactive something that fundamentally does not require more
> >> interactivity than what BOLT-11 already offers. Technical decisions
> >> should be dictated by technical needs, and I am a minimalist when it
> >> comes to adding new messages to protocols.
> >>
> >> I believe that two major implementations have an incentive to support
> >> this proposal (although I cannot speak for them):
> >>- Lightning Labs could potentially offer their Loop service to
> >>  non-LND users.
> >>- ACINQ would be able to open channels to Phoenix users without
> >>  requesting the preimage first. This would put them on the safe side
> >>  of the upcoming MICA regulation; I cannot emphasize enough how
> >>  important that is.
> >>
> >> In addition, you could certainly decide to support that feature in
> >> LDK, and I can speak for Electrum :-)
> >>
> >> It is the first time I suggest a change to the Lightning protocol, and
> >> what I am proposing is really a tiny change. All we need is a new
> >> invoice feature, that describes the prepayment of a fee using a
> >> different preimage. This feature does not need to be set on all
> >> invoices, and it could be made optional during a transition period.
> >>
> >> Here is how that feature could possibly made optional:
> >>- a new feature bit is defined, BUNDLE_PREPAYMENT
> >>- two extra fields are defined: 

[Lightning-dev] Sign up for Taproot BIP review by October 30

[Steve Lee]

Hello everyone,

The schnorr/taproot/tapscript BIPs are ready for review at this point, and
we want to get as much in-depth review from as broad a range of people as
we can before we go further on implementation/deployment. Reviewing the
BIPs is hard in two ways: not many people are familiar with reviewing BIPs
in the first place, and there are a lot of concepts involved in the three
BIPs for people to get their heads around.

This is a proposal  for a
structured review period. The idea is that participants will be given some
guidance/structure for going through the BIPs, and at the end should be
able to either describe issues with the BIP drafts that warrant changes, or
be confident that they’ve examined the proposals thoroughly enough to give
an “ACK” that the drafts should be formalised and move forwards into
implementation/deployment phases.

Benefits of participating:
* Deeply understand schnorr and taproot
* Be a stakeholder in Bitcoin consensus development
* Support/safeguard decentralisation of Bitcoin protocol development
* Have fun!

If you are interested in participating, please sign up here
.

Special thanks to AJ Towns for doing most of the heavy lifting to get this
going!

Steve
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev