This construction is pretty neat and seems to solve a lot of problems. I
find the use of CLTV with past timestamps to provide ordering in particular
to be quite clever.
If my understanding is correct though, this construction would
significantly increase the safe CLTV delta requirements because HT
Something like this might also be useful for several use cases related to
RBF. For example:
Alice sends Bob an RBF-activated transaction T1 with the intention of
bumping its fee if necessary. Bob wants to send these funds to Carol, but
cannot wait until T1 confirms, so he crafts a transaction T2 t
Hi all,
I'd like to pick up the discussion from a few months ago, and propose a new
sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
output. This was previously mentioned on the list by Joseph Poon [1], but was
never formally proposed, so I wrote a proposal [2].
We hav
(cross-posting to bitcoin-dev since this serves as motivation behind the
sighash_noinput proposal)
> TL;DR: we announce a new, simple, update mechanism for off-chain protocols,
> see the announcement [1] and the paper [2] :-)
A little over a year ago, the three Lightning Network implementation
te
