* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
@ 2021-05-17 13:14 befreeandopen
2021-05-17 13:53 ` Anton Ragin
0 siblings, 1 reply; 21+ messages in thread
From: befreeandopen @ 2021-05-17 13:14 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 7814 bytes --]
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.
> (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.
> What is being proposed is some community effort to standardize & promote this approach, because if we manage to make Bitcoin green(er) - we will remove what many commentators see as the last barrier / biggest risk to even wider Bitcoin adoption.
And you listen to those "many commentators" why exactly? Because they have many followers or they are trained to speak nicely? This is not how Bitcoin works. Bitcoin does not favor number of followers, popularity, or beauty, it is based on merit and these ideas have none. The only risk here is that too many people will fall for such false narratives and FUD (which is what the energy consumption "issue" really is) because other people, like yourself, who do not understand Bitcoin comment on it and present it as an actual issue.
> Not to mention the fact that some aspects of the Bitcoin community are pretty centralized already - 'www.bitcoin.org', GitHub repo, certain global internet cables / protocols / providers. Centralization is evil only when it enables (or makes significantly easier) a threatening attack on the network, which does not appear to be the case. It is my personal opinion only, though, I would respect it if someone disagrees.
I disagree. You are making false claims here and above and spreading FUD. For example, www.bitcoin.org is by no means an official website of Bitcoin. There is no such thing as an official website of Bitcoin. Anyone can buy bitcoin.TLD and put whatever content they want and it may or may not be relevant to Bitcoin, but it will absolutely not represent Bitcoin.
As for GitHub repo - learn about https://en.wikipedia.org/wiki/Focal_point_(game_theory) which is what this repo is. In no way it is an ultimate and fixed point of Bitcoin and it can change at any time - for example if GitHub project turned to be malicious. So again, you are wrong.
> On a separate note, I just want to draw everyone's attention to the fact that - assuming if my calculations are correct - carbon credits to offset dirty energy burned by miners would cost only approx 5% of block rewards in USD terms max.
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.
> On the other hand, BTC price has just collapsed 20% because Tesla dropped their adoption citing environmental concerns.
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.
> If every miner on the planet agrees to go green or buy carbon credits, it will actually be commercially beneficial to everybody, as the price will likely skyrocket - the problem is that such situation absent community coordination is not a Pareto-equilibrium state, which means that every single miner is incentivised to break away from the commitment to the green energy.
Once people stop spreading FUD, the price will likely skyrocket. Start with yourself please.
> Maybe there is another solution to the problem, and huge mining pools need to establish a 'green cartel' like OPEC and all start buying carbon credits in order to make Bitcoin greener and more widely adopted for their own benefit.
Maybe not.
> On Mon, May 17, 2021 at 3:58 AM Luke Dashjr <luke@dashjr.org> 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
[-- Attachment #2: Type: text/html, Size: 10742 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-17 13:14 [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy befreeandopen
@ 2021-05-17 13:53 ` Anton Ragin
2021-05-17 17:28 ` Keagan McClelland
0 siblings, 1 reply; 21+ messages in thread
From: Anton Ragin @ 2021-05-17 13:53 UTC (permalink / raw)
To: befreeandopen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5279 bytes --]
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. Environmental
concerns are real and at least some parts of the community are clearly
interested to at least discuss this matter (e.g. I am not the one who
started this thread).
Please don't be dismissive, it is an open forum and everybody is entitled
to his/her/its own opinion.
[-- Attachment #2: Type: text/html, Size: 6778 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-17 13:53 ` Anton Ragin
@ 2021-05-17 17:28 ` Keagan McClelland
2021-05-17 23:02 ` Anton Ragin
0 siblings, 1 reply; 21+ messages in thread
From: Keagan McClelland @ 2021-05-17 17:28 UTC (permalink / raw)
To: Anton Ragin, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 9001 bytes --]
In principle the idea of making your transactions not mineable except by
miners who follow some particular practice is something that can and should
be discussed. For instance, it could help give economic signals for future
soft forks such that users can declare preference in a costly, sybil
resistant way.
As I understand what you are asking, you want users to be able to issue
transactions that can only be included in blocks that are signed by miners
whose certificates can be traced back to some set of certificates that the
sender has "whitelisted". The trouble here is that in order for this to be
an open system, the user would need to be able to include an unbounded
number of optional certificates in the transaction itself, otherwise the
rest of the network would be unable to validate whether or not the
transaction, when included in the block fit the consensus rules or not.
This is not possible for rather obvious reasons:
1. transaction sizes cannot be allowed to be unbounded because this creates
denial of service attacks for the broader network
2. if the valid certificate set is not unbounded, then centralization
pressure will mount on the bound between the Nth and N+1th certifier.
Finally, all of this would require a rather large consensus change to even
implement. Given how contentious the proposal of a "choose your
miner/certifier" is, it is unlikely to gain the necessary support in the
form of code, review, miner signaling, or user uptake for a UASF.
That said, not all is lost. If you truly care about only having your
transactions mined by "green" miners or whatever other qualification you
are going after, then this can likely be implemented in upper layers as you
suggested. You can submit your transaction via an overlay network directly
to any miners that 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) 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. Environmental
> concerns are real and at least some parts of the community are clearly
> interested to at least discuss this matter (e.g. I am not the one who
> started this thread).
>
> Please don't be dismissive, it is an open forum and everybody is entitled
> to his/her/its own opinion.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 11162 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-17 17:28 ` Keagan McClelland
@ 2021-05-17 23:02 ` Anton Ragin
0 siblings, 0 replies; 21+ messages in thread
From: Anton Ragin @ 2021-05-17 23:02 UTC (permalink / raw)
To: Keagan McClelland; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 12195 bytes --]
>> This is not possible for rather obvious reasons:
>> 1. transaction sizes cannot be allowed to be unbounded because this
creates denial of service attacks for the broader network
>> 2. if the valid certificate set is not unbounded, then centralization
pressure will mount on the bound between the Nth and N+1th certifier.
>> Finally, all of this would require a rather large consensus change to
even implement. Given how contentious the proposal of a "choose your
miner/certifier" is, it is unlikely to gain the necessary support in the
form of code, review, miner signaling, or user uptake for a UASF.
My original suggestion was to hold an unbounded number of copies of
asymmetrically-encrypted transactions in the mempool, each of them could be
decrypted with the key which is owned by a particular miner. Once one of
them get mined, all other copies are discarded (this can be done by holding
hashes of transactions in the mempool unencrypted, so once the node sees
the transaction matching the hash mined - it can discard the other copies
sharing the same hash).
I agree that that opens the door to potential DoS attack - people can start
transmitting invalid transactions to perform a DoS attack on the network.
However, the following adaptation of the idea might work: the transaction
is duly signed and communicated to the mempool, but have an unbonded list
of certificates of 'preferred' miners. If for within M blocks a preferred
miner manages to mine the block - fine, if within M blocks it does not
happen, transaction can be mined by any miner. Additionally, full nodes can
demand a minimum fee which is dependant on the number of attached
certificates (e.g. if attaching N certificates makes the transaction
message 2x the size of normal message, the minimum fee is twice bigger). It
appears to me, that such M-block delay + list of preferred miners which can
be arbitrary long, but user pays higher fees if it is unreasonably long,
does not raise DoS concerns as it does not materially affect the dynamics
of things how they are right now.
>> If you truly care about only having your transactions mined by "green"
miners or whatever other qualification you are going after, then this can
likely be implemented in upper layers as you suggested. You can submit your
transaction via an overlay network directly to any miners that 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.
Overlay network is one of the solutions, however community-supported
functionality of giving some miners a priority as suggested above will
>> It is, in fact, an open forum and everyone is entitled to their view,
including being dismissive of yours.
Accepted :)
On Mon, May 17, 2021 at 6:28 PM Keagan McClelland <
keagan.mcclelland@gmail.com> wrote:
> In principle the idea of making your transactions not mineable except by
> miners who follow some particular practice is something that can and should
> be discussed. For instance, it could help give economic signals for future
> soft forks such that users can declare preference in a costly, sybil
> resistant way.
>
> As I understand what you are asking, you want users to be able to issue
> transactions that can only be included in blocks that are signed by miners
> whose certificates can be traced back to some set of certificates that the
> sender has "whitelisted". The trouble here is that in order for this to be
> an open system, the user would need to be able to include an unbounded
> number of optional certificates in the transaction itself, otherwise the
> rest of the network would be unable to validate whether or not the
> transaction, when included in the block fit the consensus rules or not.
>
> This is not possible for rather obvious reasons:
> 1. transaction sizes cannot be allowed to be unbounded because this
> creates denial of service attacks for the broader network
> 2. if the valid certificate set is not unbounded, then centralization
> pressure will mount on the bound between the Nth and N+1th certifier.
>
> Finally, all of this would require a rather large consensus change to even
> implement. Given how contentious the proposal of a "choose your
> miner/certifier" is, it is unlikely to gain the necessary support in the
> form of code, review, miner signaling, or user uptake for a UASF.
>
> That said, not all is lost. If you truly care about only having your
> transactions mined by "green" miners or whatever other qualification you
> are going after, then this can likely be implemented in upper layers as you
> suggested. You can submit your transaction via an overlay network directly
> to any miners that 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) 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. Environmental
>> concerns are real and at least some parts of the community are clearly
>> interested to at least discuss this matter (e.g. I am not the one who
>> started this thread).
>>
>> Please don't be dismissive, it is an open forum and everybody is entitled
>> to his/her/its own opinion.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 14777 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-17 19:17 ` Michael Fuhrmann
@ 2021-05-18 8:04 ` ZmnSCPxj
0 siblings, 0 replies; 21+ messages in thread
From: ZmnSCPxj @ 2021-05-18 8:04 UTC (permalink / raw)
To: Michael Fuhrmann, Bitcoin Protocol Discussion
Good morning Michael,
> Am 17.05.2021 um 04:58 schrieb Luke Dashjr:
>
> > It increases security, and is unavoidable anyway.
> > You can't.
>
> There must be a way. dRNG + universal clock + cryptographical magic?!
Proof-of-work **is** the cryptographic magic that creates a universal clock.
In physics, the Arrow of Time is defined as the direction in which entropy increases.
Suppose you were shown a video of a particle in a low-gravity environment hitting a wall and bouncing away.
This video can be played forwards or backwards, and you would not be able to determine whether it is played forwards or backwards.
In short, in many physical interactions, there is ***no*** notion of a direction in time, i.e. no past or future.
Nearly every physical interaction, at the small scale, is reversible, thus there is no (apparent) inherent direction of time.
However, suppose you were instead shown a video where a group of ceramic shards on a floor comes together to form a vase, which then rises off the floor and then floats onto a table.
Obviously, this is a video played backwards.
A group of shards on the floor is a higher-entropy state than a vase on a table, thus it is obvious what the Arrow of Time here *actually* is.
Or suppose you were shown this video: https://www.youtube.com/watch?v=zePA3uIbB5I
Obviously, this is a video played backwards (except for the introduction, of course --- pay attention how there is a scene cut from the introduction to the main part of the video).
A Rubik cube that is in a disordered state is a higher-entropy state than a Rubik cube that is in an ordered state where each side has a specific single color, thus it is obvious that the Mythbusters did not actually do any work and just ran a time-reversed video of them disordering a newly-opened Rubik cube.
All of our clocks are ultimately derived from the *measurable* increase of entropy:
* The current definition of 1 second is measured in terms of the decay of [Caesium atoms](https://en.wikipedia.org/wiki/Isotopes_of_caesium#Caesium-133).
This decay represents the reduction of energy of the atoms and thus an increase in universal entropy.
* Wind-up clockwork watches are powered by the controlled release of the energy stored in a spring, a consumption of stored energy and thus an increase in universal entropy.
* Wind-up clockwork watches are powered by the controlled release of the energy stored in a spring, a consumption of stored energy and thus an increase in universal entropy.
Now, a low-entropy state is simply one where energy is available for consumption.
And as we know, proof-of-work requires energy consumption.
Thus, the existence of a proof-of-work is a proof that time has passed.
If time did not pass, then it would not have been possible to create the proof-of-work, because it would not be possible to consume energy (i.e. increase universal entropy) and thus create an Arrow of Time.
From this proof-of-time-passing, we can then build a universal clock, one that is deeply tied to the physical world, due to the energy consumption.
It is by this method that Bitcoin is anchored to reality.
There is already a universal clock available using cryptographic magic.
It is called proof-of-work.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-17 12:39 ` Anton Ragin
@ 2021-05-18 7:46 ` ZmnSCPxj
0 siblings, 0 replies; 21+ messages in thread
From: ZmnSCPxj @ 2021-05-18 7:46 UTC (permalink / raw)
To: Anton Ragin, Bitcoin Protocol Discussion
Good morning Anton,
> >> 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...
> >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;
> (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
>
> (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'. What is being proposed is some community effort to standardize & promote this approach, because if we manage to make Bitcoin green(er) - we will remove what many commentators see as the last barrier / biggest risk to even wider Bitcoin adoption.
The point of avoiding centralization is to avoid authorities --- who can end up being bribeable or hackable single points-of-failure, and which would potentially be able to kill Bitcoin as a whole from a single attack point.
Adding an authority which filters miners works directly against this goal, regardless of however you define "centralization" --- centralization is not the root issue here, the authority *is*.
One can observe that "more renewable" energy sources will, economically, be cheaper (in the long run) anyway, and you do not have to add anything to go towards "more green" energy resources.
After all, a "non-renewable" resource is simply a resource that has a lower supply (it cannot be renewed) than a "more renewable" energy source.
There is only so much energy that is stored in coal and oil on Earth, but the sun has a much larger total mass than Earth itself, thus it is a "more renewable" energy resource than coal and oil.
Economically, this implies that "greener" energy resources will be cheaper in the long run, simply by price being a function of supply.
In short: trust the invisible hand.
We already know that lots of miners already operate in places where energy prices have bottomed due to oversupply due to technological improvements in capturing energy that used to be dissipated as waste heat.
What is needed is to spread this knowledge to others, not mess with the design of Bitcoin at a fundamental level and risk introducing unexpected side effects (bugs).
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-17 2:58 ` Luke Dashjr
2021-05-17 12:39 ` Anton Ragin
@ 2021-05-17 19:17 ` Michael Fuhrmann
2021-05-18 8:04 ` ZmnSCPxj
1 sibling, 1 reply; 21+ messages in thread
From: Michael Fuhrmann @ 2021-05-17 19:17 UTC (permalink / raw)
To: bitcoin-dev
Am 17.05.2021 um 04:58 schrieb Luke Dashjr:
> It increases security, and is unavoidable anyway.
>
> You can't.
There must be a way. dRNG + universal clock + cryptographical magic?!
I'll think about more. Because if there is a safe way of knowing when a
block was mined then this can work and no security is lost. The run für
the next coinbase starts now at 0 seconds and should end after 600
seconds. There is no real change if you start (proofable) 540 seconds
later und must finish in 60 seconds. I see this 10 times harder than 10
times softer.
It is just a blocktime of 60 seconds with 9 minutes of idle time.
But for this time thank you for all your great answers :D
:)
ps: it wasnt a pointing fingers musk move. it was the opposite. more
like "we try hard to be more efficient than everything else before even
if we still are".
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-17 2:58 ` Luke Dashjr
@ 2021-05-17 12:39 ` Anton Ragin
2021-05-18 7:46 ` ZmnSCPxj
2021-05-17 19:17 ` Michael Fuhrmann
1 sibling, 1 reply; 21+ messages in thread
From: Anton Ragin @ 2021-05-17 12:39 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7862 bytes --]
>> 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?
I am pretty sure that is how it works in data centers absent 'special
deal', as we use some DCs in our business. However, after reading some
discussion on this thread it is pretty clear that some (maybe even
majority?) of miners have some sort of special deal on electricity - some
use 'spill over' electricity which would otherwise be wasted etc. This kind
of disproves my point, but not entirely - even 'special deal' electricity
is very unlikely to be available like water in the tap - you open it when
you need it, and pay for what you use only.
Variations in power consumption in the grid are very difficult to
compensate for:
(a) there is no efficient way to store electricity;
(b) some (majority?) power-generating assets are notoriously difficult to
throttle up and down - it takes almost a day in some cases to throttle down
power production on the nuclear power plant for example.
(did you know that sometimes the spot price for electricity goes below
zero, and consumers are being paid to consume - exactly because it is
cheaper to pay somebody to consume electricity than to switch off the
reactor?)
Because of this, an enormous spike in energy consumption every 1 minute in
10 is the worst possible load profile to any power grid, and would most
likely result in either miners or power grid infrastructure itself just
burning off peak energy during the 9 minutes 'cool-down' period.
>> 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...
>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;
(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
(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'. What is being proposed is some community
effort to standardize & promote this approach, because if we manage to make
Bitcoin green(er) - we will remove what many commentators see as the last
barrier / biggest risk to even wider Bitcoin adoption.
Not to mention the fact that some aspects of the Bitcoin community are
pretty centralized already - 'www.bitcoin.org', GitHub repo, certain global
internet cables / protocols / providers. Centralization is evil only when
it enables (or makes significantly easier) a threatening attack on the
network, which does not appear to be the case. It is my personal opinion
only, though, I would respect it if someone disagrees.
On a separate note, I just want to draw everyone's attention to the fact
that - assuming if my calculations are correct - carbon credits to offset
dirty energy burned by miners would cost only *approx 5%* of block rewards
in USD terms max. On the other hand, BTC price has just collapsed 20%
because Tesla dropped their adoption citing environmental concerns. If
every miner on the planet agrees to go green or buy carbon credits, it will
actually be commercially beneficial to everybody, as the price will likely
skyrocket - the problem is that such situation absent community
coordination is not a Pareto-equilibrium state, which means that every
single miner is incentivised to break away from the commitment to the green
energy.
Maybe there is another solution to the problem, and huge mining pools need
to establish a 'green cartel' like OPEC and all start buying carbon credits
in order to make Bitcoin greener and more widely adopted for their own
benefit.
On Mon, May 17, 2021 at 3:58 AM Luke Dashjr <luke@dashjr.org> 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...
>
>
[-- Attachment #2: Type: text/html, Size: 9403 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-16 22:05 ` Karl
@ 2021-05-17 9:34 ` Zac Greenwood
0 siblings, 0 replies; 21+ messages in thread
From: Zac Greenwood @ 2021-05-17 9:34 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Karl
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
>
>
> Are there people who can freely produce new mining equipment to an
> arbitrary degree?
>
Close. Bitmain for example produces their own ASICs and rigs which they
mine with. Antpool is controlled by Bitmain and has a significant amount of
the hash power. The marginal cost of an ASIC chip or mining rig is low
compared to R&D and setting up of the production lines etc. For Bitmain
it’s relatively cheap to produce an additional mining rig.
Unfortunately I failed to make sense of your other remarks which looked
rather confused so I take the liberty to disregard them.
Zac
_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1589 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-14 21:41 Michael Fuhrmann
` (4 preceding siblings ...)
2021-05-17 2:58 ` Luke Dashjr
@ 2021-05-17 5:17 ` yanmaani
5 siblings, 0 replies; 21+ messages in thread
From: yanmaani @ 2021-05-17 5:17 UTC (permalink / raw)
To: Michael Fuhrmann, Bitcoin Protocol Discussion
This is silly, but I'll add my take:
This would create the incentive to have chips that are idle 50% of the
time and work harder 50% of the time. This means miners would buy twice
the chips to use the same amount of power, for example.
This in turn means a greater portion of your operational costs are spent
on chips, and a smaller portion on electricity, reducing the incentive
to use cheaper power and turn off when it's expensive, because you need
to recoup your investment. That seems like a bad thing.
Here's my proposal: if you want a PoW algorithm that's better for the
environment, make one where the chips are easier to manufacture, so
power costs become a greater portion of miner expenditures. Maybe
SIMON/SPECK would do it. It could also incentivize someone to find that
NSA backdoor...
On 2021-05-14 21:41, Michael Fuhrmann via bitcoin-dev 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-14 21:41 Michael Fuhrmann
` (3 preceding siblings ...)
2021-05-16 18:10 ` Karl
@ 2021-05-17 2:58 ` Luke Dashjr
2021-05-17 12:39 ` Anton Ragin
2021-05-17 19:17 ` Michael Fuhrmann
2021-05-17 5:17 ` yanmaani
5 siblings, 2 replies; 21+ messages in thread
From: Luke Dashjr @ 2021-05-17 2:58 UTC (permalink / raw)
To: Michael Fuhrmann, Bitcoin Protocol Discussion, Karl, Anton Ragin
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...
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-16 22:06 ` Eric Voskuil
@ 2021-05-16 23:29 ` Karl
0 siblings, 0 replies; 21+ messages in thread
From: Karl @ 2021-05-16 23:29 UTC (permalink / raw)
To: Eric Voskuil, Bitcoin Protocol Discussion
On 5/16/21, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy
The chain security actually reduces by 10% in this proposal. So the
efficiency paradox is not violated, it is just the real cost of
confirming a transaction is reduced, because there is actually less
security. This eventually reduces the price of bitcoin and reduces the
amount of electricity the block reward can eventually buy.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-16 20:31 ` Anton Ragin
@ 2021-05-16 22:06 ` Eric Voskuil
2021-05-16 23:29 ` Karl
0 siblings, 1 reply; 21+ messages in thread
From: Eric Voskuil @ 2021-05-16 22:06 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 153 bytes --]
https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy
[-- Attachment #2: Type: text/html, Size: 583 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-16 21:15 ` Zac Greenwood
@ 2021-05-16 22:05 ` Karl
2021-05-17 9:34 ` Zac Greenwood
0 siblings, 1 reply; 21+ messages in thread
From: Karl @ 2021-05-16 22:05 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
> 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 <zachgrw@gmail.com> 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-16 18:10 ` Karl
2021-05-16 20:31 ` Anton Ragin
@ 2021-05-16 21:15 ` Zac Greenwood
2021-05-16 22:05 ` Karl
1 sibling, 1 reply; 21+ messages in thread
From: Zac Greenwood @ 2021-05-16 21:15 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Karl
[-- Attachment #1: Type: text/plain, Size: 4547 bytes --]
> 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
>
[-- Attachment #2: Type: text/html, Size: 9177 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-16 18:10 ` Karl
@ 2021-05-16 20:31 ` Anton Ragin
2021-05-16 22:06 ` Eric Voskuil
2021-05-16 21:15 ` Zac Greenwood
1 sibling, 1 reply; 21+ messages in thread
From: Anton Ragin @ 2021-05-16 20:31 UTC (permalink / raw)
To: Karl, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5422 bytes --]
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 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
>
[-- Attachment #2: Type: text/html, Size: 6382 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-14 21:41 Michael Fuhrmann
` (2 preceding siblings ...)
2021-05-16 15:30 ` Zac Greenwood
@ 2021-05-16 18:10 ` Karl
2021-05-16 20:31 ` Anton Ragin
2021-05-16 21:15 ` Zac Greenwood
2021-05-17 2:58 ` Luke Dashjr
2021-05-17 5:17 ` yanmaani
5 siblings, 2 replies; 21+ messages in thread
From: Karl @ 2021-05-16 18:10 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-14 21:41 Michael Fuhrmann
2021-05-15 22:14 ` René Pickhardt
2021-05-15 22:19 ` Pavol Rusnak
@ 2021-05-16 15:30 ` Zac Greenwood
2021-05-16 18:10 ` Karl
` (2 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: Zac Greenwood @ 2021-05-16 15:30 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Michael Fuhrmann
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 2769 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-14 21:41 Michael Fuhrmann
2021-05-15 22:14 ` René Pickhardt
@ 2021-05-15 22:19 ` Pavol Rusnak
2021-05-16 15:30 ` Zac Greenwood
` (3 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: Pavol Rusnak @ 2021-05-15 22:19 UTC (permalink / raw)
To: Michael Fuhrmann, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
Please read the Bitcoin whitepaper. It's a very interesting read.
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
On Sat, May 15, 2021, 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
>
[-- Attachment #2: Type: text/html, Size: 2051 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
2021-05-14 21:41 Michael Fuhrmann
@ 2021-05-15 22:14 ` René Pickhardt
2021-05-15 22:19 ` Pavol Rusnak
` (4 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: René Pickhardt @ 2021-05-15 22:14 UTC (permalink / raw)
To: Michael Fuhrmann, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
Hey Michael,
First I think the idea of "do nothing in the first 9 minutes" will
unfortunately not be useful as the computed work is mainly there to prevent
miners from altering the history of previous blocks. Thus following your
suggesting would probably drastically decease the security of the network
as less work protects previously mined blocks allowing for lower cost to
compute a reorg.
Let us assume the aforementioned point could somehow be resolved there
would be another practical issue. It is hard / impossible to sync clocks in
a distributed network which I think would be necessary for a system that
you propose. (actually Bitcoin is one way of introducing a temporal
ordering of events in a distributed network)
Finally even if that was also resolved: 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.
So while I appreciate the idea I have the feeling it would be impractical
but maybe I missed something.
Best Rene
Michael Fuhrmann via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
schrieb am Sa., 15. Mai 2021, 23:57:
> 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
>
[-- Attachment #2: Type: text/html, Size: 3217 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
@ 2021-05-14 21:41 Michael Fuhrmann
2021-05-15 22:14 ` René Pickhardt
` (5 more replies)
0 siblings, 6 replies; 21+ messages in thread
From: Michael Fuhrmann @ 2021-05-14 21:41 UTC (permalink / raw)
To: bitcoin-dev
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.
:)
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2021-05-18 8:05 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-17 13:14 [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy befreeandopen
2021-05-17 13:53 ` Anton Ragin
2021-05-17 17:28 ` Keagan McClelland
2021-05-17 23:02 ` Anton Ragin
-- strict thread matches above, loose matches on Subject: below --
2021-05-14 21:41 Michael Fuhrmann
2021-05-15 22:14 ` René Pickhardt
2021-05-15 22:19 ` Pavol Rusnak
2021-05-16 15:30 ` Zac Greenwood
2021-05-16 18:10 ` Karl
2021-05-16 20:31 ` Anton Ragin
2021-05-16 22:06 ` Eric Voskuil
2021-05-16 23:29 ` Karl
2021-05-16 21:15 ` Zac Greenwood
2021-05-16 22:05 ` Karl
2021-05-17 9:34 ` Zac Greenwood
2021-05-17 2:58 ` Luke Dashjr
2021-05-17 12:39 ` Anton Ragin
2021-05-18 7:46 ` ZmnSCPxj
2021-05-17 19:17 ` Michael Fuhrmann
2021-05-18 8:04 ` ZmnSCPxj
2021-05-17 5:17 ` yanmaani
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox