Topic: Flood attack 0.00000001 BC - page 4. (Read 41114 times)

Would love to see this value at 0.001 rather than 0.01

By the time everyone has Bitcoins, the fee will have been removed or adjusted.

I added this little tidbit into my IRC bot:

According to http://is.gd/dsqcH the world population is 6,855,986,675. If everyone had the same amount of bitcoins, everyone would have 0.00306302 bitcoins.  If 0.00000001 bitcoins were equivalent to US$0.01, then everyone would have equivalent of US$3,063.01645489 and the value of all bitcoins would be equivalent of US$21,000,000,000,000.00.

How would the BTC0.01 fee affect things considering above?

This is not quite right.  The block header that is being hashed is a constant size no matter how many transactions the block contains.
So blocks with more transactions in them should still take the same amount of time to hash.

The rest is correct and insightful though.

If I understand the workings of the system correctly, clients on the network are broadcast the details on the new transactions coming in.  If a given client is generating they take any transactions they have seen come into them, bundle them into a "trial block" (along with a new 50 BTC token for themselves) and then commence trying to find a nonce which hashes this block to something below the target value.

Since blocks with more transactions in them will take longer to hash, the flood of small payments would  make the client work harder before it solves a block.  What if we change the transaction format from the current "123 wants to send X coins to 456", to be something like "123 wants to send X coins to 456 and will pay Y coins to whomever solves the block containing this transaction".

Then each client sets their own minimum transaction fee (which defaults to 0).  If they receive new transaction from someone, they check that the fee is greater than or equal to their own minimum transaction fee.  If the fee is high enough they will add the transaction to the pool of transactions they are trying to find a solution for.  If not, they will just ignore the update (still forwarding it on to others though so the network still functions).  When they add the transaction they will really add it as 2 parts, the X coins from 123 to 456, and a second transaction of 123 to themself.

This allows for the creation of a "processing market" and allows the fee to be set by the market itself.  Some people will be willing to solve blocks for free and will include any transaction they are sent.  Other clients will set a very high fee and only try to solve the few that meet this fee.  In this way transactions with higher fees get "priority" processing since they will be included in more nodes calculations.  People who don't want to pay a transaction fee can still put packets out and they will eventually be solved but will take longer because some nodes won't work on them.

This allows the transaction fee to move up and down with the value of bitcoins and it also gives people an incentive to keep running the program after new blocks are not generating bitcoins (as they will be 20 years from now).

-Buck

Ideally, you raise the ceiling in this situation. Right now, there is a 21 million coin limit. So as the value goes up, so does the ceiling so to speak. Unless one person has 20 million bitcoins and the rest of the world has to trade with 1 million, there should be no reason go in the opposite direction for the value to value comparison. But I do understand exactly what you mean though because some world currency is traded like that where 1 unit of XYZ country equals 20,000 of another, so small decimal values have to be used.

Since the transaction fee can't get below 0.01, the value should always be greater than the fee, otherwise, people are not making any financial sense. It would be like living in a city where it cost $10.00 to drink from a water fountain. The business model should fail in light of free, public water fountains outside, so who would bother to pay that much money when the alternative makes more financial sense.

Same way with the 0.01 fee limit, people already expect it and won't value things beneath it as it wouldn't make financial sense.  If the lowest possible fee is 0.01, why would anyone sell anything for less than that? You would put yourself out of business quickly.

I think a 0.01 BTC minimum send is fine for now. At the current exchange rate, that's 8/1000 of a penny USD, or 80 millionths of a dollar. Any micropayment smaller than that would not be made one at a time. If, for example, you wanted to charge 0.001BTC for something, you could just charge 0.01 and keep a balance.

If bitcoins become much more valuable, we can change this and push out a new version.

I guess the worry here is that it's possible that bitcoins could end up being worth a lot more than they are today. For example, if 0.01 BTC works out to be the equivalent of $1 today, then that built-in 0.01 transaction fee is far too high.

If there is some way to make the transaction fee scale with the worth of the currency that would be best, but I can't think even conceptually how that could be possible. It's not like the currency has any idea how much it is worth in real terms.

You can send a billion small transactions, it doesn't slow anything down, except the user interface because you end up with a ton of items in the list.  Just go ahead and try it, see for yourself.

All of the transactions are included by nodes that are attempting to generate the next block and only the header is hashed so it is not harder to generate a block that represents a million transactions than it is to generate a simple coinbase only.  This is what the confirmations are, blocks that include your transaction.

so the fee must be the same for all nodes isn't it ?

do the nodes reject other nodes that doesn't apply the same fee?

if not, there is no way to wait/find a node that apply a lower fee?

The fee is paid to whoever generates the block that the transactions are in, and that's random.

Your friend could run a node that refunds the fee, but unless your friend can convince a lot of other people to run nodes that do the same thing you're almost certainly going to end up paying the fee.

Remember that all transactions (even payments from you to your friend) are broadcast across the payment network; they HAVE to be, because if they weren't you could spend the same coins twice without getting caught.

if i send many 0.00000001 BC using a friend node that take no fee (or that send fee back to me).

Will the friend node spead all the transactions over the network?

Gavin,

It's simple.  You will need a fixed component transaction fee, but it will probably be much smaller than that.  The fixed component should reflect the true cost to the network of running the transaction.  So, the additional bandwidth, latency, etc that the transaction actually costs the network.

Chances are, this will be tiny.  I'd guess something like 0.00001 BC, even at the current exchange rate.

But how would you distinguish between a legitimate micropayment-processing IP and a spammy "I want to make Bitcoin use so much bandwidth nobody is willing to run it any more" IP?

Really small micropayments seem to me to be a really hard problem, and I don't think Bitcoin should try to solve too many very hard problems all at once.

Hmm, I didn't realize that was in there, and I really don't like that approach.

That pretty much ruins the possibility of using bitcoin for true micropayments.  Wouldn't it be better for clients to just ignore a spammy IP?  Sure an attacker could get more, but he couldn't get millions.

From the source code:

hi, what would happen if someone sends millions of 0.00000001 BC to millions of address please ?

=> all of the networks peers must store all transactions ?
=> are each 0.00000001 owner/hash stocked in blocks on all peers?

i don't really understand how bitcoin handle fractions of bc