Recent floods by MrBurns (17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne)

[ByteCoin]

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

[1714476305]

1714476305

[1714476305]

1714476305

[FreeMoney]

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.

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

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

[m0mchil]

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.

[jgarzik]

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.

[caveden]

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

[m0mchil]

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.

[sturle]

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.

[joe]

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.

[caveden]

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.

[wumpus]

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?

[RHorning]

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.

[RHorning]

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.

[caveden]

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.

[jgarzik]

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.

[FreeMoney]

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.

[FreeMoney]

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.

[RHorning]

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?

[jgarzik]

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.

[RHorning]

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.