BitcoinTalk
#1From:
Anonymous
Subject:
af
Date:
adgadg
BitcoinTalk
#2From:
theymos
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
Spent transactions can be forgotten (though they currently aren't). That would prevent your sending coins back and forth from having a big impact on block size.
The transaction inclusion issue is fixed by increasing fees and making non-generators aware of the current blocksize. The fees after 250KB should increase faster.
I think this attack would be more difficult on the real network because of the differing fee schedules. You'll have half of the network including your transactions and half of the network not including them. Half of the network considers a block "filled" at 500KB, and half at the network-enforced maximum of 1MB.
You're right. That message is produced if fees bring a transaction over your balance, and the fee when the blocksize is over 500 KB is 21 million BTC. You wouldn't have gotten that if you weren't generating, since you wouldn't have known the current blocksize.
The transaction inclusion issue is fixed by increasing fees and making non-generators aware of the current blocksize. The fees after 250KB should increase faster.
I think this attack would be more difficult on the real network because of the differing fee schedules. You'll have half of the network including your transactions and half of the network not including them. Half of the network considers a block "filled" at 500KB, and half at the network-enforced maximum of 1MB.
Quote
Or maybe the entire size exceeded the 1 MB limit.
You're right. That message is produced if fees bring a transaction over your balance, and the fee when the blocksize is over 500 KB is 21 million BTC. You wouldn't have gotten that if you weren't generating, since you wouldn't have known the current blocksize.
BitcoinTalk
#3From:
theymos
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
Even if you made non-generators aware of the current blocksize, by doing this you could force everyone to pay transaction fees.
There's no avoiding that. An attacker will always be able to create millions of transactions; the only defense is fees on every transaction. Bitcoin was never intended to remain free forever.
BitcoinTalk
#4From:
Gavin Andresen
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
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.
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.
BitcoinTalk
#5From:
ByteCoin
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
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.
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
BitcoinTalk
#6From:
Gavin Andresen
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
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)Quote
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.
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.
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!
BitcoinTalk
#7From:
ByteCoin
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
The priority calculation you suggest would be a considerable improvement over the current system of first-come-first-served. If it were implemented then I think it's likely that the incentives outlined in my post would cease to operate and that average transaction sizes would not increase significantly.
There may be some incentive to break up large change if it is believe that spending it is not likely to be required in the near future, in order to ensure that coin holdings of adequate power always exist. It's hard to do this correctly as it requires the forcasting of both priority and spending far in advance.
If there were many contending transactions there would be a tendancy (all else being equal) to retard blocks with multiple ins because scriptSigs are so much larger than scriptPubKeys. I haven't an opinion whether this is bad or not.
I think there may be some small distortions to the value of older transactions on the grounds that they are so powerful. People might be motivated to "exchange" the private key instead of performing a transaction in order to maintain the power of these old transactions while still "spending" them without actually spending them. This would be nothing but advantage to bitcoin as these key exchages don't show up in the block chain.
Also unfortunately, there would be the incentive for the following undesirable behaviour:
Suppose someone has just been paid a large sum of bitcoin (1000BTC) and needs to make some small payments(1BTC). They also have recently been paid some smaller amouts of bitcoin(0.5BTC). If they try to pay the 1BTC debts using their 0.5BTC credits then their transactions have very low priority. This transaction can be represented as 2 * 0.5 BTC = 1BTC
If however they include the 1000BTC then the transaction has a much higher priority and it's not really wasting any significant accumulated age-derived power of the recently received 1000BTC. This transaction can be represented as 1000BTC + 2 * 0.5BTC = 1BTC + 1000BTC. This would approximately double the size of this sort of transaction.
ByteCoin
There may be some incentive to break up large change if it is believe that spending it is not likely to be required in the near future, in order to ensure that coin holdings of adequate power always exist. It's hard to do this correctly as it requires the forcasting of both priority and spending far in advance.
If there were many contending transactions there would be a tendancy (all else being equal) to retard blocks with multiple ins because scriptSigs are so much larger than scriptPubKeys. I haven't an opinion whether this is bad or not.
I think there may be some small distortions to the value of older transactions on the grounds that they are so powerful. People might be motivated to "exchange" the private key instead of performing a transaction in order to maintain the power of these old transactions while still "spending" them without actually spending them. This would be nothing but advantage to bitcoin as these key exchages don't show up in the block chain.
Also unfortunately, there would be the incentive for the following undesirable behaviour:
Suppose someone has just been paid a large sum of bitcoin (1000BTC) and needs to make some small payments(1BTC). They also have recently been paid some smaller amouts of bitcoin(0.5BTC). If they try to pay the 1BTC debts using their 0.5BTC credits then their transactions have very low priority. This transaction can be represented as 2 * 0.5 BTC = 1BTC
If however they include the 1000BTC then the transaction has a much higher priority and it's not really wasting any significant accumulated age-derived power of the recently received 1000BTC. This transaction can be represented as 1000BTC + 2 * 0.5BTC = 1BTC + 1000BTC. This would approximately double the size of this sort of transaction.
But please, create your own client and try to break things on the test network!
No incentive to do so thanks!ByteCoin
BitcoinTalk
#8From:
Gavin Andresen
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
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.
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.
BitcoinTalk
#9From:
satoshi
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
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.
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.
BitcoinTalk
#10From:
ByteCoin
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
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
BitcoinTalk
#11From:
satoshi
Subject:
Re: Some testing that I did on the testnetwork, my findings.
Date:
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.
Quote
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!
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.