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 F25B2E2E for ; 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 ; 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 To: "nullius@nym.zone" , =?Windows-1252?Q?Enrique_Ariz=F3n_Benito?= , Bitcoin Protocol Discussion 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: References: <5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone>, In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 on behalf of Enrique Ariz=F3n Benito via bitcoin-d= ev 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

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.


Given the operation of pools, wou= ld a pool be required to mine the new-miner-blocks, or would you propose operation in a pool b= e restricted individually? How would this operate?


Regards,

Damian Williamson

From: bitcoin-dev-bounces@l= ists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org&= gt; on behalf of Enrique Ariz=F3n Benito via bitcoin-dev <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 impr= ove my first mail.

> Observation:  This totally destroys Bitcoin=92s transaction-= ordering security.  A =9351% attack=94 could be executed by any miner = who has >50% of the hashpower *proportionate to miners who are allowed t= o mine a particular block*, rather than >50% of *global* hashpower.  (I infer that this could be done retroactively, and wave = my hands over some of the details since you did not talk about reorgs.)&nbs= p; The same applies as for attacks requiring 33% or 25% of total hashpower.=  

I'm not sure what you are referring to in this paragraph. Imagine for = example that there are a total of, let's say, 2^10 available next-coinbase/= miners and the algorithm just allow 50% or 2^9 of them to mine, =BFhow coul= d it be possible that one among them could have 51% of power by chance? (Please, read comments bellow before re= plying)

> Potential attack, assuming that N *must* be based partly or wholl= y on the existing set of =93next-coinbase=94 addresses:  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+1) blocks (= =3D 2 * 2^N).  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.

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 "= spent" next-coinbase versus "un-spent" 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 "thread" of mining blocks for each new new-miner-block. Schema= tically a thread would look like:
new-miner-block:next-coinbase_1 -> mined-block:next-coinbase_2 ->&nbs= p; ... -> (thread expired - see comment below about expiration)

In this case a large miner A with T times more= power than another one B could potentially spent mining power to create T = parallel threads for each thread created by miner B. A solution that could = fix this issue is to allow a maximum life time for each thread expressed in number of blocks. After a given 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.

If the famous phrase "a degree of indirec= tion solve all programming problems" 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.
 
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 lis= t of registered non-expired next-coinbase addresses  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 +/- 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 "= ++N" 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.

> What part of which block hash is matched against N bits?  Yo= u were quite unclear about this, and other important details.  (Much o= f 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 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 "many" number must be for example twice = as much as the expected maximum numbers of blocks that a large miner can mi= ne in average.
 
> How, exactly, are reorgs handled?
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.
 
> How does this interact with the difficulty adjustment algorithm?&= nbsp; 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)&nbs= p; then difficulty/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 read your scheme, the =93new-miner-block=94 must necessarily have no = payout whatsoever.  But you discuss only =93new bitcoins=94,which are = a diminishing portion of the block reward, and will eventually reach zero.  Coinbase from fees must go somewhere; but under your sch= eme, a =93new miner=94 has no payable address.

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

> What if no existing =93next-coinbase=94 address matches?  Is= N constrained to be sufficiently short that a match is guaranteed from the= existing set, then that makes it trivial for large mining farms to collect= addresses and further dominate (or even monopolize) the network in the attack described above.  If it isn=92t, then the n= etwork could suddenly halt when nobody is allowed to mine the next block; a= nd that would enable *this* attack:

I think the previous algorithm I mention to replace the "wave of = hands" (test N=3D1, then N=3D2,... ) plus the "expiring threads&q= uot; would suffice to fix it.

>  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?  Contra what you say, block hashes can=92t be =93considered random=94.  Indeed, partial preimage = bruteforcing of block hashes is the entire basis of mining POW.

Again, that is fixed by the previous algorithm


> Asking here more generally than as for the attack described above= , what stops mining farms with large hashpower from submitting many differe= nt =93next-coinbase=94 addresses in many different blocks?  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.  **This increases mining centralization.**  If= N be large, then this creates the possibility (or raises the probability) = that no address will match, and nobody will be allowed to mine the next block.

Fixed by the expiring thread model?
 
How could miner anonymity be preserved under a scheme whereby each =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-payout block.  Mining can be totally anonymous at present, and must so remain.  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.

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.

 > 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?  (Allegedly, this is one reason why some big min= ers occasionally mine empty blocks.)  Though I suppose that difficulty would drop by unspecified means.

As explained above, the difficulty is reduced by 1/2^N for each round.= And of course, miners that want to save more energy will have to adapt to = put their systems on stand-by while they  are not chosen for the next = round. I think based on my limited experience with ASIC mining that just by not sending new orders to the miner the powe= r 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, wi= thout 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 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. 
 
> Add to that the uncompensated energy cost of mining that first block w= ith *no* payout,

I think it could be clearly compensated by the save in energy for stan= dards blocks.

>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.  Whereas incumbents are much favoured by your scheme, f= urther increasing miner centralization.

I don't think so after the new fixes. What do you think? My opinion is= that, based on the "theory of games", miners acting in their own= interest will try to maximize "N".
 
> Large incumbents could also use this to produce a mining permissi= ons market, by selling the private keys to committed =93next-coinbase=94 ad= dresses. 

With the addition of thread expiration, nobody will be really motivate= d to shell/buy "next-coinbase" addresses since their utility is l= imited.

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.


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:<= br> 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 nulliu= s



--_000_PS2P216MB017917D3FD62AB944098971C9DE80PS2P216MB0179KORP_--