comb101

1. What is Haircomb?
Haircomb is an anonymous, quantum-proof token that's encoded in the transactions of the BTC blockchain. Users interact with the token by tipping segwit addresses very small amounts (330 sats) depending on the action they want to take. The information of the haircomb wallet public key, the funds destination, and the amount of funds involved, are all encoded into 21 segwit addresses, which are then tipped to execute the transaction. This is done by combining the relevant information using a ton of SHA256 hashing. Any time I refer to hashing a number, know it was using SHA256. Fair warning, I don't understand the entirety of the project yet, but I know enough to explain the basics.

2. How is a wallet generated?
Each haircomb wallet has 21 numbers that are effectively the wallet's secret keys. The public key of the wallet is found by taking each of the secret keys, and hashing it 59213 times. The 21 results we get are then concatenated in order, and hashed once. This is the wallet's public key, and also where the name haircomb comes from.

3. How can you claim haircomb?
Claiming haircomb is done by creating a wallet, and then sending 330 sats on the BTC chain to one of the wallet's secret addresses (these are generated using a process I'll explain later, and can be found in the haircoumb software after loading a wallet). Whenever a new block is mined on the BTC chain, the first completely unseen segwit address that's located in the block will be considered the "winner," and will receive haircomb in the corresponding haircomb address. If you manage to claim the haircomb in question, it'll be sent from the receiving address to your wallet address when you click the sweep button in the wallet (Just to be safe, don't sweep an address until the wallet has updated and shows that it contains comb).

4. How does a basic transaction work?
To connect one wallet to another and facilitate the transaction, first a transaction address is created by doing SHA256(wallet1_pubkey CAT wallet2_pubkey). This is inserted into a function called CutCombWhere() (gonna refer to this as CCW()), which, using some process that has to do with Pascal's Triangle (detailed in the whitepaper), generates 21 numbers. This number set has 2 key properties; all the numbers are unsigned integers in the range of 0 and 59213, and all the numbers added together have a value of 59213.
Then, each of wallet1's secret keys is hashed X times, where X is 59213 minus the corresponding CCW() number. This can be visualized as moving down the hash chain towards the corresponding public key, but stopping at the given value. This produces 21 numbers that we'll refer to as the signed numbers. Each of the signed numbers is concatenated with the haircomb whitepaper, and hashed once. The resulting values are then encoded as segwit addresses, and are then tipped 330 sats on the BTC chain. Once these numbers have been committed to the chain, the sender gives the receiver 3 pieces of information; the transaction history of the wallet, both wallet's public keys, and the signed numbers.

Using this information, the receiver validates the transaction. First, they validate the transaction history of the wallet, to confirm that the sender actually had the funds they said they did. Second, they check that the segwit addresses have been tipped on the chain. Third, they check for doublespending. This is done in two steps.

First, the receiver derives the same CCW() values that the sender did, using the same inputs (pubkey1 CAT pubkey2). Second, they continue down the hash chain for each of the signed numbers Y times, where Y is the corresponding CCW() number. Each time they hash, they check the chain for the a segwit encoded address tip that matches segwit(SHA256(whitepaper CAT hashresult)).  This works because, like I said before, all possible CCW() number sets will end up with a sum of the values being equal to 59213. If you compare any two possible transactions that a wallet could make, at least one of the resulting CCW() values will be smaller than the corresponding value of the different transaction, meaning that the receiver WILL come across the corresponding segwit address that had been commited on chain to facilitate the previous transaction.

Finally, the receiver takes the last values of each of the hash chains, and concatenates them all together to check that the sender's public key matches the key they've been given. If there was no double spend, the receiver's wallet confirms that it now has the haircombs.

But wait, the only information that was committed was the origin and destination of the transaction? How does this make any sense?

5. How does the haircomb transfer system work?
In order to answer the previous questions, you first need to understand the difference between haircomb's transfer system and a typical system like BTC. When you send somebody funds from one wallet to another using BTC, the funds are subtracted from the first wallet, added to the second, and stop at the recipient's wallet. You can visualize the funds in this case like coins, being picked up and dropped in a new location. Haircomb does not work like this. Rather than physical coins, haircomb acts more like water. When Wallet A is connected to Wallet B, every single comb from Wallet A will flow to the next wallet in the chain, Wallet B. If somebody else comes along and sends money to Wallet A, that money will flow down to Wallet A, see that Wallet A has been connected to Wallet B, and automatically flow to Wallet B. When you perform a transaction between two haircomb wallets, you aren't moving funds from one to the other. What you're doing it connecting one wallet onto the bottom of the chain of the other wallet, the funds themselves just flow down to the bottom of whatever chain they're connected to. This may seem like a problem, as it'd be impossible to send anybody just a fraction of your funds, but it's actually a blessing because, using something called a "Liquidity Stack", we can both split funds up AND send our money to an infinite amount of wallets with a SINGLE transaction.

6. How do complex transactions and liquidity stacks work?
To perform a basic transaction, the transaction key was created by doing SHA256(wallet1_pubkey CAT wallet2_pubkey). Instead, we'll create the complex transaction's key by doing SHA256(wallet1_pubkey CAT liquiditystack_key). The liquidity stack key is composed of 3 pieces of information; the change_pubkey, the receiving_pubkey, and the receiving_amount. This is concatenated together and hashed, so the final output looks like this: SHA256(sender_pubkey CAT SHA256(change_pubkey, receiving_pubkey, receiving_amount)). When the funds are sent to the liquidity stack, if the funds are less than the receiving amount, nothing happens, and they're stuck there. If the funds are equal to or greater than the receiving amount, that amount is transferred to the receiving_pubkey, and the rest of the funds are transferred to the change_pubkey.

For example:
Alice has 10 comb in wallet Alice_1, and wants to send 2 of them to Bob in wallet Bob_1. Rather than initiate a transfer between Alice_1 and Bob_1, she instead initiates a transfer to a liquidity stack, the address of which is composed of Alice_2 CAT Bob_1 CAT 2. A2 is Alice's new wallet. When the funds are sent to the liquidity stack, the stack then sends 2 of them to Bob_1, and sends the remaining amount to Alice_2. Now Alice still has control of her funds, while also being able to pay Bob a partial amount. If the liquidity stack was ever reused, i.e. Chris connects a wallet to Alice_2 CAT Bob_1 CAT 2, the liquidity stacks would see that it had already siphoned off the 2 funds it was programmed to, and would instead send all funds it received to the change address. In effect, once a stack has been used once, it just becomes like a normal wallet in the chain.

By chaining liquidity stacks, we can send funds to as many people as we want, all within a single transaction. For example, let's say Alice has 10 comb, and wants to give Bob and Chris 2 comb each. First, she build the base liquidity stack; Alice_2 CAT Chris_1 CAT 2. Then, she takes that address, and creates another liquidity stack using it; Stack_1 CAT Bob_1 CAT 2. If she then initiates a transaction using this stack as the destination, the funds will flow to the stack, 2 comb will be siphoned off to Bob, and the remaining funds will go to the change address; the base liquidity stack. Once there, 2 more comb will be siphoned off to Chris's wallet, and then the remainder will be sent to Alice_2. So at the end of the transaction, Alice will have 6 comb, and Bob and Chris will both have 2. These can be stacked infinitely, so long as you have the funds to facilitate the transfer.

This is also how the claiming works, each claiming address is just a liquidity stack address with your wallet as the change address, and a blank receiving address and amount. When this address gets awarded the haircomb, it automatically gets sent to the change address, your wallet.