Quote from: garlonicon on Today at 06:13:17 AM

Quote

I don't think TRPoW is a recipe for disaster.

Then go for it, release just another altcoin and see how it will turn out. You can release some kind of test network first, just to check if your theory works in practice.

Totally agreed with you. I think the idea needs to be tested. At least for the sake of the experiment.

Quote from: garlonicon on Today at 06:13:17 AM

Quote

You can also see Bitcoin with PoW as Bitcoin with TRPoW where N2 = N1.

You can make it backward-compatible, just by producing first-phase blocks as today and adding some rules to enforce second-phase for these blocks. The simplest way to do that could be using difficulty to decide, how long the second nonce should be. Then you have previous block hash with some zeros, you can place your second-phase nonce there, then taking a single 80-byte block header is enough.

For example:

Code:

FirstRoundHeader {
version=01000000
previousBlockHash=6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
merkleRoot=982051fd1e4ba744bbbe680e1fee14677ba1a3c3540bf7b1cdb606e857233e0e
time=61bc6649
difficulty=ffff001d
nonce=01e36299
}

SecondRoundHeader {
version=01000000
previousBlockPartialHash=6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000
secondNonce=000000
merkleRoot=982051fd1e4ba744bbbe680e1fee14677ba1a3c3540bf7b1cdb606e857233e0e
time=61bc6649
difficulty=ffff001d
nonce=01e36299
}

Because you can see 0x1d value in the difficulty, you know that you can take three bytes from the previous block hash and there must be zeroes to be valid. Also, there is no need for adding any public key to the block header, because it is already calculated in the merkle root. Also, you can add more fields to each header in the coinbase transaction if you really need them, there is no need to add them directly to your headers.

Thank you Garlonicon for these great and precious ideas/suggestions. Much appreciated. Let's me think of it. I will update you here in all cases.