Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-15 📝 Original message:On Friday, May 15, 2015 ...
📅 Original date posted:2015-05-15
📝 Original message:On Friday, May 15, 2015 9:54:55 AM s7r wrote:
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, ...
Assuming you mean one output per scriptPubKey (and not limiting tx to one
output), the alternative is essentially undefined, and creates real problems
for Bitcoin today. It's not something we should go out of the way to support
or encourage. Therefore, regardless of whatever other options are available, I
would like to see a scriptPubKey-only sighash type for strong safety within
all malleability situations (including CoinJoin and other sender-respends)
that more advanced wallet software could take advantage of in the future
(while strictly enforcing no-reuse on its own wallet to avoid known replays).
Luke
📝 Original message:On Friday, May 15, 2015 9:54:55 AM s7r wrote:
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, ...
Assuming you mean one output per scriptPubKey (and not limiting tx to one
output), the alternative is essentially undefined, and creates real problems
for Bitcoin today. It's not something we should go out of the way to support
or encourage. Therefore, regardless of whatever other options are available, I
would like to see a scriptPubKey-only sighash type for strong safety within
all malleability situations (including CoinJoin and other sender-respends)
that more advanced wallet software could take advantage of in the future
(while strictly enforcing no-reuse on its own wallet to avoid known replays).
Luke