There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.
I think OP means that transactions don't get confirmed this way.
Topic: Again, a block with 0 transactions is accepted - page 4. (Read 4410 times)
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.
I think OP means that transactions don't get confirmed this way.
OK, that's true.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
I think OP means that transactions don't get confirmed this way.
Sure, if zero transaction blocks are all we have.
I think OP means that transactions don't get confirmed this way.
Sure, if zero transaction blocks are all we have.
While this miner is not adding transactions in his block, there will be times where there will be no TXes to add in a block and I am talking about edge-cases where a block is found seconds after another. Will you also reject those?
Yes.
I repeat: bitcoin is about transactions; so, no transaction should mean automatic rejection.
Perhaps this must be hardcoded in incoming releases of the client.
No hang on, bitcoin includes the ability to pass signed cryptograms for trust certification purposes. I don't think you're going to find that functionality separable from transaction processing... no?
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.
I think OP means that transactions don't get confirmed this way. 
These blocks are becoming too often...
https://blockchain.info/block-index/387154/00000000000000cf950f6997b14b4dc361ec59742d379e4439fc85fad6c9e10d
so 1 data point is enough for you to conclude it's "too often?" https://blockchain.info/block-index/387154/00000000000000cf950f6997b14b4dc361ec59742d379e4439fc85fad6c9e10d
There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
These blocks are becoming too often...
https://blockchain.info/block-index/387154/00000000000000cf950f6997b14b4dc361ec59742d379e4439fc85fad6c9e10d
The owner of address 1Baf75Ferj6A7AoN565gCQj9kGWbDMHfN9 and the person who generated that block is is the pool Eclipse. https://blockchain.info/block-index/387154/00000000000000cf950f6997b14b4dc361ec59742d379e4439fc85fad6c9e10d
These blocks are becoming too often...
https://blockchain.info/block-index/387154/00000000000000cf950f6997b14b4dc361ec59742d379e4439fc85fad6c9e10d
https://blockchain.info/block-index/387154/00000000000000cf950f6997b14b4dc361ec59742d379e4439fc85fad6c9e10d
See: https://bitcointalksearch.org/topic/m.2277187
That is an example of fair policy I'd take if I rule a pool.
That is an example of fair policy I'd take if I rule a pool.
Then you wouldn't have any miners participating in your pool, because they wouldn't ever get paid.
If you reject a single block, then you will be forced to reject any other blocks that are found by the rest of the network that build on top of that rejected block as well.
Not necessarily. If other miner finds a block, with the unfair block as antecedent, I would continue the chain. Of course.
But if I'm lucky and my pool finds a concurrent block, then I force the network to make a decision on my block or the unfair one.
The only way you could succeed would be to convince more than 50% of the total network hash power to agree with whatever rules you decide to implement.
If only the 3 biggest pools make an agreement on this matter, the problem is solved.
Does this just mean the transaction fees aren't high enough? Shouldn't the fees be such that it's worth the overhead to include them in a block?
the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.This makes sense... a good reason to hardcode rejection of 0-transaction blocks.
And again, it would be a useless effort.
"Effort" is too strong. It's an easy countermeasure that costs nothing. Easy points should be scored.
The Botnet would then just create transactions sending back and forth between two addresses that the botnet owns. It wouldn't need the blockchain to verify the transactions, since it would create them itself.
Without the automatic rejection, you make the life of botnet owner easier.
Does this just mean the transaction fees aren't high enough? Shouldn't the fees be such that it's worth the overhead to include them in a block?
the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.This makes sense... a good reason to hardcode rejection of 0-transaction blocks.
And again, it would be a useless effort. The Botnet would then just create transactions sending back and forth between two addresses that the botnet owns. It wouldn't need the blockchain to verify the transactions, since it would create them itself.
Does this just mean the transaction fees aren't high enough? Shouldn't the fees be such that it's worth the overhead to include them in a block?
the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.This makes sense... a good reason to hardcode rejection of 0-transaction blocks.
See: https://bitcointalksearch.org/topic/m.2277187
That is an example of fair policy I'd take if I rule a pool.
That is an example of fair policy I'd take if I rule a pool.
Then you wouldn't have any miners participating in your pool, because they wouldn't ever get paid.
If you reject a single block, then you will be forced to reject any other blocks that are found by the rest of the network that build on top of that rejected block as well.
Then, any block your pool attempts to submit would be rejected by the rest of the network, because your blockchain would be "shorter" than the generally recognized one (since it would be missing all the blocks that they've already accepted.
The only way you could succeed would be to convince more than 50% of the total network hash power to agree with whatever rules you decide to implement.
the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.
Ah I've always wondered about those bitcoin botnets and how many computers they have working for them. (And what percentage of compromised computers actually have a decent hash rate)
Does this just mean the transaction fees aren't high enough? Shouldn't the fees be such that it's worth the overhead to include them in a block?
the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.
Does this just mean the transaction fees aren't high enough? Shouldn't the fees be such that it's worth the overhead to include them in a block?
I repeat: bitcoin is about transactions; so, no transaction should mean automatic rejection.
That's not 100% true. Bitcoin is about securing the blockchain also. Even an empty block confirms previous transactions.
Jump to: