Rune Kjær Svendsen [ARCHIVE] on Nostr: 📅 Original date posted:2014-02-12 📝 Original message:Instead of trying to ...

📅 Original date posted:2014-02-12
📝 Original message:Instead of trying to remove the possibility of transaction
malleability, would it make sense to define a new, "canonical
transaction hash/ID" (cTxID), which would be a hash of the part of the
transaction data which we know is not malleable, and have clients use
this cTxID internally, thus making the traditional transaction hash
irrelevant for a client to function correctly?

We already have a non-malleable transaction hash: the hash that is
signed, ie. the transaction with each scriptSig replaced by the
scriptPubKey it redeems. This could be the cTxID.

Or is this simply a too fundamental change to the way bitcoin-qt (and
all other clients) work in order to be feasible?

As far as I can see, it completely solves the issue of not having a
canonical ID for a transaction, but it also increases the
computational requirements for a node. For one, as far as I can see,
it requires the node to index all transactions, because in order to
calculate a cTxID, it would be necessary to fetch all transactions
referred to by the transaction in question, in order to pull in the
scriptPubKeys that are redeemed.


On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
>> Hello all,
>>
>> it was something I planned to do since a long time, but with the
>> recent related issues popping up, I finally got around to writing a
>> BIP about how we can get rid of transaction malleability over time.
>>
>> The proposed document is here: https://gist.github.com/sipa/8907691
>>
>> I expect most rules to not be controversial. Maybe rules 1 and 3, as
>> they require modifications to wallet software (Bitcoin Core 0.9 and
>> BitcoinJ already implement it, though) and potentially invalidate some
>> script functionality. However, these new rules remain optional and
>> controlled by an nVersion increase.
>>
>> Comments please!
>
> You should probably add making CHECKMULTISIG require the dummy value to
> be exactly equal to OP_FALSE; verifying that in the transaction itself is
> laborious. A more subtle example is we may want both CHECKSIG and
> CHECKMULTISIG to fail the transaction if the signature is invalid but
> not exactly equal to OP_FALSE; some transaction forms are significantly
> more compact if you can have failed signatures, but that's a source of
> malleability. (are there counter examples people can think of?)
>
>
> But as I said on IRC, I'm a bit hesitant to bake in assumptions about
> malleability when we have no solid idea if ECC signatures are or are not
> malleable on a fundemental level; if "whack-a-mole" anti-malleability is
> all we've got it could be ugly if a break is found. Similarly, we may
> find we missed something, or some needed change makes the malleability
> rules difficult to work with for some new script type that is required.
>
> I'd rather see a new CHECKSIG mode for the case where malleability
> absolutely must be eliminated - certain multi-party protocols - and fix
> wallet software instead. (the malleability problems people see are
> closely related to inability to handle double-spends and reorgs) But I
> can easily see that being an impossible goal engineering wise...
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>