📅 Original date posted:2015-11-03
📝 Original message:On Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote:
> I am still very much intrigued by Luke's idea of having empty scriptsigs
> and ship the signatures in external scripts, however the proposal uses the
> on-the-fly normalization because we have no good way of relaying the
> external scripts. Since we are still in the drafting phase I am open to
> suggestions and if there is a good/working solution I can amend/withdraw
> the proposal.
Changing the network protocol is trivial in comparison to making a permanent
increase in UTXO set costs.
> As for open venues for malleability, I'm not sure we can fix them at all,
> after all the ability of a single signer to doublespend by
> appending/replacing inputs/outputs in an arbitrary fashion is not fixable
> IMHO and will cause any future transaction building on its outputs to be
> orphaned. What would the perfect properties for such a fix be?
The problem isn't changing inputs/outputs, but that such changes invalidate
later spends. In particular, note that wallets *should ideally* be actively
trying to make transfers using multiple malleated versions of the same
payment.
So the way to make an anti-malleable wallet, would be to strictly enforce the
no-address-reuse rule on payments received (note this has no effect on
other/current wallets) and rely only on the hash of that scriptPubKey+value
for the input in subsequent transactions. This way, no matter what inputs or
other outputs the transaction paying the address/invoice uses, the subsequent
transaction ignores them and remains valid. (I am not suggesting this as a
mandatory change that all wallets must adopt to receive the current semi-
malleability protection you propose - only that it be *possible* for wallets
to upgrade to or offer in the future.)
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:44:06
in reply to nevent1q…822w
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:44:06Event JSON
{
"id": "28fc30420f429cb166bcca9394cf843a66abea5bc21c71d7ba3875a042ed21b2",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159846,
"kind": 1,
"tags": [
[
"e",
"59e25977e31b6de547dc99825f6bc9fc8d0d57f8dc5978611471ad70444e93b2",
"",
"root"
],
[
"e",
"ade3dbd6f15fce294bd8f0e2b5ecceb4eb0546a4ba8982f571bf8e5144deceb5",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2015-11-03\n📝 Original message:On Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote:\n\u003e I am still very much intrigued by Luke's idea of having empty scriptsigs\n\u003e and ship the signatures in external scripts, however the proposal uses the\n\u003e on-the-fly normalization because we have no good way of relaying the\n\u003e external scripts. Since we are still in the drafting phase I am open to\n\u003e suggestions and if there is a good/working solution I can amend/withdraw\n\u003e the proposal.\n\nChanging the network protocol is trivial in comparison to making a permanent \nincrease in UTXO set costs.\n\n\u003e As for open venues for malleability, I'm not sure we can fix them at all,\n\u003e after all the ability of a single signer to doublespend by\n\u003e appending/replacing inputs/outputs in an arbitrary fashion is not fixable\n\u003e IMHO and will cause any future transaction building on its outputs to be\n\u003e orphaned. What would the perfect properties for such a fix be?\n\nThe problem isn't changing inputs/outputs, but that such changes invalidate \nlater spends. In particular, note that wallets *should ideally* be actively \ntrying to make transfers using multiple malleated versions of the same \npayment.\n\nSo the way to make an anti-malleable wallet, would be to strictly enforce the \nno-address-reuse rule on payments received (note this has no effect on \nother/current wallets) and rely only on the hash of that scriptPubKey+value \nfor the input in subsequent transactions. This way, no matter what inputs or \nother outputs the transaction paying the address/invoice uses, the subsequent \ntransaction ignores them and remains valid. (I am not suggesting this as a \nmandatory change that all wallets must adopt to receive the current semi-\nmalleability protection you propose - only that it be *possible* for wallets \nto upgrade to or offer in the future.)\n\nLuke",
"sig": "d0a967659c4a11e61eb8f278773719886301be7ecd15066b33c3a143117e1b32230c7d418d82b5333b47c99cd3c4e5408d7aa42d88b27488244e45148bbde983"
}