Hi Thomas,
I thought it would be interesting to specify this in details, to figure out
the potential subtleties. I did that in a gist [1], that I plan to turn into
a bLIP after writing some prototype code for it.
Feel free to comment, either on the gist or here.
Cheers,
Bastien
[1]
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
On 6/20/23 1:45 AM, Thomas Voegtlin wrote:
- snip -
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?
They will not as-specified, but
Hi Thomas, Bastien, and list,
One point I would like to stress for this idea, is that there are potentially
three different entities at play in these payments.
This might not be obvious at first glance especially for the submarine swap
example, where people expect just two entities: the user
Hi Thomas,
> I believe pre-payment of the mining fee can be combined with 0-conf;
> I am not sure why you picture them as opposed? Even with BOLT-12, I
> don't see 0-conf going away.
Sorry if that was unclear, that's not at all what I meant. What I meant
is that if we *stopped* using 0-conf for
Hello Bastien,
Thank you for the clarification; indeed I might not have been clear
about the fact that senders need to understand the new fields.
What you are suggesting (solution 2, blacklisting non-cooperative
clients and playing with the mempool) is prone to griefing attacks and
it requires
Hello Dave,
That is an interesting idea; it would indeed save space for the prepayment hash.
I think the invoice would still need a feature bit, so that the receiver can
decide to make prepayment optional or required.
Note that for the feature to be optional, we need to subtract the prepayment
On 2023-06-12 22:10, Thomas Voegtlin wrote:
The semantics of bundled payments is as follows:
- 1. the BOLT-11 invoice contains two preimages and two amounts:
prepayment and main payment.
- 2. the receiver should wait until all the HTLCs of both payments
have arrived, before they fulfill the
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
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
I think the ship has probably sailed on getting any kind of new interoperable
change in to BOLT-11.
We already can't get amount-less BOLT-11 invoices broadly supported, rolling out yet another new
incompatible version of BOLT-11 and expecting the entire ecosystem to support it doesn't seem all
Of course, a submarine swap client needs to do the proper checks and sweep
the funds. In the case of Boltz, their website serves javascript that does
that, and they are also distributing a Progressive Web App [1]. I have no
idea whether their app is doing all this correctly, my point is rather
> Their website shows an invoice to the user, whose wallet that is agnostic
> about the swap, and it would be unpractical for them to show two invoices
> to be paid simultaneously
In order to be properly non-custodial, a submarine swap client needs to be
able to unilaterally sweep or timeout
13 matches
Mail list logo
