Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
>One needs a cost/benefit analysis, not just an account of the cost. For example, if PoW could do calculations that are otherwise useful (maybe solve a queue of standardized math-jobs, such as climate simulations) there would be more benefit, or, let's say the data storage in proof-of-space is useful. Any discussion on whether Proof of Work is suitable for the task needs to recognize that the "waste" is what creates the security. If you manage to make the proof of work useful for tasks external to the protocol, you reintroduce the "nothing at stake" problem in a roundabout way. Useful computation is something people will pay for. If they pay for it, miners can be compensated in such a way that choosing to mine one of the Not-The-Heaviest-Chain's becomes costless. This erodes the security of the network substantially. It is not a matter of coming up with the "right" kind of useful computation that is not subject to these problems. These problems are a natural consequence of it being useful outside the protocol *at all*. Keagan On Tue, May 18, 2021 at 8:24 AM Claus Ehrenberg via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Ultimately all currency security derives from energy consumption. > > Everything eventually resolves down to proof-of-work. > This is ideology. Yes, without energy and work, not many things happen. > But the amounts of energy and work to achieve a goal vary widely. Detailed > analysis comparing one alternative with the other in depth is required. > And I would not look for order-of-magnitude improvements, 25% better is > also a big deal, if discovered. > > > * Proof-of-space simply moves the work to the construction of more > storage devices. > One needs a cost/benefit analysis, not just an account of the cost. For > example, if PoW could do calculations that are otherwise useful (maybe > solve a queue of standardized math-jobs, such as climate simulations) there > would be more benefit, or, let's say the data storage in proof-of-space is > useful. > > > * Proof-of-stake simply moves the work to stake-grinding attacks. > Simply not true, there are PoS implementations that are immune to > stake-grinding attacks, and even where not, the possible amount of > computations is limited compared to PoW > > > * The optical proof-of-work simply moves the work to the construction of > more miners. > The idea was to shift from energy to cap-ex. We can get a > financial penalty for misbehavior from three sources: > - cost of energy/labor (PoW) > - cost of capital (PoS) > - cost of cap-ex > There might be a better mix than PoW only. I have written code for mixed > PoW/PoS systems and it works. Adding more cap-ex to the mix can make sense, > but the environmental impact needs to be analyzed, it could also make it > worse than just the use of electricity. At least electricity as such does > not leave waste behind. Mining in orbit with solar power would be totally > acceptable. > > > At least, proof-of-work is honest about its consumption of resources. > Agreed, but we can't be satisfied with that. If we try hard enough we can > do better. > > Cheers > Claus > > On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> > A few things jump out at me as I read this proposal >> > >> > First, deriving the hardness from capex as opposed to opex switches the >> privilege from those who have cheap electricity to those who have access to >> chip manufacturers/foundries. While this is similarly the case for Bitcoin >> ASICS today, the longevity of the PoW algorithm has led to a better >> distribution of knowledge and capital goods required to create ASICS. The >> creation of a new PoW of any kind, hurts this dimension of decentralization >> as we would have to start over from scratch on the best way to build, >> distribute, and operate these new pieces of hardware at scale. While I have >> not combed over the PoW proposed here in fine detail, the more complicated >> the algorithm is, the more it privileges those with specific knowledge >> about it and the manufacturing process. >> > >> > The competitive nature of Bitcoin mining is such that miners will be >> willing to spend up to their expected mining reward in their operating >> costs to continue to mine. Let's suppose that this new PoW was adopted, >> miners will continue to buy these chips in ever increasing quantities, >> turning the aforementioned CAPEX into a de facto OPEX. This has a few >> consequences. First it just pushes the energy consumption upstream to the >> chip manufacturing process, rather than eliminating it. And it may trade >> some marginal amount of the energy consumption for the set of resources it >> takes to educate and create chip manufacturers. The only way to avoid that >> cost being funneled back into more energy consumption is to make the >> barrier to understanding of the manufacturing process sufficiently >> difficult so as to limit the proliferation
Re: [bitcoin-dev] Opinion on proof of stake in future
1. i never suggested vdf's to replace pow. 2. my suggestion was specifically *in the context of* a working proof-of-burn protocol - vdfs used only for timing (not block height) - blind-burned coins of a specific age used to replace proof of work - the required "work" per block would simply be a competition to acquire rewards, and so miners would have to burn coins, well in advance, and hope that their burned coins got rewarded in some far future - the point of burned coins is to mimic, in every meaningful way, the value gained from proof of work... without some of the security drawbacks - the miner risks losing all of his burned coins (like all miners risk losing their work in each block) - new burns can't be used - old burns age out (like ASICs do) - other requirements on burns might be needed to properly mirror the properties of PoW and the incentives Bitcoin uses to mine honestly. 3. i do believe it is *possible* that a "burned coin + vdf system" might be more secure in the long run, and that if the entire space agreed that such an endeavor was worthwhile, a test net could be spun up, and a hard-fork could be initiated. 4. i would never suggest such a thing unless i believed it was possible that consensus was possible. so no, this is not an "alt coin" On Tue, May 18, 2021 at 10:02 AM Zac Greenwood wrote: > > Hi ZmnSCPxj, > > Please note that I am not suggesting VDFs as a means to save energy, but > solely as a means to make the time between blocks more constant. > > Zac > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj wrote: >> >> Good morning Zac, >> >> > VDFs might enable more constant block times, for instance by having a >> > two-step PoW: >> > >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to >> > difficulty adjustments similar to the as-is). As per the property of VDFs, >> > miners are able show proof of work. >> > >> > 2. Use current PoW mechanism with lower difficulty so finding a block >> > takes 1 minute on average, again subject to as-is difficulty adjustments. >> > >> > As a result, variation in block times will be greatly reduced. >> >> As I understand it, another weakness of VDFs is that they are not inherently >> progress-free (their sequential nature prevents that; they are inherently >> progress-requiring). >> >> Thus, a miner which focuses on improving the amount of energy that it can >> pump into the VDF circuitry (by overclocking and freezing the circuitry), >> could potentially get into a winner-takes-all situation, possibly leading to >> even *worse* competition and even *more* energy consumption. >> After all, if you can start mining 0.1s faster than the competition, that is >> a 0.1s advantage where *only you* can mine *in the entire world*. >> >> Regards, >> ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
> Ultimately all currency security derives from energy consumption. > Everything eventually resolves down to proof-of-work. This is ideology. Yes, without energy and work, not many things happen. But the amounts of energy and work to achieve a goal vary widely. Detailed analysis comparing one alternative with the other in depth is required. And I would not look for order-of-magnitude improvements, 25% better is also a big deal, if discovered. > * Proof-of-space simply moves the work to the construction of more storage devices. One needs a cost/benefit analysis, not just an account of the cost. For example, if PoW could do calculations that are otherwise useful (maybe solve a queue of standardized math-jobs, such as climate simulations) there would be more benefit, or, let's say the data storage in proof-of-space is useful. > * Proof-of-stake simply moves the work to stake-grinding attacks. Simply not true, there are PoS implementations that are immune to stake-grinding attacks, and even where not, the possible amount of computations is limited compared to PoW > * The optical proof-of-work simply moves the work to the construction of more miners. The idea was to shift from energy to cap-ex. We can get a financial penalty for misbehavior from three sources: - cost of energy/labor (PoW) - cost of capital (PoS) - cost of cap-ex There might be a better mix than PoW only. I have written code for mixed PoW/PoS systems and it works. Adding more cap-ex to the mix can make sense, but the environmental impact needs to be analyzed, it could also make it worse than just the use of electricity. At least electricity as such does not leave waste behind. Mining in orbit with solar power would be totally acceptable. > At least, proof-of-work is honest about its consumption of resources. Agreed, but we can't be satisfied with that. If we try hard enough we can do better. Cheers Claus On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > A few things jump out at me as I read this proposal > > > > First, deriving the hardness from capex as opposed to opex switches the > privilege from those who have cheap electricity to those who have access to > chip manufacturers/foundries. While this is similarly the case for Bitcoin > ASICS today, the longevity of the PoW algorithm has led to a better > distribution of knowledge and capital goods required to create ASICS. The > creation of a new PoW of any kind, hurts this dimension of decentralization > as we would have to start over from scratch on the best way to build, > distribute, and operate these new pieces of hardware at scale. While I have > not combed over the PoW proposed here in fine detail, the more complicated > the algorithm is, the more it privileges those with specific knowledge > about it and the manufacturing process. > > > > The competitive nature of Bitcoin mining is such that miners will be > willing to spend up to their expected mining reward in their operating > costs to continue to mine. Let's suppose that this new PoW was adopted, > miners will continue to buy these chips in ever increasing quantities, > turning the aforementioned CAPEX into a de facto OPEX. This has a few > consequences. First it just pushes the energy consumption upstream to the > chip manufacturing process, rather than eliminating it. And it may trade > some marginal amount of the energy consumption for the set of resources it > takes to educate and create chip manufacturers. The only way to avoid that > cost being funneled back into more energy consumption is to make the > barrier to understanding of the manufacturing process sufficiently > difficult so as to limit the proliferation of these chips. Again, this > privileges the chip manufacturers as well as those with close access to the > chip manufacturers. > > > > As far as I can tell, the only thing this proposal actually does is > create a very lucrative business model for those who sell this variety of > chips. Any other effects of it are transient, and in all likelihood the > transient effects create serious centralization pressure. > > > > At the end of the day, the energy consumption is foundational to the > system. The only way to do away with authorities, is to require > competition. This competition will employ ever more resources until it is > unprofitable to do so. At the base of all resources of society is energy. > You get high energy expenditure, or a privileged class of bitcoin > administrators: pick one. I suspect you'll find the vast majority of > Bitcoin users to be in the camp of the energy expenditure, since if we pick > the latter, we might as well just pack it in and give up on the Bitcoin > experiment. > > > Keagan is quite correct. > Ultimately all currency security derives from energy consumption. > Everything eventually resolves down to proof-of-work. > > * Proof-of-space simply moves the work to the construction of more storage > devices. > *
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Nothing in a dynamic system like PoW mining can be 100% anticipated, for example there might be advanced in manufacturing of chips which are patented and so on. It sounds like your take is that this means no improvements can ever be made by any mechanism, however conservative. We do go into a fair amount of detail about Minimum Effective Hardness in our paper https://assets.pubpub.org/xi9h9rps/0158167859.pdf , which is actually a special case of hardness that we invented for the context of adding an operation to a PoW, and how it applies to random matrix mults. Sent from my iPhone > On May 18, 2021, at 7:58 AM, ZmnSCPxj wrote: > > Good morning Michael, > >> That’s interesting. I didn’t know the history of ASICBOOST. > > History is immaterial, what is important is the technical description of > ASICBOOST. > Basically, by fixing the partial computation of the second block of SHA256, > we could selectively vary bits in the first block of SHA256, while reusing > the computation of the second block. > This allows a grinder to grind more candidate blocks without recomputing the > second block output, reducing the needed power consumption for the same > number of hashes attempted. > > Here is an important writeup: > https://www.mit.edu/~jlrubin/public/pdfs/Asicboost.pdf > It should really be required reading for anyone who dreams of changing PoW > algorithms to read and understand this document. > > There may be similar layer-crossings in any combined construction --- or even > just a simple hash function --- when it is applied to a specific Bitcoin > block format. > >> >> Our proposal (see Implementation) is to phase in oPoW slowly starting at a >> very low % of the rewards (say 1%). That should give a long testing period >> where there is real financial incentive for things like ASICBOOST >> >> Does that resolve or partially resolve the issue in your eyes? > > It does mitigate this somewhat. > > However, such a mechanism is an additional complication and there may be > further layer-crossing violations possible --- there may be an optimization > to have a circuit that occasionally uses SHA256d and occasionally uses oPoW, > that is not possible with a pure SHA256d or pure oPoW circuit. > So this mitigation is not as strong as it might appear at first glance; > additional layers means additional possibility of layer-crossing violations > like ASICBOOST. > > > > > Regards, > ZmnSCPxj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
That’s interesting. I didn’t know the history of ASICBOOST. Our proposal (see Implementation) is to phase in oPoW slowly starting at a very low % of the rewards (say 1%). That should give a long testing period where there is real financial incentive for things like ASICBOOST Does that resolve or partially resolve the issue in your eyes? Sent from my iPhone > On May 18, 2021, at 7:36 AM, ZmnSCPxj wrote: > > Good morning Michael, > >> That’s a fair point about patents. However, note that we were careful about >> this. oPoW only uses SHA3 (can be replaced with SHA256 in principle as well) >> and low precision linear matrix multiplication. A whole industry is trying >> to accelerate 8-bit linear matrix mults for AI so there is already a massive >> incentive (and has been for decades). >> >> See companies like Mythic, Groq, Tesla (FSD computer), google TPU and so on >> for electronic versions of this. Several of the optical ones are mentioned >> in the BIP (e.g. Lightmatter) > > > Please note that ASICBOOST for SHA256d is based on a layer-crossing > violation: SHA256 processes in blocks, and the Bitcoin block header is > slightly larger than one SHA256 block. > > Adding more to a direct SHA3 (which, as a "sponge" construction, avoids > blocks, but other layer-crossing violations may still exist) still risks > layer violations that might introduce hidden optimizations. > > Or more succinctly; > > * Just because the components have (with high probability) no more possible > optimizations, does not mean that the construction *as a whole* has no hidden > optimizations. > > Thus, even if linear matrix multiplication and SHA3 have no hidden > optimizations, their combination, together with the Bitcoin block header > format, *may* have hidden optimizations. > > And there are no *current* incentives to find such optimizations until > Bitcoin moves to this, at which point we are already committed and it would > be highly infeasible to revert to SHA256d --- i.e. too late. > > This is why changes to PoW are highly discouraged. > > > Remember, ASICBOOST was *not* an optimization of SHA256 *or* SHA256d, it was > an optimizations of SHA256d-on-a-Bitcoin-block-header. > ASICBOOST cannot speed up general SHA256 or even general SHA256d, it only > applies specifically to SHA256d-on-a-Bitcoin-block-header. > > Regards, > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Opinion on proof of stake in future
Hi ZmnSCPxj, Please note that I am not suggesting VDFs as a means to save energy, but solely as a means to make the time between blocks more constant. Zac On Tue, 18 May 2021 at 12:42, ZmnSCPxj wrote: > Good morning Zac, > > > VDFs might enable more constant block times, for instance by having a > two-step PoW: > > > > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to > difficulty adjustments similar to the as-is). As per the property of VDFs, > miners are able show proof of work. > > > > 2. Use current PoW mechanism with lower difficulty so finding a block > takes 1 minute on average, again subject to as-is difficulty adjustments. > > > > As a result, variation in block times will be greatly reduced. > > As I understand it, another weakness of VDFs is that they are not > inherently progress-free (their sequential nature prevents that; they are > inherently progress-requiring). > > Thus, a miner which focuses on improving the amount of energy that it can > pump into the VDF circuitry (by overclocking and freezing the circuitry), > could potentially get into a winner-takes-all situation, possibly leading > to even *worse* competition and even *more* energy consumption. > After all, if you can start mining 0.1s faster than the competition, that > is a 0.1s advantage where *only you* can mine *in the entire world*. > > Regards, > ZmnSCPxj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
That’s a fair point about patents. However, note that we were careful about this. oPoW only uses SHA3 (can be replaced with SHA256 in principle as well) and low precision linear matrix multiplication. A whole industry is trying to accelerate 8-bit linear matrix mults for AI so there is already a massive incentive (and has been for decades). See companies like Mythic, Groq, Tesla (FSD computer), google TPU and so on for electronic versions of this. Several of the optical ones are mentioned in the BIP (e.g. Lightmatter) Sent from my iPhone > On May 18, 2021, at 6:59 AM, ZmnSCPxj wrote: > > Good morning devrandom, > >> On Mon, May 17, 2021 at 11:47 PM ZmnSCPxj: >> >>> When considering any new proof-of-foo, it is best to consider all effects >>> until you reach the base physics of the arrow of time, at which point you >>> will realize it is ultimately just another proof-of-work anyway. >> >> Let's not simplify away economic considerations, such as externalities. The >> whole debate about the current PoW is about negative externalities related >> to energy production. >> >> Depending on the details, CAPEX (R, real-estate, construction, production) >> may have less externalities, and if that's the case, we should be interested >> in adopting a PoW that is intensive in these types of CAPEX. > > Then let us also not forget another important externality: possible > optimizations of a new PoW algorithm that risk being put into some kind of > exclusive patent. > > I think with high probability that SHA256d as used by Bitcoin will no longer > have an optimization as large in effect as ASICBOOST in the future, simply > because there is a huge incentive to find such optimizations and Bitcoin has > been using SHA256d for 12 years already, and we have already found ASICBOOST > (and while patented, as I understand it the patent owner has promised not to > enforce the patent --- my understanding may be wrong). > > Any alternative PoW algorithm risks an ASICBOOST-like optimization that is > currently unknown, but which will be discovered (and possibly patented by an > owner that *will* enforce the patent, thus putting the entire ecosystem at > direct conflict with legacy government structures) once there is a good > incentive (i.e. use in Bitcoin) for it. > > Regards, > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Devrandom is correct to point out that there is nuance to these things and it’s better to look at the details rather than proclaiming that PoW is PoW. (I do agree though w the original point that other ideas often turn out to reduce to PoW despite their convoluted architecture) A note on the key difference between hardware and energy as it relates to centralization: Hardware is easily transferable. If you have low electricity costs, Bitcoin ASICS need to be physically located in proximity to use it. You can’t sell your low power costs on an open liquid market (you can sell your hash rate but that still requires all the miners next to the power plant). Hardware can be sold online freely to anyone anywhere in the world. If a small number of foundries are producing low energy opow hardware (just as there are a small number producing SHA256 ASICS- in fact it would be the same set foundries, somewhat expanded because optical chips use larger, older nodes... for example Global Foundries has a great photonics process at 90nm), they can (and will) still sell the hardware to people all over the world. There is a huge latent demand for BTC mining. Many people currently buying alt coins or even BTC would prefer to invest in mining if they could turn a profit despite their high energy cost. Another clear benefit would be the difficulty of detecting and controlling low energy mining relative to the ASIC-warehouse-next-to-waterfall model used today. You can’t move a waterfall if the local government decides to regulate you. Just some thoughts. Sent from my iPhone > On May 18, 2021, at 5:18 AM, Devrandom wrote: > > > On Mon, May 17, 2021 at 11:47 PM ZmnSCPxj: >> >> When considering any new proof-of-foo, it is best to consider all effects >> until you reach the base physics of the arrow of time, at which point you >> will realize it is ultimately just another proof-of-work anyway. > > Let's not simplify away economic considerations, such as externalities. The > whole debate about the current PoW is about negative externalities related to > energy production. > > Depending on the details, CAPEX (R, real-estate, construction, production) > may have less externalities, and if that's the case, we should be interested > in adopting a PoW that is intensive in these types of CAPEX. > > On Mon, May 17, 2021 at 2:20 PM Keagan McClelland wrote: > >> First it just pushes the energy consumption upstream to the chip >> manufacturing process, rather than eliminating it. And it may trade some >> marginal amount of the energy consumption for the set of resources it takes >> to educate and create chip manufacturers. The only way to avoid that cost >> being funneled back into more energy consumption [...] > > I challenge you to substantiate these assertions. Real-estate and human > cognitive work are not energy intensive and are a major factor in the > expected costs of some alternative PoWs. The expected mining effort is such > that the cost will reach the expected reward, no more, so there is every > reason to believe that energy consumption will be small compared to the > current PoW. > > Therefore, the total associated negative externalities for the alternative > PoWs may well be much lower than the externalities of energy production. > This needs detailed analysis, not a knee-jerk reaction. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fee estimates and RBF
Good morning Prayank, > But it will involve lot of exception handling. Yes, that is precisely the problem here. If you select a fixed feerate and then just broadcast-and-forget, you have no real exceptions you have to handle --- but that means not using RBF at all. Testing the handling of reorgs in particular is important, as a reorg might use an older version of an RBFed transaction rather than a newer version. This also implies that further follow-up transactions might need to be recreated in such a case. As this is financial code, we need a lot of testing, and code that has a lot of branches due to having to handle a lot of possible exceptions and so forth is a headache to completely cover in testing. C-lightning supposedly supports RBF, in the sense that every transaction it makes always signals RBF, but I am almost certain there are edge cases where it might mishandle a replaced transaction and lose track of onchain funds, and it is difficult to support both "we can spend unconfirmed change outputs" (a very common feature of nearly every onchain wallet) with "we can change the feerate of unconfirmed transactions" (which changes the txid and therefore the UTXO id of the change output spent by use of the previous feature). Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Good morning Michael, > Good morning Michael, > > > Nothing in a dynamic system like PoW mining can be 100% anticipated, for > > example there might be advanced in manufacturing of chips which are > > patented and so on. > > It sounds like your take is that this means no improvements can ever be > > made by any mechanism, however conservative. > > Not at all. > > Small-enough improvements over long-enough periods of time are expected and > anticipated --- that is why there exists a difficulty adjustment mechanism. > What is risky if a large-enough improvement over a short-enough time that > overwhelms the difficulty adjustment mechanism. > ASICBOOST was a massive enough improvement that it could be argued to > potentially overwhelm this mechanism if it was not openly allowed for all > miners. Or to put it in another perspective: * Small improvements to PoW mining are tolerated by Bitcoin. * Such improvements are expected to be common. * Large improvements to PoW mining are potential extinction events for Bitcoin, due to massive centralization risk. * Such improvements are expected to be *rare* but *not* nonexistent. * The number of possible circuit configurations is bounded by physical limits (matter is quantized, excssively-large chips are infeasible, etc.), thus the number of expected optimizations of a particular overall algorithm are bounded. Suppose two manufacturers find two different small improvements to PoW mining. In all likelihood, "the sum is better than its parts" and if the two have a cross-licensing deal, they can outcompete their *other* competition. Further, even if some small competitor violates the patent, the improvement may be small enough that the patent owner may decide the competitor is too small to bother with all the legal fees involved to enforce the patent. Thus, small improvements to PoW mining are expected to eventually spread widely, and that is what the difficulty adjustment mechanism exists to modulate. But suppose a third manufacturer develops an ASICBOOST-level optimization of whatever the PoW mining algorithm is. That manufacturer has no incentive to cross-license, since it can dominate the competition without cross-licensing a bunch of smaller optimizations (that may not even add up to compete against the ASICBOOST-level optimization). And any small competitor that violates patent will be enforced against, due to the major improvement that the large optimization has and the massive monopolistic advantage the ASICBOOST-level optimization patent holder would have. SHA256d-on-Bitcoin-block-header has already uncovered ASICBOOST, and thus the number of possible other large optimizations is that much smaller --- the number of possible optimizations is bounded by physical constraints. Thus, the risk of a black-swan event where a new optimization of SHA256d-on-Bitcoin-block-header is large enough to massively centralize mining is reduced, compared to every other alternative PoW algorithm, which is an important reason to avoid changing PoW as much as possible, without some really serious study (which you might be engaged in --- I am not enough of a mathist to follow your papers). We are more likely to want to change SHA256 for SHA3 on the txid and Merkle trees than on the PoW. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Good morning Michael, > Nothing in a dynamic system like PoW mining can be 100% anticipated, for > example there might be advanced in manufacturing of chips which are patented > and so on. > > It sounds like your take is that this means no improvements can ever be made > by any mechanism, however conservative. Not at all. Small-enough improvements over long-enough periods of time are expected and anticipated --- that is why there exists a difficulty adjustment mechanism. What is risky if a large-enough improvement over a short-enough time that overwhelms the difficulty adjustment mechanism. ASICBOOST was a massive enough improvement that it could be argued to potentially overwhelm this mechanism if it was not openly allowed for all miners. > > We do go into a fair amount of detail about Minimum Effective Hardness in our > paper https://assets.pubpub.org/xi9h9rps/0158167859.pdf , which is > actually a special case of hardness that we invented for the context of > adding an operation to a PoW, and how it applies to random matrix mults. This certainly helps as well. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Prediction Markets and Bitcoin
Good morning Prayank,
>
> > Of course the people ultimately funding the development must impose what
> >direction that development goes to, after all, it is their money that is
> >being modified. Thus development must follow the market.
>
> Disagree.
>
> 1.A position in a futures market about possible outcomes of an event is not
> equivalent to funding Bitcoin development.
>
> 2.People or organizations funding Bitcoin developers or projects can always
> have some opinion, influence and disagreements. They can never impose or
> force something at least in Bitcoin protocol.
Sorry for the late reply.
I expect that many Bitcoin developers have a nontrivial amount of their life
savings in Bitcoin.
Any change in Bitcoin price represents a significant change in the value of
these life savings.
A position in a futures market represents a prediction by the one taking the
position that they expect the price of Bitcoin to change in a particular
direction, possibly based on some condition, including the direction where
development goes.
This signal then represents an implicit threat ("if Bitcoin goes against this
position, I will liquidate my Bitcoin and drop the Bitcoin price") which can be
sufficient to "fund" or "de-fund" developers who have a significant stake in
Bitcoin.
> I don't think futures market in this case will be able to aggregate and
> reflect all available information so everything mentioned above has its own
> importance which should be considered. Maybe I missed few things.
*Some* information > *No* information
>
> 3.Incorrect usage of futures markets in Bitcoin and other issues:
Well, yes, this is the hard part, sigh.
Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Good morning Michael, > That’s a fair point about patents. However, note that we were careful about > this. oPoW only uses SHA3 (can be replaced with SHA256 in principle as well) > and low precision linear matrix multiplication. A whole industry is trying to > accelerate 8-bit linear matrix mults for AI so there is already a massive > incentive (and has been for decades). > > See companies like Mythic, Groq, Tesla (FSD computer), google TPU and so on > for electronic versions of this. Several of the optical ones are mentioned in > the BIP (e.g. Lightmatter) Please note that ASICBOOST for SHA256d is based on a layer-crossing violation: SHA256 processes in blocks, and the Bitcoin block header is slightly larger than one SHA256 block. Adding more to a direct SHA3 (which, as a "sponge" construction, avoids blocks, but other layer-crossing violations may still exist) still risks layer violations that might introduce hidden optimizations. Or more succinctly; * Just because the components have (with high probability) no more possible optimizations, does not mean that the construction *as a whole* has no hidden optimizations. Thus, even if linear matrix multiplication and SHA3 have no hidden optimizations, their combination, together with the Bitcoin block header format, *may* have hidden optimizations. And there are no *current* incentives to find such optimizations until Bitcoin moves to this, at which point we are already committed and it would be highly infeasible to revert to SHA256d --- i.e. too late. This is why changes to PoW are highly discouraged. Remember, ASICBOOST was *not* an optimization of SHA256 *or* SHA256d, it was an optimizations of SHA256d-on-a-Bitcoin-block-header. ASICBOOST cannot speed up general SHA256 or even general SHA256d, it only applies specifically to SHA256d-on-a-Bitcoin-block-header. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Good morning devrandom, > On Mon, May 17, 2021 at 11:47 PM ZmnSCPxj: > > > When considering any new proof-of-foo, it is best to consider all effects > > until you reach the base physics of the arrow of time, at which point you > > will realize it is ultimately just another proof-of-work anyway. > > Let's not simplify away economic considerations, such as externalities. The > whole debate about the current PoW is about negative externalities related to > energy production. > > Depending on the details, CAPEX (R, real-estate, construction, production) > may have less externalities, and if that's the case, we should be interested > in adopting a PoW that is intensive in these types of CAPEX. Then let us also not forget another important externality: possible optimizations of a new PoW algorithm that risk being put into some kind of exclusive patent. I think with high probability that SHA256d as used by Bitcoin will no longer have an optimization as large in effect as ASICBOOST in the future, simply because there is a huge incentive to find such optimizations and Bitcoin has been using SHA256d for 12 years already, and we have already found ASICBOOST (and while patented, as I understand it the patent owner has promised not to enforce the patent --- my understanding may be wrong). Any alternative PoW algorithm risks an ASICBOOST-like optimization that is currently unknown, but which will be discovered (and possibly patented by an owner that *will* enforce the patent, thus putting the entire ecosystem at direct conflict with legacy government structures) once there is a good incentive (i.e. use in Bitcoin) for it. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Opinion on proof of stake in future
Good morning Zac, > VDFs might enable more constant block times, for instance by having a > two-step PoW: > > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to > difficulty adjustments similar to the as-is). As per the property of VDFs, > miners are able show proof of work. > > 2. Use current PoW mechanism with lower difficulty so finding a block takes 1 > minute on average, again subject to as-is difficulty adjustments. > > As a result, variation in block times will be greatly reduced. As I understand it, another weakness of VDFs is that they are not inherently progress-free (their sequential nature prevents that; they are inherently progress-requiring). Thus, a miner which focuses on improving the amount of energy that it can pump into the VDF circuitry (by overclocking and freezing the circuitry), could potentially get into a winner-takes-all situation, possibly leading to even *worse* competition and even *more* energy consumption. After all, if you can start mining 0.1s faster than the competition, that is a 0.1s advantage where *only you* can mine *in the entire world*. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Opinion on proof of stake in future
VDFs might enable more constant block times, for instance by having a two-step PoW: 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to difficulty adjustments similar to the as-is). As per the property of VDFs, miners are able show proof of work. 2. Use current PoW mechanism with lower difficulty so finding a block takes 1 minute on average, again subject to as-is difficulty adjustments. As a result, variation in block times will be greatly reduced. Zac On Tue, 18 May 2021 at 09:07, ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning Erik, > > > Verifiable Delay Functions involve active participation of a single > > verifier. Without this a VDF decays into a proof-of-work (multiple > > verifiers === parallelism). > > > > The verifier, in this case is "the bitcoin network" taken as a whole. > > I think it is reasonable to consider that some difficult-to-game > > property of the last N blocks (like the hash of the last 100 > > block-id's or whatever), could be the verification input. > > > > The VDF gets calculated by every eligible proof-of-burn miner, and > > then this is used to prevent a timing issue. > > > > Seems reasonable to me, but I haven't looked too far into the > > requirements of VDF's > > > > nice summary for anyone who is interested: > > https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3bec2bf4 > > > > While VDF's almost always lead to a "cpu-speed monopoly", this would > > only be helpful for block latency in a proof-of-burn chain. Block > > height would be calculated by eligible-miner-burned-coins, so the > > monopoly could be easily avoided. > > Interesting link. > > However, I would like to point out that the *real* reason that PoW > consumes lots of power is ***NOT***: > > * Proof-of-work is parallelizable, so it allows miners consume more energy > (by buying more grinders) in order to get more blocks than their > competitors. > > The *real* reason is: > > * Proof-of-work allows miners to consume more energy in order to get more > blocks than their competitors. > > VDFs attempt to sidestep that by removing parallelism. > However, there are ways to increase *sequential* speed, such as: > > * Overclocking. > * This shortens lifetime, so you can spend more energy (on building new > miners) in order to get more blocks than your competitors. > * Lower temperatures. > * This requires refrigeration/cooling, so you can spend more energy (on > the refrigeration process) in order to get more blocks than your > competitors. > > I am certain people with gaming rigs can point out more ways to improve > sequential speed, as necessary to get more frames per second. > > Given the above, I think VDFs will still fail at their intended task. > Speed, yo. > > Thus, VDFs do not serve as a sufficient deterrent away from > ever-increasing energy consumption --- it just moves the energy consumption > increase away from the obvious (parallelism) to the > obscure-if-you-have-no-gamer-buds. > > You humans just need to get up to Kardashev 1.0, stat. > > Regards, > ZmnSCPxj > ___ > 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: Low Energy Bitcoin PoW
On Mon, May 17, 2021 at 11:47 PM ZmnSCPxj: > > When considering any new proof-of-foo, it is best to consider all effects > until you reach the base physics of the arrow of time, at which point you > will realize it is ultimately just another proof-of-work anyway. > Let's not simplify away economic considerations, such as externalities. The whole debate about the current PoW is about negative externalities related to energy production. Depending on the details, CAPEX (R, real-estate, construction, production) may have less externalities, and if that's the case, we should be interested in adopting a PoW that is intensive in these types of CAPEX. On Mon, May 17, 2021 at 2:20 PM Keagan McClelland wrote: First it just pushes the energy consumption upstream to the chip > manufacturing process, rather than eliminating it. And it may trade some > marginal amount of the energy consumption for the set of resources it takes > to educate and create chip manufacturers. The only way to avoid that cost > being funneled back into more energy consumption [...] > I challenge you to substantiate these assertions. Real-estate and human cognitive work are not energy intensive and are a major factor in the expected costs of some alternative PoWs. The expected mining effort is such that the cost will reach the expected reward, no more, so there is every reason to believe that energy consumption will be small compared to the current PoW. Therefore, the total associated negative externalities for the alternative PoWs may well be much lower than the externalities of energy production. This needs detailed analysis, not a knee-jerk reaction. ___ 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
>> 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.mcclell...@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
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
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 ___ 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
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Opinion on proof of stake in future
Good morning Erik, > Verifiable Delay Functions involve active participation of a single > verifier. Without this a VDF decays into a proof-of-work (multiple > verifiers === parallelism). > > The verifier, in this case is "the bitcoin network" taken as a whole. > I think it is reasonable to consider that some difficult-to-game > property of the last N blocks (like the hash of the last 100 > block-id's or whatever), could be the verification input. > > The VDF gets calculated by every eligible proof-of-burn miner, and > then this is used to prevent a timing issue. > > Seems reasonable to me, but I haven't looked too far into the > requirements of VDF's > > nice summary for anyone who is interested: > https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3bec2bf4 > > While VDF's almost always lead to a "cpu-speed monopoly", this would > only be helpful for block latency in a proof-of-burn chain. Block > height would be calculated by eligible-miner-burned-coins, so the > monopoly could be easily avoided. Interesting link. However, I would like to point out that the *real* reason that PoW consumes lots of power is ***NOT***: * Proof-of-work is parallelizable, so it allows miners consume more energy (by buying more grinders) in order to get more blocks than their competitors. The *real* reason is: * Proof-of-work allows miners to consume more energy in order to get more blocks than their competitors. VDFs attempt to sidestep that by removing parallelism. However, there are ways to increase *sequential* speed, such as: * Overclocking. * This shortens lifetime, so you can spend more energy (on building new miners) in order to get more blocks than your competitors. * Lower temperatures. * This requires refrigeration/cooling, so you can spend more energy (on the refrigeration process) in order to get more blocks than your competitors. I am certain people with gaming rigs can point out more ways to improve sequential speed, as necessary to get more frames per second. Given the above, I think VDFs will still fail at their intended task. Speed, yo. Thus, VDFs do not serve as a sufficient deterrent away from ever-increasing energy consumption --- it just moves the energy consumption increase away from the obvious (parallelism) to the obscure-if-you-have-no-gamer-buds. You humans just need to get up to Kardashev 1.0, stat. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
> A few things jump out at me as I read this proposal > > First, deriving the hardness from capex as opposed to opex switches the > privilege from those who have cheap electricity to those who have access to > chip manufacturers/foundries. While this is similarly the case for Bitcoin > ASICS today, the longevity of the PoW algorithm has led to a better > distribution of knowledge and capital goods required to create ASICS. The > creation of a new PoW of any kind, hurts this dimension of decentralization > as we would have to start over from scratch on the best way to build, > distribute, and operate these new pieces of hardware at scale. While I have > not combed over the PoW proposed here in fine detail, the more complicated > the algorithm is, the more it privileges those with specific knowledge about > it and the manufacturing process. > > The competitive nature of Bitcoin mining is such that miners will be willing > to spend up to their expected mining reward in their operating costs to > continue to mine. Let's suppose that this new PoW was adopted, miners will > continue to buy these chips in ever increasing quantities, turning the > aforementioned CAPEX into a de facto OPEX. This has a few consequences. First > it just pushes the energy consumption upstream to the chip manufacturing > process, rather than eliminating it. And it may trade some marginal amount of > the energy consumption for the set of resources it takes to educate and > create chip manufacturers. The only way to avoid that cost being funneled > back into more energy consumption is to make the barrier to understanding of > the manufacturing process sufficiently difficult so as to limit the > proliferation of these chips. Again, this privileges the chip manufacturers > as well as those with close access to the chip manufacturers. > > As far as I can tell, the only thing this proposal actually does is create a > very lucrative business model for those who sell this variety of chips. Any > other effects of it are transient, and in all likelihood the transient > effects create serious centralization pressure. > > At the end of the day, the energy consumption is foundational to the system. > The only way to do away with authorities, is to require competition. This > competition will employ ever more resources until it is unprofitable to do > so. At the base of all resources of society is energy. You get high energy > expenditure, or a privileged class of bitcoin administrators: pick one. I > suspect you'll find the vast majority of Bitcoin users to be in the camp of > the energy expenditure, since if we pick the latter, we might as well just > pack it in and give up on the Bitcoin experiment. Keagan is quite correct. Ultimately all currency security derives from energy consumption. Everything eventually resolves down to proof-of-work. * Proof-of-space simply moves the work to the construction of more storage devices. * Proof-of-stake simply moves the work to stake-grinding attacks. * The optical proof-of-work simply moves the work to the construction of more miners. * Even government-enforced fiat is ultimately proof-of-work, as the operation and continued existence of any government is work. It is far better to move towards a more *direct* proof-of-work, than to add more complexity and come up with something that is just proof-of-work, but with the work moved off to somewhere else and with additional moving parts that can be jammed or hacked into. When considering any new proof-of-foo, it is best to consider all effects until you reach the base physics of the arrow of time, at which point you will realize it is ultimately just another proof-of-work anyway. At least, proof-of-work is honest about its consumption of resources. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
