Removing the nonce field for ASIC resistance and preventing selfish mining.

[shade_tom]

If we removed the nonce field from bitcoin or the blockchain concept itself, wouldn't that make the blockchain ASIC resistant and prevent selfish mining?

The reason I say this is because since ASIC miners just iterate through all the possible nonce values, by removing the nonce we make the only sources of change, the timestamp and the merkleroot.
That way the miners are incentivized to add, remove, and permutate through all the merkle tree possibilities, to do this they need transactions and as such, unselfish miners would have an advantage as they would have more transactions to play with.

Note: I don't actually intend to do this, I was just wondering what people think about it in theory.

[1714858446]

1714858446

[1714858446]

1714858446

[1714858446]

1714858446

[1714858446]

1714858446

[cloverme]

If we removed the nonce field from bitcoin or the blockchain concept itself, wouldn't that make the blockchain ASIC resistant and prevent selfish mining?

The reason I say this is because since ASIC miners just iterate through all the possible nonce values, by removing the nonce we make the only sources of change, the timestamp and the merkleroot.
That way the miners are incentivized to add, remove, and permutate through all the merkle tree possibilities, to do this they need transactions and as such, unselfish miners would have an advantage as they would have more transactions to play with.

Note: I don't actually intend to do this, I was just wondering what people think about it in theory.

Difficulty and nonce go hand in hand, difficulty tells the nonce how many 0's to have. Both are key in bitcoin's proof of work. ASICs really aren't the issue, if you can mine heavily with ASIC's there's not much difference in spending millions of dollars in a computers then to just do PoW from that perspective.

My idea was to randomize the difficulty within the 10 minute timestamp from the previous block so that computers and ASICs can participate equally.

[shade_tom]

Difficulty and nonce go hand in hand, difficulty tells the nonce how many 0's to have

What? I think you mean difficulty tells the hash of the block header how many 0's to have....

From the scheme I mentioned earlier, the way difficulty is calculated would remain the same, the only thing is that the only changeable values that modify the resulting hash are the timestamp and merkle root.

Additionally, considering the cost difference per unit hash power, between a single computer and a single ASIC, there is a difference. Why else would people want to create block-chains with ASIC-resistant hash functions, e.g. (Litecoin's attempt with Scrypt), Ethereum's EthHash, etc.

My idea was to randomize the difficulty within the 10 minute timestamp from the previous block so that computers and ASICs can participate equally.

How exactly would that work?

[vh]

As soon as you attempt to make any ASIC resistance changes to bitcoin, you will no longer be mining bitcoin.

ASIC is here to stay.  The bitcoin network will adjust to allow about one block solve every ten minutes.

Selfish or Unselfish miners does not change that.   
Fast or slow SHA processing power does not change that.   
One miner or One billion miner does not change that.

Extreme desire to want to force mining with a CPU or GPU will trigger a new coin into existence as it has in the past. 

[achow101]

Difficulty and nonce go hand in hand, difficulty tells the nonce how many 0's to have.

No, that's the nBits field. The nonce is the field that is changed in order to find a valid hash as it is more efficient than changing the other fields.


First of all, this would require a hard fork.

Secondly, removing the nonce field won't really help. Miners can just keep changing something in the coinbase transaction which can effectively act as a nonce. In fact, since the coinbase part of a coinbase transaction can include whatever data a miner wants, they could just move the nonce into the coinbase transaction and basically continue as they do now. It would add an additional 13 hashes for each block header hashed so it effectively reduces the network hashrate to 1/13 of the current hashrate. However, that won't suddenly make CPU or GPU mining viable again and it most certainly does not make Bitcoin ASIC resistant. ASIC resistance is in the hashing algorithm itself, not the data that is being hashed.

Since miners can and will essentially move the nonce into the coinbase itself, selfish mining is not effected at all. All of the other transactions in the block would remain the same and only the coinbase transaction would change. That is enough to change the merkle root.

[rngkll]

I think the problem with selfish mining have to be analyzed from another perspective. I believe the real problem is the centralization of Hash Power in an Elite group of users, by implementing memory-bound proof-of-work algorithms, ASIC or GPU advantage will be insignificant which leads to a better distribution of Hash Power. You may want to look at our approach at Nimiq for bringing true decentralization to Cryptocurrencies.

[shade_tom]

Secondly, removing the nonce field won't really help. Miners can just keep changing something in the coinbase transaction which can effectively act as a nonce. In fact, since the coinbase part of a coinbase transaction can include whatever data a miner wants, they could just move the nonce into the coinbase transaction and basically continue as they do now. It would add an additional 13 hashes for each block header hashed so it effectively reduces the network hashrate to 1/13 of the current hashrate. However, that won't suddenly make CPU or GPU mining viable again and it most certainly does not make Bitcoin ASIC resistant. ASIC resistance is in the hashing algorithm itself, not the data that is being hashed.

That's a good point about the coinbase, I almost forgot about that. Does it actually have a purpose or can we get rid of that in this hypothetical?
Conjecturing on we can, doesn't this make the bitcoin algorithm ASIC resistant?

Although you say that ASIC resistance is based on the hashing algorithm, I'd argue that the calculation of the merkle root is in itself a giant hashing function. If we use the merkle root as the only source of randomness, then I get the following calculations:

If we take the current hash rate of about 5,000,000 TH/s and multiply that by 10 minutes we get, 5,000,000,000,000,000*10*60 Hashes. Which would mean that the number of different merkle roots we need can be calculated via log2(5,000,000,000,000,000*10*60) = 61.3796682. Meaning that each block would require at least 61 transactions for the miner to find a block.

[achow101]

That's a good point about the coinbase, I almost forgot about that. Does it actually have a purpose or can we get rid of that in this hypothetical?

You could get rid of it in this hypothetical. It doesn't serve a consensus purpose, but it does help to track who mines a block as miners usually will put some identifying text in the coinbase.

Conjecturing on we can, doesn't this make the bitcoin algorithm ASIC resistant?

Although you say that ASIC resistance is based on the hashing algorithm, I'd argue that the calculation of the merkle root is in itself a giant hashing function. If we use the merkle root as the only source of randomness, then I get the following calculations:

If we take the current hash rate of about 5,000,000 TH/s and multiply that by 10 minutes we get, 5,000,000,000,000,000*10*60 Hashes.

No, that is not ASIC resistance. ASIC resistance means that the PoW algorithm (in this case sha256d) is hard to implement on an ASIC. Merkle root calculations are also SHA256d; the data for calculating a merkle root can just be passed through the same SHA256d hashing chips on an ASIC. The processing that is required to do this is also very minimal and could be done on an FPGA before being sent to the chips to be hashed. I don't think the actual hashing chips themselves are even the ones that change the nonce. IIRC the onboard FPGA processes the header and then sends it to the hashing chips to actually be hashed. That FPGA would just need to process a little bit more to make the merkle root.

Which would mean that the number of different merkle roots we need can be calculated via log2(5,000,000,000,000,000*10*60) = 61.3796682. Meaning that each block would require at least 61 transactions for the miner to find a block.

We cannot rely on there always being some minimal number of transactions to be included into a block except for the coinbase transaction. While requiring a minimal number of transactions would solve several issues, I don't think that should be done as we need to consider the scenario where few transactions are being made. The network would grind to a halt if for some reason transactions are not being made (could be from Bitcoin falling out of use and becoming an even more niche thing, some layer 2 solution makes onchain transactions few and far between, some vulnerability is discovered that people stop making txs but the blockchain must go on, etc.).

[shade_tom]

You may want to look at our approach at Nimiq for bringing true decentralization to Cryptocurrencies.
Posted on: Today at 06:33:11 AM Posted by: achow101

Whoa, a WebRTC based blockchain, I began implementing my own WebRTC blockchain but never finished it, I think I was stuck on decentralizing the signaling servers.
That's pretty sweet that you guys managed to get something running though. All the power to you  !

[shade_tom]

We cannot rely on there always being some minimal number of transactions to be included into a block except for the coinbase transaction. While requiring a minimal number of transactions would solve several issues, I don't think that should be done as we need to consider the scenario where few transactions are being made. The network would grind to a halt if for some reason transactions are not being made (could be from Bitcoin falling out of use and becoming an even more niche thing, some layer 2 solution makes onchain transactions few and far between, some vulnerability is discovered that people stop making txs but the blockchain must go on, etc.).

I just realized that it doesn't make sense for the network to grind to a halt. Assuming that a miner has even 1 satoshi, they can construct an infinite set of transactions between their accounts on the same block. However, there would be less incentive to do this as opposed to accepting transactions from the network due to transaction fees.

I do agree with you on the fact that the hashing algorithm is the thing that determines ASIC resistance though.

[TierNolan]

... unselfish miners would have an advantage as they would have more transactions to play with.

You need to define what you mean by selfish mining.  

Selfish mining is where miners hold back their blocks and then quickly broadcast them once someone else finds a block.  A selfish miner is assumed to have a really good network connection.  They can detect the other miner finding a block and then get their block (which they were withholding) to most of the mining power faster than the other miner.

I think you are confusing it with SPV mining (where miners mine empty blocks)?

If you just want to prevent SPV mining, then one way to do it is to require that blocks have the hash of the transactions from the previous block in their coinbase.

Commit in coinbase: Hash(Txids in this block | Txids in previous block)

[shade_tom]

Selfish mining is where miners hold back their blocks and then quickly broadcast them once someone else finds a block.  A selfish miner is assumed to have a really good network connection.  They can detect the other miner finding a block and then get their block (which they were withholding) to most of the mining power faster than the other miner.

Thank you for correcting me, my mistake for using the wrong terminology.

From what I could gather the reason miners do SPV mining, and as you addressed in your solution, is because they haven't downloaded the entirety of the previous block and as such don't know which transactions are still unmined.

I think that the original proposal will still be doomed to fail even for ASIC prevention as miners could simply add in their own transactions with either OP_RETURN or something similar and use that as a nonce field.