- 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

Implementing Stratum v2 for CPUchain

by vjudeu＠gazeta.pl

For now, many miners are mining in pools and they have very low control over what blocks they mine. Stratum v2 is an attempt to decentralize mining. Solutions like P2Pool are not scalable in longer perspective, so probably something like Stratum v2 should be used. Of course we should focus on Taproot and similar issues first, but I think that kind of improvement will be needed sooner or later.

May 23, 2021

Re: Peer Discovery: dns seeds and fallback hardcoded nodes

by ricardcivil＠tuta.io

Yes, dns seeds to have a dynamic list of peers and also, hardcoded peers as a fallback. Adding them automatically will improve the discovery for new nodes, and node operators will not need to search for nodes to add manually. We need volunteers to run both, seeders and stable nodes reachable through a static ip, to add to the list. We must define a guidelines and a code of conduct for operators running those services, bitcoin's guidelines are good starting point. Best regards, -- Ricard Civil 16 May 2021, 10:46 by vjudeu(a)gazeta.pl: > As far as I know, everything that is needed is just adding server IP's or hostnames, so it could be added at any time and there should be no major problem with that. Also, some of such settings could be added just to the config file, so for some changes no software update is needed at all. More than that: nodes could be added or removed from the command line. > _______________________________________________ > Cpuchain-dev mailing list -- cpuchain-dev(a)mailman3.com > To unsubscribe send an email to cpuchain-dev-leave(a)mailman3.com >

May 19, 2021

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

by ricardcivil＠tuta.io

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

May 19, 2021

Re: Testing network

by garlonicon＠onet.pl

> Testnet is even easier and no software changes are needed to start mining on testnet right now. Exactly, feel free to type "addnode 46.41.151.240:29706 add" in console, it is my test server.

May 16, 2021