public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Lonero Foundation <loneroassociation@gmail.com>
To: Eric Voskuil <eric@voskuil.org>
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 18:10:43 -0500	[thread overview]
Message-ID: <CA+YkXXyFr3JKdONXdqbQwJd=z0KQHy9MAVn2wZDfdLufZRNDag@mail.gmail.com> (raw)
In-Reply-To: <974C7CF0-5087-4120-B860-35FAEF39EA95@voskuil.org>

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

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 <eric@voskuil.org> 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 <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: 16637 bytes --]

  reply	other threads:[~2021-03-05 23:10 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   ` [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining Lonero Foundation
2021-03-05 22:49     ` Eric Voskuil
2021-03-05 23:10       ` Lonero Foundation [this message]
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='CA+YkXXyFr3JKdONXdqbQwJd=z0KQHy9MAVn2wZDfdLufZRNDag@mail.gmail.com' \
    --to=loneroassociation@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@voskuil.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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