Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6FE2C361C for ; Tue, 30 Oct 2018 04:41:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f181.google.com (mail-it1-f181.google.com [209.85.166.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3309EA7 for ; Tue, 30 Oct 2018 04:41:08 +0000 (UTC) Received: by mail-it1-f181.google.com with SMTP id r5-v6so10311002ith.2 for ; Mon, 29 Oct 2018 21:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=AJxjpaEvhb5+PT+LVLrSCZwf1Q0d7e8kJQ38MuzIqHw=; b=mKuCj+UVzlrxaWb3WQBf1BOpMRo/+ojklhp4psAbdBTJRJJfZNL5LPiKl7VZWonnYo DvPaBrZcdIkBZnNVI+1+OUIOBpkDVF0e5edDD/cztfEQ8csiuR/IV/pqHuNEtbCbk/17 CT8dW3LBB7jJanIdH2Z+oPyMWfskDC01Y45bUC0eltsuTYAqsRr0lmC8fh8ZxmFDifLS k+GwV9TBOM2bNvcKWy9T0TqwJboQ6LR9oAoVEzjCKFOd0k4kETc1ZPoLeECMJbz+GKCi 6h8/HNWeNeed52mgSt53raL2jvIymGEWaamgYMfeNNAaiEDXcvj70NLN6Be/qG3BIpRG Z0kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AJxjpaEvhb5+PT+LVLrSCZwf1Q0d7e8kJQ38MuzIqHw=; b=N6sqtMp71QFyCqiRhnrw20AJdy3m8mLokx/AE/oIySaWAOOR0/5PLkGjY5fJEHqzYG mOrBkekamVVI69jdaIUTMMDegNWWWS8w93v9oPXw02lXVXg6gmtlWCajN+/Hgbrx9O9X b/K5/IUHQVPc5ddACtv1kLCBS+XjdLZXyxOEyCLM4HLwAburPfKg2IdRqM6RCunIjMPz CZap/XS/+1NI31V5bCP/R79firInAc3OEm8D6Dc+bSSYRSzBoGMiDVUtRK01Ly5CASL6 nqlCv2fEeOrwfXnkEYGb8XkfkeK135HdcPqKPxkhGWOczBq2IGh1ggnc36sTXFjjZB5d V8tw== X-Gm-Message-State: AGRZ1gJRYjKOGrelPSELrMT+LDLjlZHDKKHsytZEE/4ug923bGf41p0p vWkv+EfqvswJkLoEMQ47N8IUnkDz00gZSYAPmSFAp7x9 X-Google-Smtp-Source: AJdET5eMUkQ27ZhJktYR9Yr/YLqBLTvH3Vt8bc3guJirewz595X4USC4kKgCAq0a0BjGC7y76ihyZa35RdG54tQ7+m8= X-Received: by 2002:a24:9886:: with SMTP id n128-v6mr406173itd.7.1540874467113; Mon, 29 Oct 2018 21:41:07 -0700 (PDT) MIME-Version: 1.0 From: Max Hastings Date: Mon, 29 Oct 2018 23:40:54 -0500 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000004181a405796acb68" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 31 Oct 2018 04:44:23 +0000 Subject: [bitcoin-dev] Proposal to modify POW protocol to improve network decentralization. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 04:41:09 -0000 --0000000000004181a405796acb68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wrote up a proposal that modifies the proof of work protocol to improve decentralization, by encouraging miners to move from larger pools to smaller pools or even mining solo, while still receiving a regular stream of income. You can read my proposal here: https://drive.google.com/open?id=3D1vkk7yI7F2QGDIBhHf_aYVHzpWrcaPVZA I am looking for feedback on the idea. Thanks, Max ---------------------------------------------------------------------------= ------- Mining Share Transactions Max Hastings *Abstract*=E2=80=94One of the challenges Bitcoin continues to face is the t= endency of the network becoming more centralized over time as miners join pools rather than mining solo. As of this writing the four biggest pools control over 51% of the total networking hash power, with the largest of the four controlling almost 20%. This paper will discuss a possible modification to the current Proof of Work protocol that Bitcoin and other cryptocurrencies use that will help incentivize miners to mine solo or join a smaller pool, rather than joining the largest pools. *1. **What is Pool Mining?* Under the proof of work protocol miners compete with one another to mine the next block by hashing a block header, then making small changes to the nonce or timestamp to get a different hash value each time the data is hashed. Miners will do this until the resulting hash value is below the current difficulty target. At that point the miner has successfully solved a block, which then is propagated across the network and validated by each node. This proof of work system works as a lottery that a miner can win for every block. In Bitcoin=E2=80=99s case a new block is found on average ever= y 10 minutes. Currently there=E2=80=99s an estimated number of 100,000 miners on= the Bitcoin network with a combined hash power of 50 million TH/s. With that many participants with that much hash power, the average time it takes for a miner to solve a block by themselves can take a long time. Most miners demand a more consistent stream of income rather than waiting to win the lottery. They currently achieve this in one of two ways, centralized pool mining and p2pool mining. Centralized pool mining works by a pool operator hosting a full node, generating a block header for the next block and distributing the block header to their pool miners to start hashing. The miners on the pool will occasionally submit what is known as =E2=80=9Cshare= s=E2=80=9D which is a hash that solves a lower difficulty than what the block needs to be solved, back to the pool operator. The purpose of this is to prove to the pool operator that you are completing work. Every so often a miner on the pool will solve a share that also solves the block which the pool operator will then propagate across the network. The pool operator will then distribute the block reward to all miners based on the number of shares they have contributed. *2. **How Pool Mining centralizes the Blockchain* When a miner joins a pool they mine the block header that is given to them by the pool operator. The pool operator has full control over which transactions will go inside the block. This gives the pool operator the ability to maliciously use the entire hashing power of the pool to attempt a double spend attack on the network, if desired. The largest Bitcoin mining pool has 20% of the total network hashing power. This is not enough power to even attempt a double spend attack, however if multiple large pools conspire they could easily conduct a double spend attack on the network. It doesn=E2=80=99t take more than a few bad pool operators to coll= ude with one another to conduct a harmful double spend attack on the network. *3. **Mining Share Transactions* Mining share transactions help incentivize miners to mine solo instead of joining a pool while still retaining the same benefits of receiving a continuous stream of small rewards rather than having to mine an entire block. Mining shares also significantly change how consensus happens on the blockchain. To mine the next block, miners first create mining share transactions which represent the work of having mined a fraction of the next block. Each block is required to contain X number of mining share transactions for it to be considered valid. This is the reason why all nodes on the network start mining the next block by first mining share transactions. Each mining share transaction contains two crucial pieces of data. The hash of the previous block, and a transaction output. After a node receives or creates X amount of mining share transactions for the next block, the nodes will begin to hash a block header which will contain X amount of mining share transactions in addition to the normal transactions. Keep in mind, the target difficulty for generating a valid block header and a mining share are equal. *4. **Maintaining a Blockchain Consensus* A block header contains the Merkle root which contains the transactions that are in a block. Traditionally the block header is backed by 100% of the mining work by the network, but with mining shares the block header is only backed by a fraction of the total work, precisely 1 / (X + 1). Where X is the total number of mining share transactions required in each block. It will be common to have multiple competing block headers broadcasted shortly after X amount of mining share transactions have been mined. However, after a node receives a valid block, it will begin mining new share transactions on to that chain. If multiple valid blocks are received by the node, they will have to pick which fork to mine off of. As mining share transactions are broadcasted throughout the network, nodes will mine off the fork that has the best chance at reaching X amount of mining share transactions first so that the next block can be mined. For example, block A, and block B are both valid blocks which creates a fork on the chain. As nodes start generating mining shares for either fork they will be continuously monitoring the competing forks for how many mining shares they currently have. Nodes will switch to the fork with the most work behind it based on the number of mining share transactions already mined. This will allow the blockchain network to reach a consensus fairly quickly as nodes monitor the number of mining share transactions coming in for multiple competing blocks= . *5. **How to measure Transaction Confirmations.* Traditionally the confirmation number for transactions are calculated based on the depth that the transaction is in the chain. For example, if the transaction is in the block at height 10, and the current block height is 15, then the number of confirmations for that transaction is 6. With mining share transactions, confirmations are measured differently since the block only represents a fraction of the total work. For example, if X is 99, meaning each block needs 99 mining share transactions to be considered valid, then each block and mining share transaction is equal to 0.01 confirmations. If Transaction A is in block 1, and there are currently 49 mining share transactions mined for block 2 then transaction A has a confirmation number of 0.5. If block 2 is already mined and there are 49 mining shares for block 3, then transaction A would have a confirmation number of 1.5. *6. **Conclusion* One of the unique attributes of Bitcoin is that it is a decentralized digital currency. It is important to keep Bitcoin and other cryptocurrency networks as decentralized as possible to prevent bad actors from performing a double spend attack on the network. With mining share transactions, users are encouraged to mine solo rather than mining on a pool while still retaining a predictable stream of income. With a more decentralized network, it makes it more difficult for bad actors to attack the network. Mining share transactions modifies the proof of work protocol in a way that changes how blockchain consensus happens. Nodes monitor the number of share transactions for competing blocks and contribute to the fork that has the most. This allows for consensus to happen fairly quickly after competing blocks are broadcasted. Confirmations also have to be measured differently so that users receiving transactions can accurately figure out how confident they should be that their transaction is final. Mining share transactions will increase the security and the integrity of the blockchain network by making it more decentralized. --0000000000004181a405796acb68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wrote up a proposal that modifies the proof of work= protocol to improve decentralization, by encouraging=C2=A0miners to move f= rom larger pools to smaller pools or even mining solo, while still receivin= g a regular stream of income.

You can read my proposal here:
https://drive.google.com/open?id=3D1vkk7yI7F2QGDIBhHf_a= YVHzpWrcaPVZA

I am looking for feedback on the= idea.

Thanks,
Max

<= div>-----------------------------------------------------------------------= -----------

Mining Share Transactions

= Max Hastings<= /span>

= =C2=A0=

Abstract=E2= =80=94One of the challenges Bitcoin continues to face is the tendency of the network becoming more centralized over time as miners join pools rather than mining solo. As of this writing the four biggest pools control over 51% of the tot= al networking hash power, with the largest of the four controlling almost 20%. This paper will discuss a possible modification to the current Proof of Wor= k protocol that Bitcoin and other cryptocurrencies use that will help incenti= vize miners to mine solo or join a smaller pool, rather than joining the largest pools.

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 What is Pool Mining?

Under the proof of work protocol miners compete with one another to mine the next block by has= hing a block header, then making small changes to the nonce or timestamp to get = a different hash value each time the data is hashed. Miners will do this unti= l the resulting hash value is below the current difficulty target. At that po= int the miner has successfully solved a block, which then is propagated across = the network and validated by each node. This proof of work system works as a lottery that a miner can win for every block. In Bitcoin=E2=80=99s case a n= ew block is found on average every 10 minutes. Currently there=E2=80=99s an estimated n= umber of 100,000 miners on the Bitcoin network with a combined hash power of 50 mill= ion TH/s. With that many participants with that much hash power, the average ti= me it takes for a miner to solve a block by themselves can take a long time. M= ost miners demand a more consistent stream of income rather than waiting to win= the lottery. They currently achieve this in one of two ways, centralized pool mining and p2pool mining. Centralized pool mining works by a pool operator hosting a full node, generating a block header for the next block and distributing the block header to their pool miners to start hashing. The mi= ners on the pool will occasionally submit what is known as =E2=80=9Cshares=E2=80= =9D which is a hash that solves a lower difficulty than what the block needs to be solved, back= to the pool operator. The purpose of this is to prove to the pool operator tha= t you are completing work. Every so often a miner on the pool will solve a sh= are that also solves the block which the pool operator will then propagate acro= ss the network. The pool operator will then distribute the block reward to all miners based on the number of shares they have contributed.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 How Pool Mining centralizes the Blo= ckchain

When a miner joins a pool they = mine the block header that is given to them by the pool operator. The pool operator = has full control over which transactions will go inside the block. This gives t= he pool operator the ability to maliciously use the entire hashing power of th= e pool to attempt a double spend attack on the network, if desired. The large= st Bitcoin mining pool has 20% of the total network hashing power. This is not enough power to even attempt a double spend attack, however if multiple lar= ge pools conspire they could easily conduct a double spend attack on the netwo= rk. It doesn=E2=80=99t take more than a few bad pool operators to collude with one= another to conduct a harmful double spend attack on the network.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Mining Share Transactions

Mining share transactions help = incentivize miners to mine solo instead of joining a pool while still retaining the sam= e benefits of receiving a continuous stream of small rewards rather than havi= ng to mine an entire block. Mining shares also significantly change how consen= sus happens on the blockchain. To mine the next block, miners first create mini= ng share transactions which represent the work of having mined a fraction of t= he next block. Each block is required to contain X number of mining share transactions for it to be considered valid. This is the reason why all node= s on the network start mining the next block by first mining share transactions.= Each mining share transaction contains two crucial pieces of data. The hash of t= he previous block, and a transaction output. After a node receives or creates = X amount of mining share transactions for the next block, the nodes will begi= n to hash a block header which will contain X amount of mining share transaction= s in addition to the normal transactions. Keep in mind, the target difficulty fo= r generating a valid block header and a mining share are equal.

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Maintaining a Blockchain Consensus<= /span>

A block header contains the Mer= kle root which contains the transactions that are in a block. Traditionally the bloc= k header is backed by 100% of the mining work by the network, but with mining shares the block header is only backed by a fraction of the total work, precisely 1 / (X + 1). Where X is the total number of mining share transact= ions required in each block. It will be common to have multiple competing block headers broadcasted shortly after X amount of mining share transactions hav= e been mined. However, after a node receives a valid block, it will begin min= ing new share transactions on to that chain. If multiple valid blocks are recei= ved by the node, they will have to pick which fork to mine off of. As mining sh= are transactions are broadcasted throughout the network, nodes will mine off th= e fork that has the best chance at reaching X amount of mining share transact= ions first so that the next block can be mined. For example, block A, and block = B are both valid blocks which creates a fork on the chain. As nodes start generating mining shares for either fork they will be continuously monitori= ng the competing forks for how many mining shares they currently have. Nodes w= ill switch to the fork with the most work behind it based on the number of mini= ng share transactions already mined. This will allow the blockchain network to reach a consensus fairly quickly as nodes monitor the number of mining shar= e transactions coming in for multiple competing blocks.

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 How to measure Transaction Confirma= tions.

Traditionally the confirmation = number for transactions are calculated based on the depth that the transaction is in t= he chain. For example, if the transaction is in the block at height 10, and th= e current block height is 15, then the number of confirmations for that trans= action is 6. With mining share transactions, confirmations are measured differentl= y since the block only represents a fraction of the total work. For example, = if X is 99, meaning each block needs 99 mining share transactions to be consider= ed valid, then each block and mining share transaction is equal to 0.01 confirmations= . If Transaction A is in block 1, and there are currently 49 mining share transactions mined for block 2 then transaction A has a confirmation number= of 0.5. If block 2 is already mined and there are 49 mining shares for block 3= , then transaction A would have a confirmation number of 1.5.

6.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Conclusion

One of the unique attributes of= Bitcoin is that it is a decentralized digital currency. It is important to keep Bitcoi= n and other cryptocurrency networks as decentralized as possible to prevent b= ad actors from performing a double spend attack on the network. With mining sh= are transactions, users are encouraged to mine solo rather than mining on a poo= l while still retaining a predictable stream of income. With a more decentral= ized network, it makes it more difficult for bad actors to attack the network. Mining share transactions modifies the proof of work protocol in a way that= changes how blockchain consensus happens. Nodes monitor the number of share transactions for competing blocks and contribute to the fork that has the m= ost. This allows for consensus to happen fairly quickly after competing blocks a= re broadcasted. Confirmations also have to be measured differently so that use= rs receiving transactions can accurately figure out how confident they should = be that their transaction is final. Mining share transactions will increase th= e security and the integrity of the blockchain network by making it more decentralized.

--0000000000004181a405796acb68--