Bitcoin Forum
March 28, 2024, 11:14:00 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: Flood attack 0.00000001 BC  (Read 41003 times)
lachesis
Full Member
***
Offline Offline

Activity: 210
Merit: 104


View Profile
August 05, 2010, 03:11:10 PM
 #41

Bitcoin isn't currently practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.

Bitcoin is practical for smaller transactions than are practical with existing payment methods.  Small enough to include what you might call the top of the micropayment range.  But it doesn't claim to be practical for arbitrarily small micropayments.
Why isn't it practical? I agree that a good micropayment system would avoid generating thousands of transactions (e.g. one per packet), but that doesn't mean that bytemaster's change idea is wrong:
Quote from: bytemaster
Payments would generally be advanced, say 1 BTC at a time and when the connection closes any "change" would be returned.  This rule makes it impossible to pay for a simple "search query" with no further transactions.
That seems like a great use case. Furthermore, as llama said, the fixed component of a transaction fee should always represent the real cost of including that transaction in a block. So, are there any more intelligent and less painful ways of implementing anti-dust spam systems?

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
1711624440
Hero Member
*
Offline Offline

Posts: 1711624440

View Profile Personal Message (Offline)

Ignore
1711624440
Reply with quote  #2

1711624440
Report to moderator
1711624440
Hero Member
*
Offline Offline

Posts: 1711624440

View Profile Personal Message (Offline)

Ignore
1711624440
Reply with quote  #2

1711624440
Report to moderator
1711624440
Hero Member
*
Offline Offline

Posts: 1711624440

View Profile Personal Message (Offline)

Ignore
1711624440
Reply with quote  #2

1711624440
Report to moderator
Make sure you back up your wallet regularly! Unlike a bank account, nobody can help you if you lose access to your BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711624440
Hero Member
*
Offline Offline

Posts: 1711624440

View Profile Personal Message (Offline)

Ignore
1711624440
Reply with quote  #2

1711624440
Report to moderator
1711624440
Hero Member
*
Offline Offline

Posts: 1711624440

View Profile Personal Message (Offline)

Ignore
1711624440
Reply with quote  #2

1711624440
Report to moderator
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
August 05, 2010, 03:39:19 PM
 #42

I think the current system works fine.  If someone wants to implement a micro-payment system then they will have to host enough nodes and contribute enough processing power to include their small transactions.   I see no reason to require any node to accept or forward micro-payment transactions if said nodes does not wish to.  

The real issue is that even a simple legitimate automated micro-payment system could overload bitcoin by introducing more transactions than the credit card system currently uses.   The net result is that block sizes could become HUGE.

In my use case you have a P2P system where they pay for priority downloads.   Assume you have a single "torrent" file with 100,000 people all seeding and downloading.  That could easily generate 100,000 micro-payments per minute.  Now clearly, the program would only have to use BTC in the event that upload != download between two clients.  

It would be distributed and thus there would be no easy way to identify "spam" from legitimate usage.    Even using my solution of transferring 1+ BTC at a time and giving change if the balance is greater than 0.01 could cause a transaction bloat writ large.

I suspect that the "cost" of handing individual transactions may be low (.00001 BTC) but the cost of handling ALL of those little transactions from millions of users using automated payment negotiation/bidding systems would quickly make it impossible to even listen for all incoming transactions.  

The only solution to this problem is to make broadcasting of a transaction "non free".  Namely, if you want me to include it you have to pay me.  The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block.   In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.  

The implication is that you may not even receive notice of payment until a node that you paid to receive your transaction and *attempt* to integrate it into a block manages to do so.  This means that you would not even see 0/unconfirmed and that a transaction must make it into a block before anyone that wasn't paid to *attempt* to integrate it even knows it exists.

This structure would encourage pay-to-ip systems because that make the receiver of the payment responsible for paying to get it integrated.   Either they run their own bitcoin generators *or* they pay to send the transaction to someone who is.  

  

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6611


View Profile
August 05, 2010, 04:03:21 PM
Merited by MirkoIta (10)
 #43

Forgot to add the good part about micropayments.  While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall.  If Bitcoin catches on on a big scale, it may already be the case by that time.  Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms.  Whatever size micropayments you need will eventually be practical.  I think in 5 or 10 years, the bandwidth and storage will seem trivial.

I am not claiming that the network is impervious to DoS attack.  I think most P2P networks can be DoS attacked in numerous ways.  (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)

If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee.  0.1.5 actually had an option to set that, but I took it out to reduce confusion.  Free transactions are nice and we can keep it that way if people don't abuse them.

That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01?  It would be awfully annoying to ask each time.  If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left.  I think it should just add it automatically.  It's trivial compared to the fees many other types of services add automatically.

Does including more slow down your hashing rate?  
No, not at all.
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6611


View Profile
August 05, 2010, 04:30:20 PM
 #44

Quote from: bytemaster
Payments would generally be advanced, say 1 BTC at a time and when the connection closes any "change" would be returned.  This rule makes it impossible to pay for a simple "search query" with no further transactions.
One alternative is to use a round-up system.  You pay for, say, 1000 pages or images or downloads or searches or whatever at a time.  When you've used up your 1000 pages, you pay for another 1000 pages.  If you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.

Or you could pay per day.  The first time you access the site on a given day, you pay for 24 hours of access.

Per 1000 or per day may be easier for consumers to get their heads around too.  They worry about per item because it's harder to figure if it might add up too fast.  Unlimited for 24 hours they know what the cost will be.  Or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use.
17ujzChRb6VPQGyANVyktc1du
Guest

August 05, 2010, 04:37:53 PM
 #45


Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.

Only if the "dust" is combined back together and confirmed deeply enough again only then can the dust space be dropped.


Improved attack would be : start with 1BTC then transfer 0.999999999BTC, then 0.999999998BTC, ...
It results 1 million accounts (minus 10000) with 0.000000001BTC each.
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6611


View Profile
August 05, 2010, 04:39:58 PM
 #46

The only solution to this problem is to make broadcasting of a transaction "non free".  Namely, if you want me to include it you have to pay me.  The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block.   In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.  
I don't know a way to implement that.  The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size.  If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?
ByteCoin
Sr. Member
****
Offline Offline

Activity: 416
Merit: 277


View Profile
August 05, 2010, 04:45:58 PM
 #47

If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?

The transaction fee transaction would be designed to be a completely predictable consequence of the main transaction and hopefully any fee for processing the main transaction would also take into account the need for a fee transaction too. In other words the fee transaction would contain its own fee. This therefore seems to be a manageable aspect of the problem.

ByteCoin
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
August 05, 2010, 04:46:52 PM
 #48

Right now the transaction fee address is left "blank" and the block generator fills it out.
Now you would fill it in with the address of the person you are asking to build the block.  

If the transmit fee <= block integration fee no one could profitably forward the transaction and thus must generate a block themselves.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6611


View Profile
August 05, 2010, 05:49:43 PM
 #49

Right now the transaction fee address is left "blank" and the block generator fills it out.
Now you would fill it in with the address of the person you are asking to build the block.  
If you're only going to have one person work on building the block, that could take days.  Oh, do you mean send a different variation to each node with the tx fee written to them?

The way it is now, it's whoever builds this gets it.

If we needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast.  Relay paying transactions to me, or I won't relay them to you.  It probably won't be an actual problem though.  It only takes one node relaying like it should to cancel out 7 others greedily not relaying.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
August 05, 2010, 06:12:02 PM
 #50

The assumption is that you would send variations of the same transaction to different nodes with a tip for working to integrate your transaction.  In order for that node to collect their tip they eventually have to generate a block, but they eventually will anyway.  The tip would be below the amount that would allow said user to "rebroadcast" their transmit fee.  So you don't get recursive transmit fees. 

Say I want to send .001 BTC to Fred.   The cluster is operating at 1billion k/hash/second, then I need to distribute my transactions to enough nodes so that the k/hash/second % of the total is acceptably high for the transaction to get logged within the next N blocks.   

So generating nodes A, B, and C each price their transmit fee proportional to their khash rate.  (how do they prove their khash rate?  total blocks generated over time?)

So I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A.   I send a different one to B and C.   

Now A, B, and C cannot make a profit by sending that transaction for anyone else to crunch on so if they want to collect they have to process it.

The trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block.




https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
knightmb
Sr. Member
****
Offline Offline

Activity: 308
Merit: 256



View Profile WWW
August 05, 2010, 07:43:02 PM
 #51

Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.

Only if the "dust" is combined back together and confirmed deeply enough again only then can the dust space be dropped.

Does sending 0.1 BTC a million times also create a single transaction? Where is the line when it goes from a single transaction to independent transactions?
Can the line be moved down slightly? Any bad side-effects if it was?

Timekoin - The World's Most Energy Efficient Encrypted Digital Currency
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652
Merit: 2164


Chief Scientist


View Profile WWW
August 06, 2010, 12:32:49 AM
 #52

So I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A.   I send a different one to B and C.   

Now A, B, and C cannot make a profit by sending that transaction for anyone else to crunch on so if they want to collect they have to process it.

The trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block.
I'm thoroughly confused on what, exactly, you're proposing.

I want to make a 100 Bitcoin transaction to you.

You're proposing that I need to pay a "transmit fee" ... which is paid to who and does what, exactly?

If I pay it to A, B, and C, does that mean they rebroadcast the transaction to everybody they're connected to?  Do they, in turn, pay transmit fees to the nodes they're rebroadcast it to?  What stops them from saying "Thank you very much for the transmit fee" and cheating (drop my transaction on the floor)?

Satoshi's proposal that all transaction carry a minimum fee to cover network overhead makes sense; whoever generates the block with the transaction gets the fee.

How often do you get the chance to work on a potentially world-changing project?
lfm
Full Member
***
Offline Offline

Activity: 196
Merit: 104



View Profile
August 07, 2010, 05:36:13 AM
 #53

Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.

Only if the "dust" is combined back together and confirmed deeply enough again only then can the dust space be dropped.

Does sending 0.1 BTC a million times also create a single transaction? Where is the line when it goes from a single transaction to independent transactions?
Can the line be moved down slightly? Any bad side-effects if it was?

I don't think you understood, it's nothing to do with the size of the transaction. it's the way transactions get split up. If you start with 1 BTC and send 100 x 0.01 transactions to your friend thats 100 transaction chains one step long. He may or may not combine them back together into a single 1BTC transaction but untill he does the net must keep all 100 transactions stored.

If you start with the same 1BTC or 0.01BTC or any single amount and pass it back and forth to your friend 100 times. Its a similar amount of traffic and storage at first but once the last one gets deeply confirmed (ie 6 blocks/1 hr later) you can forget/delete from your disk database all the transactions but the last one. It's the Merkle hash tree pruning stuff in the white paper.
Insti
Sr. Member
****
Offline Offline

Activity: 294
Merit: 252


Firstbits: 1duzy


View Profile
August 09, 2010, 09:18:42 AM
 #54

Are:
1) The transaction fees charged entirely up  to the block processing node?
Or
2) The transaction fees enforced by the network, which would mean that any block that contains an 'invalid' transaction because it did not include the correct fee would be rejected?

throughput
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
August 10, 2010, 10:13:30 AM
 #55

Does that mean, that my abilities to DDoS the entire Bitcoin network are only limited by my BTC
bying power? And not by the number of my network connections, nodes, etc?

BTW, let's test the network someday?
It is trivial to automate the process of sending small transactions to the list of known addresses.
Let's abuse the network and know the effect precisely.

I suppose, we should caution the other users...
Insti
Sr. Member
****
Offline Offline

Activity: 294
Merit: 252


Firstbits: 1duzy


View Profile
August 10, 2010, 02:53:41 PM
 #56

BTW, let's test the network someday?
It is trivial to automate the process of sending small transactions to the list of known addresses.
Let's abuse the network and know the effect precisely.

I suppose, we should caution the other users...

You should use the Test network
throughput
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
August 11, 2010, 07:37:23 AM
 #57

BTW, let's test the network someday?
It is trivial to automate the process of sending small transactions to the list of known addresses.
Let's abuse the network and know the effect precisely.

I suppose, we should caution the other users...

You should use the Test network
Test network have test scale.

Hmm, I think the other guys may not ask your permission to abuse the real network next time.
They will just do it.

I'm sure, the Bitcoin is useless if it is vulnerable to such a simple intrusion.
We should prove, that it is sustainable to real world threats. Like me  Grin

Perhaps somebody just experimented already?
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6611


View Profile
August 11, 2010, 11:28:50 PM
 #58

It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it's still small, it's nice to keep it small so new users can get going faster.  When I eventually implement client-only mode, that won't matter much anymore.

There's more work to do on transaction fees.  In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee.  However, I haven't had time yet to add that option to the UI.

Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.
throughput
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
August 12, 2010, 12:37:24 PM
 #59

It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it's still small, it's nice to keep it small so new users can get going faster.  When I eventually implement client-only mode, that won't matter much anymore.

There's more work to do on transaction fees.  In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee.  However, I haven't had time yet to add that option to the UI.

Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.
OK, I get it. Not sure for the other jerks  Grin though.
elux
Legendary
*
Offline Offline

Activity: 1458
Merit: 1006



View Profile
June 02, 2015, 10:59:38 PM
 #60

It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it's still small, it's nice to keep it small so new users can get going faster.  When I eventually implement client-only mode, that won't matter much anymore.

There's more work to do on transaction fees.  In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee.  However, I haven't had time yet to add that option to the UI.

Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.

necroing ancient thread

Bolded Satoshi's view on SPV vs block[chain] size for emphasis.

Mike and Gavin are simply siding with Satoshi on the issue.

Pages: « 1 2 [3] 4 »  All
  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!