Cpuchain-dev

Download

cpuchain-dev@mailman3.com

April 2021

3 participants
2 discussions

Activating signet with minimal difficulty
by garlonicon＠onet.pl April 18, 2021

April 18, 2021

We should skip testnet and activate signet, because it is better than testnet. Or, we could fix testnet bugs, for example "blockstorm bug", and then activate it. I think that signet with minimal difficulty 0x7fff...f will be enough for all test cases, because now mainnet difficulty is still quite close to minimal difficulty, so to test things quick, we should lower it, because then producing a lot of test blocks will be possible. Also, signing blocks will protect us from attacks. And to allow other users playing with signet coins, we could create some faucets.

3 2

Block size, sustainability and centralization implications
by ricardcivil＠tuta.io April 8, 2021

April 8, 2021

This post is to expose the current situation and begin the discussion about the block size as well to expose my opinion. Current Cpuchain's block size is 4000000000 Bytes for segwit and 1000000000 Bytes for those nodes that don't support segwit. This size affects to multiple sides of the protocol like the maximum amount of data to be stored and transmitted. Data storage and Network bandwidth are two aspects that could potentially affect to the decentralization of the network because they increase the cost of running a full node. This block size is part of Cpuchain's roadmap to achieve 80k transactions per second. From the original whitepaper: "As we believe in self-sustainable cryptocurrency that can last for more than hun-dred years, we take the scaling issue seriously and thus we’ve implemented a scaling solution that can cover up to 80K transactions per second, which exceeds current visa’s 50k tps capacity." As far as I have seen on the repository, the commit c82cee8 <https://github.com/cpuchain-core/cpuchain/commit/c82cee8f7d9dc44e75bf95470e…> only changes constant limits of block size, weight and sigops on consensus.h <https://github.com/cpuchain-core/cpuchain/commit/c82cee8f7d9dc44e75bf95470e…> and consensus.nPowTargetSpacing on chainparams.cpp <https://github.com/cpuchain-core/cpuchain/commit/c82cee8f7d9dc44e75bf95470e…>. While these limits will allow more transactions among other benefits, they will imply a huge bockchain size and a really big amount of bandwidth usage. cpuchain block size (disk and wire) nonSegwitBS 1000000000 Bytes 1GB segwitBS 4000000000 Bytes 4GB Worst cases block size: minsInDay = 1440 worstInDayNoSeg = nonSegwitBS * minsInDay = 1440000000000 Bytes 1.44TB worstInDaySeg = segwitBS * minsInDay = 5760000000000 Bytes 5.76TB worstInMonthNoSeg = nonSegwitBS * minsInDay * 30 = 4.32 * 10^13 Bytes 43.2TB worstInMonthSeg = segwitBS * minsInDay * 30 = 1.728 * 10^14 Bytes 173TB worstInYearNoSeg = nonSegwitBS * minsInDay * 365 = 5.256 * 10^14 Bytes 526TB worstInYearSeg = segwitBS * minsInDay * 365 = 2.102 * 10^15 Bytes 2.1PB As seen in hypothetical worst cases, in one day a nonsegwit node will require 1.44TB of both, storage and bandwidth. In a month the disk usage will increase in 43.2TB and in a year 526TB. Bandwidth and storage are only two of multiple sides direct or indirectly affected by the block size, we should not forget that these blocks will require more compute power to handle and process them. These facts increase the cost to maintain a full node and reduce the number of users whom can run it. This will be translated to a centralized network in nowdays, with current storage devices prices and network's common limits. In further reading I've linked some posts where block size limit is discussed, having it, of course, its pros and cons. On the other side, there are pros for this block size. A bigger number of total transaction fees, making mining more profitable (if not taking into account the costs of running a full node with these specs). This size allows more transactions per second, having a theoric capacity 10000 times bigger than bitcoin (cpuchain's block size is 1000 bigger and block time is 10 times smaller). ConclusionIn my opinion, I think that this block size isn't sustainable nor efficient with the current implementation. This size potentially makes Cpuchain more vulnerable to centralization. While there isn't any solution to handle storage and bandwidth requirements, I propose to reduce it to 1000000 Bytes for nonsegwit implementations and 4000000 Bytes for segwit implementations. Having a payment network 10x faster than bitcoin. Recall that off-chain solutions are a workaround to allow more tps. Which is your opinion about this topic? Further reading (not added in any specific order): https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki https://medium.com/segwit-co/why-a-discount-factor-of-4-why-not-2-or-8-bbce… https://en.bitcoinwiki.org/wiki/Block_size_limit_controversy https://bitcoin.stackexchange.com/questions/36085/what-are-the-arguments-fo… https://coinzodiac.com/bitcoin-block-size-argument/ https://en.bitcoin.it/wiki/Off-chain_transactions https://cpuchain.org/assets/v1.pdf https://bitcoin.stackexchange.com/questions/67760/how-are-sigops-calculated https://github.com/cpuchain-core/cpuchain/blob/master/src/consensus/consens… https://github.com/cpuchain-core/cpuchain/commit/c82cee8f7d9dc44e75bf95470e… -- Ricard Civil Sent with Tutanota, the secure & ad-free mailbox: https://tutanota.com

2 2