<oembed><type>rich</type><version>1.0</version><author_name>npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n</author_name><author_url>https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-10-21&#xA;📝 Original message:On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:&#xA;&gt; On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr &lt;luke at dashjr.org&gt; wrote:&#xA;&gt; &gt; On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:&#xA;&gt; &gt; &gt; On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr &lt;luke at dashjr.org&gt; wrote:&#xA;&gt; &gt; &gt; &gt; This doesn&#39;t completely close malleability (which should be&#xA;&gt; &gt; &gt; &gt; documented&#xA;&gt; &gt; &#xA;&gt; &gt; in&#xA;&gt; &gt; &#xA;&gt; &gt; &gt; &gt; the BIP), so I&#39;m not sure it&#39;s worth the cost, especially if closing&#xA;&gt; &gt; &gt; &gt; malleability later on would need more. How about specifying flags&#xA;&gt; &gt; &#xA;&gt; &gt; upfront&#xA;&gt; &gt; &#xA;&gt; &gt; &gt; &gt; in the UTXO-creating transaction specifying which parts the signature&#xA;&gt; &gt; &gt; &gt; will cover? This would allow implementation of fully&#xA;&gt; &gt; &gt; &gt; malleability-proof wallets.&#xA;&gt; &gt; &gt; &#xA;&gt; &gt; &gt; As far as I see it the only remaining venues for malleability are the&#xA;&gt; &gt; &gt; use of sighash flags that are not SIGHASH_ALL, as mentioned in the&#xA;&gt; &gt; &gt; BIP. Any&#xA;&gt; &gt; &#xA;&gt; &gt; use&#xA;&gt; &gt; &#xA;&gt; &gt; &gt; of non-sighash_all flags is already an explicit permission to modify&#xA;&gt; &gt; &gt; the transactions, by adding and removing inputs and outputs, so I&#xA;&gt; &gt; &gt; don&#39;t see&#xA;&gt; &gt; &#xA;&gt; &gt; how&#xA;&gt; &gt; &#xA;&gt; &gt; &gt; these can be made non-malleable. Am I missing something?&#xA;&gt; &gt; &#xA;&gt; &gt; Signer malleability is still a notable concern needing consideration.&#xA;&gt; &gt; Ideally,&#xA;&gt; &gt; wallets should be trying to actively CoinJoin, bump fees on, etc any&#xA;&gt; &gt; pending&#xA;&gt; &gt; transactions in the background. These forms of malleability affect nearly&#xA;&gt; &gt; as&#xA;&gt; &gt; many real use cases as third-party malleability.&#xA;&gt; &gt; &#xA;&gt; &gt; Luke&#xA;&gt; &#xA;&gt; How is signer malleability still a problem if we remove the signatures from&#xA;&gt; the transaction ID of the transaction and all preceding transactions? The&#xA;&gt; signer can re-sign a transaction but it won&#39;t change the transaction ID.&#xA;&#xA;The signer can also change the order of the inputs, the inputs themselves, &#xA;add/remove outputs, etc... all which should be possible without becoming a &#xA;different logical transaction. The only unique property of the logical &#xA;transaction is the scriptPubKey/address.&#xA;&#xA;Luke</html></oembed>