Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: ByteCoin on November 19, 2010, 05:39:05 AM



Title: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: ByteCoin on November 19, 2010, 05:39:05 AM
The above address has intermittently been flooding the real network with transfers of 0.06BTC to itself. A the time of posting there have been about 2350 such transactions in the block chain. See the following link for details

http://theymos.ath.cx:64150/bbe/address/17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne

The transactions must be sized somewhere in the region of 210 bytes which means that half a megabyte of useless block chain has just been generated.

At the risk of belabouring the point, I'd like to point out that clients using "balance sheets" to facilitate deletion of spent transactions would not have their storage requirements increased by the recent attack. An attack differently structured however would have a negative effect on both types of client but the effects on "balance sheet" clients would be limited by the finite divisibility of the coins.

Both client types would suffer from an attack which padded the script instead but again the effect on "balance sheet" clients is considerably smaller.

ByteCoin


Title: Re: Recent floods by 17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne
Post by: FreeMoney on November 19, 2010, 05:53:03 AM
The above address has intermittently been flooding the real network with transfers of 0.06BTC to itself. A the time of posting there have been about 2350 such transactions in the block chain. See the following link for details

http://theymos.ath.cx:64150/bbe/address/17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne

The transactions must be sized somewhere in the region of 210 bytes which means that half a megabyte of useless block chain has just been generated.

At the risk of belabouring the point, I'd like to point out that clients using "balance sheets" to facilitate deletion of spent transactions would not have their storage requirements increased by the recent attack. An attack differently structured however would have a negative effect on both types of client but the effects on "balance sheet" clients would be limited by the finite divisibility of the coins.

Both client types would suffer from an attack which padded the script instead but again the effect on "balance sheet" clients is considerably smaller.

ByteCoin

Without going all the way to a balance sheet setup, is it possible to use simple logic to delete "unnecessary to know" transactions? Ah, that's the merkle tree thing isn't it? Would it be difficult to manually cut them out in cases like this? Or at least compact them? I mean it is the exact same thing up to 270 times in a block or something.

A "pruned chain" for people wanting to download the chain to run their own node seems like it should be a priority. And maybe a torrent of a chain updated monthly or something. I'd be a seed of course and if someone sets up a website with info and the torrent link I'd donate too.

Oh, and I sent this dummy those .06 coins.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: ByteCoin on November 19, 2010, 06:04:22 AM
Without going all the way to a balance sheet setup, is it possible to use simple logic to delete "unnecessary to know" transactions? Ah, that's the merkle tree thing isn't it? Would it be difficult to manually cut them out in cases like this? Or at least compact them? I mean it is the exact same thing up to 270 times in a block or something.

The short answer is yes, it can be done. Unfortunately, evolving attacks to get round the countermeasures is considerably easier than developing reliable, side-effect free countermenasures so it's probably worth thinking about ways to prevent or discourage or minimise these attacks.

The "pruned chain" you suggest is quite a large change to the client and probably can't really solve the problem. A torrent of the chain is just admitting defeat; that the client can't cope with the data distribution.

Oh, and I sent this dummy those .06 coins.

So who are they and what did they say? I was actually worried that people might blame me!

Ok just found out it's MrBurns... see http://bitcointalk.org/index.php?topic=1835.0

The number of spam transactions vs time between blocks plot is fairly linear. It looks like one transaction is being included every 15 seconds. I think we're getting away lightly at the moment as there seems little obstacle to me to including 50k (or more (500k?) thanks to Artforz) of free transactions in every block.

ByteCoin


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: m0mchil on November 19, 2010, 06:32:51 AM
There is only one condition at the moment for a spammer to be able to flood the network - available balance. He could easily generate new addresses and make as many transactions to himself as he wish, not loosing balance in the process.

For me there is only one obvious solution to this... to introduce 0.01 (or other amount, could be discussed) mandatory transaction fee. This will effectively reduce spammer's balance with time, making him unable to spam further.

This is exactly the same phenomenon that allows other kinds of spam - lack of 'price' for some action. Even a small such price solves the problem.

Someone would grieve about 'free' bitcoin transactions. I would argue that small mandatory transaction fee would be far cheaper than the millions of spam transactions we are facing to deal with in the future.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: jgarzik on November 19, 2010, 07:26:15 AM
For me there is only one obvious solution to this... to introduce 0.01 (or other amount, could be discussed) mandatory transaction fee. This will

+1 agreed.  All TX's have a cost, a mandatory TX fee would reflect that.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: caveden on November 19, 2010, 09:56:07 AM
For me there is only one obvious solution to this... to introduce 0.01 (or other amount, could be discussed) mandatory transaction fee. This will

+1 agreed.  All TX's have a cost, a mandatory TX fee would reflect that.


Disagree.
I don't like "hard" rules like this.
Miners should be free to charge how much they want as transaction fee for including your transaction in the blocks they produce. If someone wants to include them freely, fine.

By the way, this would be a nice improvement to the default client. The possibility of
  • Specifying a minimum transaction fee for the transactions to be included in blocks generated. The minimum value could be absolute, relative to the transaction amount, or relative to the transaction data size as today.
  • A way to voluntarily add transaction fee when doing a payment. Again, the value to add could be absolute, relative etc...


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: m0mchil on November 19, 2010, 10:24:58 AM
caveden, please reconsider. Regardless of what the generator is requiring for confirming the (spam) transaction, all other participants will pay with their disk space. This is a collective cost that any single participant can easily (and free) induce at the moment.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: sturle on November 19, 2010, 12:22:57 PM
For me there is only one obvious solution to this... to introduce 0.01 (or other amount, could be discussed) mandatory transaction fee. This will effectively reduce spammer's balance with time, making him unable to spam further.
How about one free transfer per address per block, and a transaction fee for more than that?  It will be much harder to spam, and still free for most users.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: joe on November 19, 2010, 12:23:51 PM
caveden, please reconsider. Regardless of what the generator is requiring for confirming the (spam) transaction, all other participants will pay with their disk space. This is a collective cost that any single participant can easily (and free) induce at the moment.

Users who configure a mandatory transaction fee can simply ignore blocks that have spam transactions that do not meet the configured minimum fee. So no, other participants will not have to pay with their disk space.

Of course, if the chain on top of an ignored block becomes 6 longer than the chain one's own client is working on, the client should "stop fighting it" and jump back over to the longer chain with the spam block that had no transaction fees.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: caveden on November 19, 2010, 01:15:08 PM
I really think it's important that the protocol does not enforce any minimum transaction fee rule. A block should be accepted on the chain regardless of its transaction fees.
Trying to come with an arbitrary rule like that is like trying to arbitrarily fix price limits. We cannot predict what is the correct minimum fee.

Miners, yes, they should be free to set those rules for the blocks they generate. So, if those in charge of the main client decide to follow a minimum-fee rule for the blocks generate by the main client, so be it. But never reject a block generated by another miner that doesn't follow the same fee rules.

And, as I said, if the client just gives the option to the user of configuring minimum transaction fees, I don't see why people would keep accepting transactions with no fees on their blocks. That would be a sort of "charity", but towards people you don't even know.
If the custom GPU miners are not charging fees right now it's probably because the main client doesn't easily give you the option of embedding fees to your transactions.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: laanwj on November 19, 2010, 03:54:39 PM
But what if a bitcoin becomes worth $100, then transaction cost of 0.01BC will suddenly seem like a lot.

Setting some arbitrary transaction cost doesn't sound like a good thing.

On the other hand it would be very effective at countering spam. I don't see any other realistic method of stopping people from spamming the network except for some kind of transaction fee. But please make it user settable and don't enforce anything.

One question... Where do the fees go?



Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: RHorning on November 19, 2010, 03:57:20 PM
I really think it's important that the protocol does not enforce any minimum transaction fee rule. A block should be accepted on the chain regardless of its transaction fees.
Trying to come with an arbitrary rule like that is like trying to arbitrarily fix price limits. We cannot predict what is the correct minimum fee.

Miners, yes, they should be free to set those rules for the blocks they generate. So, if those in charge of the main client decide to follow a minimum-fee rule for the blocks generate by the main client, so be it. But never reject a block generated by another miner that doesn't follow the same fee rules.

And, as I said, if the client just gives the option to the user of configuring minimum transaction fees, I don't see why people would keep accepting transactions with no fees on their blocks. That would be a sort of "charity", but towards people you don't even know.
If the custom GPU miners are not charging fees right now it's probably because the main client doesn't easily give you the option of embedding fees to your transactions.

Here it is suggested that there shouldn't be arbitrary minimums, what is stopping some miner to impose a maximum fee that is essentially confiscatory?  The issue cuts both ways here, and is essentially the same principle.

More significantly, there ought to be a network-wide fee policy that is consistent across the network for a great many reasons, not the least of which is at least some predictability.  Arbitrary policies seem to be even more chaotic if every single miner has a completely different policy for fees.

The one argument against arbitrary minimum fee that does seem to be important here is that this is significantly limiting in terms of what the minimum transaction cost can be and limits the ability of Bitcoins to be sub-divided into smaller units.  One of the claims and design goals of bitcoins is that in theory bitcoins can increase in value until supposedly the 21 million bitcoins that are to be generated in total will be sufficient to enable trade with the entire world economy.  Think about that for a little and imagine if 0.00001 BTC == $1 USD.  That isn't exactly a huge stretch of the imagination here, where charging 0.01 BTC for a transaction is the equivalent of $1000 USD for the transaction.  I would imagine such a situation would be a huge limit on the use an application of Bitcoins and significantly goes against at least the basic design principles including trying to aim toward enabling microtransactions that can't be done with PayPal and other electronic currency methods.

This is also my same complaint about the current limit on transactions less than 0.01 BTC.  Yes, I understand the rationale for this limit, but I think it is going to come back and be a major logical bug to the network as a whole.

It would be a sad day if it is cheaper to send money via PayPal than it is with Bitcoins.

The whole idea of what the fee schedules ought to be for transactions is something which needs some serious thought, even though I'd agree that there shouldn't be necessarily a free lunch here either.  I would be supportive of some sort of mandatory fee, but it ought to be consistent across the network and not arbitrary on a per miner basis.  If the miner wants to be generous and waive the fees, that is another issue entirely... somehow I think that will be an exception rather than the rule.  I think the assumption that people using Bitcoins are greedy SOBs is a pretty good one to consider as a postulate.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: RHorning on November 19, 2010, 04:02:50 PM
But what if a bitcoin becomes worth $100, then transaction cost of 0.01BC will suddenly seem like a lot.

Setting some arbitrary transaction cost doesn't sound like a good thing.

On the other hand it would be very effective at countering spam. I don't see any other realistic method of stopping people from spamming the network except for some kind of transaction fee. But please make it user settable and don't enforce anything.

One question... Where do the fees go?


We ended up posting about essentially principle, I just ended up exaggerating it a bit more.

As far as where the fees go, they belong to the miner who creates the work unit.  In other words, using the current generation method, you get 50 BTC (or whatever that will be) plus the transaction fees for processing all of the transactions that happen and get incorporated into that work unit.  In theory, over time it will be primarily transaction fees and not new coins which will be the incentive for creating new work units.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: caveden on November 19, 2010, 04:43:57 PM
Here it is suggested that there shouldn't be arbitrary minimums, what is stopping some miner to impose a maximum fee that is essentially confiscatory?

Nothing. Actually, as far as I understand, a miner has no obligation whatsoever to include any transaction in the blocks he produces.

Now, if you want to talk about what's the incentive for a miner to add transactions, well, it's mainly the fees. If a miner stipulates a high fee, people wouldn't pay it, and he would lose the opportunity of grabbing the lower fees that would go for the miner which accepts them.
On the other hand, there aren't much incentives to accept "feeless" transactions... today, as the client doesn't give you the option to add a fee to each transaction, custom miners have a strong incentive to accept such feeless transactions because otherwise they would be screwing the whole bitcoin network, what end up being bad for themselves. But as soon as there is a client that allows the user to specify how much to pay on fees, I don't see why accepting feeless transactions.


More significantly, there ought to be a network-wide fee policy that is consistent across the network for a great many reasons

No, there ought not.
I am strongly against such thing.
What you are suggesting is price fixing. The whole bitcoin idea is to have sound money, government-proof. If that's what we want to create, how come we are going to try to fix prices on the protocol itself? That's contradictory with the sound economic principles behind Bitcoin.


Arbitrary policies seem to be even more chaotic if every single miner has a completely different policy for fees.

You sound like those people who want to prevent merchants from proposing very different prices, otherwise is too "chaotic".

Producing a block and storing transactions in it is a service somebody is performing for bitcoin users. It's up to s/he to choose how much to charge.
And anyway, think about it, there is a strong incentive for accepting any transaction with any positive transaction fee in it. Otherwise you'll just be letting it to the next guy who is less restrictive than you.

This is also my same complaint about the current limit on transactions less than 0.01 BTC.  Yes, I understand the rationale for this limit, but I think it is going to come back and be a major logical bug to the network as a whole.

This limit is client-based, not protocol-based. I suppose (actually, I hope!) that if a custom miner accepts transactions of less than 0,01 BTC, the default client won't reject those blocks. It's just that the miner that comes with the default client has this policy of charging 0,01 fee for <0,01 transactions.

So, this is not a problem at all, and can be changed at any moment by those in charge for the client.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: jgarzik on November 19, 2010, 04:59:09 PM
As it stands now, a spammer can flood the network with millions of 0.01 BTC transactions to himself.

Even when this uses up all free TX slots in a block -- thereby DoS'ing honest bitcoin users -- it will continue to use memory and network resources, because the TX's will hang around in RAM on each node, waiting to get added to a block.



Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: FreeMoney on November 19, 2010, 05:39:44 PM
As it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highest [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] > C ?

Maybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] < C to let in about a dozen transactions or so.

Hope that makes a little sense.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: FreeMoney on November 19, 2010, 05:41:43 PM


Here it is suggested that there shouldn't be arbitrary minimums, what is stopping some miner to impose a maximum fee that is essentially confiscatory?  The issue cuts both ways here, and is essentially the same principle.


Other miners.

And if it isn't clear, a miner can only say yes/no to a transactions previously attached fee, he can't take any bite he wants.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: RHorning on November 19, 2010, 09:36:16 PM
In reply to some of RHorning's comments:

Transaction fees should always be determined by the miner. If someone has a high limit, someone will do it cheaper and it will get accepted into a later block.

We need an easy way for people to add transaction fees from the GUI, and we need an easy way for miner's to specific a minimum transaction fee if possible. The later less important than the first.

How do you "shop" for transaction fees under this system?  I guess I'm getting very confused here over how this works.

For example, if a miner gets a successful hash, what stops them from "charging" a 95% transaction fee?  What keeps those transactions from getting incorporated into the block and recognized by the network?

Is there a way for you to say "I don't want to pay this fee" and "shop" for a miner that charges smaller fees by simply waiting?

It also sets up an interesting DOS attack where potentially a miner with a large bank of computers could charge very high transaction fees, slowing down or even potentially stopping trades.  I guess the way to stop that would be to get a bunch of computers for yourself and hope you can squeeze in a successful hash at least for yourself to get your transactions put into the network without a fee (presuming you can be selective on the fees for your friends and own addresses).

Is this something that could be put into the user interface, where you can "select" what fees you would be willing to pay?


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: jgarzik on November 19, 2010, 09:37:47 PM
It also sets up an interesting DOS attack where potentially a miner with a large bank of computers could charge very high transaction fees, slowing down or even potentially stopping trades.  I guess the way to stop that would be to get a bunch of computers for yourself and hope you can squeeze in a successful hash at least for yourself to get your transactions put into the network without a fee (presuming you can be selective on the fees for your friends and own addresses).

Well, you can do all sorts of stuff if you have >50% of network CPU power.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: RHorning on November 19, 2010, 09:50:27 PM
It also sets up an interesting DOS attack where potentially a miner with a large bank of computers could charge very high transaction fees, slowing down or even potentially stopping trades.  I guess the way to stop that would be to get a bunch of computers for yourself and hope you can squeeze in a successful hash at least for yourself to get your transactions put into the network without a fee (presuming you can be selective on the fees for your friends and own addresses).

Well, you can do all sorts of stuff if you have >50% of network CPU power.

This wouldn't even require 50% of the network CPU power.  20% would be enough to "slow the network down" with a significant degrading of service and ramp up the difficulty for the rest of the network considerably.  Then again, you would be a fool to pass up on potential transaction fees simply by only accepting transactions that would permit a high fee or an impossible fee.

My understanding of this is really muddled and I'm not not really sure how the fees are decided or what happens when you type in an address, an amount, and try send some bitcoins to somebody.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: RHorning on November 20, 2010, 01:47:29 AM

My understanding of this is really muddled and I'm not not really sure how the fees are decided or what happens when you type in an address, an amount, and try send some bitcoins to somebody.

RH, read my reply, I discussed how that works. If it isn't clear, LMK and I'll try again to simplify it.

Correct me if I'm wrong here:  When you send out the data for a transaction, you also send out some coins for a "fee" (which could be zero) that may or may not be accepted by a miner.  If it is accepted, the miner processes the transaction, keeps the fee, and the transaction is adopted into the network.  If the fee isn't sufficient, the transaction is rejected and not incorporated into that block.

The default reference implementation doesn't necessarily require fees except for transactions less than 0.01 BTC at the moment, which is perhaps where our lines of communication are getting fouled up.  This represents the "typical" acceptance of new blocks into the network, but individual miners can choose their own policies and perhaps even be as selective or indiscriminate of whatever transactions have been forwarded.

It is an interesting aspect of Bitcoins and needs to be documented elsewhere.  I'll see what I can do on that end.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: theymos on November 20, 2010, 02:04:46 AM
It is an interesting aspect of Bitcoins and needs to be documented elsewhere.  I'll see what I can do on that end.

http://www.bitcoin.org/wiki/doku.php?id=transaction_fee


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: RHorning on November 20, 2010, 05:54:10 AM
It is an interesting aspect of Bitcoins and needs to be documented elsewhere.  I'll see what I can do on that end.

http://www.bitcoin.org/wiki/doku.php?id=transaction_fee

I'll work on it.  for instance:

Quote
Whoever sends the transaction knows in advance that they're going to have to pay a transaction fee because the rules about this are shared among all Bitcoin users.

This statement from the documentation is simply incorrect.  When you sen transactions, you don't know in advance that "they're going to have to pay a transaction fee" or even how much it might be.  It is a guess, and as mentioned here on this thread the rules about this are not "shared among all Bitcoin users".  It may not even be most Bitcoin users that share any given transaction fee philosophy.

Yeah, it is a wiki.  I can change that and rework that sentence and fix other documentation there, but I am saying that the network rules on this issue are as clear as mud and the only documentation about it is the source code of the reference application, and even that isn't really all that clear.  This thread is to me clearing that up considerably, and I thank those who are at least trying to be patient with me on it.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: theymos on November 20, 2010, 06:30:04 AM
This statement from the documentation is simply incorrect.  When you sen transactions, you don't know in advance that "they're going to have to pay a transaction fee" or even how much it might be.

When I wrote that there were no custom miners and only one set of rules. I updated it:
Quote
Whoever sends the transaction is often able to guess what the appropriate fee will be based on their own fee rules. If Bitcoin believes the fee will be non-zero, it will not allow you to send the transaction without the calculated fee.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: nightrow on November 20, 2010, 10:31:07 AM
One small question about transaction fee after reading what you wrote:
What is going to happen to a transaction send with a 0.1 fee for example if every miner require a 0.2 fee ? Is it going to timeout, or will it wait forever ?


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: lfm on November 20, 2010, 03:12:06 PM
For fees to be reasonable you should figure out your costs first and adjust your fee correspondingly. Currently the whole .bitcoin directory tree seems to be about 227mb (on one of my machines). I recently got a 1tb drive for about $50 so the bitcoin database including log files and all costs me about $0.01135. Current BTC are worth about $0.25 so this disk space costs about 0.0028375 BTC

So if you generate even one block and get NO fees, just the 50BTC standard reward you have paid for a LOT of disk space.
Take 0.01 BTC out of that for disk space and the other 49.99 BTC to pay for the electricity and depreciation on your system and whatever other expenses you have and decide if it is worthwhile for you to try for another block.

If not then QUIT!

You DO NOT need to run a node to play with bitcoin. There are services such as mybitcoin.com that will allow you to keep track of your coins for free! (just the cost of your internet connection).

I don't think we need to worry about free transactions for a long time yet. Not even the spam/spew transactions.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: RHorning on November 20, 2010, 03:59:48 PM
One small question about transaction fee after reading what you wrote:
What is going to happen to a transaction send with a 0.1 fee for example if every miner require a 0.2 fee ? Is it going to timeout, or will it wait forever ?

A couple of points:

Not every miner is going to expect a given fee.  This is sort of an auction market where miners are free to choose any fee that they desire.  This is the reason there has been resistance on this thread to impose any hard rules on the network and in particular the miners.  Thinking it through, I think that is on the whole a good idea.  The possibility exists that rules could be enforced on fees in terms of what blocks get accepted into the network, but what is being said here is that the miner is the one that ultimately decides to accept the block.

BTW, I agree with the principle that miners should be completely free to accept or reject transactions, and would go so far as to say that there shouldn't be any restriction in the network on those blocks for this purpose.  I know this contradicts what I've written earlier, but I guess I'm convinced now that this is the best way.  To me, it is an issue of freedom, and one where a market approach fixes potential problems.  For those who posted earlier, I'm sold!

Into this market place, there is going to be some sort of competition to collect transaction in order to "earn" the transaction fees.  There may be some users who want to try and push the fees to higher levels, so they will be rejecting a transaction that includes a 0.1 fee (to use your example).  However, either through altruism (they just want to be nice to newbies and paupers) or perhaps they are being simply greedy (they want to collect every last possible coin, no matter how little) there will end up being somebody somewhere that will eventually process the transaction.

I'm sort of curious if somebody would include a 0.000001 BTC fee in a microtransaction of < 0.01 BTC, how many miners would process that transaction?  This isn't theoretical, as the current "default" network already rejects these sort of transactions, so it would be up to a new miner that would have to accept these sort of transaction.  Apparently there have been a few miners who are processing all transactions right now.

As the intrinsic value of Bitcoins increases (which seems to be a general trend and strong reason to believe it will continue), the desire to accept minor transactions will increase.  That sounds like a strong limiting factor on the maximum fee that on average a typical bitcoin user will have to pay in order to get a transaction into a block.  You may have to wait a bit longer, but it shouldn't be too long of a wait.  You trade off transaction fees for speed of processing, where a higher transaction fee will be more likely to be accepted.  There certainly will be times where the timeliness of getting the transaction processed is critical, so there are valid reasons for a person making the transaction to want to pay a higher fee from time to time too.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: andrewegc on December 08, 2010, 03:19:51 AM
I just created an account to comment on spam and the connection with fee's.  This seems to be a serious theoretical problem with the current implementation, because it will lead to runaway disk space usage.  And I hope someone can counter my ideas with an explanation or help brainstorm a solution.

Supposedly the market will introduce fees which will curtail spam.  The problem is that there is no real market force to increase fees that I can see.  There is no personal incentive for a given node to charge fees because they only stand to miss out on the fee's that fall below their fee threshold.

It's a "tragedy of the commons". Sure it would benefit the community as a whole to charge fee's, but who's gonna be the first one to increase their fee when they only stand lose potential fee income by doing that.

My understanding is that it costs you nothing extra to perform the block hash search with many low- or no- fee transactions included, but you stand to gain a small profit by including even the extremely low fee transactions.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: lfm on December 08, 2010, 03:59:06 AM
I just created an account to comment on spam and the connection with fee's.  This seems to be a serious theoretical problem with the current implementation, because it will lead to runaway disk space usage.  And I hope someone can counter my ideas with an explanation or help brainstorm a solution.

"runaway disk space" seems like an exaggeration to me. The most free "spam" anyone can send currently is 50kB per block. Anyone who want priority over the spam can send a fee. No matter how small the fee it will give those transactions priority over the spam. I figure 0.01 btc would currently pay for about 50MB of disk space. Do you still think we need to worry?



Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: RHorning on December 08, 2010, 03:55:21 PM
Supposedly the market will introduce fees which will curtail spam.  The problem is that there is no real market force to increase fees that I can see.  There is no personal incentive for a given node to charge fees because they only stand to miss out on the fee's that fall below their fee threshold.

It's a "tragedy of the commons". Sure it would benefit the community as a whole to charge fee's, but who's gonna be the first one to increase their fee when they only stand lose potential fee income by doing that.

There are two things that are going to drive fees in the future even if that isn't an issue at the moment:  CPU bandwidth and disk storage costs.

Simply put, running your computer is going to cost you money, as will storing all of the data.  Eventually there will be people dropping out of the mining business because the chance of getting a block is going to be very low.  I think this is happening even now.

One thing that might induce more people to jump back in is to start demanding fees for transactions, and for that matter all transactions.  It is something I'd love to see put into the current client sooner than later, where each person could start demanding fees for transactions.  Satoshi is trying to put forward an idea of some "charity" transaction where at least a few "free" transactions get put in every once in awhile, but presumably there will eventually be a huge backlog on such transactions.

It mainly is a matter of putting this into the interface where people can start selecting a fee they are expecting.  I realize that there are some who have suggested any sort of transaction with even the smallest fee will be accepted, but I am suggesting that eventually those who are accepting the smaller transactions will likely be "driven from the marketplace" when the number of transactions starts to be very large.  At the moment the issue is mainly that the number of transactions per block is quite small and therefore including any transaction at all is useful.


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: casascius on December 14, 2010, 04:24:39 PM
If there is a 50 kb limit per block, what does that mean when legitimate (non-spam) transaction volume reaches that amount?  If each transaction averages 270 bytes, that's less than 200 transactions... and if there's guaranteed to exist only a block every few minutes, wouldn't that mean the whole BitCoin network as a whole cannot sustainably commit an average of more than 200 transactions every few minutes?


Title: Re: Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)
Post by: MoonShadow on December 14, 2010, 08:40:07 PM
If there is a 50 kb limit per block, what does that mean when legitimate (non-spam) transaction volume reaches that amount?


Free transactions must wait for another block.  Spamming only consumes space in the block reserved for free transactions, fee paying transactions have space (at increasing fee levels) up to 1 meg at this time.  The 1 meg limit is a hard limit, but much discussion about replacing the hard limit with a more flexible rule has already occurred on this forum.

Quote

 If each transaction averages 270 bytes, that's less than 200 transactions... and if there's guaranteed to exist only a block every few minutes, wouldn't that mean the whole BitCoin network as a whole cannot sustainably commit an average of more than 200 transactions every few minutes?

I believe that the network can sustain a level of about 470 transactions per minute at this time, due to the hard limit.  We know that this is not enough,but these are changable rules.