This allows non-malleable transactions for use in off-chain chaining.
This is step 1/3
- Introduce SIGHASH_SPENDANYOUTPUT with unit tests
- Add BIP9 activation with integration tests
- Add flag to tooling
Details
Details
- Reviewers
deadalnix tomtomtom7 - Group Reviewers
Restricted Owners Package (Owns No Changed Paths) Restricted Project
WIP
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- sighash2
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 982 Build 982: arc lint + arc unit
Event Timeline
Comment Actions
I don't think this is a good change. This make a signature reusable. This is not a new proposal, it was discussed ages ago under the name SIGHASH_NOINPUT or something similar. This makes addresses reuse vulnerable. Yes I know, one should not reuse addresses, but that's not a good reason to make them more insecure, just like 0-conf not being 100% secure do not make RBF ok.
Comment Actions
My apologies for stubbornly reopening the discussion but I believe one is still needed; hopefully short yet open. Please consider (along the arguments on the ml):
- MalFix (like this) doesn't "fix" malleability as TXIDs are still malleable. It only serves off-chain chaining transactions by making prev-tx-out invariant on the signature. The primary (if not only) use case for this is a payment channel's "punishment" transaction.
- From the explanation of Joseph Poon (https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-February/000445.html), this flag may actually be needed for LN to function efficiently. If this is the case, not only MalFix would be rather moot, but using this instead would give Cash an edge.
- Yes, transactions with this flag can be replayed to other transactions with the same public key. That is exactly the point of this flag. This is bad in the same way "SIGHASH_NONE" is bad; it has very specific use cases.
We need to look at our goal: if we want to enable more automated trickery that that relies on off chain chaining, this serves our purpose better.
If we want want to solve the other inconveniences of malleability (which I'm sceptical we should), neither MalFix nor this helps.
Technical arguments aside, I think this provides us with a better narrative as we are in some ways ahead of SegWit on the matter
Comment Actions
Added note that scriptPubKey / scriptCode committing obstructs Eltoo.
| src/script/interpreter.cpp | ||
|---|---|---|
| 1410 | Worth noting that this prevents implementing the floating transactions of Eltoo, which require that the UTXO script not be committed in the signature. Preferably scriptCode shouldn't be committed either, so it's not necessary to modify Eltoo scripts to use OP_CODESEPARATOR. (Easy modification in the case of Eltoo updates, but perhaps not so easy for more complex scripts). | |