please delete

[SapphireSpire]

nothing to see

[1714144319]

1714144319

[1714144319]

1714144319

[1714144319]

1714144319

[ranochigo]

The block header is hashed to form the block hash and that has a few more variables like timestamp, ver number etc. Transactions do not have to be ordered by their timestamp either.

The proposal that you stated would introduce would be detrimental to the network. Firstly, if the miner were to decide how much to mine, those who has a huge hash power could generate blocks with low reward and thus low difficulty. This effective makes the block interval much much faster and that the others would likely generate a lot more orphans.

The principle of mining is that whoever has the most resources should be able to decide and secure the network. If you were to be able to generate a block with little hashpower, it would be pointless for anyone to wait for 6 confirmations. Block reorgs would happen much more often and that it would be unsafe for people to trust transactions without waiting for thousands of confirmations.

It would also be quite tough to ensure a fixed distribution of the coin. The ability to choose the block reward would result in an uneven distribution of the coins over time.

[BrewMaster]

here is the problem, how are you going to stop a miner (or basically any random person with a CPU) to choose the smallest target possible and flood the network will millions of blocks per second. remember that it is not just about the reward but it is about the now bloated blockchain for no reason which puts a burden on all the nodes to sync and store all these junk blocks.

[DannyHamilton]

In the current mining algorithm, a miner will:
1. collect an arbitrary number of unprocessed transactions from thetheir mempool,

Fixed that for you.  Using the phrase "the mempool" makes it sound like there is just one mempool that everyone shares.  Actually, each full node has its own mempool which may be significatnly different from any other node's mempool.

2. sort the transactions according to their time stamps,

Transactions do not have timestamps.  The transactions can be placed in the block in any order at all.

3. hash them in pairs to calculate the Merkle root,
4. hash the Merkle root with the last block hash,
5. hash the result with the nonce,

A Merkle root is calculated from the transaction list.

Next, a block header is built.  The block header is 80 bytes long and contains:

• A 4 byte version number
• The 32 byte hash of the previous block in the blockchain
• The 32 byte Merkle Root of the transactions selected for this block
• A 4 byte timestamp
• 4 bytes representing the current difficulty target
• A 4 byte nonce

This 80 byte header is then hashed twice using SHA256 to calculate the hash of this block.

6. compare the size of the result with the target size of the difficulty level.
7. If the hash is too big, increment the nonce and try again.
8. If the hash fits, publish the block and repeat.

Generally correct, however it is possible to try all possible nonce values and still not find a solution.  If this happens, then something else in the header must be modified to continue trying.  Some possible things the mining pool (or solo miner) can modify are:

• The timestamp.
• The Merkle Root

There are a few ways to modify the Merkle Root.  Such as:

• Change the order of transactions in the list
• Modify the coinbase transaction with extraneous information (the transaction that pays the block reward)
• Add or remove transactions from the list

(after which the Merkle Root would be re-calcualted)

But it doesn't end there, now there are multiple blocks on different
branches of the blockchain competing for inclusion into the main trunk.

Typically, there aren't any competing blocks.  Typically, one block is solved, and is broadcast. As each solo miner (or mining pool) receives the solved block, they abandon the block they are currently working on and immediately begin a new block.

Occasionally, there may be 2 or three blocks that are all solved so close together in time that different parts of the network hear about different blocks first. In that case each solo miner (or mining pool) chooses the block that they hear about first and build on top of that.

Now what would be the consequences of omitting steps 6 to 8?
1. Eliminate the size requirement of the block hash.
2. Add the simple rule that the block with the smallest hash always wins.

Then anyone can completely destroy a blockchain by simply mining an old block with a lower hash that it was originally included with.  Once they do that, all blocks after the block that they re-mined become instantly invalid and all confirmations are lost.

So the new mining algorithm would be:
1. collect an arbitrary number of unprocessed transactions from the mempool,
2. sort the transactions according to their time stamps,
3. hash them in pairs to calculate the Merkle root,
4. hash the Merkle root with the last block hash,
5. hash the result with the nonce as many times as you want,
6. publish the block and repeat.

This would give miners the choice of how much work to do on each block-
whether to mine more on each block or mine less on more blocks.
If miners chose to mine more on each block, the block difficulty increases while the block rate decreases.
If miners chose to mine less on more blocks, the block difficulty decreases while the block rate increases.

This isn't going to work.  As a miner, I'd have no way of knowing what height to mine at. I don't know which earlier blocks are at a difficulty where all miners other miners have moved on, and which blocks are still being replaced.  Any time a block is replaced, all blocks that came after it are also invalid.

Consequences:

Complete disaster and an unusable system.

The principle of mining is that whoever has the most resources should NOT be able to decide and secure the network.

Fixed that for you.

As long as the largest miner has less hash power than the entire rest of the world combined, Bitcoin's proof-of-work blockchain is decentralized.  It is not possible for the "whoever has the most resources" to "decide" or control the network.

If you were to be able to generate a block with little hashpower, it would be pointless for anyone to wait for 6 confirmations.

It is currently possible for an individual with only 1 hash per minute hashpower to "generate a block" (as long as they get lucky and one of their early attempts is lower than the target value.  Having more hashpower doesn't guarantee that you'll win the next block, it just increases your odds.

here is the problem, how are you going to stop a miner (or basically any random person with a CPU) to choose the smallest target possible and flood the network will millions of blocks per second.

Correct.  An attacker would generate millions of hashes for a block and then sort them from lowest to highest.  Then they would publish each of those blocks a few microseconds apart in order. Every other miner/node on the network would have to spend all of their time receiving, verifying, and re-broadcasting all those blocks. The network would be flooded with constant block relaying, and would become unusable.

[BrewMaster]

here is the problem, how are you going to stop a miner (or basically any random person with a CPU) to choose the smallest target possible and flood the network will millions of blocks per second.

You can mine at zero difficulty if you want but it won't be long before
everyone else is mining at higher difficulties. At that point your blocks
will be ignored. Hopefully the economic loss of never winning a block
will encourage you to do the same, thereby reducing the block rate
from a flood to a manageable stream.

if the difficulty is supposed to increase then your starting post doesn't make sense anymore because we are back where we started (what bitcoin is currently doing).
and also what you said about "This would give miners the choice of how much work to do on each block-" is no longer true. a miner will always want to do least amount of work and get the most number of results out.

[DannyHamilton]

The only way to replace a recently mined block with your own is to replace every block on top of it as well, which would require you to out-pace the rest of the network, which is only possible if the network is slower than you alone.

The block with the smallest hash (highest difficulty) always wins.

Which is it?  You can't have it both ways.

Either I can invalidate a block by mining a block with a lower hash value, or the only way to replace a recently mined block with your own is to replace every block on top of it as well.

There needs to be some way to determine which are the VALID blocks in the chain, and to reject the invalid blocks.  You are currently offering two competing rules that can't co-exist.


Imagine this:

I choose the very first hash that I get for BLOCK_A and immediately start mining a second block, BLOCK_B on top of that where I also choose the first hash I get.  I immediately broadcast BOTH blocks and start mining BLOCK_C normally.  Everytime someone broadcasts a replacement for my BLOCK_A, I broadcast my latest BLOCK_C and continue to calculate hashes for BLOCK_C.

Now, If "the block with the smallest hash (highest difficulty) ALWAYS wins", then by broadcasting a smaller hash BLOCK_A, they can invalidate my entire chain of 3 blocks (since my BLOCK_B and BLOCK_C are built on top of an invalid block (too high difficulty).

On the other hand, if "The only way to replace a recently mined block with your own is to replace every block on top of it as well", then it is extremely unlikely that they will ever replace my BLOCK_A, since they'd have to also replace BLOCK_B and BLOCK_C. My continuous mining on BLOCK_C allows me to kill any attempt they make to ever replace BLOCK_A (any time they spend mining BLOCK_A and BLOCK_B is extra time I get to spend finding even lower hashes on BLOCK_C).


Also imagine this:

I start mining a block.  I get super lucky and quickly find a SUPER LOW hash.  A hash that "on average" would take the combined entire rest of the network days to beat.

I don't broadcast the block.  Instead, I silently build an empty block on top of it. When that block is at the average difficulty that the rest of the network is accepting, I silently mine third block (also empty) on top of that. When that third block is at the average difficulty that the rest of the network is accepting, I silently mine a fourth block (also empty) on top of that, I keep doing this while keeping track of what actual network is doing.  When the sum of the difficulties of the live blockchain starts to approach the sum of the difficulties of my secret chain (likely after a hundred or more blocks have been added to the live chain) I suddenly broadcast my entire secret chain.

Now, If "the block with the smallest hash (highest difficulty) ALWAYS wins" (or even if the chain with the highest difficulty ALWAYS wins), then by broadcasting my higher difficulty secret chain I instantly invalidate ALL of the blocks that everyone else has been working with.  They lose all their block rewards from the past hundred blocks or more, and all users suddenly lose ALL confirmations. I get ALL those block rewards for myself.

On the other hand, if "The only way to replace a recently mined block with your own is to replace every block on top of it as well", then I have managed to replace ALL the blocks on the existing blockchain. Nobody can invalidate my chain without going back and starting over again back at my super high difficulty block. Again they lose all their block rewards from the past hundred blocks or more, and all users suddenly lose ALL confirmations. I get ALL those block rewards for myself.

[DannyHamilton]

Please note...

When trying to come up with some way to modify the existing proof-of-work algorithms it is VERY IMPORTANT to think MUCH MORE about all the possible ways that someone might take advantage of your new algorithm than about the way you think your algorithm might be better.

The current blockchain concept is carefully balanced to prevent a lot of different attack vectors (end even then it is still vulnerable to a majority hashpower attack).  Changing any one thing about it is likely to open up some of those attack vectors unless you find some other way to prevent them.

[DannyHamilton]

- Lots of nonsense that doesn't take into consideration any of the issues involved in designing a trustless distributed system, and fails to understand the points I'm making -

Good luck.

[HCP]

Every time you generate a block, you want to publish it immediately so that everyone can compare it with all the
other blocks of the same height. That's when the block with the smallest hash wins and all other blocks are
orphaned. If you want to actually win a block, you'll need to mine with as high a difficulty as you can.

What other blocks at the same height? You seem to think that all miners are going to find blocks at precisely the same time and then compare notes... that's not likely to happen.

If you publish a chain of blocks, each block has to win at it's own height. If any of them lose, it and all following
blocks will be orphaned, regardless of hash size because they're chained, and everyone will start mining on top of
your latest winning block. That's why you never want to mine your own chains.

Why would any of them lose? There are no other "equal" blocks if you publish a valid chain 100 blocks long (which == longest chain/most work etc). As soon as you do that... ALL the "old" blocks immediately become invalid/orphaned. They won't match any of the valid block hashes from the new chain, so they're useless...

So none of those old (now invalid) blocks can be used. History has effectively been rewritten and there is no way to do anything about it... except go all the way back to block #2 of the new 100 block chain and try and find one with a lower hash... and then 98 more blocks, so that you can invalidate the new chain... But, good luck catching up while that miner has a 100 block head start!

At most you'd probably only be able to go back 5-10 blocks MAX... But the rest of the new chain would likely be unable to be modified without some sort of significant hash power.