Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-03 📝 Original message:On Tuesday, November 03, ...
📅 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
📝 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