public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil•org>
To: Lonero Foundation <loneroassociation@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining
Date: Fri, 5 Mar 2021 14:49:57 -0800	[thread overview]
Message-ID: <974C7CF0-5087-4120-B860-35FAEF39EA95@voskuil.org> (raw)
In-Reply-To: <CA+YkXXxzURKiD5r9ATG8CefRzyh9CKzF4Cwzd3-Mr5v5XrzinA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 9557 bytes --]

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 <loneroassociation@gmail•com> 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 <eric@voskuil•org> 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 <loneroassociation@gmail•com> 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 <eric@voskuil•org> 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 <c1.devrandom@niftybox•net> 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

[-- Attachment #2: Type: text/html, Size: 15311 bytes --]

  reply	other threads:[~2021-03-05 22:50 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+YkXXzfEyeXYMyPKL20S+2VVRZVuHRT6eRgX56FBgG_A+uVSw@mail.gmail.com>
     [not found] ` <12480994-451A-4256-8EFA-4741B3EC2006@voskuil.org>
2021-03-05 22:03   ` Lonero Foundation
2021-03-05 22:49     ` Eric Voskuil [this message]
2021-03-05 23:10       ` Lonero Foundation
2021-03-05 20:53 Eric Voskuil
  -- strict thread matches above, loose matches on Subject: below --
2021-03-04 23:42 Lonero Foundation
2021-03-05 13:42 ` Ryan Grant
     [not found]   ` <CAB0O3SVNyr_t23Y0LyT0mSaf6LONFRLYJ8qzO7rcdJFnrGccFw@mail.gmail.com>
2021-03-05 15:12     ` Lonero Foundation
2021-03-05 16:16       ` Lonero Foundation
2021-03-05 21:11         ` Keagan McClelland
2021-03-05 21:21           ` Lonero Foundation
2021-03-06  0:41             ` Keagan McClelland
2021-03-06  0:57               ` Lonero Foundation
2021-03-06 15:21                 ` Ricardo Filipe
     [not found]                   ` <CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com>
2021-03-08 23:40                     ` Lonero Foundation
2021-03-11 15:29                       ` Lonero Foundation
2021-03-12 15:02                         ` Erik Aronesty
2021-03-12 16:54                           ` Lonero Foundation
2021-03-12 22:37                             ` email
2021-03-12 23:21                               ` Lonero Foundation
2021-03-12 23:31                                 ` Lonero Foundation
2021-03-13  8:13                                   ` email
2021-03-13 15:02                                     ` Lonero Foundation
2021-03-13 15:45                                       ` yancy
2021-03-13 17:11                                         ` Lonero Foundation
2021-03-13 19:44                                           ` email
2021-03-14  5:45                                             ` Lonero Foundation
2021-03-17  0:24                                       ` Erik Aronesty
2021-03-17  5:05                         ` ZmnSCPxj
2021-03-17  5:59                           ` Lonero Foundation
2021-03-17  6:56                             ` ZmnSCPxj
2021-03-17  7:06                               ` Lonero Foundation
2021-03-14 12:36         ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-14 14:32           ` Thomas Hartman
2021-03-16 18:22             ` Lonero Foundation
2021-03-15  2:02           ` Eric Martindale
2021-03-15  2:32             ` Lonero Foundation
     [not found]               ` <CA+YkXXyMUQtdSvjuMPQO71LpPb8qFdy-LTSrA8FEbeWMbPWa4w@mail.gmail.com>
2021-03-15  2:58                 ` Lonero Foundation

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=974C7CF0-5087-4120-B860-35FAEF39EA95@voskuil.org \
    --to=eric@voskuil$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=loneroassociation@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox