Pages:
Author

Topic: [BOUNTY] A patch for bitcoind to modify tx list in "getmemorypool" (Read 5443 times)

legendary
Activity: 2576
Merit: 1186
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.
legendary
Activity: 2940
Merit: 1333
Is this bounty still available?  It wouldn't be hard to implement if there's still interest in it.
sr. member
Activity: 389
Merit: 250
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 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.
It may be possible to analyze based on how much fee they're giving away. If a miner accepts a 0.001 BTC tainted fee then it's taint might negligibly increase. If a miner accepts a 3 BTC tx fee with no outputs, then the coin is probably being melted.

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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
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 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.
legendary
Activity: 2940
Merit: 1333
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 coin melting ever becomes popular then it will stop being effective, as the taint calculations start taking it into account.
newbie
Activity: 13
Merit: 0
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?
donator
Activity: 532
Merit: 501
We have cookies
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?
"Simple" 51% attack doesn't allows them to redeem your TXes, but with "coin melting" it becomes possible. And it looks a bit less evil (just kidding).
hero member
Activity: 597
Merit: 500
But if I'm not wrong the % of orphan blocks is very low
legendary
Activity: 2940
Merit: 1333
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?

None.  But point 1 doesn't need cooperation at all.
hero member
Activity: 597
Merit: 500
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?
legendary
Activity: 2940
Merit: 1333
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.

Good points.  Guess there's no point implementing it then...
donator
Activity: 532
Merit: 501
We have cookies
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.
legendary
Activity: 2940
Merit: 1333
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?
donator
Activity: 1218
Merit: 1079
Gerald Davis
Examples usage of setminfee

Setting minfee of 0.005 BTC per KB
Code:
E:\bitcoin\bitcoin-0.6.0rc5+customfee-win32>bitcoind setminfee 0.0005
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
}

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

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

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.
hero member
Activity: 597
Merit: 500
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.
hero member
Activity: 597
Merit: 500
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.

full member
Activity: 168
Merit: 100
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
donator
Activity: 1218
Merit: 1079
Gerald Davis
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.
legendary
Activity: 2576
Merit: 1186
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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
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.
Pages:
Jump to: