Re: [bitcoin-dev] Reducing block reward via soft fork
Well, it is done automatically every 4 years :) It is a self-balancing system - more people shout about Bitcoin being dirty -> less adoption -> lower the price -> less energy consumption. Add on top the fact that in 2024 block rewards will fall 50% anyway and someday it will be zero. I am all for making Bitcoin green(er), but IMHO there shall be no short-termism of the sort "Elon complained + price dropped 40% - lets go radically change things". IMHO if we want to make BTC cleaner we can add functionality where users can prioritise some miners over the others, with the view that users will prioritise "green" miners and they will get more TX fees, and there will be economic incentive to go green. On Sun, 23 May 2021, 09:49 James Lu via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > Background > === > Reducing the block reward reduces the incentive to mine. It reduces the > maximum energy price at which mining is profitable, reducing the energy use. > > Bitcoins have value because they are accepted by full node users, from > individual node operators, to exchanges and custodians like Coinbase. > Anything else and the Bitcoins don't exist and are worthless. Like all > currencies, Bitcoin has value because others recognize that they have value. > > Idea > === > Reduce the block reward by adding fewer coins to the UTXO set per block. > This should be done gradually > > Consensus layer > === > This is a soft fork, because it tightens the > > Some Possible Weaknesses > === > - It will cost less than a nation-state of energy to reverse recent > Bitcoin transactions. > - Some miners may protest and lobby exchanges. > - By pushing mining towards the cheapest energy sources, centralization > increases towards Chinese miners. > - The Bitcoin network may split if consensus is not built before flag day. > > However, given the current political headwinds and widespread public > discussion around Bitcoin's energy use, it may be socially possible to > ask individual users and major exchanges to install a version of Bitcoin > with a reduced block reward. > > Alternatives > === > Instead of outright rejecting transactions (and the blocks that contain > them) that attempt to spend increased block rewards, treat them as no-ops. > ___ > 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
hat fit your criteria. Since miners operate in a selfish > way, it is not in their interest to share your transaction with other > miners, and the probable case is that your transaction will only be > included in a block that is signed by your preferred authority. > > I should note though, that you may be waiting forever for your > transactions to be mined and your business partners might choose not to do > business with you in the future due to delays caused by virtue signaling to > nocoiners. > > > Please don't be dismissive, it is an open forum and everybody is > entitled to his/her/its own opinion. > > It is, in fact, an open forum and everyone is entitled to their view, > including being dismissive of yours. > > > I respectfully submit that people who know how to launch rockets to the > sky and beam high-speed internet from the satellites to every place on > earth are at least capable of understanding how Bitcoin works. There is > even an english expression which reads 'it is not a rocket science' which I > think fits especially nicely in this particular case :) > > No one is contesting that Elon and the rest of the technical staff at > Tesla are *capable* of understanding Bitcoin. We are just asserting that, > at present, they do not understand the underlying mechanics well enough to > give consistent rationale for their choices, and because their public > statements reveal either a deep hypocrisy, or deep ignorance in their > understanding of Bitcoin. > > Keagan > > On Mon, May 17, 2021 at 8:11 AM Anton Ragin via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hello, list >> >> >Hello centralisation. Might as well just have someone sign miner keys, >> and get >> >rid of PoW entirely... >> >No, it is not centralization - >> >> No, it is not centralization, as: >> >> (a) different miners could use different standards / certifications for >> 'green' status, there are many already; >> >> >> >> That does not refute the claim at all. Just because you can choose >> from multiple centralized authorities, which are well known and can >> collude, it does not mean it is decentralized by any reasonable definition >> of the term. >> >> (b) it does not affect stability of the network in a material way, rather >> creates small (12.5% of revenue max) incentive to move to green sources of >> energy (or buy carbon credits) and get certified - miners who would choose >> to run dirty energy will still be able to do so. >> and >> >> >> >> Who is to issue these credits? A centralized entity I guess ... There >> is no place for such in Bitcoin. >> >> If I am to concede on the point that *voluntarily* green-status miner >> certification is 'centralization', can you please explain *in detail* why >> aren't 'bitcoin.org' and GitHub repo similar examples of >> 'centralization'? You make a correct point that bitcoin.org and the >> GitHub repo are not 'official' things of Bitcoin network, however nowhere >> in my proposals on green miner certification I was suggesting to introduce >> an 'official' certificate for such a thing. May be I mis-formulated my >> ideas, in that case I apologize: >> >> The only thing which I suggested was to introduce an option to have some >> transactions encrypted in the mempool to allow Bitcoin users some control >> over who mines their transaction - full stop. Users could then decide how >> to use this functionality themselves, and such functionality could have >> uses way beyond 'green miners' - for example, some users might prefer to >> send their transactions *directly to trusted miners* to prevent certain >> quantum computer enabled attacks (e.g. when there is a window of >> opportunity to steal coins if you have fast QC when you spend even from >> p2phk address). Another example - if users are given some flexibility whom >> to send the transactions, they might actually want to steer them away from >> huge mining pools such as Antpool to support small independent miners, smth >> of this sort - which actually would boost diversity in the network. >> >> You may or may not agree that climate change is real, or may or may not >> agree that Bitcoin energy consumption is a problem - I respectfully submit >> it is not the right forum to find truth on these topics. We are discussing >> ideas which *might *make Bitcoin a better solution for users who care >> about certain things, *without *making it worse for somebody else (like >> you, for example - who don't like centralization in any form). >> >> >> (c) not
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
Hello, list >Hello centralisation. Might as well just have someone sign miner keys, and get >rid of PoW entirely... >No, it is not centralization - No, it is not centralization, as: (a) different miners could use different standards / certifications for 'green' status, there are many already; >> That does not refute the claim at all. Just because you can choose from multiple centralized authorities, which are well known and can collude, it does not mean it is decentralized by any reasonable definition of the term. (b) it does not affect stability of the network in a material way, rather creates small (12.5% of revenue max) incentive to move to green sources of energy (or buy carbon credits) and get certified - miners who would choose to run dirty energy will still be able to do so. and >> Who is to issue these credits? A centralized entity I guess ... There is no place for such in Bitcoin. If I am to concede on the point that *voluntarily* green-status miner certification is 'centralization', can you please explain *in detail* why aren't 'bitcoin.org' and GitHub repo similar examples of 'centralization'? You make a correct point that bitcoin.org and the GitHub repo are not 'official' things of Bitcoin network, however nowhere in my proposals on green miner certification I was suggesting to introduce an 'official' certificate for such a thing. May be I mis-formulated my ideas, in that case I apologize: The only thing which I suggested was to introduce an option to have some transactions encrypted in the mempool to allow Bitcoin users some control over who mines their transaction - full stop. Users could then decide how to use this functionality themselves, and such functionality could have uses way beyond 'green miners' - for example, some users might prefer to send their transactions *directly to trusted miners* to prevent certain quantum computer enabled attacks (e.g. when there is a window of opportunity to steal coins if you have fast QC when you spend even from p2phk address). Another example - if users are given some flexibility whom to send the transactions, they might actually want to steer them away from huge mining pools such as Antpool to support small independent miners, smth of this sort - which actually would boost diversity in the network. You may or may not agree that climate change is real, or may or may not agree that Bitcoin energy consumption is a problem - I respectfully submit it is not the right forum to find truth on these topics. We are discussing ideas which *might *make Bitcoin a better solution for users who care about certain things, *without *making it worse for somebody else (like you, for example - who don't like centralization in any form). >> (c) nothing is being proposed beyond what is already possible - Antpool can go green today, and solicit users to send them signed transactions directly instead of adding them to a public mempool, under the pretext that it would make the transfer 'greener'. >> And if there was an economic advantage in doing so, miners would quite likely already implement that. Yet, somehow, they are not doing that. Arguments of the sort 'if something could be done or should have been done - it would be done already' are flawed, in my opinion, as following the same logic nothing (including Bitcoin itself) should have been done ever. As a matter of fact, we are working on a green miner initiative with certain miners, having a call with Hut8 in 20 minutes myself - and I know that we are not the only ones. Green crypto initiatives are actually widespread, and the solutions will be popping up soon. >> Please stop with the carbon credit nonsense. There is likely no such thing to exist on a free market and no one is interested in these state regulations. Please read this Wikipedia Article: https://en.wikipedia.org/wiki/Carbon_offset "There are two types of markets for carbon offsets, compliance and *voluntary*" [emphasis added]. Voluntary carbon offset markets are actually growing really fast. >> Just because a big company is controlled by people who do not understand Bitcoin, it does not make the issue valid. There are no such environmental concerns once you understand how Bitcoin and free market work. Don't help to spread the FUD. I respectfully submit that people who know how to launch rockets to the sky and beam high-speed internet from the satellites to every place on earth are at least capable of understanding how Bitcoin works. There is even an english expression which reads 'it is not a rocket science' which I think fits especially nicely in this particular case :) >> Once people stop spreading FUD, the price will likely skyrocket. Start with yourself please. I guess you misinterpret my intentions, I think it doesn't matter what Bitcoin price is - my personal interest is the widest possible adoption of blockchain as a peer-to-peer way to transfer value between consenting individuals free from government control or intervention.
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
8 AM Luke Dashjr wrote: > 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. 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
