That's a great step, it would be even better to link the advisory. One I found by that number was for JavaRE and the other for Bind DNS :-/.

Dia

If you look at recent blocks found by Eligius http://blockchain.info/blocks/Eligius every block only contains the one generation transaction.

a) provide p2pool users some control

Now is there a guide anywhere for compiling modified version of bitcoind under windows?

".01 BTC" is not a reasonable fee, period. Here's why.

Looks good to me.  Thanks for the prompt response.

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.

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.

One thing I thought of is it would be useful to have a getminfee to complement setminfee.

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

Danger of buffer overflow, (if there is a bug in the to hex code).  Virtually no real-life performance gain.

Tonal support, tonal is base 16 numbers with strange characters for the numbers higher than 9.
Problem: nobody cares about tonal other than Luke.

Is this affecting Bitcoin version 0.3.21?

I just spent coins from a generate and was charged a fee.  The generate was for .6793514 and since 120 confirmations were required before they could be spent, and since I was trying ot send exactly .6793514, I expected to be able to send the transaction for free.  Instead, a fee of .0005 was required and I had to spend .6788514 instead to afford the fee.  I know that ultimately fees will be necessary to support mining, but I believe right now fees are only required for transactions that fall outside of a certain scope.  My expectation did involve some assumption, but was based on this (from FAQ):Just out of curiosity, was the minimum payout's intent to be able to spend without a fee (in which case maybe it is currently too low, whether it was when implemented or not) or just to minimize fees (100 .00678851 inputs would have presumably required a larger fee)?