Allow either node to send tx_init_rbf in v2 establishment
#1236
Conversation
There was a problem hiding this comment.
I have prototyped this in ACINQ/eclair#3021 and I don't see any reason to disallow it.
Splicing allows either node to send `tx_init_rbf` as they may want to take the opportunity to contribute or withdraw additional funds to / from the channel. Allow the same for v2 channel establishment for consistency.
jkczyz
force-pushed
the
2025-03-dual-funding-rbf
branch
from
7feaee0 to
966e550
Compare
|
Squashed the fixups. @vincenzopalazzo Anyone else from CLN need to chime in on this? |
|
I haven't tested it but this should work fine in CLN. We essentially treat RBF as just a |
|
@ddustin be careful, it must NOT be treated as |
|
@ddustin I tested against |
| The sender of `tx_init_rbf`: | ||
| - MUST be the *initiator* | ||
| - MAY be either the *initiator* or the *accepter* | ||
| - If the sender is the accepter, it becomes the initiator of the `interactive-tx` session and thus: |
There was a problem hiding this comment.
Hello! Looking at updating CLN to accommodate this, and ran into a question which seems obvious but wanted to confirm.
I'm taking this to mean that the serial_ids and all other role-related indicators are swapped for the entirety of the tx construction phase?
Work in progress to allow acceptor to initiate an RBF Mostly works, except that the original funder isn't setup to re-add their original funds to the channel, so the init fails because it's missing any overlapping inputs. lightning/bolts#1236
|
Is it an implementation detail to have the OG opening peer re-adding their original inputs to the transaction or is that something we should specify? |
I'd say it's an implementation detail. They could choose to not add them / take the opportunity to use entirely different inputs / amounts. |
Oh, and since they are no longer the initiator, they wouldn't be paying for the common fields nor the funding output. So they may decide to choose different UTXOs to spend as their fee responsibility may decrease. |
|
One issue we ran into on CLN is that without a common input with the
previous tx, the RBF attempt fails (our checks don’t allow a second tx for
a channel to be signed).
For splicing, you’re guaranteed to have at least the prev channel outpoint
in the tx, but for a new channel there’s not an obvious common outpoint.
…On Tue, Oct 21, 2025 at 17:27 Jeffrey Czyz ***@***.***> wrote:
*jkczyz* left a comment (lightning/bolts#1236)
<#1236 (comment)>
I'd say it's an implementation detail. They could choose to not add them /
take the opportunity to use entirely different inputs / amounts.
Oh, and since they are no longer the initiator, they wouldn't be paying
for the common fields nor the funding output. So they may decide to choose
different UTXOs to spend as their fee responsibility may decrease.
—
Reply to this email directly, view it on GitHub
<#1236 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIMAKNI4BAHA5EUGUU5MI33Y2XNTAVCNFSM6AAAAABYWRXSNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMRZG44TGMJWGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
5 participants
Splicing allows either node to send
tx_init_rbfas they may want to take the opportunity to contribute or withdraw additional funds to / from the channel. Allow the same for v2 channel establishment for consistency.