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

Re: Doing block header checking in parallel

by ricardcivil＠tuta.io

I am assuming that we are talking about the validation of the block header and not the whole block. Block headers need more contextual assumptions for example, but not limited to, timestamp correctness and nbits. For example checks that could be done in parallel, without the context, are the hash computation of the header and the validation that the hash is equal to or lower than the target encoded in nbits, this check must assume that the target value in the header in question is correct. Other non-contextual checks can be done in parallel. Best regards, -- Ricard Civil 13 May 2021, 06:02 by vjudeu(a)gazeta.pl: >> While the first can be easily done in parallel, the second type needs a more contextualized solution. Could you elaborate on the procedure? >> > > I think we should handle it in a similar way as in transaction verification. Having some chain of blocks A->B->C->D we can verify block D in one thread and block C in another thread. We can verify multiple blocks in parallel and as long as everything is ok, we would get a speedup. But: it is possible that block A is invalid, and then we should reject blocks B, C and D later. But assuming that bandwidth is not a bottleneck, we could for example allow downloading some data without checking everything and reject that later if needed. For example, if we have 4 threads, we could verify each four blocks separately and later join results from them. > > Having full context is not needed. For example: if we want to verify block D without checking previous blocks, we can assume that our transaction inputs are correct. We store that assumptions somewhere. Later, when block C verification ends, we can collect all UTXO's created in block C and match them with assumptions we made for block D. Of course it is possible that not all assumptions will be cleared, but after clearing all assumptions for some block, we could safely say that this block is valid. And if finally we would have all assumptions for all blocks cleared, then we would have everything validated. > > More than that: if there would be some long, but invalid chain, we could create SPV proofs for other nodes and share them, speeding up stale chains rejection even further. But to start with, block verification should be optimized. > _______________________________________________ > Cpuchain-dev mailing list -- cpuchain-dev(a)mailman3.com > To unsubscribe send an email to cpuchain-dev-leave(a)mailman3.com >

May 16, 2021

Re: Doing block header checking in parallel

by vjudeu＠gazeta.pl

> While the first can be easily done in parallel, the second type needs a more contextualized solution. Could you elaborate on the procedure? I think we should handle it in a similar way as in transaction verification. Having some chain of blocks A->B->C->D we can verify block D in one thread and block C in another thread. We can verify multiple blocks in parallel and as long as everything is ok, we would get a speedup. But: it is possible that block A is invalid, and then we should reject blocks B, C and D later. But assuming that bandwidth is not a bottleneck, we could for example allow downloading some data without checking everything and reject that later if needed. For example, if we have 4 threads, we could verify each four blocks separately and later join results from them. Having full context is not needed. For example: if we want to verify block D without checking previous blocks, we can assume that our transaction inputs are correct. We store that assumptions somewhere. Later, when block C verification ends, we can collect all UTXO's created in block C and match them with assumptions we made for block D. Of course it is possible that not all assumptions will be cleared, but after clearing all assumptions for some block, we could safely say that this block is valid. And if finally we would have all assumptions for all blocks cleared, then we would have everything validated. More than that: if there would be some long, but invalid chain, we could create SPV proofs for other nodes and share them, speeding up stale chains rejection even further. But to start with, block verification should be optimized.

May 13, 2021

Re: Doing block header checking in parallel

by ricardcivil＠tuta.io

Validating Block's headers in parallel will be faster, but it's more complex. There are two kinds of checks, non-contextual and contextual. While the first can be easily done in parallel, the second type needs a more contextualized solution. Could you elaborate on the procedure? Best regards, -- Ricard Civil 12 May 2021, 19:07 by vjudeu(a)gazeta.pl: > For now, all hashes are downloaded and validated one-by-one in a linear way. It is fast enough for coins like Bitcoin where sha256d is quite fast to calculate. But for CPUchain, we have cpupower, which is much more complicated. So, my proposal is to implement it in a different way, for example we could validate many hashes in many different threads and do that in parallel, as it is currently done for transactions. > _______________________________________________ > Cpuchain-dev mailing list -- cpuchain-dev(a)mailman3.com > To unsubscribe send an email to cpuchain-dev-leave(a)mailman3.com >

May 13, 2021

Doing block header checking in parallel

by vjudeu＠gazeta.pl

For now, all hashes are downloaded and validated one-by-one in a linear way. It is fast enough for coins like Bitcoin where sha256d is quite fast to calculate. But for CPUchain, we have cpupower, which is much more complicated. So, my proposal is to implement it in a different way, for example we could validate many hashes in many different threads and do that in parallel, as it is currently done for transactions.

May 12, 2021

Taproot test sidechain

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

May 12, 2021

Taproot activation on CPUchain

by vjudeu＠gazeta.pl

We should activate taproot on CPUchain. Users can show their support by using "cpu1qtapr00t" vanity addresses, it would work even if mining in pool, few days of mining with vanitygen is enough to get such address (there is vanitybech that generates "bc1qtapr00t", importing that key to CPUchain would give you "cpu1qtapr00t"). But that's about users and pool miners, we as developers should upgrade the core client to the latest version and start signalling. On bitcoin, there are now blocks voting for taproot, we should start doing it on our coin, too.

May 2, 2021