Making insane fee non-standard

[Mitchell]

That guy used a brainwallet, didn't knew how it worked and shot himself in the foot. I don't feel sorry for him.

This is the type of attitude that holds back bitcoin adoption. Most people are not as technical as us, or interested in spending dozens of hours researching exactly how to move their bitcoins around safely.

If they did some research (or just looked at weusecoins.org) they would have seen recommended wallets and a brainwallet isn't listened. How much easier do we need to make it?

[grau]

An outright rejection to protect people here feels like dangers are not addressed to keep them from using alternate tools.

Can you please step back for a moment and consider how this response feels from my shoes. You're basically accusing me of being in a conspiracy to prevent people from using "alternative tools" simply because I think that degrading the functionality of the network with a bunch of hyper-specific mistake detectors to patch over _incompetently_ and _unsafely_ authored "alternative tools" is not a grand idea. I tend to think that making bitcoind subsume the functionality of other people's software would be the ultimate in keeping people from using alternative tools. But hey, if thats what you want you always have the option of just using bitcoind directly and gaining the mistake protection it presents towards the user.

But, moreover, don't you think you could have expressed an opinion on the ease of alternative implementations without the suggestion that anyone here had any ill motivations?

I apologize that what I said felt like accusing you with ill motivation.

Evaluating an issue only from the viewpoint, if it is an issue for a user using the reference implementation, does not feel right however. Bitcoin is also a protocol that should be welcoming and if it does not endanger higher goals, even forgiving.

Security of the Bitcoin system includes for the average user the security of his Bitcoins. The discussion if we have to protect him shooting into his feet reminds me to the arguments for and against priority of implementing encryption of the wallet.dat a year (or two) ago.

I think that it is a design error that the fee of a transaction can not be validated by consulting only the transaction. The SIGHASH_WITHINPUTVALUE (https://bitcointalk.org/index.php?topic=181734.0) is a sensible suggestion to remedy this worth of a soft fork IMHO.

I guess that the stance on this issue will change as soon as some spectacular losses through fees go through the media, similar to prominent thefts of wallet.dat before encryption.

edit: its is a hardfork suggestion

[StarfishPrime]

^^ Agree. It's not unthinkable that some kind of very basic enhanced tx validition be made part of the protocol either (i.e. fee > outputs = invalid). Something that wouldn't cause unnecessary, arbitrary limitations - but at the same time prevent obviously erroneous tx's from being confirmed.

Any commercial payment/transaction system has some type of validation to prevent common, obvious errors. Card processors will typically invalidate duplicate, identical credit card transactions from the same vendor within a few minutes of each other for example (and probably a $10000 visa purchase at Starbucks) since it's usually the result of some type of processing error.

[gmaxwell]

Software absolutely should have protection against stupidity. But the network is enormously hard to update, and as I pointed to there are real use cases that involve paying high fees (and, indeed, fees greater than outputs) so what you are suggesting does not avoid an unnecessary arbitrary limitation.

We are trying to remove the IsStandard restrictions over time, adding more of them— especially ones that assume a particular value for a particular amount of coin, is entirely the wrong direction.

There is basically no boundary to the kinds of mistake poorly written node software can make.  Perhaps they'll use a constant value as their DSA nonce— do you suggest we add code to screen for duplicate nonces on relay?  Perhaps they'll use a 32 bit LCG to generate their private keys. Perhaps they'll confuse their main output and change output?

Brainwallet prefills the destination in the transaction make with an address. If you're using a system that copies on highlight then hilighting to erase the address will wipe out the address in your copy buffer and then you may paste the default back in without noticing it— It's a mistake I've made several times while screwing with the site, but I'd never use it for an actual transaction— shall we blacklist that default output?

[StarfishPrime]

Software absolutely should have protection against stupidity. But the network is enormously hard to update, and as I pointed to there are real use cases that involve paying high fees (and, indeed, fees greater than outputs) so what you are suggesting does not avoid an unnecessary arbitrary limitation.

We are trying to remove the IsStandard restrictions over time, adding more of them— especially ones that assume a particular value for a particular amount of coin, is entirely the wrong direction.

There is basically no boundary to the kinds of mistake poorly written node software can make.  Perhaps they'll use a constant value as their DSA nonce— do you suggest we add code to screen for duplicate nonces on relay?  Perhaps they'll use a 32 bit LCG to generate their private keys. Perhaps they'll confuse their main output and change output?

Brainwallet prefills the destination in the transaction make with an address. If you're using a system that copies on highlight then hilighting to erase the address will wipe out the address in your copy buffer and then you may paste the default back in without noticing it— It's a mistake I've made several times while screwing with the site, but I'd never use it for an actual transaction— shall we blacklist that default output?

Yes, I'm with you that arbitrary, hard-coded limitations are a almost always a bad thing to be avoided at all costs. Definitely not suggesting that the credit card examples above be considered for bitcoin, but I still think something like a fee > outputs check or similar shouldn't be ruled out entirely for some future implementation (it would prevent virtually all of these obvious errors). I can't really see any use case argument disallowing it, even for sacrificial tx's, since they might also be able to include an iterative output (back to the tx input) if necessary?
-
edit: It could be argued that existing enforcement of minimum fees is more arbitrary and poorly implemented (hard-coded) than anything suggested here!