follow us on twitter . like us on facebook . follow us on instagram . subscribe to our youtube channel . announcements on telegram channel . ask urgent question ONLY . Subscribe to our reddit . Altcoins Talks Shop Shop


This is an Ad. Advertised sites are not endorsement by our Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise Here Ads bidding Bidding Open

Author Topic: Getting rid of pools: Proof of Collaborative Work  (Read 1238 times)

Offline bosshyip

  • Full Member
  • *
  • Activity: 262
  • points:
    2083
  • Karma: 2
  • Mpcx
  • Trade Count: (0)
  • Referrals: 0
  • Last Active: April 23, 2023, 04:11:57 AM
    • View Profile

  • Total Badges: 16
    Badges: (View All)
    Topic Starter Poll Starter 100 Posts
Getting rid of pools: Proof of Collaborative Work
« on: July 06, 2018, 08:05:07 AM »
Proof of Collaborative Work

A proposal for eliminating the necessity of pool mining in bitcoin and other PoW blockchains

Motivation
For bitcoin and the altcoins which are based on common PoW principles,  centralization of mining through using pools, is both inevitable and unfortunate and puts all the reasonings that support the security of PoW in a paradoxical, fragile situation.

A same problem does exist with PoS networks. Things can get even worse  there because of the fact that most PoS based systems enforce long run deposit strategies for miners that is highly discouraging for them to migrate from one pool to another because of the costs involved.

Satoshi Nakamoto's implementation of PoW that is the core of bitcoin client software is based on a winner-takes-all strategy which is the fundamental factor behind two critical flaws: mining variance and proximity premium which are the most important forces that participate in forming pooling pressure.

Until now, both mining variance and proximity premium are known to be unavoidable and hence pooling pressure is considered an inherent flaw for bitcoin and other PoW based currencies.

In this proposal, we are suggesting an alternative variant of PoW in which the traditional winner-takes-all is replaced with a collaborator-takes-share strategy.

The problem of solo mining becoming too risky and impractical for small mining facilities appeared in 2010, less than 2 years after bitcoin had been launched. It was the worst timing ever, although Satoshi Nakamoto made a comment on bitcointalk about first pool proposals,  it was among the latest posts Satoshi made and he just disappeared few days later from this forum, forever, without making a serious contribution to the subject.

This way, the confused community came out with an unbelievable solution for such a critical problem, a second layer centralized protocol, named pooling, boosted by greed and ignorance, supported by junior hackers who as usual missed the forest.

Bitcoin was just 2 years old when pooling age began and eventually dominated almost all the hashpower of the network.

A quick review of Slush thread in which Satoshi has made the above referenced reply, could reveal how immature and naive this solution was and has been discussed and how it has been adopted: In a rush with an obvious greed.
Nobody ever mentioned the possibility of an algorithm tweak to keep PoW decentralized. Instead everybody was talking about how practical was such a centralized service while the answer was more than obvious:
Yes! you can always do everything with a centralized service, don't bother investigating. 

Anyway, in the thread, one couldn't find any arguments about the centralization consequences or the possibility of alternative approaches including the core algorithm improvements Shocked

I think it is not fair. PoW is great and can easily be improved to eliminate such a paradoxically centralized second layer solution. This proposal, Proof of Collaborative Work (PoCW) is an example of inherent possibilities and capacities of PoW. I didn't find any similar proposal and it looks to be original but If there is a history, I'll be glad to be informed about. Smiley

The Idea is accepting and propagating works with hundreds of thousands times lower difficulties and accumulating them as a proof of work for a given transaction set, letting miners with a very low shares of hash power ( say of orders like 10-6) to participate directly in the network and yet experience and monitor their performance on an hourly basis.



Imo, now, after almost a decade being passed, Moore law has done enough to make it feasible utilizing more bandwidth and storage resources and it seems to me kinda hypocritic to make arguments about 'poor miners' and pretending to be concerned about centralization threats and making excuses so for rejecting this very specific proposal that although increases the demand for such resources, can radically disrupt current situation with pools and centralized mining.

This proposal is mainly designed for bitcoin. For the sake of convenience and letting the readers to have a more specific perception of the idea, I have deliberately used constants instead of adjustable parameters.

Outlines
An immediate but not practically feasible approach can be reducing blocktime (along with proportional reduction in block reward). Although this approach, as mentioned, can not be applied because of network propagation problems involved, but a very excellent consequence would be its immediate impact on the scalability problem if employed, we will use it partially (reducing blocktime to 1 minute compared to current 10 minutes period).
As  mentioned earlier (and with all due respects to Core team), I don't take objections about the storage and network requirements implications and consequences of reducing blocktime as a serious criticism. We should not leave mining in hands of 5 mining pools to support a hypothetical poor miner/full node owner who can not afford installing a 1 terabyte HD in next 2 years!.
Also note, blocktime reduction is not a necessary part of PoCW, the proposed algorithm, I'm just including it as one of my old ideas (adopted from another forum member who suggested it as an alternative to infamous block size debate and later has been developed a bit more by me) which I think deserves more investigation and discussion.
PoCW uses a series of mining relevant data structures to be preserved on the blockchain or transmitted as network messages
Net Merkle Tree: It is an ordinary Merkle hash tree of transactions with the exception that its coinbase transaction shows no block reward (newly published coins) instead the miner charges all transaction fees to his account (supports SegWit)
Collaboration Share: it is  a completely new data structure composed of following fields:
1- The root of a Net Merkle Tree
2- Collaborating miner's wallet address
3- A nonce
calculated difficulty using previous block hash padded with all previous fields, it is always assumed to be at least as hard as 0.0001 compared to current block difficulty
Coinbase Share: it is new too and is composed of
1- A Collaborating miner's wallet address
2- A nonce
3- A computed difficulty score using the hash of
previous block's hash padded with
current block's merkle root, padded with
Collaborating miner's address padded with the nonce field
4-  A reward amount field
Shared Coinbase Transaction: It is a list of Coinbase Shares 
First share's difficulty score field is fixed to be  2%
For each share difficulty score is at least as good as 0.0001
Sum of reward amount fields is equal to block reward and for each share is calculated proportional to its difficulty score
Prepared Block: It is an ordinary bitcoin block with some exceptions
1- Its merkle root points to a  Net Merkle Tree
2- It is fixed to yield a hash that is as difficult as target difficulty * 0.05
Finalization Block: It is an ordinary bitcoin block with some exceptions
1- Its merkle root points to a  Net Merkle Tree
2- It is fixed to yield a hash that is as difficult as target difficulty * 0.02
3- It has a new field which is a pointer to (the hash of) a non empty Shared Coinbase Transaction
4- The Shared CoinBase Transaction's sum of difficulty scores is greater than or equal to 0.95
Mining process goes through 3 phases for each block:
Preparation Phase: It takes just few seconds for the miners to produce one or (barely) 2 or 3 Prepared Blocks typically. Note that the transaction fees are already transferred to miner's wallet through coinbase transaction committed to the Net Merkle Tree's root for each block.
Contribution Phase: Miners start picking one valid Prepared Block's Merkle root, according to their speculations (which become more accurate as new shares are submitted to the network) about it to get enough shares eventually, and producing/relaying valid Contribution Shares for it.
As the sum of the difficulty scores for a given Prepared Block's Merkle root grows we expect an exponential convergence rate for the most popular Merkle root to be included in Contribution Shares. 
Finalization Phase: After the total scores approaches the 0.93 limit, rational Miners would begin to produce a Finalized block
Verification process involves:
Checking both the hash of the finalized block and all of its Shared Coinbase Transaction items to satisfy network difficulty target cumulatively
Checking reward distribution in the shared coinbase transaction
Checking Merkle tree to be Net
UTXO calculation is extended to include Shared Coinbase Transactions committed to finalized blocks on the blockchain as well
Attacks/forks brief analysis:
Short range attacks/unintentional forks that try to change the Merkle root are as hard as they are in traditional PoW networks
Short range attacks/unintentional forks that preserve the Merkle root but try to change the Shared CoinBase Transaction has  zero side effects on the users (not the miners) and as of redistributing the shares in favor of the forking miner, they are poorly incentivized as gains won't go anything further than like %2-%10  redistribution ever.
Long Range attacks with a total rewrite agenda will fail just like Traditional PoW 
Long Range attacks with partial coinbase rewrite are again poorly incentivized and the costs won't be justified

Implementation

This is a radical improvement to classical PoW, I admit, but the costs involved are fair for the huge impacts and benefits. I have reviewed the bitcoin Core's code and found it totally feasible and practical form the sole programming perspective. Wallets could easily be upgraded to support the new algorithm as well,  but a series of more complicated issues, mostly political are extremely discouraging but it is just too soon to give up and go for a fresh start with a new coin, or just manage for an immature fork with little support, imo.

Before any further decisions, it would be of high value to have enough feedback from the community. Meanwhile I'll be busy coding canonical parts as a BIP for bitcoin blockchain, I think it takes like 2-3 weeks or even a bit more because I'm not part of the team and have to absorb a lot before producing anything useful, plus, I'm not full time, yet Wink

I have examined the proposed algorithm's feasibility as much as I could, yet I can imagine there might be some flaws overlooked, and the readers are welcome to improve it. Philosophical comments questioning the whole idea of eliminating pools don't look to be constructive tho. Thank you.


Major Edits and Protocol Improvements:
June 10, 2018 09:30 pm Inspired by a discussion with @ir.hn

A Prepared Block should be saved in the fullnodes for a long period of time enough to mitigate any cheating attempt to avoid Preparation Phase and using non-prepared, trivially generated Net Merkle Roots.   
Full nodes MAY respond to a query by peers asking for a block's respected Prepared Block if they have decided to save the required data long enough
For the latest 1000 blocks preserving such a data is mandatory.
For blocks with an accumulated difficulty harder than or equal to the respected network difficulty, it would be unnecessary to fulfil the above requirement.*
Prepared Block and Preparation phase terms replaced the original Initiation Block and Initiation Phase terms respectively to avoid ambiguity
Notes:
* This is added to let miners with large enough hash powers choose not to participate in collaborative work.
reserved for future upgrades
July 3, 2018 02:20 pm inspired by discussions with @anunimint

A special  transaction was added to Shared CoinBase Transaction to guarantee/adjust proper reward for the finder of Prepared Block and some enhancements were made to include both block reward and transaction fees (partially) in the final calculations.
In Finalization Phase, miners should calculate a total reward for the miner of its respected Prepared Block as follows: 
preparedBlockReward = blockReward *0.04 + totalTransactionFees *0.3
Shared Coin Base Transaction should include one input/output address-amount pair that adjusts the amount of reward assigned to the Prepared Block Miner in the ordinary coinbase transaction
All the calculations needed for calculating rewards assigned to the miners of finalized block and shares will be carried out on the sum of network block reward and 70% of transaction fees collected in transactions that are committed to Net Merkle Tree
Note:
 This change is made to both guarantee a minimum reward for miners of Prepared Blocks and incentivize them for including more transactions with higher fees 
reserved for future upgrades
███▌
 ▐██▌
   ███
    ▐██▌
      ███
 ███   ▐██▌                  ██
 ████    ███               ████
 █████▌   ▐██▌           █████
 ███ ███    ███        ████ ███
 ███  ▐██▌   ▐██▌    ████   ███
 ███    ███    ██ ████     ███
 ███     ▐██▌   █████       ███
 ███       ███   ▐█▌        ███
 ███        ▐██▌            ███
 ███          ███           ███
 ███           ███         ███
                 ▐██▌
                  ▐██
                    ██▌
                      ████




..DIGITAL CRYPTO.............
..WEALTH MANAGEMENT..
..PLATFORM.......................

██
██
██
██
██
██
██
██
██
██
██
██
██

██
██
██
██
██
██
██
██
██
██
██
██
██

        ▄▄████████▄▄
     ▄████████████████▄
   ▄████████████████████▄
  ███████████████▀▀  ████
 ████████████▀▀      ██████
▐████████▀▀   ▄▄     ██████▌
▐████▀▀    ▄█▀▀     ███████▌
▐████████ █▀        ███████▌
 ████████ ▄███▄   ███████
  ████████████████▄▄██████
   ▀████████████████████▀
     ▀████████████████▀
        ▀▀████████▀▀

Altcoins Talks - Cryptocurrency Forum

Getting rid of pools: Proof of Collaborative Work
« on: July 06, 2018, 08:05:07 AM »

This is an Ad. Advertised sites are not endorsement by our Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise Here Ads bidding Bidding Open


Offline sugarchrisp

  • Hero Member
  • *
  • Activity: 847
  • points:
    5443
  • Karma: 16
  • Beyond Protocol Street Team
  • Trade Count: (0)
  • Referrals: 0
  • Last Active: July 09, 2021, 04:21:10 PM
    • View Profile

  • Total Badges: 19
    Badges: (View All)
    10 Posts First Post Fifth year Anniversary
Re: Getting rid of pools: Proof of Collaborative Work
« Reply #1 on: July 06, 2018, 09:01:30 AM »
Proof of Collaborative Work

A proposal for eliminating the necessity of pool mining in bitcoin and other PoW blockchains

Motivation
For bitcoin and the altcoins which are based on common PoW principles,  centralization of mining through using pools, is both inevitable and unfortunate and puts all the reasonings that support the security of PoW in a paradoxical, fragile situation.

A same problem does exist with PoS networks. Things can get even worse  there because of the fact that most PoS based systems enforce long run deposit strategies for miners that is highly discouraging for them to migrate from one pool to another because of the costs involved.

Satoshi Nakamoto's implementation of PoW that is the core of bitcoin client software is based on a winner-takes-all strategy which is the fundamental factor behind two critical flaws: mining variance and proximity premium which are the most important forces that participate in forming pooling pressure.

Until now, both mining variance and proximity premium are known to be unavoidable and hence pooling pressure is considered an inherent flaw for bitcoin and other PoW based currencies.

In this proposal, we are suggesting an alternative variant of PoW in which the traditional winner-takes-all is replaced with a collaborator-takes-share strategy.

The problem of solo mining becoming too risky and impractical for small mining facilities appeared in 2010, less than 2 years after bitcoin had been launched. It was the worst timing ever, although Satoshi Nakamoto made a comment on bitcointalk about first pool proposals,  it was among the latest posts Satoshi made and he just disappeared few days later from this forum, forever, without making a serious contribution to the subject.

This way, the confused community came out with an unbelievable solution for such a critical problem, a second layer centralized protocol, named pooling, boosted by greed and ignorance, supported by junior hackers who as usual missed the forest.

Bitcoin was just 2 years old when pooling age began and eventually dominated almost all the hashpower of the network.

A quick review of Slush thread in which Satoshi has made the above referenced reply, could reveal how immature and naive this solution was and has been discussed and how it has been adopted: In a rush with an obvious greed.
Nobody ever mentioned the possibility of an algorithm tweak to keep PoW decentralized. Instead everybody was talking about how practical was such a centralized service while the answer was more than obvious:
Yes! you can always do everything with a centralized service, don't bother investigating. 

Anyway, in the thread, one couldn't find any arguments about the centralization consequences or the possibility of alternative approaches including the core algorithm improvements Shocked

I think it is not fair. PoW is great and can easily be improved to eliminate such a paradoxically centralized second layer solution. This proposal, Proof of Collaborative Work (PoCW) is an example of inherent possibilities and capacities of PoW. I didn't find any similar proposal and it looks to be original but If there is a history, I'll be glad to be informed about. Smiley

The Idea is accepting and propagating works with hundreds of thousands times lower difficulties and accumulating them as a proof of work for a given transaction set, letting miners with a very low shares of hash power ( say of orders like 10-6) to participate directly in the network and yet experience and monitor their performance on an hourly basis.



Imo, now, after almost a decade being passed, Moore law has done enough to make it feasible utilizing more bandwidth and storage resources and it seems to me kinda hypocritic to make arguments about 'poor miners' and pretending to be concerned about centralization threats and making excuses so for rejecting this very specific proposal that although increases the demand for such resources, can radically disrupt current situation with pools and centralized mining.

This proposal is mainly designed for bitcoin. For the sake of convenience and letting the readers to have a more specific perception of the idea, I have deliberately used constants instead of adjustable parameters.

Outlines
An immediate but not practically feasible approach can be reducing blocktime (along with proportional reduction in block reward). Although this approach, as mentioned, can not be applied because of network propagation problems involved, but a very excellent consequence would be its immediate impact on the scalability problem if employed, we will use it partially (reducing blocktime to 1 minute compared to current 10 minutes period).
As  mentioned earlier (and with all due respects to Core team), I don't take objections about the storage and network requirements implications and consequences of reducing blocktime as a serious criticism. We should not leave mining in hands of 5 mining pools to support a hypothetical poor miner/full node owner who can not afford installing a 1 terabyte HD in next 2 years!.
Also note, blocktime reduction is not a necessary part of PoCW, the proposed algorithm, I'm just including it as one of my old ideas (adopted from another forum member who suggested it as an alternative to infamous block size debate and later has been developed a bit more by me) which I think deserves more investigation and discussion.
PoCW uses a series of mining relevant data structures to be preserved on the blockchain or transmitted as network messages
Net Merkle Tree: It is an ordinary Merkle hash tree of transactions with the exception that its coinbase transaction shows no block reward (newly published coins) instead the miner charges all transaction fees to his account (supports SegWit)
Collaboration Share: it is  a completely new data structure composed of following fields:
1- The root of a Net Merkle Tree
2- Collaborating miner's wallet address
3- A nonce
calculated difficulty using previous block hash padded with all previous fields, it is always assumed to be at least as hard as 0.0001 compared to current block difficulty
Coinbase Share: it is new too and is composed of
1- A Collaborating miner's wallet address
2- A nonce
3- A computed difficulty score using the hash of
previous block's hash padded with
current block's merkle root, padded with
Collaborating miner's address padded with the nonce field
4-  A reward amount field
Shared Coinbase Transaction: It is a list of Coinbase Shares 
First share's difficulty score field is fixed to be  2%
For each share difficulty score is at least as good as 0.0001
Sum of reward amount fields is equal to block reward and for each share is calculated proportional to its difficulty score
Prepared Block: It is an ordinary bitcoin block with some exceptions
1- Its merkle root points to a  Net Merkle Tree
2- It is fixed to yield a hash that is as difficult as target difficulty * 0.05
Finalization Block: It is an ordinary bitcoin block with some exceptions
1- Its merkle root points to a  Net Merkle Tree
2- It is fixed to yield a hash that is as difficult as target difficulty * 0.02
3- It has a new field which is a pointer to (the hash of) a non empty Shared Coinbase Transaction
4- The Shared CoinBase Transaction's sum of difficulty scores is greater than or equal to 0.95
Mining process goes through 3 phases for each block:
Preparation Phase: It takes just few seconds for the miners to produce one or (barely) 2 or 3 Prepared Blocks typically. Note that the transaction fees are already transferred to miner's wallet through coinbase transaction committed to the Net Merkle Tree's root for each block.
Contribution Phase: Miners start picking one valid Prepared Block's Merkle root, according to their speculations (which become more accurate as new shares are submitted to the network) about it to get enough shares eventually, and producing/relaying valid Contribution Shares for it.
As the sum of the difficulty scores for a given Prepared Block's Merkle root grows we expect an exponential convergence rate for the most popular Merkle root to be included in Contribution Shares. 
Finalization Phase: After the total scores approaches the 0.93 limit, rational Miners would begin to produce a Finalized block
Verification process involves:
Checking both the hash of the finalized block and all of its Shared Coinbase Transaction items to satisfy network difficulty target cumulatively
Checking reward distribution in the shared coinbase transaction
Checking Merkle tree to be Net
UTXO calculation is extended to include Shared Coinbase Transactions committed to finalized blocks on the blockchain as well
Attacks/forks brief analysis:
Short range attacks/unintentional forks that try to change the Merkle root are as hard as they are in traditional PoW networks
Short range attacks/unintentional forks that preserve the Merkle root but try to change the Shared CoinBase Transaction has  zero side effects on the users (not the miners) and as of redistributing the shares in favor of the forking miner, they are poorly incentivized as gains won't go anything further than like %2-%10  redistribution ever.
Long Range attacks with a total rewrite agenda will fail just like Traditional PoW 
Long Range attacks with partial coinbase rewrite are again poorly incentivized and the costs won't be justified

Implementation

This is a radical improvement to classical PoW, I admit, but the costs involved are fair for the huge impacts and benefits. I have reviewed the bitcoin Core's code and found it totally feasible and practical form the sole programming perspective. Wallets could easily be upgraded to support the new algorithm as well,  but a series of more complicated issues, mostly political are extremely discouraging but it is just too soon to give up and go for a fresh start with a new coin, or just manage for an immature fork with little support, imo.

Before any further decisions, it would be of high value to have enough feedback from the community. Meanwhile I'll be busy coding canonical parts as a BIP for bitcoin blockchain, I think it takes like 2-3 weeks or even a bit more because I'm not part of the team and have to absorb a lot before producing anything useful, plus, I'm not full time, yet Wink

I have examined the proposed algorithm's feasibility as much as I could, yet I can imagine there might be some flaws overlooked, and the readers are welcome to improve it. Philosophical comments questioning the whole idea of eliminating pools don't look to be constructive tho. Thank you.


Major Edits and Protocol Improvements:
June 10, 2018 09:30 pm Inspired by a discussion with @ir.hn

A Prepared Block should be saved in the fullnodes for a long period of time enough to mitigate any cheating attempt to avoid Preparation Phase and using non-prepared, trivially generated Net Merkle Roots.   
Full nodes MAY respond to a query by peers asking for a block's respected Prepared Block if they have decided to save the required data long enough
For the latest 1000 blocks preserving such a data is mandatory.
For blocks with an accumulated difficulty harder than or equal to the respected network difficulty, it would be unnecessary to fulfil the above requirement.*
Prepared Block and Preparation phase terms replaced the original Initiation Block and Initiation Phase terms respectively to avoid ambiguity
Notes:
* This is added to let miners with large enough hash powers choose not to participate in collaborative work.
reserved for future upgrades
July 3, 2018 02:20 pm inspired by discussions with @anunimint

A special  transaction was added to Shared CoinBase Transaction to guarantee/adjust proper reward for the finder of Prepared Block and some enhancements were made to include both block reward and transaction fees (partially) in the final calculations.
In Finalization Phase, miners should calculate a total reward for the miner of its respected Prepared Block as follows: 
preparedBlockReward = blockReward *0.04 + totalTransactionFees *0.3
Shared Coin Base Transaction should include one input/output address-amount pair that adjusts the amount of reward assigned to the Prepared Block Miner in the ordinary coinbase transaction
All the calculations needed for calculating rewards assigned to the miners of finalized block and shares will be carried out on the sum of network block reward and 70% of transaction fees collected in transactions that are committed to Net Merkle Tree
Note:
 This change is made to both guarantee a minimum reward for miners of Prepared Blocks and incentivize them for including more transactions with higher fees 
reserved for future upgrades


Isn't all this completely ripped from a bitcoin talk post?   At least source it if you're using their material <3
Beyond Protocol Street Team
http://beyond.link | Coming Fall 2021
Official altcoinstalks thread

 

ETH & ERC20 Tokens Donations: 0x2143F7146F0AadC0F9d85ea98F23273Da0e002Ab
BNB & BEP20 Tokens Donations: 0xcbDAB774B5659cB905d4db5487F9e2057b96147F
BTC Donations: bc1qjf99wr3dz9jn9fr43q28x0r50zeyxewcq8swng
BTC Tips for Moderators: 1Pz1S3d4Aiq7QE4m3MmuoUPEvKaAYbZRoG
Powered by SMFPacks Social Login Mod