📅 Original date posted:2015-10-21
📝 Original message:On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:
> On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <luke at dashjr.org> wrote:
> > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:
> > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke at dashjr.org> wrote:
> > > > This doesn't completely close malleability (which should be
> > > > documented
> >
> > in
> >
> > > > the BIP), so I'm not sure it's worth the cost, especially if closing
> > > > malleability later on would need more. How about specifying flags
> >
> > upfront
> >
> > > > in the UTXO-creating transaction specifying which parts the signature
> > > > will cover? This would allow implementation of fully
> > > > malleability-proof wallets.
> > >
> > > As far as I see it the only remaining venues for malleability are the
> > > use of sighash flags that are not SIGHASH_ALL, as mentioned in the
> > > BIP. Any
> >
> > use
> >
> > > of non-sighash_all flags is already an explicit permission to modify
> > > the transactions, by adding and removing inputs and outputs, so I
> > > don't see
> >
> > how
> >
> > > these can be made non-malleable. Am I missing something?
> >
> > Signer malleability is still a notable concern needing consideration.
> > Ideally,
> > wallets should be trying to actively CoinJoin, bump fees on, etc any
> > pending
> > transactions in the background. These forms of malleability affect nearly
> > as
> > many real use cases as third-party malleability.
> >
> > Luke
>
> How is signer malleability still a problem if we remove the signatures from
> the transaction ID of the transaction and all preceding transactions? The
> signer can re-sign a transaction but it won't change the transaction ID.
The signer can also change the order of the inputs, the inputs themselves,
add/remove outputs, etc... all which should be possible without becoming a
different logical transaction. The only unique property of the logical
transaction is the scriptPubKey/address.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:43:43
in reply to nevent1q…h5vl
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:43:43Event JSON
{
"id": "b4ca171cb20a0d334a3fd960696cae0ff4a7150a1006e78123b7f148e09e75d4",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159823,
"kind": 1,
"tags": [
[
"e",
"e71cb83b97f22f5353a76bf12fac79eec2c215f6e13d11b1eb608f076bcfae47",
"",
"root"
],
[
"e",
"287aedce9a1aa3f9dd1c8d7ae6949d9cd552588c200d389bc5cbdbe4dccb6e01",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2015-10-21\n📝 Original message:On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:\n\u003e On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:\n\u003e \u003e \u003e On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e \u003e \u003e This doesn't completely close malleability (which should be\n\u003e \u003e \u003e \u003e documented\n\u003e \u003e \n\u003e \u003e in\n\u003e \u003e \n\u003e \u003e \u003e \u003e the BIP), so I'm not sure it's worth the cost, especially if closing\n\u003e \u003e \u003e \u003e malleability later on would need more. How about specifying flags\n\u003e \u003e \n\u003e \u003e upfront\n\u003e \u003e \n\u003e \u003e \u003e \u003e in the UTXO-creating transaction specifying which parts the signature\n\u003e \u003e \u003e \u003e will cover? This would allow implementation of fully\n\u003e \u003e \u003e \u003e malleability-proof wallets.\n\u003e \u003e \u003e \n\u003e \u003e \u003e As far as I see it the only remaining venues for malleability are the\n\u003e \u003e \u003e use of sighash flags that are not SIGHASH_ALL, as mentioned in the\n\u003e \u003e \u003e BIP. Any\n\u003e \u003e \n\u003e \u003e use\n\u003e \u003e \n\u003e \u003e \u003e of non-sighash_all flags is already an explicit permission to modify\n\u003e \u003e \u003e the transactions, by adding and removing inputs and outputs, so I\n\u003e \u003e \u003e don't see\n\u003e \u003e \n\u003e \u003e how\n\u003e \u003e \n\u003e \u003e \u003e these can be made non-malleable. Am I missing something?\n\u003e \u003e \n\u003e \u003e Signer malleability is still a notable concern needing consideration.\n\u003e \u003e Ideally,\n\u003e \u003e wallets should be trying to actively CoinJoin, bump fees on, etc any\n\u003e \u003e pending\n\u003e \u003e transactions in the background. These forms of malleability affect nearly\n\u003e \u003e as\n\u003e \u003e many real use cases as third-party malleability.\n\u003e \u003e \n\u003e \u003e Luke\n\u003e \n\u003e How is signer malleability still a problem if we remove the signatures from\n\u003e the transaction ID of the transaction and all preceding transactions? The\n\u003e signer can re-sign a transaction but it won't change the transaction ID.\n\nThe signer can also change the order of the inputs, the inputs themselves, \nadd/remove outputs, etc... all which should be possible without becoming a \ndifferent logical transaction. The only unique property of the logical \ntransaction is the scriptPubKey/address.\n\nLuke",
"sig": "dfe6ab75d725c3f3efbc48a94262444dc4a0de09e3a06c67c66d125c4712ad2b51047c43c0f6d5c2c9b027e1f38af40e15ca17a40e67faae42214e460db388f4"
}