Topic: A bug in the bitcoind who steals your money. (Read 4123 times)
Please implement a returning of fees amount upon completion of the transaction in CLI. Otherwise it becomes impossible to count the balance.
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.
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. 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.
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.
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.
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.
Then
and store the prepared transaction for specified address until daemon reload or next transaction? (quick'n'dirty)
Or more flexible:
And then
Code:
$ bitcoin feecalc 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100.41318448
{
"txsize": 12.111,
"fee": 0.13
}
Or more flexible:
Code:
$ bitcoin prepare 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100.41318448
{
"txsize": 12.111,
"fee": 0.13,
"prepared_txid": "123467890qwertyvbhnjkl5bw4mtkwebgygusdc8blahblah"
}
Code:
$ bitcoin sendprepared 123467890qwertyvbhnjkl5bw4mtkwebgygusdc8blahblah
454825ecea7a89564b3751521e0d98215c76b4f83aa5284b62846621ecb7b587
I think, there is a need for fee pre-calculation API call.
Like that:
Like that:
Code:
$ bitcoin feecalc 100.41318448
{
"txsize": 12.111,
"fee": 0.13
}
Coins are randomized before selection, so that wouldn't be reliable.
The Wallet protocol
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. 
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).
I think, there is a need for fee pre-calculation API call.
+1
I think, there is a need for fee pre-calculation API call.
Like that:
Like that:
Code:
$ bitcoin feecalc 100.41318448
{
"txsize": 12.111,
"fee": 0.13
}
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.
The downside is that more transactions are broadcast to the network.
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.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.
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 bitcoind really dangerous for those who send large amounts from CLI.
Sorry for my bad english, i use google translate...
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.
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.
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.
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:
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
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
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.
Jump to: