Full Update to latest Bitcoin version, just pick interesting updates, or nothing?
I think we should keep it as compatible as possible, just to make upgrading easier. So, the procedure is probably something like that: 1) get Bitcoin version the same as CPUchain (to see only changes between coins and get rid of changes between versions) 2) compare and save differences somewhere (for example as git commits) 3) merge newest commits from Bitcoin 4) merge CPUchain changes to the newest Bitcoin version All differences between Bitcoin and CPUchain should be clearly separated (probably at least two branches are needed), that would make upgrading easier in the future. Also, changes needed for consensus should be clearly separated from additional improvements, like faster initial block download.
Taproot, Schnorr signatures and Signet are the most interesting improvements since 0.18. We could make the whole upgrade to 0.21, imo this is the best option. Since a large part of the community and the ecosystem aren't actively participating and probably they aren't aware about this thread, I suggest to send an announcement to the community and ecosystem. If we all agree, then just update, if there are different opinions, discuss them and deliberate. Finally launch the agreed update and see the adoption. We must define the parameters to soft fork. There are several merge conflicts but they aren't a problem. I can be in charge of this job. Best regards, -- Ricard Civil 16 May 2021, 10:47 by vjudeu@gazeta.pl:
I think we should keep it as compatible as possible, just to make upgrading easier. So, the procedure is probably something like that:
1) get Bitcoin version the same as CPUchain (to see only changes between coins and get rid of changes between versions) 2) compare and save differences somewhere (for example as git commits) 3) merge newest commits from Bitcoin 4) merge CPUchain changes to the newest Bitcoin version
All differences between Bitcoin and CPUchain should be clearly separated (probably at least two branches are needed), that would make upgrading easier in the future. Also, changes needed for consensus should be clearly separated from additional improvements, like faster initial block download. _______________________________________________ Cpuchain-dev mailing list -- cpuchain-dev@mailman3.com To unsubscribe send an email to cpuchain-dev-leave@mailman3.com
I have some good news and some bad news. The good news is that all CPUchain-related changes seems to be present only in the latest seven commits: 8fe10f3f minkcrypto@gmail.com Update build-unix.md 8a4243a2 minkcrypto@gmail.com misc: change branding of cpupower 1e58bcbc minkcrypto@gmail.com Update seeds 77c68b45 minkcrypto@gmail.com Add additional rpc call support for ApiServer f19e2ba9 minkcrypto@gmail.com Update README.md 5d1cced8 minkcrypto@gmail.com Update README.md c82cee8f minkcrypto@gmail.com CPUchain Core 0.18.1 fa27a076 laanwj@gmail.com doc: Bump manpages pre-final In the Bitcoin Core source code, there is fa27a076 commit hash, so I assume (correct me if I am wrong, but it seems to be true as far as I know how Git works) the whole history up to that point is present in both coins. The bad news is that after switching to bitcoin and picking that seven changes on top of the latest released version, there are many conflicts and I am still trying to figure out some way to merge that in a clear way that can be accepted by everyone.
Those merging conflicts a totally normal. Don’t consider them as a bad new. I solved some of them a couple of weeks ago, just to test, in a local repo. As I already said in a prior post, don’t worry, I can be in charge of the merging task. Best regards, -- Ricard Civil 6 jun 2021 8:56 por vjudeu@gazeta.pl:
I have some good news and some bad news. The good news is that all CPUchain-related changes seems to be present only in the latest seven commits:
8fe10f3f minkcrypto@gmail.com Update build-unix.md 8a4243a2 minkcrypto@gmail.com misc: change branding of cpupower 1e58bcbc minkcrypto@gmail.com Update seeds 77c68b45 minkcrypto@gmail.com Add additional rpc call support for ApiServer f19e2ba9 minkcrypto@gmail.com Update README.md 5d1cced8 minkcrypto@gmail.com Update README.md c82cee8f minkcrypto@gmail.com CPUchain Core 0.18.1 fa27a076 laanwj@gmail.com doc: Bump manpages pre-final
In the Bitcoin Core source code, there is fa27a076 commit hash, so I assume (correct me if I am wrong, but it seems to be true as far as I know how Git works) the whole history up to that point is present in both coins. The bad news is that after switching to bitcoin and picking that seven changes on top of the latest released version, there are many conflicts and I am still trying to figure out some way to merge that in a clear way that can be accepted by everyone. _______________________________________________ Cpuchain-dev mailing list -- cpuchain-dev@mailman3.com To unsubscribe send an email to cpuchain-dev-leave@mailman3.com
Also, what about signatures? We still have "Min Khang Aung" PGP public key in our code, but as far as I know he is inactive. Should we replace that with our own signatures? Another thing is having an access to the repository. If no active developer has it, then the only way is creating another one, but as the main page is still pointing to the original code, we have no power to change that. Doing separate copies of everything is something I want to avoid if possible, but I am afraid we have no choice if creators of the coin are not there.
Yes, I’m afraid that Min Khang Aung is unreachable. In my opinion, yes, we must replace Min’s signatures with our own. At least while he (or she/they, i personally don’t know) is disappeared since we don’t know if his key has been compromised. There is already a cloned repo from the original https://github.com/cpuchain-core/cpuchain Bitcoin’s repo workflow is a good starting point. Best regards, -- Ricard Civil 6 jun 2021 10:56 por vjudeu@gazeta.pl:
Also, what about signatures? We still have "Min Khang Aung" PGP public key in our code, but as far as I know he is inactive. Should we replace that with our own signatures? Another thing is having an access to the repository. If no active developer has it, then the only way is creating another one, but as the main page is still pointing to the original code, we have no power to change that. Doing separate copies of everything is something I want to avoid if possible, but I am afraid we have no choice if creators of the coin are not there. _______________________________________________ Cpuchain-dev mailing list -- cpuchain-dev@mailman3.com To unsubscribe send an email to cpuchain-dev-leave@mailman3.com
participants (2)
-
ricardcivil＠tuta.io -
vjudeu＠gazeta.pl