Flood attack 0.00000001 BC - page 3.

Insti

sr. member

Activity: 294

Merit: 252

Firstbits: 1duzy

Quote from: ?? on ??

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.

Quote from: Gavin Andresen on August 04, 2010, 08:55:59 AM

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.

Insti

sr. member

Activity: 294

Merit: 252

Firstbits: 1duzy

Quote from: satoshi on August 04, 2010, 12:25:36 PM

Quote from: Insti on August 04, 2010, 10:58:31 AM

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?

satoshi

founder

Activity: 364

Merit: 6472

Quote from: Insti on August 04, 2010, 10:58:31 AM

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

sr. member

Activity: 294

Merit: 252

Firstbits: 1duzy

Quote from: theymos on August 04, 2010, 11:43:56 AM

Quote from: Insti on August 04, 2010, 10:58:31 AM

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 ?

bytemaster

hero member

Activity: 770

Merit: 566

fractally

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.

theymos

administrator

Activity: 5166

Merit: 12850

Quote from: Insti on August 04, 2010, 10:58:31 AM

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.

knightmb

sr. member

Activity: 308

Merit: 256

Quote from: Insti on August 04, 2010, 10:58:31 AM

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.

Insti

sr. member

Activity: 294

Merit: 252

Firstbits: 1duzy

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.

bytemaster

hero member

Activity: 770

Merit: 566

fractally

Quote from: Gavin Andresen on August 04, 2010, 08:55:59 AM

Quote from: Insti on August 04, 2010, 08:17:00 AM

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

sr. member

Activity: 294

Merit: 252

Firstbits: 1duzy

Quote from: Gavin Andresen on August 04, 2010, 08:55:59 AM

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.)

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: Insti on August 04, 2010, 08:17:00 AM

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

sr. member

Activity: 294

Merit: 252

Firstbits: 1duzy

Quote from: Gavin Andresen on August 04, 2010, 07:58:58 AM

... 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

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: bytemaster on August 04, 2010, 02:22:56 AM

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).

bytemaster

hero member

Activity: 770

Merit: 566

fractally

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.

llama

member

Activity: 103

Merit: 61

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.

melvster

sr. member

Activity: 350

Merit: 250

Quote from: throughput on July 23, 2010, 09:39:41 AM

Hi.

Quote from: nenolod on July 23, 2010, 01:03:00 AM

Quote from: llama on July 12, 2010, 10:23:46 AM

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 Sad

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.

throughput

full member

Activity: 158

Merit: 100

Hi.

Quote from: nenolod on July 23, 2010, 01:03:00 AM

Quote from: llama on July 12, 2010, 10:23:46 AM

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 Sad

Red

full member

Activity: 210

Merit: 111

Does paying the "fee" require the use of the "pay to anyone" signature I read about in another thread?

nenolod

newbie

Activity: 8

Merit: 0

Quote from: llama on July 12, 2010, 10:23:46 AM

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.

BeeCee1

member

Activity: 115

Merit: 10

What would happen if someone modified their client to not offer to pay the fee, and also modified their client to not require the fee?

Here's my best guess:
* They generate a 0.00000001 BC payment (but don't include the fee)
* This transaction goes to the clients peers
* The peers don't include it in the block they are solving since fee not paid.
* Do the peers still pass the transaction along to the rest of the network?
* A block gets solved without the transaction in it
* client notices its transaction wasn't in the block and re-broadcasts the transaction?
* eventually client solves a block itself and that transaction is included in it so it goes out to the rest of the network

Topic: Flood attack 0.00000001 BC - page 3. (Read 41014 times)