Bitcoin Forum
March 28, 2024, 10:10:09 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: af  (Read 3648 times)
Anonymous
Guest

af
November 05, 2010, 11:44:00 PM
Last edit: September 11, 2011, 04:28:24 PM by davidonpda
 #1

adgadg
1711663809
Hero Member
*
Offline Offline

Posts: 1711663809

View Profile Personal Message (Offline)

Ignore
1711663809
Reply with quote  #2

1711663809
Report to moderator
1711663809
Hero Member
*
Offline Offline

Posts: 1711663809

View Profile Personal Message (Offline)

Ignore
1711663809
Reply with quote  #2

1711663809
Report to moderator
Remember that Bitcoin is still beta software. Don't put all of your money into BTC!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711663809
Hero Member
*
Offline Offline

Posts: 1711663809

View Profile Personal Message (Offline)

Ignore
1711663809
Reply with quote  #2

1711663809
Report to moderator
1711663809
Hero Member
*
Offline Offline

Posts: 1711663809

View Profile Personal Message (Offline)

Ignore
1711663809
Reply with quote  #2

1711663809
Report to moderator
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
November 06, 2010, 12:14:10 AM
Merited by Foxpup (3), ABCbits (1)
 #2

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.

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
November 06, 2010, 06:08:19 PM
Merited by Foxpup (1)
 #3

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2164


Chief Scientist


View Profile WWW
November 07, 2010, 02:14:29 AM
 #4

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.

How often do you get the chance to work on a potentially world-changing project?
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416
Merit: 277


View Profile
November 08, 2010, 02:31:22 AM
 #5

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
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2164


Chief Scientist


View Profile WWW
November 08, 2010, 11:57:37 PM
 #6

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.  

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!


How often do you get the chance to work on a potentially world-changing project?
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416
Merit: 277


View Profile
November 09, 2010, 12:30:32 AM
Last edit: November 09, 2010, 01:01:26 AM by ByteCoin
 #7

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.  

But please, create your own client and try to break things on the test network!
No incentive to do so thanks!

ByteCoin
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2164


Chief Scientist


View Profile WWW
November 09, 2010, 07:36:38 PM
 #8

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.

How often do you get the chance to work on a potentially world-changing project?
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 6611


View Profile
November 13, 2010, 11:25:26 PM
Merited by Foxpup (3)
 #9

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.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416
Merit: 277


View Profile
November 13, 2010, 11:55:11 PM
 #10

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
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 6611


View Profile
November 14, 2010, 04:53:19 PM
Last edit: November 14, 2010, 05:15:52 PM by satoshi
Merited by Foxpup (2), ABCbits (2)
 #11

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.
throughput
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
November 15, 2010, 11:27:28 AM
 #12

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.

So, I agree totally, and  we need a txfee monitor for the last block(s) to be able to see
what it was filled with, to concisely put a better bet, with no guessing.
MrFlibble
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
November 24, 2010, 11:15:17 PM
 #13

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.

Forgive me for suggesting complexity, but the "priority" of input coins could be tracked back more than one block to make some sliding average.  This reduces the effect of "temporarily devaluing" money by transferring it.

If you look back ten hops and found no "old" money, then there is frivolous jiggling going on.  It also creates a new type of complexity attack.   Sad
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!