The energy cost of mining cannot be reduced, nor is it rational to consider it “too high”.
e > On Jan 18, 2018, at 06:34, Enrique Arizón Benito via bitcoin-dev > <[email protected]> wrote: > > Thanks "nullius" for your remarks. Notice my first post was not an RFC but > just a blur idea to inspect if something similar had already been discussed > in the group. In fact your post has helped me a lot to improve my first mail. > > > Observation: This totally destroys Bitcoin’s transaction-ordering > > security. A “51% attack” could be executed by any miner who has >50% of > > the hashpower *proportionate to miners who are allowed to mine a particular > > block*, rather than >50% of *global* hashpower. (I infer that this could > > be done retroactively, and wave my hands over some of the details since you > > did not talk about reorgs.) The same applies as for attacks requiring 33% > > or 25% of total hashpower. > > I'm not sure what you are referring to in this paragraph. Imagine for example > that there are a total of, let's say, 2^10 available next-coinbase/miners and > the algorithm just allow 50% or 2^9 of them to mine, ¿how 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 “next-coinbase” addresses: A large miner could gradually > > push N higher, by progressively committing new “next-coinbase” addresses > > which differ in the next bit for all previously seen combinations of bits. > > Large miners would have a vast advantage over small miners, insofar as > > deliberately incrementing N by one more bit could only be done by a miner > > who creates 2^(N+1) blocks (= 2 * 2^N). By such means, it may be possible > > for a very large miner to eventually lock out all other miners altogether, > > and monopolize all Bitcoin mining. > > I do not think it would be easy even for a large miner but that made me think > for an alternative algorithm. Let's introduce the concept of "spent" > next-coinbase versus "un-spent" one, something like similarly to UTXO. A > next-coinbase would only be valid if it has not been previously used to mine > a block. Simplifying, with the spent vs unspent a large miner is restricted > to a single next-coinbase as anyone else. Being more precise it's allowed a > single next-coinbase for each mined new-miner-block mined creating a "thread" > of mining blocks for each new new-miner-block. Schematically a thread would > look like: > new-miner-block:next-coinbase_1 -> mined-block:next-coinbase_2 -> ... -> > (thread expired - see comment below about expiration) > > In this case a large miner A with T times more power than another one B could > potentially spent mining power to create T parallel threads for each thread > created by miner B. A solution that could fix this issue is to allow a > maximum life time for each thread expressed in number of blocks. After a > given number of blocks have being mined the miner is forced to create new > new-miner-block to continue participating. The algorithm to choose the > life-time must be such that if a miner tries to create many parallel threads > (many new-miner-block), by the time it start mining transaction blocks the > first new-miner-block will start to expire, so he will be punished. > > If the famous phrase "a degree of indirection solve all programming problems" > I think this is an example applied to blockchain. First the consensus chooses > who can participate in the next round, then selected miners participate in > the round. > >> Now, questions: >> >> How is N determined? By a wave of the hands? > > Great question. I left it unspecified in the first mail. An algorithm comes > to my mind (You are welcome to propose others). Let's imagine the list of > registered non-expired next-coinbase addresses is 2^10. The consensus checks > that for N=1 there is *about* 1/2^N == 1/2 of unspent next-coinbase addresses > that match (it must be close to 1/2 of the total 2^10 addresses with maybe an > small +/- 1% statistical deviation). Then N=1 will be accepted. Check now for > N=2. If there are 1/(2^N) = 1/4 next-coinbase addresses matching then N=2 is > accepted. The algorithm continues until some "++N" fails. Initially N=0 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 the threads will > expire and N will be automatically be decreased. Miners will act rationally > to keep enough threads open in their own interest since that will decrease > the electricity bill. > > > What part of which block hash is matched against N bits? You were quite > > unclear about this, and other important details. (Much of what I say here > > is based on assumptions and inferences necessary to fill in the blanks.) > > Thinking about it, the hash must run over "many" different blocks and it must > include the next next-coinbase (to force calculating the hash after choosing > a next-coinbase). Since it's not expected that many blocks are mined by the > same miner in a row (maybe no more than 2 o 3) the "many" number must be for > example twice as much as the expected maximum numbers of blocks that a large > miner can mine in average. > > > How, exactly, are reorgs handled? > I think reorgs are not affected by this algorithm. The next-coinbase > objective is just to randomly choose which miner will be allowed for the next > round. > > > How does this interact with the difficulty adjustment algorithm? Indeed, > > how is difficulty determined at all under your scheme? > As I see it, if the network wants to keep the same pace of new blocks each N > seconds, and N=1 (only half of the miners are allowed to mine) then > difficulty/power-bill is lowered by two, for N=2 by 4, ... > > > What happens to coinbase fees from a “new-miner-block”? The way I read > > your scheme, the “new-miner-block” must necessarily have no payout > > whatsoever. But you discuss only “new bitcoins”,which are a diminishing > > portion of the block reward, and will eventually reach zero. Coinbase from > > fees must go somewhere; but under your scheme, a “new miner” has no payable > > address. > > This new-miner-block will have NO transactions inside. > > > What if no existing “next-coinbase” 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’t, 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" (test > N=1, then N=2,... ) plus the "expiring threads" would suffice to fix it. > > > What stops a malicious miner (including a “new miner” creating a > > “new-miner block”) from deliberately working to create a block with a hash > > which does not have N bits matching any of the existing “next-coinbase” > > addresses? Contra what you say, block hashes can’t be “considered random”. > > Indeed, partial preimage bruteforcing of block hashes is the entire basis > > of mining POW. > > Again, that is fixed by the previous algorithm > > > > Asking here more generally than as for the attack described above, what > > stops mining farms with large hashpower from submitting many different > > “next-coinbase” 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 > > “next-coinbase” 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 >> “next-coinbase” address can be linked to a previous “next-coinbase” 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 certain information they choose to >> put in a block header, which they could choose to change or omit—or by IP >> address, which is trivially changed and is never a reliable identifier. >> > The anonymity decreases in the sense that if you know a next-coinbase address > owner you know all its related next-coinbase for the expiring > (physical-time-limited) thread. The anonymity increases in the sense that > miner will consume fewer energy. Electricity bill is the easiest way today to > trace miners. > > > How does this even save electricity, when there is much mining equipment > (especially on large mining farms) which cannot be easily shut down and > restarted? (Allegedly, this is one reason why some big miners occasionally > mine empty blocks.) Though I suppose that difficulty would drop by > unspecified means. > > As explained above, the difficulty is reduced by 1/2^N for each round. And of > course, miners that want to save more energy will have to adapt to put their > systems on stand-by while they are not chosen for the next round. I think > based on my limited experience with ASIC mining that just by not sending new > orders to the miner the power comsumption will decrease dramatically even if > the equipment is still on. >> >> Further observations: >> >> This scheme drastically increases the upfront investment required for a new >> miner to start mining. To mine even one new block all by oneself, without a >> pool, already requires a huge investment. > > Once introduced the concept of "expiring" thread I think he will be pretty > much in the same condition. To obtain bitcoins he will first need to mine a > new-miner-block to enter the game and then an standard block before the > thread expires. Notice the expire time/block-length start just after the > new-miner-block has been mined so the probabilities to mine before the > expiration time will be proportional to its mining power, as for everyone > else. > > > Add to that the uncompensated energy cost of mining that first block with > > *no* payout, > > I think it could be clearly compensated by the save in energy for standards > blocks. > > >and I expect that the bar would be prohibitive to almost all new > >entrants.Mining costs and incentives are delicately balanced by the design > >of the network. Whereas incumbents are much favoured by your scheme, > >further increasing miner centralization. > > I don't think so after the new fixes. What do you think? My opinion is that, > based on the "theory of games", miners acting in their own interest will try > to maximize "N". > > > Large incumbents could also use this to produce a mining permissions > > market, by selling the private keys to committed “next-coinbase” > > 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ón 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. >> >> -- >> [email protected] | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C >> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: >> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) >> “‘If you’re not doing anything wrong, you have nothing to hide.’ >> No! Because I do nothing wrong, I have nothing to show.” — nullius > > > > > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
