MIME-Version: 1.0
References: <CA+YkXXxUdZFYTa1c-F=-FzoQQVtV3GUmE2Okec-zRAD3xS1qAQ@mail.gmail.com>
 <CAMnpzfop8ttqjMAKoS37zpQV6WiZfi1Bn+y_e-HaepTiD4Vm1Q@mail.gmail.com>
 <CAB0O3SVNyr_t23Y0LyT0mSaf6LONFRLYJ8qzO7rcdJFnrGccFw@mail.gmail.com>
 <CA+YkXXwkSCu=2UOEhzFBzGDHo1c=Ewqsnxp632ke3jdH1ff5WA@mail.gmail.com>
 <CA+YkXXwfS7eer5Za_ed9tCNdfOp4c3nV_X=mfXzoDxMm6BrizQ@mail.gmail.com>
 <CALeFGL31M5DAULLRtCwjPYHaPVqsVqREUg6WQ2-cuj23SNk=BA@mail.gmail.com>
 <CA+YkXXwBMG6YUAhf-2U5EV5Ep5RgG2foc9chramNFN5=AQ=-EA@mail.gmail.com>
 <CALeFGL3E-rWW9aJkwre_3UF44vbNxPH2436DvaQdHoqEQ5b+eg@mail.gmail.com>
 <CA+YkXXyBmOootb=Kt6CH3yquYVnAZd=fJQqiF_A3p_pkB8QC3g@mail.gmail.com>
In-Reply-To: <CA+YkXXyBmOootb=Kt6CH3yquYVnAZd=fJQqiF_A3p_pkB8QC3g@mail.gmail.com>
From: Ricardo Filipe <ricardojdfilipe@gmail.com>
Date: Sat, 6 Mar 2021 15:21:12 +0000
Message-ID: <CALC81CMDQf4PqxRisQw58OL7QSFeMcQTvLMvmtOGJ_ya4-dhLg@mail.gmail.com>
To: Lonero Foundation <loneroassociation@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST
 Datastore for Energy Efficient Mining
Precedence: list

As said before, you are free to create the BIP in your own repository
and bring it to discussion on the mailing list. then you can do a PR

Lonero Foundation via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> escreveu no dia s=C3=A1bado,
6/03/2021 =C3=A0(s) 08:58:
>
> I know Ethereum had an outlandishly large percentage of nodes running on =
AWS, I heard the same thing is for Bitcoin but for mining. Had trouble find=
ing the article online so take it with a grain of salt. The point though is=
 that both servers and ASIC specific hardware would still be able to benefi=
t from the cryptography upgrade I am proposing, as this was in relation to =
the disinfranchisemet point.
>
> That said, I think the best way to move forward is to submit a BIP pull r=
equest for a draft via GitHub using BIP #2's draft format and any questions=
 people have can be answered in the reqeust's comments. That way people don=
't have to get emails everytime there is a reply, but replies still get see=
n as opposed to offline discussion. Since the instructions say to email bit=
coin-dev before doing a bip draft, I have done that. Since people want to s=
ee the draft beforehand and it isn't merged manually anyways, I think it is=
 the easiest way to handle this.
>
> I'm also okay w/ continuing the discussion on bitcoin-dev but rather form=
 a discussion on git instead given I don't want to accidentally impolitely =
bother people given this is a moderated list and we already established som=
e interest for at least a draft.
>
> Does that seem fine?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland <keagan.mcclelland@gmail.c=
om> wrote:
>>
>> > A large portion of BTC is already mined through AWS servers and non-as=
ic specific hardware anyways. A majority of them would benefit from a hybri=
d proof, and the fact that it is hybrid in that manner wouldn't disenfranch=
ise currently optimized mining entities as well.
>>
>> My instincts tell me that this is an outlandish claim. Do you have suppo=
rting evidence for this?
>>
>> Keagan
>>
>> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
>>>
>>> Actually I mentioned a proof of space and time hybrid which is much dif=
ferent than staking. Sorry to draw for the confusion as PoC is more commonl=
y used then PoST.
>>> There is a way to make PoC cryptographically compatible w/ Proof of Wor=
k as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>> It has rarely been done though given the technological complexity of be=
ing both CPU compatible and memory-hard compatible. There are lots of benef=
its outside of the realm of efficiency, and I already looked into numerous =
fault tolerant designs as well and what others in the cryptography communit=
y attempted to propose. The actual argument you have only against this is t=
he Proof of Memory fallacy, which is only partially true. Given how the cur=
rent hashing algorithm works, hard memory allocation wouldn't be of much be=
nefit 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 figu=
res 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 cryptograph=
y 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 provid=
e 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 mino=
r 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 ex=
penditure 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-asi=
c 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 disenfranchi=
se currently optimized mining entities as well.
>>>
>>> There are other reasons why a cryptography upgrade like this is benefic=
ial. Theoretically one can argue BItcoin isn't fully decentralized. It is f=
ew unsolved mathematical proofs away from being entirely broken. My goal ou=
tside 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 vario=
us research in regards to this area and work alot with distributed computin=
g. I believe if the BTC community likes such a proposal, I would single han=
dedly 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-st=
op-telling-us-that-you-arent-pi3s3yjl
>>>
>>> Best regards,  Andrew
>>>
>>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <keagan.mcclelland@gma=
il.com> wrote:
>>>>
>>>> It is important to understand that it is critical for the work to be "=
useless" in order for the security model to be the same. If the work was us=
eful it provides an avenue for actors to have nothing at stake when submitt=
ing a proof of work, since the marginal cost of block construction will be =
lessened by the fact that the work was useful in a different context and th=
erefore would have been done anyway. This actually degrades the security of=
 the network in the process.
>>>>
>>>> As a separate issue, proposing a hard fork in the hashing algorithm wi=
ll invalidate the enormous amount of capital expenditure by mining entities=
 and disincentivize future capital expenditure into mining hardware that ma=
y compute these more "useful" proofs of work. This is because any change in=
 the POW algorithm will be considered unstable and subject to change in the=
 future. This puts the entire network at even more risk meaning that no ent=
ity is tying their own interests to that of the bitcoin network at large. I=
t also puts the developers in a position where they can be bribed by entiti=
es with a vested interest in deciding what the new "useful" proof of work s=
hould be.
>>>>
>>>> All of these things make the Bitcoin network worse off.
>>>>
>>>> Keagan
>>>>
>>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>> Also in regards to my other email, I forgot to iterate that my crypto=
graphy proposal helps behind the efficiency category but also tackles probl=
ems such as NP-Completeness or Halting which is something the BTC network c=
ould be vulnerable to in the future. For sake of simplicity, I do want to d=
o this BIP because it tackles lots of the issues in regards to this manner =
and can provide useful insight to the community. If things such as bigger b=
lock height have been proposed as hard forks, I feel at the very least an u=
pgrade regarding the hashing algorithm and cryptography does at least warra=
nt some discussion. Anyways I hope I can send you my BIP, just let me know =
on the preferred format?
>>>>>
>>>>> Best regards, Andrew
>>>>>
>>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <loneroassociation@gm=
ail.com> wrote:
>>>>>>
>>>>>> Hi, this isn't about the energy efficient argument in regards to ren=
ewables or mining devices but a better cryptography layer to get the most o=
ut 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 n=
ot 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 negati=
ve externalities will go away soon because of the move to renewables, so th=
e point is likely moot.
>>>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev