path: root/d9/10cec1f3d9163b9a8e3247bdd02ba6fa097a2b

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7FF5D109D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 18 Jan 2018 05:22:54 +0000 (UTC)
Received: by mail-pg0-f54.google.com with SMTP id s9so11298300pgq.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <eric@voskuil.org>
X-Mailer: iPhone Mail (15C153)
In-Reply-To: <CAD-msxGPsAR=SVzScE1dVsFaN4kBKySSP6U5Q0P7vXxBMcEiqQ@mail.gmail.com>
Date: Thu, 18 Jan 2018 13:22:47 +0800
Content-Transfer-Encoding: 7bit
Message-Id: <2C70E809-0657-4FBE-9E12-008E2A7C4207@voskuil.org>
References: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com>
	<5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone>
	<CAD-msxGPsAR=SVzScE1dVsFaN4kBKySSP6U5Q0P7vXxBMcEiqQ@mail.gmail.com>
To: =?utf-8?Q?Enrique_Ariz=C3=B3n_Benito?= <enrique.arizonbenito@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <bit=
coin-dev@lists.linuxfoundation.org> 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>The energy cost of mining c=
annot be reduced, nor is it rational to consider it =E2=80=9Ctoo high=E2=80=9D=
.</div><div><br></div><div>e</div><div><br>On Jan 18, 2018, at 06:34, Enriqu=
e Ariz=C3=B3n Benito via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>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.<br></div><d=
iv><br></div><div>&gt; Observation:&nbsp; This totally destroys Bitcoin=E2=80=
=99s transaction-ordering=20
security.&nbsp; A =E2=80=9C51% attack=E2=80=9D could be executed by any mine=
r who has &gt;50%
 of the hashpower *proportionate to miners who are allowed to mine a=20
particular block*, rather than &gt;50% of *global* hashpower.&nbsp; (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.)&nbsp; The same applies as=20=

for attacks requiring 33% or 25% of total hashpower.&nbsp;</div><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>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)<br></div><div><br></div><div>&gt; 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:&nbsp; 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).&nbsp=
;=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.</di=
v><div><br></div><div>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: <br>new-miner-block:next-coinbase_1 -&gt; mined-b=
lock:next-coinbase_2 -&gt;&nbsp; ... -&gt; (thread expired - see comment bel=
ow about expiration)<br></div><br></div><div class=3D"gmail_quote">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.<br><br></div><div class=3D"gmai=
l_quote">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.<br></div><div class=3D"gmail_quote"><div>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
Now, questions:<br>
<br>
How is N determined?&nbsp; By a wave of the hands?<br></blockquote><div><br>=
</div><div>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&nbsp; 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.<br><br></div><div>&gt; What pa=
rt of which block hash is matched against N bits?&nbsp; You were quite
 unclear about this, and other important details.&nbsp; (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-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.<br>
</div><div>&nbsp;<br></div><div>&gt; How, exactly, are reorgs handled?</div>=
<div>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.<br></div><div>&nbsp;</div><div>&gt; How does this interact with the d=
ifficulty adjustment algorithm?&nbsp; Indeed, how is difficulty determined a=
t 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 min=
ers are allowed to mine)&nbsp; then difficulty/power-bill is lowered by two,=
 for N=3D2 by 4, ...</div><div><br></div>&gt;=20
What happens to coinbase fees from a =E2=80=9Cnew-miner-block=E2=80=9D?&nbsp=
; The way I read=20
your scheme, the =E2=80=9Cnew-miner-block=E2=80=9D must necessarily have no p=
ayout=20
whatsoever.&nbsp; 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.&nbsp; 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 n=
ew-miner-block will have NO transactions inside.<br></div><div><br> </div><d=
iv>&gt;=20

What if no existing =E2=80=9Cnext-coinbase=E2=80=9D address matches?&nbsp; 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.&nbsp; 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:</div><div><br></div><div>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.<br></div><div><br></div><d=
iv>&gt;&nbsp;
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?&nbsp; Contra what you say, block h=
ashes can=E2=80=99t be=20
=E2=80=9Cconsidered random=E2=80=9D.&nbsp; Indeed, partial preimage brutefor=
cing of block=20
hashes is the entire basis of mining POW.<br></div><div><br> </div><div>Agai=
n, that is fixed by the previous algorithm</div><div><br></div><div><br></di=
v><div>&gt; 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?&nbsp; 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.&nbsp; **=
This increases=20
mining centralization.**&nbsp; 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 th=
e expiring thread model?<br>
</div><div>&nbsp;<br></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">=

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?&nbsp; The only way to start fresh would be with a prohibitively=20
expensive no-payout block.&nbsp; Mining can be totally anonymous at present,=
=20
and must so remain.&nbsp; 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 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.<br></div><div><br></div><div>&nbsp;&gt; 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?&nbsp; (Allegedly, this is one reason why some big miners=20
occasionally mine empty blocks.)&nbsp; Though I suppose that difficulty woul=
d
 drop by unspecified means.</div><div><br></div><div>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&nbsp; 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.<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Further observations:<br>
<br>
This scheme drastically increases the upfront investment required for a=20
new miner to start mining.&nbsp; To mine even one new block all by oneself,=20=

without a pool, already requires a huge investment.&nbsp;</blockquote><div>&=
nbsp;</div><div>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.&nbsp; <br></div><div>&nbsp;</div>&gt; Add to that the=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 energy=
 for standards blocks.</div><div> <br></div><div>&gt;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.&nbsp; Whereas incumbents are much favoured by your=20=

scheme, further increasing miner centralization.</div><div><br></div><div>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". <br></div><div>&nbsp; <br></div><div>&gt; 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.&nbsp; <=
br><br></div><div>With the addition of thread expiration, nobody will be rea=
lly motivated to shell/buy "next-coinbase" addresses since their utility is l=
imited.<br></div><div><br></div><div>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.<br></div><div><br></div><div><br></div><div>Best Regards,</div=
><div><br></div><div>Enrique Ariz=C3=B3n Benito</div><div><br></div><div><br=
></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-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_22135=
94593287026671gmail-HOEnZb"></span>&nbsp;</blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><span class=3D"gmail-m_6404816983919078843m_70577=
92341444477592m_2213594593287026671gmail-HOEnZb"><font color=3D"#888888">
<br>
-- <br>
<a href=3D"mailto:nullius@nym.zone">nullius@nym.zone</a> | PGP ECC: 0xC2E91C=
D74A4C57A105F6C21B5A00<wbr>591B2F307E0C<br>
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7<wbr>f6agex98an7h | (Segwit nested:<b=
r>
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaY<wbr>kCnG)&nbsp; (PGP RSA: 0x36EBB4AB699A10EE)=
<br>
=E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have nothi=
ng to hide.=E2=80=99<br>
No!&nbsp; 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>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-30409492-9FAF-4667-BF83-E20C5D9C2025--