Bitcoin Forum

https://bitcointalk.org/index.php?topic=372725.0

Someone just accidentally paid 20BTC as fee. I think we should make any transaction with >0.1 XBT fee as non-standard. (0.0001 XBT/kB * 1000kB = 0.1 XBT).

OT: This could be avoided if the blockchain.info API blocked the transaction.

Certainly any client should produce warnings galore before someone is allowed to do this. Blocking the transaction is also a good idea, presuming there are "no good uses" for sending huge transaction fees.

"Just" as in >1500 blocks ago (IOW over a week ago)?   Current Bitcoin-qt codebase will not aid someone in footgunning like this, but there isn't anything we can do about irresponsible services like brainwallet (which create extreme risk of loss in several ways, not just this one).

Please don't start another thread about this.

Nothing we can do. we can warn people against using it? :)

Pull requests welcome.
(but in master the confirmation dialog always shows the fee, and shows the total in BTC, mBTC and uBTC no matter what unit configured, so it's much more difficult make mistakes already)

I think bitcoind will still relay transactions with insane fee? If most nodes do not relay such transactions they are less likely to reach a miner. (On miners' standpoint I think they will still mine it if they see one)

We could never stop people from creating/using irresponsible/buggy services. However, the bitcoind, as the backbone of the network, should filter such insane behavior. After all, it is about the reputation of the whole bitcoin network.

Do you mean a limit in absolute terms, or in per-kB terms?

I think an absolute limit is enough. 0.1XBT is about 80USD right now. It's not small but even bitcoin users in developing countries should earn this amount in less than a month so it doesn't do real harm.

I think this is a bad idea, and I pointed out that I thought it was a bad idea the last time it was proposed (https://bitcointalk.org/index.php?topic=332403.0).

There is absolutely no way to prevent people using brainwallet from shooting themselves in the foot. What the reference software does is probably not even relevant in this case since it submits directly to bc.i and bc.i is directly connected to many miners (who, if they're not asleep at the switch will just remove the limit).  There are real applications (https://en.bitcoin.it/wiki/Identity_protocol_v1) for paying large fees, and any fee you select is at risk of becoming not-large or too-large at unknown times in the future.

Insane fees might actually create a problem for consensus: when fee exceeds X/p where X is an average block payoff and p is a probability that a miner will mine the next block (aka the percentage of hash rate), it makes sense to mine a block which includes a transaction with this obscene fee instead of mining a block on top of the longest chain.

Hypothetically, a software bug which sends a huge sum to a fee could destabilize the whole network if miners were game-theoretically rational.

For example, suppose somebody who has has 100,000 BTC in one wallet uses custom software to make a transaction (he absolutely needs to do it on a highly secure, air-gapped system; standard software doesn't cut), and fucks up signing a transaction with a 100,000 BTC fee. This kills the Bitcoin. Why?

I don't know about you, but if I was a mining pool operator, I'd rush to keyboard and try to patch bitcoind to make it mine that transaction no matter what. Perhaps the opportunity cost is on scale of 50 BTC, but it doesn't matter when 100,000 BTC is on table (and sometimes pools have bad luck/orphans/outages, it isn't unheard of).

Now suppose there is an IsStandard rules against insane fees, it will prevent propagation, and perhaps a rich guy who has 100,000 BTC would double-check it. Catastrophe averted.

Good idea, jl2012!

The mining pool could just give the fee back. ASICMINER did in the same circumstance.

Indeed. GUIs need to prevent this from happening, not the protocol.

It's impossible to prevent foot-shooting at that level anyway. What's next, 'make coins sent to addresses without known private keys non-standard'?

Good luck with that assumption. 
Check this out: www.bit.ly/11UKOqB (I'm using 2005 figures below)
This measures % of the population of each country earning under USD2 per day (or 60 per month).
Nigeria sits at over 80% of the population under USD2 .  Many African countries are sitting between 70% and 90% of the population earning less than USD2 per day.  South Africa is at 38%.
China (35%) and India(74%) pretty high too, as is some other Asian countries like Indonesia (63%)

However I imagine bitcoin is not going to be high on the agenda for these people.

This could be fixed but need a hardfork. Miner should be able to send part of its earning to the next miner by making an anyone-can-redeem output. This is not possible now because of the 100-block requirement

There could be ways to prevent people shooting their feet, such us introducing SIGHASH_WITHINPUTVALUE as discussed in https://bitcointalk.org/index.php?topic=181734.0 a proposal that has further positive effects on offline txs and hardware implementations.

The idea of making excessive fees non-standard is also worth exploring.

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

Personally I think a much better solution would be to have the fee *explicitly specifiable* in the script (a new op such as OP_CHECKFEE).

The idea being that if this check is present then the amount specified must match the actual fee.

The benefit of this is that it also allows for safe offline signing without needing the blockchain (currently such signing could be dangerous as the offline device without a blockchain doesn't have the information to be able to calculate the fee).

Shoving in a _fee_ operator is a really kludgy way to handle it as if it worked it would break the sighash independence and the ability to do ANYONE CAN PAY to add fees to unstick a transaction which had fees which were too low. But since the ScriptSig is not under the signature hash if a fee amount on the signature stack was the only thing preventing incorrect fees a signature could be trivially rebound from a transaction with sane fees to one with insane fees by a hostile host/relayer.

The only non-hardforking way I know to address that is to introduce a new checksig operator, which is not a small step at all. ... moreover, I don't think it would have helped here: Brainwallet looks up the input values (using blockchain.info), it knew what they were.

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?

Well admittedly I am coming at this from another angle as I would really love to have the fee included in the script for 100% safe air-grapped QR code tx signing from a device that doesn't need any blockchain info.

Am not sure but perhaps it could be made to work by having more than one OP_CHECKFEE included (so the original could still be present) but am guessing you'd consider that a "kludge on top of a kludge". ;)

In all the time I used brainwallet.org's source, it always set the change to be sent back to my sending address, not to fee. What implementations are people using that they are fucking up their TXes so badly? It seems like I'd have to go light years out of my way to find and use them. Or are people trying to construct raw TXes without knowing WTF they're doing?

That guy used a brainwallet, didn't knew how it worked and shot himself in the foot. I don't feel sorry for him. Electrum did add a confirmation dialog to prevent high fee's in their latest version.

It's a P2P pool and the fee has been send to over 300 people. Kinda hard to do.

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?

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

^^ 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.

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!