# FAQ - Bitcoin

• FAQ - Bitcoin
• Bitcoin Definition
• Bitcoin Mining Calculator - Updated with 2020 Miners
• How bitcoin works - Bitcoin Wiki
• Nonce - Bitcoin Wiki
##### Technical: Taproot: Why Activate?

This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
• You the HODLer should be the one who controls where your money goes. Your keys, your coins.
• You the HODLer should be able to coordinate and make contracts with other people regarding your funds.
• You the HODLer should be able to do the above without anyone watching over your shoulder and judging you.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

## Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
• Privacy. Everyone scraping the Bitcoin blockchain can see any HTLCs, and preimages used to claim them.
• This can be mitigated by using offchain techniques so HTLCs are never published onchain in the happy case. Lightning would probably in practice be the easiest way to do this offchain. Of course, there are practical limits to what you can pay on Lightning. If you are buying something expensive, then Lightning might not be practical. For example, the "software" you are activating is really the firmware of a car, and what you are buying is not the software really but the car itself (with the activation of the car firmware being equivalent to getting the car keys).
• Even offchain techniques need an onchain escape hatch in case of unresponsiveness! This means that, if something bad happens during payment, the HTLC might end up being published onchain anyway, revealing the fact that some special contract occurred.
• And an HTLC that is claimed with a preimage onchain will also publicly reveal the preimage onchain. If that preimage is really the activation key of a software than it can now be pirated. If that preimage is really the activation key for your newly-bought cryptographic car --- well, not your keys, not your car!
• Trust requirement. You are trusting the developer that it gives you the hash of an actual valid activation key, without any way to validate that the activation key hidden by the hash is actually valid.
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given public key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
• Privacy: PTLCs are private even if done onchain. Nobody else can learn what the private key behind the public key is, except you who knows the adaptor signature that when combined with the complete onchain signature lets you know what the private key of the activation key is. Somebody scraping the blockchain will not learn the same information even if all PTLCs are done onchain!
• Lightning is still useful for reducing onchain use, and will also get PTLCs soon after Taproot is activated, but even if something bad happens and a PTLC has to go onchain, it doesn't reveal anything!
• Trust issues can be proven more easily with a public-private keypair than with a hash-preimage pair.
• For example, the developer of the software you are buying could provide a signature signing a message saying "unlock access to the full version for 1 day". You can check if feeding this message and signature to the program will indeed unlock full-version access for 1 day. Then you can check if the signature is valid for the purported pubkey whose private key you will pay for. If so, you can now believe that getting the private key (by paying for it in a PTLC) would let you generate any number of "unlock access to the full version for 1 day" message+signatures, which is equivalent to getting full access to the software indefinitely.
• For the car, the manufacturer can show that signing a message "start the engine" and feeding the signature to the car's fimrware will indeed start the engine, and maybe even let you have a small test drive. You can then check if the signature is valid for the purported pubkey whose privkey you will pay for. If so, you can now believe that gaining knowledge of the privkey will let you start the car engine at any time you want.
• (pedantry: the signatures need to be unique else they could be replayed, this can be done with a challenge-response sequence for the car, where the car gathers entropy somehow (it's a car, it probably has a bunch of sensors nowadays so it can get entropy for free) and uses the gathered entropy to challenge you to sign a random number and only start if you are able to sign the random number; for the software, it could record previous signatures somewhere in the developer's cloud server and refuse to run if you try to replay a previously-seen signature.)
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

## Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
• Current quantum computers can barely crack prime factorization problem for primes of 5 bits.
• The 256-bit elliptic curve use by Bitcoin is, by my (possibly wrong) understanding, equivalent to 4096-bit primes, so you can see a pretty big gap between now (5 bit primes) and what is needed (4096 bit primes).
• A lot of financial non-Bitcoin systems use the equivalent of 3072-bit primes or less, and are probably easier targets to crack than the equivalent-to-4096-bit-primes Bitcoin.
So:
• Quantum computers capable of cracking Bitcoin are still far off.
• Pay-to-public-key-hash is not as protective as you might think.
• We will probably see banks get cracked before Bitcoin, so the banking system is a useful canary-in-a-coal-mine to see whether we should panic about being quantum vulnerable.
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

## Summary

• If you are a singlesig HODL-only Bitcoin user, Taproot will not affect you positively or negatively. Importantly: Taproot does no harm!
• If you use or intend to use multisig, Taproot will be a positive for you.
• If you transact onchain regularly using typical P2PKH/P2WPKH addresses, you get a minor reduction in feerates since multisig users will likely switch to Taproot to get smaller tx sizes, freeing up blockspace for yours.
• If you are using multiparticipant setups for special systems of trade, Taproot will be a positive for you.
• Remember: Lightning channels are multipartiicpiant setups for special systems of lightning-fast offchain trades!

## I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!
• If you have developer experience especially in C, C++, or related languages
• Review the Taproot code! There is one pull request in Bitcoin Core, and one in libsecp256k1. I deliberately am not putting links here, to avoid brigades of nontechnical but enthusiastic people leaving pointless reviews, but if you are qualified you know how to find them!
• But I am not a cryptographeBitcoin Core contributomathematician/someone as awesome as Pieter Wuille
• That's perfectly fine! The cryptographers have been over the code already and agree the math is right and the implementation is right. What is wanted is the dreary dreary dreary software engineering: are the comments comprehensive and understandable? no misspellings in the comments? variable names understandable? reasonable function naming convention? misleading coding style? off-by-one errors in loops? conditions not covered by tests? accidental mixups of variables with the same types? missing frees? read-before-init? better test coverage of suspicious-looking code? missing or mismatching header guards? portability issues? consistent coding style? you know, stuff any coder with a few years of experience in coding anything might be able to catch. With enough eyes all bugs are shallow!
• If you are running a mining pool/mining operation/exchange/custodial service/SPV server
• One of the typical issues with upgrading software is that subtle incompatibilities with your current custom programs tend to arise, disrupting operations and potentially losing income due to downtime. If so, consider moving to the two-node setup suggested by gmax, which is in the last section of my previous post. With this, you have an up-to-date "public" node and a fixed-version "private" node, with the public node protecting the private node from any invalid chainsplits or invalid transactions. Moving to this setup from a typical one-node setup should be smooth and should not disrupt operations (too much).
• If you are running your own fullnode for fun or for your own wallet
• Be prepared to upgrade! The more nodes validating the new rules (even if you are a non-mining node!), the safer every softfork will be!
• If you are using an SPV wallet or custodial wallet/service (including hardware wallets using the software of the wallet provider)
• Contact your wallet provider / SPV server and ask for a statement on whether they support Taproot, and whether they are prepared to upgrade for Taproot! Make it known to them that Taproot is something you want!

## But I Hate Taproot!!

That's fine!
• Raise your objections to Taproot now, or forever hold your peace! Maybe you can raise them here and some of the devs (probably nullc, he goes everywhere, even in rbtc!) might be able to see your objections! Or if your objections are very technical, head over to the appropriate pull request and object away!
• Maybe you simply misunderstand something, and we can clarify it here!
• Or maybe you do have a good objection, and we can make Taproot better by finding a solution for it!

##### [ Bitcoin ] Technical: Taproot: Why Activate?

###### Topic originally posted in Bitcoin by almkglor [link]
This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
• You the HODLer should be the one who controls where your money goes. Your keys, your coins.
• You the HODLer should be able to coordinate and make contracts with other people regarding your funds.
• You the HODLer should be able to do the above without anyone watching over your shoulder and judging you.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

## Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
• Privacy. Everyone scraping the Bitcoin blockchain can see any HTLCs, and preimages used to claim them.
• This can be mitigated by using offchain techniques so HTLCs are never published onchain in the happy case. Lightning would probably in practice be the easiest way to do this offchain. Of course, there are practical limits to what you can pay on Lightning. If you are buying something expensive, then Lightning might not be practical. For example, the "software" you are activating is really the firmware of a car, and what you are buying is not the software really but the car itself (with the activation of the car firmware being equivalent to getting the car keys).
• Even offchain techniques need an onchain escape hatch in case of unresponsiveness! This means that, if something bad happens during payment, the HTLC might end up being published onchain anyway, revealing the fact that some special contract occurred.
• And an HTLC that is claimed with a preimage onchain will also publicly reveal the preimage onchain. If that preimage is really the activation key of a software than it can now be pirated. If that preimage is really the activation key for your newly-bought cryptographic car --- well, not your keys, not your car!
• Trust requirement. You are trusting the developer that it gives you the hash of an actual valid activation key, without any way to validate that the activation key hidden by the hash is actually valid.
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given private key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
• Privacy: PTLCs are private even if done onchain. Nobody else can learn what the private key behind the public key is, except you who knows the adaptor signature that when combined with the complete onchain signature lets you know what the private key of the activation key is. Somebody scraping the blockchain will not learn the same information even if all PTLCs are done onchain!
• Lightning is still useful for reducing onchain use, and will also get PTLCs soon after Taproot is activated, but even if something bad happens and a PTLC has to go onchain, it doesn't reveal anything!
• Trust issues can be proven more easily with a public-private keypair than with a hash-preimage pair.
• For example, the developer of the software you are buying could provide a signature signing a message saying "unlock access to the full version for 1 day". You can check if feeding this message and signature to the program will indeed unlock full-version access for 1 day. Then you can check if the signature is valid for the purported pubkey whose private key you will pay for. If so, you can now believe that getting the private key (by paying for it in a PTLC) would let you generate any number of "unlock access to the full version for 1 day" message+signatures, which is equivalent to getting full access to the software indefinitely.
• For the car, the manufacturer can show that signing a message "start the engine" and feeding the signature to the car's fimrware will indeed start the engine, and maybe even let you have a small test drive. You can then check if the signature is valid for the purported pubkey whose privkey you will pay for. If so, you can now believe that gaining knowledge of the privkey will let you start the car engine at any time you want.
• (pedantry: the signatures need to be unique else they could be replayed, this can be done with a challenge-response sequence for the car, where the car gathers entropy somehow (it's a car, it probably has a bunch of sensors nowadays so it can get entropy for free) and uses the gathered entropy to challenge you to sign a random number and only start if you are able to sign the random number; for the software, it could record previous signatures somewhere in the developer's cloud server and refuse to run if you try to replay a previously-seen signature.)
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

## Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
• Current quantum computers can barely crack prime factorization problem for primes of 5 bits.
• The 256-bit elliptic curve use by Bitcoin is, by my (possibly wrong) understanding, equivalent to 4096-bit primes, so you can see a pretty big gap between now (5 bit primes) and what is needed (4096 bit primes).
• A lot of financial non-Bitcoin systems use the equivalent of 3072-bit primes or less, and are probably easier targets to crack than the equivalent-to-4096-bit-primes Bitcoin.
So:
• Quantum computers capable of cracking Bitcoin are still far off.
• Pay-to-public-key-hash is not as protective as you might think.
• We will probably see banks get cracked before Bitcoin, so the banking system is a useful canary-in-a-coal-mine to see whether we should panic about being quantum vulnerable.
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

## Summary

• If you are a singlesig HODL-only Bitcoin user, Taproot will not affect you positively or negatively. Importantly: Taproot does no harm!
• If you use or intend to use multisig, Taproot will be a positive for you.
• If you transact onchain regularly using typical P2PKH/P2WPKH addresses, you get a minor reduction in feerates since multisig users will likely switch to Taproot to get smaller tx sizes, freeing up blockspace for yours.
• If you are using multiparticipant setups for special systems of trade, Taproot will be a positive for you.
• Remember: Lightning channels are multipartiicpiant setups for special systems of lightning-fast offchain trades!

## I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!
• If you have developer experience especially in C, C++, or related languages
• Review the Taproot code! There is one pull request in Bitcoin Core, and one in libsecp256k1. I deliberately am not putting links here, to avoid brigades of nontechnical but enthusiastic people leaving pointless reviews, but if you are qualified you know how to find them!
• But I am not a cryptographeBitcoin Core contributomathematician/someone as awesome as Pieter Wuille
• That's perfectly fine! The cryptographers have been over the code already and agree the math is right and the implementation is right. What is wanted is the dreary dreary dreary software engineering: are the comments comprehensive and understandable? no misspellings in the comments? variable names understandable? reasonable function naming convention? misleading coding style? off-by-one errors in loops? conditions not covered by tests? accidental mixups of variables with the same types? missing frees? read-before-init? better test coverage of suspicious-looking code? missing or mismatching header guards? portability issues? consistent coding style? you know, stuff any coder with a few years of experience in coding anything might be able to catch. With enough eyes all bugs are shallow!
• If you are running a mining pool/mining operation/exchange/custodial service/SPV server
• One of the typical issues with upgrading software is that subtle incompatibilities with your current custom programs tend to arise, disrupting operations and potentially losing income due to downtime. If so, consider moving to the two-node setup suggested by gmax, which is in the last section of my previous post. With this, you have an up-to-date "public" node and a fixed-version "private" node, with the public node protecting the private node from any invalid chainsplits or invalid transactions. Moving to this setup from a typical one-node setup should be smooth and should not disrupt operations (too much).
• If you are running your own fullnode for fun or for your own wallet
• Be prepared to upgrade! The more nodes validating the new rules (even if you are a non-mining node!), the safer every softfork will be!
• If you are using an SPV wallet or custodial wallet/service (including hardware wallets using the software of the wallet provider)
• Contact your wallet provider / SPV server and ask for a statement on whether they support Taproot, and whether they are prepared to upgrade for Taproot! Make it known to them that Taproot is something you want!

## But I Hate Taproot!!

That's fine!
• Raise your objections to Taproot now, or forever hold your peace! Maybe you can raise them here and some of the devs (probably nullc, he goes everywhere, even in rbtc!) might be able to see your objections! Or if your objections are very technical, head over to the appropriate pull request and object away!
• Maybe you simply misunderstand something, and we can clarify it here!
• Or maybe you do have a good objection, and we can make Taproot better by finding a solution for it!

###### almkglor your post has been copied because one or more comments in this topic have been removed. This copy will preserve unmoderated topic. If you would like to opt-out, please send a message using [this link].
[deleted comment]
[deleted comment]
[deleted comment]

The fundamental divide in trading revolves around the question of market structure. Many feel that the market operates totally randomly and its’ behavior cannot be predicted. For the purposes of this article, we will assume that the market has a structure, but that that structure is not perfect. That market structure naturally generates chart patterns as the market records prices in time. In order to determine when the stock market will crash, causing a major decline in BTC price, we will analyze an instrument, an exchange traded fund, which represents an index, as opposed to a particular stock. The price patterns of the various stocks in an index are effectively smoothed out. In doing so, a more technical picture arises. Perhaps the most popular of these is the SPDR S&P Standard and Poor 500 Exchange Traded Fund ($SPY). In trading, little to no concern is given about value of underlying asset. We are concerned primarily about liquidity and trading ranges, which are the amount of value fluctuating on a short-term basis, as measured by volatility-implied trading ranges. Fundamental analysis plays a role, however markets often do not react to real-world factors in a logical fashion. Therefore, fundamental analysis is more appropriate for long-term investing. The fundamental derivatives of a chart are time (x-axis) and price (y-axis). The primary technical indicator is price, as everything else is lagging in the past. Price represents current asking price and incorrectly implementing positions based on price is one of the biggest trading errors. Markets and currencies ordinarily have noise, their tendency to back-and-fill, which must be filtered out for true pattern recognition. That noise does have a utility, however, in allowing traders second chances to enter favorable positions at slightly less favorable entry points. When you have any market with enough liquidity for historical data to record a pattern, then a structure can be divined. The market probes prices as part of an ongoing price-discovery process. Market technicians must sometimes look outside of the technical realm and use visual inspection to ascertain the relevance of certain patterns, using a qualitative eye that recognizes the underlying quantitative nature Markets and instruments rise slower than they correct, however they rise much more than they fall. In the same vein, instruments can only fall to having no worth, whereas they could theoretically grow infinitely and have continued to grow over time. Money in a fiat system is illusory. It is a fundamentally synthetic instrument which has no intrinsic value. Hence, the recent seemingly illogical fluctuations in the market. According to trade theory, the unending purpose of a market or instrument is to create and break price ranges according to the laws of supply and demand. We must determine when to trade based on each market inflection point as defined in price and in time as opposed to abandoning the trend (as the contrarian trading in this sub often does). Time and Price symmetry must be used to be in accordance with the trend. When coupled with a favorable risk to reward ratio, the ability to stay in the market for most of the defined time period, and adherence to risk management rules; the trader has a solid methodology for achieving considerable gains. We will engage in a longer term market-oriented analysis to avoid any time-focused pressure. The Bitcoin market is open twenty-four-hours a day, so trading may be done when the individual is ready, without any pressing need to be constantly alert. Let alone, we can safely project months in advance with relatively high accuracy. Bitcoin is an asset which an individual can both trade and invest, however this article will be focused on trading due to the wide volatility in BTC prices over the short-term. ## Technical Indicator Analysis of Bitcoin Technical indicators are often considered self-fulfilling prophecies due to mass-market psychology gravitating towards certain common numbers yielded from them. They are also often discounted when it comes to BTC. That means a trader must be especially aware of these numbers as they can prognosticate market movements. Often, they are meaningless in the larger picture of things. • Volume – derived from the market itself, it is mostly irrelevant. The major problem with volume for stocks is that the US market open causes tremendous volume surges eradicating any intrinsic volume analysis. This does not occur with BTC, as it is open twenty-four-seven. At major highs and lows, the market is typically anemic. Most traders are not active at terminal discretes (peaks and troughs) because of levels of fear. Volume allows us confidence in time and price symmetry market inflection points, if we observe low volume at a foretold range of values. We can rationalize that an absolute discrete is usually only discovered and anticipated by very few traders. As the general market realizes it, a herd mentality will push the market in the direction favorable to defending it. Volume is also useful for swing trading, as chances for swing’s validity increases if an increase in volume is seen on and after the swing’s activation. Volume is steadily decreasing. Lows and highs are reached when volume is lower. Therefore, due to the relatively high volume on the 12th of March, we can safely determine that a low for BTC was not reached. • VIX – Volatility Index, this technical indicator indicates level of fear by the amount of options-based “insurance” in portfolios. A low VIX environment, less than 20 for the S&P index, indicates a stable market with a possible uptrend. A high VIX, over 20, indicates a possible downtrend. VIX is essentially useless for BTC as BTC-based options do not exist. It allows us to predict the market low for$SPY, which will have an indirect impact on BTC in the short term, likely leading to the yearly low. However, it is equally important to see how VIX is changing over time, if it is decreasing or increasing, as that indicates increasing or decreasing fear. Low volatility allows high leverage without risk or rest. Occasionally, markets do rise with high VIX.
As VIX is unusually high, in the forties, we can be confident that a downtrend for the S&P 500 is imminent.
• RSI (Relative Strength Index): The most important technical indicator, useful for determining highs and lows when time symmetry is not availing itself. Sometimes analysis of RSI can conflict in different time frames, easiest way to use it is when it is at extremes – either under 30 or over 70. Extremes can be used for filtering highs or lows based on time-and-price window calculations. Highly instructive as to major corrective clues and indicative of continued directional movement. Must determine if longer-term RSI values find support at same values as before. It is currently at 73.56.
• Secondly, RSI may be used as a high or low filter, to observe the level that short-term RSI reaches in counter-trend corrections. Repetitions based on market movements based on RSI determine how long a trade should be held onto. Once a short term RSI reaches an extreme and stay there, the other RSI’s should gradually reach the same extremes. Once all RSI’s are at extreme highs, a trend confirmation should occur and RSI’s should drop to their midpoint.

## Trend Definition Analysis of Bitcoin

Trend definition is highly powerful, cannot be understated. Knowledge of trend logic is enough to be a profitable trader, yet defining a trend is an arduous process. Multiple trends coexist across multiple time frames and across multiple market sectors. Like time structure, it makes the underlying price of the instrument irrelevant. Trend definitions cannot determine the validity of newly formed discretes. Trend becomes apparent when trades based in counter-trend inflection points continue to fail.
Downtrends are defined as an instrument making lower lows and lower highs that are recurrent, additive, qualified swing setups. Downtrends for all instruments are similar, except forex. They are fast and complete much quicker than uptrends. An average downtrend is 18 months, something which we will return to. An uptrend inception occurs when an instrument reaches a point where it fails to make a new low, then that low will be tested. After that, the instrument will either have a deep range retracement or it may take out the low slightly, resulting in a double-bottom. A swing must eventually form.
A simple way to roughly determine trend is to attempt to draw a line from three tops going upwards (uptrend) or a line from three bottoms going downwards (downtrend). It is not possible to correctly draw a downtrend line on the BTC chart, but it is possible to correctly draw an uptrend – indicating that the overall trend is downwards. The only mitigating factor is the impending stock market crash.

## Time Symmetry Analysis of Bitcoin

Time is the movement from the past through the present into the future. It is a measurement in quantified intervals. In many ways, our perception of it is a human construct. It is more powerful than price as time may be utilized for a trade regardless of the market inflection point’s price. Were it possible to perfectly understand time, price would be totally irrelevant due to the predictive certainty time affords. Time structure is easier to learn than price, but much more difficult to apply with any accuracy. It is the hardest aspect of trading to learn, but also the most rewarding.
Humans do not have the ability to recognize every time window, however the ability to define market inflection points in terms of time is the single most powerful trading edge. Regardless, price should not be abandoned for time alone. Time structure analysis It is inherently flawed, as such the markets have a fail-safe, which is Price Structure. Even though Time is much more powerful, Price Structure should never be completely ignored. Time is the qualifier for Price and vice versa. Time can fail by tricking traders into counter-trend trading.
Time is a predestined trade quantifier, a filter to slow trades down, as it allows a trader to specifically focus on specific time windows and rest at others. It allows for quantitative measurements to reach deterministic values and is the primary qualifier for trends. Time structure should be utilized before price structure, and it is the primary trade criterion which requires support from price. We can see price structure on a chart, as areas of mathematical support or resistance, but we cannot see time structure.
Time may be used to tell us an exact point in the future where the market will inflect, after Price Theory has been fulfilled. In the present, price objectives based on price theory added to possible future times for market inflection points give us the exact time of market inflection points and price.
Time Structure is repetitions of time or inherent cycles of time, occurring in a methodical way to provide time windows which may be utilized for inflection points. They are not easily recognized and not easily defined by a price chart as measuring and observing time is very exact. Time structure is not a science, yet it does require precise measurements. Nothing is certain or definite. The critical question must be if a particular approach to time structure is currently lucrative or not.
We will measure it in intervals of 180 bars. Our goal is to determine time windows, when the market will react and when we should pay the most attention. By using time repetitions, the fact that market inflection points occurred at some point in the past and should, therefore, reoccur at some point in the future, we should obtain confidence as to when SPY will reach a market inflection point. Time repetitions are essentially the market’s memory. However, simply measuring the time between two points then trying to extrapolate into the future does not work. Measuring time is not the same as defining time repetitions. We will evaluate past sessions for market inflection points, whether discretes, qualified swings, or intra-range. Then records the times that the market has made highs or lows in a comparable time period to the future one seeks to trade in.
What follows is a time Histogram – A grouping of times which appear close together, then segregated based on that closeness. Time is aligned into combined histogram of repetitions and cycles, however cycles are irrelevant on a daily basis. If trading on an hourly basis, do not use hours.
• Yearly Lows (last seven years): 1/1/13, 4/10/14, 1/15/15, 1/17/16, 1/1/17, 12/15/18, 2/6/19
• Monthly Mode: 1, 1, 1, 1, 2, 4, 12
• Daily Mode: 1, 1, 6, 10, 15, 15, 17
• Monthly Lows (for the last year): 3/12/20 (10:00pm), 2/28/20 (7:09am), 1/2/20 (8:09pm), 12/18/19 (8:00am), 11/25/19 (1:00am), 10/24/19 (2:59am), 9/30/19 (2:59am), 8/29,19 (4:00am), 7/17/19 (7:59am), 6/4/19 (5:59pm), 5/1/19 (12:00am), 4/1/19 (12:00am)
• Daily Lows Mode for those Months: 1, 1, 2, 4, 12, 17, 18, 24, 25, 28, 29, 30
• Hourly Lows Mode for those Months (Military time): 0100, 0200, 0200, 0400, 0700, 0700, 0800, 1200, 1200, 1700, 2000, 2200
• Minute Lows Mode for those Months: 00, 00, 00, 00, 00, 00, 09, 09, 59, 59, 59, 59
• Day of the Week Lows (last twenty-six weeks):
Weighted Times are repetitions which appears multiple times within the same list, observed and accentuated once divided into relevant sections of the histogram. They are important in the presently defined trading time period and are similar to a mathematical mode with respect to a series. Phased times are essentially periodical patterns in histograms, though they do not guarantee inflection points
Evaluating the yearly lows, we see that BTC tends to have its lows primarily at the beginning of every year, with a possibility of it being at the end of the year. Following the same methodology, we get the middle of the month as the likeliest day. However, evaluating the monthly lows for the past year, the beginning and end of the month are more likely for lows.
Therefore, we have two primary dates from our histogram.
1/1/21, 1/15/21, and 1/29/21
2:00am, 8:00am, 12:00pm, or 10:00pm
In fact, the high for this year was February the 14th, only thirty days off from our histogram calculations.
The 8.6-Year Armstrong-Princeton Global Economic Confidence model states that 2.15 year intervals occur between corrections, relevant highs and lows. 2.15 years from the all-time peak discrete is February 9, 2020 – a reasonably accurate depiction of the low for this year (which was on 3/12/20). (Taking only the Armstrong model into account, the next high should be Saturday, April 23, 2022). Therefore, the Armstrong model indicates that we have actually bottomed out for the year!
Bear markets cannot exist in perpetuity whereas bull markets can. Bear markets will eventually have price objectives of zero, whereas bull markets can increase to infinity. It can occur for individual market instruments, but not markets as a whole. Since bull markets are defined by low volatility, they also last longer. Once a bull market is indicated, the trader can remain in a long position until a new high is reached, then switch to shorts. The average bear market is eighteen months long, giving us a date of August 19th, 2021 for the end of this bear market – roughly speaking. They cannot be shorter than fifteen months for a central-bank controlled market, which does not apply to Bitcoin. (Otherwise, it would continue until Sunday, September 12, 2021.) However, we should expect Bitcoin to experience its’ exponential growth after the stock market re-enters a bull market.
Terry Laundy’s T-Theory implemented by measuring the time of an indicator from peak to trough, then using that to define a future time window. It is similar to an head-and-shoulders pattern in that it is the process of forming the right side from a synthetic technical indicator. If the indicator is making continued lows, then time is recalculated for defining the right side of the T. The date of the market inflection point may be a price or indicator inflection date, so it is not always exactly useful. It is better to make us aware of possible market inflection points, clustered with other data. It gives us an RSI low of May, 9th 2020.
The Bradley Cycle is coupled with volatility allows start dates for campaigns or put options as insurance in portfolios for stocks. However, it is also useful for predicting market moves instead of terminal dates for discretes. Using dates which correspond to discretes, we can see how those dates correspond with changes in VIX.
Therefore, our timeline looks like:
• 2/14/20 – yearly high ($10372 USD) • 3/12/20 – yearly low thus far ($3858 USD)
• 5/9/20 – T-Theory true yearly low (BTC between 4863 and 3569)
• 5/26/20 – hashrate difficulty halvening
• 11/14/20 – stock market low
• 1/15/21 – yearly low for BTC, around $8528 • 8/19/21 – end of stock bear market • 11/26/21 – eighteen months from halvening, average peak from halvenings (BTC begins rising from$3000 area to above $23,312) • 4/23/22 – all-time high Taken from my blog: http://aliamin.info/2020/ submitted by aibnsamin1 to Bitcoin [link] [comments] ##### Epic Cash AMA Recap with CryptoDiffer Community CryptoDiffer team Hello, everyone! We are glad to meet here: Max Freeman (@maxfreeman4), Project Lead at Epic Cash Yoga Dude (@Yogadude), PR&Marketing at Epic Cash Xenolink (@Xenolink), Advisor at Epic Cash Max Freeman Project Lead at Epic Cash Thanks Max, we are excited to be here! Yoga Dude PR&Marketing at Epic Cash Hello Everyone! Thank you for having us here! Xenolink Advisor at Epic Cash Thank you to the CryptoDiffer team and CryptoDiffer community for hosting us! CryptoDiffer team Let`s start from the first introduction question: Q1: Can you introduce yourself to the community? What is your background and how did you join Epic Cash? Yoga Dude PR&Marketing at Epic Cash Hello! My background is Marketing and Business Development, I’ve been in crypto since 2011 started with Bitcoin, then Monero in 2014, Ethereum in 2015 and at some point Doge for fun and profit. I joined Epic Cash team in September 2019 handling PR and Marketing. I saw in Epic Cash what was missing in my previous cryptos — things that were missing in Bitcoin and Monero especially. Xenolink Advisor at Epic Cash Hello Cryptodiffer Community, I am not an original co-founder nor am I a developer for the Epic Cash project. I am however a community member that is involved in helping scale this project to higher levels. One of the many beauties of Epic Cash is that every single member in the community has the opportunity to be part of EPIC’s team, it can be from development all the way to content producing. Epic Cash is a community driven project. The true Core Team of Epic Cash is our community. I believe a community that is the Core Team is truly powerful. EPIC Cash has one of the freshest and strongest communities I have seen in quite a while. Which is one of the reasons why I became involved in this project. Epic displayed some of the most self community produced content I have seen in a project. I’m actually a doctor of medicine but in terms of my experience in crypto, I have been involved in the industry since 2012 beginning with mining Litecoin. Since then I have been doing deep dive analysis on different projects, investing, and building a network in crypto that I will utilize to help connect and scale Epic in every way I can. To give some credit to those people in my network that have been a part of helping give Epic exposure, I would like to give a special thanks to u/Tetsugan and u/Saurabhblr. Tetsugan has been doing a lot of work for the Japanese community to penetrate the Japanese market, and Japan has already developed a growing interest in Epic. Daku Sarabh the owner and creator of Crypto Daku Robinhooders, I would like to thank him and his community for giving us one of our first large AMA’s, which he has supported our project early and given us a free AMA. Many more to thank but can’t be disclosed. Also thank you to all the Epic Community leaders, developers, and Content producers! Max Freeman Project Lead at Epic Cash I’m Max Freeman, which stands for “Maximum Freedom for Mankind”. I started working on the ideas that would become Epic in 2018. I fell in love with Bitcoin in 2017 but realized that it needs privacy at the base layer, fungibility, better scalability in order to go to the next level. CryptoDiffer team Really interesting backgrounds I must admit, pleasure to see the team that clearly has one vision of the project by being completely decentralized:) Q2: Can you briefly describe what is Epic Cash in 3–5 sentences? What technology stands behind Epic Cash and why it’s better than the existing one? Max Freeman Project Lead at Epic Cash I’d like to highlight the differences between Epic and the two highest-valued privacy coin projects, Monero and Zcash. XMR has always-on privacy like Epic does, but at a cost: Its blockchain is over 20x more data intensive than Epic, which limits its possibilities for scalability. Epic’s blockchain is small and light enough to run a full node on cell phones, something that is in our product road map. ZEC by comparison can’t run on low end devices because of its zero knowledge based approach, and only 1% of transactions are fully private. Epic is simply newer, more advanced technology than prior networks thanks to Mimblewimble We will also add more algorithms to widen the range of hardware that can participate in mining. For example, cell phones and tablets based around ARM chips. Millions of people can mine Epic that can’t mine Bitcoin, and that will help grow the network rapidly. There are some great short videos on our YouTube channel https://www.youtube.com/channel/UCQBFfksJlM97rgrplLRwNUg/videos that explain why we believe we have created something truly special here. Our core architecture derives from Grin, so we are fortunate to benefit on an ongoing basis from their considerable development efforts. We are focused on making our currency truly usable and widely available, beyond a store of value and becoming a true medium of exchange. Yoga Dude PR&Marketing at Epic Cash Well we all have our views, but in a nutshell, we offer things that were missing in the previous cryptos. We have sound fiscal emission schedule matching Bitcoin, but we are vastly more private and faster. Our blockchain is lighter than Bitcoin or Monero and our tech is more scalable. Also, we are unique in that we are mineable with CPUs and GPUs as well as ASICs, giving the broadest population the ability to mine Epic Cash. Plus, you can’t forget FUNGIBILITY 🙂 we are big on that — since you can’t have true privacy without fungibility. Also, please understand, we have HUGE respect to all the cryptos that came before us, we learned a lot from them, and thanks to their mistakes we evolved. Xenolink Advisor at Epic Cash To add on, what also makes Epic Cash unique is the ability to decentralize the mining using a tri-algo model of Random X (CPU), Progpow (GPU), and Cuckoo (ASIC) for an ability to do hybrid mining. I believe this is an issue we can see today in Bitcoin having centralized mining and the average user has a costly barrier of entry. To follow up on this one in my opinion one of the things we adopted that we have seen success for , in example Bitcoin and Monero, is a strong community driven coin. I believe having a community driven coin will provide a more organic atmosphere especially when starting with No ICO, or Premine with a fair distribution model for everyone. CryptoDiffer team Q3: What are the major milestones Epic Cash has achieved so far? Maybe you can share with us some exciting plans for future weeks/months? Yoga Dude PR&Marketing at Epic Cash Since we went live in September of 2019, we attracted a very large community of users, miners, investors and contributors from across the world. Epic Cash is a very international project with white papers translated into over 30 languages. We are very much a community driven project; this is very evident from our content and the amount of translations in our white papers and in our social media content. We are constantly working on improving our usability, security and privacy, as well as getting our message and philosophy out into the world to achieve mass adoption. We have a lot of exciting plans for our project, the plan is to make Epic Cash into something that is More than Money. You can tell I am the Marketing guy since my message is less about the actual tech and more about the usability and use cases for Epic Cash, I think our Team and Community have a great mix of technical, practical, social and fiscal experiences. Since we opened our YouTube channels content for community submissions, we have seen our content translated into Spanish, French, German, Polish, Chinese, Japanese, Arabic, Russian, and other languages Max Freeman Project Lead at Epic Cash Our future development roadmap will be published soon and includes 4 tracks: Usability Mining Core Protocol Ecosystem Development Core Protocol Epic Server 2.9.0 — this release improves the difficulty adjustment and is aimed at making block emission closer to the target 60 seconds, particularly reducing the incidence of extremely short and long blocks — Status: In Development (Testing) Anticipated Release: June 2020 Epic Server 3.0.0 — this completes the rebase to Grin 3.0.0 and serves as the prerequisite to some important functional building blocks for the future of the ecosystem. Specifically, sending via Tor (which eliminates the need to open ports), proof of payment (useful for certain dex applications e.g. Bisq), and our native mobile app. Status: In Development (Testing) Anticipated Release: Fall 2020 Non-Interactive Transactions — this will enhance usability by enabling “fire and forget” send-to-address functionality that users are accustomed to from most cryptocurrencies. Status: Drawing Board Anticipated Release: n/a Scaling Options — when blocks start becoming full, how will we increase capacity? Two obvious options are increasing the block size, as well as a Lightning Network-style Layer 2 structure. Status: Drawing Board Anticipated Release: n/a Confidential Assets — Similar to Raven, Tari, and Beam, the ability to create independently tradable assets that ride on the Epic Blockchain. Status: Drawing Board Anticipated Release: n/a Usability GUI Wallet 2.0 — Restore from seed words and various usability enhancements — Status: Needs Assessment Anticipated Release: Fall 2020 Mobile App — Native mobile experience for iOS and Android. Status: In Development (Testing) Anticipated Release: Winter 2020 Telegram Integration — Anonymous payments over the Telegram network, bot functionality for groups. Status: Drawing Board Anticipated Release: n/a Mining RandomX on ARM — Our 4th PoW algorithm, this will enable tablets, cell phones, and low power devices such as Raspberry Pi to participate in mining. Status: Needs Assessment Anticipated Release: n/a The economics of mining Epic are extremely compelling for countries that have free or extremely cheap electricity, since anyone with an ordinary PC can mine. Individual people around the world can simply run the miner and earn meaningful money (imagine Venezuela for example), something that has not been possible since the very early days of Bitcoin. Ecosystem Development Atomic Swaps — Connecting Epic to other blockchains in a trustless way, starting with ETH so that Epic can trade on DeFi infrastructure such as Uniswap, Kyber, etc. Status: Drawing Board Anticipated Release: n/a Xenolink Advisor at Epic Cash From the Community aspect, we have been further developing our community international reach. We have been seeing an increase in interest from South America, China, Russia, Japan, Italy, and the Philippines. We are working on targeting more countries. We truly aim to be a decentralized project that is open to everyone worldwide. CryptoDiffer team Great, thank you for your answers, we now can move to community questions part! Cryptodiffer Community You have 3 mining algorithms, the question is: how do they not compete with each other? Is there any benefit of mining on the GPU and CPU if someone is mining on the ASIC? Max Freeman Project Lead at Epic Cash The block selection is deterministic, so that every 100 blocks, 60% are for RandomX (CPU), 38% for ProgPow (GPU), and 2% for Cuckoo (ASIC) — the policy is flexible so that we can have as many algorithms with any percentages we want. The goal is to make the most decentralized and resilient network possible, and with that in mind we are excited to work on enabling tablets and cell phones to mine, since that opens it up to millions of people that otherwise can’t take part. Cryptodiffer Community To Run a project smoothly, Funding is very important, From where does the Funding/revenue come from? Xenolink Advisor at Epic Cash Yes, early on this was realized and in order to scale a project funds are indeed needed. Epic Cash did not start with any funding and no ICO and was organically genesis mined with no pre-mine. Epic cash is also a nonprofit community driven project similar to Monero. There is no profit-driven entity in the picture. To overcome the revenue issue Epic Cash setup a development fund tax that decreases 1% every year until 2028 when Epic Cash reaches singularity with Bitcoin emissions. Currently it is at 7.77%. This will help support the scaling of the project. Cryptodiffer Community Hi! In your experience working also with MONERO can you please clarify which are those identified problems that EPIC CASH aims to develop and resolve? What’s the main advantage that EPIC CASH has over MONERO? Thank you! Yoga Dude PR&Marketing at Epic Cash First, I must admit that I am still a huge fan and HODLer of Monero. That said: ✅ our blockchain is MUCH lighter than Monero’s ✅ our transaction processing speed is much faster ✅ our address-less blockchain is more private ✅ Epic Cash can be mined with CPU (RandomX) GPU (ProgPow) and Cuckoo, whereas Monero migrated to RandomX and currently only mineable with CPU Cryptodiffer Community 1. the feature ‘Cut Through’ deletes old data, how is it decided which data will be deletes, and what are the consequences of it for the platform and therefore the users? 2. On your website I see links to download Epic wallet and mining software for Linux,Windows and MacOs, I am a user of android, is there a version for me, or does it have a release date? Max Freeman Project Lead at Epic Cash 1. This is one of the most exciting features of Mimblewimble, which is its extraordinary ability to compress blockchain data. In Bitcoin, the entire history of a coin must be replayed every time it is spent, and comprehensive details are permanently stored in the blockchain. Epic discards spent transaction inputs and consolidates outputs, storing neither addresses or amounts, only a tiny kernel to allow sender and receiver to prove their transaction. 2. The Vitex mobile app is great for today, and we have a native mobile app for iOS and Android in the works as well. Cryptodiffer Community$EPIC Have total Supply of 21,000,000 EPIC , is there any burning plan? Or Buyback program to maintain $EPIC price in the future? Who is Epic Biggest competitors? And what’s makes epic better than competitors? Xenolink Advisor at Epic Cash We respect the older generation coins like Bitcoin. But we have learned that the supply economics of Bitcoin is very sound. Until today we can witness how the Bitcoin is being adopted institutionally and by retail. We match the 21 million BTC supply economics because it is an inelastic fixed model which makes the long-term economics very sound. To have an elastic model of burning tokens or printing tokens will not have a solid economic future. Take for example the USD which is an inflating supply. In terms of competitors we look at everyone in crypto with respect and also learn from everyone. If we had to compare to other Mimblewimble tech coins, Grin is an inelastic forever inflating supply which in the long term is not sound economics. Beam however is an inelastic model but is formed as a corporation. The fair distribution is not there because of the permanent revenue model setup for them. Epic Cash a non-profit development tax fund model for scaling purposes that will disappear by 2028’s singularity. Cryptodiffer Community What your plans in place for global expansion, are you focusing on only market at this time? Or focus on building and developing or getting customers and users, or partnerships? Yoga Dude PR&Marketing at Epic Cash Since we are a community project, we have many developers, in addition to the core team. Our plans for Global expansion are simple — we have advocates in different regions addressing their audiences in their native languages. We are growing organically, by explaining our ideology and usability. The idea is to grow beyond needing a fiat bridge for crypto use, but to rather replace fiat with our borderless, private and fungible crypto so people can use it to get goods and services without using banks. We are not limiting ourselves to one particular demographic — Epic Cash is a valid solution for the gamers, investors, techie and non techie people, and the unbanked. Cryptodiffer Community EPIC confidential coin! Did you have any problems with the regulators? And there will be no problems with listing on centralized exchanges? Xenolink Advisor at Epic Cash In terms of structure, we are carefully set up to minimize these concerns. Without a company or investors in the picture, and having raised no funds, there is little scope to attack in terms of securities laws. Bitcoin and Ethereum are widely acknowledged as acceptable, and we follow in their well-established footprints in that respect. Centralized exchanges already trade other privacy coins, so we don’t see this as much of an issue either. In general, decentralized p2p exchange options are more interesting than today’s centralized platforms. They are more censorship resistant, secure, and privacy-protecting. As the technology gets better, they should continue to gain market share and that’s why we’re proud to be partnered with Vitex, whose exchange and mobile app work very well. Cryptodiffer Community What are the main utility and real-life usage of the #EPIC As an investor, why should we invest in the #EPIC project as a long-term investment? Max Freeman Project Lead at Epic Cash Because our blockchain is so light (only 1.16gb currently, and grows very slowly) it is naturally well suited to become a decentralized mobile money standard because people can run a full node on their phone, guaranteeing the security of their funds. Scalability in Bitcoin requires complicated and compromised workarounds such as Lightning Network and light clients, and these problems are solved in Epic. With our forthcoming Mobile Mining app, hundreds of millions of cell phones and tablets will be able to easily join the network. People can quickly and cheaply send money to one another, fulfilling the long-envisioned promise of P2P electronic cash. As an investor, it’s important to ask a few key questions. Bitcoin Standard tokenomics of disinflation and a fixed supply are well proven over a decade now. We follow this model exactly, with a permanently synchronized supply from 2028, and 4 emission halvings from now until then, with our first one in about two weeks. Beyond that, we can apply some simple logical tests. What is more valuable, money that can only be used in some cases (censorable Bitcoin based on a lack of fungibility) or money that can be used universally? (fungible Epic based on always-on privacy by default). Epic is also poised to be a more decentralized and therefore resilient network because of wider participation in mining. Epic is designed to be Bitcoin++ Privacy, Fungibility, Scalability Cryptodiffer Community Q1. What are advantages for choosing three mining algorithms RandomX+, ProgPow and CuckAToo31+ ? Q2. Beam and Grin use MimbleWimble protocol, so what are difference for Epic? All of you will be friends for partners or competitors? Max Freeman Project Lead at Epic Cash RandomX and ProgPow are designed to use the entirety of a CPU / GPU’s unique processing capabilities in a way that other types of hardware don’t work as well. You can run RandomX on a GPU but it doesn’t work nearly as well as a much cheaper CPU, for example. Cuckoo is a “memory hard” algorithm that widens the range of companies that can produce the hardware. Grin and Beam are great projects and we’ve learned a lot from them. We inherited our first codebase from Grin’s excellent Rust design, which is a better language for community participation than C++ that Beam currently uses. Functionally, Mimblewimble is similar across the 3 coins, with standard Confidential Transactions, CoinJoin, Dandelion++, Schnorr Signatures and other advanced features. Grin is primarily ASIC-targeted, Beam is GPU-targeted, and Epic is multi-hardware. The biggest differences though are in tokenomics and project structure. Grin has permanent inflation of 60 coins per block with no halvings, which means steady erosion of value over time due to new supply pressure. It also lacks a steady funding model, making future development in jeopardy, particularly as the per coin price falls. Beam has a for-profit model with heavy early inflation and a high developer tax. Epic builds on the strengths of these earlier mimblewimble projects and addresses the parts that could be improved. Cryptodiffer Community Some privacy coin has scalability issues! How Epic cash will solve scalability issues? Why you choose randomX consensus algorithem? Xenolink Advisor at Epic Cash Fungibility means that you can’t distinguish one unit of currency from another, in example Gold. Fungibility has recently become a hot issue as people have been noticing Bitcoins being locked up by exchanges which may of had a nefarious history which are called Tainted Coins. In example coins that have been involved in a hack, darknet market transactions, or even processing coin through a mixer. Today we can already see freshly mined Bitcoins being sold at a premium price to avoid the fungibility problem Bitcoin carries today. Bitcoin can be tracked by chainalysis and is not a fungible cryptocurrency. One of the features that Epic has is privacy with added fungibility, because of Mimblewimble technology, Epic has no addresses recorded and therefore nothing can be tracked by chainalysis. Below I provide a link of an example of what the lack of fungibility is resulting in today with Bitcoin. One of the reasons why we chose the Random X algo. is because of the easy barrier of entry and also to further decentralize the mining. Random X algo can be mined on old computers or laptops. We also have 2 other algos Progpow (GPU), and Cuckoo (ASIC) to create a wider decentralization of mining methods for Epic. Cryptodiffer Community I’m a newbie in crypto and blockchain so how will Epic Cash team target and educate people who don’t know about blockchain and crypto? What is the uniqueness of Epic Cash that cannot be found in other project that´s been released so far ? Yoga Dude Pr&Marketing at Epic Cash Actually, while we have our white paper translated into over 30 languages, we are more focused on explaining our uses and advantages rather than cold specs. Our tech is solid, but we not get hung up on pure tech talk which most casual users do not need to or care to understand. As long as our fundamentals and tech are secure and user friendly our primary goal is to educate about use cases and market potential. The uniqueness of Epic Cash is its amalgamation of “whats good” in other cryptos. We use Mimblewimble for privacy and anonymity. Our blockchain is much lighter than our competitors. We are the only Mimblewimble crypto to use a unique cocktail of mining algorithms allowing to be mined by casual miners with gaming rigs and laptops, while remaining friendly to GPU and CPU farmers. The “uniqueness” is learning from the mistakes of those who came before us, we evolved and learned, which is why our privacy is better, we are faster, we are fungible, we offer diverse mining and so on. We are the best blend — thats powerful and unique Cryptodiffer Community Can you share EPIC’s vision for decentralized finance (DEFI)? What features do EPIC have to support DEFI? Yoga Dude PR&Marketing at Epic Cash We view Epic as ideally suited to be the decentralized digital reserve asset of the new Private Internet of Money that’s emerging. At a technology level, atomic swaps can be created to build liquidity bridges so that wrapped Epic tokens (like WBTC, WETH) can trade on other networks as ERC20, BEP2, NEP5, VIP180, Algorand and so on. There is more Bitcoin value locked on Ethereum than in Lightning Network, so we will similarly integrate Epic so that it can trade on networks such as Uniswap, Kyber, and so on. Longer term, if there is market demand for it, thanks to Scriptless Script functionality our blockchain has, we can build “Confidential Assets” (which Raven, Tari, and Beam are all also working on) that enable people to create tokenized assets in a private way. Cryptodiffer Community If you could choose one celebrity to promote Epic-cash, who that would be? Max Freeman Project Lead at Epic Cash I am a firm believer that the strength of the project lies in allowing community members to become their own celebrities, if their content is good enough the community will propel them to celebrity status. Organic celebrities with small but loyal following are vastly more beneficial than big name professional shills with inflated but non caring audiences. I remember the early days of Apple when an enthusiastic dude named Guy Kawasaki became Apple Evangelist, he was literally going around stores that sold Apple and visited user groups and Evangelized his belief in Apple. This guy became a Legend and helped Apple become what it is today. Epic Cash will have its OWN Celebrities Cryptodiffer Community How does$EPIC solve scalability of transactions? Current blockchains face issues with scalability a lot, how does EPIC creates a solution to it? Xenolink Advisor at Epic Cash Epic Cash is utilizing Mimblewimble technology. Besides the privacy & fungibility aspect of the tech. There is the scalability features of it. It is implemented into Epic by transaction cut-through. Which means it allows nodes to remove all intermediate transactions, thus significantly reducing the blockchain size without affecting its validation. Mimblewimble also does not use addresses like a BTC address, and amount of transactions are also not recorded. One problem Monero and Bitcoin are facing now is scalability. It is evident today that data is getting more expensive and that will be a problem in the long run for those coins. Epic is 90% lighter and more scalable compared to Monero and Bitcoin. Cryptodiffer Community what are the ways that Epic Cash generates profits/revenue to maintain your project and what is its revenue model ? How can it make benefit win-win to both invester and your project ? Max Freeman Project Lead at Epic Cash There is a block subsidy of 7.77% that declines 1.11% per year until 0, where it stays after that. As a nonprofit community effort, this extremely modest amount goes much further than in other projects, which often take 20, 30, even 50+ % of the coin supply. We believe that this ongoing funding model best aligns the long term incentives for all participants and balances the compromises between the ends of the centralized/decentralized spectrum of choices that any project must make. Cryptodiffer Community Q1 : What are your major goals to archive in the next 3–4 years? Q2 : What are your plans to expand and gain more adoption? Yoga Dude Pr&Marketing at Epic Cash Max already talked about our technical plans and goals in his roadmap. Allow me to talk more about the non technical 😁 We are aiming for broader reach in the non technical more mainstream community — this is a big challenge but we believe it is doable. By offering simpler ways to mine Epic Cash (with smart phones for example), and by doing more education we will achieve the holy grail of crypto — moving past the fiat bridges and getting Epic Cash to be accepted as means of payment for goods and services. We will accomplish this by working with regional advocacy groups, community interaction, off-line promotional activities and diverse social media targeting. Cryptodiffer Community It seems to me that EpicCash will have its first Halving, right? Why a halving so soon? Is a mobile version feasible? Max Freeman Project Lead at Epic Cash Our supply emission catches up to that of Bitcoin’s first 19 years after 8 years in Epic, so that requires more frequent halvings. Today’s block emission is 16, next up are 8, 4, 2, and then finally 0.15625. After that, the supply of Epic and that of BTC stay synchronized until maxing out at 21m coins in 2140. Today we have a mobile wallet through the Vitex app, a native mobile wallet coming, and are working on mobile mining. Cryptodiffer Community What markets will you add after that? Yoga Dude PR&Marketing at Epic Cash Well, we are aiming to have ALL markets Epic Cash in its final iteration will be usable by everyone everywhere regardless of their technical expertise. We are not limiting ourselves to the technocrats, one of our main goals is to help the billions of unbanked. We want everyone to be able to mine, buy, and most of all USE Epic Cash — gamers, farmers, soccer moms, students, retirees, everyone really — even bankers (well once we defeat the banking industry) We will continue building on the multilingual diversity of our global community adding support and advocacy groups in more countries in more languages. Epic Cash is More than Money and its for Everyone. Cryptodiffer Community Almost, all cryptocurrencies are decentralized & no-one knows who owns that cryptocurrencies ! then also, why Privacy is needed? hats the advantages of Private coins? Max Freeman Project Lead at Epic Cash With a public transparent blockchain such as Bitcoin, you are permanently posting a detailed history of your money movements open for anyone to see (not just legitimate authorities, either!) — It would be considered crazy to post your credit card or bank statements to Twitter, but that’s what is happening every time you send a transaction that is not private. This excellent video from community contributor Spencer Lambert https://www.youtube.com/watch?v=0blbfmvCq\_4 explains better than I can. Privacy is not just for criminals, it’s for everyone. Do you want your landlord to increase the rent when he sees that you get a raise? Your insurance company to raise your healthcare costs because they see you buying too much ice cream? If you’re a business, do you want your employees to see how much money their coworkers make? Do you want your competitors to trace your supplier and customer relationships? Of course not. By privacy being default for everyone, cryptocurrency can be used in a much wider range of situations without unacceptable compromises. Cryptodiffer Community What are the main utility and real-life usage of the #EPIC As an investor, why should we invest in the #EPIC project as a long-term investment? Xenolink Advisor at Epic Cash Epic Cash can be used as a Private and Fungible store of value, medium of exchange, and unit of account. As Epic Cash grows and becomes adopted it can be compared to how Bitcoin and Monero is used and adopted as well. As Epic is adopted by the masses, it can be accepted as a medium of exchange for store owners and as fungible payments without the worry of having money that is tainted. Epic Cash as a store of value may be a good long term aspect of investment to consider. Epic Cash carries an inelastic fixed supply economic model of 21 million coins. There will be 5 halvings which this month of June will be our first halving of epic. From a block reward of 16 Epic reduced to 8. If we look at BTC’s price action and history of their halvings it has been proven and show that there has been an increase in value due to the scarcity and from halvings a reduction of # of BTC’s mined per block. An inelastic supply model like Bitcoin provides proof of the circulating supply compared to the total supply by the history of it’s Price action which is evident in long term charts since the birth of Bitcoin. EPIC Plans to have 5 halvings before the year 2028 to match the emissions of Bitcoin which we call the singularity event. Below is a chart displaying our halvings model approaching singularity. Once bitcoin and cryptocurrency becomes adopted mainstream, the fungibility problem will be more noticed by the general public. Privacy coins and the features of fungibility/scalability will most likely be sought over. Right now a majority of people believe that all cryptocurrency is fungible. However, that is not true. We can already see Chainalysis confirming that they can trace and track and even for other well-known privacy coins today such as Z-Cash. Cryptodiffer Community 1. You aim to reach support from a global community, what are your plans to get spanish speakers involved into Epic Cash? And emerging markets like the african 2. How am I secure I won’t be affected by receiving tainted money? Max Freeman Project Lead at Epic Cash Native speakers from our community are working to raise awareness in key markets such as mining in Argentina and Venezuela for Spanish (Roberto Navarro called Epic “the holy grail of cryptocurrency” and Ethiopia and certain North African countries that have the lowest electricity costs in the world. Remittances between USA and Latin American countries are expensive and slow, so Epic is also perfect for people to send money back home as well. Cryptodiffer Community Do EPICs in 2020 focus more on research and coding, or on sales and implementation? Yoga Dude PR&Marketing at Epic Cash We will definitely continue to work on research and coding, with emphasis on improved accessibility (especially via smartphones) usability, security and privacy. In terms of financial infrastructure will continuing to add exchanges both KYC and non KYC. Big part of our plans is in ongoing Marketing and PR outreach. The idea is to make Epic Cash a viral sensation of sorts. If we can get Epic Cash adopters to spread the word and tell their family, coworkers and friends about Epic Cash — there will be no stopping us and to help that happen we have a growing army of content creators, and supporters. Everyone with skin in the game gets the benefit of advancing the cause. Folks also, this isn’t an answer to the question but an example of a real-world Epic Cash content — https://www.youtube.com/watch?v=XtAVEqKGgqY a challenge from one of our content creators to beat his 21 pull ups and get 100 epics! This has not been claimed yet — people need to step up 🙂 and to help that I will match another 100 Epic Cash to the first person to beat this Cryptodiffer Community I was watching some videos explaining how to send and receive transactions in EpicCash, which consists of ports and sending links, my question is why this is so, which, for now, looks complex? Let’s talk about the economic model, can EpicCash comply with the concept of value reserve? Max Freeman Project Lead at Epic Cash In V3, which is coming later this summer, Epic can be sent over Tor, which eliminates this issue of port opening, even though using tools like ngrok.io, it’s not necessarily as painful as directly configuring the router ports. Early Lightning Network had this issue as well and it’s something we have a plan to address via research into non-interactive transactions. “Fire and Forget” payments to an address, as people are used to in Bitcoin, is coming to Epic and we’re excited to develop functionality that other advanced mimblewimble coins don’t yet have. We are committed to constant improvement in usability and utility, to make our money system the ease of use leader. We are involved in the project (anyone can join the Freeman Family) because we believe that simply by choosing to use a form of money that better aligns with our ideals, that we can make a positive change in the world. Some of my thoughts about how I got involved are here: https://medium.com/epic-cash/the-freeman-family-e3b9c3b3f166 Max Freeman Project Lead at Epic Cash Huge thanks to our friends Maks and Vladyslav, we welcome everyone to come say hi at one of our friendly communities. It is extremely early in this journey, our market cap is only 0.5m right now, whereas the 3 other mimblewimble coins are at20m, $30m and$100m respectively. Epic is a historic opportunity to follow in the footsteps of legends such as Bitcoin and Monero, and we hope to become the first Top 5 privacy coin project.
Would like to Thank the Cryptodiffer Team and the Cryptodiffer community for hosting us and also engaging with us to learn more about Epic. If anyone else has more questions and wants to know more about EPIC , can find us at our telegram channel at https://t.me/EpicCash .
Yoga Dude Pr&Marketing at Epic Cash
Thank you, CryptoDiffer Team, and this wonderful Community!!!
Cryptodiffer TEAM
Thank you for your time, it was an insightful session

##### Dive Into Tendermint Consensus Protocol (I)

This article is written by the CoinEx Chain lab. CoinEx Chain is the world’s first public chain exclusively designed for DEX, and will also include a Smart Chain supporting smart contracts and a Privacy Chain protecting users’ privacy.
longcpp @ 20200618
This is Part 1 of the serialized articles aimed to explain the Tendermint consensus protocol in detail.
Part 1. Preliminary of the consensus protocol: security model and PBFT protocol
Part 2. Tendermint consensus protocol illustrated: two-phase voting protocol and the locking and unlocking mechanism
Part 3. Weighted round-robin proposer selection algorithm used in Tendermint project
Any consensus agreement that is ultimately reached is the General Agreement, that is, the majority opinion. The consensus protocol on which the blockchain system operates is no exception. As a distributed system, the blockchain system aims to maintain the validity of the system. Intuitively, the validity of the blockchain system has two meanings: firstly, there is no ambiguity, and secondly, it can process requests to update its status. The former corresponds to the safety requirements of distributed systems, while the latter to the requirements of liveness. The validity of distributed systems is mainly maintained by consensus protocols, considering the multiple nodes and network communication involved in such systems may be unstable, which has brought huge challenges to the design of consensus protocols.

## The semi-synchronous network model and Byzantine fault tolerance

Researchers of distributed systems characterize these problems that may occur in nodes and network communications using node failure models and network models. The fail-stop failure in node failure models refers to the situation where the node itself stops running due to configuration errors or other reasons, thus unable to go on with the consensus protocol. This type of failure will not cause side effects on other parts of the distributed system except that the node itself stops running. However, for such distributed systems as the public blockchain, when designing a consensus protocol, we still need to consider the evildoing intended by nodes besides their failure. These incidents are all included in the Byzantine Failure model, which covers all unexpected situations that may occur on the node, for example, passive downtime failures and any deviation intended by the nodes from the consensus protocol. For a better explanation, downtime failures refer to nodes’ passive running halt, and the Byzantine failure to any arbitrary deviation of nodes from the consensus protocol.
Compared with the node failure model which can be roughly divided into the passive and active models, the modeling of network communication is more difficult. The network itself suffers problems of instability and communication delay. Moreover, since all network communication is ultimately completed by the node which may have a downtime failure or a Byzantine failure in itself, it is usually difficult to define whether such failure arises from the node or the network itself when a node does not receive another node's network message. Although the network communication may be affected by many factors, the researchers found that the network model can be classified by the communication delay. For example, the node may fail to send data packages due to the fail-stop failure, and as a result, the corresponding communication delay is unknown and can be any value. According to the concept of communication delay, the network communication model can be divided into the following three categories:
• The synchronous network model: There is a fixed, known upper bound of delay $\Delta$ in network communication. Under this model, the maximum delay of network communication between two nodes in the network is $\Delta$. Even if there is a malicious node, the communication delay arising therefrom does not exceed $\Delta$.
• The asynchronous network model: There is an unknown delay in network communication, with the upper bound of the delay known, but the message can still be successfully delivered in the end. Under this model, the network communication delay between two nodes in the network can be any possible value, that is, a malicious node, if any, can arbitrarily extend the communication delay.
• The semi-synchronous network model: Assume that there is a Global Stabilization Time (GST), before which it is an asynchronous network model and after which, a synchronous network model. In other words, there is a fixed, known upper bound of delay in network communication $\Delta$. A malicious node can delay the GST arbitrarily, and there will be no notification when no GST occurs. Under this model, the delay in the delivery of the message at the time $T$ is $\Delta + max(T, GST)$.
The synchronous network model is the most ideal network environment. Every message sent through the network can be received within a predictable time, but this model cannot reflect the real network communication situation. As in a real network, network failures are inevitable from time to time, causing the failure in the assumption of the synchronous network model. Yet the asynchronous network model goes to the other extreme and cannot reflect the real network situation either. Moreover, according to the FLP (Fischer-Lynch-Paterson) theorem, under this model if there is one node fails, no consensus protocol will reach consensus in a limited time. In contrast, the semi-synchronous network model can better describe the real-world network communication situation: network communication is usually synchronous or may return to normal after a short time. Such an experience must be no stranger to everyone: the web page, which usually gets loaded quite fast, opens slowly every now and then, and you need to try before you know the network is back to normal since there is usually no notification. The peer-to-peer (P2P) network communication, which is widely used in blockchain projects, also makes it possible for a node to send and receive information from multiple network channels. It is unrealistic to keep blocking the network information transmission of a node for a long time. Therefore, all the discussion below is under the semi-synchronous network model.
The design and selection of consensus protocols for public chain networks that allow nodes to dynamically join and leave need to consider possible Byzantine failures. Therefore, the consensus protocol of a public chain network is designed to guarantee the security and liveness of the network under the semi-synchronous network model on the premise of possible Byzantine failure. Researchers of distributed systems point out that to ensure the security and liveness of the system, the consensus protocol itself needs to meet three requirements:
• Validity: The value reached by honest nodes must be the value proposed by one of them
• Agreement: All honest nodes must reach consensus on the same value
• Termination: The honest nodes must eventually reach consensus on a certain value
Validity and agreement can guarantee the security of the distributed system, that is, the honest nodes will never reach a consensus on a random value, and once the consensus is reached, all honest nodes agree on this value. Termination guarantees the liveness of distributed systems. A distributed system unable to reach consensus is useless.

## The CAP theorem and Byzantine Generals Problem

In a semi-synchronous network, is it possible to design a Byzantine fault-tolerant consensus protocol that satisfies validity, agreement, and termination? How many Byzantine nodes can a system tolerance? The CAP theorem and Byzantine Generals Problem provide an answer for these two questions and have thus become the basic guidelines for the design of Byzantine fault-tolerant consensus protocols.
Lamport, Shostak, and Pease abstracted the design of the consensus mechanism in the distributed system in 1982 as the Byzantine Generals Problem, which refers to such a situation as described below: several generals each lead the army to fight in the war, and their troops are stationed in different places. The generals must formulate a unified action plan for the victory. However, since the camps are far away from each other, they can only communicate with each other through the communication soldiers, or, in other words, they cannot appear on the same occasion at the same time to reach a consensus. Unfortunately, among the generals, there is a traitor or two who intend to undermine the unified actions of the loyal generals by sending the wrong information, and the communication soldiers cannot send the message to the destination by themselves. It is assumed that each communication soldier can prove the information he has brought comes from a certain general, just as in the case of a real BFT consensus protocol, each node has its public and private keys to establish an encrypted communication channel for each other to ensure that its messages will not be tampered with in the network communication, and the message receiver can also verify the sender of the message based thereon. As already mentioned, any consensus agreement ultimately reached represents the consensus of the majority. In the process of generals communicating with each other for an offensive or retreat, a general also makes decisions based on the majority opinion from the information collected by himself.
According to the research of Lamport et al, if there are 1/3 or more traitors in the node, the generals cannot reach a unified decision. For example, in the following figure, assume there are 3 generals and only 1 traitor. In the figure on the left, suppose that General C is the traitor, and A and B are loyal. If A wants to launch an attack and informs B and C of such intention, yet the traitor C sends a message to B, suggesting what he has received from A is a retreat. In this case, B can't decide as he doesn't know who the traitor is, and the information received is insufficient for him to decide. If A is a traitor, he can send different messages to B and C. Then C faithfully reports to B the information he received. At this moment as B receives conflicting information, he cannot make any decisions. In both cases, even if B had received consistent information, it would be impossible for him to spot the traitor between A and C. Therefore, it is obvious that in both situations shown in the figure below, the honest General B cannot make a choice.
According to this conclusion, when there are $n$ generals with at most $f$ traitors (n≤3f), the generals cannot reach a consensus if $n \leq 3f$; and with $n > 3f$, a consensus can be reached. This conclusion also suggests that when the number of Byzantine failures $f$ exceeds 1/3 of the total number of nodes $n$ in the system $f \ge n/3$ , no consensus will be reached on any consensus protocol among all honest nodes. Only when $f < n/3$, such condition is likely to happen, without loss of generality, and for the subsequent discussion on the consensus protocol, $n \ge 3f + 1$ by default.
The conclusion reached by Lamport et al. on the Byzantine Generals Problem draws a line between the possible and the impossible in the design of the Byzantine fault tolerance consensus protocol. Within the possible range, how will the consensus protocol be designed? Can both the security and liveness of distributed systems be fully guaranteed? Brewer provided the answer in his CAP theorem in 2000. It indicated that a distributed system requires the following three basic attributes, but any distributed system can only meet two of the three at the same time.
1. Consistency: When any node responds to the request, it must either provide the latest status information or provide no status information
2. Availability: Any node in the system must be able to continue reading and writing
3. Partition Tolerance: The system can tolerate the loss of any number of messages between two nodes and still function normally

https://preview.redd.it/1ozfwk7u7m851.png?width=1400&format=png&auto=webp&s=fdee6318de2cf1c021e636654766a7a0fe7b38b4
A distributed system aims to provide consistent services. Therefore, the consistency attribute requires that the two nodes in the system cannot provide conflicting status information or expired information, which can ensure the security of the distributed system. The availability attribute is to ensure that the system can continuously update its status and guarantee the availability of distributed systems. The partition tolerance attribute is related to the network communication delay, and, under the semi-synchronous network model, it can be the status before GST when the network is in an asynchronous status with an unknown delay in the network communication. In this condition, communicating nodes may not receive information from each other, and the network is thus considered to be in a partitioned status. Partition tolerance requires the distributed system to function normally even in network partitions.
The proof of the CAP theorem can be demonstrated with the following diagram. The curve represents the network partition, and each network has four nodes, distinguished by the numbers 1, 2, 3, and 4. The distributed system stores color information, and all the status information stored by all nodes is blue at first.
1. Partition tolerance and availability mean the loss of consistency: When node 1 receives a new request in the leftmost image, the status changes to red, the status transition information of node 1 is passed to node 3, and node 3 also updates the status information to red. However, since node 3 and node 4 did not receive the corresponding information due to the network partition, the status information is still blue. At this moment, if the status information is queried through node 2, the blue returned by node 2 is not the latest status of the system, thus losing consistency.
2. Partition tolerance and consistency mean the loss of availability: In the middle figure, the initial status information of all nodes is blue. When node 1 and node 3 update the status information to red, node 2 and node 4 maintain the outdated information as blue due to network partition. Also when querying status information through node 2, you need to first ask other nodes to make sure you’re in the latest status before returning status information as node 2 needs to follow consistency, but because of the network partition, node 2 cannot receive any information from node 1 or node 3. Then node 2 cannot determine whether it is in the latest status, so it chooses not to return any information, thus depriving the system of availability.
3. Consistency and availability mean the loss of the partition tolerance: In the right-most figure, the system does not have a network partition at first, and both status updates and queries can go smoothly. However, once a network partition occurs, it degenerates into one of the previous two conditions. It is thus proved that any distributed system cannot have consistency, availability, and partition tolerance all at the same time.

The discovery of the CAP theorem seems to declare that the aforementioned goals of the consensus protocol is impossible. However, if you’re careful enough, you may find from the above that those are all extreme cases, such as network partitions that cause the failure of information transmission, which could be rare, especially in P2P network. In the second case, the system rarely returns the same information with node 2, and the general practice is to query other nodes and return the latest status as believed after a while, regardless of whether it has received the request information of other nodes. Therefore, although the CAP theorem points out that any distributed system cannot satisfy the three attributes at the same time, it is not a binary choice, as the designer of the consensus protocol can weigh up all the three attributes according to the needs of the distributed system. However, as the communication delay is always involved in the distributed system, one always needs to choose between availability and consistency while ensuring a certain degree of partition tolerance. Specifically, in the second case, it is about the value that node 2 returns: a probably outdated value or no value. Returning the possibly outdated value may violate consistency but guarantees availability; yet returning no value deprives the system of availability but guarantees its consistency. Tendermint consensus protocol to be introduced is consistent in this trade-off. In other words, it will lose availability in some cases.
The genius of Satoshi Nakamoto is that with constraints of the CAP theorem, he managed to reach a reliable Byzantine consensus in a distributed network by combining PoW mechanism, Satoshi Nakamoto consensus, and economic incentives with appropriate parameter configuration. Whether Bitcoin's mechanism design solves the Byzantine Generals Problem has remained a dispute among academicians. Garay, Kiayias, and Leonardos analyzed the link between Bitcoin mechanism design and the Byzantine consensus in detail in their paper The Bitcoin Backbone Protocol: Analysis and Applications. In simple terms, the Satoshi Consensus is a probabilistic Byzantine fault-tolerant consensus protocol that depends on such conditions as the network communication environment and the proportion of malicious nodes' hashrate. When the proportion of malicious nodes’ hashrate does not exceed 1/2 in a good network communication environment, the Satoshi Consensus can reliably solve the Byzantine consensus problem in a distributed environment. However, when the environment turns bad, even with the proportion within 1/2, the Satoshi Consensus may still fail to reach a reliable conclusion on the Byzantine consensus problem. It is worth noting that the quality of the network environment is relative to Bitcoin's block interval. The 10-minute block generation interval of the Bitcoin can ensure that the system is in a good network communication environment in most cases, given the fact that the broadcast time of a block in the distributed network is usually just several seconds. In addition, economic incentives can motivate most nodes to actively comply with the agreement. It is thus considered that with the current Bitcoin network parameter configuration and mechanism design, the Bitcoin mechanism design has reliably solved the Byzantine Consensus problem in the current network environment.

## Practical Byzantine Fault Tolerance, PBFT

It is not an easy task to design the Byzantine fault-tolerant consensus protocol in a semi-synchronous network. The first practically usable Byzantine fault-tolerant consensus protocol is the Practical Byzantine Fault Tolerance (PBFT) designed by Castro and Liskov in 1999, the first of its kind with polynomial complexity. For a distributed system with $n$ nodes, the communication complexity is $O(n2$.) Castro and Liskov showed in the paper that by transforming centralized file system into a distributed one using the PBFT protocol, the overwall performance was only slowed down by 3%. In this section we will briefly introduce the PBFT protocol, paving the way for further detailed explanations of the Tendermint protocol and the improvements of the Tendermint protocol.
The PBFT protocol that includes $n=3f+1$ nodes can tolerate up to $f$ Byzantine nodes. In the original paper of PBFT, full connection is required among all the $n$ nodes, that is, any two of the n nodes must be connected. All the nodes of the network jointly maintain the system status through network communication. In the Bitcoin network, a node can participate in or exit the consensus process through hashrate mining at any time, which is managed by the administrator, and the PFBT protocol needs to determine all the participating nodes before the protocol starts. All nodes in the PBFT protocol are divided into two categories, master nodes, and slave nodes. There is only one master node at any time, and all nodes take turns to be the master node. All nodes run in a rotation process called View, in each of which the master node will be reelected. The master node selection algorithm in PBFT is very simple: all nodes become the master node in turn by the index number. In each view, all nodes try to reach a consensus on the system status. It is worth mentioning that in the PBFT protocol, each node has its own digital signature key pair. All sent messages (including request messages from the client) need to be signed to ensure the integrity of the message in the network and the traceability of the message itself. (You can determine who sent a message based on the digital signature).
The following figure shows the basic flow of the PBFT consensus protocol. Assume that the current view’s master node is node 0. Client C initiates a request to the master node 0. After the master node receives the request, it broadcasts the request to all slave nodes that process the request of client C and return the result to the client. After the client receives f+1 identical results from different nodes (based on the signature value), the result can be taken as the final result of the entire operation. Since the system can have at most f Byzantine nodes, at least one of the f+1 results received by the client comes from an honest node, and the security of the consensus protocol guarantees that all honest nodes will reach consensus on the same status. So, the feedback from 1 honest node is enough to confirm that the corresponding request has been processed by the system.

https://preview.redd.it/sz8so5ly7m851.png?width=1400&format=png&auto=webp&s=d472810e76bbc202e91a25ef29a51e109a576554
For the status synchronization of all honest nodes, the PBFT protocol has two constraints on each node: on one hand, all nodes must start from the same status, and on the other, the status transition of all nodes must be definite, that is, given the same status and request, the results after the operation must be the same. Under these two constraints, as long as the entire system agrees on the processing order of all transactions, the status of all honest nodes will be consistent. This is also the main purpose of the PBFT protocol: to reach a consensus on the order of transactions between all nodes, thereby ensuring the security of the entire distributed system. In terms of availability, the PBFT consensus protocol relies on a timeout mechanism to find anomalies in the consensus process and start the View Change protocol in time to try to reach a consensus again.
The figure above shows a simplified workflow of the PBFT protocol. Where C is the client, 0, 1, 2, and 3 represent 4 nodes respectively. Specifically, 0 is the master node of the current view, 1, 2, 3 are slave nodes, and node 3 is faulty. Under normal circumstances, the PBFT consensus protocol reaches consensus on the order of transactions between nodes through a three-phase protocol. These three phases are respectively: Pre-Prepare, Prepare, and Commit:
• The master node of the pre-preparation node is responsible for assigning the sequence number to the received client request, and broadcasting the message to the slave node. The message contains the hash value of the client request d, the sequence number of the current viewv, the sequence number n assigned by the master node to the request, and the signature information of the master nodesig. The scheme design of the PBFT protocol separates the request transmission from the request sequencing process, and the request transmission is not to be discussed here. The slave node that receives the message accepts the message after confirming the message is legitimate and enter preparation phase. The message in this step checks the basic signature, hash value, current view, and, most importantly, whether the master node has given the same sequence number to other request from the client in the current view.
• In preparation, the slave node broadcasts the message to all nodes (including itself), indicating that it assigns the sequence number n to the client request with the hash value d under the current view v, with its signaturesig as proof. The node receiving the message will check the correctness of the signature, the matching of the view sequence number, etc., and accept the legitimate message. When the PRE-PREPARE message about a client request (from the main node) received by a node matches with the PREPARE from 2f slave nodes, the system has agreed on the sequence number requested by the client in the current view. This means that 2f+1 nodes in the current view agree with the request sequence number. Since it contains information from at most fmalicious nodes, there are a total of f+1 honest nodes that have agreed with the allocation of the request sequence number. With f malicious nodes, there are a total of 2f+1 honest nodes, so f+1represents the majority of the honest nodes, which is the consensus of the majority mentioned before.
• After the node (including the master node and the slave node) receives a PRE-PREPARE message requested by the client and 2f PREPARE messages, the message is broadcast across the network and enters the submission phase. This message is used to indicate that the node has observed that the whole network has reached a consensus on the sequence number allocation of the request message from the client. When the node receives 2f+1 COMMIT messages, there are at least f+1 honest nodes, that is, most of the honest nodes have observed that the entire network has reached consensus on the arrangement of sequence numbers of the request message from the client. The node can process the client request and return the execution result to the client at this moment.
Roughly speaking, in the pre-preparation phase, the master node assigns a sequence number to all new client requests. During preparation, all nodes reach consensus on the client request sequence number in this view, while in submission the consistency of the request sequence number of the client in different views is to be guaranteed. In addition, the design of the PBFT protocol itself does not require the request message to be submitted by the assigned sequence number, but out of order. That can improve the efficiency of the implementation of the consensus protocol. Yet, the messages are still processed by the sequence number assigned by the consensus protocol for the consistency of the distributed system.
In the three-phase protocol execution of the PBFT protocol, in addition to maintaining the status information of the distributed system, the node itself also needs to log all kinds of consensus information it receives. The gradual accumulation of logs will consume considerable system resources. Therefore, the PBFT protocol additionally defines checkpoints to help the node deal with garbage collection. You can set a checkpoint every 100 or 1000 sequence numbers according to the request sequence number. After the client request at the checkpoint is executed, the node broadcasts messages throughout the network, indicating that after the node executes the client request with sequence number n, the hash value of the system status is d, and it is vouched by its own signature sig. After 2f+1 matching CHECKPOINT messages (one of which can come from the node itself) are received, most of the honest nodes in the entire network have reached a consensus on the system status after the execution of the client request with the sequence numbern, and then you can clear all relevant log records of client requests with the sequence number less than n. The node needs to save these2f+1 CHECKPOINTmessages as proof of the legitimate status at this moment, and the corresponding checkpoint is called a stable checkpoint.
The three-phase protocol of the PBFT protocol can ensure the consistency of the processing order of the client request, and the checkpoint mechanism is set to help nodes perform garbage collection and further ensures the status consistency of the distributed system, both of which can guarantee the security of the distributed system aforementioned. How is the availability of the distributed system guaranteed? In the semi-synchronous network model, a timeout mechanism is usually introduced, which is related to delays in the network environment. It is assumed that the network delay has a known upper bound after GST. In such condition, an initial value is usually set according to the network condition of the system deployed. In case of a timeout event, besides the corresponding processing flow triggered, additional mechanisms will be activated to readjust the waiting time. For example, an algorithm like TCP's exponential back off can be adopted to adjust the waiting time after a timeout event.
To ensure the availability of the system in the PBFT protocol, a timeout mechanism is also introduced. In addition, due to the potential the Byzantine failure in the master node itself, the PBFT protocol also needs to ensure the security and availability of the system in this case. When the Byzantine failure occurs in the master node, for example, when the slave node does not receive the PRE-PREPARE message or the PRE-PREPARE message sent by the master node from the master node within the time window and is thus determined to be illegitimate, the slave node can broadcast to the entire network, indicating that the node requests to switch to the new view with sequence number v+1. n indicates the request sequence number corresponding to the latest stable checkpoint local to the node, and C is to prove the stable checkpoint 2f+1 legitimate CHECKPOINT messages as aforementioned. After the latest stable checkpoint and before initiating the VIEWCHANGE message, the system may have reached a consensus on the sequence numbers of some request messages in the previous view. To ensure the consistency of these request sequence numbers to be switched in the view, the VIEWCHANGE message needs to carry this kind of the information to the new view, which is also the meaning of the P field in the message. P contains all the client request messages collected at the node with a request sequence number greater than n and the proof that a consensus has been reached on the sequence number in the node: the legitimate PRE-PREPARE message of the request and 2f matching PREPARE messages. When the master node in view v+1 collects 2f+1 VIEWCHANGE messages, it can broadcast the NEW-VIEW message and take the entire system into a new view. For the security of the system in combination with the three-phase protocol of the PBFT protocol, the construction rules of the NEW-VIEW information are designed in a quite complicated way. You can refer to the original paper of PBFT for more details.

VIEWCHANGE contains a lot of information. For example, C contains 2f+1 signature information, P contains several signature sets, and each set has 2f+1 signature. At least 2f+1 nodes need to send a VIEWCHANGE message before prompting the system to enter the next new view, and that means, in addition to the complex logic of constructing the information of VIEWCHANGE and NEW-VIEW, the communication complexity of the view conversion protocol is $O(n2$.) Such complexity also limits the PBFT protocol to support only a few nodes, and when there are 100 nodes, it is usually too complex to practically deploy PBFT. It is worth noting that in some materials the communication complexity of the PBFT protocol is inappropriately attributed to the full connection between n nodes. By changing the fully connected network topology to the P2P network topology based on distributed hash tables commonly used in blockchain projects, high communication complexity caused by full connection can be conveniently solved, yet still, it is difficult to improve the communication complexity during the view conversion process. In recent years, researchers have proposed to reduce the amount of communication in this step by adopting aggregate signature scheme. With this technology, 2f+1 signature information can be compressed into one, thereby reducing the communication volume during view change.