June 2021 - Cpuchain-dev - lists.mailman3.com

Re: Testing network

by vjudeu＠gazeta.pl

> We need to determine:- Multisig block script, the k-of-n and who will store the keys. In the BTC signet there is "OP_1 03ad5e0edad18cb1f0fc0d28a3d4f1f3e445640337489abb10404f2d1e086be430 0359ef5021964fe22d6f8e05b2463c9540ce96883fe3b278760f048f5189f2e6c4 OP_2 OP_CHECKMULTISIG", so they used 1-of-2 with two keys. Here we could do the same. One key for some signet miner running on some server 24/7 to produce blocks in regular intervals and one key for the first developer who created signet. Also, some captcha-protected faucet is needed to give test coins to the users.

June 7, 2021

Re: Testing network

by ricardcivil＠tuta.io

I think that we should choose to launch a signet and, if needed, consider new solutions in a future. As you said, signet is easy to set up. To launch it, We need to determine:- Multisig block script, the k-of-n and who will store the keys. Services we'll need: - Hardcoded nodes and maybe DNS seeds ? - Issuers - Faucets (Operators can run those 3 services simultaneously) Best regards, -- Ricard Civil 16 May 2021, 10:50 by vjudeu(a)gazeta.pl: > Signet is one idea, sidechain is another one. For now, I am more focused on sidechain, because: > > 1) signet require signing blocks, it means that developers should give coins to the users through faucets, so it is no longer permissionless > 2) having too small difficulty means that attacking the network is easy, having too high difficulty means that mining mainnet is more profitable and testing is costly > 3) reusing coins from mainnet in testnet means that miners can get two coins at once, which is perfect, also difficulty matches for both coins > 4) destroying coins from testnet when mainnet coins are moved means that testnet transactions could be deleted after testing if needed > 5) there could be more than one sidechain, for example now we would have taproot sidechain, but later we could get rid of it (just by moving coins on mainnet) and create some other testnet for other features, that means upgrading is easier, no voting, no signalling, just moving coins from one network to another with single mainchain transaction > > But of course, sidechains needs more coding, there are some existing examples like Truthcoin, but still, if we need to start it right now, signet is of course easier to set up. Testnet is even easier and no software changes are needed to start mining on testnet right now. > _______________________________________________ > Cpuchain-dev mailing list -- cpuchain-dev(a)mailman3.com > To unsubscribe send an email to cpuchain-dev-leave(a)mailman3.com >

June 7, 2021

Re: Full Update to latest Bitcoin version, just pick interesting updates, or nothing?

by ricardcivil＠tuta.io

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(a)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(a)mailman3.com > To unsubscribe send an email to cpuchain-dev-leave(a)mailman3.com >

June 6, 2021

Re: Full Update to latest Bitcoin version, just pick interesting updates, or nothing?

by 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.

June 6, 2021

Re: Full Update to latest Bitcoin version, just pick interesting updates, or nothing?

by ricardcivil＠tuta.io

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(a)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(a)gmail.com Update build-unix.md > 8a4243a2 minkcrypto(a)gmail.com misc: change branding of cpupower > 1e58bcbc minkcrypto(a)gmail.com Update seeds > 77c68b45 minkcrypto(a)gmail.com Add additional rpc call support for ApiServer > f19e2ba9 minkcrypto(a)gmail.com Update README.md > 5d1cced8 minkcrypto(a)gmail.com Update README.md > c82cee8f minkcrypto(a)gmail.com CPUchain Core 0.18.1 > fa27a076 laanwj(a)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(a)mailman3.com > To unsubscribe send an email to cpuchain-dev-leave(a)mailman3.com >

June 6, 2021

Re: Full Update to latest Bitcoin version, just pick interesting updates, or nothing?

by 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(a)gmail.com Update build-unix.md 8a4243a2 minkcrypto(a)gmail.com misc: change branding of cpupower 1e58bcbc minkcrypto(a)gmail.com Update seeds 77c68b45 minkcrypto(a)gmail.com Add additional rpc call support for ApiServer f19e2ba9 minkcrypto(a)gmail.com Update README.md 5d1cced8 minkcrypto(a)gmail.com Update README.md c82cee8f minkcrypto(a)gmail.com CPUchain Core 0.18.1 fa27a076 laanwj(a)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.

June 6, 2021