Hi ZmnSCPxj, >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
You forget, refund tx #1 has a script (which btw won't be visible with taproot): "Alice & Bob OR Alice in +1 day" (relative) so if Alice broadcasts it after protocol completion, she is just giving Bob the key to her LTC (note: if she's wise she'd move the LTC beforehand), but Bob doesn't lose the BTC because he has both keys and can just react before the relative timelock expires. No chaos. >This is why we eventually decided in Lightning to use two CPFP outpoints rather than one I appreciate the explanation. I see the problem now, and yes, that does seem like a headache. Cheers, Ruben On Wed, May 13, 2020 at 1:39 PM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > 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, sigh. > > 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. > > > > > >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well > > > > 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. > > Regards, > ZmnSCPxj >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
