{"type":"rich","version":"1.0","author_name":"npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","author_url":"https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-21\n📝 Original message:On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:\n\u003e On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e This doesn't completely close malleability (which should be documented in\n\u003e \u003e the BIP), so I'm not sure it's worth the cost, especially if closing\n\u003e \u003e malleability later on would need more. How about specifying flags upfront\n\u003e \u003e in the UTXO-creating transaction specifying which parts the signature\n\u003e \u003e will cover? This would allow implementation of fully malleability-proof\n\u003e \u003e wallets.\n\u003e \n\u003e As far as I see it the only remaining venues for malleability are the use\n\u003e of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any use\n\u003e of non-sighash_all flags is already an explicit permission to modify the\n\u003e transactions, by adding and removing inputs and outputs, so I don't see how\n\u003e these can be made non-malleable. Am I missing something?\n\nSigner malleability is still a notable concern needing consideration. Ideally, \nwallets should be trying to actively CoinJoin, bump fees on, etc any pending \ntransactions in the background. These forms of malleability affect nearly as \nmany real use cases as third-party malleability.\n\nLuke"}