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 17:03:21 -0500 [thread overview]
Message-ID: <CA+YkXXxzURKiD5r9ATG8CefRzyh9CKzF4Cwzd3-Mr5v5XrzinA@mail.gmail.com> (raw)
In-Reply-To: <12480994-451A-4256-8EFA-4741B3EC2006@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 8778 bytes --]
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: 13579 bytes --]
next parent reply other threads:[~2021-03-05 22:03 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 [this message]
2021-03-05 22:49 ` [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining Eric Voskuil
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=CA+YkXXxzURKiD5r9ATG8CefRzyh9CKzF4Cwzd3-Mr5v5XrzinA@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