Bitcoin Forum
June 18, 2024, 10:33:55 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Making insane fee non-standard  (Read 1927 times)
jl2012 (OP)
Legendary
*
Offline Offline

Activity: 1792
Merit: 1097


View Profile
December 16, 2013, 04:42:57 AM
 #1

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.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
empoweoqwj
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
December 16, 2013, 04:47:33 AM
 #2

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
Moderator
Legendary
*
expert
Offline Offline

Activity: 4200
Merit: 8441



View Profile WWW
December 16, 2013, 05:48:04 AM
 #3

"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
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
December 16, 2013, 06:02:33 AM
 #4

"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? Smiley
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
December 16, 2013, 07:27:34 AM
 #5

Nothing we can do. we can warn people against using it? Smiley
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)

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
jl2012 (OP)
Legendary
*
Offline Offline

Activity: 1792
Merit: 1097


View Profile
December 16, 2013, 08:28:47 AM
 #6

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

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1009



View Profile
December 16, 2013, 08:40:07 AM
 #7

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 (OP)
Legendary
*
Offline Offline

Activity: 1792
Merit: 1097


View Profile
December 16, 2013, 08:51:49 AM
 #8

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.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4200
Merit: 8441



View Profile WWW
December 16, 2013, 04:40:20 PM
 #9

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
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
December 16, 2013, 08:23:35 PM
 #10

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!

Chromia: a better dapp platform
empoweoqwj
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
December 17, 2013, 07:33:58 AM
 #11

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
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
December 17, 2013, 07:54:14 AM
 #12

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

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
spin
Sr. Member
****
Offline Offline

Activity: 362
Merit: 261


View Profile
December 17, 2013, 08:16:09 AM
 #13


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.


If you liked this post buy me a beer.  Beers are quite cheap where I live!
bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
jl2012 (OP)
Legendary
*
Offline Offline

Activity: 1792
Merit: 1097


View Profile
December 17, 2013, 08:32:35 AM
 #14

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

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1021


bits of proof


View Profile WWW
December 17, 2013, 08:37:42 AM
 #15

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
December 17, 2013, 08:41:22 AM
 #16

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4200
Merit: 8441



View Profile WWW
December 17, 2013, 09:04:37 AM
 #17

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
December 17, 2013, 09:28:36 AM
 #18

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
TheButterZone
Legendary
*
Offline Offline

Activity: 3010
Merit: 1031


RIP Mommy


View Profile WWW
December 17, 2013, 09:37:53 AM
 #19

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?

Saying that you don't trust someone because of their behavior is completely valid.
Mitchell
Copper Member
Legendary
*
Offline Offline

Activity: 3962
Merit: 2204


Verified awesomeness ✔


View Profile WWW
December 17, 2013, 09:45:44 AM
 #20

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

.
Duelbits
            ▄████▄▄
          ▄█████████▄
        ▄█████████████▄
     ▄██████████████████▄
   ▄████▄▄▄█████████▄▄▄███▄
 ▄████▐▀▄▄▀▌████▐▀▄▄▀▌██

 ██████▀▀▀▀███████▀▀▀▀█████

▐████████████■▄▄▄■██████████▀
▐██████████████████████████▀
██████████████████████████▀
▀███████████████████████▀
  ▀███████████████████▀
    ▀███████████████▀
.
         ▄ ▄▄▀▀▀▀▄▄
         ▄▀▀▄      █
         █   ▀▄     █
       ▄█▄     ▀▄   █
      ▄▀ ▀▄      ▀█▀
    ▄▀     ▀█▄▄▄▀▀ ▀
  ▄▀  ▄▀  ▄▀

Live Games

   ▄▄▀▀▀▀▀▀▀▄▄
 ▄▀ ▄▄▀▀▀▀▀▄▄ ▀▄
▄▀ █ ▄  █  ▄ █ ▀▄
█ █   ▀   ▀   █ █  ▄▄▄
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀ █ █   █
█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█  █▄█
█ ▀▀█  ▀▀█  ▀▀█ █  █▄█

Slots
.
        ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄
        █         ▄▄  █
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄       █
█  ▄▄         █       █
█             █       █
█   ▄▀▀▄▀▀▄   █       █
█   ▀▄   ▄▀   █       █

Blackjack
|█▀▀▀▀▀█▄▄▄
       ▀████▄▄
         ██████▄
▄▄▄▄▄▄▄▄█▀    ▀▀█
████████▄        █
█████████▄        █
██████████▄     ▄██
█████████▀▀▀█▄▄████
▀▀███▀▀       ████
   █          ███
   █          █▀
▄█████▄▄▄ ▄▄▀▀
███████▀▀▀
.
                 NEW!                  
SPORTS BETTING 
|||
[ Đ ][ Ł ]
AVAILABLE NOW

Advertisements are not endorsed by me.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!