Hi, in regards to my research this is just one of my patents: https://patents.google.com/patent/CN110825707A This isn't related to this proposal but gives you a general depth of understanding in regards to the technology and field I'm working on in reducing redundancy and efficiency. You aren't a cryptographer, but there are easy ways to validate my proposal if it was to be made. In regards to popularity, many people have wanted to upgrade BTC's cryptography in a similar manner. I believe it is at the very least a topic of interest to you and others in the community. I would like to draft it out. Lastly, I wasn't sure if you wanted to create a private thread or meant reply all so that is my fault. The recent reply is to the BTC Dev list so I wanted to provide my insight in regards to your inquiry. Best regards, Andrew On Fri, Mar 5, 2021, 5:50 PM Eric Voskuil wrote: > FYI it’s generally considered bad form repost a private thread, especially > one you initiate. > > ... > > It’s typically more effective to generate some community support before > actually submitting a BIP. Otherwise the process gets easily overwhelmed. > This is likely why you aren’t getting a response. You can draft the BIP in > your own repo and collect feedback from interested parties. > > Posting a link to your research/code is a good start. I’d be happy to look > at an overview of the central principles. I’m not a cryptographer. I write > code, but I look at these things from economic principles. So far all I > have to go on is that you go “much beyond” Chia. That’s not really anything. > > e > > On Mar 5, 2021, at 14:03, Lonero Foundation > wrote: > >  > Hi, Eric. Chia's network is a bad example. They go after energy > consumption in the wrong way entirely. True, it requires a comparable cost > of hardware. I am trying to tackle cryptography in a way that goes much > beyond that. Part of what I am doing includes lowering invalided proofs > while trying to get the best of both worlds in regards to PoW and PoC. It > is an efficiency issue to the core. In regards to the mechanisms of how I > will do that, I suggest you look at the entire proposal which is why I am > hoping the BIP team would be so gracious as to allow me to draft it out on > GitHub. > > Best regards, Andrew > > On Fri, Mar 5, 2021, 4:42 PM Eric Voskuil wrote: > >> How is the argument against PoM only partially true? >> >> I wrote this as soon as I saw Chia. Had two debates on Twitter with >> Brahm, before he blocked me. Two years later, after they finally realized I >> was correct, one of their PhDs contacted me and told me. Better to flesh >> this out early. They had already raised $20 and done their research, so he >> wasn’t exactly in a listening mode. >> >> e >> >> On Mar 5, 2021, at 13:20, Lonero Foundation >> wrote: >> >>  >> Actually I mentioned a proof of space and time hybrid which is much >> different than staking. Sorry to draw for the confusion as PoC is more >> commonly used then PoST. >> There is a way to make PoC cryptographically compatible w/ Proof of Work >> as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space >> It has rarely been done though given the technological complexity of >> being both CPU compatible and memory-hard compatible. There are lots of >> benefits outside of the realm of efficiency, and I already looked into >> numerous fault tolerant designs as well and what others in the cryptography >> community attempted to propose. The actual argument you have only against >> this is the Proof of Memory fallacy, which is only partially true. Given >> how the current hashing algorithm works, hard memory allocation wouldn't be >> of much benefit given it is more optimized for CPU/ASIC specific mining. >> I'm working towards a hybrid mechanism that fixes that. BTW: The way >> Bitcoin currently stands in its cryptography still needs updating >> regardless. If someone figures out NP hardness or the halting problem the >> traditional rule of millions of years to break all of Bitcoin's >> cryptography now comes down to minutes. Bitcoin is going to have to >> eventually radically upgrade their cryptography and hashing algo in the >> future regardless. I want to integrate some form of NP complexity in >> regards to the hybrid cryptography I'm aiming to provide which includes a >> polynomial time algorithm in the cryptography. More than likely the first >> version of my BTC hard fork will be coded in a way where integrating such >> complexity in the future only requires a soft fork or minor upgrade to its >> chain. >> >> In regards to the argument, "As a separate issue, proposing a hard fork >> in the hashing algorithm will invalidate the enormous amount of capital >> expenditure by mining entities and disincentivize future capital >> expenditure into mining hardware that may compute these more "useful" >> proofs of work." >> >> A large portion of BTC is already mined through AWS servers and non-asic >> specific hardware anyways. A majority of them would benefit from a hybrid >> proof, and the fact that it is hybrid in that manner wouldn't >> disenfranchise currently optimized mining entities as well. >> >> There are other reasons why a cryptography upgrade like this is >> beneficial. Theoretically one can argue BItcoin isn't fully decentralized. >> It is few unsolved mathematical proofs away from being entirely broken. My >> goal outside of efficiency is to build cryptography in a way that prevents >> such an event from happening in the future, if it was to ever happen. I >> have various research in regards to this area and work alot with >> distributed computing. I believe if the BTC community likes such a >> proposal, I would single handedly be able to build the cryptographic proof >> myself (though would like as many open source contributors as I can get :) >> >> Anyways just something to consider. We are in the same space in regards >> to what warrants a shitcoin or the whole argument against staking. >> >> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl >> >> Best regards, Andrew >> >> On Fri, Mar 5, 2021 at 3:53 PM Eric Voskuil wrote: >> >>> Hi Andrew, >>> >>> Do you mean that you can reduce the cost of executing the cryptography >>> at a comparable level of security? If so this will only have the effect of >>> increasing the amount of it that is required to consume the same cost. >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox >>> >>> You mentioned a staking hybrid in your original post. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fallacy >>> >>> This would be a change to dynamics - the economic forces at work. >>> Staking is not censorship resistant >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy >>> >>> and is therefore what I refer to as cryptodynamically insecure. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles >>> >>> As such it wouldn’t likely be considered as a contribution to Bitcoin. >>> It might of course be useful in some other context. >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definition >>> >>> But BIPs are proposals aimed at Bitcoin improvement. >>> >>> >>> https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_a_BIP >>> >>> Non-staking attempts to improve energy efficiency are either proof of >>> work in disguise, such as proof of memory: >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy >>> >>> or attempts to repurpose “wasteful” computing, such as by finding prime >>> numbers, which does not imply a reduction in dedicated energy >>> consumption. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle >>> >>> Finally, waste and renewable energy approaches at “carbon” (vs energy) >>> reduction must still consume the same in cost as the reward. In other >>> words, the apparent benefit represents a temporary market shift, with >>> advantage to first movers. The market will still consume what it consumes. >>> If the hashing energy was free all reward consumption would shift to >>> operations. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fallacy >>> >>> The motivation behind these attempts is naively understandable, but >>> based on a false premise. >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy >>> >>> The one thing that reduces Bitcoin energy consumption is an increase in >>> energy cost relative to block reward. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Exhaustion-Fallacy >>> >>> e >>> >>> On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>  >>> Hi, this isn't about the energy efficient argument in regards to >>> renewables or mining devices but a better cryptography layer to get the >>> most out of your hashing for validation. I do understand the arbitrariness >>> of it, but do want to still propose a document. Do I use the Media Wiki >>> format on GitHub and just attach it as my proposal? >>> >>> Best regards, Andrew >>> >>> On Fri, Mar 5, 2021, 10:07 AM Devrandom >>> wrote: >>> >>>> Hi Ryan and Andrew, >>>> >>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> >>>>> >>>>> https://www.truthcoin.info/blog/pow-cheapest/ >>>>> "Nothing is Cheaper than Proof of Work" >>>>> on | 04 Aug 2015 >>>>> >>>>> >>>> Just to belabor this a bit, the paper demonstrates that the mining >>>> market will tend to expend resources equivalent to miner reward. It does >>>> not prove that mining work has to expend *energy* as a primary cost. >>>> >>>> Some might argue that energy expenditure has negative externalities and >>>> that we should move to other resources. I would argue that the negative >>>> externalities will go away soon because of the move to renewables, so the >>>> point is likely moot. >>>> >>>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>>