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
Re: Flood attack 0.00000001 BC
From the source code:
Code:
main.h: // To limit dust spam, require a 0.01 fee if any output is less than 0.01
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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?
Will the friend node spead all the transactions over the network?
Re: Flood attack 0.00000001 BC
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 spread all the transactions over the network?
Will the friend node spread all the transactions over the network?
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.
Re: Flood attack 0.00000001 BC
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?
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?
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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.
If bitcoins become much more valuable, we can change this and push out a new version.
Re: Flood attack 0.00000001 BC
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.
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.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.
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.
Re: Flood attack 0.00000001 BC
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
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
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
From the source code:
Code:
main.h: // To limit dust spam, require a 0.01 fee if any output is less than 0.01
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?
Re: Flood attack 0.00000001 BC
By the time everyone has Bitcoins, the fee will have been removed or adjusted.
Re: Flood attack 0.00000001 BC
From the source code:
Code:
main.h: // To limit dust spam, require a 0.01 fee if any output is less than 0.01
Would love to see this value at 0.001 rather than 0.01
Re: Flood attack 0.00000001 BC
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
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
Re: Flood attack 0.00000001 BC
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.
Re: Flood attack 0.00000001 BC
Does paying the "fee" require the use of the "pay to anyone" signature I read about in another thread?
Re: Flood attack 0.00000001 BC
Hi.
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
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
Re: Flood attack 0.00000001 BC
Hi.
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
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.
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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.
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).
Re: Flood attack 0.00000001 BC
... 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.
Re: Flood attack 0.00000001 BC
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;
foreach(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = CENT;
Re: Flood attack 0.00000001 BC
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.)
Re: Flood attack 0.00000001 BC
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;
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.
Re: Flood attack 0.00000001 BC
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.
Re: Flood attack 0.00000001 BC
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.
Re: Flood attack 0.00000001 BC
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.
Re: Flood attack 0.00000001 BC
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.
Re: Flood attack 0.00000001 BC
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 ?
Re: Flood attack 0.00000001 BC
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.
Re: Flood attack 0.00000001 BC
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?
Re: Flood attack 0.00000001 BC
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":
In your scenario there are two outputs, 1 is 1 BTC and the other is 0.005 BTC.Code:
main.h:
foreach(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = CENT;
foreach(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = CENT;
0.005 < 0.01 therefore a fee applies to the transaction.
Re: Flood attack 0.00000001 BC
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?
Does including more slow down your hashing rate?
Re: Flood attack 0.00000001 BC
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.
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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: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.
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?Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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.
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.Re: Flood attack 0.00000001 BC
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.
Anonymous#45
Re: Flood attack 0.00000001 BC
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.
Re: Flood attack 0.00000001 BC
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?Re: Flood attack 0.00000001 BC
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
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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?Now you would fill it in with the address of the person you are asking to build the block.
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.
Re: Flood attack 0.00000001 BC
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.
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.
Re: Flood attack 0.00000001 BC
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?Only if the "dust" is combined back together and confirmed deeply enough again only then can the dust space be dropped.
Can the line be moved down slightly? Any bad side-effects if it was?
Re: Flood attack 0.00000001 BC
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.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 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.
Re: Flood attack 0.00000001 BC
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?Only if the "dust" is combined back together and confirmed deeply enough again only then can the dust space be dropped.
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.
Re: Flood attack 0.00000001 BC
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?
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?
Re: Flood attack 0.00000001 BC
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...
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...
Re: Flood attack 0.00000001 BC
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...
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
Re: Flood attack 0.00000001 BC
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...
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
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
Perhaps somebody just experimented already?
Re: Flood attack 0.00000001 BC
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.
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.