Is this bounty still available? It wouldn't be hard to implement if there's still interest in it.
I did it a long time ago. It's pretty much obsolete now, though. 
Topic: [BOUNTY] A patch for bitcoind to modify tx list in "getmemorypool" (Read 5470 times)
August 20, 2012, 06:01:17 PM
Is this bounty still available? It wouldn't be hard to implement if there's still interest in it.
August 19, 2012, 11:55:29 PM
What's the benefit of "coin melting"?
If you just want to merge multiple "junk" inputs to one output, why do you add any tx fee at all?
I imagine you only use 'coin melting' if the accepted method of calculating which coins are 'tainted' only looks at inputs and outputs, and ignores transaction fees.If you just want to merge multiple "junk" inputs to one output, why do you add any tx fee at all?
If coin melting ever becomes popular then it will stop being effective, as the taint calculations start taking it into account.
Losses from orphaned blocks might just be part of the cost of business for this type of transaction. I could also see it as an incentive to melt slowly as well.
April 29, 2012, 09:02:15 PM
What's the benefit of "coin melting"?
If you just want to merge multiple "junk" inputs to one output, why do you add any tx fee at all?
If you just want to merge multiple "junk" inputs to one output, why do you add any tx fee at all?
I imagine you only use 'coin melting' if the accepted method of calculating which coins are 'tainted' only looks at inputs and outputs, and ignores transaction fees.
If coin melting ever becomes popular then it will stop being effective, as the taint calculations start taking it into account.
Unlikely unless you want to bankrupt miners by considering their block rewards tainted.
April 29, 2012, 08:34:50 PM
What's the benefit of "coin melting"?
If you just want to merge multiple "junk" inputs to one output, why do you add any tx fee at all?
If you just want to merge multiple "junk" inputs to one output, why do you add any tx fee at all?
I imagine you only use 'coin melting' if the accepted method of calculating which coins are 'tainted' only looks at inputs and outputs, and ignores transaction fees.
If coin melting ever becomes popular then it will stop being effective, as the taint calculations start taking it into account.
April 29, 2012, 07:36:48 PM
What's the benefit of "coin melting"?
If you just want to merge multiple "junk" inputs to one output, why do you add any tx fee at all?
If you just want to merge multiple "junk" inputs to one output, why do you add any tx fee at all?
March 30, 2012, 05:10:20 AM
Yes, it's possible, but not secure enough.
1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
And what's the difference between this big miners cooperation an the cooperation needed for a 51 % attack?1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
March 30, 2012, 04:36:08 AM
But if I'm not wrong the % of orphan blocks is very low
March 30, 2012, 04:13:15 AM
Yes, it's possible, but not secure enough.
1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
And what's the difference between this big miners cooperation an the cooperation needed for a 51 % attack?
None. But point 1 doesn't need cooperation at all.
March 30, 2012, 04:12:03 AM
Yes, it's possible, but not secure enough.
1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
And what's the difference between this big miners cooperation an the cooperation needed for a 51 % attack?
March 29, 2012, 07:44:01 PM
Yes, it's possible, but not secure enough.
1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
Good points. Guess there's no point implementing it then...
March 29, 2012, 07:07:17 PM
One related question. Is it possible to have bitcoind create a tx but not broadcast it? If so is it then part of the memorypool? If not could bitcoind be modified to make it part of the memorypool? Essentially I want the ability to include a tx in a block that hasn't been broadcasted (coin melting).
Yes, it's possible, but not secure enough.1. If your block becomes orphaned, someone will pick this TX and take fees.
2. Big miners can cooperate and intentionally invalidate blocks with unusually high fees to pick them up and split profits.
Otherwise the idea is good.
March 29, 2012, 03:16:35 AM
One related question. Is it possible to have bitcoind create a tx but not broadcast it? If so is it then part of the memorypool? If not could bitcoind be modified to make it part of the memorypool? Essentially I want the ability to include a tx in a block that hasn't been broadcasted (coin melting).
A problem with this would be what to do if you create one of these 'melt' transactions, but don't manage to mine a block before shutting down bitcoind. The transaction is stored in the wallet along with any other pending transactions. The wallet format doesn't currently store whether a transaction is "secret" or not. It could do, but that would make the wallet format incompatible with standard client wallet files.
A simple solution would be for the client never to broadcast any transactions that you create on the client while in the new mode. The wallet already has a field for each transaction which says whether you created it or not. Another would be to have a threshold, and never broadcast any of your transactions which have a fee over a certain amount.
Given this, do you have any further thoughts on how you want this feature to work?
March 28, 2012, 08:38:26 AM
Examples usage of setminfee
Setting minfee of 0.005 BTC per KB
Checking minfee using getmininginfo
Checking the memorypool returned by bitcoind (used by p2pool or solominer to generate work)
Note tx section is empty. At the time of execution the node has not received any unconfirmed tx with a fee of >= 0.0005 BTC
Setting the minfee to 1 satoshi (1E-8 BTC, the smallest unit in Bitcoin) and checking mempool
Essentially this includes all paying txs and excludes all non-paying txs.
Roughly 10% of tx volume includes a fee of some token amount.
p2pool works fine with modified bitcoind. I have noticed no errors, changes in payout, increase in stales, or reduction reported hashpower.
Setting minfee of 0.005 BTC per KB
Code:
E:\bitcoin\bitcoin-0.6.0rc5+customfee-win32>bitcoind setminfee 0.0005
true
true
Checking minfee using getmininginfo
Code:
E:\bitcoin\bitcoin-0.6.0rc5+customfee-win32>bitcoind getmininginfo
{
"blocks" : 173278,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 1498294.36281651,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"pooledtx" : 37,
"minfee" : 0.00050000,
"minfeeper" : 1000,
"testnet" : false
}
{
"blocks" : 173278,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 1498294.36281651,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"pooledtx" : 37,
"minfee" : 0.00050000,
"minfeeper" : 1000,
"testnet" : false
}
Checking the memorypool returned by bitcoind (used by p2pool or solominer to generate work)
Code:
E:\bitcoin\bitcoin-0.6.0rc5+customfee-win32>bitcoind getmemorypool
{
"version" : 1,
"previousblockhash" : "0000000000000223a54ba1689d09a07aac9c172002fee5866b18c
2e52ecf5569",
"transactions" : [
],
"coinbasevalue" : 5000000000,
"coinbaseflags" : "062f503253482f",
"time" : 1332941298,
"mintime" : 1332936934,
"curtime" : 1332941298,
"bits" : "1a0b3287"
}
{
"version" : 1,
"previousblockhash" : "0000000000000223a54ba1689d09a07aac9c172002fee5866b18c
2e52ecf5569",
"transactions" : [
],
"coinbasevalue" : 5000000000,
"coinbaseflags" : "062f503253482f",
"time" : 1332941298,
"mintime" : 1332936934,
"curtime" : 1332941298,
"bits" : "1a0b3287"
}
Note tx section is empty. At the time of execution the node has not received any unconfirmed tx with a fee of >= 0.0005 BTC
Setting the minfee to 1 satoshi (1E-8 BTC, the smallest unit in Bitcoin) and checking mempool
Essentially this includes all paying txs and excludes all non-paying txs.
Code:
E:\bitcoin\bitcoin-0.6.0rc5+customfee-win32>bitcoind setminfee 0.00000001
true
E:\bitcoin\bitcoin-0.6.0rc5+customfee-win32>bitcoind getmemorypool
{
"version" : 1,
"previousblockhash" : "000000000000087818d53138fbd4256625e37c98a38b6fe8569e56852c92ab70",
"transactions" : [
"0100000004820c6bd1fa106889710348767abb456e5f38b82c3acf570a3c2635480bab6761010000008c493046022100f3cd34b9f81b525
45b31fc3b25c2042db02d2924bf7e69a22adbbfd4ad080a17022100dd0683a739959d8d1a98d94ffd7ed06ad4d2da3b81ab3e2327d6b74746cfd51b0
14104854590bebc0e4b6daccf49084bb9df726c34bc1038f41cfdfc6e1738d84768ee682492c7f05c726dd1e5539bf5ee41233189e5b82295faad798
7f31012aac52affffffff73a1e10e24c7aee9e4d868692cc4249dfb7189dddbeecf3943d24c0badf10757010000008c493046022100e6a8db0114607
be4cb186154a1c7822712d5659d8121f08e19acfe7d67ad3441022100cd2370ffeebce357aad64ce7d731b2be881e047aa2c3bcc6767c114ad4fc785
f0141041a0067d8576419beee8815c37393f617e9f673e6465962f83c6b6274b5e173eae2bb30ffd78e7571e5ce5db5fe4f2b1b641d6ceb51aad3435
fa4566cf0828a1effffffffbd4e061d000de7688e4de4d7111ddb804de9d2cbd1217748038e296b0c03cc02010000008b483045022100e54f20c2758
17ab65cff34ab1c3591dbf9ab25f1c1996d806404f746b935534202207f5bda330867c1d214bfdacf0a2a18bce38f0ddea35fba8b9ae65d2d62d962c
1014104854590bebc0e4b6daccf49084bb9df726c34bc1038f41cfdfc6e1738d84768ee682492c7f05c726dd1e5539bf5ee41233189e5b82295faad7
987f31012aac52afffffffff4a1d363c469b1ff2df888f82a02402accafb01cddc3b00f22299afd5487721b010000008a47304402203ace625c70475
cf2de8f41e3e492c13c4cf459cae42b1c37ba5ae1ad1f18c57f02200c57f4f0fc49be27f3933decb8e22ba89337f1e57a7e38e33642e142515501fa0
14104854590bebc0e4b6daccf49084bb9df726c34bc1038f41cfdfc6e1738d84768ee682492c7f05c726dd1e5539bf5ee41233189e5b82295faad798
7f31012aac52affffffff0249a5a700000000001976a914b31e6898ceb2fe42ab62ee03400ac24cab90be0f88ac00ca9a3b000000001976a914abe03
f415de01d078829249d0abdec8c61466aab88ac00000000",
"0100000001595e7ee07f3d6036f2e28c290e4e5cab0689fc5153217fff0e43e95118862c61000000008b483045022100a2d355c1a460b4f
b7e000d37543ca85172d6f69a3ef084e3218e3970718083e4022027d648435c3f742c215eac0e4e5e16d446c96033d876b3de532160513ad6123d014
104c4506a275655a451fd7d43d9650661d5de7aeffb92101d2d702198a62a7f6b8ede1f8e7e70dfcb2e6d3ab5c29a7b7448fcc5052497998ecd022d6
be8241bbdc0ffffffff02e05d0954000000001976a9145466de9c2c4bbe7346470b1b028156996f151cc188ac406d1b23000000001976a914cf09a8b
3d56b1ae91f9f908ef5a485f12612d1b788ac00000000",
"0100000008986745fd96b4112c018e1cdecfe7f51008026f19822856bee9dbd789192d8b732a0000008b483045022100fa5fa977579fc60
e5a919d7d762cc191683790108c914b2265077a86143ead570220125c386f43d20c67df9d07b41f2ba60c808c747c519f9ce42d1ec7fb39a9eb9e014
10414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f75
65eedfeeb95ffffffffbd67aebc82a410c42183c5cdadb16597bf0f677112693a95ca40905e0c458a1c870000008c493046022100f62b188dac58832
4fd994452939165dbd3e0610f0dba88edc45162cb8adf66f8022100b5b637073059db398f29b566c17da3959866aaf6bc1209743c8dc3dc4ddc5cbf0
1410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f
7565eedfeeb95ffffffff708c77f212d0f70535aa1ab2a08d45499469d4c5b8c969166d18921e4c7ce36a360000008b4830450221009d41e4dc8095b
bf41cc707dd39b905d918061e9af1c3ebe4be27a1ebc5f5366f02200c3d0fd038a5276d75e7542b50008bf1739f4582b690d98e47609809d95b1a5a0
1410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f
7565eedfeeb95ffffffff72d37e5d931dd8c379052d702afb25983927055dd4a621aac66901a13bba6a9d2f0000008a47304402206b20c438e2a981c
82385eca99ac00d17bf3893c0b23092a3da9be747347edf4702201712aa42ff4bf37d64298c477b34061713989677c9fe4df0f619331025bcce62014
10414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f75
65eedfeeb95ffffffff80b290fc21ad8b97521fb67961a5983361ce053ba9959ab2188258857edbc215180000008b48304502210085c56958bafe3e8
32aadc2a354f2de76467b60e653a47b964c7eddb0f7344dda0220084d691b196acbbf33d94aec64d044f10f95f5050e58b00fb3309d72d41e3564014
10414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f75
65eedfeeb95ffffffff1053469ea8e4e643fff50eabe8ed92d0c877a4ca7497151304578fdba730425e750000008c493046022100a682b3cfd7aa01c
094aff041fa9e2102de37f76af91fa995cb1c82c644dfb42e022100c365c36ae78c41c318e635ba9c5c267db932a0ae6eaeec878a4dfded21e3bc310
1410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f
7565eedfeeb95ffffffff682397d21cf100e2e37819a25ddc9421bd35aab8aacbfb77e33ea2e50ded4079130000008c49304602210082767c02c33ee
d79d7afda96cedc03dd6368cb6b2f0ca0480b659d813d8b50ee0221008ab2aaec43210fdaaaeac23adb7d240ecf87c1b1e06149cba805401447e0926
601410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d
5f7565eedfeeb95fffffffff3326d4c5c34b116c4af6672e46ac09dabdb039a22e5cc249a2810a343328c343e0000008b4830450220395aa223d95ee
d4d1294ee987f358eb10f7d17310c98fd9f878f4fc84295b330022100e144ccd018f50eb6982ebe568dd6fd850920bd3e915f405c0866937249d7f76
601410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d
5f7565eedfeeb95ffffffff0266dc0200000000001976a914f52562ac702bd680e224adced83c83a18db7cead88ac400d380c000000001976a914bbc
dec3fc1e60e61815ce3017ef4628715f995bb88ac00000000",
"010000000199ea376b2eff833fc3e28beceaec19943b241d82803e5628ae15a5332fc016211e0000008c493046022100adf90d9a6875f81
da1777ec4bd3d4c243851807250bbba2a546afcd52c25f39e022100dbea922df2ee0297bc2fd4b336526f92fbb19e5341ada461188599f10e61e58f0
14104b785a383162fb61566fd8931ca81737150616f101f772d51185afa9626f22826e1eb539080d039f0ee1fb27afbbff059b25f67bf3ee48efbbd1
57058bcf8c16cffffffff02a29d0000000000001976a9148c5cfffd4b8b2b5c7491fd8f8bf29078edb9f18f88ac60198501000000001976a91411574
6a81d18e3142141facf9e0e34326c25831e88ac00000000",
"0100000001ded223b8ea4f7ba4586db2e6cf975719e7bd5d36febdabe8629b1c532e978d9a010000006c493046022100ef2467f2c8e806b
eeed1adb9456258f429b1ff97d7728415ff17611e5033d093022100cb22a3aec2a6a83a10e725c2f013a32efbc03d0d4d7ca59c7ef30c4d02b4cbcb0
12102cce9c77c9586f5ba9cf8682a200522b235f0aa3e46c681e7698f1867a47c071fffffffff0220a10700000000001976a914c9eb4dd2f5175a15f
b11a638450dba76396569be88ace02f3808000000001976a9142dbde30815faee5bf221d6688ebad7e12f7b2b1a88ac00000000",
"01000000017703b5bdddfcff918bd2502d13a37fcc41d3741711ba4ceb83a8d05bcb9b6b21010000006b483045022100cfceae940568471
7386c9abe5a6c49f2afaf6d6469a7263124c7435a1fbca46902205a2b75795dddf50c9cbf66b84690dbea29a8a00d797ad366f39ef7968890059e012
102cce9c77c9586f5ba9cf8682a200522b235f0aa3e46c681e7698f1867a47c071fffffffff0220a10700000000001976a914b0af94b8add7c589747
ebf5c8be217cf04fff1d888ac50ea1a05000000001976a9142dbde30815faee5bf221d6688ebad7e12f7b2b1a88ac00000000",
"01000000013e4ddad8766a7d899d60deeb958da585247c801dbfbaa6cb969f645e8cac40c8000000008b483045022100a6a031ab842b8b8
68ec384378016f28ed99224370e478e3e974a64783fba778902201802cbbdae85017805ee2d54870d3422a0b1c7a205466c9343ed4ad27dc8e3a1014
104c77300900a901b0e1eb2e3883ac6a7527c54eb377c8ac5cb68882ee885ed98c7f57b85e302436b6d81ff890f5693415d68bc7d53c2d1266a138c8
b2dde17ff86ffffffff02b0e94a07000000001976a91436e284659b13cc4df6a24efa38298321fe3879b088ac20e88d00000000001976a91423d5b12
c9deba304b7773cd5a7de0d55a739852988ac00000000",
"0100000001e908118907b83ad6db5250271070c7253971a2c3b7a47a283953a4640096bc4d000000008c493046022100985506639078d54
456521db3ac08731623de5746645ffa8ad728e10f95e13842022100e73dc34ecb35741d6e88095e74c5aa6312b198d30ee41e6d605f814fdcf381e50
141048afb3763791c66be7de9087c4770606910665f499c4ea3928245eb19cecab2201c2828fbaaa9929602a347186a36af2a97bc71e2df511d30c6b
ae823585193faffffffff026a709a01000000001976a914ec9891bfba0c64a4683a73dca4c1fb2e630145b588ac01000000000000001976a914d01ee
ecf89e7b13082b9e90a1a8c62115465bd3b88ac00000000",
"01000000011ab8482a97a10f046513944e1425e601a296920d469184c8ad937c31043078e0000000008b48304502206f0480265d67e0f0a
7084610f545439b1c35cf1f98e6181d932d1db1238fc2380221008c302b27c3ba22c478dec3feb0fb7c1235be615afa627641a0bfc7ac9d939dfd014
104e9c6e19c370c5246599406629d30af585a22951bad08699b2a164f5213bf4620ca839b84505da72072973af8cc5e133f2b85948dfd553db1a91d4
7da92eed571ffffffff02a04da206000000001976a914cee251fb299a547d29e2d3f8c0475f8c3a8b793688acc0d8a700000000001976a914c347c45
81999a0f2875aa9ddbee9e47236b291e788ac00000000",
"01000000019032628f653fba3273c0124294ec60567c675c35866326b235fbe9bb0179c370000000008a473044022075a988ab396170d17
9872320ad663ca41bd12b1ca5db007ada82e178f9508d4502200c03e286231346e3e5f2cbb4728265d8fd748d74df637a1edd3a32eba0885cf001410
458e0f4cc38664fdf047cc4f59cc2f62768d51d7072a0cb453644da167ea2526612f2d59e66c44ded15b1603a5d4091368ac3e8def80060312f6acf0
1c49d711dffffffff0230a21306000000001976a914539fde3640b31e49096aaab08907461c59e7740988ac20e88d00000000001976a91423d5b12c9
deba304b7773cd5a7de0d55a739852988ac00000000"
],
"coinbasevalue" : 5001450000,
"coinbaseflags" : "062f503253482f",
"time" : 1332941492,
"mintime" : 1332938361,
"curtime" : 1332941492,
"bits" : "1a0b3287"
}
true
E:\bitcoin\bitcoin-0.6.0rc5+customfee-win32>bitcoind getmemorypool
{
"version" : 1,
"previousblockhash" : "000000000000087818d53138fbd4256625e37c98a38b6fe8569e56852c92ab70",
"transactions" : [
"0100000004820c6bd1fa106889710348767abb456e5f38b82c3acf570a3c2635480bab6761010000008c493046022100f3cd34b9f81b525
45b31fc3b25c2042db02d2924bf7e69a22adbbfd4ad080a17022100dd0683a739959d8d1a98d94ffd7ed06ad4d2da3b81ab3e2327d6b74746cfd51b0
14104854590bebc0e4b6daccf49084bb9df726c34bc1038f41cfdfc6e1738d84768ee682492c7f05c726dd1e5539bf5ee41233189e5b82295faad798
7f31012aac52affffffff73a1e10e24c7aee9e4d868692cc4249dfb7189dddbeecf3943d24c0badf10757010000008c493046022100e6a8db0114607
be4cb186154a1c7822712d5659d8121f08e19acfe7d67ad3441022100cd2370ffeebce357aad64ce7d731b2be881e047aa2c3bcc6767c114ad4fc785
f0141041a0067d8576419beee8815c37393f617e9f673e6465962f83c6b6274b5e173eae2bb30ffd78e7571e5ce5db5fe4f2b1b641d6ceb51aad3435
fa4566cf0828a1effffffffbd4e061d000de7688e4de4d7111ddb804de9d2cbd1217748038e296b0c03cc02010000008b483045022100e54f20c2758
17ab65cff34ab1c3591dbf9ab25f1c1996d806404f746b935534202207f5bda330867c1d214bfdacf0a2a18bce38f0ddea35fba8b9ae65d2d62d962c
1014104854590bebc0e4b6daccf49084bb9df726c34bc1038f41cfdfc6e1738d84768ee682492c7f05c726dd1e5539bf5ee41233189e5b82295faad7
987f31012aac52afffffffff4a1d363c469b1ff2df888f82a02402accafb01cddc3b00f22299afd5487721b010000008a47304402203ace625c70475
cf2de8f41e3e492c13c4cf459cae42b1c37ba5ae1ad1f18c57f02200c57f4f0fc49be27f3933decb8e22ba89337f1e57a7e38e33642e142515501fa0
14104854590bebc0e4b6daccf49084bb9df726c34bc1038f41cfdfc6e1738d84768ee682492c7f05c726dd1e5539bf5ee41233189e5b82295faad798
7f31012aac52affffffff0249a5a700000000001976a914b31e6898ceb2fe42ab62ee03400ac24cab90be0f88ac00ca9a3b000000001976a914abe03
f415de01d078829249d0abdec8c61466aab88ac00000000",
"0100000001595e7ee07f3d6036f2e28c290e4e5cab0689fc5153217fff0e43e95118862c61000000008b483045022100a2d355c1a460b4f
b7e000d37543ca85172d6f69a3ef084e3218e3970718083e4022027d648435c3f742c215eac0e4e5e16d446c96033d876b3de532160513ad6123d014
104c4506a275655a451fd7d43d9650661d5de7aeffb92101d2d702198a62a7f6b8ede1f8e7e70dfcb2e6d3ab5c29a7b7448fcc5052497998ecd022d6
be8241bbdc0ffffffff02e05d0954000000001976a9145466de9c2c4bbe7346470b1b028156996f151cc188ac406d1b23000000001976a914cf09a8b
3d56b1ae91f9f908ef5a485f12612d1b788ac00000000",
"0100000008986745fd96b4112c018e1cdecfe7f51008026f19822856bee9dbd789192d8b732a0000008b483045022100fa5fa977579fc60
e5a919d7d762cc191683790108c914b2265077a86143ead570220125c386f43d20c67df9d07b41f2ba60c808c747c519f9ce42d1ec7fb39a9eb9e014
10414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f75
65eedfeeb95ffffffffbd67aebc82a410c42183c5cdadb16597bf0f677112693a95ca40905e0c458a1c870000008c493046022100f62b188dac58832
4fd994452939165dbd3e0610f0dba88edc45162cb8adf66f8022100b5b637073059db398f29b566c17da3959866aaf6bc1209743c8dc3dc4ddc5cbf0
1410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f
7565eedfeeb95ffffffff708c77f212d0f70535aa1ab2a08d45499469d4c5b8c969166d18921e4c7ce36a360000008b4830450221009d41e4dc8095b
bf41cc707dd39b905d918061e9af1c3ebe4be27a1ebc5f5366f02200c3d0fd038a5276d75e7542b50008bf1739f4582b690d98e47609809d95b1a5a0
1410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f
7565eedfeeb95ffffffff72d37e5d931dd8c379052d702afb25983927055dd4a621aac66901a13bba6a9d2f0000008a47304402206b20c438e2a981c
82385eca99ac00d17bf3893c0b23092a3da9be747347edf4702201712aa42ff4bf37d64298c477b34061713989677c9fe4df0f619331025bcce62014
10414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f75
65eedfeeb95ffffffff80b290fc21ad8b97521fb67961a5983361ce053ba9959ab2188258857edbc215180000008b48304502210085c56958bafe3e8
32aadc2a354f2de76467b60e653a47b964c7eddb0f7344dda0220084d691b196acbbf33d94aec64d044f10f95f5050e58b00fb3309d72d41e3564014
10414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f75
65eedfeeb95ffffffff1053469ea8e4e643fff50eabe8ed92d0c877a4ca7497151304578fdba730425e750000008c493046022100a682b3cfd7aa01c
094aff041fa9e2102de37f76af91fa995cb1c82c644dfb42e022100c365c36ae78c41c318e635ba9c5c267db932a0ae6eaeec878a4dfded21e3bc310
1410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d5f
7565eedfeeb95ffffffff682397d21cf100e2e37819a25ddc9421bd35aab8aacbfb77e33ea2e50ded4079130000008c49304602210082767c02c33ee
d79d7afda96cedc03dd6368cb6b2f0ca0480b659d813d8b50ee0221008ab2aaec43210fdaaaeac23adb7d240ecf87c1b1e06149cba805401447e0926
601410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d
5f7565eedfeeb95fffffffff3326d4c5c34b116c4af6672e46ac09dabdb039a22e5cc249a2810a343328c343e0000008b4830450220395aa223d95ee
d4d1294ee987f358eb10f7d17310c98fd9f878f4fc84295b330022100e144ccd018f50eb6982ebe568dd6fd850920bd3e915f405c0866937249d7f76
601410414bf0a8673732d34c20aee6c790a563d4025278ae510ff2ff4e0e2098bd65cd892ec596a7335fb250ecf70dd54a1351214301da2b69bfad4d
5f7565eedfeeb95ffffffff0266dc0200000000001976a914f52562ac702bd680e224adced83c83a18db7cead88ac400d380c000000001976a914bbc
dec3fc1e60e61815ce3017ef4628715f995bb88ac00000000",
"010000000199ea376b2eff833fc3e28beceaec19943b241d82803e5628ae15a5332fc016211e0000008c493046022100adf90d9a6875f81
da1777ec4bd3d4c243851807250bbba2a546afcd52c25f39e022100dbea922df2ee0297bc2fd4b336526f92fbb19e5341ada461188599f10e61e58f0
14104b785a383162fb61566fd8931ca81737150616f101f772d51185afa9626f22826e1eb539080d039f0ee1fb27afbbff059b25f67bf3ee48efbbd1
57058bcf8c16cffffffff02a29d0000000000001976a9148c5cfffd4b8b2b5c7491fd8f8bf29078edb9f18f88ac60198501000000001976a91411574
6a81d18e3142141facf9e0e34326c25831e88ac00000000",
"0100000001ded223b8ea4f7ba4586db2e6cf975719e7bd5d36febdabe8629b1c532e978d9a010000006c493046022100ef2467f2c8e806b
eeed1adb9456258f429b1ff97d7728415ff17611e5033d093022100cb22a3aec2a6a83a10e725c2f013a32efbc03d0d4d7ca59c7ef30c4d02b4cbcb0
12102cce9c77c9586f5ba9cf8682a200522b235f0aa3e46c681e7698f1867a47c071fffffffff0220a10700000000001976a914c9eb4dd2f5175a15f
b11a638450dba76396569be88ace02f3808000000001976a9142dbde30815faee5bf221d6688ebad7e12f7b2b1a88ac00000000",
"01000000017703b5bdddfcff918bd2502d13a37fcc41d3741711ba4ceb83a8d05bcb9b6b21010000006b483045022100cfceae940568471
7386c9abe5a6c49f2afaf6d6469a7263124c7435a1fbca46902205a2b75795dddf50c9cbf66b84690dbea29a8a00d797ad366f39ef7968890059e012
102cce9c77c9586f5ba9cf8682a200522b235f0aa3e46c681e7698f1867a47c071fffffffff0220a10700000000001976a914b0af94b8add7c589747
ebf5c8be217cf04fff1d888ac50ea1a05000000001976a9142dbde30815faee5bf221d6688ebad7e12f7b2b1a88ac00000000",
"01000000013e4ddad8766a7d899d60deeb958da585247c801dbfbaa6cb969f645e8cac40c8000000008b483045022100a6a031ab842b8b8
68ec384378016f28ed99224370e478e3e974a64783fba778902201802cbbdae85017805ee2d54870d3422a0b1c7a205466c9343ed4ad27dc8e3a1014
104c77300900a901b0e1eb2e3883ac6a7527c54eb377c8ac5cb68882ee885ed98c7f57b85e302436b6d81ff890f5693415d68bc7d53c2d1266a138c8
b2dde17ff86ffffffff02b0e94a07000000001976a91436e284659b13cc4df6a24efa38298321fe3879b088ac20e88d00000000001976a91423d5b12
c9deba304b7773cd5a7de0d55a739852988ac00000000",
"0100000001e908118907b83ad6db5250271070c7253971a2c3b7a47a283953a4640096bc4d000000008c493046022100985506639078d54
456521db3ac08731623de5746645ffa8ad728e10f95e13842022100e73dc34ecb35741d6e88095e74c5aa6312b198d30ee41e6d605f814fdcf381e50
141048afb3763791c66be7de9087c4770606910665f499c4ea3928245eb19cecab2201c2828fbaaa9929602a347186a36af2a97bc71e2df511d30c6b
ae823585193faffffffff026a709a01000000001976a914ec9891bfba0c64a4683a73dca4c1fb2e630145b588ac01000000000000001976a914d01ee
ecf89e7b13082b9e90a1a8c62115465bd3b88ac00000000",
"01000000011ab8482a97a10f046513944e1425e601a296920d469184c8ad937c31043078e0000000008b48304502206f0480265d67e0f0a
7084610f545439b1c35cf1f98e6181d932d1db1238fc2380221008c302b27c3ba22c478dec3feb0fb7c1235be615afa627641a0bfc7ac9d939dfd014
104e9c6e19c370c5246599406629d30af585a22951bad08699b2a164f5213bf4620ca839b84505da72072973af8cc5e133f2b85948dfd553db1a91d4
7da92eed571ffffffff02a04da206000000001976a914cee251fb299a547d29e2d3f8c0475f8c3a8b793688acc0d8a700000000001976a914c347c45
81999a0f2875aa9ddbee9e47236b291e788ac00000000",
"01000000019032628f653fba3273c0124294ec60567c675c35866326b235fbe9bb0179c370000000008a473044022075a988ab396170d17
9872320ad663ca41bd12b1ca5db007ada82e178f9508d4502200c03e286231346e3e5f2cbb4728265d8fd748d74df637a1edd3a32eba0885cf001410
458e0f4cc38664fdf047cc4f59cc2f62768d51d7072a0cb453644da167ea2526612f2d59e66c44ded15b1603a5d4091368ac3e8def80060312f6acf0
1c49d711dffffffff0230a21306000000001976a914539fde3640b31e49096aaab08907461c59e7740988ac20e88d00000000001976a91423d5b12c9
deba304b7773cd5a7de0d55a739852988ac00000000"
],
"coinbasevalue" : 5001450000,
"coinbaseflags" : "062f503253482f",
"time" : 1332941492,
"mintime" : 1332938361,
"curtime" : 1332941492,
"bits" : "1a0b3287"
}
Roughly 10% of tx volume includes a fee of some token amount.
p2pool works fine with modified bitcoind. I have noticed no errors, changes in payout, increase in stales, or reduction reported hashpower.
March 28, 2012, 07:29:21 AM
Polvos, you also offered to contribute toward the bounty; if you feel the desire to tip me, you can use 1DGzpZzce1c7nsg1SN7exV6bsaju1Mcrc6 - it's fine with me if you choose not to, though.
Nice work, coder. Tipped you 5 BTC. Please, can you think a little about the melt mining work? I think it's good to counter MtGox abuse. Thank you.
March 27, 2012, 01:32:00 PM
One related question. Is it possible to have bitcoind create a tx but not broadcast it? If so is it then part of the memorypool? If not could bitcoind be modified to make it part of the memorypool? Essentially I want the ability to include a tx in a block that hasn't been broadcasted (coin melting).
YU-HUUUU
Let's melt some coins and hearts.
March 27, 2012, 12:03:38 PM
That wouldn't allow miners to change fees quickly. IMO, a better solution is to push a URI and signing pubkeyhash into the coinbase... then have a simple (signed) script at the URI that calculates the fee required for a given txn.
"n" could be one block, or are you suggesting that miners would need to vary within a single block?
EDIT: I suggested that the client generate the fee from a message as it might be possible for the miner to be down/DDoSd, and another miner could/would pick up the txn.
Are there use cases where a script at a URI would be an issue due to latency? I'm thinking of fast txns over slow/satellite links, but can't honestly think of a current use case for that scenario (the bitcoin cash terminal is the only one I can think of that may be relevant).
marked
March 27, 2012, 11:46:56 AM
That wouldn't allow miners to change fees quickly. IMO, a better solution is to push a URI and signing pubkeyhash into the coinbase... then have a simple (signed) script at the URI that calculates the fee required for a given txn.
Interesting. Or possibly just a signed fee manifest at the URI. Client detects new block, checks coinbase for tx fee data and uses uri to grab fee manifest. Client updates its database.
Alternatively if blocks are signed (which is useful in other applications) with pubkeyhash a miner could simply transmit an updated fee manifest (via a new message type) to the network as needed. each node would check to validate manifest and relay only if valid. some sort of spam rule would be needed to avoid a DOS. Still the combination of node being able to sign the block (proof of hashing power) and publish a fee manifest gives clients the ability to compute time vs fee effectively.
Anyways this is why it is useful to start the discussion.
March 27, 2012, 11:44:02 AM
My first thought is that the protocol could be modified so that the fee data is added to block (coinbase?). That way the client can look at the last x blocks and get an estimate of the fees the network is requiring. That combined with the number of pending tx and their included fees would allow the client to make educated guesses on confirmation times.
That wouldn't allow miners to change fees quickly. IMO, a better solution is to push a URI and signing pubkeyhash into the coinbase... then have a simple (signed) script at the URI that calculates the fee required for a given txn. March 27, 2012, 11:32:40 AM
I do think something like that will be needed in time so the client can make informed decisions on confirmation time vs cost.
It might be a little early adding that to the protocol but given fees can be dynamic that information will need to be shared and the network already has the infrastructure for relaying information in a p2p fashion. The one thing I am not sure about is that for the info to be useful you would want proof of hashing power. It doesn't matter what % of nodes say they require a fee of 0.0025 what matters is what % of the hashing power does.
My first thought is that the protocol could be modified so that the fee data is added to block (coinbase?). That way the client can look at the last x blocks and get an estimate of the fees the network is requiring. That combined with the number of pending tx and their included fees would allow the client to make educated guesses on confirmation times.
Still we likely are years away from needing such a protocol enhancement but it is good to start thinking about it.
It might be a little early adding that to the protocol but given fees can be dynamic that information will need to be shared and the network already has the infrastructure for relaying information in a p2p fashion. The one thing I am not sure about is that for the info to be useful you would want proof of hashing power. It doesn't matter what % of nodes say they require a fee of 0.0025 what matters is what % of the hashing power does.
My first thought is that the protocol could be modified so that the fee data is added to block (coinbase?). That way the client can look at the last x blocks and get an estimate of the fees the network is requiring. That combined with the number of pending tx and their included fees would allow the client to make educated guesses on confirmation times.
Still we likely are years away from needing such a protocol enhancement but it is good to start thinking about it.
March 27, 2012, 11:26:39 AM
I'd like to make a suggestion that a mining pool announces the TX fee to the network.
The announcement is a simple message containing a pool id, a fee, and a txfee duration. The message is signed with the pool public key.
The fee is valid for the next "n" blocks where "n" is a value determined to be no less than 6 valid tx blocks, and no more than 6*24*30 blocks.
So for example
deathandtaxes mines with a min fee of 0.01
slush mines with a min fee of 0.005
eclipsemc mines with a min fee of 0.001
deepbit mines with a min fee of 0.0005
eligius mines with a min fee of 0.0002
(not casting doubt on hashing power, but just choosing pools from memory and in no particular order.)
In this instance my client can choose
to be somewhat lax, and have it on a when it gets confirmed if at all basis with a fee of <0.0002,
to get the somewhere during this day, at 0.0002
to get confirmed within a half day, at 0.0005
to get confirmed within 3 hours, at 0.001
to get confirmed within 1 hour at 0.005
to get confirmed in the next valid tx block at 0.01 (because all mining block finders would include under that structure)
thoughts?
marked
The announcement is a simple message containing a pool id, a fee, and a txfee duration. The message is signed with the pool public key.
The fee is valid for the next "n" blocks where "n" is a value determined to be no less than 6 valid tx blocks, and no more than 6*24*30 blocks.
- 6 valid TX block to bypass the 0TX miner otherwise it is theoretically possible to send a tx and have a new fee structure, so the tx gets dropped.
- Client's would need to be modified to listen for this message. A set of known public keys to decrypt the message or authenticate it would be required from each mining pool and included in each client.
- If a block is mined with a non-announcing pool/miner then the fee is set to a default.
So for example
deathandtaxes mines with a min fee of 0.01
slush mines with a min fee of 0.005
eclipsemc mines with a min fee of 0.001
deepbit mines with a min fee of 0.0005
eligius mines with a min fee of 0.0002
(not casting doubt on hashing power, but just choosing pools from memory and in no particular order.)
In this instance my client can choose
to be somewhat lax, and have it on a when it gets confirmed if at all basis with a fee of <0.0002,
to get the somewhere during this day, at 0.0002
to get confirmed within a half day, at 0.0005
to get confirmed within 3 hours, at 0.001
to get confirmed within 1 hour at 0.005
to get confirmed in the next valid tx block at 0.01 (because all mining block finders would include under that structure)
thoughts?
marked
March 27, 2012, 09:35:02 AM
One related question. Is it possible to have bitcoind create a tx but not broadcast it? If so is it then part of the memorypool? If not could bitcoind be modified to make it part of the memorypool? Essentially I want the ability to include a tx in a block that hasn't been broadcasted (coin melting).
Possible, but might not be simple to do in bitcoind. March 27, 2012, 09:27:04 AM
Thanks for the binaries.
I had a problem when copying existing blockchain & wallet (which is empty) from RC2 version. Yeah stupidly I didn't write down the error. I cleared the data directory and bitcoind worked fine from a coldstart (created new wallet and downloaded entire blockcahin).
The modified bitcoind has been powering my p2pool instance for 10 hours now and p2pool hasn't reported any errors and I see no change in sharechain deads, rejects, or orphans.
I adjusted fee to 0.01 BTC, to zero, and to 1 satoshi. For all values getmininginfo showed set minfee properly and getmemorypool returned the correct transactions (decoding them to verify was "fun"
).
For anyone interested I will post some screenshots this evening and provide an update. Given I only have 15GH/s it likely will take a while before I see a block from the custom memorypool but p2pool doesn't have a problem with the memorypool returned.
Thanks for your help Luke. I have some ideas to build upon this in the future that may alleviate some of the (unecessary IMHO) concern.
One related question. Is it possible to have bitcoind create a tx but not broadcast it? If so is it then part of the memorypool? If not could bitcoind be modified to make it part of the memorypool? Essentially I want the ability to include a tx in a block that hasn't been broadcasted (coin melting).
I had a problem when copying existing blockchain & wallet (which is empty) from RC2 version. Yeah stupidly I didn't write down the error. I cleared the data directory and bitcoind worked fine from a coldstart (created new wallet and downloaded entire blockcahin).
The modified bitcoind has been powering my p2pool instance for 10 hours now and p2pool hasn't reported any errors and I see no change in sharechain deads, rejects, or orphans.
I adjusted fee to 0.01 BTC, to zero, and to 1 satoshi. For all values getmininginfo showed set minfee properly and getmemorypool returned the correct transactions (decoding them to verify was "fun"
). For anyone interested I will post some screenshots this evening and provide an update. Given I only have 15GH/s it likely will take a while before I see a block from the custom memorypool but p2pool doesn't have a problem with the memorypool returned.
Thanks for your help Luke. I have some ideas to build upon this in the future that may alleviate some of the (unecessary IMHO) concern.
One related question. Is it possible to have bitcoind create a tx but not broadcast it? If so is it then part of the memorypool? If not could bitcoind be modified to make it part of the memorypool? Essentially I want the ability to include a tx in a block that hasn't been broadcasted (coin melting).
March 26, 2012, 03:56:33 PM
If you want, I could trivially build a Windows binary. I won't bill for the time spent by the compiler, of course :p
That would be great. Thanks.
March 26, 2012, 03:55:09 PM
Nevermind, I can see how % rates are unworkable now.
I think pay-per-KB or per byte or whatever is reasonable, but I think it needs a little more tweaking so the whole network can be informed about what fees miners are charging. I think that a per-KB fee should also make spam fees obsolete.
The only problem that I can see is that, as per the scenario you outlined, fees might vary by several orders of magnitude, which might make it a huge pain for a client to decide on a fee. Is it possible for a client to determine what % of hashing power is charging what? If you can figure that out, then you could create a "confidence scale" to match a minimum fee with a minimum confidence rate.
I think pay-per-KB or per byte or whatever is reasonable, but I think it needs a little more tweaking so the whole network can be informed about what fees miners are charging. I think that a per-KB fee should also make spam fees obsolete.
The only problem that I can see is that, as per the scenario you outlined, fees might vary by several orders of magnitude, which might make it a huge pain for a client to decide on a fee. Is it possible for a client to determine what % of hashing power is charging what? If you can figure that out, then you could create a "confidence scale" to match a minimum fee with a minimum confidence rate.
March 26, 2012, 03:31:39 PM
Polvos, you also offered to contribute toward the bounty; if you feel the desire to tip me, you can use 1DGzpZzce1c7nsg1SN7exV6bsaju1Mcrc6 - it's fine with me if you choose not to, though.
Let's see how works your code and I will tip you some coins. For the moment it seems quite promising. Good work.
March 26, 2012, 02:48:59 PM
".01 BTC" is not a reasonable fee, period. Here's why.
That is how free markets work. If I want to change 0.01 BTC I can. Obviously I lose your business. Someone else might charge 0.005, someone else 0.001, someone else might accept free tx.
There is no scenario where every miner demands the exact same fee amount.
Hypothetically someday lets say:
10% of miners require a fee of at least 0.01 BTC
25% of miners require a fee of at least 0.005 BTC
25% of miners require a fee of at least 0.0001 BTC
20% of miners require a fee of at least a single satoshi.
20% of miners require no fee.
Obviously in reality this sliding scale would have many more data points but using this as an example.
If you included no fee your tx would still be processed but only 20% of the network would be working on it so confirmation time is 50 min.
If you included a single satoshi as a fee then 40% of the network would be working on it so your confirmation time drops to only 25 min.
If you included a fee of 0.0001 (1/20th of a cent at todays value) you buy 65% of the network and avg confirmation of 15 min.
etc.
If miners broadcasted fee schedules and hashing power via a p2p protocol clients could advise users on fees and projected confirmation times.
Another option would be to include a "charity window". Miner could specify to include x or x% of outstanding tx which are below the fee limit. "low fee" tx would be processed first come first serve after priority tx so confirmation times would be longer but they would be processed.
Quote
I would say a "Fair" rate is more like 0.05%, maybe 0.025%, with a spam fee that increases exponentially per digit below the spam threshold, say 20% to send 0.001BTC, 50% for 0.0001BTC, 100% for 0.00001BTC, and doubling forward. Of course, since this was very poorly thought out before client was released, figuring out how to reach any kind of consensus between miners and clients is not going to be easy.
% based fees are neither desirable nor possible in the Bitcoin network. What you or I consider fair is irrelevant. Most miners will likely accept 0 BTC tx, each if free to set their own price. Users are free to set what they are willing to pay. The market (not you or me) will determine what is "fair".
Fair price in a free market is what someone is willing to pay and someone is willing to sell. What is being bought and sold is inclusion of a tx in the next block.
Quote
unless all miners and all clients agree to what a reasonable fee is, there's going to be serious conflicts at some point. Either significant numbers of empty blocks, no way for a client to determine what a "good" fee is
That is simply impossible. 100% consensus on "fair" never happens. Only central control can implement price controls. IF you feel that is the only possible "fix" then you should uninstall Bitcoin now because it will NEVER happen in a decentralized network.Quote
and if enough people get tired of that behavior, you might end up on your very own blockchain fork one day. Of course, for the protocol to change at all, and for any reason would generally end up producing large forks, which is a major downside of the BTC system, and of the fact that it's experimental.
This requires no protocol change. If hypothetically miners setting their own tx fees was outlawed by some future protocol change well I could simply stop (and I likely would stop mining too).
March 26, 2012, 02:47:04 PM
Your argument seems to be based entirely on trying to profit from usury. Usury is evil, so IMO your argument can be ignored. 
Lol, well then my resources stay in fiat or PMs.
That is far from the point. The point isnt to decide what is and isnt a reasonable fee, the point is to see what the market will shift towards as subsidy decreases. And I have yet to hear a reason why it wouldn't shift down quite low at that time.
How are market values determined? Except by what the miners who control the majority processing power arbitrarily decide? In any other economic situation the trade between price and willing customers would necessarily lead to fair market prices, but here if a miner creates a block, then they basically get to decide the network's fee policy for the next 10 minutes all to themselves. That might be somewhat reasonable at a 0% subsidy, but at current that could easily kill the network if a majority of miners happen to be stupid (which is guaranteed in the long run). With no way for a fair market price to be determined by supply and demand, miners become parasites who decide on their own welfare checks, and users become orphaned trying to discover what fee will reasonably get their tx pushed.
March 26, 2012, 02:43:41 PM
I won't bill for the time spent by the compiler, of course :p
March 26, 2012, 02:36:56 PM
".01 BTC" is not a reasonable fee, period. Here's why.
That is far from the point. The point isnt to decide what is and isnt a reasonable fee, the point is to see what the market will shift towards as subsidy decreases. And I have yet to hear a reason why it wouldnt shift down quite low at that time. March 26, 2012, 02:35:10 PM
a) provide p2pool users some control
Hey, don't forget BitPenny and Eligius miners! Now is there a guide anywhere for compiling modified version of bitcoind under windows?
If you want, I could trivially build a Windows binary. I won't bill for the time spent by the compiler, of course :p".01 BTC" is not a reasonable fee, period. Here's why.
Your argument seems to be based entirely on trying to profit from usury. Usury is evil, so IMO your argument can be ignored. March 26, 2012, 02:26:27 PM
".01 BTC" is not a reasonable fee, period. Here's why.
I lend 1BTC to someone for 1 day, interest paid is 1%, total 1.01 BTC due.
I pay him the 1BTC loan, there's 0.01BTC paid to you.
He spends his 1BTC on whatever it is he wanted, there's 0.01 BTC paid to you.
He trades cash for 1.01BTC to pay me back, another 0.01 BTC paid to you.
He sends me the 1.01BTC, there's another .01BTC paid to you.
The interest on the loan was 0.01 BTC, total interest paid to me = 0.01BTC, interest paid to you just for the tx, .04 BTC, or 4 times the interest the loan was worth. This sort of 1BTC/1% transaction happens regularly on the lending forum.
I should point out that western union does indeed charge based on how much you send, although it's a flat rate for up to a certain amount, but that's pretty irrelevant. I would say a "Fair" rate is more like 0.05%, maybe 0.025%, with a spam fee that increases exponentially per digit below the spam threshold, say 20% to send 0.001BTC, 50% for 0.0001BTC, 100% for 0.00001BTC, and doubling forward. Of course, since this was very poorly thought out before client was released, figuring out how to reach any kind of consensus between miners and clients is not going to be easy.
I won't spam up this thread anymore, but I think what you are proposing has serious flaws. Since the blockchain is a "tragedy of the commons" type of problem, unless all miners and all clients agree to what a reasonable fee is, there's going to be serious conflicts at some point. Either significant numbers of empty blocks, no way for a client to determine what a "good" fee is, and if enough people get tired of that behavior, you might end up on your very own blockchain fork one day. Of course, for the protocol to change at all, and for any reason would generally end up producing large forks, which is a major downside of the BTC system, and of the fact that it's experimental.
If you are dealing with piddly small amounts like that, you can deal with waiting longer for fee-free transactions to be processed by generous nodes. I lend 1BTC to someone for 1 day, interest paid is 1%, total 1.01 BTC due.
I pay him the 1BTC loan, there's 0.01BTC paid to you.
He spends his 1BTC on whatever it is he wanted, there's 0.01 BTC paid to you.
He trades cash for 1.01BTC to pay me back, another 0.01 BTC paid to you.
He sends me the 1.01BTC, there's another .01BTC paid to you.
The interest on the loan was 0.01 BTC, total interest paid to me = 0.01BTC, interest paid to you just for the tx, .04 BTC, or 4 times the interest the loan was worth. This sort of 1BTC/1% transaction happens regularly on the lending forum.
I should point out that western union does indeed charge based on how much you send, although it's a flat rate for up to a certain amount, but that's pretty irrelevant. I would say a "Fair" rate is more like 0.05%, maybe 0.025%, with a spam fee that increases exponentially per digit below the spam threshold, say 20% to send 0.001BTC, 50% for 0.0001BTC, 100% for 0.00001BTC, and doubling forward. Of course, since this was very poorly thought out before client was released, figuring out how to reach any kind of consensus between miners and clients is not going to be easy.
I won't spam up this thread anymore, but I think what you are proposing has serious flaws. Since the blockchain is a "tragedy of the commons" type of problem, unless all miners and all clients agree to what a reasonable fee is, there's going to be serious conflicts at some point. Either significant numbers of empty blocks, no way for a client to determine what a "good" fee is, and if enough people get tired of that behavior, you might end up on your very own blockchain fork one day. Of course, for the protocol to change at all, and for any reason would generally end up producing large forks, which is a major downside of the BTC system, and of the fact that it's experimental.
March 26, 2012, 02:23:12 PM
".01 BTC" is not a reasonable fee, period. Here's why.
I lend 1BTC to someone for 1 day, interest paid is 1%, total 1.01 BTC due.
I pay him the 1BTC loan, there's 0.01BTC paid to you.
He spends his 1BTC on whatever it is he wanted, there's 0.01 BTC paid to you.
He trades cash for 1.01BTC to pay me back, another 0.01 BTC paid to you.
He sends me the 1.01BTC, there's another .01BTC paid to you.
The interest on the loan was 0.01 BTC, total interest paid to me = 0.01BTC, interest paid to you just for the tx, .04 BTC, or 4 times the interest the loan was worth. This sort of 1BTC/1% transaction happens regularly on the lending forum.
I should point out that western union does indeed charge based on how much you send, although it's a flat rate for up to a certain amount, but that's pretty irrelevant. I would say a "Fair" rate is more like 0.05%, maybe 0.025%, with a spam fee that increases exponentially per digit below the spam threshold, say 20% to send 0.001BTC, 50% for 0.0001BTC, 100% for 0.00001BTC, and doubling forward. Of course, since this was very poorly thought out before client was released, figuring out how to reach any kind of consensus between miners and clients is not going to be easy.
I won't spam up this thread anymore, but I think what you are proposing has serious flaws. Since the blockchain is a "tragedy of the commons" type of problem, unless all miners and all clients agree to what a reasonable fee is, there's going to be serious conflicts at some point. Either significant numbers of empty blocks, no way for a client to determine what a "good" fee is, and if enough people get tired of that behavior, you might end up on your very own blockchain fork one day. Of course, for the protocol to change at all, and for any reason would generally end up producing large forks, which is a major downside of the BTC system, and of the fact that it's experimental.
I lend 1BTC to someone for 1 day, interest paid is 1%, total 1.01 BTC due.
I pay him the 1BTC loan, there's 0.01BTC paid to you.
He spends his 1BTC on whatever it is he wanted, there's 0.01 BTC paid to you.
He trades cash for 1.01BTC to pay me back, another 0.01 BTC paid to you.
He sends me the 1.01BTC, there's another .01BTC paid to you.
The interest on the loan was 0.01 BTC, total interest paid to me = 0.01BTC, interest paid to you just for the tx, .04 BTC, or 4 times the interest the loan was worth. This sort of 1BTC/1% transaction happens regularly on the lending forum.
I should point out that western union does indeed charge based on how much you send, although it's a flat rate for up to a certain amount, but that's pretty irrelevant. I would say a "Fair" rate is more like 0.05%, maybe 0.025%, with a spam fee that increases exponentially per digit below the spam threshold, say 20% to send 0.001BTC, 50% for 0.0001BTC, 100% for 0.00001BTC, and doubling forward. Of course, since this was very poorly thought out before client was released, figuring out how to reach any kind of consensus between miners and clients is not going to be easy.
I won't spam up this thread anymore, but I think what you are proposing has serious flaws. Since the blockchain is a "tragedy of the commons" type of problem, unless all miners and all clients agree to what a reasonable fee is, there's going to be serious conflicts at some point. Either significant numbers of empty blocks, no way for a client to determine what a "good" fee is, and if enough people get tired of that behavior, you might end up on your very own blockchain fork one day. Of course, for the protocol to change at all, and for any reason would generally end up producing large forks, which is a major downside of the BTC system, and of the fact that it's experimental.
March 26, 2012, 01:35:32 PM
Of course but right now you choices are accept all tx or pocess no tx. Here at least you now have some crude control. This was intended to be a starting point to a) provide p2pool users some control and b) spark a conversation on mining fees.
Right now, the choice for those using the original satoshi client is either a) accept everything that passes the anti-spam rules or b) dont mine.Don't get me wrong, this patch is a cool idea, but in the long run its unlikely to make a difference, and in the short run, you really need to get mining pools involved, a few p2pool users doesnt do much...
To spark a discussion on txfees, you need to come up with a real solution to the long term issues with txfees, which this is not.
At this point it is more the principal of the issue and to spark a debate. The "cost" to a miner is essentially nothing (even one with dozens of GH/s). If not enough miners start enforcing higher fees then fees won't rise but the amount lost remains "almost nothing". If enough miners start enforcing higher fees then all miners benefit. Yeah there is some aspect of tragedy of the commons but w/ block subsidies still high (yes 25 BTC is high) the "cost" of helping is nearly nothing.
Again, this isnt a serious suggestion, nor is it actually a suggestion at all to modify/fix the fee system, it just makes it easier for people to do what was already being done by some pools/miners. Even if miners decide to start increasing minfee now during high BTC subsidy, all they do is force users to pay more fee now for relatively no gain to miners. When the subsidy falls low enough, miners would go back to what is in their individual best interest, which is to accept 1-satoshi-fee txes. March 26, 2012, 01:15:47 PM
Looks good to me. Thanks for the prompt response.
If this is complete, where would you like me to send a refund (if you want one) of your advance? Let me know if you would prefer to wait for testing and merging to mainline (which might require more time, depending on the reactions of other developers).Polvos, you also offered to contribute toward the bounty; if you feel the desire to tip me, you can use 1DGzpZzce1c7nsg1SN7exV6bsaju1Mcrc6 - it's fine with me if you choose not to, though.
I've submitted an upstream pull request. Miners who want this feature should express their support on this thread, and developers with comments can do so on the pull request itself.
No keep the advance. We likely need some testing and the code may require some tweaking. 20 BTC IMHO is well spent.
Now is there a guide anywhere for compiling modified version of bitcoind under windows?
March 26, 2012, 01:07:26 PM
I think everyone would like to see that, but something slightly more complicated and thorough needs to be thought up.
Of course but right now you choices are accept all tx or pocess no tx. Here at least you now have some crude control. This was intended to be a starting point to a) provide p2pool users some control and b) spark a conversation on mining fees.
Quote
No, actually it wouldnt. This patch does not change the minimum default fee in AcceptToMemoryPool which is required for a tx to a. get relayed through the network and b. be accepted by your node.
For most tx the default fee is 0.00. It is based on coinage (1 day, 1 BTC input = free). One could reject only zero fee txs (accept tx which don't violate spam rules and have at least 1 satoshi in fees).
One could modify the spam rules but I didn't want that because I think it is reckless. The spam rules are designed not to cost users money but to protect the network. If enough miners foolishly removed the spam rules one could cripple the network, users, wallets with massive (TBs) worth of spam for a negigible cost. I intentionally asked for the spam rules to be enforced for that reason.
Quote
Though this only partially applies today (as the 50 BTC per block is usually much higher than any fees), in the future as the 50 BTC/block subsidy decreases, any incentive miners had to do this "for the good of the network" goes away and it becomes get a few coins, or get nothing. Thus, the fee system could use some help to avoid this very dilemma.
True miners will reduce their direct compensation by excluding paying low fee tx but the amount they lose is essentially negligible. Chart tx vs fees in the blockchain for the last 100,00 or so tx. You will notice that even excluding tx w/ fee < 0.01 results in only a negligible drop in gross revenue (as in pennies a block). With a lower min fee you "lose" even less.
At this point it is more the principal of the issue and to spark a debate. The "cost" to a miner is essentially nothing (even one with dozens of GH/s). If not enough miners start enforcing higher fees then fees won't rise but the amount lost remains "almost nothing". If enough miners start enforcing higher fees then all miners benefit. Yeah there is some aspect of tragedy of the commons but w/ block subsidies still high (yes 25 BTC is high) the "cost" of helping is nearly nothing.
March 26, 2012, 12:35:10 PM
Thats it. Although 0.01 is somewhat arbitrarily chosen by me. We need to start somewhere. I feel the service provided is worth AT LEAST 1 bitcent and it is a nice round value. The larger goal is to allow ALL miners (not just me) to see fees at a level they feel aproporiate.
I think everyone would like to see that, but something slightly more complicated and thorough needs to be thought up.If anyone has an issue with 0.01 BTC as a fee amount it is better discussed in another thread on appropriate fee pricing. The code would allow enforcing fees on as low as flat 1 satoshi per tx (of unlimited size - although soon you would hit the spam limit).
No, actually it wouldnt. This patch does not change the minimum default fee in AcceptToMemoryPool which is required for a tx to a. get relayed through the network and b. be accepted by your node.I don't want to clutter this thread up too much but from this humble begining it would be my hope to see fee handling become more robust over time. Bitcoin will eventually require fees to support at least part of the network cost. Miners will need robust tools to price their service appropriately:
Agreed, the fee system in Bitcoin as it stands now is not very well done. In fact, its quite poor. However, a simple change like this really doesnt help much. Though individual miners who mine in a pool and thus don't make much on txfees couldnt care less whether a particular tx with a low fee is accepted, large-scale miners who want as many coins as possible have absolutely no incentive to increase mintxfee. Though this only partially applies today (as the 50 BTC per block is usually much higher than any fees), in the future as the 50 BTC/block subsidy decreases, any incentive miners had to do this "for the good of the network" goes away and it becomes get a few coins, or get nothing. Thus, the fee system could use some help to avoid this very dilemma. March 26, 2012, 09:40:35 AM
Looks good to me. Thanks for the prompt response.
If this is complete, where would you like me to send a refund (if you want one) of your advance? Let me know if you would prefer to wait for testing and merging to mainline (which might require more time, depending on the reactions of other developers).Polvos, you also offered to contribute toward the bounty; if you feel the desire to tip me, you can use 1DGzpZzce1c7nsg1SN7exV6bsaju1Mcrc6 - it's fine with me if you choose not to, though.
I've submitted an upstream pull request. Miners who want this feature should express their support on this thread, and developers with comments can do so on the pull request itself.
March 26, 2012, 09:11:44 AM
bitcoind has always priced transactions per 1000 bytes (SI kB). I can certainly change it, but I don't think upstream will accept it that way.
No reason to change it then.
If the "spam fee" is higher than the user-defined fee, the spam fee is left alone. Otherwise, the user fee overrides it.
Gotcha. I see now that prior to this segment the min "spam fee" is already computed based on coinage of the inputs.
Looks good to me. Thanks for the prompt response.
March 26, 2012, 09:04:19 AM
on line 64 (main.cpp)
I would change this to 1024. It will be much easier to understand if miners announce pricing either as flat value or per KB (i.e. "0.01 BTC per KB").
bitcoind has always priced transactions per 1000 bytes (SI kB). I can certainly change it, but I don't think upstream will accept it that way.Code:
int64 nMinFeePer = 1000;
I would change this to 1024. It will be much easier to understand if miners announce pricing either as flat value or per KB (i.e. "0.01 BTC per KB").
on line 5222 (init.cpp)
Since this is for warning on excessively high fees I would increase the threshold. The current threshold ~0.1 US cents even if BTC value increased significantly it would still be sub 1 US cent. I would increase the warning point to 1 bitcent. (> 0.01). While 1 bitcent may be "high" it is likely an intentional value. Someone misunderstanding the concept or units (thinking they are satoshis, fractional BTC or %) would likely put a much higher value and still be warned.
The warning limit here is 0.00025 BTC per byte, or 0.25 BTC per 1000 bytes. Surely that is sufficiently high?Code:
if (nMinFeeBase / nMinFeePer > 0.00025 * COIN
Since this is for warning on excessively high fees I would increase the threshold. The current threshold ~0.1 US cents even if BTC value increased significantly it would still be sub 1 US cent. I would increase the warning point to 1 bitcent. (> 0.01). While 1 bitcent may be "high" it is likely an intentional value. Someone misunderstanding the concept or units (thinking they are satoshis, fractional BTC or %) would likely put a much higher value and still be warned.
one line 592-602 of main.h
Not sure what is happening here (this bounty gives me more excuse to look into bitcoind sourcecode). My first thought is we are comparing the bitcoind "spam" min fee to the user defined fee? The spam fee depends on coinage though and the processing fee shouldn't. Likely I am misunderstanding so feel free to school me.
If the "spam fee" is higher than the user-defined fee, the spam fee is left alone. Otherwise, the user fee overrides it. Not sure what is happening here (this bounty gives me more excuse to look into bitcoind sourcecode). My first thought is we are comparing the bitcoind "spam" min fee to the user defined fee? The spam fee depends on coinage though and the processing fee shouldn't. Likely I am misunderstanding so feel free to school me.
March 26, 2012, 07:46:04 AM
Out of curiosity, can I ask why you want this?
I think he wants some FREEDOM choosing what transactions to add in a block he's mining. Those above 0,01 BTC fee specifically.Thats it. Although 0.01 is somewhat arbitrarily chosen by me. We need to start somewhere. I feel the service provided is worth AT LEAST 1 bitcent and it is a nice round value. The larger goal is to allow ALL miners (not just me) to see fees at a level they feel aproporiate.
If anyone has an issue with 0.01 BTC as a fee amount it is better discussed in another thread on appropriate fee pricing. The code would allow enforcing fees on as low as flat 1 satoshi per tx (of unlimited size - although soon you would hit the spam limit).
I don't want to clutter this thread up too much but from this humble begining it would be my hope to see fee handling become more robust over time. Bitcoin will eventually require fees to support at least part of the network cost. Miners will need robust tools to price their service appropriately:
Some ideas for enhancement (future versions outside the scope of this bounty):
* Allow "charity" windows. Miner could set a certain # or % of tx to allow below the fee threshold.
* Provide protocol to allow miners to announce their hashing power (verified by PofW) and price.
* Update client side processing to take miner announcements and provide users simple and easy pricing
" for this transaction current mining power indicates a fee of 0.01 has 95% confidence of being in the next block, a fee of 0.0005 has a 95% confidence of being in the next 20 blocks, no fee has only a 95% confidence of being included in the next 288 blocks"
* Allow re-fees. Receiver adding fees to a tx chain to speed up confirmation (sender issues w/ no fee and receiver adds a fee on dependent tx to speed up confirmation).
March 26, 2012, 07:42:23 AM
Here's your first draft: https://github.com/luke-jr/bitcoin/compare/customfee
Time billed: 30 mins
Awaiting input/comments...
Time billed: 30 mins
Awaiting input/comments...
Looks good so far. I have to compliment you. We don't always agree on everything but you write some solid code. Very clean and well documented.
Only have three minor comments ...
on line 64 (main.cpp)
Code:
int64 nMinFeePer = 1000;
I would change this to 1024. It will be much easier to understand if miners announce pricing either as flat value or per KB (i.e. "0.01 BTC per KB").
on line 5222 (init.cpp)
Code:
if (nMinFeeBase / nMinFeePer > 0.00025 * COIN
Since this is for warning on excessively high fees I would increase the threshold. The current threshold ~0.1 US cents even if BTC value increased significantly it would still be sub 1 US cent. I would increase the warning point to 1 bitcent. (> 0.01). While 1 bitcent may be "high" it is likely an intentional value. Someone misunderstanding the concept or units (thinking they are satoshis, fractional BTC or %) would likely put a much higher value and still be warned.
one line 592-602 of main.h
Not sure what is happening here (this bounty gives me more excuse to look into bitcoind sourcecode). My first thought is we are comparing the bitcoind "spam" min fee to the user defined fee? The spam fee depends on coinage though and the processing fee shouldn't. Likely I am misunderstanding so feel free to school me.
I like it so far.
To anyone reading. If you have any comments please provide them. Although I am paying the bounty I intend for this to be open source (MIT licensed) and hopefully someday be integrated into the mainline. The quicker we start the "open" discuss the more relevent this module will become to mining community.
March 26, 2012, 03:09:22 AM
Out of curiosity, can I ask why you want this?
I think he wants some FREEDOM choosing what transactions to add in a block he's mining. Those above 0,01 BTC fee specifically. March 26, 2012, 12:49:22 AM
Out of curiosity, can I ask why you want this?
March 25, 2012, 11:00:50 PM
Here's your first draft: https://github.com/luke-jr/bitcoin/compare/customfee
Time billed: 30 mins
Awaiting input/comments...
Time billed: 30 mins
Awaiting input/comments...
March 25, 2012, 10:35:49 PM
I intend to make it such that you can set it per-N-bytes, though.
Good point. In hindsight it should be coupled to the critical resource which is blockchain space.
March 25, 2012, 10:30:29 PM
A couple reasons why % based fee systems are not compatible with Bitcoin:
1) The bitcoin network has no knowledge of the payment amount only the total inputs and total outputs. I paid 20 BTC with an input worth 180 BTC. If the miner charged 1% I would need to pay 1.8 BTC in fees. If I from inputs worth 20 BTC I would only need to pay 0.2 BTC. Given users have no direct control over which inputs are used it would only lead to confusion.
2) As a miner my costs is not dependent on the tx value. Processing a 1,000,000 BTC tx takes no more work than processing a 1 BTC one. Charging a % simply takes more value from higher valued txs for no valid reason other than you can. The analogy I would use is that Bitcoin cost structure is more like a wire transfer or check than a credit card.
3) While BTC changes the daily fluctuations aren't particularly meaningful. Over the last 90 days 0.01 BTC has had a value in USD of 4.2 to 8.1 cents. I doubt many people would say "oh for 4.2 cents I would send that but not for 8.1 cents".
4) The critical resource is space in the block chain which doesn't depend on tx value. A 1,000,000 BTC tx involving a few inputs and a single output may only require 1 KB of space. On the other hand a 1 BTC tx made up of a hundreds of junk (0.00001, 0.00038, etc.) inputs could take 20KB+. Charging more for the low cost tx and less for the high cost tx is illogical.
A miner with a fixed min fee will need to periodically adjust that fee. Obviously 0.01 BTC @ ~$ USD is 5 cents if BTC:USD rises by a magnitude (say to 50 USD) then revising the fee schedule is likely required. Still if one kept a fee of 0.01 BTC it isn't materially more or less expensive as long as BTC trades in a range of 2 USD to 9 USD which means miner wouldn't need to adjust very often.
1) The bitcoin network has no knowledge of the payment amount only the total inputs and total outputs. I paid 20 BTC with an input worth 180 BTC. If the miner charged 1% I would need to pay 1.8 BTC in fees. If I from inputs worth 20 BTC I would only need to pay 0.2 BTC. Given users have no direct control over which inputs are used it would only lead to confusion.
2) As a miner my costs is not dependent on the tx value. Processing a 1,000,000 BTC tx takes no more work than processing a 1 BTC one. Charging a % simply takes more value from higher valued txs for no valid reason other than you can. The analogy I would use is that Bitcoin cost structure is more like a wire transfer or check than a credit card.
3) While BTC changes the daily fluctuations aren't particularly meaningful. Over the last 90 days 0.01 BTC has had a value in USD of 4.2 to 8.1 cents. I doubt many people would say "oh for 4.2 cents I would send that but not for 8.1 cents".
4) The critical resource is space in the block chain which doesn't depend on tx value. A 1,000,000 BTC tx involving a few inputs and a single output may only require 1 KB of space. On the other hand a 1 BTC tx made up of a hundreds of junk (0.00001, 0.00038, etc.) inputs could take 20KB+. Charging more for the low cost tx and less for the high cost tx is illogical.
A miner with a fixed min fee will need to periodically adjust that fee. Obviously 0.01 BTC @ ~$ USD is 5 cents if BTC:USD rises by a magnitude (say to 50 USD) then revising the fee schedule is likely required. Still if one kept a fee of 0.01 BTC it isn't materially more or less expensive as long as BTC trades in a range of 2 USD to 9 USD which means miner wouldn't need to adjust very often.
March 25, 2012, 10:27:56 PM
Just sort of a relevant comment while you're on about this, but what about making fees proportional to the amount being sent? ie charging 0.1% as a fee rather than a nominal BTC amount. You could just use a higher % for extra small tx.
The main reason I would suggest doing it that way is since the trade value of BTC fluctuates so much it may be impractical on the user end to deal with fees set in nominal terms, whereas %s scale automatically and are simple to understand.
It's not possible to determine how much is being sent, and most of the transfers you would want to "tax" more are inversely proportional to that amount anyway. I intend to make it such that you can set it per-N-bytes, though. The main reason I would suggest doing it that way is since the trade value of BTC fluctuates so much it may be impractical on the user end to deal with fees set in nominal terms, whereas %s scale automatically and are simple to understand.
March 25, 2012, 10:21:03 PM
Just sort of a relevant comment while you're on about this, but what about making fees proportional to the amount being sent? ie charging 0.1% as a fee rather than a nominal BTC amount. You could just use a higher % for extra small tx.
The main reason I would suggest doing it that way is since the trade value of BTC fluctuates so much it may be impractical on the user end to deal with fees set in nominal terms, whereas %s scale automatically and are simple to understand.
The main reason I would suggest doing it that way is since the trade value of BTC fluctuates so much it may be impractical on the user end to deal with fees set in nominal terms, whereas %s scale automatically and are simple to understand.
March 25, 2012, 09:28:03 PM
One thing I thought of is it would be useful to have a getminfee to complement setminfee.
Probably sufficient to just add it to the getmininginfo results?Sure that works too.
March 25, 2012, 09:25:34 PM
One thing I thought of is it would be useful to have a getminfee to complement setminfee.
Probably sufficient to just add it to the getmininginfo results? March 25, 2012, 08:09:50 PM
So if vanilla bitcoind would charge 0.0005 BTC for a fee, you want to charge 0.0005 BTC + "min fee" for the same? Or just the greater of the two?
Although it is an edge case I think greater of the two would work the best.
One thing I thought of is it would be useful to have a getminfee to complement setminfee.
getminfee - returns minfee value
setminefee -sets minfee value (default 0)
getmemorypool - modified to exclude tx which have a fee < minfee.
20 BTC sent
tx id: 76c9a9cda85e34560c1c0f2ce827f71e0e92bcb2a42ec1e4bdd6dd8174e738e4
Let me know if you have any questions.
March 25, 2012, 07:14:05 PM
20 BTC advanced and balance due upon completion sound ok?
Sure. 1FXGUecLqVPdqGUR5qEpLt9QUjGg5P1k2KJust to clarify this min fee would be in addition to any spam rules. So bitcoind should do its normal spam checks and then exclude any tx (i.e setting min fee to 0.001 should still result in spam tx without min spam fee from being excluded). I could see some people setting the min fee to 1E-8 to exclude only free tx and I don't want the min fee rule to accidentally compromise any spam prevention.
So if vanilla bitcoind would charge 0.0005 BTC for a fee, you want to charge 0.0005 BTC + "min fee" for the same? Or just the greater of the two?One thing I did think of is making bitcoind smarter to detect dependencies and including tx chains but that likely will need to wait for a future bounty. What I mean is I send 20 BTC from A to B (you) but I include no fee. You get tired of waiting so you make a tx based on the unconfirmed A->B as an input sending it to C with a fee. If the bitcoind was "smart" enough someday it could detect that B-> C depends on A->B and include both even if A->B is under the min fee (as long as B->C is over min fee).
Yeah, I've wanted this kind of functionality for a while, but I haven't been able to justify spending the time to figure out the algorithms it would need. March 25, 2012, 06:58:11 PM
Well Luke I waited to see if anyone else was interested and I guess not so the job is yours.
MIT license is fine. You can retain the copyright (unless you don't want you name associated with the code in which case it can be copyrighted under my name).
8 BTC/hr * likely <4 hrs = 32 BTC.
20 BTC advanced and balance due upon completion sound ok?
Just to clarify this min fee would be in addition to any spam rules. So bitcoind should do its normal spam checks and then exclude any tx (i.e setting min fee to 0.001 should still result in spam tx without min spam fee from being excluded). I could see some people setting the min fee to 1E-8 to exclude only free tx and I don't want the min fee rule to accidentally compromise any spam prevention.
One thing I did think of is making bitcoind smarter to detect dependencies and including tx chains but that likely will need to wait for a future bounty. What I mean is I send 20 BTC from A to B (you) but I include no fee. You get tired of waiting so you make a tx based on the unconfirmed A->B as an input sending it to C with a fee. If the bitcoind was "smart" enough someday it could detect that B-> C depends on A->B and include both even if A->B is under the min fee (as long as B->C is over min fee).
Let me know if the terms are ok and provide me an address to deposit the 20 BTC advance.
MIT license is fine. You can retain the copyright (unless you don't want you name associated with the code in which case it can be copyrighted under my name).
8 BTC/hr * likely <4 hrs = 32 BTC.
20 BTC advanced and balance due upon completion sound ok?
Just to clarify this min fee would be in addition to any spam rules. So bitcoind should do its normal spam checks and then exclude any tx (i.e setting min fee to 0.001 should still result in spam tx without min spam fee from being excluded). I could see some people setting the min fee to 1E-8 to exclude only free tx and I don't want the min fee rule to accidentally compromise any spam prevention.
One thing I did think of is making bitcoind smarter to detect dependencies and including tx chains but that likely will need to wait for a future bounty. What I mean is I send 20 BTC from A to B (you) but I include no fee. You get tired of waiting so you make a tx based on the unconfirmed A->B as an input sending it to C with a fee. If the bitcoind was "smart" enough someday it could detect that B-> C depends on A->B and include both even if A->B is under the min fee (as long as B->C is over min fee).
Let me know if the terms are ok and provide me an address to deposit the 20 BTC advance.
March 25, 2012, 03:11:32 AM
I'm absolutely agree with your statements D&T so I will contribute here. I lack the programming skills and don't understand deeply the BTC protocol but I can donate some coins to the bounty.
March 24, 2012, 11:28:15 PM
Actually, bitcoind already excludes transactions that don't meet the hard-coded fee rules. I'd be glad to write the simple JSON-RPC method to configure it for only 8 BTC/hr*. I expect it would take at most 4 hours, probably less.
* 8 BTC/hr rate assumes I publish it under the MIT license. I don't care who holds the copyright itself.
* 8 BTC/hr rate assumes I publish it under the MIT license. I don't care who holds the copyright itself.
March 24, 2012, 11:24:06 PM
Proposal:
A patch to bitcoind that modifies tx list returned by getmemorypool by excluding tx below a user defined fee.
Background:
The getmemorypool RPC call returns the components necessary to build a block header.
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
The getmemorypool RPC call is used by p2pool to generate blockheaders for getwork requests by miners. The default action of "getmemorypool" is to return all valid tx not yet known by the node to be in a block. I am seeking development of a patch which will exclude transactions with a transaction fee below the min fee set by the operator. The list of tx returned should simply be the tx with an appropriate fee.
Implementation:
I imagine the easiest way to accomplish this is to have a new RPC call "setminfee". By default "setminfee" is set to 0 BTC. The modified "getmemorypool" would check the min-fee value (default 0) and exclude any tx with fee < min fee. I am open to alternative implementation however a reason should be provided.
Bounty:
Make me an offer. Honestly I have no idea the amount of work this will involve. I don't want to vastly overpay or insult anyone with a low ball offer.
A patch to bitcoind that modifies tx list returned by getmemorypool by excluding tx below a user defined fee.
Background:
The getmemorypool RPC call returns the components necessary to build a block header.
Quote
version" : block version
"previousblockhash" : hash of current highest block
"transactions" : contents of non-coinbase transactions that should be included in the next block
"coinbasevalue" : maximum allowable input to coinbase transaction, including the generation award and transaction fees
"time" : timestamp appropriate for next block
"bits" : compressed target of next block
"previousblockhash" : hash of current highest block
"transactions" : contents of non-coinbase transactions that should be included in the next block
"coinbasevalue" : maximum allowable input to coinbase transaction, including the generation award and transaction fees
"time" : timestamp appropriate for next block
"bits" : compressed target of next block
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
The getmemorypool RPC call is used by p2pool to generate blockheaders for getwork requests by miners. The default action of "getmemorypool" is to return all valid tx not yet known by the node to be in a block. I am seeking development of a patch which will exclude transactions with a transaction fee below the min fee set by the operator. The list of tx returned should simply be the tx with an appropriate fee.
Implementation:
I imagine the easiest way to accomplish this is to have a new RPC call "setminfee". By default "setminfee" is set to 0 BTC. The modified "getmemorypool" would check the min-fee value (default 0) and exclude any tx with fee < min fee. I am open to alternative implementation however a reason should be provided.
Bounty:
Make me an offer. Honestly I have no idea the amount of work this will involve. I don't want to vastly overpay or insult anyone with a low ball offer.
Jump to: