Bitcoin Forum
April 19, 2024, 09:12:02 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: A Two-Round Proof of Work instead of PoW  (Read 648 times)
garlonicon
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1932


View Profile
November 20, 2021, 08:45:05 PM
 #81

Quote
If (hash mod N > K), then the miner will move to the next block without calculating any hash.
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.

Quote
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
It works, because license plates are distributed in centralized way.

Quote
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.
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.

Quote
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.
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).

Hold your horses before deploying blockchain-related things. You don't want to deploy SHA-1 collision without deploying hardened SHA-1. Once you reveal some code, and make it Open Source, there is no "undo" button. Once you share some idea, there is no way to erase it from reader's memory.
1713561122
Hero Member
*
Offline Offline

Posts: 1713561122

View Profile Personal Message (Offline)

Ignore
1713561122
Reply with quote  #2

1713561122
Report to moderator
1713561122
Hero Member
*
Offline Offline

Posts: 1713561122

View Profile Personal Message (Offline)

Ignore
1713561122
Reply with quote  #2

1713561122
Report to moderator
1713561122
Hero Member
*
Offline Offline

Posts: 1713561122

View Profile Personal Message (Offline)

Ignore
1713561122
Reply with quote  #2

1713561122
Report to moderator
Unlike traditional banking where clients have only a few account numbers, with Bitcoin people can create an unlimited number of accounts (addresses). This can be used to easily track payments, and it improves anonymity.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713561122
Hero Member
*
Offline Offline

Posts: 1713561122

View Profile Personal Message (Offline)

Ignore
1713561122
Reply with quote  #2

1713561122
Report to moderator
1713561122
Hero Member
*
Offline Offline

Posts: 1713561122

View Profile Personal Message (Offline)

Ignore
1713561122
Reply with quote  #2

1713561122
Report to moderator
larry_vw_1955
Sr. Member
****
Offline Offline

Activity: 1036
Merit: 350


View Profile
November 21, 2021, 03:22:19 AM
Merited by Quickseller (2)
 #82

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.

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??)

Quote
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.

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.
Epictetus (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 5


View Profile
November 21, 2021, 09:05:41 AM
Last edit: November 21, 2021, 10:00:27 AM by Epictetus
 #83


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??)
Indeed. You are right. This is why we proposed equation (2) and (3)

Quote
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.
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.
Epictetus (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 5


View Profile
November 21, 2021, 09:19:19 AM
Last edit: November 21, 2021, 09:43:17 AM by Epictetus
 #84

Quote
If (hash mod N > K), then the miner will move to the next block without calculating any hash.
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.
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.  

Quote
Quote
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
It works, because license plates are distributed in centralized way.
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.


Quote
Quote
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.
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).
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.
larry_vw_1955
Sr. Member
****
Offline Offline

Activity: 1036
Merit: 350


View Profile
November 22, 2021, 02:15:54 AM
Last edit: November 22, 2021, 02:27:40 AM by larry_vw_1955
 #85


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

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

Quote
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.

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. Grin

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

Quote
In comparison to today PoW, JPoW is a pain for the miners.

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.

Quote
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%.

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!
Epictetus (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 5


View Profile
November 22, 2021, 04:05:55 AM
Last edit: November 22, 2021, 04:55:31 AM by Epictetus
 #86

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

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

Quote
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. Grin
If individual miners would do that then you can get dollars to donuts that larger miners would too somehow.
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.  

Quote
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.
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.

Quote
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!
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.
larry_vw_1955
Sr. Member
****
Offline Offline

Activity: 1036
Merit: 350


View Profile
November 22, 2021, 05:43:24 AM
 #87


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.

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

Quote
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.

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. Grin

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.
vjudeu
Hero Member
*****
Offline Offline

Activity: 657
Merit: 1510



View Profile
November 22, 2021, 06:54:10 AM
 #88

Quote
But it will create for them the issue of managing a long list of addresses and keys.
Did you know about HD wallets? You can have one key and derive every other key from that.

Quote
force miners to have ONLY ONE UNIQUE address
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.

Quote
democratizing bitcoin mining is what I say needs to be done but how?
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.

Quote
An asic miner should count as one cpu just like my intel core 2 duo.
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.

Quote
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
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.

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
larry_vw_1955
Sr. Member
****
Offline Offline

Activity: 1036
Merit: 350


View Profile
November 22, 2021, 07:13:04 AM
 #89


Quote
An asic miner should count as one cpu just like my intel core 2 duo.
No, it should be proportional to the work you did.


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.


Quote
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
Quote
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.
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. Cheesy 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.
Epictetus (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 5


View Profile
November 22, 2021, 07:33:39 AM
 #90

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. Cheesy 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.
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.

Epictetus (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 5


View Profile
November 22, 2021, 07:55:15 AM
Last edit: November 26, 2021, 01:33:49 AM by Epictetus
 #91

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.

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.

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. 

 
vjudeu
Hero Member
*****
Offline Offline

Activity: 657
Merit: 1510



View Profile
November 22, 2021, 08:12:47 AM
 #92

Quote
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.
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).

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
Epictetus (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 5


View Profile
November 22, 2021, 08:18:36 AM
 #93

Quote
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.
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).
True. True.
garlonicon
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1932


View Profile
November 22, 2021, 05:42:41 PM
 #94

Quote
A_hash = Hash(Block Head + sign(Block Head))
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.

Hold your horses before deploying blockchain-related things. You don't want to deploy SHA-1 collision without deploying hardened SHA-1. Once you reveal some code, and make it Open Source, there is no "undo" button. Once you share some idea, there is no way to erase it from reader's memory.
Epictetus (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 5


View Profile
November 23, 2021, 04:18:04 AM
 #95

Quote
A_hash = Hash(Block Head + sign(Block Head))
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.

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.
Pages: « 1 2 3 4 [5]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!