Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
On Friday 14 May 2021 21:41:23 Michael Fuhrmann via bitcoin-dev wrote: > Bitcoin should create blocks every 10 minutes in average. So why do > miners need to mine the 9 minutes after the last block was found? It's > not necessary. It increases security, and is unavoidable anyway. > Problem: How to prevent "pre-mining" in the 9 minutes time window? You can't. > Possible ideas for discussion: > > - (maybe most difficult) global network timer sending a salted hash time > code after 9 minutes. this enables validation by nodes. PoW *is* the global network timer. > - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just > high enough) times higher difficulty. so everyone can mine any time but > before to 9 minutes are up there will be a too high downside. It is more > efficient to wait then paying high bills. The bitcoin will get a "puls". There's no timestamp at this stage of consensus. On Sunday 16 May 2021 18:10:12 Karl via bitcoin-dev wrote: > The clock might be implementable on a peer network level by requiring > inclusion of a transaction that was broadcast after a 9 minute delay. That requires a centralised authority. On Sunday 16 May 2021 20:31:47 Anton Ragin via bitcoin-dev wrote: > 1. Has anyone considered that it might be technically not possible to > completely 'power down' mining rigs during this 'cool-down' period of time? > While modern CPUs have power-saving modes, I am not sure about ASICs used > for mining. That would be miners' problem, not the network's... New ASICs would no doubt be made to work more efficiently. > 2. I am not a huge data-center specialist, but it was my understanding that > they charge per unit of installed (maximum) electricity consumption. It > would mean that if the miner needs X kilowatts-hour within that 1 minute > when they are allowed to mine, he/she will have to pay for the same X for > the remaining 9 minutes - and as such would have no economic incentive not > to draw that power when idling. Actually, this would be a good thing: it would heavily discourage datacentre use (which is very harmful to mining decentralisation). > 4. My counter-proposal to the community to address energy consumption > problems would be *to encourage users to allow only 'green miners' process > their transaction.* In particular: >... > (b) Should there be some non-profit organization(s) certifying green miners > and giving them cryptographic certificates of conformity (either usage of > green energy or purchase of offsets), users could encrypt their > transactions and submit to mempool in such a format that *only green miners > would be able to decrypt and process them*. Hello centralisation. Might as well just have someone sign miner keys, and get rid of PoW entirely... ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
> 1. Has anyone considered that it might be technically not possible to > completely 'power down' mining rigs during this 'cool-down' period of time? > While modern CPUs have power-saving modes, I am not sure about ASICs used for > mining. Sounds like a point to consider, note the economic pressure of course so most people will find a way to power down. > 2. I am not a huge data-center specialist, but it was my understanding that > they charge per unit of installed (maximum) electricity consumption. It would > mean that if the miner needs X kilowatts-hour within that 1 minute when they > are allowed to mine, he/she will have to pay for the same X for the remaining > 9 minutes - and as such would have no economic incentive not to draw that > power when idling. That sounds kind of exotic, could you take charge of checking to see how true it is? > (a) Environmental concerns cause Bitcoin to be less popular and thus push the > price lower, which in turn lowers miner's power consumption (lower Bitcoin > price => less they can afford to spend on electricity). So it is a > self-stabilizing system to begin with. I like the idea but history shows that money outcompetes cute animals. > (b) Crazy power consumption may be a temporary problem, after the number of > halving events economic attractiveness of mining will decrease and power > consumption with it. If hashrate flattens, the chain security situation changes too. > 4. My counter-proposal to the community to address energy consumption > problems would be to encourage users to allow only 'green miners' process > their transaction. In particular: This cool idea of providing a way for users to support different miners with their transactions is not in conflict with reducing mining time. Both of these ideas are great ones; they are very different. On 5/16/21, Zac Greenwood wrote: >> if energy is only expended for 10% of the same duration, this money must > now be spent on hardware. > > More equipment obviously increases the total energy usage. Are there people who can freely produce new mining equipment to an arbitrary degree? As I mentioned already and you didn't address, I thought the supply was limited. > For your proposal again this means that energy usage would not be likely to > decrease appreciably, because large miners having access to near-free energy > use the block-reward sized budget fully on equipment and other operational > expenses. Purchasing equipment with the same funds is unrelated to whether or not the machines are running full blast during a theoretical 90% downtime when a hash cannot succeed. If their electricity is free, they have no new funds to buy equipment with. Additionally, you claim that all these people use renewable energy so I don't know why they are being discussed at all. > On the other hand, roughly every four years the coinbase reward halves, which > does significantly lower the miner budget, at least in terms of BTC. Adjusting that could be another good approach to influencing properties of the chain. I think there's another thread around it, rather than this one. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
> if energy is only expended for 10% of the same duration, this money must now be spent on hardware. More equipment obviously increases the total energy usage. You correctly point out that the total expenses of a miner are not just energy but include capital expenses for equipment and operational cost for staff, rent etc. Actually, non-energy expenses are perhaps a much larger fraction of the total cost than you might expect. Miners using excess waste energy such as Chinese miners close to hydropower stations pay a near zero price for energy and are unlikely to be bound by the price of electricity. Unsurprisingly, miners having access to near-free electricity are responsible for a significant share of the total energy usage of Bitcoin. Since such energy is often waste energy from renewable sources such as hydropower, the carbon footprint of Bitcoin is not nearly as alarming as its energy usage implies. In fact, since mining is a race to the bottom in terms of cost, these large miners drive out competing miners that employ more expensive, often non-renewable sources of energy. It’s for instance impossible to mine profitably using household-priced electricity. Looking at it from that angle, access to renewable, near-free waste energy helps keeping Bitcoin more green than it would otherwise be. To put it another way: the high energy usage of the Bitcoin network indicates cheap, otherwise wasted energy is employed. For your proposal again this means that energy usage would not be likely to decrease appreciably, because large miners having access to near-free energy use the block-reward sized budget fully on equipment and other operational expenses. On the other hand, roughly every four years the coinbase reward halves, which does significantly lower the miner budget, at least in terms of BTC. Zac On Sun, 16 May 2021 at 21:02, Karl via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > [sorry if I haven't replied to the other thread on this, I get swamped > by email and don't catch them all] > > This solution is workable but it seems somewhat difficult to me at this > time. > > The clock might be implementable on a peer network level by requiring > inclusion of a transaction that was broadcast after a 9 minute delay. > > Usually a 50% hashrate attack is needed to reverse a transaction in > bitcoin. With this change, this naively appears to become a 5% > hashrate attack, unless a second source of truth around time and order > is added, to verify proposed histories with. > > A 5% hashrate attack is much harder here, because the users of mining > pools would be mining only 10% of the time, so compromising mining > pools would not be as useful. > > Historically, hashrate has increased exponentially. This means that > the difficulty of performing an attack, whether it is 5% or 50%, is > still culturally infeasible because it is a multiplicative, rather > than an exponential, change. > > If this approach were to be implemented, it could be important to > consider how many block confirmations people wait for to trust their > transaction is on the chain. A lone powerful miner could > intentionally fork the chain more easily by a factor of 10. They > would need to have hashrate that competes with a major pool to do so. > > > How would you prevent miners to already compute the simpler difficulty > problem directly after the block was found and publish their solution > directly after minute 9? We would always have many people with a finished / > competing solution. > > Such a chain would have to wait a longer time to add further blocks > and would permanently be shorter. > > > Your proposal won’t save any energy because it does nothing to decrease > the budget available to mine a block (being the block reward). > > You are assuming this budget is directly related to energy > expenditure, but if energy is only expended for 10% of the same > duration, this money must now be spent on hardware. The supply of > bitcoin hardware is limited. > > In the long term, it won't be, so a 10% decrease is a stop-gap > measure. Additionally, in the long term, we will have quantum > computers and AI-designed cryptography algorithms, so things will be > different in a lot of other ways too. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
1. Has anyone considered that it might be technically not possible to completely 'power down' mining rigs during this 'cool-down' period of time? While modern CPUs have power-saving modes, I am not sure about ASICs used for mining. 2. I am not a huge data-center specialist, but it was my understanding that they charge per unit of installed (maximum) electricity consumption. It would mean that if the miner needs X kilowatts-hour within that 1 minute when they are allowed to mine, he/she will have to pay for the same X for the remaining 9 minutes - and as such would have no economic incentive not to draw that power when idling. 3. Not really a criticism of the idea to reduce Bitcoin energy consumption, but rather a couple of observations: (a) Environmental concerns cause Bitcoin to be less popular and thus push the price lower, which in turn lowers miner's power consumption (lower Bitcoin price => less they can afford to spend on electricity). So it is a self-stabilizing system to begin with. (b) Crazy power consumption may be a temporary problem, after the number of halving events economic attractiveness of mining will decrease and power consumption with it. 4. My counter-proposal to the community to address energy consumption problems would be *to encourage users to allow only 'green miners' process their transaction.* In particular: (a) According to this source ( https://www.blockchain.com/charts/transaction-fees-usd), fees represent approximately 12.5% of total miner reward. Not a lot, but not insignificant either. (b) Based on the method used in this source ( https://digiconomist.net/bitcoin-energy-consumption/) to offset CO2 emissions of bitcoin mining the miner would need to spend approx ~3.6% - 7.2% (depending how 'dirty' is his power source) x 87.5% (mined portion of its rewards) of its fees (assuming 50k Bitcoin price and 15$ / tonne of CO2 price of carbon offset). (b) Should there be some non-profit organization(s) certifying green miners and giving them cryptographic certificates of conformity (either usage of green energy or purchase of offsets), users could encrypt their transactions and submit to mempool in such a format that *only green miners would be able to decrypt and process them*. Users routing transactions specifically to 'green miners' (and posting potentially higher fees) would create economic incentives for miners to use green energy and/or buy CO2 offsets, as described above with ~3.1% - 6.8% of total revenue cost to offset CO2 vs.12.5% of fees component in mining, if majority of users would use the routing to green miners method - there is a chance that Bitcoin network will become significantly greener. Anton. On Sun, May 16, 2021 at 8:02 PM Karl via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > [sorry if I haven't replied to the other thread on this, I get swamped > by email and don't catch them all] > > This solution is workable but it seems somewhat difficult to me at this > time. > > The clock might be implementable on a peer network level by requiring > inclusion of a transaction that was broadcast after a 9 minute delay. > > Usually a 50% hashrate attack is needed to reverse a transaction in > bitcoin. With this change, this naively appears to become a 5% > hashrate attack, unless a second source of truth around time and order > is added, to verify proposed histories with. > > A 5% hashrate attack is much harder here, because the users of mining > pools would be mining only 10% of the time, so compromising mining > pools would not be as useful. > > Historically, hashrate has increased exponentially. This means that > the difficulty of performing an attack, whether it is 5% or 50%, is > still culturally infeasible because it is a multiplicative, rather > than an exponential, change. > > If this approach were to be implemented, it could be important to > consider how many block confirmations people wait for to trust their > transaction is on the chain. A lone powerful miner could > intentionally fork the chain more easily by a factor of 10. They > would need to have hashrate that competes with a major pool to do so. > > > How would you prevent miners to already compute the simpler difficulty > problem directly after the block was found and publish their solution > directly after minute 9? We would always have many people with a finished / > competing solution. > > Such a chain would have to wait a longer time to add further blocks > and would permanently be shorter. > > > Your proposal won’t save any energy because it does nothing to decrease > the budget available to mine a block (being the block reward). > > You are assuming this budget is directly related to energy > expenditure, but if energy is only expended for 10% of the same > duration, this money must now be spent on hardware. The supply of > bitcoin hardware is limited. > > In the long term, it won't be, so a 10% decrease is a stop-gap > measure. Additionally, in the long term, we
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
[sorry if I haven't replied to the other thread on this, I get swamped by email and don't catch them all] This solution is workable but it seems somewhat difficult to me at this time. The clock might be implementable on a peer network level by requiring inclusion of a transaction that was broadcast after a 9 minute delay. Usually a 50% hashrate attack is needed to reverse a transaction in bitcoin. With this change, this naively appears to become a 5% hashrate attack, unless a second source of truth around time and order is added, to verify proposed histories with. A 5% hashrate attack is much harder here, because the users of mining pools would be mining only 10% of the time, so compromising mining pools would not be as useful. Historically, hashrate has increased exponentially. This means that the difficulty of performing an attack, whether it is 5% or 50%, is still culturally infeasible because it is a multiplicative, rather than an exponential, change. If this approach were to be implemented, it could be important to consider how many block confirmations people wait for to trust their transaction is on the chain. A lone powerful miner could intentionally fork the chain more easily by a factor of 10. They would need to have hashrate that competes with a major pool to do so. > How would you prevent miners to already compute the simpler difficulty > problem directly after the block was found and publish their solution > directly after minute 9? We would always have many people with a finished / > competing solution. Such a chain would have to wait a longer time to add further blocks and would permanently be shorter. > Your proposal won’t save any energy because it does nothing to decrease the > budget available to mine a block (being the block reward). You are assuming this budget is directly related to energy expenditure, but if energy is only expended for 10% of the same duration, this money must now be spent on hardware. The supply of bitcoin hardware is limited. In the long term, it won't be, so a 10% decrease is a stop-gap measure. Additionally, in the long term, we will have quantum computers and AI-designed cryptography algorithms, so things will be different in a lot of other ways too. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
Hi Michael, Your proposal won’t save any energy because it does nothing to decrease the budget available to mine a block (being the block reward). Even if it were technically possible to find a way for nodes to somehow reach consensus on a hash that gets generated after 9 minutes, all it achieves is that miners will be expending the entire budget given to them in the form of the block reward within a single minute on average. Also please realize that the energy expenditure of Bitcoin is a fundamental part of its design. An attacker has no other option than to expend as much as half of all the miners together do in order for a sustained 51% attack to be successful, making such attack uneconomical. Zac On Sat, 15 May 2021 at 23:57, Michael Fuhrmann via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > Bitcoin should create blocks every 10 minutes in average. So why do > miners need to mine the 9 minutes after the last block was found? It's > not necessary. > > Problem: How to prevent "pre-mining" in the 9 minutes time window? > > Possible ideas for discussion: > > - (maybe most difficult) global network timer sending a salted hash time > code after 9 minutes. this enables validation by nodes. > > - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just > high enough) times higher difficulty. so everyone can mine any time but > before to 9 minutes are up there will be a too high downside. It is more > efficient to wait then paying high bills. The bitcoin will get a "puls". > > > I dont think I see all problems behind these ideas but if there is a > working solution to do so then the energy fud will find it's end. Saving > energy without loosing rosbustness. > > > > :) > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
