Lonero Foundation [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-11 📝 Original message:Hi, I have submitted the ...
📅 Original date posted:2021-03-11
📝 Original message:Hi, I have submitted the BIP Pull Request here:
https://github.com/bitcoin/bips/pull/1084
Hoping to receive a BIP # for the draft prior to development/reference
implementation.
Best regards, Andrew
On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <loneroassociation at gmail.com>
wrote:
> Hi, here is the list to the BIP proposal on my own repo:
> https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki
> Can I submit a pull request on the BIPs repo for this to go into draft
> mode? Also, I think this provides at least some more insight on what I want
> to work on.
>
> Best regards, Andrew
>
> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <
> loneroassociation at gmail.com> wrote:
>
>> [off-list]
>>
>> Okay. I will do so and post the link here for discussion before doing a
>> pull request on BIP's repo as the best way to handle it.
>>
>> Best regards, Andrew
>>
>> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe <ricardojdfilipe at gmail.com>
>> wrote:
>>
>>> 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 at lists.linuxfoundation.org> escreveu no dia sábado,
>>> 6/03/2021 à(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
>>> finding 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 benefit 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 request 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 seen as opposed to offline discussion. Since the instructions say
>>> to email bitcoin-dev before doing a bip draft, I have done that. Since
>>> people want to see 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 some 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 at gmail.com> wrote:
>>> >>
>>> >> > 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.
>>> >>
>>> >> My instincts tell me that this is an outlandish claim. Do you have
>>> supporting evidence for this?
>>> >>
>>> >> Keagan
>>> >>
>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> 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 4:11 PM Keagan McClelland <
>>> keagan.mcclelland at gmail.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 useful it provides an avenue for actors to have nothing at stake when
>>> submitting 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 therefore 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
>>> 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. 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 entity is tying their own interests to that of the bitcoin
>>> network at large. It also puts the developers in a position where they can
>>> be bribed by entities with a vested interest in deciding what the new
>>> "useful" proof of work should 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 <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>>>>
>>> >>>>> Also in regards to my other email, I forgot to iterate that my
>>> cryptography proposal helps behind the efficiency category but also tackles
>>> problems such as NP-Completeness or Halting which is something the BTC
>>> network could be vulnerable to in the future. For sake of simplicity, I do
>>> want to do 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 block height have been proposed as hard forks, I feel at the very
>>> least an upgrade regarding the hashing algorithm and cryptography does at
>>> least warrant 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 at gmail.com> 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 at niftybox.net> wrote:
>>> >>>>>>>
>>> >>>>>>> Hi Ryan and Andrew,
>>> >>>>>>>
>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
>>> bitcoin-dev at 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 at lists.linuxfoundation.org
>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >>>
>>> >>> _______________________________________________
>>> >>> bitcoin-dev mailing list
>>> >>> bitcoin-dev at lists.linuxfoundation.org
>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210311/cf8f16b7/attachment-0001.html>;
📝 Original message:Hi, I have submitted the BIP Pull Request here:
https://github.com/bitcoin/bips/pull/1084
Hoping to receive a BIP # for the draft prior to development/reference
implementation.
Best regards, Andrew
On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <loneroassociation at gmail.com>
wrote:
> Hi, here is the list to the BIP proposal on my own repo:
> https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki
> Can I submit a pull request on the BIPs repo for this to go into draft
> mode? Also, I think this provides at least some more insight on what I want
> to work on.
>
> Best regards, Andrew
>
> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <
> loneroassociation at gmail.com> wrote:
>
>> [off-list]
>>
>> Okay. I will do so and post the link here for discussion before doing a
>> pull request on BIP's repo as the best way to handle it.
>>
>> Best regards, Andrew
>>
>> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe <ricardojdfilipe at gmail.com>
>> wrote:
>>
>>> 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 at lists.linuxfoundation.org> escreveu no dia sábado,
>>> 6/03/2021 à(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
>>> finding 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 benefit 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 request 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 seen as opposed to offline discussion. Since the instructions say
>>> to email bitcoin-dev before doing a bip draft, I have done that. Since
>>> people want to see 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 some 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 at gmail.com> wrote:
>>> >>
>>> >> > 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.
>>> >>
>>> >> My instincts tell me that this is an outlandish claim. Do you have
>>> supporting evidence for this?
>>> >>
>>> >> Keagan
>>> >>
>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> 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 4:11 PM Keagan McClelland <
>>> keagan.mcclelland at gmail.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 useful it provides an avenue for actors to have nothing at stake when
>>> submitting 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 therefore 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
>>> 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. 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 entity is tying their own interests to that of the bitcoin
>>> network at large. It also puts the developers in a position where they can
>>> be bribed by entities with a vested interest in deciding what the new
>>> "useful" proof of work should 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 <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>>>>
>>> >>>>> Also in regards to my other email, I forgot to iterate that my
>>> cryptography proposal helps behind the efficiency category but also tackles
>>> problems such as NP-Completeness or Halting which is something the BTC
>>> network could be vulnerable to in the future. For sake of simplicity, I do
>>> want to do 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 block height have been proposed as hard forks, I feel at the very
>>> least an upgrade regarding the hashing algorithm and cryptography does at
>>> least warrant 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 at gmail.com> 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 at niftybox.net> wrote:
>>> >>>>>>>
>>> >>>>>>> Hi Ryan and Andrew,
>>> >>>>>>>
>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
>>> bitcoin-dev at 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 at lists.linuxfoundation.org
>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >>>
>>> >>> _______________________________________________
>>> >>> bitcoin-dev mailing list
>>> >>> bitcoin-dev at lists.linuxfoundation.org
>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210311/cf8f16b7/attachment-0001.html>;