[bitcoin-dev] Introducing a POW through a soft-fork

Thu Nov 2 23:55:55 UTC 2017

Just going to throw in my support for a POW change, not any particular implementation, but the idea.

Bitcoin is technically owned by China now. That's not acceptable.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
> Hi all,
> 
> Feedback is welcome on the draft below.  In particular, I want to see if there is interest in further development of the idea and also interested in any attack vectors or undesirable dynamics.
> 
> (Formatted version available here: https://github.com/devrandom/btc-papers/blob/master/aux-pow.md <https://github.com/devrandom/btc-papers/blob/master/aux-pow.md> )
> 
> # Soft-fork Introduction of a New POW
> 
> ## Motivation:
> 
> - Mitigate mining centralization pressures by introducing a POW that does not have economies of scale
> - Introduce an intermediary confirmation point, reducing the impact of mining power fluctuations
> 
> Note however that choice of a suitable POW will require deep analysis.  Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are not, unexpected/covert optimization.
> 
> In particular, unexpected/covert optimizations, such as ASCIBOOST, present a potential centralizing and destabilizing force.
> 
> ## Design
> 
> ### Aux POW intermediate block
> 
> Auxiliary POW blocks are introduced between normal blocks - i.e. the chain alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain all transactions from the aux-POW block.
> Block space is not increased.
> 
> The new intermediate block and the pointers are introduced via a soft-fork restriction.
> 
> ### Reward for aux POW miners
> 
> The reward for the aux POW smoothly increases from zero to a target value (e.g. 1/2 of the total reward) over time.
> The reward is transferred via a soft-fork restriction requiring a coinbase output to an address published in the
> aux-POW block.
> 
> ### Aux POW difficulty adjustment
> 
> Difficulty adjustments remain independent for the two POWs.
> 
> The difficulty of the aux POW is adjusted based on the average time between normal block found
> to aux block found.
> 
> Further details are dependent on the specific POW.
> 
> ### Heaviest chain rule change
> 
> This is a semi-hard change, because non-upgraded nodes can get on the wrong chain in case of attack.  However,
> it might be possible to construct an alert system that notifies non-upgraded nodes of an upcoming rule change.
> All blocks are still valid, so this is not a hardforking change.
> 
> The heaviest chain definition changes from sum of `difficulty` to sum of:
> 
>     mainDifficulty ^ x * auxDifficulty ^ y
> 
> where we start at:
> 
>     x = 1; y = 0
> 
> and end at values of x and y that are related to the target relative rewards.  For example, if the target rewards
> are equally distributed, we will want ot end up at:
> 
>     x = 1/2; y = 1/2
> 
> so that both POWs have equal weight.  If the aux POW is to become dominant, x should end small relative to y.
> 
> 
> ## Questions and Answers
> 
> - What should be the parameters if we want the aux POW to have equal weight? A: 1/2 of the reward should be transferred
> to aux miners and x = 1/2, y = 1/2.
> 
> - What should be the parameters if we want to deprecate the main POW?  A: most of the reward should be transferred to
> aux miners and x = 0, y = 1.  The main difficulty will tend to zero, and aux miners will just trivially generate the
> main block immediately after finding an aux block, with identical content.
> 
> - Wasted bandwidth to transfer transactions twice?  A: this can be optimized by skipping transactions already
> transferred.
> 
> - Why would miners agree to soft-fork away some of their reward?  A: they would agree if they believe that
> the coins will increase in value due to improved security properties.
> 
> ## Open Questions
> 
> - After a block of one type is found, we can naively assume that POW will become idle while a block of the other type is being mined.  In practice, the spare capacity can be used to find alternative ("attacking") blocks or mine other coins.  Is that a problem?
> - Is selfish mining amplified by this scheme for miners that have both types of hardware?
> 
> ## POW candidates
> 
> - SHA256 (i.e. use same POW, but introduce an intermediate block for faster confirmation)
> - Proof of Space and Time (Bram Cohen)
> - Equihash
> - Ethash
> 
> ## Next Steps
> 
> - evaluate POW candidates
> - evaluate difficulty adjustment rules
> - simulate miner behavior to identify if there are incentives for detrimental behavior patterns (e.g. block withholding / selfish mining)
> - Protocol details
> 
> ## Credits
> 
> Bram Cohen came up with a similar idea back in March:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/7d5311c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/7d5311c6/attachment-0001.sig>