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

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)

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.

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.

There is no direct correlation between difficulty and price, but difficulty follows price.

Difficulty is set by hashing power.  The network attempts to maintain an average time between blocks of 10 minutes.  If hahsing power rises (people deploying new miners) then avg time will fall.  The network correct that by raising difficulty and thus the new hashing power isn't any faster (combined) at finding blocks then it was before.  

Say difficulty is 10 TH/s. As an example if 10% more hashing power comes online (~1.0TH/s, or 11 TH/s total), time between blocks at current difficulty falls to ~9 minutes.  At the next difficulty adjustment difficulty will rise 10% and the 11 TH/s network will find blocks in 10 minutes (no faster than the 10TH/s network did).

So what keeps difficulty from going to elventy bazillion?  Economics.  GPU cost a certain amount, and use a certain amount of power.  Thus price rising leads to rising difficulty (as new miners chase higher profits) and price falling leads to lower difficulty (as marginal miners quit).  Trying to predict difficult OR price is a fools errand but the relationship between price AND difficulty is relatively stable:


Over last 90 days 1 GH/s of hashing power has earned between $3.00 and $6.00 per day (minus electrical costs).

When price/difficulty gets too low (either due to rising difficulty or falling price) it becomes unprofitable and some miners quit raising price/difficulty.  When it gets too high it encourages new hardware spending and price/difficulty falls.

BadBear was indicating that over the long run FPGA change that.  They have high upfront cost but low operating cost.  Thus once bought they can remain online and profitable even when price/difficulty falls to levels that would idle a GPU.  Since they don't idle that is going to put downward pressure on price/difficulty.   As more and more FPGA are deployed one would expect the price/difficulty ratio to fall (network getting mrore efficient).

That doesn't work.

As a security feature in linux if password is not set you intentionally can't remote login.  NULL == "".  You can have a passwd of "" but root's password is set to NULL

root password must be changed before logging in via ssh.  The easiest way to is to set root from direct connection (monitor & keyboard) before deploying.  Alternatively if BAMT has any other usernames configured (i.e. "user") with a non-NULL password you could login to that account "sudo su root" and then use "passwd" to set root's password.  Finally log out and login as root.  I am not sure if BAMT has any other accounts configured though.

An alt-coin which uses a different PoW (or PoS) would be immune to that particular attack.

So would any alt-coin that wasn't a dump and pump piece of junk.  You know one that actually submitted a proposal, took in feedback, had a launch date announced well in advance, had a working testnet, got support of multiple pools and miners to have sufficient strength on day one.

Of course no alt-coin has shown any innovation, any progress.  They are wothless pump and dump scams. 

Where do you get this garbage about exorbitant transaction fees?  A bit penny is exorbitant?  In what universe?

If you think the value and utility of Bitcoin is so useless why are you even here?


Srawman aside I never claimed I had.   You seem to have a very deep seated hatred of miners.

Interesting.  So why does your unmodified title say 3x BFL Singles 2.5GH/s @ 130W?

That is what I was confused about.

BFL Singles are 85W to 90W.

Where are you getting 130W from?

I have 16GH expanding to 20GH and I see absolutely no reason to solo mine.  p2pool = solo mining w/ shared rewards.  If you don't want to use p2pool support a smaller pool.  Take Bitminter = ~150GH/s to 200 GH/s.  Even if you had 50 GH/s why not mine with 1/5th the variance.

When the only options were high fee hopper vulnerable pools solomining made more sense.  Today I just don't see a point. 

You don't need a wallet.  Just send them DIRECTLY to an exchange.

Open account at an exchange which trades NMC (MtGox doesn't).  In your exchange account find the address you use for namecoin deposits.  Put that address in the NMC payout address for Slush's (or any) pool.  NMC go directly from pool to your exchange account where you can sell them.

There are non-interest fees.

For example I closed a deal on some GPU but I didn't have the coinz.
Seller said he would take Paypal but I had to pay the fees.

Instead I asked for a 2 week loan @ 3% interest and used my hashing power.  Now as an interest rate I consider 3% for 2 weeks (216% APR) to be high but I would have paid the same for using Paypal.  If I had enough coins I never would have taken the loan.

The other options was to put a deposit down and wait for Dwolla to clear.  Due to limited rep at the time they wouldn't ship until funds cleared.  Now Dwolla had negligible cost but it would have taken a week.  At the time the cards were earning about 3% of their value (net) per week.  So waiting would still have cost me 3%

Paypal - give 3% to banksters
Dwolla - lose 3% revenue waiting a week
BTC loan - give 3% interest to lender, keep entire transaction BTC only, and help improve BTC economy.



I agree the high interest rates in generally do indicate some bad due diligence.  It can't all be for productive purposes and that means either the lender or the borrower is making a bad decision.

When loans burst I don't think it will have any effect on Bitcoin.

Why not just send them directly to an exchange account like BTC-E?

If the top 10 transactions are 1 satoshi then that forces miners to include all tx with at least a 1 satoshi fee.  It creates a race to the bottom.  Smart users will keep fees as low as possible and encourage others users to do so.  "Look as long as nobody pays too much the miners are forced to include are freeloader txs".

Your insulting language is counterproductive.  You are aware that passing any breaking change on block validity rules will require support of a majority of us "greedy miners".  Also money supply growth isn't 30% anymore and after the subsidy drop it will be closer to 10%.  By the next subsidy break it will be ~4%.  Users have enjoyed price deflation due to the fact that the demand for currency has grown faster than the money supply.

Good point.  In hindsight it should be coupled to the critical resource which is blockchain space.

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.

Sure that works too. 

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.

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.

If/when the rate of coin destruction exceeds the rate of coin creation then the money supply will shrink = monetary deflation.