Citation on the 30%? I recall someone here claiming 30% when it was really more like 5% because they failed at math.

It takes about .1816 KB per input, if all inputs are 0.01 and you're paying 0.01 per KB (.20 node behavior) you'll have no more than 18.2% fees for large transactions made of many 0.01 inputs. With 0.0005 BTC/KB it's a 0.9% fee for a big transaction made entirely of 0.01 inputs.  Of course, this goes down very fast when the inputs are larger.

Since acounts are just a daemon local bookeeping function and don't control the inputs, I think it wouldn't be reasonable to change someone a txn fee of more than the base fee just because their TXN got an unlucky selection of coins from the shared inputs.  Instead you should just have a constant fee that covers the average and then some.  It's just a simple cost of doing business.

Of course, an RPC could be provided to query the fees for a TXN in advance (if you can tolerate an approximation, since additional inputs will change it), or a the send could get a maximum fee argument and reject with the required fee if you don't authorize enough.

The txn size related fees (which, FWIW, these patches do _nothing_ to) are simply not going away.  The tx_data has a direct cost on the network— every megabyte stored in the blockchain results in something like 40gigabytes transmitted and stored in the bitcoin network. Without fees for large transactions people will have a good reason do do psycho "backup my data into the blockchain" games and other such stuff.

IIRC, the async work is what is incompatible with slush. It has nothing to do with the new kernel at all.  Basically when the miner would otherwise be idle it increments the ntime anyways, hoping that the pool will still accept those shares.  On slush, it won't so that work is wasted, but it would have been wasted regardless.  The solution to that is to use a better pool, IMO.

No he isn't.  It's not a problem that actually exists. You simply charge your clients for the txn fees generated when they are generated. Whats the issue? A DDOS can certainly bankrupt you— it can drive up absolutely astronomic connectivity fees, force you to use commercial mitigation services, and take you offline so that you can't earn the income you need to pay the bills.  Worse, they are hard to stop, compared to simply passing on txn fees to your customers in one form or another where they exist.

I'm not being confrontational, I just didn't follow that you thought this software would be desirable for exchanges simply because no competent exchange is going to run a fork of bitcoin that causes them to get stuck and unspendable outputs in their wallets and makes users wait days or weeks for payments to arrive. Presumably they care enough about the success of bitcoin to not allow this outcome.

They could also flood you with HTTP requests sent by a million node botnet.  Whats your point?  There is nothing special about bitcoin here, you're also offtopic for this thread as far as I can tell.

FWIW, bitcoin itself resists big coin bitdusting by making the priority depend on tx_value * input_age / tx_size.  So quickly recirculating a large coin doesn't magically get you past it.

Err.  Bitcoins are fungible, it's pretty much never the case that the coins being withdrawn are at all related to the ones deposited.   Once you have a reasonably large balance you'll be cycling out old coins most of the time unless there is a bank run.

So that mostly just leaves the burden of lots of small inputs, but you'll cycle out the small inputs with other transactions in due time without incurring large fees... but if stuffing your wallet with pennies does become problematic you can simply employ a rule of not crediting dust inputs, or imposing a small fee on deposits.   It doesn't have to be "convoluted". if(amount<0.0001)amount=0;

Some sites, like tradehill for example make you specify the exact input size— and impose significant delays on deposits if you get it wrong. You can reject bitdust transactions at this point too, so no one should be surprised by their dust transaction being lost to them.

There has been some talk about tx fee estimation, but because the coin selection algorithm doesn't guarantee the lowest fees and is perturbed by new inputs it's currently hard to asynchronously estimate fees.

No— Bitcoincharts won't show any transaction which looks too much like DDOS. For example, it won't show a fee-less transaction with a 1e-8 output.  This is because the node feeding that page imposes the same anti-DOS rules as other nodes and it drops those transactions on the floor the moment they come in. Also because a sufficiently "bad" transactions will seldom make it to that host in the first place.

I've verified this myself.  In fact it wasn't even showing transactions that were perfectly fine under .23 rules, like transactions with <0.01 btc outputs and a 0.0005 fee, because it hadn't been upgraded yet.

Moreover, the reason it contains coins from unconfirmed transactions but not the older unconfirmed transaction itself is probably because the unconfirmed transaction is stuck.  It's perfectly valid to spend unconfirmed coin, you'll just need to be mined at the same time or later.   But you can see how producing transactions that won't ever confirm isn't just bad for you, it's bad for other people because these transactions are like a cancer that spreads when they show up as the only coins in someone's wallet and they get respent.

The likely reason that you haven't had any issues is simply because the cases where fees are forced are fairly rare, especially after you've been running bitcoin with a non-zero balance for a few weeks.  You've likely just not had many cases where a fee would have been demanded by your client in the first place.

Or just clamp it at some reasonable value and don't even bother throwing an error.


I'd hope it would be, especially now that you're async— run multiple work collecting threads, have the miners threads pull from ones with current work in round-robin or random (to reduce lock contention) order.

Having one miner process per system is nice from a maintenance perspective (it sucks to have to track the health of 6 processes), but it's an increased liability e.g. if one TCP session loses a packet and stalls out for 10 seconds before recovering then the I've got 1.8GH/s going stale. And god forbid a pool go down or the internet have some routing retardation. Having two or three separate access threads being pulled from in realtime would greatly reduce that risk while still reducing load on the pools vs one card one socket that most miner programs result in.

I can't comment on later versions of phoenix, but I log all my shares with phatk+phoenix svn r64 (which is what I'm mostly running) and the hash meter expected shares agrees quite closely with the actual ones. ::shrugs::

Does it?  The fact that the nonce changes doesn't create any cheating risk. So, e.g. if you just treat the few least significant bits of the timestamp as more nonce you're no worse off.


Luke has patches to make bitcoind handle ntime rolling in his public repository. I strongly suggest running them, because they also fix duplicate work that bitcoind will already issue without rolling. (because it's able to reset the extranonce twice)

I told you that what you have done will cause users to lose coins. The solution is to simply run stock bitcoind, which changed from the .20 behavior because people were losing coins. I think this is pretty darn constructive.


Well, you haven't included links so I'm not sure exactly what you were saying—  but the behavior has changed in .23.

"properly coded pools using stock bitcoind as backend"

That is an oxymoron.

If you're using stock bitcoind as a backend for a non-trivally sized pool you're going to be losing work due to blocking getworks and time/extra_nonce update races.

The change to support rolling ntime is a one line patch to bitcoind.

Long polling, of course. The pool knows how old a block header its willing to accept, which is what this is useful for.

N seconds or ntime incremented by N?

So, you're also going to be offering your free services to help unstick transactions from people's wallets when they make ones which will _never_ become confirmed?

Because doing that is a pain, and that pain is why the fees are enforced for borderline transactions.  Otherwise people are going to be rightfully mad at you when your software causes them to lose small amounts of bitcoin forever.

Moreover, your claim that most miners will honor these transactions is patently false. It's not hard to find transactions that very few will honor and that almost no node will forward.  For example, send 0.0001 BTC with no fee or 10x reduced fe.


This is silly. The way the dust spam logic treats insufficient fees as non-existent. Simply reducing them by 10x isn't really any better than not paying them at all,  unless you're fortunate enough to manage to connect to eligius (which has a mandatory fee on every transaction but only a very small one). In that case you might as well just apply the eligius fee rules directly.

You've also failed to completely remove the need for fees, but I'm not going to show you what you missed, lest you footgun yourself and others even worse.


If you don't understand it then it is exceptionally irresponsible of you to modify it and encourage other people to run your modified version. Screw yourself, if you like, but not other people.  I hope other folks here are smart enough to not run code from someone who admits that they don't know what they are doing.

The relay and mining rules of other nodes is the only thing that protect them and the network from penny flooding attack. You can't change those except by convincing them to run software that you've made vulnerable.

The fee rules are there so that a consequence of the relay rules of other nodes you don't end up losing bitcoin because you have a stuck transaction that never confirms.  This isn't hypothetical, it happens to people, and it was in response to this that the minimums were setup for transactions that will very likely have forwarding problems.

The crappiest thing is that your patch will end up screwing people with the least ability to deal with it. Those of us with mature wallets with well aged inputs and enough bitcoin to not be doing bitdust transactions pretty much never run into needing fees, patch or not. Instead the people who will get screwed are newbies who won't even know where to get started in recovering coin lost due to forever non-confirmation.

This seems to be pretty narrow: http://eprint.iacr.org/2009/363.pdf (linked to by some troll in #bitcoin-dev 0_o)

But I think that it's enough evidence that giving a third party the ability to control the input to ECDSA is bad. Because the hash function is in the way, an attacker probably can't find two messages that set the signature input to the right values for any attack likely to exist, but I'd much rather that he have no ability to perform such a search at all.

Instead I propose:
ECDSA_SIGN(SHA256(fixed_string+128_bit_nonce+message))

Where the nonce is selected by the signer at sign time, and is included with the signed message (just pack it into the signature).  The space it takes up could be recovered by not including the public key (which can be recovered from the signing address+signature, making it actually less data than the existing patch. Also... Hex?  it would be much smaller base64ed). This also covers the Zebedee attack, actually somewhat better because Zebedee has to attack each signature one at a time rather than each signer, I think this also solves the plaintext TX matching hash attack of Bytecoin above in a simpler and less overhead generating way.

The nonce may also prevent replay attacks in some places where the signatures might be used. E.g.  sign("Release my stored funds")  and someone intercepts it and sends it again later. Such systems ought to force the message to contain an anti-replay cookie, but we get one for free as a side effect.

Congrats, you're finally as fast as phoenix / phatk for me— actually about 0.4% faster it looks like.  (Only tested it on the 5850s with SDK 2.4 so far)

I seemed to be getting high stales with -f0, -f1 was fine but it could have just been bad luck. There didn't appear to be much if any hashrate difference, so I just left it at 1%.

Still need the ability to loadshare (ideally) or fail over between multiple pools.   But it's looking pretty good.  Good work.

The poo doesn't get bigger due to magical pixie dust. It gets bigger due to hashpower being added, same way solomining gets biggerr.


By using the words "on average" you make your statement completely incorrect as many have pointed out here.

It's fine to say that there is increased risk of higher or lower payouts, and the low payouts matter more to you because they'll put you out of business (or the higher means less because you somehow don't need more coin(??))... and thus on average solo has lower utility for you, but that lower utility != less btc _on average_.

You know that the last four rounds of sha256 can be eliminated when mining, right?

Not news: http://forum.bitcoin.org/index.php?topic=11551

On this subject, I've seen people hating on bitcoin7 for using "float" on IRC a bunch— but it turns out that they are using decimal float, which is perfectly fine and reasonable for this. Only the use of binary float leads to perplexing results with bitcoin values.

Hm? it reduces variance vs solo by an enormous factor. This might not be all that helpful for joe-random cpu-miner, but for someone with enough power that they might even think about running solo its _very_ attractive because it reduces the variance enough to make 'solo' perfectly reasonable without the negatives of the pool system— poor reliability, fees, cheating (by operators and other users), and power consolidation that endangers bitcoin.

The payout system implied by this makes it automatically not so great for aggregating lots of tiny users. Were you to increase the number of shares so that most slow users would get one every block then you'd end up with massively bloated blocks, and also a lot of people with micropayments that cost them more money to use as inputs.

Moreover, centralized pools themselves could be participants in this scheme, so smaller pool operators would have less variance disadvantage vs big ones, so even the pooling that remains could be more distributed and competitive.