What the "average user" needs to know about Transaction Mutability

[justusranvier]

I should read the code, but I would assume that the transaction ID is a 256 bit hash of the transaction details. If so, then it should take quite a birthday attack to create a valid alternate transaction ID. If the ID isn't a hash of the transaction details, then where is the hole in this idea, because it seems readily obvious.

Because of the way transactions are constructed, the data that is signed is a subset of the data that is hashed. It's possible to change the transaction in ways that do not invalidate the signatures, but do change the hash.

For some types of transactions this is a useful and necessary property. For other types of transactions (most of what happens on the blockchain today), it is a nuisance that wallet software must be careful to account for.

If you're running an exchange whose wallet does not handle mutability correctly, and also makes several other errors at the same time, you can end up losing a lot of bitcoins.

[1715124620]

1715124620

[1715124620]

1715124620

[1715124620]

1715124620

[1715124620]

1715124620

[Peter R]

- What should BitPay do if it receives a valid transaction that was built using unconfirmed outputs while the network was under malleability attack?

As per the standard I propose: ignore it until it makes it into a block.
If this behaviour was standard then customers / wallet apps would quickly learn better than to do this.

Interesting.  

So if the transaction is questionable, the BitPay receipt, instead of saying "PAID," would say "UNABLE TO CONFIRM PAYMENT UNTIL NEXT BLOCK."  It is then up to the merchant to decide what to do.  

BitPay could provide an "issue refund" button to immediately send those same coins back to the customer, should the customer be unable to wait.   Or if the merchant knows the customer, then he might say "don't worry about it, it'll be fine and if not just get me tomorrow."  Lastly, if the customer is going to be eating in the cafe anyways, they'll just wait.  

Since these questionable transactions should be very rare [especially with better wallet coin control], perhaps this is a workable solution.  

[Rampion]

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

I disagree.This is a very popular use case, and there's no reason that it can't work "well enough" in the real world.

Consider this typical scenario of a pub selling beer for bitcoin:
* we have a well connected node
* we receive a ZC txn for the beer composed entirely of confirmed UTXO as its inputs (even just 1 block deep)
* we listen for N seconds and do not observe other txns that double spend our ZC txn's inputs
* our ZC txn pays the appropriate fee to be included in a block quickly

Should we give the beer to this bloke right away, or wait for his txn to make it into a block?

I'd argue we're pretty safe just giving him his beer. It's worth all of $5.50, and the chance of a double spend invalidating that txn, given the above observations, is vanishingly small. Yes, he might:
* have a node connected to hashpower we're not aware of / well connected to
* be able to broadcast his double spend txn to that part of the network without us noticing it
* be lucky and get it into a block
* be really fast at drinking his beer and running out the door

But it's not bloody likely :-)

Honest customers will always outnumber this guy 1000:1.

No, the chance of an invalid transaction is not vanoshingly small if the buyer has used unconfirmed change. "Listening for N seconds" won't work, I had ALL my transactions mutated since the bot started spamming and most of them were mutated +4 minutes after the original was broadcasted, and still ALL the mutated transactions made it into blocks invalidating the original ones I broadcasted.

The attacker must have nodes very well connected with pools.

[Syke]

"Listening for N seconds" won't work, I had ALL my transactions mutated since the bot started spamming and most of them were mutated +4 minutes after the original was broadcasted, and still ALL the mutated transactions made it into blocks invalidating the original ones I broadcasted.

The attacker must have nodes very well connected with pools.

I'd like to understand how that worked. In 4 minutes, your TX should have propogated across the whole network. I don't see how a mutated TX could have beat yours to the pools unless the attacker mined the block himself. The mutated TX must have been transmitted before the 4 minutes.

[Rampion]

"Listening for N seconds" won't work, I had ALL my transactions mutated since the bot started spamming and most of them were mutated +4 minutes after the original was broadcasted, and still ALL the mutated transactions made it into blocks invalidating the original ones I broadcasted.

The attacker must have nodes very well connected with pools.

I'd like to understand how that worked. In 4 minutes, your TX should have propogated across the whole network. I don't see how a mutated TX could have beat yours to the pools unless the attacker mined the block himself. The mutated TX must have been transmitted before the 4 minutes.

Well, the mutated transactions beat the original ones, even tough they were broadcasted 2,3 or 4 minutes later - not only one time, but multiple times. I guess mine is a poorly connected node (its not even a full node, 8 connections only), while the attacker has nodes very well connected to pools.

Furthermore, I run Bitcoin via Tor (as I think everybody should do) - I don't know if that could make my transactions "slower" than those of the attacker.

[PrintCoins]

And if I understand correctly, this is an issue where the THEIVES have to act QUICKLY.

If you wait 10-20 minutes (confirmations), then there is way too many computers, ie: the whole network with the transaction and question already confirmed and buried under other ones- can't change the hashes now. (lest you do a 51% attack, which presumably again is harder with the passage of time)

The thieves can only copy transactions, they cannot change the contents. Only one of the copies can be included in the blockchain. If further transactions are based on one of the transactions that will never be part of the blockchain, all these transactions will also timeout when the not-included copy does.

This changes nothing on the usual practice that once a transaction is part of the blockchain it is safe to trust it. A 51% attack actually rewrites the blockchain.

I don't know if I would call the attackers thieves. By the looks of things they aren't making off with bitcoins, they are just invalidating transactions that others are making, and thus making the db's of exchanges inconsistent with the actual bitcoins they possess. They are more like griefers.

The piece of the puzzle I don't understand is how this is a problem for exchanges. Since the very start of bitcoin it was considered that 6 confirmations were required before a transaction was considered valid for any serious financial situation. This probably could drop down to 1 or two conformations since the network is pretty robust now, but considering 0 confirmations as being worth anything? Heck, you wouldn't even do that for an e-commerce site.

My basic conceptual model of how you build any online service using bitcoins as a unit of account is you have a bitcoin address for a user, and you get bitcoins received at that address with 1 confirmation and use that to base the user's balance off of. In your db you then record transfers to and from that user and add and subtract accordingly through a transaction log. So the balance is the sum of bitcoins received + credits - debits.

Not really rocket science, and I feel something must be missing in my view as this very basic system seems the most obvious to me, and it seems like it would be immune to the problems that are plaguing all of the exchanges. Is it just that they were dancing on the edge of the razor of zero-confirm transactions because they felt that turn around was that important?

Please, tell me where I am wrong. Something is not adding up.

[anth0ny]

The piece of the puzzle I don't understand is how this is a problem for exchanges.

My understanding is that some people were using transaction mutability to make it look like they never got paid for their BTC withdrawal. They were then convincing the exchange to (I believe manually) resend a new transaction because they claimed the original transaction never went through.

[DeathAndTaxes]

I don't know if I would call the attackers thieves. By the looks of things they aren't making off with bitcoins, they are just invalidating transactions that others are making, and thus making the db's of exchanges inconsistent with the actual bitcoins they possess. They are more like griefers.

There were two different scenarios involving the mutability.

The first was the attackers were ONLY modifying their OWN transactions.  They would then report the tx failed, MtGox would lookup the tx id, see it wasn't in any block and pay them a second (and third? and twenty eight?) time.

After MtGox wised up 30 days later someone (possibly the same people, or new people) began mass modifying the tx of OTHERS.  This particular event has no direct ecnomic value and your right it is likely griefers, or someone looking to damage the credability of the Bitcoin network.  When people are talking about thieves they are talking about the former event.

[PrintCoins]

I don't know if I would call the attackers thieves. By the looks of things they aren't making off with bitcoins, they are just invalidating transactions that others are making, and thus making the db's of exchanges inconsistent with the actual bitcoins they possess. They are more like griefers.

There were two different scenarios involving the mutability.

The first was the attackers were ONLY modifying their OWN transactions.  They would then report the tx failed, MtGox would lookup the tx id, see it wasn't in any block and pay them a second (and third? and twenty eight?) time.

After MtGox wised up 30 days later someone (possibly the same people, or new people) began mass modifying the tx of OTHERS.  This particular event has no direct ecnomic value and your right it is likely griefers, or someone looking to damage the credability of the Bitcoin network.  When people are talking about thieves they are talking about the former event.

Ok, now I finally grasped the attack I think on gox.

In my own wallet(s)
Transaction A is created
Transaction B is created Based on A.
Transaction C based on B is sent to Gox
  ... gox acts idiotically and recognizes C before B is finalized
  Bitcoins bumped up in my gox account
I invalidate B so the bitcoins are still in my wallet
I withdraw bitcoins from gox and it says ok as its database of my account shows bitcoins it never really got.
I have just doubled my money

Rinse and repeat until gox notices the problem.

Sounds like gox would be empty in short order.

So then they wise up and shut the door (or they just see no money in their wallet). If they didn't lose most of their bitcoins in the process then they could just make a minor tweak to their process and only recognize confirmed transactions. Unfortunately I think they have been drained dry and are just looking for a way to open the bank with no money in the vault and prevent a run. They need to get some reserve of bitcoins back in their vaults to make payouts so people can feel calm and safe, and I suspect their bluster about waiting till bitcoin fixes itself is a delaying tactic.

Or if you want to be optimistic, gox could have kept 90% of their funds in a cold wallet and all is safe. They could easily verify such things to the public though and their lack of transparency is discouraging. A simple, "look guys, don't sweat it, here is one of our many addresses in cold storage with $1M in bitcoin and this message was signed from its private key. Chill out, and we will have things flowing smoothly in a jiffy."

Unfortunately, I am a pessimist, and this is the second time that gox has f-ed up on a massive scale. I think this will lead to a level of disappointment that wil make mybitcoin look like a small pickpocketing.

[DeathAndTaxes]

Ok, now I finally grasped the attack I think on gox.

<snip>

No the attack didn't involve tx from the user or deposits as both would require confirmations and any breakdown due to malleability would have not resulted in extra payments.

Simple version:
User has x BTC on his MtGox account.
User created a withdraw request for x BTC.
MtGox creates a withdraw transfer with tx id "A".
MtGox's wallet is creating "broken" tx anyways which make legitimate issues for tx propagation.
User takes tx id "A", modifies the mutable parts and this produced tx id "B".
Tx "B" ends up in a block and user has received x BTC.
User notifies MtGox they haven't received their withdraw.
MtGox looks in blockchain and there is no tx "A" and thus assumes (incorrectly) this means user has not been paid.
MtGox creates a new tx ("C") for x BTC to the address specified by user and has now paid the user twice.

User could not either deposit the double bitcoins and pull the con again or modified tx "C" so it is tx "D" and report a second failure ("MtGox tx C didn't confirm either please pay me again, I mean pay me) to continue to the theft.

MtGox has had legitimate issues with withdraws not being confirmed (due to their own errors) for more than a month.  How many times did an attacker pull the attack described above? How many bitcoins were double paid?

Or if you want to be optimistic, gox could have kept 90% of their funds in a cold wallet and all is safe.

Or they saw all these requests as valid normal outflows and when the hot wallet got low, moved funds from one or more cold wallets to replenish the hot wallet so the could continue to double, triple, quadruple pay withdraw requests.

Only MtGox knows how much they overpaid and they simply are not talking.

[tvbcof]

... someone (possibly the same people, or new people) began mass modifying the tx of OTHERS.  This particular event has no direct ecnomic value and your right it is likely griefers, or someone looking to damage the credability of the Bitcoin network.  ...

What I still do not fully understand is whether capturing and manipulating the transaction ID of a transaction would result in neither the original nor the modification making it to confirmation due to the perception of a double-spend attack, or would one win out and in all cases the desired transaction is accomplished.

The former constitutes a potentially severe DOS attack.  The latter would not be that big a deal (in my own use-case and as far as I currently understand.)

Or is it the case currently that the end result of an intercept+modify_hash+redistribute attack would be somewhat left to chance due to differences in the protocol implementation and such-like.

[DeathAndTaxes]

... someone (possibly the same people, or new people) began mass modifying the tx of OTHERS.  This particular event has no direct ecnomic value and your right it is likely griefers, or someone looking to damage the credability of the Bitcoin network.  ...

What I still do not fully understand is whether capturing and manipulating the transaction ID of a transaction would result in neither the original nor the modification making it to confirmation due to the perception of a double-spend attack, or would one win out and in all cases the desired transaction is accomplished.

One transaction will always be confirmed (assuming the original tx is valid).  Even in a traditional double spend nodes (different outputs for same inputs), each node will independently rely the original and drop the duplicate.  "Original" and "duplicate" in this context are based on which version a particular node sees first.  In a race situation, it will not necessarily be the same for each node.  One of the two copies ends up in the memory pool of miners, and eventually one miner will put the copy it knows about into the next block.

Any tx can be duplicated but to be included in the next block it has to win a race with the original to at least some % of the miners.   MtGox made this race incredibly easy by creating transactions with non-canonical signatures (among other issues) which were dropped by most nodes.   So the "good original" had essentially no chance of making it to a miner which is why so many "legit" withdraw requests were broken and never confirmed.  No miner ever became aware of them because they were dropped by relay nodes between MtGox and the miners.   To spoof MtGox, the attacker didn't have to split miliseconds and work against the clock to win the "race", they could manually modify the broken tx and rebroadcast it minutes or hours later and still be included in the next block.  It wasn't any more of a "race" between two runners where one of them dies on the starting line, no matter how slow the other run is, eventually he is going to "win".

The one issue "you" as a user need to be more aware of is that the change from a tx is identified by its hash (and index).   If you spend unconfirmed change BEFORE a tx is included in a block, it is possible the duplicate will be included instead.  The original tx will not have an issue (both the tx you created and the mutated tx "do" the same thing) however the unconfirmed change is no longer valid.  It refers to the wrong tx id so the subsequent tx will fail.

[StevenS]

There are other forms of mutation involving alterations to the script.  There have been proposals to prohibit obviously-mutated scripts (like scripts with a bunch of no-ops stuck on the end), but going beyond the obviously-mutated scripts risks accidentally banning useful scripts or future uses of the script system not currently foreseen.

I don't understand. Isn't the script signed? Or are you talking about something other than the output scripts?

[justusranvier]

What I still do not fully understand is whether capturing and manipulating the transaction ID of a transaction would result in neither the original nor the modification making it to confirmation due to the perception of a double-spend attack, or would one win out and in all cases the desired transaction is accomplished.

The former constitutes a potentially severe DOS attack.  The latter would not be that big a deal (in my own use-case and as far as I currently understand.)

Or is it the case currently that the end result of an intercept+modify_hash+redistribute attack would be somewhat left to chance due to differences in the protocol implementation and such-like.

Before there were griefers on the network mutating transactions it was safe to spend your own unconfirmed change, because you could reasonably assume that you weren't going to invalidate your own transaction.

Now it's no longer safe. because you don't know what version of your transaction is going to make it into the blockchain, therefore any transactions you make that reference  unconfirmed change will fail.

This is bad news for wallets that do not manage their outputs well. I'm interested in seeing how these single-key wallets like blockchain.info are affected. Any wallet that tries to keep its entire balance in a single utxo is going to only be usable for spends once per block.

[DeathAndTaxes]

There are other forms of mutation involving alterations to the script.  There have been proposals to prohibit obviously-mutated scripts (like scripts with a bunch of no-ops stuck on the end), but going beyond the obviously-mutated scripts risks accidentally banning useful scripts or future uses of the script system not currently foreseen.

I don't understand. Isn't the script signed? Or are you talking about something other than the output scripts?

The script being modified is the input script.  It contains the signature and thus the entire input script can't be signed (a signature can't be an input for its own signature).  

There are lots of ways they input side of the tx can be modified in such a way which doesn't change the inputs or outputs but does result in a slightly "different" tx and when that is hashed produces a slightly different hash.

A concrete example might help:

ECDSA signatures require a random nonce (S) for security.   If you remember the talk about broken RNG and stolen bitcoins this was because a few wallets reused the same S on mutiple tx and this allows one to compute the private key used for signing.  The pubkey, signature (R) and nonce (S) are stored in the input script for later verification.

ECDSA has a property that for a given payload and private key both S and -S will produce the same signature.  Thus an attacker could take any tx and invert the sign of S and the signature will still verify. This isn't unique to Bitcoin, it is true of any application using ECDSA.   The problem becomes that the "same" tx using S and -S will produce different tx hashes.  Same signature, different hashes.

To prevent mutability of the tx hash requires creating new rules for Bitcoin that limit the scope of a valid transaction.  For example if going forward clients ONLY used an +S value, then -S values could be considered non-standard (and eventually invalid).  This would prevent an attacker from changing the S value to produce the same signature.  Bitcoin would be more restrictive then the underlying ECDSA.  All Bitcoin signatures would be valid ECDSA signatures, but not all valid ECDSA signatures would be valid Bitcoin signatures.

This is just one example there are other elements of the tx protocol which allow similar mutability (without changing the core tx itself, inputs used, outputs used, value to each output, and tx fees).  All of these will have be the restricted to a single valid version to make tx ids immutable.

Sipa has done a lot of good work in outlining the problem and based on what I have read I believe it is only a matter of when not if, tx ids are immutable.


A side note (only read if interested in an alternative).  There is no chance this will be adopted by Bitcoin but it would be a cleaner change which makes sense if starting from a blank sheet of paper.

Anyone designing an alternative to Bitcoin would be best served by moving the signature outside of the tx body.  This is how most cryptographic systems work.

So instead of:

Code:

Some stuff here
Inputs (including the signatures crammed in but obviously not signed because that would be impossible)
Some random stuff here
Outputs
Some more random stuff here

an alt-coin could use a more logical structure like:

Code:

Tx Body (Tx hash = hash of entire tx body)
------------------------
Tx header
Tx Input(s)
Tx Output(s)
------------------------
Tx Signatures -signatures are not part of tx body, they are simply appended to the tx to allow verification.

The Tx body would consist of the header, list of input(s), and list of output(s).   The input would not contain the signature (neither R or S) and wouldn't even need to contain the pubkey (it could be reconstructed from the signature).  If the same format as Bitcoin was used the input would be only (input_txid, input_index).  The entire tx would be hashed.  That is the tx id.  The same hash would be fed to each of the private keys to produce a signature.  The signatures would be appended to the tx body.

To verify a node would take the tx message, remove the signatures (they are just appended after the end of the tx body).  The tx node would hash the tx body (header + input list + output list).  The hash + each signature would be used to reconstruct the public key(s).  The signature(s) would be verified using the tx hash and public key(s).  If the sigantures are valid and the tx is otherwise valid it is now valid.  Tx mutability would not be an issue. [/size]

[tvbcof]

What I still do not fully understand is whether capturing and manipulating the transaction ID of a transaction would result in neither the original nor the modification making it to confirmation due to the perception of a double-spend attack, or would one win out and in all cases the desired transaction is accomplished.

The former constitutes a potentially severe DOS attack.  The latter would not be that big a deal (in my own use-case and as far as I currently understand.)

Or is it the case currently that the end result of an intercept+modify_hash+redistribute attack would be somewhat left to chance due to differences in the protocol implementation and such-like.

Before there were griefers on the network mutating transactions it was safe to spend your own unconfirmed change, because you could reasonably assume that you weren't going to invalidate your own transaction.

Now it's no longer safe. because you don't know what version of your transaction is going to make it into the blockchain, therefore any transactions you make that reference  unconfirmed change will fail.

This is bad news for wallets that do not manage their outputs well. I'm interested in seeing how these single-key wallets like blockchain.info are affected. Any wallet that tries to keep its entire balance in a single utxo is going to only be usable for spends once per block.

Thanks for the input.  Are you quite sure that that is empirically the case, or is it more theoretical?  (That is, transactions work as always whether attacked or not, but one must rely on confirmation rather than transaction hash?)

For my part, I rarely make more than one spend per block cycle.  I'd be totally fine not spending unconfirmed outputs and would be totally fine doing my planning to adhere to such a policy.  I typically only make a handful of transactions per month (if that)  and feel pretty guilty about every spend I make since they are highly subsidized.  I voluntarily pay an unusually high transaction fee.

I'd be delighted to do a bulk of my petty spending work in an off-chain solutions which avoided spamming the global block-chain.  As soon as one which is reliable and trustworthy appears, I'll jump eeen it!

[DeathAndTaxes]

Thanks for the input.  Are you quite sure that that is empirically the case, or is it more theoretical?  (That is, transactions work as always whether attacked or not, but one must rely on confirmation rather than transaction hash?).

Yes it is empirically the case.  A node will become aware of both copies of the transaction.  If you create a given tx (assuming it is otherwise valid) the tx or a copy of it will eventually be confirmed and an attacker can't use this to block transactions, freeze transactions, or destroy transactions.  No core element of a tx can be changed (the inputs used, the number of outputs, the address (well PubKeyHash) of each output, any part of the output script, the value of each output, or the tx fee).

Right now the bitcoin client will display both copies although that is more a reporting issue than an issue with the network itself.  There are pull requests being considered to handle this in a more logical manner (only show one copy of duplicates to the user, only include one copy in the wallet balance).

For my part, I rarely make more than one spend per block cycle.  I'd be totally fine not spending unconfirmed outputs and would be totally fine doing my planning to adhere to such a policy.  I typically only make a handful of transactions per month (if that)  and feel pretty guilty about every spend I make since they are highly subsidized.  I voluntarily pay an unusually high transaction fee.

Then you should have no issue with the issue of broken unconfirmed change outputs.   There are pull requests being considered which will give you the ability to require 1 (or more) confirmations on change before spending in order to avoid even accidentally spending unconfirmed change.  Once confirmed the tx id is immutable baring a re-org of the network.

[iain]

The script being modified is the input script.  There are lots of ways they input side of the tx can be modified in such a way which doesn't change the inputs or outputs but does result in a slightly "different" tx and when that is hashed produces a slightly different hash.

Here is just one example.

ECDSA signatures require a random nonce (S) for security.   If you remember the talk about broken RNG and stolen bitcoins this was because a few wallets reused the same S on mutiple tx and this allows one to compute the private key used for signing.

ECDSA has a property that for a given payload and private key both S and -S will produce the same signature.  Thus an attacker could take any tx and invert the sign of S and the signature will still verify.  However when you now hash they produce unique signatures.

To prevent mutability of the tx hash requires creating new rules for Bitcoin that limit the scope of a valid transaction.  For example if going forward clients ONLY used an +S value, then -S values could be considered non-standard (and eventually invalid).  This would prevent an attacker from changing the S value to produce the same signature.  Bitcoin would be more restrictive then the underlying ECDSA.  All Bitcoin signatures would be valid ECDSA signatures, but not all valid ECDSA signatures would be valid Bitcoin signatures.

This is just one example there are other elements of the tx protocol which allow similar mutability (without changing the core tx itself, inputs used, outputs used, value to each output, and tx fees).  All of these will have be the restricted to a single valid version to make tx ids immutable.

Sipa has done a lot of good work in outlining the problem and based on what I have read I believe it is only a matter of when not if, tx ids are immutable.

Would it help if the protocol was changed so that, from a certain future block onwards, all transactions must identify any previous transaction they're spending one or more outpoint(s) of, not by the hash of the whole previous tx, as is required today, but instead just by the hash of the core parts of the previous tx? (its inputs/outputs/values, not its signatures.) After all, the purpose of a txid is merely to identify a tx, not to "bless" it as valid. That blessing has already happened when either the free-floating transaction was checked (including signature-checked of course!) and accepted into one's mempool, or a block containing the transaction was checked and found to be valid, or both.

This has the wonderful consequence of rendering unnecessary the endless "arms race" of finding sources of malleability and shutting them down one by one - inventing endless new rules (relay ["standardness"] rules or, eventually, validity rules) about how to write an integer, how many OP_DROPs to put here or there, what syntax to use for ECDSA signatures, etc etc ad nauseum. None of this would matter any more. The new-style txid would stay the same.

Validating nodes would need to do a re-indexing of their UTXO database as the switch moment approached, re-labelling all entries as "outpoint #n of [new-style txid for that tx]" rather than "outpoint #n of [old-style txid for that tx]", in order to be ready to do quick lookups from the switch moment onwards. However, this is a purely private matter for each node, to help with its efficiency. Publicly, the stream of new transactions and blocks would simply, seamlessly, switch to using the new-style txids.

Does this break anything?

[DeathAndTaxes]

That certainly is an alternative solution.  The tx id just needs to be a unique way to identify each transaction.  It doesn't necessarily have to include the signature.  It is possible that in the future there will be new tx types (extending the protocol) with different inputs but that isn't an impossible obstacle.   Client support can be added before the switch in the same manner as it will be for any change.  

It would however require clients to compute tx ids "one way" for existing tx in the blockchain (v1 txs) and a different way for future tx (v3 txs).  I think that break with backwards compatibility is what the developers are looking to avoid.

Still if you wanted to compute the tx hash differently and there was consensus for such a breaking change there is a lot that can be done to improve the bitcoin transaction structure.  The signature should not be in the input.  The signature is of the tx, it should be outside the tx.  The input should just deal with the input.  You could also explicitly define the tx fee to avoid issues with implicit fees.  You could use pubkey reconstruction to remove pubkeys from inputs.  The S value could be computed deterministically from the tx hash to bypass the issue of poor PRNG implementation.

So if we are going to do a breaking change well there is a lot of cleanup which can be done.  It would be possible to reduce the size of the average tx by 30% while keeping the same functionality and improving mutability and security.  I don't think that is the route that we will go though as it would involve a breaking change.

[JonesL]

gox says blockchain fixed up something on that