{"type":"rich","version":"1.0","author_name":"npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3","author_url":"https://nostr.ae/npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-11-02\n📝 Original message:Just going to throw in my support for a POW change, not any particular implementation, but the idea.\n\nBitcoin is technically owned by China now. That's not acceptable.\n\n- Greg\n\n--\nPlease do not email me anything that you are not comfortable also sharing with the NSA.\n\n\u003e On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Hi all,\n\u003e \n\u003e 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.\n\u003e \n\u003e (Formatted version available here: https://github.com/devrandom/btc-papers/blob/master/aux-pow.md \u003chttps://github.com/devrandom/btc-papers/blob/master/aux-pow.md\u003e )\n\u003e \n\u003e # Soft-fork Introduction of a New POW\n\u003e \n\u003e ## Motivation:\n\u003e \n\u003e - Mitigate mining centralization pressures by introducing a POW that does not have economies of scale\n\u003e - Introduce an intermediary confirmation point, reducing the impact of mining power fluctuations\n\u003e \n\u003e 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.\n\u003e \n\u003e In particular, unexpected/covert optimizations, such as ASCIBOOST, present a potential centralizing and destabilizing force.\n\u003e \n\u003e ## Design\n\u003e \n\u003e ### Aux POW intermediate block\n\u003e \n\u003e Auxiliary POW blocks are introduced between normal blocks - i.e. the chain alternates between the two POWs.\n\u003e Each aux-POW block points to the previous normal block and contains transactions just like a normal block.\n\u003e Each normal block points to the previous aux-POW block and must contain all transactions from the aux-POW block.\n\u003e Block space is not increased.\n\u003e \n\u003e The new intermediate block and the pointers are introduced via a soft-fork restriction.\n\u003e \n\u003e ### Reward for aux POW miners\n\u003e \n\u003e The reward for the aux POW smoothly increases from zero to a target value (e.g. 1/2 of the total reward) over time.\n\u003e The reward is transferred via a soft-fork restriction requiring a coinbase output to an address published in the\n\u003e aux-POW block.\n\u003e \n\u003e ### Aux POW difficulty adjustment\n\u003e \n\u003e Difficulty adjustments remain independent for the two POWs.\n\u003e \n\u003e The difficulty of the aux POW is adjusted based on the average time between normal block found\n\u003e to aux block found.\n\u003e \n\u003e Further details are dependent on the specific POW.\n\u003e \n\u003e ### Heaviest chain rule change\n\u003e \n\u003e This is a semi-hard change, because non-upgraded nodes can get on the wrong chain in case of attack.  However,\n\u003e it might be possible to construct an alert system that notifies non-upgraded nodes of an upcoming rule change.\n\u003e All blocks are still valid, so this is not a hardforking change.\n\u003e \n\u003e The heaviest chain definition changes from sum of `difficulty` to sum of:\n\u003e \n\u003e     mainDifficulty ^ x * auxDifficulty ^ y\n\u003e \n\u003e where we start at:\n\u003e \n\u003e     x = 1; y = 0\n\u003e \n\u003e and end at values of x and y that are related to the target relative rewards.  For example, if the target rewards\n\u003e are equally distributed, we will want ot end up at:\n\u003e \n\u003e     x = 1/2; y = 1/2\n\u003e \n\u003e so that both POWs have equal weight.  If the aux POW is to become dominant, x should end small relative to y.\n\u003e \n\u003e \n\u003e ## Questions and Answers\n\u003e \n\u003e - What should be the parameters if we want the aux POW to have equal weight? A: 1/2 of the reward should be transferred\n\u003e to aux miners and x = 1/2, y = 1/2.\n\u003e \n\u003e - What should be the parameters if we want to deprecate the main POW?  A: most of the reward should be transferred to\n\u003e aux miners and x = 0, y = 1.  The main difficulty will tend to zero, and aux miners will just trivially generate the\n\u003e main block immediately after finding an aux block, with identical content.\n\u003e \n\u003e - Wasted bandwidth to transfer transactions twice?  A: this can be optimized by skipping transactions already\n\u003e transferred.\n\u003e \n\u003e - Why would miners agree to soft-fork away some of their reward?  A: they would agree if they believe that\n\u003e the coins will increase in value due to improved security properties.\n\u003e \n\u003e ## Open Questions\n\u003e \n\u003e - 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?\n\u003e - Is selfish mining amplified by this scheme for miners that have both types of hardware?\n\u003e \n\u003e ## POW candidates\n\u003e \n\u003e - SHA256 (i.e. use same POW, but introduce an intermediate block for faster confirmation)\n\u003e - Proof of Space and Time (Bram Cohen)\n\u003e - Equihash\n\u003e - Ethash\n\u003e \n\u003e ## Next Steps\n\u003e \n\u003e - evaluate POW candidates\n\u003e - evaluate difficulty adjustment rules\n\u003e - simulate miner behavior to identify if there are incentives for detrimental behavior patterns (e.g. block withholding / selfish mining)\n\u003e - Protocol details\n\u003e \n\u003e ## Credits\n\u003e \n\u003e Bram Cohen came up with a similar idea back in March:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html \u003chttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html\u003e_______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/7d5311c6/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/7d5311c6/attachment-0001.sig\u003e"}