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

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.

• 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

Possible, but might not be simple to do in bitcoind.

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).

Windows binaries are done: installer | zip (sigs)

That would be great.  Thanks.

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.

Let's see how works your code and I will tip you some coins. For the moment it seems quite promising. Good work.

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.


% 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.


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.



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).

Lol, well then my resources stay in fiat or PMs.


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.

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.

Hey, don't forget BitPenny and Eligius miners!

If you want, I could trivially build a Windows binary. I won't bill for the time spent by the compiler, of course :p

Your argument seems to be based entirely on trying to profit from usury. Usury is evil, so IMO your argument can be ignored.

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.

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

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.

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. 

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?

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.


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. 



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.

I think everyone would like to see that, but  something slightly more complicated and thorough needs to be thought up.

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.

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.

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 reason to change it then.


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.