From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7FF5D109D for ; Thu, 18 Jan 2018 05:22:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f54.google.com (mail-pg0-f54.google.com [74.125.83.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D18C7203 for ; Thu, 18 Jan 2018 05:22:54 +0000 (UTC) Received: by mail-pg0-f54.google.com with SMTP id s9so11298300pgq.13 for ; Wed, 17 Jan 2018 21:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9xltCIwmSjmD4gwrt5IZdbRj1YzL8drnUGpzt+K5NWM=; b=HZIxWd34c4mcpIP9xsnoMy+K0OlCkRRO4p2h/u0l71KjYnr7dPi80lVLrUuqKJkBPr 19PDSPipbeW6lTqUaVV9+Wq7/UatJk8kpvOkI7+cE3U5ZLESSe7AwNbecLqwYskekYJ6 y5tnEVkmKrrp2ayC5EhMBbjCYLbsC40FNpKSHMtZLDr7hvkzv7u4RZ13aBdioHQMEUL8 XvM+WvJc9yjb1VmonI4vevCn/AK1zJDodx/4Q1dbxsmUn+OpqyIiYV8yIpX2mVlhhAg8 A0C1iEh3+c13mg3mWy9OoehZFD9pjZecTsuJ6+j0oIEDaD35uNsKxiSU1damdMzsuYVv gHGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9xltCIwmSjmD4gwrt5IZdbRj1YzL8drnUGpzt+K5NWM=; b=Cq0o2klkp4+du00srjLZ52Z69MXhrwE32tgOyhdONumDrGStr2BEyXfKv10fJ9436i 6csEaDAvi+2XjA/iiApYBDWUSGjOgT8sCCwly5Ae7yw9twpTIhP08DITtoizgy6Ri7Uw L/rVrFabhnOTzI6Lz/tOccsW+utZJcxPml83dGDNrxcKLKV2OUrtn3HXvADayklA0+aa H3oAV6oKgpz61Vu6uZgZs9NxlfZkyZgqZYc2D7E7AXB42ce/r+I3smxK+3lmP6Stn6sh muxkQeI83HA3Lt6/PAvlF7M/iJGkQS4VrN+E8z5VEc0LiygX2bb8Z+0t7hKcnBWknbvM 1J8w== X-Gm-Message-State: AKwxytej79dFUcJURfNygPRtgVrR+7JfXH2sWS5X3xavXj+6M3TPMICX PjdfLDTeHzlY/m5RKjYENgAa/A== X-Google-Smtp-Source: ACJfBotuBgsySZxEmALTdsNdu3+5/bQAi4CemBk+67j/JE3gyglD1cic5hSuOLdFb6C41cYVE+agzw== X-Received: by 10.159.202.145 with SMTP id p17mr20893429plo.375.1516252974328; Wed, 17 Jan 2018 21:22:54 -0800 (PST) Received: from ?IPv6:2600:380:4420:597f:8027:db0e:8d38:f237? ([2600:380:4420:597f:8027:db0e:8d38:f237]) by smtp.gmail.com with ESMTPSA id g69sm9750786pgc.32.2018.01.17.21.22.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 21:22:53 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-30409492-9FAF-4667-BF83-E20C5D9C2025 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Thu, 18 Jan 2018 13:22:47 +0800 Content-Transfer-Encoding: 7bit Message-Id: <2C70E809-0657-4FBE-9E12-008E2A7C4207@voskuil.org> References: <5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone> To: =?utf-8?Q?Enrique_Ariz=C3=B3n_Benito?= , Bitcoin Protocol Discussion X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE, URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 18 Jan 2018 15:51:12 +0000 Cc: nullius@nym.zone 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 05:22:56 -0000 --Apple-Mail-30409492-9FAF-4667-BF83-E20C5D9C2025 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The energy cost of mining cannot be reduced, nor is it rational to consider i= t =E2=80=9Ctoo high=E2=80=9D. e > On Jan 18, 2018, at 06:34, Enrique Ariz=C3=B3n Benito via bitcoin-dev wrote: >=20 > 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 mai= l. >=20 > > Observation: This totally destroys Bitcoin=E2=80=99s transaction-orderi= ng security. A =E2=80=9C51% attack=E2=80=9D could be executed by any miner w= ho has >50% of the hashpower *proportionate to miners who are allowed to min= e a particular block*, rather than >50% of *global* hashpower. (I infer tha= t this could be done retroactively, and wave my hands over some of the detai= ls since you did not talk about reorgs.) The same applies as for attacks re= quiring 33% or 25% of total hashpower.=20 >=20 > I'm not sure what you are referring to in this paragraph. Imagine for exam= ple that there are a total of, let's say, 2^10 available next-coinbase/miner= s and the algorithm just allow 50% or 2^9 of them to mine, =C2=BFhow could i= t be possible that one among them could have 51% of power by chance? (Please= , read comments bellow before replying) >=20 > > Potential attack, assuming that N *must* be based partly or wholly on th= e 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 s= een combinations of bits. Large miners would have a vast advantage over smal= l miners, insofar as deliberately incrementing N by one more bit could only b= e done by a miner who creates 2^(N+1) blocks (=3D 2 * 2^N). By such means, i= t may be possible for a very large miner to eventually lock out all other mi= ners altogether, and monopolize all Bitcoin mining. >=20 > I do not think it would be easy even for a large miner but that made me th= ink for an alternative algorithm. Let's introduce the concept of "spent" nex= t-coinbase versus "un-spent" one, something like similarly to UTXO. A next-c= oinbase would only be valid if it has not been previously used to mine a blo= ck. Simplifying, with the spent vs unspent a large miner is restricted to a s= ingle 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 m= ining blocks for each new new-miner-block. Schematically a thread would look= like:=20 > new-miner-block:next-coinbase_1 -> mined-block:next-coinbase_2 -> ... -> (= thread expired - see comment below about expiration) >=20 > In this case a large miner A with T times more power than another one B co= uld potentially spent mining power to create T parallel threads for each thr= ead created by miner B. A solution that could fix this issue is to allow a m= aximum life time for each thread expressed in number of blocks. After a give= n number of blocks have being mined the miner is forced to create new new-mi= ner-block to continue participating. The algorithm to choose the life-time m= ust 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-m= iner-block will start to expire, so he will be punished. >=20 > If the famous phrase "a degree of indirection solve all programming proble= ms" I think this is an example applied to blockchain. First the consensus ch= ooses who can participate in the next round, then selected miners participat= e in the round. > =20 >> Now, questions: >>=20 >> How is N determined? By a wave of the hands? >=20 > Great question. I left it unspecified in the first mail. An algorithm come= s to my mind (You are welcome to propose others). Let's imagine the list of r= egistered 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-coinbase a= ddresses that match (it must be close to 1/2 of the total 2^10 addresses wit= h 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 m= atching then N=3D2 is accepted. The algorithm continues until some "++N" fai= ls. Initially N=3D0 and so all miners are welcome to the game. They 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 th= e threads will expire and N will be automatically be decreased. Miners will a= ct rationally to keep enough threads open in their own interest since that w= ill decrease the electricity bill. >=20 > > 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 i= s based on assumptions and inferences necessary to fill in the blanks.) >=20 > Thinking about it, the hash must run over "many" different blocks and it m= ust include the next next-coinbase (to force calculating the hash after choo= sing 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 b= e for example twice as much as the expected maximum numbers of blocks that a= large miner can mine in average. > =20 > > How, exactly, are reorgs handled? > I think reorgs are not affected by this algorithm. The next-coinbase objec= tive is just to randomly choose which miner will be allowed for the next rou= nd. > =20 > > 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 di= fficulty/power-bill is lowered by two, for N=3D2 by 4, ... >=20 > > 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 nece= ssarily have no payout whatsoever. But you discuss only =E2=80=9Cnew bitcoi= ns=E2=80=9D,which are a diminishing portion of the block reward, and will ev= entually reach zero. Coinbase from fees must go somewhere; but under your s= cheme, a =E2=80=9Cnew miner=E2=80=9D has no payable address. >=20 > This new-miner-block will have NO transactions inside. >=20 > > 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 e= xisting set, then that makes it trivial for large mining farms to collect ad= dresses and further dominate (or even monopolize) the network in the attack d= escribed above. If it isn=E2=80=99t, then the network could suddenly halt w= hen nobody is allowed to mine the next block; and that would enable *this* a= ttack: >=20 > I think the previous algorithm I mention to replace the "wave of hands" (t= est N=3D1, then N=3D2,... ) plus the "expiring threads" would suffice to fix= it. >=20 > > What stops a malicious miner (including a =E2=80=9Cnew miner=E2=80=9D c= reating a =E2=80=9Cnew-miner block=E2=80=9D) from deliberately working to cr= eate a block with a hash which does not have N bits matching any of the exis= ting =E2=80=9Cnext-coinbase=E2=80=9D addresses? Contra what you say, block h= ashes can=E2=80=99t be =E2=80=9Cconsidered random=E2=80=9D. Indeed, partial= preimage bruteforcing of block hashes is the entire basis of mining POW. >=20 > Again, that is fixed by the previous algorithm >=20 >=20 > > Asking here more generally than as for the attack described above, what s= tops mining farms with large hashpower from submitting many different =E2=80= =9Cnext-coinbase=E2=80=9D addresses in many different blocks? If N be 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= increases mining centralization.** If N be large, then this creates the po= ssibility (or raises the probability) that no address will match, and nobody= will be allowed to mine the next block. >=20 > Fixed by the expiring thread model? > =20 >> 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 proh= ibitively expensive no-payout block. Mining can be totally anonymous at pre= sent, and 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 o= mit=E2=80=94or by IP address, which is trivially changed and is never a reli= able identifier. >>=20 > The anonymity decreases in the sense that if you know a next-coinbase addr= ess owner you know all its related next-coinbase for the expiring (physical-= time-limited) thread. The anonymity increases in the sense that miner will c= onsume fewer energy. Electricity bill is the easiest way today to trace mine= rs. >=20 > > How does this even save electricity, when there is much mining equipmen= t (especially on large mining farms) which cannot be easily shut down and re= started? (Allegedly, this is one reason why some big miners occasionally mi= ne empty blocks.) Though I suppose that difficulty would drop by unspecifie= d means. >=20 > 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 t= heir systems on stand-by while they are not chosen for the next round. I th= ink based on my limited experience with ASIC mining that just by not sending= new orders to the miner the power comsumption will decrease dramatically ev= en if the equipment is still on. >>=20 >> Further observations: >>=20 >> This scheme drastically increases the upfront investment required for a n= ew miner to start mining. To mine even one new block all by oneself, withou= t a pool, already requires a huge investment.=20 > =20 > 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 thr= ead expires. Notice the expire time/block-length start just after the new-mi= ner-block has been mined so the probabilities to mine before the expiration t= ime will be proportional to its mining power, as for everyone else. =20 > =20 > > Add to that the uncompensated energy cost of mining that first block wit= h *no* payout, >=20 > I think it could be clearly compensated by the save in energy for standard= s blocks. >=20 > >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 ne= twork. Whereas incumbents are much favoured by your scheme, further increas= ing miner centralization. >=20 > I don't think so after the new fixes. What do you think? My opinion is th= at, based on the "theory of games", miners acting in their own interest will= try to maximize "N".=20 > =20 > > Large incumbents could also use this to produce a mining permissions mar= ket, by selling the private keys to committed =E2=80=9Cnext-coinbase=E2=80=9D= addresses. =20 >=20 > With the addition of thread expiration, nobody will be really motivated to= shell/buy "next-coinbase" addresses since their utility is limited. >=20 > 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 p= ossible. No reduction costs are expected in hardware. >=20 >=20 > Best Regards, >=20 > Enrique Ariz=C3=B3n Benito >=20 >=20 >=20 >> I have not even tried to imagine what oddball attacks might be possible f= or any miner with sufficient hashpower to deliberately cause a small reorg.=20= >>=20 >> --=20 >> 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 >=20 >=20 >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-30409492-9FAF-4667-BF83-E20C5D9C2025 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The energy cost of mining c= annot be reduced, nor is it rational to consider it =E2=80=9Ctoo high=E2=80=9D= .

e

On Jan 18, 2018, at 06:34, Enriqu= e Ariz=C3=B3n Benito via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Thanks "nul= lius" for your remarks. Notice my first post was not an RFC but just a blur i= dea 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-ordering=20 security.  A =E2=80=9C51% attack=E2=80=9D could be executed by any mine= r who has >50% of the hashpower *proportionate to miners who are allowed to mine a=20 particular block*, rather than >50% of *global* hashpower.  (I infer= =20 that this could be done retroactively, and wave my hands over some of=20 the details since you did not talk about reorgs.)  The same applies as=20= for attacks requiring 33% or 25% of total hashpower. 

I'm not sure wh= at you are referring to in this paragraph. Imagine for example that there ar= e a total of, let's say, 2^10 available next-coinbase/miners and the algorit= hm just allow 50% or 2^9 of them to mine, =C2=BFhow could it be possible tha= t one among them could have 51% of power by chance? (Please, read comments b= ellow before replying)

> Potential attack, a= ssuming that N *must* be based partly or wholly on=20 the existing set of =E2=80=9Cnext-coinbase=E2=80=9D addresses:  A large= miner could=20 gradually push N higher, by progressively committing new =E2=80=9Cnext-coinb= ase=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). = ;=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.

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 co= ncept of "spent" next-coinbase versus "un-spent" one, something like similar= ly to UTXO. A next-coinbase would only be valid if it has not been previousl= y 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 i= t's allowed a single next-coinbase for each mined new-miner-block mined crea= ting a "thread" of mining blocks for each new new-miner-block. Schematically= a thread would look like:
new-miner-block:next-coinbase_1 -> mined-b= lock:next-coinbase_2 ->  ... -> (thread expired - see comment bel= ow about expiration)

In this c= ase a large miner A with T times more power than another one B could potenti= ally 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 t= o 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 w= ill 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 conse= nsus chooses who can participate in the next round, then selected miners par= ticipate 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 algor= ithm 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 c= onsensus checks that for N=3D1 there is *about* 1/2^N =3D=3D 1/2 of unspent n= ext-coinbase 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 wil= l be accepted. Check now for N=3D2. If there are 1/(2^N) =3D 1/4 next-coinba= se addresses matching then N=3D2 is accepted. The algorithm continues until s= ome "++N" fails. Initially N=3D0 and so all miners are welcome to the game. T= hey all will start producing next-coinbase addresses and when there are enou= gh 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, e= ventually the threads will expire and N will be automatically be decreased. M= iners will act rationally to keep enough threads open in their own interest s= ince that will decrease the electricity bill.

> What pa= rt of which block hash is matched against N bits?  You were quite unclear about this, and other important details.  (Much of what I say=20= here is based on assumptions and inferences necessary to fill in the=20 blanks.)

Thinking about it, the hash must run over "= many" different blocks and it must include the next next-coinbase (to force c= alculating 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 ma= ximum 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 ob= jective is just to randomly choose which miner will be allowed for the next= round.
 
> How does this interact with the d= ifficulty adjustment algorithm?  Indeed, how is difficulty determined a= t 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 min= ers are allowed to mine)  then difficulty/power-bill is lowered by two,= for N=3D2 by 4, ...

>=20 What happens to coinbase fees from a =E2=80=9Cnew-miner-block=E2=80=9D? = ; The way I read=20 your scheme, the =E2=80=9Cnew-miner-block=E2=80=9D must necessarily have no p= ayout=20 whatsoever.  But you discuss only =E2=80=9Cnew bitcoins=E2=80=9D,which a= re a=20 diminishing portion of the block reward, and will eventually reach=20 zero.  Coinbase from fees must go somewhere; but under your scheme, a=20= =E2=80=9Cnew miner=E2=80=9D has no payable address.

This n= ew-miner-block will have NO transactions inside.

>=20 What if no existing =E2=80=9Cnext-coinbase=E2=80=9D address matches?  I= s 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.  If it isn=E2=80=99t, then the network could su= ddenly=20 halt when nobody is allowed to mine the next block; and that would=20 enable *this* attack:

I think the previous algorith= m I mention to replace the "wave of hands" (test N=3D1, then N=3D2,... ) plu= s the "expiring threads" would suffice to fix it.

>  What stops a malicious miner (including a =E2=80=9Cnew miner=E2=80=9D creati= ng a=20 =E2=80=9Cnew-miner block=E2=80=9D) from deliberately working to create a blo= ck with a=20 hash which does not have N bits matching any of the existing=20 =E2=80=9Cnext-coinbase=E2=80=9D addresses?  Contra what you say, block h= ashes can=E2=80=99t be=20 =E2=80=9Cconsidered random=E2=80=9D.  Indeed, partial preimage brutefor= cing of block=20 hashes is the entire basis of mining POW.

Agai= n, that is fixed by the previous algorithm


> Asking here more generally than as for the attack described abov= e, 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?  If= 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.  **= This increases=20 mining centralization.**  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.

Fixed by th= e expiring thread model?
 
= 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=9C= next-coinbase=E2=80=9D=20 address?  The only way to start fresh would be with a prohibitively=20 expensive no-payout block.  Mining can be totally anonymous at present,= =20 and must so remain.  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.

The anonymity decreases in the sense that if you know a= next-coinbase address owner you know all its related next-coinbase for the e= xpiring (physical-time-limited) thread. The anonymity increases in the sense= that miner will consume fewer energy. Electricity bill is the easiest way t= oday to trace miners.

 > How does this e= ven 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=20 occasionally mine empty blocks.)  Though I suppose that difficulty woul= d drop by unspecified means.

As explained above, the= difficulty is reduced by 1/2^N for each round. And of course, miners that w= ant to save more energy will have to adapt to put their systems on stand-by w= hile they  are not chosen for the next round. I think based on my limit= ed experience with ASIC mining that just by not sending new orders to the mi= ner the power comsumption will decrease dramatically even if the equipment i= s still on.

Further observations:

This scheme drastically increases the upfront investment required for a=20 new miner to start mining.  To mine even one new block all by oneself,=20= without a pool, already requires a huge investment. 
&= nbsp;
Once introduced the concept of "expiring" thread I think he w= ill be pretty much in the same condition. To obtain bitcoins he will first n= eed to mine a new-miner-block to enter the game and then an standard block b= efore the thread expires. Notice the expire time/block-length start just aft= er the new-miner-block has been mined so the probabilities to mine before th= e expiration time will be proportional to its mining power, as for everyone e= lse. 
 
> Add to that the=20 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 b= ar would be prohibitive to almost all new=20 entrants.Mining costs and incentives are delicately balanced by the=20 design of the network.  Whereas incumbents are much favoured by your=20= scheme, further increasing miner centralization.

I d= on't think so after the new fixes. What do you think? My opinion is that, b= ased on the "theory of games", miners acting in their own interest will try t= o maximize "N".
 
> Large incumbents c= ould 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.  <= br>
With the addition of thread expiration, nobody will be rea= lly motivated to shell/buy "next-coinbase" addresses since their utility is l= imited.

Just a remark: Notice this algorithm re= duces the electricity bill, but the hardware needed stays the same, since fo= r each round the miner participates in, it will try to mine as fast as possi= ble 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=20 for any miner with sufficient hashpower to deliberately cause a small=20 reorg. 

--
nullius@nym.zone | PGP ECC: 0xC2E91C= D74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)=
=E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have nothi= ng to hide.=E2=80=99
No!  Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80= =94 nullius

=


____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-30409492-9FAF-4667-BF83-E20C5D9C2025--