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

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

Testing network

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

May 16, 2021

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

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.

May 16, 2021

Peer Discovery: dns seeds and fallback hardcoded nodes

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

May 16, 2021

Initial block download time

by vjudeu＠gazeta.pl

I think this should be covered by some later update, after we complete upgrading to the newest Bitcoin Core version. Also, if some improvements are related to Bitcoin, they should be submitted there first, if they are only CPUchain-related, then they should be included in the end. In this way, we could get some feedback about our optimizations, as long as they are applicable also to Bitcoin.

May 16, 2021

Next Cpuchain Core release issues list

by ricardcivil＠tuta.io

Next relesase should be asap intended to fix known problems and improve the stability. Initial block download time Peer Discovery: dns seeds and fallback hardcoded nodes Full Update to latest Bitcoin version, just pick interesting updates, or nothing? Testing network To keep the conversation organized, this thread is only intended to discuss the above list and to propose the inclusion or removal of items from the above list. Each topic must be discussed in depth on its own separated thread. Best regards, -- Ricard Civil

May 16, 2021

Re: Taproot test sidechain

by ricardcivil＠tuta.io

I'm more in favor to test Taproot in a testing network like testnet or signet. I think that signet would be the better option. Using a sidechain implies real money. We must have a free of risks testing environment. We can solve the problems related with mining difficulty. Best regards, -- Ricard Civil 12 May 2021, 17:12 by vjudeu(a)gazeta.pl: > When I tried to create signet or testnet for CPUchain, I noticed one important problem: mining is difficult. The goal is to create a chain where everyone can get some test coins without anyone's permission. On the other hand, mining should not be too easy, because then the network would be much less secure. The solution I found is test sidechain. To create testnet block, you have to vote for or against taproot in your own block, in a BIP-9 or similar way (to be decided, but BIP-9 is now used on Bitcoin). But then, another problem comes in: that chain would have unlimited coin supply! To fix that, coins should be destroyed when they are moved on the mainchain. In this way, any miner can easily create some testnet coins while mining mainnet coins, just by voting for or against taproot in the block. On the other hand, testnet coins could be later deleted simply by moving coins in the mainnet. All testnet transactions would have Schnorr signatures and tapscript, so that publishing them o > n the mainnet would be impossible, unless such features would be activated, but even then having some coins for testing would be useful. And still, as long as non-taproot coins would be spent on testnet in a taproot-compatible way, both transaction chains should be safely separated. > > Also, as we talk about testnet, it is possible to introduce users to such network, simply by letting them spend their coins in more than one way. For example: if someone has some coins locked with some public key (hash), all that is needed is creating spending transaction with Schnorr signature. That transaction would be rejected on mainnet, but accepted on testnet sidechain. And later, any user can simply move mainchain coins and destroy all connected test coins in this way. But, as getting miners support is more important, I think we should stick with block signalling first, because Miner Activated Soft Fork would be safer than User Activated Soft Fork. > _______________________________________________ > Cpuchain-dev mailing list -- cpuchain-dev(a)mailman3.com > To unsubscribe send an email to cpuchain-dev-leave(a)mailman3.com >

May 16, 2021