Good morning Ruben,

> Hi ZmnSCPxj,
> >potentially both Alice and Bob know all the secrets on the LTC side and end 
> >up competing over it
> That's exactly right.
> >Bob can thus give a copy of the revoke tx with signature directly to its 
> >favorite miner, forcing Alice to take 3 transactions
> Note that the timelock on the revoke tx is longer than the timelock on refund 
> tx #1. The idea is that Alice aborts the protocol by publishing refund tx #1 
> if the protocol hasn't reached step 4 in the svg by the time it becomes 
> valid. This should entirely mitigate the issue you're describing.

But if refund tx #1 at all exists, then you drop to the same issue you objected 
to with my proposal, which is that, on completion of the protocol, if Bob lets 
the refund tx#1 become valid (i.e. does not spend the BTC txo) then Alice can 
broadcast it, putting both their funds into chaos.

So you might as well just use my counterproposal instead, which is simpler, 
gets bring-your-own-fees for free, etc.

I suppose there is some *slight* improvement in that with your proposal, Alice 
*can* use revoke tx -> refund tx #2, but still, if Alice is insane then it 
could very well mess with the protocol by instead using refund tx #1.
Thus, if Bob wants to survive in an environment where Alices are possibly 
insane (e.g. the real world), it should do everything in its power to ensure 
that the BTC txo is spent before the timeout of refund tx #1, if refund tx #1 
exists at all.
And if Bob is already going to do that, then Alice and Bob might as well just 
use my counterproposal etc etc.

> >adding two CPFP outputs (one for each participant)
> There seems to be a situation where RBF can be disabled by the other party, 
> but I'm not sure I see it... Why would a single output spendable by either 
> key be insufficient?

If one party quickly broadcasts a long chain of low-feerate transactions on top 
of the single output, then the output is "pinned".

Low feerate means it is undesirable for miners to mine it, because it pays low 
for the amount of blockspace it has.
But because there is a long chain of transactions, the absolute fee of that 
chain can be sizable, and we have a rule in RBF which, paraphrased, goes 
something like "the replacing transaction should also have a higher absolute 
fee than *all* the transactions it replaces", meaning the fee jump that the 
other side has to offer *has to be* pretty big.

If the other outputs of the tx are then multisig, then the pinning participant 
can simply refuse to sign for those, and if the existing txes spending the 
other outputs are relative-time-locked, they cannot be used to CPFP the revoke 
tx onchain.

This is why we eventually decided in Lightning to use two CPFP outpoints rather 
than one, and are also realizing just how much of a headache the RBF rules are, 

Still, in your proposed protocol the dependent transactions are all 
relative-timelocked, so timely confirmation of the revoke tx is not necessary, 
unlike in the case of Lightning where all HTLCs have to use an absolute 
timelock because we have to coordinate multiple HTLCs in forwarding and 
violation of the timelocks can lead to headaches and fund loss and so on.
So maybe a single hook output, or even none at all, is workable.

> Allowing others to add inputs/outputs would introduce malleability. Refund tx 
> #2 and the timeout tx would become invalid.

Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that.

> >Bob cannot safely perform step 2 before getting both signatures for the 
> >revoke tx
> That's right, as you guessed, he does receive a copy of the signed revoke tx 
> at protocol start.
> >>alternatively Bob can just spend before the timelock expires.
> >This seems to be the safest alternative
> I agree not giving Alice time to publish the revoke tx is safest, but one 
> does not preclude the other. The revoke tx is on an absolute timelock, so 
> spending it before that time means you don't have anything to worry about, 
> and spending it later means you'll have to be online and keep an eye out. If 
> staying online is not a problem, then fee wise that seems preferable. As long 
> as less than half of all valid (i.e. the timelock was reached) revoke 
> transactions get broadcast, you'll be saving on fees.

In a world where Alice may be insane and mess with the protocol just to grief 
Bob even if Alice loses its money (e.g. the real world), Bob should not depend 
on Alice behaving correctly or politely, so it should still have backup 
watchers set up in case it accidentally goes to sleep and so on.

bitcoin-dev mailing list

Reply via email to