Flood attack 0.00000001 BC

[throughput]

Hi.

That pretty much ruins the possibility of using bitcoin for true micropayments. 

I do not see how it does that.  1 BTC will likely always be smaller than USD/EUR/etc, thus meaning that it can be used for micropayments.

Micropayment is less that 0.01 $, I suppose.
Having an (economically) effective implementation of micropayment system will affect the way current economics works.
For example, it may make the media producer's business unprofitable in some areas, I suppose.

So, the economics may be interested in payments with less that 0.001 $ volume and with more than millions transaction per day numbers.
But that system still does not exists

[1714118881]

1714118881

[1714118881]

1714118881

[1714118881]

1714118881

[1714118881]

1714118881

[1714118881]

1714118881

[melvster]

Hi.

That pretty much ruins the possibility of using bitcoin for true micropayments. 

I do not see how it does that.  1 BTC will likely always be smaller than USD/EUR/etc, thus meaning that it can be used for micropayments.

Micropayment is less that 0.01 $, I suppose.
Having an (economically) effective implementation of micropayment system will affect the way current economics works.
For example, it may make the media producer's business unprofitable in some areas, I suppose.

So, the economics may be interested in payments with less that 0.001 $ volume and with more than millions transaction per day numbers.
But that system still does not exists

You can do it if you have a system of micropayments with the CASH OUT in bitcoins.  That way most transactions will not go through the bitcoin system.

[llama]

I think it's very important that the transaction fee reflect no more than the true cost that the transaction causes the network.

Micropayments can be useful even if they're very very tiny.  Imagine a lightbulb that sends a little ping bitcoin charge for every millisecond it's turned on.  There are countless applications for tiny tiny payments.

[bytemaster]

Well, right now nothing stops someone from creating a system where:

A sends  1.00000001 to B
B sends  1.00000000 back to A

Net result is a micro-payment and no processing fee.  I am creating a system that does something very similar to the above.   The reality is that any "micro-payment" system should probably be handled outside the BTC block and have the payments "summed up" before being sent. 

I think the processing fee design is brilliant.  Every node can pick and choose which transactions it wants to include and thus the "time until included" is directly proportional to the number of nodes who accept your "offer".  Worst case you have to wait until your lonely PC can create a block which at the moment could be weeks!

In fact, I think it would be reasonable to offer to pay the nodes that propagate your transaction if there was some way to "enforce it" and prevent rouge clients from collecting fees but not doing work.

[Gavin Andresen]

Well, right now nothing stops someone from creating a system where:

A sends  1.00000001 to B
B sends  1.00000000 back to A

Net result is a micro-payment and no processing fee.

... unless B started with zero bitcoins.  Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001).

[Insti]

... unless B started with zero bitcoins.  Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001).

Surely this is not correct?

The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.

[Gavin Andresen]

The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.

The rule is "if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee":

Code:

main.h:
foreach(const CTxOut& txout, vout)
  if (txout.nValue < CENT)
    nMinFee = CENT;

[Insti]

The rule is "if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee":

Since there is no way to tell which is the 'change' transaction.
That's kinda cool.
 (and somewhat horrible at the same time.)

[bytemaster]

The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.

The rule is "if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee":

Code:

main.h:
foreach(const CTxOut& txout, vout)
  if (txout.nValue < CENT)
    nMinFee = CENT;

Wow, ok this needs to go or it becomes impossible to do micropayment systems.    For example, I am trying to build an automated system you "pay per packet" sent across a P2P network.  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.   I suppose that I would have to release the P2P program with its own BTC client that does not have this rule.  It would take longer for transactions to post, but in theory if all clients are mining then you would still have a good chance of getting the payment in.

[Insti]

What exactly is this 'dust spam' that this 0.01BTC transaction fee "solving"?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

I'm not aware that the network is straining under the weight of the existing transaction volume.
Anyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.

[knightmb]

What exactly is this 'dust spam' that this 0.01BTC transaction fee "solving"?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

I'm not aware that the network is straining under the weight of the existing transaction volume.
Anyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.

There are builds that remove this limit, mainly for testing right now, I think that's why it's disabled until it can be tweaked a little more.

[theymos]

What exactly is this 'dust spam' that this 0.01BTC transaction fee "solving"?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

I'm not aware that the network is straining under the weight of the existing transaction volume.
Anyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.

Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.

A better solution would be to deprioritize transactions below 0.01 and completely drop them if there are more than 10,000 (or whatever) in the queue. Then these transactions would be slower and less reliable than other transactions, but they would work and not interfere with "real" transactions.

[bytemaster]

priority is all contingent upon how many nodes accept them.  Thus if only 1% of the nodes accept a transaction fee of 0.000001 btc then you will have a 1% chance of being included in the next block.  If all nodes accept transaction fees of 1BTC then you have near 100% chance of being in the next block.

[Insti]

What exactly is this 'dust spam' that this 0.01BTC transaction fee "solving"?

Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.

Someone with one Bitcoin can already send 100,000,000 transactions, by repeatedly sending the coin to themselves. How is it any different if the value of the transaction is 1 or 0.00000001 ?

[satoshi]

It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

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.

[Insti]

It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

Bitcoin isn't practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, certainly 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 not?
I don't see how size would make a difference.
Is it just due to the number of transactions that the system is able to handle?

[Insti]

User sends you 1.005 bc's, you send them back 1. Is a fee charged in that scenario? Because the change coming back to you would be .005?

Yes, this was covered above.

The rule is "if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee":

Code:

main.h:
foreach(const CTxOut& txout, vout)
  if (txout.nValue < CENT)
    nMinFee = CENT;

In your scenario there are two outputs, 1 is 1 BTC and the other is 0.005 BTC.
0.005 < 0.01 therefore a fee applies to the transaction.

[FreeMoney]

Can the fee rules be arbitrarily complicated? And is the size limit hard wired or completely up to the node?

Does including more slow down your hashing rate? 

[lfm]

What exactly is this 'dust spam' that this 0.01BTC transaction fee "solving"?

Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.

Someone with one Bitcoin can already send 100,000,000 transactions, by repeatedly sending the coin to themselves. How is it any different if the value of the transaction is 1 or 0.00000001 ?

I'd like to repeat that question. Why could someone with 1 bc, not just send it back and forth between accounts a billion times? No fees would be charged.

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.

[lfm]

Well, right now nothing stops someone from creating a system where:

A sends  1.00000001 to B
B sends  1.00000000 back to A

Net result is a micro-payment and no processing fee.

... unless B started with zero bitcoins.  Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001).

ok if a and b both start out with 1 BTC and agree to transfer 0.0001 using two inputs and two outputs on a single transaction can change a to 0.9999 and b to 1.0001. The rest of the network it would seem would accept the transaction.

The only stumbling block is whoever creates the transaction needs the private keys for both inputs which would come from different wallets normally. The one who creates the transaction could cheat.