public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Max Hastings <max.jacob.hastings@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Proposal to modify POW protocol to improve network decentralization.
Date: Mon, 29 Oct 2018 23:40:54 -0500	[thread overview]
Message-ID: <CABPqyW=jOJo3edbvUUNRF2_5-vQSZ5AChPQ7TafWd5Mzv2MBWw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 8621 bytes --]

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=1vkk7yI7F2QGDIBhHf_aYVHzpWrcaPVZA

I am looking for feedback on the idea.

Thanks,
Max

----------------------------------------------------------------------------------

Mining Share Transactions

Max Hastings



*Abstract*—One 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 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’s case a new block is found on average every 10
minutes. Currently there’s 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 “shares” 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’t take more than a few bad pool operators to collude 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.

[-- Attachment #2: Type: text/html, Size: 14545 bytes --]

                 reply	other threads:[~2018-10-30  4:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABPqyW=jOJo3edbvUUNRF2_5-vQSZ5AChPQ7TafWd5Mzv2MBWw@mail.gmail.com' \
    --to=max.jacob.hastings@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox