-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent ANYONECANPAY-signed inputs replay #83
base: master
Are you sure you want to change the base?
Conversation
Due to exchanging ALL | ANYONECANPAY signatures, Unvault and Deposit inputs could be replayed in other Cancel or Emergency transactions, effectively merging those transactions. Even though unlikely and in most cases requiring internal corruption this would be a massive DOS, so prevent them by comitting to specific vaults. There exists more complicated way of comitting to each vault but we go with a simple-to-reason-about solution for now. Reported-by: Stepan Snigirev <snigirev.stepan@gmail.com> Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
Hmm so i'm now really hesitating with tweaking the public keys à la BIP32 or Lightning Network with the tweak being the unvault outpoint, it'd be a huge win... At the expense of surely making coin tracking more complicated. |
We could also "just" change the Cancel descriptor from
To
With |
@@ -145,6 +153,10 @@ transactions are never meant to be used. | |||
|
|||
The Emergency `scriptPubKey` is not known to the managers. | |||
|
|||
In addition to the deposit output, the Emergency transaction features a data-carrying output committing | |||
to the Deposit transaction it's used for in order for the `ANYONECANPAY | ALL` signature to not be replayed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"...committing to the Deposit transaction id and the output index (vout) it is used for..."
Is there any chance that the Unvault Tx will batch deposit UTxOs in a future version? If so should we consider committing to the vout too in the Cancel and Unvault-Emergency Txs now? What about the Spend Tx? Are they always signed with ALL? |
To be honest i don't think we should do this for the Cancel, but rather #83 (comment) .
Yes. I mean it's left to the managers, they could sign with NONE if they want, but they could also leak their keys. |
Maybe I'm wrong, but it seems like there is nothing stopping an attacker from choosing H to be the same when constructing both Cancel Tx 1 and Cancel Tx 2. What verification do we have that the H are unique? What verification is there that the H actually has committed to the correct previous Unvault Txid? |
They would not exchange signatures for the same transaction. Now, for the enforcement of the verification.. I wonder if it's possible to do on the HW and asked @stepansnigirev by mail some time ago. It seems possible since it's an information internal to the transaction, but i would have to implement it to really be sure of what it takes. FWIW this solution would:
|
Right, so we assume at least 1 of the stakeholders' wallets is not compromised. Notably, this has nothing to do with their HW, unless we have some HW feature that reliably let's stakeholders check the H is consistent with the associated unvault Tx.
Well, isn't it information internal to the previous Tx? |
One of their HW* if it can be generated by the HW. If you are the last honest stakeholder standing, your HW won't send rogue signatures to the other participants. Also, there is the brittle argument of the watchtower ACK that may one day be checked on the HW.
Your transaction refers the outpoints it spends, therefore it's part of your transaction's input. |
That's what I was getting at with ....
If that feature is robust, then the assumption becomes 'at least one of the stakeholders' HW is not compromised'.
ah yeah of course! |
Are you suggesting the WT could refuse to ACK if it notices the inconsistency (H incorrect)? |
Yes but the premise is wrong, they don't need to verify it but to trust the HW (they don't re-compute the signature by hand each time they sign, they just assume that the HW does its job right).
Well watchtowers do verify signatures before ACKing |
Ok. If the check is fully automated, then the trust is on the HW software. That's much better in terms of UX. Is this in the revault-compatibility HW features list somewhere? |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given my small comment,
ACK 147faea
My last approach is clearly not going to work for HWs (they can't bear storing an infinite amount of descriptors..). I'm now thinking of stuffing a short-channel-id in |
In order for watchtowers to be able to fee-bump Cancel and Emergencies transactions and to get around transactions pining, stakeholders exchange
ANYONECANPAY | ALL
signatures.It was known that the malleability introduced could cause some issues, however they were minors and mostly considered in the realm of fee bumping (eg stripping the fee bumping input). Now, some design decisions make it actually practical to DOS the operation by merging Cancel or Emergencies transactions together (effectively burning an entire input to fees) under certain conditions.
Consider the Cancel transaction.
Two deposit transactions paying to the same address for the same amount will create a transaction chain ultimately paying to the Cancel output (same address and amount, as we reuse keys across the transaction chain and have static fees).
The
ACP | ALL
will not (as would aACP | SINGLE
) commit to the input index used, it can therefore be freely placed as second, third, or whatever input in a transaction given that this transaction contains a single output to the Cancel utxo.Thus, the signature would be valid as a second input of a second transaction. It would effectively result in burning an entire vault.
Therefore we need a way to commit to a specifc Unvault txo (or Deposit for an Emergency) per transaction or to the index in the transaction. There are many ways to do so:
ACP | SINGLE
which would prevent it to be used asnth
input in another transaction.nSequence
andnLockTime
unused bits (like Lightning does) to commit to part of the bits of the spent outpoint. However we could not stuff more than 48 bits which would make bruteforce way more practical when considering an attack from a miner.