Bitcoin Forum
December 05, 2016, 02:37:58 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: A bug in the bitсoind who steals your money.  (Read 3614 times)
adv
Full Member
***
Offline Offline

Activity: 169


View Profile
April 14, 2011, 02:54:18 PM
 #1

Code:
$ bitcoind getinfo
{
    "version" : 31900,
    "balance" : 100.41318448,
    "blocks" : 118195,
    "connections" : 25,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 82347.22294654,
    "hashespersec" : 0,
    "testnet" : false,
    "keypoololdest" : 1291293105,
    "paytxfee" : 0.00000000,
    "errors" : ""
}
$ bitcoind sendtoaddress 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100.41318448
error: {"code":-4,"message":"Error: This is an oversized transaction that requires a transaction fee of 0.14  "}
$ bitcoind sendtoaddress 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100.41
error: {"code":-4,"message":"Error: This is an oversized transaction that requires a transaction fee of 0.14  "}
$ bitcoind sendtoaddress 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100.4
error: {"code":-4,"message":"Error: This is an oversized transaction that requires a transaction fee of 0.13  "}
$ bitcoind sendtoaddress 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100
454825ecea7a89564b3751521e0d98215c76b4f83aa5284b62846621ecb7b587
$ bitcoind getinfo
{
    "version" : 31900,
    "balance" : 0.28318448,
    "blocks" : 118195,
    "connections" : 25,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 82347.22294654,
    "hashespersec" : 0,
    "testnet" : false,
    "keypoololdest" : 1291293105,
    "paytxfee" : 0.00000000,
    "errors" : ""
}

And the fee for the transaction still acted without question or confirmation! http://blockexplorer.com/t/3dH5rnVCPr
Code:
$ bitcoind gettransaction 454825ecea7a89564b3751521e0d98215c76b4f83aa5284b62846621ecb7b587
{
    "amount" : -100.00000000,
    "fee" : -0.13000000,
    "confirmations" : 10,
    "txid" : "454825ecea7a89564b3751521e0d98215c76b4f83aa5284b62846621ecb7b587",
    "time" : 1302709644,
    "details" : [
        {
            "account" : "",
            "address" : "15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd",
            "category" : "send",
            "amount" : -100.00000000,
            "fee" : -0.13000000
        }
    ]
}

In fact, the console client stole my money and gave them to miner.
GUI client is asked to pay for a large transaction.
Looks like ugly coders for some reason decided to always answer yes to this question from the console. :^/

Discussion in Russian: http://bitcointalk.org/index.php?topic=5796.0

U may thank me here: 14Js1ng1SvYBPgUJnjNAEPYH4d6SHF79UF
1480905478
Hero Member
*
Offline Offline

Posts: 1480905478

View Profile Personal Message (Offline)

Ignore
1480905478
Reply with quote  #2

1480905478
Report to moderator
1480905478
Hero Member
*
Offline Offline

Posts: 1480905478

View Profile Personal Message (Offline)

Ignore
1480905478
Reply with quote  #2

1480905478
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480905478
Hero Member
*
Offline Offline

Posts: 1480905478

View Profile Personal Message (Offline)

Ignore
1480905478
Reply with quote  #2

1480905478
Report to moderator
1480905478
Hero Member
*
Offline Offline

Posts: 1480905478

View Profile Personal Message (Offline)

Ignore
1480905478
Reply with quote  #2

1480905478
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
April 14, 2011, 03:55:46 PM
 #2

Looks like ugly coders for some reason decided to always answer yes to this question from the console. :^/

I'm not really ugly, am I?  You should have seen me in college when I was too cheap to get a haircut...

So:  bitcoind doesn't ask for confirmation before sending fees with a transaction because it is was much easier to implement that way, and for most uses of bitcoind paying an occasional transaction fee isn't a problem.

If you'd like to help fix it, patches are welcome.  I think a new setting that says "don't pay more than N bitcoins for any transaction without asking me" and a new argument to the send routines to say either "I'm willing to pay up to X bitcoins for this transaction" or "I want to pay X bitcoins in transaction fees with this transaction" is a good idea.

How often do you get the chance to work on a potentially world-changing project?
AbeSkray
Member
**
Offline Offline

Activity: 72



View Profile
April 14, 2011, 03:58:01 PM
 #3

According to block explorer, your transaction was 12.111 kB (13 kB rounded up). According to the wiki, the standard Bitcoin client (0.3.20) will include 0.01 BTC per kB as automatic transaction fee. If you're code savvy, you can modify your client's default rules so that it doesn't apply the transaction fee, but your transaction may not go through until a block is created by a miner who is also not following the default rules.

What I don't understand is why your transaction was so big. At cursory glance, it looks like your transaction was aggregated from 90 addresses that each sent about 1 BTC. However, there are only 4 unique sending addresses involved:
  • 1. 16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ
  • 2. 1BY19SCbjrbi8wtFnbMvC81R7cw5hnRQvv
  • 3. 1BvzaqfYgTE1fkG5F6Nspw4wtnERGMwjAJ
  • 4. 1KcfkMACYPCNxhFtAtEEZSH6JGqDoZtcq1

The majority of the transaction (71.14 BTC) came from the first address. Can anyone explain why that address was recorded seventy times in one transaction, instead of just once with the lump sum of 71.14 BTC?

Block 118197

Code:
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.17
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.1
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.1
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.05
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.52
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.13
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.09
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.14
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.13
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.22
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.52
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.08
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.18
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.08
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.15
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.22
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.1
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.13
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.02
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.03
1BY19SCbjrbi8wtFnbMvC81R7cw5hnRQvv: 20
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.06
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.06
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.07
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.45
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.39
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.08
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.15
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.09
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.07
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.14
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.09
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.07
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.05
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.03
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.05
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.18
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.1
1KcfkMACYPCNxhFtAtEEZSH6JGqDoZtcq1: 1.06
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 0.03
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.11
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.09
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.08
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.02
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.28
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.06
1BY19SCbjrbi8wtFnbMvC81R7cw5hnRQvv: 9.95
1BvzaqfYgTE1fkG5F6Nspw4wtnERGMwjAJ: 1
1KcfkMACYPCNxhFtAtEEZSH6JGqDoZtcq1: 1
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.15
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.11
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 0.02
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.04
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.01
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.02
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.23
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.07
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.05
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.12
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.01
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.02
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.2
16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 1.11
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
April 14, 2011, 04:01:39 PM
 #4

The majority of the transaction (71.14 BTC) came from the first address. Can anyone explain why that address was recorded seventy times in one transaction, instead of just once with the lump sum of 71.14 BTC?

Transactions always consume the output of a specific previous transaction. If all funds available to that first address arrived there through many small transactions, you would need a lot of inputs to consume it as well. Bitcoin only conceptually deals with "money coming from an address", in reality it always comes from a previous transaction.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
adv
Full Member
***
Offline Offline

Activity: 169


View Profile
April 14, 2011, 05:12:15 PM
 #5

The majority of the transaction (71.14 BTC) came from the first address. Can anyone explain why that address was recorded seventy times in one transaction, instead of just once with the lump sum of 71.14 BTC?

Transactions always consume the output of a specific previous transaction. If all funds available to that first address arrived there through many small transactions, you would need a lot of inputs to consume it as well. Bitcoin only conceptually deals with "money coming from an address", in reality it always comes from a previous transaction.
Yes, and 16u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ was my input for Slush's pool.

U may thank me here: 14Js1ng1SvYBPgUJnjNAEPYH4d6SHF79UF
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
April 14, 2011, 05:36:49 PM
 #6

I think this is the biggest fee I've seen in a transaction. Even then, 0.13 BTC on a transfer of 100 BTC, that's only 0.13%. Not too shabby anyway.
adv
Full Member
***
Offline Offline

Activity: 169


View Profile
April 14, 2011, 05:47:49 PM
 #7

So:  bitcoind doesn't ask for confirmation before sending fees with a transaction because it is was much easier to implement that way, and for most uses of bitcoind paying an occasional transaction fee isn't a problem.

If you'd like to help fix it, patches are welcome.  I think a new setting that says "don't pay more than N bitcoins for any transaction without asking me" and a new argument to the send routines to say either "I'm willing to pay up to X bitcoins for this transaction" or "I want to pay X bitcoins in transaction fees with this transaction" is a good idea.
I think there are more simple and correct solution: block with giving error message transactions, which required more fee than paytxfee option. And setting individual fee for each transaction leave for the future.
Or in other words, just say "No" by default on the issue of additional pay for the size.
I think a new setting that says "don't pay more than N bitcoins for any transaction without asking me" - not really needed option in this case.

About the patch: I know C, not C++ and not so well know bitcoin code. So I can make mistake due to which someone will lose a significant amount of money. After all, I was just lucky that I had lost 0.13, but not 13 ​​or 130 BTC...

Not that I really offended you, but the existing behavior bitсoind really dangerous for those who send large amounts from CLI.

Sorry for my bad english, i use google translate...

U may thank me here: 14Js1ng1SvYBPgUJnjNAEPYH4d6SHF79UF
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
April 14, 2011, 07:11:38 PM
 #8

Could we add a way to tell the client to consolidate inputs by transferring inputs to an address owned by the client. I was planning to do so for the android client to save stored data (blocks to remember and time to aggregate enough inputs). Please don't shoot me :-)
The downside is that more transactions are broadcast to the network.

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
m0Ray
Sr. Member
****
Offline Offline

Activity: 364



View Profile
April 14, 2011, 07:21:22 PM
 #9

I think, there is a need for fee pre-calculation API call.
Like that:
Code:
$ bitcoin feecalc 100.41318448
{
 "txsize": 12.111,
 "fee": 0.13
}

IT-услуги широкого профиля за биткойн.
V for Vendetta, not for «vvhite ribbon»
kseistrup
Hero Member
*****
Offline Offline

Activity: 565


Unselfish actions pay back better


View Profile WWW
April 14, 2011, 07:27:11 PM
 #10

I think, there is a need for fee pre-calculation API call.

+1


Klaus Alexander Seistrup
http://about.me/kseistrup
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
April 14, 2011, 07:29:19 PM
 #11

The Wallet protocol should take care of this by allowing creating transactions without submitting them to the network. So you would do it in three steps: first, ask it to create the transaction; then, check the transaction it returns; finally, give it the okay to sign and transmit it (possibly providing a higher-authority password).

m0Ray
Sr. Member
****
Offline Offline

Activity: 364



View Profile
April 14, 2011, 07:46:02 PM
 #12

Looks sane, but when it will be available? For now, almost everyone uses classic JSON-RPC API. The proposed quick fix will be a good help for client application developers.

IT-услуги широкого профиля за биткойн.
V for Vendetta, not for «vvhite ribbon»
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 14, 2011, 07:47:35 PM
 #13

I think, there is a need for fee pre-calculation API call.
Like that:
Code:
$ bitcoin feecalc 100.41318448
{
 "txsize": 12.111,
 "fee": 0.13
}

Coins are randomized before selection, so that wouldn't be reliable.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
m0Ray
Sr. Member
****
Offline Offline

Activity: 364



View Profile
April 14, 2011, 07:57:51 PM
 #14

Then
Code:
$ bitcoin feecalc 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100.41318448
{
 "txsize": 12.111,
 "fee": 0.13
}
and store the prepared transaction for specified address until daemon reload or next transaction? (quick'n'dirty)

Or more flexible:
Code:
$ bitcoin prepare 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100.41318448
{
 "txsize": 12.111,
 "fee": 0.13,
 "prepared_txid": "123467890qwertyvbhnjkl5bw4mtkwebgygusdc8blahblah"
}
And then
Code:
$ bitcoin sendprepared 123467890qwertyvbhnjkl5bw4mtkwebgygusdc8blahblah
454825ecea7a89564b3751521e0d98215c76b4f83aa5284b62846621ecb7b587

IT-услуги широкого профиля за биткойн.
V for Vendetta, not for «vvhite ribbon»
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
April 15, 2011, 08:23:58 AM
 #15

I think, there is a need for fee pre-calculation API call.

I disagree. There's no way to "pre-calculate" fees as miners are free to set the fee policy they want. This standard policy that's being followed by most miners is a set of arbitrary rules that were coded into the standard client, but these are not carved on stone or anything. Miners are free to come up with their own policies.

Actually, I don't even think the standard client should have this fee policy or even a miner. It should limit itself in defining what is a valid block and what is not.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
epii
Full Member
***
Offline Offline

Activity: 196



View Profile
April 15, 2011, 09:00:59 AM
 #16

I think, there is a need for fee pre-calculation API call.

I disagree. There's no way to "pre-calculate" fees as miners are free to set the fee policy they want. This standard policy that's being followed by most miners is a set of arbitrary rules that were coded into the standard client, but these are not carved on stone or anything. Miners are free to come up with their own policies.

Actually, I don't even think the standard client should have this fee policy or even a miner. It should limit itself in defining what is a valid block and what is not.
But presumably the client will have some fee policy, unless the user is expected to manually guess at a good fee for every transaction they make.  Thus, it ought to be possible to calculate in advance what the fee would be, in accordance with whatever policy the client uses.

Vires In Numeris.
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
April 15, 2011, 09:23:25 AM
 #17

But presumably the client will have some fee policy, unless the user is expected to manually guess at a good fee for every transaction they make. 

Exactly, the user should guess the good fee for every transaction.
And it's miners who have fee policies, not "clients", as in general purpose clients.

Thus, it ought to be possible to calculate in advance what the fee would be, in accordance with whatever policy the client uses.

The only way I can think of doing a "fee prediction" is by looking at the block chain and seeing the cheapest fees that managed to get included within the delay you accept to wait for. For example, if you accept to wait up to 100 blocks before your first confirmation, check which were the cheapest fee per kb transaction that managed to get included in the last 100 blocks. There could be an automation of such process, but I don't think it's up to the reference implementation to provide such service.
And still, this is a prediction, there's no guarantee that it'll work.

The thing that the reference implementation should have, IMHO, is the ability to resend a transaction with higher fees.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
April 15, 2011, 09:36:01 AM
 #18

The thing that the reference implementation should have, IMHO, is the ability to resend a transaction with higher fees.

There is a currently unimplemented feature of the protocol, where transactions can be given a version number, and a new version of a given transaction can be created, overriding the previous one as long as it is not accepted into the block chain. I assume that is meant to be used to update transactions with a higher fee when the original one wasn't enough.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
epii
Full Member
***
Offline Offline

Activity: 196



View Profile
April 15, 2011, 09:36:08 AM
 #19

And it's miners who have fee policies, not "clients", as in general purpose clients.
Policy, scheme, convention, whatever you want to call it - I mean clients should have (as they already do) some built-in fee-determining algorithm.  I don't think it needs to be any more complicated than a preference for fee/kb in a GUI client (and in a CLI client this could be passed as an argument).  However you do it, this makes it possible to do a "fee pre-calculation" as described above.  All this really is is a pre-calculation of the size of the outgoing transaction.

Vires In Numeris.
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
April 15, 2011, 09:44:49 AM
 #20

Ah ok, but then it's how you say, you're just pre-calculating the transaction size and multiplying by a user preference. It has nothing to do with how miners will treat your transaction.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!