Forgetting the forgetful

[gmaxwell]

Some people have hypothesized the that the recent five-fold increase of the number of 1tx transactions (now about 16% of blocks) is due to a botnet mining without a copy of the blockchain (which might get noticed by the owners of the stolen computing power) and also without using a pool (which creates a central point for tracking the botnet).

I've not seen any real evidence for this, nor do I yet share the concern people have had over it—  

But if this is really the case, we can prevent this kind of behavior:

Take the _inputs_ (not their IDs, the data) to the transactions in the previous block.  Hash them, giving H1.

Take the inputs to the txn you are currently mining, hash them, giving H2.

Take the hash of all your outputs in the coinbase giving H3.

Add to your coinbase H(H(H1||H2)||H3).

Make including this a protocol rule.

Now the botnet can only mine if it had access to verify the transactions in the prior block (and the block its mining).

Every stick needs a little carrot too:

Make every full node also give a getmemorypool style command on the network port which gives out a set of transactions, along with H(H1||H2).  A botnet that wants to mine without having a copy of the blockchain can trust random nodes to provide the proof of memory, but if it does so it must take the exact set of transactions that node provides.

You could go further and commit to random txn in the open set instead of just recent inputs, but that isn't required just to shift the incentives away from memoryless mining.

[1714043866]

1714043866

[1714043866]

1714043866

[MPOE-PR]

Alternatively, let people put enough fees in their transactions so that it becomes economically unfeasible to ignore them. Why fix problems that do not exist?

[finway]

Alternatively, let people put enough fees in their transactions so that it becomes economically unfeasible to ignore them. Why fix problems that do not exist?

It's not about fees, they just don't include txes.

[cunicula]

Hmm.. If a botnet really does have 16%, then doesn't it seem likely that a botnet will someday have 51%? Is an approximate 3 fold increase in currently observed max mining botnet size improbable? If it is probable doesn't that mean alarm bells should be going off in the developers' heads? What is to stop the botnet from holding blockchain info on his own computer and communicating it to the bots via the net? Maybe it isn't a botnet and is just some lone secretive individual or group? Does that really matter. Couldn't his operation plausibly increase by 3-fold too? Are miners of empty blocks trustworthy guys?

[gmaxwell]

Hmm.. If a botnet really does have 16%, then doesn't it seem likely that a botnet will someday have 51%? Is an approximate 3 fold increase in currently observed max mining botnet size improbable? If it is probable doesn't that mean alarm bells should be going off in the developers' heads? What is to stop the botnet from holding blockchain info on his own computer and communicating it to the bots via the net? Maybe it isn't a botnet and is just some lone secretive individual or group? Does that really matter. Couldn't his operation plausibly increase by 3-fold too? Are miners of empty blocks trustworthy guys?

I don't consider botsnets problematic on their face.  Why should I?

"What is to stop the botnet from holding blockchain info on his own computer and communicating it to the bots via the net"

It makes the botnet easier to track, block, discover, and the owner easier to catch.  But if they want to do that great!  

I suspect you're missing the point of my message:  It's arguable that there is an economic incentive to be anti-social: You can avoid the cost of maintaining the blockchain while mining so long as you don't mine any transactions.  We can largely eliminate that misincentive. I don't actually think such a change is required now, I'm just pointing out that we're not helpless.

Alternatively, let people put enough fees in their transactions so that it becomes economically unfeasible to ignore them. Why fix problems that do not exist?

It's not about fees, they just don't include txes.

You actually don't know that— "they" might not even exist.  There could be some bug in popular getmemorypool mining software causing txn to not get mined, for example.  Alternatively, the miner(s) here might happily mine txn with large enough fees.  You're identifying them only on the basis of them not having txn, so if the party in question even exists you'd be intentionally ignoring the blocks where they do mine txn with fees, so you can't say they don't.

[cunicula]

I don't consider botsnets problematic on their face.  Why should I?

Do you consider monopolized mining problematic. If they get 51%, why let others continue to mine?

[Mike Hearn]

If it is a botnet (I share Gregs skepticism) then we'll hear about it soon enough. To get that kind of speed you'd need enough computers that you'll show up in the AV firms radar soon enough.

[finway]

If it is a botnet (I share Gregs skepticism) then we'll hear about it soon enough. To get that kind of speed you'd need enough computers that you'll show up in the AV firms radar soon enough.

Hope it will.

[Maged]

Some people have hypothesized the that the recent five-fold increase of the number of 1tx transactions (now about 16% of blocks) is due to a botnet mining without a copy of the blockchain (which might get noticed by the owners of the stolen computing power) and also without using a pool (which creates a central point for tracking the botnet).

I've not seen any real evidence for this, nor do I yet share the concern people have had over it—  

But if this is really the case, we can prevent this kind of behavior:

Take the _inputs_ (not their IDs, the data) to the transactions in the previous block.  Hash them, giving H1.

Take the inputs to the txn you are currently mining, hash them, giving H2.

Take the hash of all your outputs in the coinbase giving H3.

Add to your coinbase H(H(H1||H2)||H3).

Make including this a protocol rule.

Now the botnet can only mine if it had access to verify the transactions in the prior block (and the block its mining).

Oh! Here's an idea: We could make it so that every block must contain the hash of the previous block, forming a blockchain! It's brilliant!

Sarcasm aside, if they're able to mine valid blocks, they at least have the last block or they trust something else to provide it. Any additional proof that they have the chain is just as meaningless.

[gmaxwell]

.
Oh! Here's an idea: We could make it so that every block must contain the hash of the previous block, forming a blockchain! It's brilliant!
Sarcasm aside, if they're able to mine valid blocks, they at least have the last block or they trust something else to provide it. Any additional proof that they have the chain is just as meaningless.

When someone who is clearly experienced with the system suggests something that sounds pointless I usually assume I've misread the suggestion and try again.  I've found this to be a useful technique. I think it's one you might consider adopting, because we've clearly failed to communicate here.

I'm unsure where I failed on my part: I already emphasized including the _INPUTS_, not the content of the prior block, as the mechanism and that the particular motivation miners who do not have the the set of unspent transaction— creating an incentive to mine no txn, or I'd try to restate it to make it more clear.

[Maged]

I'm unsure where I failed on my part: I already emphasized including the _INPUTS_, not the content of the prior block, as the mechanism and that the particular motivation miners who do not have the the set of unspent transaction— creating an incentive to mine no txn, or I'd try to restate it to make it more clear.

Ah, I see. I missed the inputs part. In that case, let me bring up another point:

Take the inputs to the txn you are currently mining, hash them, giving H2.

What if you aren't mining any transactions (other than the coinbase, which may or may not have an input based on the definition of "input")? What would H2 be?

This does mean that it's easier for botnets to include transactions rather than not, if they want a minimal data footprint, I'll give you that.

[gmaxwell]

I'm unsure where I failed on my part: I already emphasized including the _INPUTS_, not the content of the prior block, as the mechanism and that the particular motivation miners who do not have the the set of unspent transaction— creating an incentive to mine no txn, or I'd try to restate it to make it more clear.

Ah, I see. I missed the inputs part. In that case, let me bring up another point:

Take the inputs to the txn you are currently mining, hash them, giving H2.

What if you aren't mining any transactions (other than the coinbase, which may or may not have an input based on the definition of "input")? What would H2 be?

This does mean that it's easier for botnets to include transactions rather than not, if they want a minimal data footprint, I'll give you that.

An empty string would be fine. It doesn't really matter. The point of H2 is just so it would be easy for people to do the proof-of-memory for you but only so long as you take the transactions they selected. If there aren't any transactions then H2 could be anything, so long as it was standardized.

[theymos]

Couldn't "dumb" miners get all of the necessary data fairly easily and without doing any verification by downloading the latest block and getting the necessary transactions from Bitcoin nodes (with getdata)?

[Maged]

Also, another problem with this: trust. If you don't ultimately trust a node that provides the verification hash, and you have no way of verifying the pending transaction list yourself (if you did, you'd just calculate it yourself), you would logically only use a verification hash that includes no pending transactions. Being the only list that can be independently verified without the blockchain, several nodes/websites would gladly publish it, bringing us back to square one.

Additionally, what's stopping people from just publishing H1? Since H1 will always be the same for everyone, it becomes no different from just asking a node what the last block hash was.

The only way around this that I can think of would be if there was a standard method of selecting transactions for the next block and then making it a block requirement, but for obvious reasons that is a bad idea. (not to mention, it'd also be able to solve the problem on its own and not require this anyway)

[gmaxwell]

Also, another problem with this: trust. If you don't ultimately trust a node that provides the verification hash, and you have no way of verifying the pending transaction list yourself (if you did, you'd just calculate it yourself), you would logically only use a verification hash that includes no pending transactions. Being the only list that can be independently verified without the blockchain, several nodes/websites would gladly publish it, bringing us back to square one.

Additionally, what's stopping people from just publishing H1? Since H1 will always be the same for everyone, it becomes no different from just asking a node what the last block hash was.

The only way around this that I can think of would be if there was a standard method of selecting transactions for the next block and then making it a block requirement, but for obvious reasons that is a bad idea. (not to mention, it'd also be able to solve the problem on its own and not require this anyway)

I don't see why you think people would publish sets that excluded transactions, or why they'd publish H1.   Why would I expend resources to generate tokens so _you_ can mine while DOSing the network?  That would be counterproductive.

Nodes could, in fact, SPV-style validate the transactions— but I doubt they would.

[Meni Rosenfeld]

Also, another problem with this: trust. If you don't ultimately trust a node that provides the verification hash, and you have no way of verifying the pending transaction list yourself (if you did, you'd just calculate it yourself), you would logically only use a verification hash that includes no pending transactions. Being the only list that can be independently verified without the blockchain, several nodes/websites would gladly publish it, bringing us back to square one.

Additionally, what's stopping people from just publishing H1? Since H1 will always be the same for everyone, it becomes no different from just asking a node what the last block hash was.

The only way around this that I can think of would be if there was a standard method of selecting transactions for the next block and then making it a block requirement, but for obvious reasons that is a bad idea. (not to mention, it'd also be able to solve the problem on its own and not require this anyway)

I don't see why you think people would publish sets that excluded transactions, or why they'd publish H1.   Why would I expend resources to generate tokens so _you_ can mine while DOSing the network?  That would be counterproductive.

The miner can pay the node for this service. Going forward running a node will be expensive, node operators will look for ways to monetize it and others will look for nodes offering services to obviate the need to run a node themselves.

Since it's not at all clear that mining tx-free blocks constitutes DoS, there's nothing shady about such an agreement.

[ByteCoin]

Due to the absence of effective fungibility for bitcoins, all bitcoins are traceable back to their coinbase transactions. A taint-tracing service could allow a community of bitcoin users to agree to consider coins created in "empty" blocks to be less valuable than those created in normal blocks.
This would allow for retrospective punishment of the antisocial miner and those unlucky or unwise enough to accept their coins at face value.

ByteCoin

[Maged]

Quick question, what is this proposal really trying to solve? My reply to you, gmaxwell, depends on what you answer to that question. Your answer appears to be "botnets mining without a copy of the blockchain", however, I'm curious how that is a bad thing (for the network as a whole). I suspect that it has to do with how we'd be using SPV clients in the future, but I want to know what you think.