add checksum to transactions? #3181

In https://bitcointalk.org/index.php?topic=298545.msg3198434#msg3198434, gmaxwell wrote about the danger of sending large numbers of Bitcoins in a single transaction:

One bitflip while making a transaction with these fat txouts and its $10 million in paper value down the drain.

Is this a real concern? If a bit gets flipped when broadcasting a transaction, could it cause the transacted coins to become unspendable forever?

If so, would it be better if transactions contained a checksum, much like bitcoin addresses do, such that random bitflips are detectable?

The problem is a bitflip making the transaction, not broadcasting it (where there is already multiple checksums in place). If you bitflip during creation, your checksum will account for the bitflip, not detect it!

As luke says, once it's signed— no problem, a bit flip will invalidate the signature. But if you sign the wrong thing because of a bitflip before signing it.... Well, it's not likely, but its an unnecessary risk in virtually all cases.

So is it better to send multiple smaller outputs rather than a single large one when sending a large amount? The last time I tried to use bitcoind to send multiple outputs to a single address it didn't allow it. Or is it better to make a lot of separate transactions rather than a single transaction with multiple outputs? Would a bitflip invalidate all the outputs of a single transaction? I guess it could.

Maybe the client should warn if I try to send too large an amount in a single transaction, or even offer to split it into the appropriate amount of smaller transactions.

Or is there some way the client could check the transaction after signing it to make sure it's valid?

I hadn't considered until I read gmaxwell's forum post that it was unsafe to assume that bitcoind would sign transactions correctly.

bitcoind verifies the signature after signing.

I don't see any need to do multiple smaller outputs.

It seems like there's a different of opinion here. Does 'bitflip' pose a risk of fund loss or not? It would be good to get some agreement on this point so we're not accidentally either spreading FUD or being complacent.

@jgarzik Verifying the signature does nothing relevant here, alas, as it's not a concern about ecdsa leaking the private key.

The risk is an error can cause the change addresses to be wrong or cause the values to be wrong. Nothing currently guards against this (though, obviously, it's unlikely). Then it goes on to sign that wrong value, it validates fine, but doesn't do what you want. We could and should go an verify more after signing, though doing that wouldn't completely eliminate change risk.

The behavior I was complaining about that Dooglus is talking about is where someone puts 100k btc in a single coin and then makes a bunch of small payments with ~100k change each time. It's taking a small but unnecessary risk to move huge amounts of coins when the actual amount being moved is small.

So many bitflips can happen.. Isn't the txid almost the transaction checksum?

someone puts 100k btc in a single coin and then makes a bunch of small payments with ~100k change each time. It's taking a small but unnecessary risk to move huge amounts of coins when the actual amount being moved is small.

What do you suggest then? Warn the user if the input/(output-change) ratio is too high (even with coin selection)?

If I understand this issue correct, it is about bitflips in outputs, so nValue or scriptPubKey.

The wallet, as well as the rpc should reject absurdly high fees, so at least a bit flip in a higher bit of nValue is checked by Bitcoin Core.

For the other cases I don't see how Bitcoin Core can prevent them from happening. The best solution would be to store the address/value pairs and verify them when the signed transaction comes back?

The GUI does this by showing each address/value pair. For the RPC, I think the end user has to implement this, so closing for now unless there are specific improvements to take.