rich1.0npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3https://nostr.ae/npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3njumphttps://nostr.ae📅 Original date posted:2017-11-02 📝 Original message: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>