adv (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 02:54:18 PM |
|
$ 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$ 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
|
|
|
Gavin Andresen
Legendary
Offline
Activity: 1652
Merit: 2297
Chief Scientist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 03:55:46 PM |
|
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
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 72
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 03:58:01 PM |
|
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 11819716u5Tq1A5sQhGF3C1M9aMQvjXb25NyTsrZ: 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 04:01:39 PM |
|
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.
|
I do Bitcoin stuff.
|
|
|
adv (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 05:12:15 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 05:36:49 PM |
|
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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 05:47:49 PM |
|
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 bitcoind 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 07:11:38 PM |
|
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.
|
|
|
|
m0Ray
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 07:21:22 PM |
|
I think, there is a need for fee pre-calculation API call. Like that: $ bitcoin feecalc 100.41318448 { "txsize": 12.111, "fee": 0.13 }
|
|
|
|
kseistrup
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 07:27:11 PM |
|
I think, there is a need for fee pre-calculation API call.
+1
|
Klaus Alexander Seistrup
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 07:29:19 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 07:46:02 PM |
|
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.
|
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5292
Merit: 13207
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 07:47:35 PM |
|
I think, there is a need for fee pre-calculation API call. Like that: $ bitcoin feecalc 100.41318448 { "txsize": 12.111, "fee": 0.13 } Coins are randomized before selection, so that wouldn't be reliable.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
m0Ray
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 14, 2011, 07:57:51 PM Last edit: April 14, 2011, 08:58:42 PM by m0Ray |
|
Then $ 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: $ bitcoin prepare 15hZrw6V2HaWZShQsQASKYwhYjkCpT6Byd 100.41318448 { "txsize": 12.111, "fee": 0.13, "prepared_txid": "123467890qwertyvbhnjkl5bw4mtkwebgygusdc8blahblah" } And then $ bitcoin sendprepared 123467890qwertyvbhnjkl5bw4mtkwebgygusdc8blahblah 454825ecea7a89564b3751521e0d98215c76b4f83aa5284b62846621ecb7b587
|
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 15, 2011, 08:23:58 AM |
|
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.
|
|
|
|
epii
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 15, 2011, 09:00:59 AM |
|
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.
|
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 15, 2011, 09:23:25 AM |
|
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.
|
|
|
|
Pieter Wuille
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 15, 2011, 09:36:01 AM |
|
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.
|
I do Bitcoin stuff.
|
|
|
epii
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 15, 2011, 09:36:08 AM |
|
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.
|
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 15, 2011, 09:44:49 AM |
|
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.
|
|
|
|
|