search

dtr-org / unit-e

A digital currency for a new era of decentralized trust
https://unit-e.io
MIT License
45 stars 15 forks source link

Adapt information about implemented UIPs and BIPs #895

Closed cornelius closed 5 years ago

cornelius commented 5 years ago

This fixes #640.

The information has been taken from https://github.com/dtr-org/unit-e-project/blob/master/bip-activation-reference.md, so that file can then be removed.

scravy commented 5 years ago

Why not have UIPs and BIPs?

Some BIPs are literally implemented and do not affect bitcoin per se, but are for instance wallet designs.

cornelius commented 5 years ago

Why not have UIPs and BIPs?

Some BIPs are literally implemented and do not affect bitcoin per se, but are for instance wallet designs.

I think we should have UIPs and BIPs. I agree that it is important to document what BIPs are implemented. The question is how to do that from a practical point of view.

Keeping the bips.md file as it comes from upstream appears to be confusing to me, because it has detailed references to Bitcoin Core, release versions, release dates, protocol bumps, block numbers, pull requests. That's why, in the first iteration of this pull request, I opted for removing it and referencing it from upstream with the comments about what we changed. So the information about both UIPs and BIPs is in one file.

Alternatively we could keep the bips.md file, and add a comment at the top with the notes about what we changed. So having two files, and keeping the original upstream information in the file, not only referencing the file from the bitcoin repo.

Or we actually write our own version of the list of BIPs with references to our own versions and comments where BIPs don't literally apply. That would probably be the nicest solution, but also quite a bit of effort. That's why I was hesitant to do that and opted for the simpler solution of just putting together the information we already have written down.

What do you think would be the best solution for now?

thothd commented 5 years ago

Why not have UIPs and BIPs? Some BIPs are literally implemented and do not affect bitcoin per se, but are for instance wallet designs.

I think we should have UIPs and BIPs. I agree that it is important to document what BIPs are implemented. The question is how to do that from a practical point of view.

Keeping the bips.md file as it comes from upstream appears to be confusing to me, because it has detailed references to Bitcoin Core, release versions, release dates, protocol bumps, block numbers, pull requests. That's why, in the first iteration of this pull request, I opted for removing it and referencing it from upstream with the comments about what we changed. So the information about both UIPs and BIPs is in one file.

Alternatively we could keep the bips.md file, and add a comment at the top with the notes about what we changed. So having two files, and keeping the original upstream information in the file, not only referencing the file from the bitcoin repo.

Or we actually write our own version of the list of BIPs with references to our own versions and comments where BIPs don't literally apply. That would probably be the nicest solution, but also quite a bit of effort. That's why I was hesitant to do that and opted for the simpler solution of just putting together the information we already have written down.

What do you think would be the best solution for now?

I've mentioned my thoughts above: "sounds like we actually wanna curate / filter the bips.md, keeping the ones we actually have in the codebase, maybe commenting on ones that we implemented slightly different? except for the removed or enabled by default bips which are in this file, not sure how you can track it otherwise by just referring to Bitcoin Core bips.md"

so yeah I think we should keep bips.md with comments at the top should be good enough for now

cornelius commented 5 years ago

so yeah I think we should keep bips.md with comments at the top should be good enough for now

Ok, I'll adapt the pull request.