Some testing that I did on the testnetwork, my findings.
[Original post content lost — the author vandalized the post, replacing the title with “af” and the body with “adgadg” on the live BitcoinTalk forum.]
Actually… prioritizing free transactions based on both amount and their “age” should make this attack toothless.
The basic idea is that if you’re spamming lots of small free transactions, you’ll be creating lots of brand-new “pennies” (you’ll take an old 50BTC generated transaction, then split off a penny and get a penny and 49.99 change. Then split that 49.99 to get another penny, and so on and so on).
Sorting pending free transactions so that larger-value transactions and free transactions with inputs deep in the block chain (“old money”) are given priority would let normal transactions go through.
The spammy transactions would still take up network bandwidth and disk space; if that becomes a problem, nodes could just ignore small, new transactions (not relay them) and let the nodes that are doing the spamming queue up and rebroadcast the transactions. They’d trickle into the network eventually, and in the meantime the spammer’s bit-pennies would be tied up.
Quote from: gavinandresen on November 07, 2010, 02:14:29 AM
Actually… prioritizing free transactions based on both amount and their “age” should make this attack toothless.
Sorting pending free transactions so that larger-value transactions and free transactions with inputs deep in the block chain (“old money”) are given priority would let normal transactions go through.
Prioritizing larger value transactions doesn’t really solve the problem because it’s perfectly possible to spam by sending large amounts of bitcoin from one of your addresses to another ad infinitum.
If you prioritize older transactions, people would be incentivised to split their bitcoin holdings in such a fashion as to ensure that they do not generate significant amounts of change when they buy things with bitcoins. If you hold your bitcoins in powers of 2 * 0.01 then you can pay for anything you can aford with no change and the least fragmentation. Of course after spending the money you have to rebalance your holdings as soon as possible. The best way to do this is not immediately obvious to me. Possibly under certain circumstances it might be advantageous to generate change as long as you could specify how you wanted it split up. Possibly powers of 3 might be best for multiple purchases. Anyway, the end effect would be that transactions would have more ins and outs. Probably the average number of ins and outs would be some very small multiple (or large fraction) of the log of the number of bitcoin pennies in the transaction. I estimate that this might increase the average transactions size by over 10 times.
ByteCoin
Quote from: ByteCoin on November 08, 2010, 02:31:22 AM
Prioritizing larger value transactions doesn’t really solve the problem because it’s perfectly possible to spam by sending large amounts of bitcoin from one of your addresses to another ad infinitum.
No, you can’t, because every time you send them they become “new”, and the priority is age multiplied by amount: Code:// Priority is sum(valuein * age) / txsize (valuein is the size of the bitcoin input, age is # of blocks deep, and txsize is the number of bytes the transaction takes up)
Ummm… the more you mess around with the coins in your wallet, the newer they are, and the lower their priority (relative to everybody else who might want to get their transactions into the next block). I haven’t thought deeply about it, but I bet simply leaving your coins as they are and making change as necessary will work out best. But please, create your own client and try to break things on the test network!
With davidonpda’s help, I did some testing myself today with Satoshi’s latest code changes (setting priority based on transaction age, bitcoin amounts in, and total transaction size in bytes — svn rev 176).
It behaved as expected, putting larger, older transactions ahead of the pennies being flooded into the network, so “normal” transactions will be confirmed promptly even if somebody decides to be a jerk and floods the network with transactions.
Thank you for limiting flood tests to the testnet.
Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack. The key was Gavin’s idea for prioritising transactions based on the age of their dependencies. Every coin is entitled to turn over so often. The longer waited, the more priority accumulates. Priority is sum(valuein * age) / txsize. Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.
In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that’s all you have left. This helps keep you from turning your coins over rapidly unless you’re forcing it by actually turning all your coins over rapidly.
Quote from: satoshi on November 13, 2010, 11:25:26 PM
In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that’s all you have left. This helps keep you from turning your coins over rapidly unless you’re forcing it by actually turning all your coins over rapidly.
Of course, if the network is not being flooded and you’re not overly concerned about the current transaction getting held up then it’s probably worth preferring to use your 0 conf transactions so that you can “save” the higher priority coins for when the network is being flooded.
Unless I misunderstand, it looks to me like the current logic is more likely to spend the accumulated priority of older transactions. It’s a minor point however.
Gaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!
ByteCoin
Quote from: ByteCoin on November 13, 2010, 11:55:11 PM
Of course, if the network is not being flooded and you’re not overly concerned about the current transaction getting held up then it’s probably worth preferring to use your 0 conf transactions so that you can “save” the higher priority coins for when the network is being flooded.
You should use at least some priority in case a flood comes along before the next block.
As long as all dependencies have at least 1 conf, if the transaction doesn’t have enough priority at first, the dependencies will age until it does.
QuoteGaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course! Or managing how much priority you spend on a transaction. The software would have to know your future plans to know whether to spend your priority now or save it for later. I don’t think we’ll need to get into that much detail though. There’s a wide enough difference between normal users and flooders.
Priority doesn’t have to do everything. Once you know there’s a flood, you can add -paytxfee=0.01. Hopefully with priority, your transactions before that should be at worst slow, not stuck.