What is the exact definition in context of multisig transactions?
For P2PKH sure, there’s only 1 key and using it to create a new signature is a double spend.
For multisig, I think the term “malleability” would still apply since you can malleate the TXID without having access to any of the other keys even though they’d normally be required to change the transaction.
BIP-141 recognized this in the motivation section:
In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62)
The paper that describes the XMR-BTC swap claims it’s not possible on BCH because of it:
The bitcoin transactions in this protocol require the fix for transaction malleability provided by the SegWit upgrade. This allows us to chain transactions without necessarily broadcasting them. This protocol is only compatible with cryptocurrencies which use a bitcoin style UTXO model and have an equivalent malleability fix such as Litecoin (i.e. Bitcoin Cash is not compatible.)
Do you believe it is possible to modify the details of the BTC XMR atomic swap protocol so they can work BCH XMR? Presumably this would use introspection and allow un-broadcast recovery transactions to be modified by a potential victim of an attempted rug pull.
In the context of protocol development and even advertising, we have no malleability there (to the best of my knowledge) as it would require private keys to make changes and thus what leaves your wallet is what gets mined.
But then we have the birthday paradox, we have the mess of needing to use p2sh instead of the script being in the prev-out and indeed private keys outside of your control.
Its not an issue in 99% of the cases, but in real life using them unconfirmed is… tricky.
Well, I don’t think it is that tricky. I could be wrong (not going to read the whole paper on my Sunday afternoon), but that sounds like BS.
BCH has Schnorr signatures, which means the needed multi-signature capability required by the two scripted transactions on the BCH chain should be transparent to the blockchain, known only by the swap code Alice and Bob run.
I am trying to thouroughly understand the BTC XMR paper before commenting further. I am wary of subtle details in the protocols, scripting, or cryptography.
That’d be 3rd party malleability, i.e. anyone being able to change a signed TX’s TXID. I think this has been closed with HF 2019-11-15 Schnorr Multisig so you’re right – changing a TXID of a TX signed with multisig would require access to a (singular!) private key. Not keys. Key, just one, any one key from the set, regardless of the required number of signatures required by the script.
This is the literal definition of 2nd party malleability: a single signer can change the TX without approval from other co-signers even when required number of signatures is > 1.
Even if the scripts of the paper were “bare” (as opposed to P2SH), the problem would still be there.
Sorry, it’s not BS. Using Bitcoin specification of 2016, or BitcoinCash specifications prior to activating HF 2018-11-15 the script had no way to work around the problem. Paper authors were probably just unaware that we had covenant through OP_CAT, OP_SPLIT and OP_CHECKDATASIG. That’s understandable, to do covenants using 2018 spec is extremely brain-twisting. Thankfully, since 2022, we have introspection opcodes – meaning it’s more straight-forward to code covenants, and above I presented such covenant-based solution.
Why is 2nd party malleability a problem for the scheme?
Let’s first observe possible flows of BTC/BCH:
[Bob's P2PKH UTXO]
|
(fund swaplock)
|
V
[SWAPLOCK UTXO] --(complete swap)--> [Alice's P2PKH UTXO, Bob gets XMR]
|
(initiate refund, option available only if timelock t_0 expired)
|
V
[REFUND UTXO] --(complete refund)--> [Bob's P2PKH UTXO, Alice gets XMR]
|
(recovery and punish Bob, option available only if timelock t_1 expired)
|
V
[Alice's P2PKH UTXO, Bob gets nothing]
During the off-chain interactive setup phase, both parties pre-sign and exchange signatures for all multisigs and construct and verify XMR key shares.
Then, Bob goes first and funds the SWAPLOCK.
Alice sees that, waits for some confirmations, and then funds the XMR output.
Then, after the XMR TX gets some confirmations, Bob reveals the hashlock secret to Alice, opening the (complete swap) path for her. If he fails to do it, Alice has to wait for timelock to initiate refund.
Then, Alice opens the hashlock and signs the (complete swap). Bob sees the signature published and from it extracts the XMR key share he needs to collect XMR – this part is the verifiably encrypted signature (VES) crypto magic.
If Bob goes missing (his fault) Alice just waits for timelocks to expire and gets Bob’s BCH and he gets nothing and XMR is stuck forever (unless he shows up later with a good excuse and Alice shows grace and reveals her XMR share to him).
But what if Alice is malicious? She could just wait for the timelock t_0 to expire and race to submit a changed (initiate refund) TX by swapping her old signature with new one (it’s 2-of-2 she can’t change the TX template without Bob, but can change TXID). That would mean the pre-signed (complete refund) TX that Bob has would be useless and he couldn’t complete the refund without Alice generating a new signature for him.
Alice could then just wait for the timelock t_1 to expire, collect her BCH, leaving Bob with nothing, punishing him out of malice.
With covenants, Bob doesn’t need Alice to go through with the refund even if parent’s TXID changes - he can update the prevout refs all by himself without invalidating the spending path.
FWIW, the paper by Gugger (h4sh3d) is not the only proposed Monero atomic swap protocol. Some others that have not been implemented in production code AFAIK:
It highlights the problem of fees on BTC and how Bob could be exposed to a draining attack because he has to go first. IMO it’s less of a problem on BCH since our fees are significantly lower (also helped by the contracts being smaller). The above paper proposes an alternative where Alice goes first by funding XMR output, but it depends on having adaptor signatures on both chains (as opposed to just on BCH/BTC in the original protocol), which is pending more research.
The 2nd paper needs capability to pre-sign XMR, which is not supported at the moment.
The 3rd paper relies on some generic crypto magic which goes over my head but it seems to be universally applicable and the transactions will look like ordinary P2PKH, so it is an improvement over HTLCs since it preserves privacy and transactions would be smaller, and also allows cyclic swaps: a multi-party chain of atomic swaps, such that either the whole chain goes through, or nothing does.
The 4th paper uses one-way payment channels to implement an interactive cross-chain swap. Parties simply update the channels in ping-pong fashion: transfer the currencies in small increments to each other until the swap is complete. This sounds promising, as we can have efficient such channels on BCH!
I understand the logic of combining those concepts into one, but inventing a new type of malleability this way is mostly just confusing…
And, the important part is that we still are in a phase where the rest of the world is unaware that Bitcoin Cash fixed transaction malleability, so reusing that word for something very different is not something I think is smart.
I’ve had various people ask what malleability is still a problem in the protocol. The knowledge that we fixed them in previous hardforks is absolutely not common knowledge (the segwit loving people are basically saying if its not segwit, you still have malleability) So… My question to you is that maybe you can come up with something less loaded there. “One of the parties re-signed the tx and changed the txid” doesn’t feel like its anywhere near the same concept as malleability fixed with segwit. Transaction malleability - Bitcoin Wiki
It is a case of “scriptSig Malleability” described there, e.g. in case of 2-of-2 multisig one of the parties can malleate the scriptSig as a whole without approval of the other party, which is why it’s called “2nd-party malleability”. In case of 2-of-3 with parties A, B, C: C could intercept a TX by A & B and replace either signature with his in order to change the TXID. This is solvable by:
SegWit (BTC)
PMv3 detached proofs (I think Radiant implemented this)
Using TX “idem” for prevout refs instead of TXID (BU was proposing this and implemented it for their new chain)
SIGHASH_NOINPUT (BCH solution, we construct the equivalent TX preimage using introspection opcodes and verify it using OP_CHECKDATASIG). This was also proposed in LN WP, pg. 57
SegWit BIP recognizes it as malleability in Motivation section:
In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62)
We implemented BIP62, so the multisig problem persists - but it’s not really a problem for us because we have more advanced Script and can work around it by constructing SIGHASH_NOINPUT, or even better - directly use covenant to enforce particular BCH flow instead of relying on pre-signed multisig.
thanks for the detailed answer. I’m not sure how this relates to my point, I already acknowledged your logical naming makes sense, I’m not arguing that.
I hope you still understood the gist of my post and please consider it.
Depends on how you define the “problem”. We implemented all of BIP-62 so closed off 3rd-party malleability.
We don’t have SegWit so it’s still possible for a single signer in multisig to generate a new signature to change TXID without approval of other signers, but this is not a problem for us because we don’t need to rely on multisig to enforce TX template - we have direct covenants for that.
Also, you can emulate SIGHASH_ANYPREVOUT by using introspection opcodes and OP_CHECKDATASIGVERIFY so it’s still possible to pre-sign descendant transactions without them being ruggable if parent TXID changes.
Few hours later @mainnet_pat published a mannet TX, done using his independent implementation with mainnet-js and cashscript libraries alongside cross-compiled Rust WASM for DLEQ. Also, he optimized the BCH contract a little by removing an unnecessarry sha256 op (which I already updated - v4.1.0).
Shortly after, PHCitizen performed TXs on mainnets and is waiting for review to claim the bounty.
@mainnet_pat is interested in building a real app out of this, and for that he’s seeking funding. I’m part of that flipstarter, too, but pat will be doing bulk of the work tho, I’m just doing some contract stuff & research.
I already went ahead and done some research, and realized this VES scheme will work just as well with BTC/LTC/DOGE, and can be made even simpler because those chains are scriptable (we just need OP_IF and OP_CHECKSEQUENCEVERIFY on their end), so we need just the 1 TX on BCH end for both swap & refund paths because the refund path will refund Bob directly instead of sending to the 2nd stage of the refund contract.
This is OK, because Alice doesn’t need Bob for the refund (as she does in XMR-BCH swap, where the 2nd stage is relying on another VES with roles inverted) because timelock on BTC/LTC/DOGE will just release refund path to her directly.
The BTC/LTC/DOGE contract is just this:
OP_IF
// When Alice pulls from the BCH contract, Bob will learn Alice's
// key share of this key and he can just sweep it by using this path.
<key_combined_alice_bob_ves.public_key> OP_CHECKSIG
OP_ELSE
// If timelock expires then Alice can sweep BTC back to herself using
// her own key.
<timelock_1> OP_CHECKSEQUENCEVERIFY OP_DROP
<key_alice.public_key> OP_CHECKSIG
OP_ENDIF
Oh yeah, we can swap not just BCH but any BCH+CashTokens UTXO for XMR/BTC/LTC/DOGE. When swapping pure BCH the contract is lighter for 15 bytes of covenant code which verify CashTokens contents but other than that it all works the same.
I am searching for an independent party who can verify the atomicity of the PHCitizen’s proposed implementation, based on @bitcoincashautist 's BCH script contracts. If the implementation is verified as atomic, then PHCitizen would receive the 18.4 XMR + 2.97 BCH bounty.
Maybe someone knowledgeable about the scripts activated in May 2022 could help. It could be reasonable to pay a portion of the bounty to someone who is capable of confirming the implementation’s atomicity (or finding a flaw). Maybe the 2.4 XMR that was contributed to the bounty after PHCitizen implemented their solution, or the equivalent in BCH.
I’ve taken a look at the v4-XMR contract by @bitcoincashautist. While I haven’t done a deep dive on the cryptography used, I can verify the workings of the contract being a co-developer of CashScript.
I’ve found some outdated comments and asked to improve some comments.
Specifically, to clearly mention that the off-chain interaction that takes place in preparation for the contract (aliceSignatureVES) and that this setup is asymetrical (bobSignatureVES) is not yet revealed during the setup of the contract because bob needs to make sure refundLockingBytecode is honest.
PHCitizen’s impementation is fully written in rust is not using the Cashscript SDK, so I can’t verify his implementation.
If I needed to describe the workings of swap contract in my own words:
either 1) both parties collaborate and swap goes through in the Swaplock contract which uses an interactive construction of bobSignatureVES after the initial contract set-up
or a timelock expires and the funds are forwarded to the Refund contract
then 2) a refund of the original funds can (should) be initiated by bob
3) if bob fails to refund within a given timeframe (=is being dishonest) alice gets his BCH after all, bob gets nothing (there is still the option to rescue the locked XMR if alice shows grace)
The contract construction favors Alice, as only bob can be punished by losing his funds and not receiving anything in return. This is because bob is favored in the asymmetrical setup where he already gets aliceSignatureVES needed to initiate a refund.
Overall, the design is sensible and because of the refund- and punishment timelocks, honest behavior is incentivized.
Output of cashc -h swaplock.cash (v4.0.0, v4.1.0 will differ in 1 opcode, sha256): c3519dc4519d00c600cc949d00cb009c6300cd7888547978a85379bb675279b27500cd54798854790088686d6d7551
Note that both swaplock.cash and refund.cash have the same contract “tail”, it’s just the committed contract parameters that get changed depending on whether it’s 1st or 2nd stage.
