Spam attack and miners choice of transactions

[SebastianJu]

Hello,

i wanted to ask how miners chose the transactions to be implemented. I mean the spam transactions are huge. Yes, the standard is to pay per kb, but are the huge transactions really paying so well for their size?

I mean, when a miner sees a small transaction paying 0.00001 btc and a huge transaction paying 0.0001 Bitcoin. Then he choses the huge transaction even when the huge one is 100 times bigger than the small transaction? Or is there some logic implemented?

At the end the small transactions might bring in more fees in total.

Additionally, accepting these huge blocks is lowering the propagation time of that block. Which leads to some blocks found being orphaned by faster 1 transaction blocks.

Maybe its already implemented that way. I was only wondering if the spam couldnt be handled on that way.

Greetings!

[1714876532]

1714876532

[1714876532]

1714876532

[gmaxwell]

Because the size of a block is limited, the approriate stratey (ignoring transaction dependencies) for miners to use is to order transactions by fees per byte and select in that order.

This is what Bitcoin Core already does.

[jbrnt]

Because the size of a block is limited, the approriate stratey (ignoring transaction dependencies) for miners to use is to order transactions by fees per byte and select in that order.
This is what Bitcoin Core already does.

When 2 or more transactions different in size, one 500 bytes and another one 5k, have the exactly the same fee per byte. Would miners prefer to include the small one and ignore the huge one? Or they will also be ranked by priorty?

Are these rules the same across most miners (following Core) or they all have their different selection criteria?

[SebastianJu]

Because the size of a block is limited, the approriate stratey (ignoring transaction dependencies) for miners to use is to order transactions by fees per byte and select in that order.

This is what Bitcoin Core already does.

Ok. Then all the small normal fees have less fees combined than the huge spam transactions.

Then i have another question. I know that was suggested already but i didnt read why it did not get implemented. Why does one transaction containing many transactions pay a much lower fee per transaction than a normal transaction? I mean bitcoin seems to me the only currency where you can send transactions in bulk and pay less. There is no currency that has such a thing.

When you compare it to sending out letters then it doesnt matter if you bring a big box with hundreds of letters to the post office. You still have to pay the price for each letter, regardless of you bringing it in a huge box. You might send all letters in a package but then you can only use one target.

The usecases for such transactions are limited and it doesnt seem very logical to me that such transactions have to pay less fees.

What is the reason behind? I mean we could stop the spamming with that. And it would be, in my opinion, a more normal behaviour of a currency. No normal person will use such transactions regularly, maximum 2 transactions with one transaction including change. So at the end the only one in favor are companies. And they would not need that favor.

Can you explain why this didnt get implemented?

[-ck]

It is up to the pool operator to decide how to prioritise its transactions. For pools that filter transactions according to some arbitrary rules, personal beliefs of the pool operator that makes them use blacklists, and not scalable software, they implement their own choices for how to build blocks and often build 1 transaction blocks to cope with their lack of scalable pool code on block changes before starting again with transaction filled blocks later which is doing the network a real disservice in these times of massive amounts of transactions on the network. For other pools (like all the ckpool based ones) we use the default bitcoind transaction rules which means that we're generating generous large blocks with many of these transactions - and the difference in fee is substantial with many block rewards having 1-2% of the reward from fee which is quite significant. The default bitcoind rules mean that basically the longer the time is between blocks, the higher the transaction fee reward is - and it adds up to quite a lot. Use of matt's relaynode means that block propagation doesn't appear to be hindered to the point of being orphaned even if it is larger. The reality is two pools finding blocks within a short time frame is still uncommon.

[SebastianJu]

It is up to the pool operator to decide how to prioritise its transactions. For pools that filter transactions according to some arbitrary rules, personal beliefs of the pool operator that makes them use blacklists, and not scalable software, they implement their own choices for how to build blocks and often build 1 transaction blocks to cope with their lack of scalable pool code on block changes before starting again with transaction filled blocks later which is doing the network a real disservice in these times of massive amounts of transactions on the network. For other pools (like all the ckpool based ones) we use the default bitcoind transaction rules which means that we're generating generous large blocks with many of these transactions - and the difference in fee is substantial with many block rewards having 1-2% of the reward from fee which is quite significant. The default bitcoind rules mean that basically the longer the time is between blocks, the higher the transaction fee reward is - and it adds up to quite a lot. Use of matt's relaynode means that block propagation doesn't appear to be hindered to the point of being orphaned even if it is larger. The reality is two pools finding blocks within a short time frame is still uncommon.

I know miners can decide. Though the standard setting is mighty since i think that not many miners will go the way to custom code something for them.

When i would be a miner and somehow could get the code to do so then i would SPV mine, would verify the previous block in the meanwhile, would start with 1 transaction block and would check transactions too in the meanwhile. Then i would implement only exceptional good transactions, i mean high fee per byte.

I would do so because i would have an advantage against other miners. The protocol allows this and developers should always assume that something that can be exploited, will be exploited.

Your mentioning of matts relaynode... is it similar to my suggestion on here? https://bitcointalk.org/index.php?topic=1130555.0 The first paragraph:

So the empty blocks, or 1 transaction blocks, happen because a so small block will be propagated very fast through the nodes. Means 1 MB blocks might have a hard time reaching >50% and might get orphaned often.

When we now get 20MB blocks at one point, shouldnt the problem worsen then? I mean i can imagine the incentive to mine 1 transaction blocks will be even higher because the p2p speed wont keep up with that i think.

* Wont this be a problem?

Maybe a solution is to spread headers first, so some data identifying a found block. These headers are spread through all nodes in light time. The blocks follow later and can be verified. A one transaction block verified faster gets still orphaned when a 20 MB block gets verified later. That would ensure that empty blocks are not worth it.

There would need to be a timeout. Spreading faked headers wouldnt help because they would need to match a found block.

I think the 1 transaction problem will only get worse the bigger the block will become. And as far as i read... Mining 1 transaction blocks gives you a 1% advantage profit wise over normal miners.

And i still wonder why bitcoin is handling multiple transactions with multiple target addresses so much different than any other payment system and even some altcoins. Is there a good reason behind?

PS: Your post is really hard to read in the blockform you posted it. And very long sentences. I nearly stopped reading when it wouldnt be an answer to myself.

[-ck]

There is a thread discussing use of empty blocks to try and speed up block change propagation for its miners:
https://bitcointalk.org/index.php?topic=1085800.0

Kano did a comparison of ckpool using full transaction block changes vs a prominent pool that does the 1 transaction block change you mention and the block change speed was always propagated faster with a well tuned bitcoind and good pool software and full transactions. The 1 transaction block you speak of is a workaround for a poor set up and less scalable pool software. It is within that same thread above, the specific post is:
https://bitcointalk.org/index.php?topic=1085800.msg11847437#msg11847437

Saying miners won't use custom code for bitcoind is naive given that most pools run all their own code. The "miners" you speak of these days are 99% mining on prominent pools and every single successful pool out there has coders modifying bitcoind or are not even using bitcoind. p2pool miners who are the only non "pooled-miners" constitute less than 0.5% of the network now as "individual miners" and even then, they are mostly modifying their default bitcoind settings.

Matt's relaynode is nothing to do with mining transaction fee blocks. It is exactly the opposite - it is designed to propagate blocks across the world as fast as possible irrespective of the amount of transactions.
See https://blog.bitcoinfoundation.org/a-bitcoin-backbone/ and http://bitcoinrelaynetwork.org/

If you're saying that mining 1 transaction blocks is going to be faster even with all of the above, the answer is generically yes. However, transactions and transaction fee incentive are the cornerstone of bitcoin and mining and some of us pool operators believe every effort should be made to make managing this as fast as possible while transmitting as many transactions as possible the key to good pooled mining. We have shown that you can do this without detriment, and long term when fees become the bulk of the reward it will become essential.

I see no evidence anywhere of this alleged 1% advantage to empty block mining. The next halving is only a year away, and with fees being 1-2% now in great transaction floods, that will rise to be up to 5% which is far from insignificant. Add to that the possible rise in max blocksize...

[SebastianJu]

There is a thread discussing use of empty blocks to try and speed up block change propagation for its miners:
https://bitcointalk.org/index.php?topic=1085800.0

Kano did a comparison of ckpool using full transaction block changes vs a prominent pool that does the 1 transaction block change you mention and the block change speed was always propagated faster with a well tuned bitcoind and good pool software and full transactions. The 1 transaction block you speak of is a workaround for a poor set up and less scalable pool software. It is within that same thread above, the specific post is:
https://bitcointalk.org/index.php?topic=1085800.msg11847437#msg11847437

Saying miners won't use custom code for bitcoind is naive given that most pools run all their own code. The "miners" you speak of these days are 99% mining on prominent pools and every single successful pool out there has coders modifying bitcoind or are not even using bitcoind. p2pool miners who are the only non "pooled-miners" constitute less than 0.5% of the network now as "individual miners" and even then, they are mostly modifying their default bitcoind settings.

Matt's relaynode is nothing to do with mining transaction fee blocks. It is exactly the opposite - it is designed to propagate blocks across the world as fast as possible irrespective of the amount of transactions.
See https://blog.bitcoinfoundation.org/a-bitcoin-backbone/ and http://bitcoinrelaynetwork.org/

If you're saying that mining 1 transaction blocks is going to be faster even with all of the above, the answer is generically yes. However, transactions and transaction fee incentive are the cornerstone of bitcoin and mining and some of us pool operators believe every effort should be made to make managing this as fast as possible while transmitting as many transactions as possible the key to good pooled mining. We have shown that you can do this without detriment, and long term when fees become the bulk of the reward it will become essential.

I see no evidence anywhere of this alleged 1% advantage to empty block mining. The next halving is only a year away, and with fees being 1-2% now in great transaction floods, that will rise to be up to 5% which is far from insignificant. Add to that the possible rise in max blocksize...

Thank you for your answer. You probably are right. The halving will work against it even though the real blocksize will work for the development of 1 transaction blocks.

300ms Propagation of Matts Relaynode sounds impressive. Is that the speed until you get >50%? I wonder what happens when the blocks will be 10 times bigger. Sure, the halving will have happened but the fees will probably still be a small part of the reward. Matts Relaynode then might have, in the worst case a 3 second propagation time. Thats still not much compared to bitcoins average time for found blocks.

I think i maybe overestimated the problem. Thanks for explaining.

Can someone explain my second question too?

Then i have another question. I know that was suggested already but i didnt read why it did not get implemented. Why does one transaction containing many transactions pay a much lower fee per transaction than a normal transaction? I mean bitcoin seems to me the only currency where you can send transactions in bulk and pay less. There is no currency that has such a thing.

When you compare it to sending out letters then it doesnt matter if you bring a big box with hundreds of letters to the post office. You still have to pay the price for each letter, regardless of you bringing it in a huge box. You might send all letters in a package but then you can only use one target.

The usecases for such transactions are limited and it doesnt seem very logical to me that such transactions have to pay less fees.

What is the reason behind? I mean we could stop the spamming with that. And it would be, in my opinion, a more normal behaviour of a currency. No normal person will use such transactions regularly, maximum 2 transactions with one transaction including change. So at the end the only one in favor are companies. And they would not need that favor.

Can you explain why this didnt get implemented?

[arnuschky]

Then i have another question. I know that was suggested already but i didnt read why it did not get implemented. Why does one transaction containing many transactions pay a much lower fee per transaction than a normal transaction? I mean bitcoin seems to me the only currency where you can send transactions in bulk and pay less. There is no currency that has such a thing.

When you compare it to sending out letters then it doesnt matter if you bring a big box with hundreds of letters to the post office. You still have to pay the price for each letter, regardless of you bringing it in a huge box. You might send all letters in a package but then you can only use one target.

The usecases for such transactions are limited and it doesnt seem very logical to me that such transactions have to pay less fees.

What is the reason behind? I mean we could stop the spamming with that. And it would be, in my opinion, a more normal behaviour of a currency. No normal person will use such transactions regularly, maximum 2 transactions with one transaction including change. So at the end the only one in favor are companies. And they would not need that favor.

Can you explain why this didnt get implemented?

Quite unclear about what you are asking. What didn't get implemented? What is cheaper? A transaction cannot "contain" a transaction. What you mean is possible a more complex transaction that contains more outputs, no?

To clarify: It's not cheaper to send larger transactions (and there is no such thing as "bulk" sending transactions). You simply pay by size, period. Your transaction is bigger, you use up more space in a block and therefore you pay more. The fee market is meant to be exactly that: a market where transactions compete for space in a block. Of course the smaller ones are cheaper than the bigger ones, as they use less of the scarce resource (bytes).

[SebastianJu]

Then i have another question. I know that was suggested already but i didnt read why it did not get implemented. Why does one transaction containing many transactions pay a much lower fee per transaction than a normal transaction? I mean bitcoin seems to me the only currency where you can send transactions in bulk and pay less. There is no currency that has such a thing.

When you compare it to sending out letters then it doesnt matter if you bring a big box with hundreds of letters to the post office. You still have to pay the price for each letter, regardless of you bringing it in a huge box. You might send all letters in a package but then you can only use one target.

The usecases for such transactions are limited and it doesnt seem very logical to me that such transactions have to pay less fees.

What is the reason behind? I mean we could stop the spamming with that. And it would be, in my opinion, a more normal behaviour of a currency. No normal person will use such transactions regularly, maximum 2 transactions with one transaction including change. So at the end the only one in favor are companies. And they would not need that favor.

Can you explain why this didnt get implemented?

Quite unclear about what you are asking. What didn't get implemented? What is cheaper? A transaction cannot "contain" a transaction. What you mean is possible a more complex transaction that contains more outputs, no?

To clarify: It's not cheaper to send larger transactions (and there is no such thing as "bulk" sending transactions). You simply pay by size, period. Your transaction is bigger, you use up more space in a block and therefore you pay more. The fee market is meant to be exactly that: a market where transactions compete for space in a block. Of course the smaller ones are cheaper than the bigger ones, as they use less of the scarce resource (bytes).

Im sorry about being unclear. I will describe again.

Litecoin has a spam protection included that lets users pay a fee by output not only by size of the transaction, age of coins and size of amount. That effectively prevents spam.

My question is why that wasnt implemented into the bitcoin network. It could prevent the currently ongoing spam, which seems to be done often and shortly. I suspect they try to find out how to maximize fees in the network with making bitcoiners fear that their transaction wont go through since a spam attack might happen in the next minute. So fear leads to everyone raising fees. Doing the attack randomly ensures fear. Thats why i asked about that type of fee.

If you see the fee as competing for space in the block then this is not a good way to handle it. Clearly the space in the block would be too cheap. And the fee is already that high that it cant be really a replacement for fiat. You cant spend small amounts like $0.01 because the fee is way higher than that, for example. And i believe that is a usecase that needs to be possible. At least i interprete satoshi the way that he wanted to provide a way to avoid banks. Bitcoin as a high payment system surely would not be this.

Thats why i came up with the example of letters. You cant send hundred of letters in one letter and await to reach different targets that way. The same goes for any other payment system. But bitcoin favors this behaviour for some reason i dont see.

I would want to know the reason that was not implemented yet.

[amaclin]

My question is why that wasnt implemented into the bitcoin network.

Who should implement things which break consensus rules? And how?

[SebastianJu]

My question is why that wasnt implemented into the bitcoin network.

Who should implement things which break consensus rules? And how?

I don't understand what you mean with breaking consensus rules. Isn't any fork breaking the consensus rules that were valid previously? So a simple fork can happen and things be dealt differently from now on. I don't see that there would be many complaining about charging fees per output. Only a small group of companies have an advantage from that. And spammers... at least with small blocksizelimit and intelligent timing in order to drop costs for spamming and spreading fear that using a lower fee will let the transaction be stuck.

[amaclin]

I don't understand what you mean with breaking consensus rules.
Isn't any fork breaking the consensus rules that were valid previously?

Yes. Fork(split) is the result of new rules.
Your question was:

My question is why that wasnt implemented into the bitcoin network.

And I am asking: who should implement any ideas?
Me? No, I do not want to do it at least for free.
May be Barack Obama? I doubt.
May be Gavin Andressen? Why should he implement your ideas?
Or may be you? So, ask yourself.

[dexX7]

Litecoin has a spam protection included that lets users pay a fee by output not only by size of the transaction, age of coins and size of amount. That effectively prevents spam.

My question is why that wasnt implemented into the bitcoin network. It could prevent the currently ongoing spam, which seems to be done often and shortly.

Hey Sabastian, you are probably referring to:

https://github.com/bitcoin/bitcoin/pull/1536

The logic behind Litecoin's solution: lowish outputs are penalized and each lowish output implies a higher transaction fee.

In retrospective it looks like it was superseded by a related solution:

The minimum values of outputs depend on the size of the outputs. It should not be uneconomic to spend outputs, and the larger the size of an output, the higher the minimum value shall be.

In practise: consider you receive a very low amount, let's say 1 satoshi, then it would cost you more to spend that value than it's actually worth. To prevent that the chain fills up with outputs, which probably won't get spent, the "dust" threshold was introduced:

https://github.com/bitcoin/bitcoin/pull/2577

There was recently a discussion on Reddit about the topic, which may provide some more insights:

https://www.reddit.com/r/Bitcoin/comments/3ci25k/the_current_spam_attack_on_bitcoin_is_not/csvtt8l

My question is why that wasnt implemented into the bitcoin network.

Who should implement things which break consensus rules? And how?

Output value and transaction fee policies don't break consensus.

[SebastianJu]

I don't understand what you mean with breaking consensus rules.
Isn't any fork breaking the consensus rules that were valid previously?

Yes. Fork(split) is the result of new rules.
Your question was:

My question is why that wasnt implemented into the bitcoin network.

And I am asking: who should implement any ideas?
Me? No, I do not want to do it at least for free.
May be Barack Obama? I doubt.
May be Gavin Andressen? Why should he implement your ideas?
Or may be you? So, ask yourself.

Who should implement? The same who implement all new things. I think if the community would donate for the development of this particular item then developers might implement it. I mean it's not like developers are the allmighty gods that rule about what has to be implemented and what not.

And i think crowdfunding that would be working since the spammer angried a lot bitcoiners. And it's an easy solution.

[SebastianJu]

Litecoin has a spam protection included that lets users pay a fee by output not only by size of the transaction, age of coins and size of amount. That effectively prevents spam.

My question is why that wasnt implemented into the bitcoin network. It could prevent the currently ongoing spam, which seems to be done often and shortly.

Hey Sabastian, you are probably referring to:

https://github.com/bitcoin/bitcoin/pull/1536

The logic behind Litecoin's solution: lowish outputs are penalized and each lowish output implies a higher transaction fee.

In retrospective it looks like it was superseded by a related solution:

The minimum values of outputs depend on the size of the outputs. It should not be uneconomic to spend outputs, and the larger the size of an output, the higher the minimum value shall be.

In practise: consider you receive a very low amount, let's say 1 satoshi, then it would cost you more to spend that value than it's actually worth. To prevent that the chain fills up with outputs, which probably won't get spent, the "dust" threshold was introduced:

https://github.com/bitcoin/bitcoin/pull/2577

There was recently a discussion on Reddit about the topic, which may provide some more insights:

https://www.reddit.com/r/Bitcoin/comments/3ci25k/the_current_spam_attack_on_bitcoin_is_not/csvtt8l

My question is why that wasnt implemented into the bitcoin network.

Who should implement things which break consensus rules? And how?

Output value and transaction fee policies don't break consensus.

Thanks dexX7. I have read that. I'm not so sure anymore if the litecoin implementation or what bitcoin implemented is the same like i imagined. And on top i wonder if i wasn't completely wrong from the start.

What i thought is:

When normal users do a transaction then they mostly have a transaction that has one input and 2 outputs. It doesn't matter if one of the outputs goes to a change address or to the input address again.

Normal users have to pay a fee for that.

Now it's possible to create multiple transactions in one transaction. Lets say someone sends coins to 20 output addresses including the change address. That means in fact he has 10 times as many transactions done. Of course it might be that he only has one input address, so that transaction might be smaller than 10 individual transactions.

But lets assume this one big transaction is as big as the 10 transactions.

So what i wonder now is, the miners check for the fee satoshi per byte and chose the transactions accordingly. Then if we assume that 10 transactions are the same size like 1 of this big transactions then would both have to pay the same fee to have the same priority or has the big transaction an advantage?