Topic: A Two-Round Proof of Work instead of PoW (Read 834 times)

Thank you very much Garlonicon for the link. Yea. You are absolutely right on A_hash. It was my first intuition and then I switched to B_hash to avoid congesting the network as every miner can do all the B_hash calculation by itself. Your point on backward-compatibility is brilliant.

You don't have to add signatures to the block header. You can add them to the coinbase transaction, like it is done in signet, in this way you can make it backward-compatible. You can find all technical details in BIP-325: https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki.

In general, to start your network, all you need is constructing signet challenge to allow signing blocks only by those miners, which passed the initial selection. By default, signet challenge is set to 1-of-2 multisig, so only two miners can produce blocks (because it is needed to test things in more stable way than in testnet). You can change that signet challenge, just to allow only signatures that passed the first round and you will get your coin.

True. True.

You know that miners in pools are mining on pool's address? If you force them to mine on their own addresses, then they will include a transaction sending coins back to the pool (or even directly distributing rewards to previous miners, selected by the pool).

The problem with any variant of PoW is that it will push miners to compete on CPU ground and invest a lot of money on CPU. In such system, miners will always find a way to group themselves and form pools and monopolies. Which is against the ideal of the decentralization.


This idea you can implement it easily. Just ask everyone to calculate their A_hash: A_hash = Hash(Block Head + sign(Block Head))
And Everyone will broadcast its A_hash and everyone will know that this A_hash can be produced only by the miner itself and no one else.

Let's call this proposal: Proof of Hash Ownership: PHO. (Harsh Ownership  or Hard Ownership).

Now the issue is how to find the consensus on the winner:
1- The closest to the target like in PoW.
2- The closest to the arithmetic average mod a Big N of all the B_hash of the network.
3- The closest to the geometric average mod a Big N of all the B_hash of the network.
4- min of all the B_hash
5- max of all the B_hash
4- Others

And the idea is how to make sure that everyone is OK on the outcome? Bitcoin PoW proposed the criteria of the fastest miner which push people to invest heavily in CPU. The criteria 2 seems to me the best as it cannot be manipulated. And also after let's say 70% of network A_hash received/collected, a miner can conclude which miner is the winner. This is thanks to the Law of large numbers. Like in Monte Carlo method. If we have a fixed list of miners Criterias 4 and 5 are the best.

In this case, we can clearly expect miners to flood the system with their X sub miners in order to win the block. The network congestion can be a problem. To solve the broadcast / congestion problem in the network we can replace A_hash by B_hash where B_hash = Hash(Block Head + Public Key). And all the miners need to keep a list of all the miners updated and do the hash calculation by themselves instead of waiting to receive it from the senders. New miners will need to announce themselves to the network first if they want to be taken into account. The first let's say 100 winners will announce themselves by broadcasting the list of all the B_hash done by themselves and the criteria result. The network will accept the block of the fastest miner among the top 100 following the criteria. Here we don't need 70% of the miners because we have the nearly full list of miners (with some exception due to eventual network issues or manipulation). All miners will be able to do the same as the winner and contest the result in case there is need. The list of miners can be updated weekly at a specific time to avoid potential issues and congestion in the network and also for all the miners to be working with the same updated list. Top 100 (or another number) is needed to have a system working efficiently. Otherwise we can have cases where a winner of a block not broadcasting the block result etc. So we need a kind of competition to force miners to have good IT systems reliable. The Top 100 will create issue of two miners claiming the same block reward. But this can be resolved by making the priority goes first to the real winner as per the criteria 1-6 if we have a problem around a chain of the same length otherwise we go for the longest chain. The good thing here, we will always be able to know who is the legitimate winner of a block. An attacker from the miner list won't be able to highjack a block because its B_hash must be among the top 100 first. And attacker outside the list won't be able to do it because it is outside the list. And by design, a selfish mining attack is impossible here. Also, no 51% attack because the system is not based on CPU power. Because even if you have huge CPU, you will still need first to be able to put yourself in the top 100 which quite random.        

A potential issue will be the list of miners can be huge as everyone will be able to create 100-1000 addresses. And this can affect the Block Time. So we need a way to keep the block time fix.

To limit miners from creating 1000+ addresses, we can, during the weekly miner list update session, impose on each address to broadcast their B_hash message signed by the address key and run another PHO round to win the chance to update the miners list. The block time can be set to 10min to allow for all the miners to send their pings. The fastest will update the list and win a reward equivalent to a Block Reward and add the block to the blockchain. And everyone else should use the list sent and signed by the winner. Once the miner list updated, the block time can be updated too based on the new list.
This part will be only on a weekly basis. It goes without saying that the genesis block should be a block that updates the mining list.

More details on the whole PHO consensus protocol here: https://drive.google.com/file/d/1Py5nZWCW2YJ-E3IcEp4_trmeTKmGWgKQ/view?usp=sharing
or here https://www.researchgate.net/publication/356554200_Proof_of_Hash_Ownership

As usual your thoughts and spicy critics are powerful and most welcome as always. 

 

The idea has a lot of merit. But we need to find a way to implement it in such a way that most of honest players comply with it. Because as said by Vjudeu, miners can always create N sub-miners etc.

The other idea that I suggested along side with JPoW was to create a Placebo Proof-of-Work (PPoW): a group of miners unknowingly run the real PoW and another group of miners unknowingly run only a placebo PoW, a PoW with no hashing computation at all. And we adjust the seize of each group accordingly to get the desired number of miners to run the hash competition. But the issue again is that miners can still ignore the Placebo PoW and just use the traditional PoW disregarding the rules to win the block reward. So, I need to find a way to stop such behavior which I haven't figured that out yet.

Not trying to hijack the OPs thread and proposal since it probably has some serious merit but no it should not be proportional to the work done. That's the whole point behind one cpu one vote. Some people don't have as powerful equipment as someone else but if they can do one single hash that should put them on equal footing with everyone else. at least that's what the phrase means to me. the idea that we need all the extra hashes from a single cpu is not true, i dont think. just one hash is enough, no more is needed or useful. there is enough cpus out there to secure the network with just one hash each maybe.


They can't pretend simply because it's "one cpu one vote". Unless they go and buy alot of cpus they won't get but one vote. they can knock themself out on getting more cpus though. But I don't think that would scale very well. which is good. now of course, you do run up against the issue of how do you make sure that each cpu is only submitting a single hash. i haven't figured that out yet.

Did you know about HD wallets? You can have one key and derive every other key from that.

If you limit the number of addresses that miners can have, then they will be forced to form pools. Imagine you have one million miners and only 100 of them can do Proof of Work. Then the obvious solution is forming a pool. Finally you would have 100 big mining pools where each pool has its own address. You can even force all miners to have ONLY ONE UNIQUE address in the whole network, then that address could be worthless, everyone could mine a block with private key equal to one and include a transaction sending funds where they want.

For example by splitting rewards in P2P way. Now you have to solo mine a block matching the network difficulty. To get rid of pools, you need a way to mine N times easier block and receive N times lower coinbase reward in pure P2P way.

No, it should be proportional to the work you did. For example, now you have a block with hash 000000000000000000091ae845e53e648e536eddc25be691baab2cf59a0c9123 and you have 0x170c69ea difficulty, so the target is 0000000000000000000c69ea0000000000000000000000000000000000000000. In this block, some miner got 6.30623404 BTC, so 630623404 (0x25968cac) satoshis. If you multiply the target by the number of satoshis, you would get 000000000001d29bb35f21380000000000000000000000000000000000000000. That means to mine one satoshi, you should produce a block with hash below that target. If mining in the Lightning Network would be possible, then going to millisatoshis or even lower fractions should be possible to get reasonably low target for each CPU miner. The only problem with this approach is joining shares. You can collect N headers, but it will be always too low to cover every miner, so there is a need to join shares somehow, also to make it backward-compatible.

You cannot do that. Bigger miners can pretend to be N smaller miners to get more chances. In your proposal, the better connected miners always win, that means of course specialized mining pools with their own servers, not some small solo miner running a single CPU.

Yeah, I'm with you on that issue. I don't like the idea that big miners and big corporations took over mining bitcoin and the little guy got trampled on so it's no longer "one cpu one vote" i wish there was a way to go back to that.

democratizing bitcoin mining is what I say needs to be done but how?

democratic. : to make (something) available to all people


I think it should be one cpu one vote. An asic miner should count as one cpu just like my intel core 2 duo. they should both get the same weight/power to collect a mining reward but that's not how it works. i dont think satoshi meant it to be that way but that's how it turned out. and its a shame. i'm just not sure how one could implement that. it still needs to involve proof of work but leveling the playing field between different hash rate hardware seems a challenge.

i actually do have some idea of how to go about that procedure maybe i'll post it sometime. i'm sure people will not want to do it though! for example, only let each miner perform one hash. whichever miner comes closest to the target is the winner. and they get to mine the block.

We are not stopping individual miners but only limiting the hash computation to a group of miners at each block.

They can do that. But it will create for them the issue of managing a long list of addresses and keys. And that each time they will need to spend time calculating the signatures and the hashes. Which at the end may not worth it. The other idea is again to inspire from the uniqueness of car plate numbers and force miners to have ONLY ONE UNIQUE address.  

Yea. But this is NOT a desired outcome. Because we have a system that was supposed to be decentralized became de facto centralized in the hands of few miners. What if these few miners decided to engage in 51% attack without announcing it and steal people money.

The idea is to create a system that is as decentralized as possible. The current state of affaires is not at the best interest of Bitcoin ideologically. Today, we have few miners running the show and they can create a monopoly whenever they want to. Just another Banking system with a different name. Check this link: https://github.com/taprootactivation/Taproot-Activation
If you take the Top 8 biggest mining pools they represent over 80% of total hash rate. Total dominance of these few pools over the entire Bitcoin network. Imagine if Google, Amazon, Apple, Facebook and Microsoft decide to join the mining party.

But I still dont see how you are stopping individual miners. I guess you're just focused on controlling mining pools.


You didn't address the question about what is stopping an individual miner from just setting up a bunch of private keys and doing that hash on each one to guarantee they get a favorable hash result from at least one of them. They would most likely do that. So you must not be worried about them cheating the system in that way.

If individual miners would do that then you can get dollars to donuts that larger miners would too somehow.


Which is why I doubt we would ever see something like this in bitcoin. Miners control the game. And they seem pretty happy with the way things are.


Well I wouldn't know that I agree with you that miners would be forced to share their private keys with each other to work your system. For example, what's stopping a group of miners from creating a multisignature taproot public key? i guess it's a theoretical work around but maybe not so doable in practice hopefully for your sake!

Yes. But like in Bitcoin, we bet that the network will be controlled by honest miners who will play by the rules. And even if they don't, their work will be simply ignored by the honest nodes and hence waste of money for the miners involved in such practice.  

Yes. There is no way to stop a miner from hashing if he want to launch his machine. But technically his hash work will go to dustbin.


Indeed. But it reduces pool mining to be only between miners who can share their private keys with each others. A total trust is required. Which means that there a is large number of miners who won't be able to create pools unless they trust each other 100%. And this in itself will create a limitation in the pool formation. It won't stop it. But it is a huge limitation as miners will need first to find an address that is authorized to hash. And then run their mills using the private key of the authorized address. In comparison to today PoW, JPoW is a pain for the miners.

Indeed. You are right. This is why we proposed equation (2) and (3)

Indeed. But it reduces pool mining to be only between miners who can share their private keys with each others. A total trust is required. Which means that there a is large number of miners who won't be able to create pools unless they trust each other 100%. And this in itself will create a limitation in the pool formation. It won't stop it. But it is a huge limitation as miners will need first to find an address that is authorized to hash. And then run their mills using the private key of the authorized address. In comparison to today PoW, JPoW is a pain for the miners.

Maybe I'm ignorant about how bitcoin mining works but it seems like a miner could just compute the above hash for multiple public keys they own so as to guarantee one of them hashes out to the desired constraint (less than K, I believe??)


Once again, if a miner has multiple private keys they'll just compute the above hash for each one.

If i was a miner, that's what I would do. Unless it was computationally too expensive.

It is impossible in any decentralized system. You could have some difficulty and accept only blocks with hash modulo 2 equal to zero, that would be as hard as mining with doubled difficulty, you cannot expect that people will stop mining just because your official mining software is doing that. If N is some natural power of two, then it is the same as taking some last bits of the hash. By checking blocks for the classical Proof of Work and some condition with hash modulo N, you are just rising the difficulty in some obscured way.

It works, because license plates are distributed in centralized way.

Each miner would know that, so each miner would just continue mining. Mining some partially valid block when solo mining is the same as mining nothing. If you need a block with 32 leading zero bits, you don't send a block with 31 zero bits, you also don't stop your miner, you just mine all the time to reach a block with 32 leading zero bits. It doesn't matter if you split validation into checking leading and trailing bits or if you do it as usual, just by checking if the hash is lower than the target. Checking if the first 16 bits are set to zero and if the hash modulo 2^16 is zero is exactly as hard to mine as producing a single block with 32 leading zero bits.

No, it won't change anything. Miners will share their private keys with mining pools. Today they are mining directly to the pool's address, so sharing the key requires the same level of trust as today. But that's just one option. In any useful coin you can still make transactions. That means you can mine a block where you send your reward to yourself, but you can include a transaction sending some older coins to the pool. Then, the pool can accept your shares only if you paid them first, in this way you can reach the same system as you have today, but just with more transactions to obfuscate what is going on (if for example you will find a way to punish miners for sharing keys).

So True. Pool domination is a reality. Now we need a way to complicate life for mining pools.
So I got this new idea that I called: Jakarta Proof of Work. Instead of running a Two-Round PoW, we just directly limit the miners that are going to participate in the hash competition for a block.
Read article here: https://www.researchgate.net/publication/356414880_JPoW_and_TRPoW_Variants_of_Proof_of_Work
or directly here or google drive: https://drive.google.com/file/d/1f_a2obArSQ9kmFVeqE11ApPYTk31IYv2/view?usp=sharing
==============Begin==============
The other simple idea is to do like Jakarta’s odd-even traffic policy to limit the number of cars entering Jakarta: the policy stipulates that cars whose license plate ends in an odd number are only allowed to circulate on odd-numbered dates and vice versa. So, like in the case of Jakarta, we don't want every miner to participate in the hash computation all the time. So, we propose a Jakarta PoW (JPoW) where only miners with (hash mod N < K) where, for each block, for each miner with its public key $PublicKey$:
Equation (1):  hash = Hash(Block Head + Public Key)
If (hash mod N < K), then the miner will go for the traditional Bitcoin PoW.  If (hash mod N > K), then the miner will move to the next block without calculating any hash. $N$ and $K$ are parameters to adjust to determine the number of miners participating in the hash competition. To get a similar model like Jakarta odd-even policy, we can just choose $N=2$ and $K=1$.  When a miner receives an $nonce$ from another miner, it can easily verify that the sender is authorized to participate in the hash computation. If all is fine, it accepts the $nonce$ and moves to the next block competition. If the miner sending the $nonce$ is not authorized to participate in the hash computation, the miner receiving the $nonce$ will ignore what it received and continue solving for its own $nonce$ and listening to the network like in Bitcoin. In JPoW, if a miner ignores the rules and just go for the hash calculation, such miner will be ignored by the honest nodes in the network.
With equation (1), it will be still possible for miners that cannot participate in a hash computation to rent their machines to miners that are authorized to hash as the public keys information is available to all miners. So, to resolve this issue, we replace $Public Key$ by $sign(Block Head)$:
Equation(2): hash = Hash(Block Head + sign(Block Head))
The $sign(Block Head)$ can be produced by the miner only. And it is not available to all the miners at the time of the block creation. If a miner wants to participate in a pool, it will need to send its $sign(Block Head)$ to its pool. The pool will still be able to help on the hash calculation.
Even though $sign(Block Head)$ will slow down the process as the pool will still need to wait for its arrival before starting looking for the nonce while hashing for $Hash(Block Head + sign(Block Head) +  nonce)$. To complicate the problem further for the pool, we slightly modify the PoW and search for a nonce while hashing the following equation (3):  PoW hash = Hash(Block Head + sign(Block Head) +  sign(nonce))
The replacement of $nonce$ in PoW by $sign(nonce)$ will force the miner to either share its private key with the mining pool or calculate the hash itself. Sharing one's private key is a significant constraint and it is expected to complicate mining pool formation.
===============End====

Your comments / suggestions / critics are the most welcome as always.

 Thank you

 

You can see for example here: https://github.com/taprootactivation/Taproot-Activation. As far as I know, only the biggest pools were contacted for taproot support, there were no solo miners having some significant power. That means even if your proposal would be backward-compatible, you would ask big mining pools for support, not some independent solo miners. Of course you can rely on solo miners, but then I expect you wouldn't get more than few percent of the mining power supporting your version.

It is true that miners can/will organize themselves in pools and participate in the hash calculation all the time. TRPoW can still be able to reduce the total energy consumption in the network thanks to the non-pooled miners.
Now the question what is the fraction of non-pooled miners in Bitcoin network?

Thank you very much Vjudeu for your time and your great sharing and all the links. Much appreciated Bro. I learned a lot from you since the beginning of this thread. The content you shared is brilliant.

I guess not. All changes described in the whitepaper from this topic are backward-incompatible, that would mean a hard fork (or an altcoin, if it would be based on its own Genesis Block). But even in a soft fork case I doubt miners will go for it. They have no reason to split the whole process into two phases. It will be just another obfuscated Proof of Work, where things are the same like in plain, old, single-phase Proof of Work, but only some people will know how to produce the best blocks.

Or even worse: if it would be backward-compatible, then it could be simplified as just another merge-mined coin: by producing coins valid in both chains, miners will never switch to your coin, they would just get the same amount of Bitcoins and YourCoins, then sell YourCoins for Bitcoins, so the price will fall. I guess the same things would happen as for example in Luck: first some discussions on bitcointalk, then some negative feedback, then some test version release without addressing any problems from that feedback, and then creating just another altcoin that would be pumped and dumped as usual.

It would be true only for a short period of time. Then, the difficulty will adjust. Miners can switch between Bitcoin and your coin, also they will probably sell everything when your coin will enter some exchange for the first time.

It probably is. But when people don't want to learn from mistakes made by others, then they have to make their own.

Satoshi first did a lot of coding and testing, and then wrote the whitepaper. I think in many coins, things are going backwards: first there is some unchecked idea with some whitepaper, then there is some coding and testing, and later there are many big surprises, because some things were not checked before releasing the whitepaper and they are getting out of control.