ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-16 📝 Original message: Good morning Rusty, > I ...
📅 Original date posted:2018-11-16
📝 Original message:
Good morning Rusty,
> I tried to simplify RBF as much as possible; it adds a lot of
> complexity :( In particular, below we have one side pay the fees (and
> thus responsible for RBF), in violation of the summit agreement,
> and simplified the fee amount as much as reasonable.
This (initiator-pays) was proposed on the summit, by my memory.
At the time, I was going to propose also that only the splice-initiator would then be allowed to add splice-ins and/or splice-outs, since the splice-initiator "owns" the splice (as it pays all the fees).
And then, I would also propose that once splice-initiator indicates satisfaction with splice ins and outs, the two switch sides (but the fees proposed by the first splice-initiator remain deducted from the splice-initiator) and the other party has an opportunity to add its own splice-ins/outs, for which it would pay for.
However, RBF adds a whole new dimension...
It's certainly much easier to reason about a single payer of the fees.
>
> RBF it implicitly requires multiple (exclusive) splices at once. This
> will all require a great deal of testing...
Would it be useful to define a dual-funding RBF protocol first, so we have practice for splice RBF?
Regards,
ZmnSCPxj
📝 Original message:
Good morning Rusty,
> I tried to simplify RBF as much as possible; it adds a lot of
> complexity :( In particular, below we have one side pay the fees (and
> thus responsible for RBF), in violation of the summit agreement,
> and simplified the fee amount as much as reasonable.
This (initiator-pays) was proposed on the summit, by my memory.
At the time, I was going to propose also that only the splice-initiator would then be allowed to add splice-ins and/or splice-outs, since the splice-initiator "owns" the splice (as it pays all the fees).
And then, I would also propose that once splice-initiator indicates satisfaction with splice ins and outs, the two switch sides (but the fees proposed by the first splice-initiator remain deducted from the splice-initiator) and the other party has an opportunity to add its own splice-ins/outs, for which it would pay for.
However, RBF adds a whole new dimension...
It's certainly much easier to reason about a single payer of the fees.
>
> RBF it implicitly requires multiple (exclusive) splices at once. This
> will all require a great deal of testing...
Would it be useful to define a dual-funding RBF protocol first, so we have practice for splice RBF?
Regards,
ZmnSCPxj