path: root/e9/f8f2e6888ab912484b4b0051ccbcffbfb04034

Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F25B2E2E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 18 Jan 2018 08:24:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-HK2-obe.outbound.protection.outlook.com
	(mail-oln040092255023.outbound.protection.outlook.com [40.92.255.23])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B6EBE7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 18 Jan 2018 08:24:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; 
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
	bh=JD1LRB1D5EX7mtRQMoRv4zIWLaRLtE0HEFW9JGSah2Q=;
	b=ttvwiw1KtB3pjYJEtGIn9OCwaqipPkY5YZ5e7AK9h+TNJDmuDMjyfdyU4bUwb1C+EOuE1IfYFuVyA9FGEn9Q8NAjXaRUMLWkdYKjMF1JPGngbRrLrA7qo+JQdxFjr7bMPhB4oAAu2/pmxSKdGDwpPDBtLeq85QtCLgTznNIjvd7xagtKzPhwozb1WjHslaMGC7CbA1pKWE3f6UUZq/GQeaEPPzL6FiihFZbiaIHq03/Wfb7m3MfAa22oWcTvjT7SUjNsFVfH6veNaEwbl0js3xXSl0Hp3ACDw6BY1EX9w78ilDqmeTD08nx/GvGf/UxPPbJsT6UdN6vnAY303tTnrw==
Received: from HK2APC01FT038.eop-APC01.prod.protection.outlook.com
	(10.152.248.51) by HK2APC01HT055.eop-APC01.prod.protection.outlook.com
	(10.152.249.220) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.12;
	Thu, 18 Jan 2018 08:24:40 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.248.57) by
	HK2APC01FT038.mail.protection.outlook.com (10.152.248.243) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.12 via
	Frontend Transport; Thu, 18 Jan 2018 08:24:40 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by
	PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id
	15.20.0407.012; Thu, 18 Jan 2018 08:24:40 +0000
From: Damian Williamson <willtech@live.com.au>
To: "nullius@nym.zone" <nullius@nym.zone>,
	=?Windows-1252?Q?Enrique_Ariz=F3n_Benito?=
	<enrique.arizonbenito@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Proposal to reduce mining power bill
Thread-Index: AQHTjlM+8R+5SoILrkevmf2tHXZ8B6N1oDkAgAMJt4CAAKMkJA==
Date: Thu, 18 Jan 2018 08:24:40 +0000
Message-ID: <PS2P216MB017917D3FD62AB944098971C9DE80@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com>
	<5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone>,
	<CAD-msxGPsAR=SVzScE1dVsFaN4kBKySSP6U5Q0P7vXxBMcEiqQ@mail.gmail.com>
In-Reply-To: <CAD-msxGPsAR=SVzScE1dVsFaN4kBKySSP6U5Q0P7vXxBMcEiqQ@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:07BB6A3870CEA08934E00AC96AADA1F9ABE1DC451AFBC5190F542E0C5FA5B6D0;
	UpperCasedChecksum:E1A6D51E747FF85D39A4D19AF944CFE85587565E29A8FAB5F9634F8AF3142E1A;
	SizeAsReceived:7313; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [BYVzI8KwaCFNMwLUhyHmlNm1jg4VlVjW]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HK2APC01HT055;
	6:uhzc6Yme80jYoqIDgdz79N8lzIgzIPyasBPoWxsm36+w1nUEhTjM/qg0itaX4J+pqIcuqLMURajQCBcQjhpLE9b+b7aX4Uxrd60psjqSUNMvRC4e+edJMpqmQH8OCDHxTajYV5VfGuSm9cLFDf1n9w0e3sswkIaEnkr2QF89Rji/ZBjCD3heR9s9tRrC1UPuS9hnXElhPg5BGK46QEohibVFtjO1/Q0Dr7aD/aDZPZ6bO/uIF1qyQ961KJ1H2pi3FVlIMm2RYi5WfAdLgcva5MrTW67vSCTwNUc97uwt1vsOeNsRW9BMCDdTefLE0J8EW8Ow0bPOrmw6sh8n6cRdBFSL0hrWE9TpHVUJyxOskYE=;
	5:/qjw90h7I/JXIM6/qzoXb7ZNIwSZTeoaYVYLkKOhjQmIrWWh8SLbPG6YR3/S9yEBVparQRaA+NoyxcXBGh2oj7ruE+YQt8x/HFWXYDps5YdPJrxBsIaCtXO6t4AEikYSDsGobY0Xg9Lki3up2dJUpCMdldgCW6netIJ8HZgdj6c=;
	24:hXQjH6sidD+Go8eMpVdi/PWVffIeDz6xp9iUabk3PqvWc4uP7daUSlU/i1skBO1DoGsjslwsyJ5eXUh/xY0/dl3/r1UdtUTv+V3rIRh7aQU=;
	7:JWTEKCCXSWJhmTFdJjB8dVUDTDhYuJPNPUZNnV+7pI6ETqagLWl1Ra9MEyb8hGTmbQsF6I5NtM4FwdwWXtDE83qNfK3qbL7iP5bwAXl92XNabj7JywHzWojUnw5ylRskTbBHfEqcV5CLRiWW5/YflkcBaORhNpNaFwgSPq3mJbny6JbkJukqKOtvjTvnOSTrZvusoOl6A2ksCgHM5C3samGoaCDtjG84oAlHgZ7Fl4vsa20KGuIFX8sWnbxecXSA
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(7020095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045);
	SRVR:HK2APC01HT055; 
x-ms-traffictypediagnostic: HK2APC01HT055:
x-ms-office365-filtering-correlation-id: 9ea5a669-3f2a-453f-3b90-08d55e4cebb6
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:HK2APC01HT055; BCL:0; PCL:0;
	RULEID:(100000803101)(100110400095); SRVR:HK2APC01HT055; 
x-forefront-prvs: 05568D1FF7
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:HK2APC01HT055;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB017917D3FD62AB944098971C9DE80PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9ea5a669-3f2a-453f-3b90-08d55e4cebb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2018 08:24:40.7125 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT055
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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: Thu, 18 Jan 2018 15:51:25 +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: Thu, 18 Jan 2018 08:24:46 -0000

--_000_PS2P216MB017917D3FD62AB944098971C9DE80PS2P216MB0179KORP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

It probably could be noted, although it is well known, pools, in some views=
, act as one large individual miner, not just when separately considering t=
he actions of pools.


Given the operation of pools, would a pool be required to mine the new-mine=
r-blocks, or would you propose operation in a pool be restricted individual=
ly? How would this operate?


Regards,

Damian Williamson

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Enrique Ariz=F3n Benito via bitcoin-d=
ev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Thursday, 18 January 2018 9:34:11 AM
To: nullius@nym.zone; bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal to reduce mining power bill

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 ma=
il.

> Observation:  This totally destroys Bitcoin=92s transaction-ordering secu=
rity.  A =9351% attack=94 could be executed by any miner who has >50% of th=
e hashpower *proportionate to miners who are allowed to mine a particular b=
lock*, 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 d=
id not talk about reorgs.)  The same applies as for attacks requiring 33% o=
r 25% of total hashpower.

I'm not sure what you are referring to in this paragraph. Imagine for examp=
le 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, =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 =93next-coinbase=94 addresses:  A large miner could gradua=
lly push N higher, by progressively committing new =93next-coinbase=94 addr=
esses which differ in the next bit for all previously seen combinations of =
bits. Large miners would have a vast advantage over small miners, insofar a=
s 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 possib=
le for a very large miner to eventually lock out all other miners altogethe=
r, and monopolize all Bitcoin mining.

I do not think it would be easy even for a large miner but that made me thi=
nk 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-=
coinbase would only be valid if it has not been previously used to mine a b=
lock. 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 s=
ingle next-coinbase for each mined new-miner-block mined creating a "thread=
" of mining blocks for each new new-miner-block. Schematically a thread wou=
ld 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 cou=
ld 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 =
maximum life time for each thread expressed in number of blocks. After a gi=
ven 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-ti=
me 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 problem=
s" I think this is an example applied to blockchain. First the consensus ch=
ooses who can participate in the next round, then selected miners participa=
te 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 chec=
ks that for N=3D1 there is *about* 1/2^N =3D=3D 1/2 of unspent next-coinbas=
e 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 acce=
pted. Check now for N=3D2. If there are 1/(2^N) =3D 1/4 next-coinbase addre=
sses matching then N=3D2 is accepted. The algorithm continues until some "+=
+N" fails. 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 e=
quilibrium naturally. If new miners stop producing new new-miner-blocks, ev=
entually the threads will expire and N will be automatically be decreased. =
Miners will act rationally to keep enough threads open in their own interes=
t 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 mu=
st 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 b=
y 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 tha=
t a large miner can mine in average.

> How, exactly, are reorgs handled?
I think reorgs are not affected by this algorithm. The next-coinbase object=
ive is just to randomly choose which miner will be allowed for the next rou=
nd.

> 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, ...

> What happens to coinbase fees from a =93new-miner-block=94?  The way I re=
ad your scheme, the =93new-miner-block=94 must necessarily have no payout w=
hatsoever.  But you discuss only =93new bitcoins=94,which are a diminishing=
 portion of the block reward, and will eventually reach zero.  Coinbase fro=
m fees must go somewhere; but under your scheme, a =93new miner=94 has no p=
ayable address.

This new-miner-block will have NO transactions inside.

> What if no existing =93next-coinbase=94 address matches?  Is N constraine=
d 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 an=
d further dominate (or even monopolize) the network in the attack described=
 above.  If it isn=92t, then the network could suddenly halt when nobody 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" (te=
st N=3D1, then N=3D2,... ) plus the "expiring threads" would suffice to fix=
 it.

>  What stops a malicious miner (including a =93new miner=94 creating a =93=
new-miner block=94) from deliberately working to create a block with a hash=
 which does not have N bits matching any of the existing =93next-coinbase=
=94 addresses?  Contra what you say, block hashes can=92t be =93considered =
random=94.  Indeed, partial preimage bruteforcing of block hashes is the en=
tire basis of mining POW.

Again, that is fixed by the previous algorithm


> Asking here more generally than as for the attack described above, what s=
tops mining farms with large hashpower from submitting many different =93ne=
xt-coinbase=94 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 =
=93next-coinbase=94 addresses which match any N.  **This increases mining c=
entralization.**  If N be large, then this creates the possibility (or rais=
es 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 =93next-=
coinbase=94 address can be linked to a previous =93next-coinbase=94 address=
?  The only way to start fresh would be with a prohibitively expensive no-p=
ayout block.  Mining can be totally anonymous at present, and must so remai=
n.  Miners are only identified by certain information they choose to put in=
 a block header, which they could choose to change or omit=97or by IP addre=
ss, which is trivially changed and is never a reliable identifier.

The anonymity decreases in the sense that if you know a next-coinbase addre=
ss 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 mi=
ners.

 > How does this even save electricity, when there is much mining equipment=
 (especially on large mining farms) which cannot be easily shut down and re=
started?  (Allegedly, this is one reason why some big miners occasionally m=
ine empty blocks.)  Though I suppose that difficulty would drop by unspecif=
ied 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 t=
heir systems on stand-by while they  are not chosen for the next round. I t=
hink based on my limited experience with ASIC mining that just by not sendi=
ng 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 th=
read expires. Notice the expire time/block-length start just after the new-=
miner-block has been mined so the probabilities to mine before the expirati=
on 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 ne=
twork.  Whereas incumbents are much favoured by your scheme, further increa=
sing 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 mark=
et, by selling the private keys to committed =93next-coinbase=94 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=F3n 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)
=93=91If you=92re not doing anything wrong, you have nothing to hide.=92
No!  Because I do nothing wrong, I have nothing to show.=94 =97 nullius




--_000_PS2P216MB017917D3FD62AB944098971C9DE80PS2P216MB0179KORP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">It probably could be noted, altho=
ugh it is well known, pools, in some views, act as one large individual min=
er, not just when separately considering the actions of pools.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Given the operation of pools, wou=
ld a pool be required to
<span>mine the new-miner-blocks, or would you propose operation in a pool b=
e restricted individually? How would this operate?</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span><br>
</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>Regards,</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><span>Damian Williamson</span><br=
>
</p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Enrique Ariz=F3n Benito via bitcoin-dev
 &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> Thursday, 18 January 2018 9:34:11 AM<br>
<b>To:</b> nullius@nym.zone; bitcoin-dev@lists.linuxfoundation.org<br>
<b>Subject:</b> Re: [bitcoin-dev] Proposal to reduce mining power bill</fon=
t>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">
<div>Thanks &quot;nullius&quot; 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 impr=
ove my first mail.<br>
</div>
<div><br>
</div>
<div>&gt; Observation:&nbsp; This totally destroys Bitcoin=92s transaction-=
ordering security.&nbsp; A =9351% attack=94 could be executed by any miner =
who has &gt;50% of the hashpower *proportionate to miners who are allowed t=
o mine a particular block*, rather than &gt;50% of *global*
 hashpower.&nbsp; (I infer that this could be done retroactively, and wave =
my hands over some of the details since you did not talk about reorgs.)&nbs=
p; The same applies as for attacks requiring 33% or 25% of total hashpower.=
&nbsp;</div>
<div class=3D"x_gmail_extra">
<div class=3D"x_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 and the algorithm just allow 50% or 2^9 of them to mine, =BFhow coul=
d it be possible that one among them
 could have 51% of power by chance? (Please, read comments bellow before re=
plying)<br>
</div>
<div><br>
</div>
<div>&gt; Potential attack, assuming that N *must* be based partly or wholl=
y on the existing set of =93next-coinbase=94 addresses:&nbsp; A large miner=
 could gradually push N higher, by progressively committing new =93next-coi=
nbase=94 addresses which differ in the next bit
 for all previously seen combinations of bits. Large miners would have a va=
st advantage over small miners, insofar as deliberately incrementing N by o=
ne more bit could only be done by a miner who creates 2^(N&#43;1) blocks (=
=3D 2 * 2^N).&nbsp; By such means, it may be
 possible for a very large miner to eventually lock out all other miners al=
together, and monopolize all Bitcoin mining.</div>
<div><br>
</div>
<div>I do not think it would be easy even for a large miner but that made m=
e think for an alternative algorithm. Let's introduce the concept of &quot;=
spent&quot; next-coinbase versus &quot;un-spent&quot; one, something like s=
imilarly 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 &quot;thread&quot; of mining blocks for each new new-miner-block. Schema=
tically a thread would look like:
<br>
new-miner-block:next-coinbase_1 -&gt; mined-block:next-coinbase_2 -&gt;&nbs=
p; ... -&gt; (thread expired - see comment below about expiration)<br>
</div>
<br>
</div>
<div class=3D"x_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 solution that could =
fix this issue is to allow a maximum
 life time for each thread expressed in number of blocks. After a given num=
ber 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, s=
o he will be punished.<br>
<br>
</div>
<div class=3D"x_gmail_quote">If the famous phrase &quot;a degree of indirec=
tion solve all programming problems&quot; I think this is an example applie=
d to blockchain. First the consensus chooses who can participate in the nex=
t round, then selected miners participate in
 the round.<br>
</div>
<div class=3D"x_gmail_quote">
<div>&nbsp;</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-left: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 algorithm =
comes to my mind (You are welcome to propose others). Let's imagine the lis=
t of registered non-expired next-coinbase addresses&nbsp; is 2^10. The cons=
ensus 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 &#43;/- 1% st=
atistical 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 some &quot;=
&#43;&#43;N&quot; fails. Initially N=3D0 and so all miners are welcome to t=
he game. They all will start producing next-coinbase addresses and when the=
re are enough different ones N will become 1, then 2,
 ... This system will will keep an equilibrium naturally. If new miners sto=
p producing new new-miner-blocks, eventually the threads will expire and N =
will be automatically be decreased. Miners will act rationally to keep enou=
gh threads open in their own interest
 since that will decrease the electricity bill.<br>
<br>
</div>
<div>&gt; What part of which block hash is matched against N bits?&nbsp; Yo=
u were quite unclear about this, and other important details.&nbsp; (Much o=
f what I say here is based on assumptions and inferences necessary to fill =
in the blanks.)</div>
<div><br>
</div>
<div>Thinking about it, the hash must run over &quot;many&quot; different b=
locks 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 blo=
cks are mined by the same miner in a row (maybe
 no more than 2 o 3) the &quot;many&quot; number must be for example twice =
as much as the expected maximum numbers of blocks that a large miner can mi=
ne 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 o=
bjective is just to randomly choose which miner will be allowed for the nex=
t round.<br>
</div>
<div>&nbsp;</div>
<div>&gt; How does this interact with the difficulty adjustment algorithm?&=
nbsp; Indeed, how is difficulty determined 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)&nbs=
p; then difficulty/power-bill is lowered by two, for N=3D2 by 4, ...</div>
<div><br>
</div>
&gt; What happens to coinbase fees from a =93new-miner-block=94?&nbsp; The =
way I read your scheme, the =93new-miner-block=94 must necessarily have no =
payout whatsoever.&nbsp; But you discuss only =93new bitcoins=94,which are =
a diminishing portion of the block reward, and will eventually
 reach zero.&nbsp; Coinbase from fees must go somewhere; but under your sch=
eme, a =93new miner=94 has no payable address.
<div><br>
</div>
<div>This new-miner-block will have NO transactions inside.<br>
</div>
<div><br>
</div>
<div>&gt; What if no existing =93next-coinbase=94 address matches?&nbsp; 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.&nbsp; If it isn=92t, then the n=
etwork could suddenly halt when nobody is allowed to mine the next block; a=
nd that would enable *this* attack:</div>
<div><br>
</div>
<div>I think the previous algorithm I mention to replace the &quot;wave of =
hands&quot; (test N=3D1, then N=3D2,... ) plus the &quot;expiring threads&q=
uot; would suffice to fix it.<br>
</div>
<div><br>
</div>
<div>&gt;&nbsp; What stops a malicious miner (including a =93new miner=94 c=
reating a =93new-miner block=94) from deliberately working to create a bloc=
k with a hash which does not have N bits matching any of the existing =93ne=
xt-coinbase=94 addresses?&nbsp; Contra what you say, block
 hashes can=92t be =93considered random=94.&nbsp; Indeed, partial preimage =
bruteforcing of block hashes is the entire basis of mining POW.<br>
</div>
<div><br>
</div>
<div>Again, that is fixed by the previous algorithm</div>
<div><br>
</div>
<div><br>
</div>
<div>&gt; Asking here more generally than as for the attack described above=
, what stops mining farms with large hashpower from submitting many differe=
nt =93next-coinbase=94 addresses in many different blocks?&nbsp; If N be sm=
all, then it should be feasible for a large
 mining farm to eventually register a set of =93next-coinbase=94 addresses =
which match any N.&nbsp; **This increases mining centralization.**&nbsp; 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.<br>
<br>
</div>
<div>Fixed by the expiring thread model?<br>
</div>
<div>&nbsp;<br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-left:1px solid rgb(204,204,204); padding-left:1ex">
How could miner anonymity be preserved under a scheme whereby each =93next-=
coinbase=94 address can be linked to a previous =93next-coinbase=94 address=
?&nbsp; The only way to start fresh would be with a prohibitively expensive=
 no-payout block.&nbsp; Mining can be totally anonymous
 at present, and must so remain.&nbsp; Miners are only identified by certai=
n information they choose to put in a block header, which they could choose=
 to change or omit=97or by IP address, which is trivially changed and is ne=
ver a 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 expiring (phys=
ical-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>&nbsp;&gt; How does this even save electricity, when there is much min=
ing equipment (especially on large mining farms) which cannot be easily shu=
t down and restarted?&nbsp; (Allegedly, this is one reason why some big min=
ers occasionally mine empty blocks.)&nbsp; Though
 I suppose that difficulty would 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 want to save more energy will have to adapt to =
put their systems on stand-by while they&nbsp; 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 powe=
r comsumption will decrease dramatically even if the equipment is still on.=
<br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-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 new=
 miner to start mining.&nbsp; To mine even one new block all by oneself, wi=
thout a pool, already requires a huge investment.&nbsp;</blockquote>
<div>&nbsp;</div>
<div>Once introduced the concept of &quot;expiring&quot; 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 bloc=
k before the thread expires. Notice the expire
 time/block-length start just after the new-miner-block has been mined so t=
he probabilities to mine before the expiration time will be proportional to=
 its mining power, as for everyone else.&nbsp;
<br>
</div>
<div>&nbsp;</div>
&gt; Add to that the uncompensated energy cost of mining that first block w=
ith *no* payout,
<div><br>
</div>
<div>I think it could be clearly compensated by the save in energy for stan=
dards blocks.</div>
<div><br>
</div>
<div>&gt;and I expect that the bar would be prohibitive to almost all new e=
ntrants.Mining costs and incentives are delicately balanced by the design o=
f the network.&nbsp; Whereas incumbents are much favoured by your scheme, f=
urther 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 &quot;theory of games&quot;, miners acting in their own=
 interest will try to maximize &quot;N&quot;.
<br>
</div>
<div>&nbsp; <br>
</div>
<div>&gt; Large incumbents could also use this to produce a mining permissi=
ons market, by selling the private keys to committed =93next-coinbase=94 ad=
dresses.&nbsp;
<br>
<br>
</div>
<div>With the addition of thread expiration, nobody will be really motivate=
d to shell/buy &quot;next-coinbase&quot; addresses since their utility is l=
imited.<br>
</div>
<div><br>
</div>
<div>Just a remark: Notice this algorithm reduces the electricity bill, but=
 the hardware needed stays the same, since for each round the miner partici=
pates in, it will try to mine as fast as possible and so use as much hardwa=
re 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=F3n Benito</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-left:1px solid rgb(204,204,204); padding-left:1ex">
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.<s=
pan class=3D"x_gmail-m_6404816983919078843m_7057792341444477592m_2213594593=
287026671gmail-HOEnZb"></span>&nbsp;</blockquote>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-left:1px solid rgb(204,204,204); padding-left:1ex">
<span class=3D"x_gmail-m_6404816983919078843m_7057792341444477592m_22135945=
93287026671gmail-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)&nbsp; (PGP RSA: 0x36EBB4AB699A10EE=
)<br>
=93=91If you=92re not doing anything wrong, you have nothing to hide.=92<br=
>
No!&nbsp; Because I do nothing wrong, I have nothing to show.=94 =97 nulliu=
s<br>
</font></span></blockquote>
</div>
</div>
<div class=3D"x_gmail_extra"><br>
</div>
<div class=3D"x_gmail_extra"><br>
</div>
<div class=3D"x_gmail_extra"><br>
</div>
</div>
</div>
</body>
</html>

--_000_PS2P216MB017917D3FD62AB944098971C9DE80PS2P216MB0179KORP_--