BTC-XMR atomic swaps are now live on their mainnets. I have been talking with some Monero developers about how BCH-XMR atomic swaps could be implemented. They say they do not think it is possible without SegWit.
Is this true? If it isn’t true, then it could be good to demonstrate that BCH can do XMR-BCH atomic swaps without SegWit. However, I am not in a position to implement an atomic swap capability nor even really understand the technical details of how it might be done. I can provide the Monero developer’s discussion contact upon request if there is interest in this.
I’m not sure why there’s any fundamental reason it cannot be done without segwit, my best guess is that they might have built their swap implementation for segwit and are unwilling to adapt it for BCH.
A multisig spend is used in the middle of a TX chain, after which a pre-signed TX must be used to recover funds. If the counterparty malleates the multisig spend using an alternative signature, the pre-signed TX will be rendered invalid, making one party unable to claim their funds. After they don’t claim their funds for a long enough period of time, the counterparty is allowed to. This means any attempt at the atomic swap protocol when signatures contribute to the TX ID allows one party to unilaterally steal funds.
I just reread the intended use of Schnorr signatures in regards to BCH and have to say I initially misunderstood it. That is on me. While I have to double check the specifics of Schnorr-usage from Script, a modified set of scripts should theoretically exist enabling this.
Then yes, all third party vectors should no longer exist. I also reviewed PMv3 (relevant thread immediately available), whose detached signatures do still contribute to the TX ID, and noted that despite a brief moment otherwise, they are not intending to introduce further malleability. I also noted the following thread discussing malleability as a whole Transaction malleability: MalFix, SegWit, SIGHASH_NOINPUT, SIGHASH_SPENDANYOUTPUT, etc. It was created a while after the relevant fixes, and is generally ignorable, but I do want to mention it to emphasize why a lack of malleability is so important.
Sorry for initially saying otherwise, and I’ll try to review the exact details of Schnorr-utilizing Scripts later.
We could have a parallel BCH bounties system, but there is no central hub for that now, I think. There are a few BCH-based Fiverr-like systems, I believe, although these types of bounties probably aren’t a good fit for it.
I have established a BCH address for donations for this bounty. I will personally custody the funds and release them to whoever completes the bounty requirements. The address is:
I, Rucknium, solemnly swear to release these funds to the person or persons who fulfills the requirements for the BCH<>XMR Atomic Swaps bounty at https://bounties.monero.social/posts/37/bch-xmr-atomic-swaps The Times 23/Nov/2021 Hong Kong student Tony Chung jailed for wanting independence
++++++++++++++++++
Signature of the above statement with the private key of bitcoincash:qrm0snx7l9kakt6lmzdpyupwryjktr47au6004uwyp
Is the REFUND spend described in the paper the problem?
The descendant TX is pre-signed and so if the same party malleates the parent then it invalidates its own signature in the descendant?
If yes, then this is solvable - we can use introspection opcodes (activated in May '22) to emulate SIGHASH_ANYPREVOUT (APO) so descendant TX’s signature would be valid even if prevout TXID changes - the spender would simply have to update the prevout TXID in the TX, and the signature would still be valid.
I think these should work. If anyone tries to rug any child transaction, the other party can simply update the child with new prevout reference, because the signatures for the custom sighash will still be valid.
Sounds reasonable. Would like much more documentation in the contract itself to understand the primary intent, all the exploits and edge cases it is avoiding and how they are being covered.
It would be cool if paper’s author (h4sh3d) would review this contract here.
Thing is, child TX-es get signed before the parent. Parties only sign the parent once they verified children are signed correctly, and then the parent gets mined. With SegWit, it’s not vulnerable to 2nd party malleability, but on BCH it would be. So, I make the child TX-es signatures malleable too, so that link to parent can be updated without breaking the signature.
Also, I should have added a disclaimer: this is not intended as a production version, but as proof-of-concept to get the ball rolling.
One edge-case is malleability of fees (which could be closed with few more opcodes to tighten the TX). Bob could malleate the funding TX, and post his version of children to the mempool first and add 1 more input and output to ensure the fee will be minimum. Shouldn’t be an issue on BCH, but the possibility is there - and we can close this option, or use it as a feature, we could have these custom preimage signatures sign for the exact amount going from the input to output, and then either party could fund the TX with an extra input to pay for the fees - something not possible with BTC version
Because of malleability, it’s extra work on the app stack too, because they have to monitor for the possibility of parent’s TXID being changed and update the children accordingly.
Transaction malleability breaking the chain is. I believe 2-party Schnorr has no malleability and would be sufficient. Introspection may be another path forward.
Regarding your scripts, I don’t want to sign off on them due to their complexity, sorry. I can, immediately, note that since adaptor signature swaps leak a private key, they can’t reuse public keys. Accordingly, building a custom sighash should only require committing to bytecodes, not to values, if you want to micro-optimize this.
Yup, wrapped my head around it in the meantime. On BCH, signatures are 1st/2nd party malleable but, as demonstrated above, we can mitigate that by excluding parent TXID(s) from descendant signatures, so e.g. Bob posting a malleated funding TX can’t invalidate the pre-signed Refund path - because Alice can just update the pre-signed TX prevout ref. and Bob’s signature will continue to be valid.
2nd party maleability is still the problem - the 2nd party can roll another signature with a different random value, and post that TX instead of the agreed one, and with that invalidate any pre-signed children which would block the refund path, since, without SegWit, the signature is included in the TXID calculation.
Yes, see v2 of the contract (didn’t want to clutter by posting the code here).
Introspection enforces forwarding BCH to the correct recipient (either P2PKH constructed from either party’s key, or forwarding to Refund contract) + require a data signature to reveal the XMR share.
The covenant / introspection approach not only has significant size savings but also makes the TX chain more tight, I use it to enforce 1in-1out TX form, and commit to the fee while at it.
Yup, that’s why in the refund contract’s recovery path (if Bob diappears) we have to use another key for Alice, a non-leaking one.
Also note that in my contracts the signatures are replayable, so swap & refund keys must be considered one-time for that reason, too.
See the v2, we don’t really need to sign anything since we can enforce BCH balance flow with covenant / introspection opcodes, in which case the purpose of the data signature is just to unlock the spending path & force the party to reveal their XMR share.
The revealing signatures could really be signing whatever message, but the message needs to be known in advance for the VES to work, right? So I just make the output bytecode immutable (covenant) & require a signature of just the output’s bytecode as the message.
And I have coded a version (referred to as v3) in CashScript, too. It is slightly bigger when compiled, but the advantage is possibility of using CashScript tooling for application development.
I’ve noticed you talk about various malleability concepts online and I have yet to figure out what it is you are talking about.
Maybe I can start with what my position / understanding is.
You use “1st person malleability” sometimes, which is a term that feels acadamic or technical, but not really useful. Like you can’t call “breaking and entering” when you use your own key on your own front door.
1st person would be the owner of the private key re-signing the input. Not really malleability.
2nd person, as quoted above, as I understand the quoted part, is about an unconfirmed input being double spend, with the intention to make your transaction invalid and you need to re-sign to follow that change.
Similar to the above, this is not malleability. This is double spending.
Malleability is defined as a valid (signed) transaction being modified in a way that changes its TXID, but does NOT invalidate its signatures and thus allowing it to be mined in its new form, with the new TXID.
I am not aware of any way to malleate a normal p2sh or p2pkh transaction. Multisig is a bit tricky, but malleating without any of the signers being in on it is also as far as I know not possible.
Malleability for all the important cases has been solved years ago on BCH, no?
Yup, and on BCH we closed off 3rd party malleability.
If you and me sign a 2/2 then you’re my “2nd party” and from my PoV I’m the “1st party”. Our signatures are independent, meaning any party can reroll their own signature to change the TXID without having to get a new signature from the other party.
This means I can double-spend a 2/2 all by myself and invalidate the whole graph of descendant transactions, and that would be a problem for the original swap scheme outlined in the paper, for the same reason it would be a problem for Lightning Network: they use multisig to emulate covenants.
We can work around the issue of invalidating descendant transactions by using proper covenants - which can be coded such that they allow updating the prevout refs without breaking any signature, meaning the descendant transactions graph could be reconstructed if the parent gets double-spent, without needing updated signature from the other party.
Any other type of “malleability” you described in this thread doesn’t fall under the definition of malleability. Any TXID change that requires access to private key is not malleability.
It typically is just scamming / double spending / updating-the-tx. Whatever is appropriate.
Re-using a known term that is still active in the crypto space to mean something different doesn’t feel right. It certainly confused me, and I expect it to cause confusion in others too.
