Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-13 📝 Original message:I think this hardfork is ...

📅 Original date posted:2015-05-13
📝 Original message:I think this hardfork is dead-on-arrival given the ideas for OP_CHECKSIG
softforking. Instead of referring to previous transactions by a normalised
hash, it makes better sense to simply change the outpoints in the signed data
and allow nodes to hotfix dependent transactions when/if they are malleated.
Furthermore, the approach of using a hash of scriptPubKey in the input rather
than an outpoint also solves dependencies in the face of intentional
malleability (respending with a higher fee, or CoinJoin, for a few examples).

These aren't barriers to making the proposal or being assigned a BIP number if
you want to go forward with that, but you may wish to reconsider spending time
on it.

Luke


On Wednesday, May 13, 2015 12:48:04 PM Christian Decker wrote:
> Hi All,
>
> I'd like to propose a BIP to normalize transaction IDs in order to address
> transaction malleability and facilitate higher level protocols.
>
> The normalized transaction ID is an alias used in parallel to the current
> (legacy) transaction IDs to address outputs in transactions. It is
> calculated by removing (zeroing) the scriptSig before computing the hash,
> which ensures that only data whose integrity is also guaranteed by the
> signatures influences the hash. Thus if anything causes the normalized ID
> to change it automatically invalidates the signature. When validating a
> client supporting this BIP would use both the normalized tx ID as well as
> the legacy tx ID when validating transactions.
>
> The detailed writeup can be found here:
> https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
>
> @gmaxwell: I'd like to request a BIP number, unless there is something
> really wrong with the proposal.
>
> In addition to being a simple alternative that solves transaction
> malleability it also hugely simplifies higher level protocols. We can now
> use template transactions upon which sequences of transactions can be built
> before signing them.
>
> I hesitated quite a while to propose it since it does require a hardfork
> (old clients would not find the prevTx identified by the normalized
> transaction ID and deem the spending transaction invalid), but it seems
> that hardforks are no longer the dreaded boogeyman nobody talks about.
> I left out the details of how the hardfork is to be done, as it does not
> really matter and we may have a good mechanism to apply a bunch of
> hardforks concurrently in the future.
>
> I'm sure it'll take time to implement and upgrade, but I think it would be
> a nice addition to the functionality and would solve a long standing
> problem :-)
>
> Please let me know what you think, the proposal is definitely not set in
> stone at this point and I'm sure we can improve it further.
>
> Regards,
> Christian