New BIP: PoST Datastore for Advanced Cryptography and Higher Efficiency Mining

[Mentors4EDU]

A new BIP for Consensus (Hard Fork) PoST Datastore for Advanced Cryptography and Higher Efficiency Mining
I have already talked about this a bit in the btc-dev list. I decided to submit at least for draft status, and hope that I can be assigned a BIP number to address/work on this further.

[Mentors4EDU]

@luke-jr I am hoping to be assigned a BIP # soon for this draft so I have something to reference instead of bip-amkn-posthyb.

Keep in mind this is just draft status, but I will start doing implementations soon so that eventually I can potentially upgrade it to final status.

[luke-jr]

BIP number assignment requires a technically-sound specification (it appears there is none in this draft), and documentation of backward compatibility impact.

Please feel free to ping me once you've added these.

[kallewoof]

I skimmed through the text, and I'm more confused than I was before I began. I suggest the author read up on other BIPs to get a better feel for how these are usually structured, then read BIP 2 carefully. It could also perhaps be a good exercise to read up on the scientific method.

[Mentors4EDU]

Hi, I'm adding more details in regards to technical implementation given the complexity of this subject. I will also integrate backwards compatibility into my proposal. Will ping Luke when done. I was planning to have some preprints with a higher level of technical detail, but will integrate a higher level of technical detail given the need of further soundness or clarification in the proposal.

[Mentors4EDU]

@luke-jr Do let me know if you need any further updates for this to be assigned a bip draft number? As I want to start doing implementation and dev work quite soon.

[Mentors4EDU]

Hello @luke-jr
Not to be a bother, but I'm still awaiting a BIP draft number so I can at least start developing the reference implementation. I have made a few updates since last time.

[michaelfolkson]

I'm not familiar with the thought process behind giving a draft BIP a number. However, I wouldn't support giving this a BIP number. It seems to be attempting to achieve multiple hugely ambitious goals (with a lot of missing detail) and on top of that needs a hard fork (which though not impossible adds an additional dimension of complexity).

I'd recommend focusing on just one goal (ideally not needing a hard fork). Though if you do this it would also need to be fleshed out a lot more than currently to be considered for a BIP number (in my opinion).

[Mentors4EDU]

I'm not familiar with the thought process behind giving a draft BIP a number. However, I wouldn't support giving this a BIP number. It seems to be attempting to achieve multiple hugely ambitious goals (with a lot of missing detail) and on top of that needs a hard fork (which though not impossible adds an additional dimension of complexity).

I'd recommend focusing on just one goal (ideally not needing a hard fork). Though if you do this it would also need to be fleshed out a lot more than currently to be considered for a BIP number (in my opinion).

Hi, hard forks are one of the types of BIP proposals allowed. It is a major change in the consensus, hence the need. There are enough details in regards to what I am trying to build, hence the purpose of this draft. Since the two main goals are related to consensus and it will likely be part of the same hard fork, it is much easier to include it in one BIP. That said, if there is a part needed emphasis on do let me know, for reference please check the comments URL to see if the question was already asked or not as I had somewhat thorough discussions on the subject matter.

[Mentors4EDU]

I also want to emphasize that the same topic was already proposed March 4th, receiving a BIP number doesn't automatically mean final or approved. If there is a section though needing expanding, I'm happy to add more details further or clarify as needed, however I'm looking for a number to at least establish it's place in being proposed and it doesn't seem to contradict the current BIP format. @luke-jr

[Mentors4EDU]

BIP number assignment requires a technically-sound specification (it appears there is none in this draft), and documentation of backward compatibility impact.

Please feel free to ping me once you've added these.

@luke-jr I think my newest commits cover these two.
I also have covered this already via the bitcoin-dev list as well.
Best regards, Andrew

[luke-jr]

Still don't see a spec.

[Mentors4EDU]

Still don't see a spec.

Hi, I am updating this further and will be tagging you quite soon when done.

[Mentors4EDU]

Hi @luke-jr
Please view the file, I have added to the specification and added a core considerations subsection.
This has some UMLs, lists some parameters, and includes some references.
I am hoping since this has been actively edited since March, and I added backwards compatibility and the specifications section, that this can finally be assigned a bip draft number. That would be super helpful prior to me finishing up implementation and development. Do let me know if you need anything else.

[Mentors4EDU]

Hi, these changes were added along with the past edits, further expanding on the technological specifications or what is expected in regards to the implementation.

Hoping for at least a draft # soon, as I have already started a portion of the development.

[maflcko]

I think this can be closed according to BIP 2

Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.

I read the whole mailing list thread and couldn't find a single approval of this BIP. Neither did anyone approve the BIP in this thread.

[maflcko]

You can read the full BIP 2 here: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

[Mentors4EDU]

You can read the full BIP 2 here: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

Hi, the BIP has been discussed. Bip 2 specifically states, "The BIP draft must have been sent to the Bitcoin development mailing list for discussion.".

Also, please take into account assigning a BIP draft # doesn't even mean acceptance. Accepted BIPs are proposed. There is a difference between the draft and proposed statuses.

The BIP doesn't describe a democratic voting process and I don't think drafts or proposals for the entire Bitcoin ecosystem are decided on the basis of input from a very small group of people. That sounds a bit too centralized and also prune to the fact that a majority of people on the mailing lists don't like hard forks to begin with, hence creating a possibility of censorship.

That said, I think blockchain voting or mass adoption are long term better indicators of community support over just mailing list feedback from a few people.

I also think outright proposing to close a BIP after over 20 revisions and two months of work isn't really a healthy way to effectively communicate the point across and with all due respect, not the best way to handle things internally.

[Mentors4EDU]

Anyways I'm hoping for a draft number so I can push this proposal to a further status afterwords and continue working on the technological implementation. If more revisions are needed let me know, but I feel the way the proposal has been structured is a mass improvement and worth the read.

[maflcko]

I also think outright proposing to close a BIP after over 20 revisions and two months of work isn't really a healthy way to effectively communicate the point across and with all due respect, not the best way to handle things internally.

I posted this above, but the way to vet an idea is not to put two months of work into a document and request it to be merged. BIP 2 states:

Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time.

[...]

Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the Bitcoin development mailing list.

[Mentors4EDU]

I also think outright proposing to close a BIP after over 20 revisions and two months of work isn't really a healthy way to effectively communicate the point across and with all due respect, not the best way to handle things internally.

I posted this above, but the way to vet an idea is not to put two months of work into a document and request it to be merged. BIP 2 states:

Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time.

[...]

Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the Bitcoin development mailing list.

Hi, there needs to be specifics then on what constitutes the Bitcoin community. I have already sought out general feedback for many of the topics presented in this BIP before going to the mailing list. This includes from software engineers who were concerned about Bitcoin's energy consumption as well as from posts I did on Hackernoon.

Also keep in mind quantum resistance, energy consumption and network latency are some of the most discussed areas of interest on the Bitcoin mailing lists. I believe any lack of interest or skepticism would change in the future once the technological implementation becomes more prevalent. However, closing it on the assumption that it probably isn't worth anybody's time is living in the past and probably prevents people from potentially seeing a technology that fixes issues they have always been discussing anyways.

That is why I disagree, and think it is healthier to assign it a draft # and allow it to naturally grow to where it can be proposed or withdrawn or abandoned.

[maflcko]

Again, there is ~zero support for this hard-fork proposal on the mailing list. A hard-fork proposal ideally has 100% support to avoid a chain split. I know that there are hard-fork proposals in this repository that didn't achieve 100% support, but at least the support was non-zero at some time and there was a slim chance that they might get adopted.

[Mentors4EDU]

Again, there is ~zero support for this hard-fork proposal on the mailing list. A hard-fork proposal ideally has 100% support to avoid a chain split. I know that there are hard-fork proposals in this repository that didn't achieve 100% support, but at least the support was non-zero at some time and there was a slim chance that they might get adopted.

Hi, a large degree of the criticisms I have received was on misunderstandings of the technology. Some have mistakenly believed that this might disenfranchise ASIC miners or reduce the capital expenditure aimed at securing Bitcoin. Both of these were assumptions that were untrue and are reasons why I decided to address them specifically in my BIP. You do understand also as a Bitcoin maximalist, if this is just Bitcoin but with better energy efficiency and Quantum resistance in its architecture, in the future it could have the potential to become de facto Bitcoin. A majority of what is discussed in this BIP likely would have to have similar things take place on Bitcoin's code anyways given what will become the end of Moore's law and the rise of Quantum computing.

[Mentors4EDU]

Hi @luke-jr
Given that this BIP tackles energy efficiency problems such as the ones seen here, as well as problems related to security from various standpoints that the community is still considering, I feel like as a draft this isn't a bad place to start.

I have already been seeking out feedback from various places. The specifications section has been expanded dramatically as well as other sections.

Please let me know if anything else is needed to otherwise assign a draft number. Thank you for your time.

[maflcko]

#1084 (comment)

The burden is on you (as per BIP 2) to show that this has non-zero support. You can't claim that no one understands this and thus it must be a good start.

[Mentors4EDU]

Hi, @MarcoFalke
I'm more then willing to show this has non-zero support. Many of the comments weren't outright disapprovals but rather concerns. Anyways, I will provide some insights quite soon as a more detailed response in regards to the support levels. Hopefully they will be as valuable as the same person telling me I have zero support in three or four different ways as comments to a GitHub pull request.

Best regards, Andrew

[Mentors4EDU]

Hi @MarcoFalke
I do apologize if I do sound a bit salty. I will provide a comments summary in this BIP in regards to the concerns on support levels and insight and clarity on that area. I was hoping however, that you would provide comments in regards to which areas you were looking for more expansions on or comments in regards to the tech. Henceforth, my disparaging remarks in the morning.
Best regards, Andrew

[michaelfolkson]

I think this can be closed according to BIP 2

I agree with @MarcoFalke that this can be closed for all the reasons given above. There has to be a bar for giving out BIP numbers and it seems to be universally agreed that this proposed BIP does not meet that bar.

[Mentors4EDU]

I have archived this bip as a preprint and will develop this project further. I am deciding to close this bip for now and hopefully people's minds are changed after the project is live.

Best regards, Andrew