diff options
| author | Enrique Arizón Benito <enrique.arizonbenito@gmail.com> | 2018-01-17 23:34:11 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-01-17 22:34:14 +0000 |
| commit | b4c0e15f4eb8f00b1859d0c253d3958d3c853307 (patch) | |
| tree | 34e81028891afee85512d1d30ed9bbe31e784fde | |
| parent | e38859df662d869d17569708ad02fdf9a119739d (diff) | |
| download | pi-bitcoindev-b4c0e15f4eb8f00b1859d0c253d3958d3c853307.tar.gz pi-bitcoindev-b4c0e15f4eb8f00b1859d0c253d3958d3c853307.zip | |
Re: [bitcoin-dev] Proposal to reduce mining power bill
| -rw-r--r-- | 87/0550e151c6c89aa12be4549eb3eda4b1c5189d | 587 |
1 files changed, 587 insertions, 0 deletions
diff --git a/87/0550e151c6c89aa12be4549eb3eda4b1c5189d b/87/0550e151c6c89aa12be4549eb3eda4b1c5189d new file mode 100644 index 000000000..ffad065df --- /dev/null +++ b/87/0550e151c6c89aa12be4549eb3eda4b1c5189d @@ -0,0 +1,587 @@ +Return-Path: <enrique.arizonbenito@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id B83AFF1E + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 17 Jan 2018 22:34:14 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-io0-f170.google.com (mail-io0-f170.google.com + [209.85.223.170]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA474413 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 17 Jan 2018 22:34:12 +0000 (UTC) +Received: by mail-io0-f170.google.com with SMTP id f89so14597095ioj.4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 17 Jan 2018 14:34:12 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to; + bh=677XfTfLBe/mtoBpA5+rRgcbgQgEuZk2Qxm7f7C0yTc=; + b=lgNCfLnDs8lc5owNTyiBrilTdSxxzEiUkStTnduzxIIAqu30i0lZNe+EDTZdh49rP4 + 2DfleQ12v6x25rQDNPT/qLfvqFaSgrBggusRd1/etDZU72cH9jnmdupFP6KfA2ZHY2LM + 3ji0rVIoLyrvk3HplTpldINuWvE+NTYPH/zf0wm8O5zY9c8Anv62adyRUB4VujkP8g7U + TnCcHBsuec2XGoPDMcfs1wvVoNFOwG2bmnlmKKLhj84Xt8sp9CvZIkiVZ/J5I51UVS2y + wD3iiUQoJvPqfeLXE2OdJDv+c6zXHoQT35tBLm9+P+OvER7OhzxRbFo99QcwpevkUtai + DCPQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to; + bh=677XfTfLBe/mtoBpA5+rRgcbgQgEuZk2Qxm7f7C0yTc=; + b=N1DxmdrTT57PAycKt4En5dVf+ZLbvWI5e/4GDh155/FO4SwAI7gj+3spF/iqglSGmx + BRT98k5+CtsYUqD0ONb6I73nL/9aFk8vl+4XU5QCD+Ut/aMiugQ6FyXxBUvvVq6Btcc8 + Mc3RgIImMixebxoxmZxeZX2Usf9/1rL3lM3lTU/Lsmp8OcBDx/StGKTsNfTqm3seWBpC + Z3tM4xz9ov0qTYXcGMkR1mv/pZGX37qs6QXlodbuFmzaPP6HTXKmiuOAn/r9GhlRIYD3 + 5bYJcK/0vp6A4UiGny9Tx5tnWx7dW0ybUI2MfNvPV++eEujUq026+b01V9j805Q0TO0+ + q/wA== +X-Gm-Message-State: AKwxytdpn/YU3uGT5xvXOQzZfZ+r853GeC+LJ/EdfM5EN6INxvA/xcf5 + HxebYrwxIlNc4RbmoF2aFDios2rbDyVCzBTwn1W4IQ== +X-Google-Smtp-Source: ACJfBoulf49DhU9NsS+oUtymLwvg+sRToADG9ngsgh6Q4JlpQdvmlw/gldiW0Alv8V1YUEacrre+p4OaI4xesy7WvyM= +X-Received: by 10.107.199.7 with SMTP id x7mr2416283iof.64.1516228452078; Wed, + 17 Jan 2018 14:34:12 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.36.73.69 with HTTP; Wed, 17 Jan 2018 14:34:11 -0800 (PST) +In-Reply-To: <5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone> +References: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com> + <5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone> +From: =?UTF-8?Q?Enrique_Ariz=C3=B3n_Benito?= <enrique.arizonbenito@gmail.com> +Date: Wed, 17 Jan 2018 23:34:11 +0100 +Message-ID: <CAD-msxGPsAR=SVzScE1dVsFaN4kBKySSP6U5Q0P7vXxBMcEiqQ@mail.gmail.com> +To: nullius@nym.zone, bitcoin-dev@lists.linuxfoundation.org +Content-Type: multipart/alternative; boundary="94eb2c11ba0048e89705630072b4" +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Wed, 17 Jan 2018 22:48:02 +0000 +Subject: Re: [bitcoin-dev] Proposal to reduce mining power bill +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 17 Jan 2018 22:34:14 -0000 + +--94eb2c11ba0048e89705630072b4 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Thanks "nullius" for your remarks. Notice my first post was not an RFC but +just a blur idea to inspect if something similar had already been discussed +in the group. In fact your post has helped me a lot to improve my first +mail. + +> Observation: This totally destroys Bitcoin=E2=80=99s transaction-orderin= +g +security. A =E2=80=9C51% attack=E2=80=9D could be executed by any miner wh= +o has >50% of +the hashpower *proportionate to miners who are allowed to mine a particular +block*, rather than >50% of *global* hashpower. (I infer that this could +be done retroactively, and wave my hands over some of the details since you +did not talk about reorgs.) The same applies as for attacks requiring 33% +or 25% of total hashpower. + +I'm not sure what you are referring to in this paragraph. Imagine for +example that there are a total of, let's say, 2^10 available +next-coinbase/miners and the algorithm just allow 50% or 2^9 of them to +mine, =C2=BFhow could it be possible that one among them could have 51% of = +power +by chance? (Please, read comments bellow before replying) + +> Potential attack, assuming that N *must* be based partly or wholly on the +existing set of =E2=80=9Cnext-coinbase=E2=80=9D addresses: A large miner c= +ould gradually +push N higher, by progressively committing new =E2=80=9Cnext-coinbase=E2=80= +=9D addresses +which differ in the next bit for all previously seen combinations of bits. +Large miners would have a vast advantage over small miners, insofar as +deliberately incrementing N by one more bit could only be done by a miner +who creates 2^(N+1) blocks (=3D 2 * 2^N). By such means, it may be possibl= +e +for a very large miner to eventually lock out all other miners altogether, +and monopolize all Bitcoin mining. + +I do not think it would be easy even for a large miner but that made me +think for an alternative algorithm. Let's introduce the concept of "spent" +next-coinbase versus "un-spent" one, something like similarly to UTXO. A +next-coinbase would only be valid if it has not been previously used to +mine a block. Simplifying, with the spent vs unspent a large miner is +restricted to a single next-coinbase as anyone else. Being more precise +it's allowed a single next-coinbase for each mined new-miner-block mined +creating a "thread" of mining blocks for each new new-miner-block. +Schematically a thread would look like: +new-miner-block:next-coinbase_1 -> mined-block:next-coinbase_2 -> ... -> +(thread expired - see comment below about expiration) + +In this case a large miner A with T times more power than another one B +could potentially spent mining power to create T parallel threads for each +thread created by miner B. A solution that could fix this issue is to allow +a maximum life time for each thread expressed in number of blocks. After a +given number of blocks have being mined the miner is forced to create new +new-miner-block to continue participating. The algorithm to choose the +life-time must be such that if a miner tries to create many parallel +threads (many new-miner-block), by the time it start mining transaction +blocks the first new-miner-block will start to expire, so he will be +punished. + +If the famous phrase "a degree of indirection solve all programming +problems" I think this is an example applied to blockchain. First the +consensus chooses who can participate in the next round, then selected +miners participate in the round. + + +> Now, questions: +> +> How is N determined? By a wave of the hands? +> + +Great question. I left it unspecified in the first mail. An algorithm comes +to my mind (You are welcome to propose others). Let's imagine the list of +registered non-expired next-coinbase addresses is 2^10. The consensus +checks that for N=3D1 there is *about* 1/2^N =3D=3D 1/2 of unspent next-coi= +nbase +addresses that match (it must be close to 1/2 of the total 2^10 addresses +with maybe an small +/- 1% statistical deviation). Then N=3D1 will be +accepted. Check now for N=3D2. If there are 1/(2^N) =3D 1/4 next-coinbase +addresses matching then N=3D2 is accepted. The algorithm continues until so= +me +"++N" fails. Initially N=3D0 and so all miners are welcome to the game. The= +y +all will start producing next-coinbase addresses and when there are enough +different ones N will become 1, then 2, ... This system will will keep an +equilibrium naturally. If new miners stop producing new new-miner-blocks, +eventually the threads will expire and N will be automatically be +decreased. Miners will act rationally to keep enough threads open in their +own interest since that will decrease the electricity bill. + +> What part of which block hash is matched against N bits? You were quite +unclear about this, and other important details. (Much of what I say here +is based on assumptions and inferences necessary to fill in the blanks.) + +Thinking about it, the hash must run over "many" different blocks and it +must include the next next-coinbase (to force calculating the hash after +choosing a next-coinbase). Since it's not expected that many blocks are +mined by the same miner in a row (maybe no more than 2 o 3) the "many" +number must be for example twice as much as the expected maximum numbers of +blocks that a large miner can mine in average. + +> How, exactly, are reorgs handled? +I think reorgs are not affected by this algorithm. The next-coinbase +objective is just to randomly choose which miner will be allowed for the +next round. + +> How does this interact with the difficulty adjustment algorithm? Indeed, +how is difficulty determined at all under your scheme? +As I see it, if the network wants to keep the same pace of new blocks each +N seconds, and N=3D1 (only half of the miners are allowed to mine) then +difficulty/power-bill is lowered by two, for N=3D2 by 4, ... + +> What happens to coinbase fees from a =E2=80=9Cnew-miner-block=E2=80=9D? = +The way I read +your scheme, the =E2=80=9Cnew-miner-block=E2=80=9D must necessarily have no= + payout +whatsoever. But you discuss only =E2=80=9Cnew bitcoins=E2=80=9D,which are = +a diminishing +portion of the block reward, and will eventually reach zero. Coinbase from +fees must go somewhere; but under your scheme, a =E2=80=9Cnew miner=E2=80= +=9D has no payable +address. + +This new-miner-block will have NO transactions inside. + +> What if no existing =E2=80=9Cnext-coinbase=E2=80=9D address matches? Is = +N constrained to +be sufficiently short that a match is guaranteed from the existing set, +then that makes it trivial for large mining farms to collect addresses and +further dominate (or even monopolize) the network in the attack described +above. If it isn=E2=80=99t, then the network could suddenly halt when nobo= +dy is +allowed to mine the next block; and that would enable *this* attack: + +I think the previous algorithm I mention to replace the "wave of hands" +(test N=3D1, then N=3D2,... ) plus the "expiring threads" would suffice to = +fix +it. + +> What stops a malicious miner (including a =E2=80=9Cnew miner=E2=80=9D cr= +eating a +=E2=80=9Cnew-miner block=E2=80=9D) from deliberately working to create a bl= +ock with a hash +which does not have N bits matching any of the existing =E2=80=9Cnext-coinb= +ase=E2=80=9D +addresses? Contra what you say, block hashes can=E2=80=99t be =E2=80=9Ccon= +sidered +random=E2=80=9D. Indeed, partial preimage bruteforcing of block hashes is = +the +entire basis of mining POW. + +Again, that is fixed by the previous algorithm + + +> Asking here more generally than as for the attack described above, what +stops mining farms with large hashpower from submitting many different +=E2=80=9Cnext-coinbase=E2=80=9D addresses in many different blocks? If N b= +e small, then it +should be feasible for a large mining farm to eventually register a set of +=E2=80=9Cnext-coinbase=E2=80=9D addresses which match any N. **This increa= +ses mining +centralization.** If N be large, then this creates the possibility (or +raises the probability) that no address will match, and nobody will be +allowed to mine the next block. + +Fixed by the expiring thread model? + + +> How could miner anonymity be preserved under a scheme whereby each +> =E2=80=9Cnext-coinbase=E2=80=9D address can be linked to a previous =E2= +=80=9Cnext-coinbase=E2=80=9D +> address? The only way to start fresh would be with a prohibitively +> expensive no-payout block. Mining can be totally anonymous at present, a= +nd +> must so remain. Miners are only identified by certain information they +> choose to put in a block header, which they could choose to change or +> omit=E2=80=94or by IP address, which is trivially changed and is never a = +reliable +> identifier. +> +> The anonymity decreases in the sense that if you know a next-coinbase +address owner you know all its related next-coinbase for the expiring +(physical-time-limited) thread. The anonymity increases in the sense that +miner will consume fewer energy. Electricity bill is the easiest way today +to trace miners. + + > How does this even save electricity, when there is much mining equipment +(especially on large mining farms) which cannot be easily shut down and +restarted? (Allegedly, this is one reason why some big miners occasionally +mine empty blocks.) Though I suppose that difficulty would drop by +unspecified means. + +As explained above, the difficulty is reduced by 1/2^N for each round. And +of course, miners that want to save more energy will have to adapt to put +their systems on stand-by while they are not chosen for the next round. I +think based on my limited experience with ASIC mining that just by not +sending new orders to the miner the power comsumption will decrease +dramatically even if the equipment is still on. + +> +> Further observations: +> +> This scheme drastically increases the upfront investment required for a +> new miner to start mining. To mine even one new block all by oneself, +> without a pool, already requires a huge investment. + + +Once introduced the concept of "expiring" thread I think he will be pretty +much in the same condition. To obtain bitcoins he will first need to mine a +new-miner-block to enter the game and then an standard block before the +thread expires. Notice the expire time/block-length start just after the +new-miner-block has been mined so the probabilities to mine before the +expiration time will be proportional to its mining power, as for everyone +else. + +> Add to that the uncompensated energy cost of mining that first block with +*no* payout, + +I think it could be clearly compensated by the save in energy for standards +blocks. + +>and I expect that the bar would be prohibitive to almost all new +entrants.Mining costs and incentives are delicately balanced by the design +of the network. Whereas incumbents are much favoured by your scheme, +further increasing miner centralization. + +I don't think so after the new fixes. What do you think? My opinion is +that, based on the "theory of games", miners acting in their own interest +will try to maximize "N". + +> Large incumbents could also use this to produce a mining permissions +market, by selling the private keys to committed =E2=80=9Cnext-coinbase=E2= +=80=9D +addresses. + +With the addition of thread expiration, nobody will be really motivated to +shell/buy "next-coinbase" addresses since their utility is limited. + +Just a remark: Notice this algorithm reduces the electricity bill, but the +hardware needed stays the same, since for each round the miner participates +in, it will try to mine as fast as possible and so use as much hardware as +possible. No reduction costs are expected in hardware. + + +Best Regards, + +Enrique Ariz=C3=B3n Benito + + + +I have not even tried to imagine what oddball attacks might be possible for +> any miner with sufficient hashpower to deliberately cause a small reorg. + + +> -- +> nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C +> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: +> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) +> =E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have no= +thing to hide.=E2=80=99 +> No! Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80= +=94 nullius +> + +--94eb2c11ba0048e89705630072b4 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Thanks "nullius" for your remarks. Notice m= +y first post was not an RFC but just a blur idea to inspect if something si= +milar had already been discussed in the group. In fact your post has helped= + me a lot to improve my first mail.<br></div><div><br></div><div>> Obser= +vation:=C2=A0 This totally destroys Bitcoin=E2=80=99s transaction-ordering= +=20 +security.=C2=A0 A =E2=80=9C51% attack=E2=80=9D could be executed by any min= +er who has >50% + of the hashpower *proportionate to miners who are allowed to mine a=20 +particular block*, rather than >50% of *global* hashpower.=C2=A0 (I infe= +r=20 +that this could be done retroactively, and wave my hands over some of=20 +the details since you did not talk about reorgs.)=C2=A0 The same applies as= +=20 +for attacks requiring 33% or 25% of total hashpower.=C2=A0</div><div class= +=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>I'm not= + sure what you are referring to in this paragraph. Imagine for example that= + there are a total of, let's say, 2^10 available next-coinbase/miners a= +nd the algorithm just allow 50% or 2^9 of them to mine, =C2=BFhow could it = +be possible that one among them could have 51% of power by chance? (Please,= + read comments bellow before replying)<br></div><div><br></div><div>> Po= +tential attack, assuming that N *must* be based partly or wholly on=20 +the existing set of =E2=80=9Cnext-coinbase=E2=80=9D addresses:=C2=A0 A larg= +e miner could=20 +gradually push N higher, by progressively committing new =E2=80=9Cnext-coin= +base=E2=80=9D + addresses which differ in the next bit for all previously seen=20 +combinations of bits. Large miners would have a vast advantage over=20 +small miners, insofar as deliberately incrementing N by one more bit=20 +could only be done by a miner who creates 2^(N+1) blocks (=3D 2 * 2^N).=C2= +=A0=20 +By such means, it may be possible for a very large miner to eventually=20 +lock out all other miners altogether, and monopolize all Bitcoin mining.</d= +iv><div><br></div><div>I do not think it would be easy even for a large min= +er but that made me think for an alternative algorithm. Let's introduce= + the concept of "spent" next-coinbase versus "un-spent"= + one, something like similarly to UTXO. A next-coinbase would only be valid= + if it has not been previously used to mine a block. Simplifying, with the = +spent vs unspent a large miner is restricted to a single next-coinbase as a= +nyone else. Being more precise it's allowed a single next-coinbase for = +each mined new-miner-block mined creating a "thread" of mining bl= +ocks for each new new-miner-block. Schematically a thread would look like: = +<br>new-miner-block:next-coinbase_1 -> mined-block:next-coinbase_2 ->= +=C2=A0 ... -> (thread expired - see comment below about expiration)<br><= +/div><br></div><div class=3D"gmail_quote">In this case a large miner A with= + T times more power than another one B could potentially spent mining power= + to create T parallel threads for each thread created by miner B. A solutio= +n that could fix this issue is to allow a maximum life time for each thread= + expressed in number of blocks. After a given number of blocks have being m= +ined the miner is forced to create new new-miner-block to continue particip= +ating. The algorithm to choose the life-time must be such that if a miner t= +ries to create many parallel threads (many new-miner-block), by the time it= + start mining transaction blocks the first new-miner-block will start to ex= +pire, so he will be punished.<br><br></div><div class=3D"gmail_quote">If th= +e famous phrase "a degree of indirection solve all programming problem= +s" I think this is an example applied to blockchain. First the consens= +us chooses who can participate in the next round, then selected miners part= +icipate in the round.<br></div><div class=3D"gmail_quote"><div>=C2=A0</div>= +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= +left:1px solid rgb(204,204,204);padding-left:1ex"> +Now, questions:<br> +<br> +How is N determined?=C2=A0 By a wave of the hands?<br></blockquote><div><br= +></div><div>Great question. I left it unspecified in the first mail. An alg= +orithm comes to my mind (You are welcome to propose others). Let's imag= +ine the list of registered non-expired next-coinbase addresses=C2=A0 is 2^1= +0. The consensus checks that for N=3D1 there is *about* 1/2^N =3D=3D 1/2 of= + unspent next-coinbase addresses that match (it must be close to 1/2 of the= + total 2^10 addresses with maybe an small +/- 1% statistical deviation). Th= +en N=3D1 will be accepted. Check now for N=3D2. If there are 1/(2^N) =3D 1/= +4 next-coinbase addresses matching then N=3D2 is accepted. The algorithm co= +ntinues until some "++N" fails. Initially N=3D0 and so all miners= + are welcome to the game. They all will start producing next-coinbase addre= +sses and when there are enough different ones N will become 1, then 2, ... = +This system will will keep an equilibrium naturally. If new miners stop pro= +ducing new new-miner-blocks, eventually the threads will expire and N will = +be automatically be decreased. Miners will act rationally to keep enough th= +reads open in their own interest since that will decrease the electricity b= +ill.<br><br></div><div>> What part of which block hash is matched agains= +t N bits?=C2=A0 You were quite + unclear about this, and other important details.=C2=A0 (Much of what I say= +=20 +here is based on assumptions and inferences necessary to fill in the=20 +blanks.)</div><div><br></div><div>Thinking about it, the hash must run over= + "many" different blocks and it must include the next next-coinba= +se (to force calculating the hash after choosing a next-coinbase). Since it= +'s not expected that many blocks are mined by the same miner in a row (= +maybe no more than 2 o 3) the "many" number must be for example t= +wice as much as the expected maximum numbers of blocks that a large miner c= +an mine in average.<br> +</div><div>=C2=A0<br></div><div>> How, exactly, are reorgs handled?</div= +><div>I think reorgs are not affected by this algorithm. The next-coinbase = +objective is just to randomly choose which miner will be allowed for the n= +ext round.<br></div><div>=C2=A0</div><div>> How does this interact with = +the difficulty adjustment algorithm?=C2=A0 Indeed, how is difficulty determ= +ined at all under your scheme?</div><div>As I see it, if the network wants = +to keep the same pace of new blocks each N seconds, and N=3D1 (only half of= + the miners are allowed to mine)=C2=A0 then difficulty/power-bill is lowere= +d by two, for N=3D2 by 4, ...</div><div><br></div>>=20 +What happens to coinbase fees from a =E2=80=9Cnew-miner-block=E2=80=9D?=C2= +=A0 The way I read=20 +your scheme, the =E2=80=9Cnew-miner-block=E2=80=9D must necessarily have no= + payout=20 +whatsoever.=C2=A0 But you discuss only =E2=80=9Cnew bitcoins=E2=80=9D,which= + are a=20 +diminishing portion of the block reward, and will eventually reach=20 +zero.=C2=A0 Coinbase from fees must go somewhere; but under your scheme, a= +=20 +=E2=80=9Cnew miner=E2=80=9D has no payable address.<div><br></div><div>This= + new-miner-block will have NO transactions inside.<br></div><div><br> </div= +><div>>=20 + +What if no existing =E2=80=9Cnext-coinbase=E2=80=9D address matches?=C2=A0 = +Is N constrained=20 +to be sufficiently short that a match is guaranteed from the existing=20 +set, then that makes it trivial for large mining farms to collect=20 +addresses and further dominate (or even monopolize) the network in the=20 +attack described above.=C2=A0 If it isn=E2=80=99t, then the network could s= +uddenly=20 +halt when nobody is allowed to mine the next block; and that would=20 +enable *this* attack:</div><div><br></div><div>I think the previous algorit= +hm I mention to replace the "wave of hands" (test N=3D1, then N= +=3D2,... ) plus the "expiring threads" would suffice to fix it.<b= +r></div><div><br></div><div>>=C2=A0 +What stops a malicious miner (including a =E2=80=9Cnew miner=E2=80=9D creat= +ing a=20 +=E2=80=9Cnew-miner block=E2=80=9D) from deliberately working to create a bl= +ock with a=20 +hash which does not have N bits matching any of the existing=20 +=E2=80=9Cnext-coinbase=E2=80=9D addresses?=C2=A0 Contra what you say, block= + hashes can=E2=80=99t be=20 +=E2=80=9Cconsidered random=E2=80=9D.=C2=A0 Indeed, partial preimage brutefo= +rcing of block=20 +hashes is the entire basis of mining POW.<br></div><div><br> </div><div>Aga= +in, that is fixed by the previous algorithm</div><div><br></div><div><br></= +div><div>> Asking here more generally than as for the attack described a= +bove, what=20 +stops mining farms with large hashpower from submitting many different=20 +=E2=80=9Cnext-coinbase=E2=80=9D addresses in many different blocks?=C2=A0 I= +f N be small, then + it should be feasible for a large mining farm to eventually register a=20 +set of =E2=80=9Cnext-coinbase=E2=80=9D addresses which match any N.=C2=A0 *= +*This increases=20 +mining centralization.**=C2=A0 If N be large, then this creates the=20 +possibility (or raises the probability) that no address will match, and=20 +nobody will be allowed to mine the next block.<br><br></div><div>Fixed by t= +he expiring thread model?<br> +</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi= +n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= +"> +How could miner anonymity be preserved under a scheme whereby each=20 +=E2=80=9Cnext-coinbase=E2=80=9D address can be linked to a previous =E2=80= +=9Cnext-coinbase=E2=80=9D=20 +address?=C2=A0 The only way to start fresh would be with a prohibitively=20 +expensive no-payout block.=C2=A0 Mining can be totally anonymous at present= +,=20 +and must so remain.=C2=A0 Miners are only identified by certain information= +=20 +they choose to put in a block header, which they could choose to change=20 +or omit=E2=80=94or by IP address, which is trivially changed and is never a= +=20 +reliable identifier.<br> +<br></blockquote><div>The anonymity decreases in the sense that if you know= + a next-coinbase address owner you know all its related next-coinbase for t= +he expiring (physical-time-limited) thread. The anonymity increases in the = +sense that miner will consume fewer energy. Electricity bill is the easiest= + way today to trace miners.<br></div><div><br></div><div>=C2=A0> How doe= +s this even save electricity, when there is much mining equipment + (especially on large mining farms) which cannot be easily shut down and + restarted?=C2=A0 (Allegedly, this is one reason why some big miners=20 +occasionally mine empty blocks.)=C2=A0 Though I suppose that difficulty wou= +ld + drop by unspecified means.</div><div><br></div><div>As explained above, th= +e difficulty is reduced by 1/2^N for each round. And of course, miners that= + want to save more energy will have to adapt to put their systems on stand-= +by while they=C2=A0 are not chosen for the next round. I think based on my = +limited experience with ASIC mining that just by not sending new orders to = +the miner the power comsumption will decrease dramatically even if the equi= +pment is still on.<br></div><blockquote class=3D"gmail_quote" style=3D"marg= +in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= +x"> +<br> +Further observations:<br> +<br> +This scheme drastically increases the upfront investment required for a=20 +new miner to start mining.=C2=A0 To mine even one new block all by oneself,= +=20 +without a pool, already requires a huge investment.=C2=A0</blockquote><div>= +=C2=A0</div><div>Once introduced the concept of "expiring" thread= + I think he will be pretty much in the same condition. To obtain bitcoins h= +e will first need to mine a new-miner-block to enter the game and then an s= +tandard block before the thread expires. Notice the expire time/block-lengt= +h start just after the new-miner-block has been mined so the probabilities = +to mine before the expiration time will be proportional to its mining power= +, as for everyone else.=C2=A0 <br></div><div>=C2=A0</div>> Add to that t= +he=20 +uncompensated energy cost of mining that first block with *no* payout, <div= +><br></div><div>I think it could be clearly compensated by the save in ener= +gy for standards blocks.</div><div> <br></div><div>>and I expect that th= +e bar would be prohibitive to almost all new=20 +entrants.Mining costs and incentives are delicately balanced by the=20 +design of the network.=C2=A0 Whereas incumbents are much favoured by your= +=20 +scheme, further increasing miner centralization.</div><div><br></div><div>I= + don't think so after the new fixes. What do you think? My opinion is = +that, based on the "theory of games", miners acting in their own = +interest will try to maximize "N". <br></div><div>=C2=A0 <br></di= +v><div>> Large incumbents could + also use this to produce a mining permissions market, by selling the=20 +private keys to committed =E2=80=9Cnext-coinbase=E2=80=9D addresses.=C2=A0 = +<br><br></div><div>With the addition of thread expiration, nobody will be r= +eally motivated to shell/buy "next-coinbase" addresses since thei= +r utility is limited.<br></div><div><br></div><div>Just a remark: Notice th= +is algorithm reduces the electricity bill, but the hardware needed stays th= +e same, since for each round the miner participates in, it will try to mine= + as fast as possible and so use as much hardware as possible. No reduction = +costs are expected in hardware.<br></div><div><br></div><div><br></div><div= +>Best Regards,</div><div><br></div><div>Enrique Ariz=C3=B3n Benito</div><di= +v><br></div><div><br></div><div><br></div><blockquote class=3D"gmail_quote"= + style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= +adding-left:1ex"> +I have not even tried to imagine what oddball attacks might be possible=20 +for any miner with sufficient hashpower to deliberately cause a small=20 +reorg.<span class=3D"gmail-m_6404816983919078843m_7057792341444477592m_2213= +594593287026671gmail-HOEnZb"></span>=C2=A0</blockquote><blockquote class=3D= +"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= +04,204,204);padding-left:1ex"><span class=3D"gmail-m_6404816983919078843m_7= +057792341444477592m_2213594593287026671gmail-HOEnZb"><font color=3D"#888888= +"> +<br> +-- <br> +nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00<wbr>591B2F307E0C= +<br> +Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7<wbr>f6agex98an7h | (Segwit nested:<= +br> +3NULL3ZCUXr7RDLxXeLPDMZDZYxuaY<wbr>kCnG)=C2=A0 (PGP RSA: 0x36EBB4AB699A10EE= +)<br> +=E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have noth= +ing to hide.=E2=80=99<br> +No!=C2=A0 Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2= +=80=94 nullius<br> +</font></span></blockquote></div></div><div class=3D"gmail_extra"><br></div= +><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div>= +</div> + +--94eb2c11ba0048e89705630072b4-- + |