Making insane fee non-standard

[jl2012]

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.

[empoweoqwj]

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.

[gmaxwell]

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

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

[empoweoqwj]

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

"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?

[wumpus]

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)

[jl2012]

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

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

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.

[justusranvier]

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

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

[jl2012]

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

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.

[gmaxwell]

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.

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

[killerstorm]

I think this is a bad idea

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!

[empoweoqwj]

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.

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

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

[wumpus]

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

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'?

[spin]

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.

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.

[jl2012]

I think this is a bad idea

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!

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

[grau]

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.

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

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.

[CIYAM]

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

[gmaxwell]

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

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.

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?

[CIYAM]

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.

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

[TheButterZone]

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?

[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. Electrum did add a confirmation dialog to prevent high fee's in their latest version.

- Shows a confirmation dialog if the transaction fee is higher than 1mBTC.

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

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