Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker <decker.christian@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

Hm, that is true as long as the signer is the only signer of the
transaction, otherwise he'd be invalidating the signatures of the other
signers. That can however be fixed by having a canonical ordering of Inputs
and Outputs, which has been discussed before in order to decrease
information that can be gained about the spender. Maybe we can defer to
that effort?

On Wed, Oct 21, 2015 at 10:41 AM Luke Dashjr <luke@dashjr.org> wrote:

> On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:
> > On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <luke@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@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
>

[-- Attachment #2: Type: text/html, Size: 3378 bytes --]