Devrandom [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-02 📝 Original message:I am also concerned. ...

📅 Original date posted:2017-11-02
📝 Original message:I am also concerned. However, this proposal allows two POWs to coexist and
allows for gradual transitions. This is hopefully a less disruptive
approach since it allows cooperative miners to migrate over time. And of
course, as a soft-fork it keeps backwards compatibility with existing
software.

On Thu, Nov 2, 2017 at 4:55 PM Tao Effect <contact at taoeffect.com> wrote:

> 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> 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 )
>
> # 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
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20171103/d8fa3100/attachment.html>;