Hey,
In testing the `splice_locked` workflow I discovered a race condition which
is critical we solve correctly. The core problem happens if any channel
activity occurs in the time after `splice_locked` is sent and before
`splice_locked` is received.
`splice_locked` is defined as being locked onc
This all works for me, I will update my implementation to be compatible
with this approach.
Perhaps we should pick another name than `funding_amount` though?
The current spec (for `splice` & `splice_ack`) proposal uses
* [`u64`:`funding_satoshis`]
How about we go with something like:
* [`s64`:`r
Good morning again ariard and t-bast,
>
> For cases where the one doing splice-in is an LSP and the other side is a
> client of that LSP, also consider this proposal:
> https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24
>
> While it is designed for 0-conf channel funding, the actual
Hi ariard and t-bast,
I would like to point out that spends from swap-in-potentiam addresses are
safely 0-conf if Bob is the other signatory in the swap-in-potentiam address.
On the other hand swap-in-potentiam is arguably cheating, since sending to a
swap-in-potentiam address is actually a cha
