throughput



Offline



Activity: 158

Merit: 100







Full MemberActivity: 158Merit: 100 Re: Flood attack 0.00000001 BC July 23, 2010, 01:39:41 PM #21



Quote from: nenolod on July 23, 2010, 05:03:00 AM Quote from: llama on July 12, 2010, 02:23:46 PM 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.

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

llama



Offline



Activity: 103

Merit: 31







MemberActivity: 103Merit: 31 Re: Flood attack 0.00000001 BC August 04, 2010, 05:14:55 AM #23 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. Bitbills

bytemaster



Offline



Activity: 770

Merit: 559



BitShares







Hero MemberActivity: 770Merit: 559BitShares Re: Flood attack 0.00000001 BC August 04, 2010, 06:22:56 AM #24 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. https://steemit.com Blogging is the new Mining

bytemaster



Offline



Activity: 770

Merit: 559



BitShares







Hero MemberActivity: 770Merit: 559BitShares Re: Flood attack 0.00000001 BC August 04, 2010, 01:40:35 PM #29 Quote from: gavinandresen on August 04, 2010, 12:55:59 PM Quote from: Insti on August 04, 2010, 12:17:00 PM 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;



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

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.



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. https://steemit.com Blogging is the new Mining

Insti



Offline



Activity: 294

Merit: 251





Firstbits: 1duzy







Sr. MemberActivity: 294Merit: 251Firstbits: 1duzy Re: Flood attack 0.00000001 BC August 04, 2010, 02:58:31 PM #30

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.





theymos

Legendary



Offline



Activity: 3892

Merit: 7919







AdministratorLegendaryActivity: 3892Merit: 7919 Re: Flood attack 0.00000001 BC August 04, 2010, 03:43:56 PM #32 Quote from: Insti on August 04, 2010, 02:58:31 PM

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

bytemaster



Offline



Activity: 770

Merit: 559



BitShares







Hero MemberActivity: 770Merit: 559BitShares Re: Flood attack 0.00000001 BC August 04, 2010, 03:54:09 PM #33 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. https://steemit.com Blogging is the new Mining

satoshi

Sr. Member



Offline



Activity: 364

Merit: 2583







FounderSr. MemberActivity: 364Merit: 2583 Re: Flood attack 0.00000001 BC August 04, 2010, 04:25:36 PM

Last edit: August 05, 2010, 03:05:09 PM by satoshi #35 Quote from: Insti on August 04, 2010, 02:58:31 PM 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.

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



Offline



Activity: 294

Merit: 251





Firstbits: 1duzy







Sr. MemberActivity: 294Merit: 251Firstbits: 1duzy Re: Flood attack 0.00000001 BC August 04, 2010, 04:33:24 PM #36 Quote from: satoshi on August 04, 2010, 04:25:36 PM Quote from: Insti on August 04, 2010, 02:58:31 PM 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.

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?

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?

lfm



Offline



Activity: 196

Merit: 100









Full MemberActivity: 196Merit: 100 Re: Flood attack 0.00000001 BC August 05, 2010, 02:52:32 PM #39 Quote from: davidonpda on August 04, 2010, 05:02:14 PM Quote from: Insti on August 04, 2010, 04:11:55 PM Quote from: theymos on August 04, 2010, 03:43:56 PM Quote from: Insti on August 04, 2010, 02:58:31 PM 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 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 ?

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.

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.

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.