Topic: [ANN][COMB] Haircomb - Quantum proof, anonymity and more - page 8. (Read 6890 times)

Wow, thank you so much for this! It's way more complicated than I initially thought, that's awesome! If I lay out how I read this, can you point out any mistakes I've made?

Alice has tokens on alice_public_key. She knows corresponding preimages(I don't know this term, can you define it for me?) apk_pi_1 through apk_pi_21, we'll say in an array called apk_pi_array. She wants to send all her funds to Bob's address bob_public_key. So. . .

1. txid = SHA256(alice_public_key CAT bob_public_key)
2. smallnums = CutCombWhere(txid) (Which produces an array of small numbers that sum up to 59213)
3. Generate a new BTC TX value by doing:
        N = 0
        SHA256(SHA256(59213-small_nums[N]), SHA256(apk_pi_array[N])) (How I intepreted SHA256^(59213-x)(y), let me know if I got the syntax wrong.)
        Encode the result to segwit.
    Repeat with N+=1 until the last loop of N = 20.

To validate Alice's starting balance, she gives Bob the entire TX history of the public_key she used to trade? Is the correct?

"in which blocks and outputs it is buried (height of commitment). If it isn't buried,the payment is rejected."
I don't understand what "buried (height of commitment)." mean in this context. I get the general idea I think, you're validating the position of the transaction on the Host Chain (?), but I want to understand 100% what you mean.



I get the steps that Bob walks through here, but I'm not able to understand/appreciate the relationship between the numbers and functions used that allows for this to actually work. I'll figure it out in the future though, but for now I want to get the non-crypto steps locked in my head first. Thanks for being patient with me

Also, kelozar, I'm stuck on 2 PMs per day, I'll message you again they let me lol.

Alice owns 999 tokens on a haircomb public key bignum_0. She also knows the corresponding preimages bignum_1,bignum_2,bignum_3...bignum_19,bignum_20,bignum_21.
Bob generates an address bignum_22.
Alice wishes to pay and permanently redirect all her funds from bignum_0 to bignum_22. She calculates the "transaction" bignum_23=SHA256(bignum_0 concatenate bignum_22)
bignum_23 is inserted into the function CutCombWhere(), smallnum_1,smallnum_2,...,smallnum_21 = CutCombWhere(bignum_23)
All the small nums (smallnum_1,smallnum_2,...,smallnum_21) are unsigned integers less or equal to 59213 and for any specific CutCombWhere input they sum to 59213
Now Alice does the signature
bignum_24 = SHA256^(59213-smallnum_1)(bignum_1)
bignum_25 = SHA256^(59213-smallnum_2)(bignum_2)
bignum_26 = SHA256^(59213-smallnum_3)(bignum_3)
...
bignum_44 = SHA256^(59213-smallnum_21)(bignum_21)
The signature is then committed to using the whitepaper

bignum_45 = SHA256(whitepaper concatenate bignum_24)
bignum_46 = SHA256(whitepaper concatenate bignum_25)
bignum_47 = SHA256(whitepaper concatenate bignum_26)
...
bignum_65 = SHA256(whitepaper concatenate bignum_44)

Now bignum_45 ... bignum_65 is segwit encoded and propagated on chain. When there are sufficiently
many confirmations, the haircomb isn't in address bignum_0 anymore, it is now in the address bignum_22.

To prove to Bob that the haircomb is now in the address bignum_22, Alice does the following.

She gives bignum_24,bignum_25,bignum_26...bignum_44 to Bob. (The signature)
She gives bignum_0, bignum_22  to Bob. (The "transaction")
Additional proofs that the haircomb public key bignum_0 contained 999 tokens in the first place ("transaction history")

Now first of all Bob validates the transaction history and realizes that Alice really owned 999 tokens on a haircomb public key bignum_0

Secondly Bob checks if the signature is really commited to on chain and in which blocks and outputs it is buried (height of commitment). If it isn't buried,
the payment is rejected.

Bob independently calculates the "transaction", bignum_23=SHA256(bignum_0 concatenate bignum_22)
From this, Bob independently derives the same small nums (smallnum_1,smallnum_2,...,smallnum_21) using the CutCombWhere(bignum_23) just like Alice did.

And Bob can check for double spend by hashing the value bignum_24 smallnum_1 times. After every iteration he gets a different "X". Every different
SHA256(whitepaper concatenate "X") is looked up on-chain to see if there is conflict (if the conflict is buried earlier than our height of commitment).

Bob also checks for doublespend hashing the value bignum_25 smallnum_2 times.
Bob also checks for doublespend hashing the value bignum_26 smallnum_3 times.
...
Bob also checks for doublespend hashing the value bignum_44 smallnum_21 times.

Finally, a byproduct of this doublespend checking are the last values of "X" (bignum_66, bignum_67...bignum_86) for every one of the 21 teeth. Bob in the end checks,
to see if the Alice's haircomb itself is genuine.

bignum_0 = SHA256(bignum_66 concatenate bignum_67 concatenate ... concatenate bignum_86 )

and compares this bignum_0 with the bignum_0 from Alice.

If there was no double spend - the funds are now in Bob's possession (in the address bignum_22).

I mostly answered my question reading the whitepaper again, but I still have something to clear up.


I want to make sure my understanding is correct. The steps, as I read them, are as follows:

STAGE 1:
1. Take the first number of the signature of the sender's signature (n)
2. Hash n using SHA256(whitepaper + n)
3. Convert into a HostChain segwit address
4. Repeat for remaining digits

STAGE 2:
For each address generated in stage 1, find the hash of SHA256(source_address, destination_address), convert to segwit, and tip?

This seems incorrect. I'm confused by the following lines in the whitepaper:

and

The first line suggests you're turning the signature digits into segwit addresses before hashing again, which doesn't make sense to me and seems incorrect. The second line(s) suggest you're tipping to a hash of two keys. Is the "source address" supposed to be interpreted as ONE of the 21 generated hashs, and my putting step 3 in Stage 1 was a misunderstanding? This makes the most sense to me, but I want to be certain. The reason I placed step 3 in there is due to the order of the quoted lines, and the use of "source address."

Assuming that I'm correct about that, then another question I have is what's stopping somebody from tipping the same address to execute the transaction a second time? If Bob sends a portion of his fund to somebody using a liquidity stack, and the remainder go back to his wallet, what's to stop the recipient from just tipping the same segwit address again to initiate another, identical transaction? I understand in BTC the signature changes for each transaction entry, but I don't see how you get the same effect in the Haircomb system. Cryptography isn't my strong suit, if someone could tell me what I'm missing I'd appreciate it.

EDIT: Reading the whitepaper again, it seems like what probably happens is something like the following (this will also highlight what I'm not understanding yet):

1. Take the public key and run the signature function f(public_key, )
2. Take the signature and create a hash for each number as n in SHA256(whitepaper + n)
3. For each result, do SHA256(result + destination_wallet_public_key)
4. Convert those hash results to the addresses
5. Tip said addresses.

This makes the most sense to me. I still don't know what the part of the signature function is though, and I don't understand the actual signature function itself, although I don't need to or expect to (at least, not for a while)

I still don't understand how the heck the haircomb transaction data is hosted within the bitcoin layer 1 data. If someone could explain that to me I'd appreciate it greatly.

EDIT: After doing some more reading I understand it better, however I'm confused about the wording in the whitepaper. I get that the transaction details are encoded into the segwit addresses of bitcoin transactions, you fund the generated segwit address with BTC to execute a transaction. The part I'm confused about is the wording or:


I'm assuming the change address is the a receiver's public key, and the output address is the sender's private key, correct? Otherwise wouldn't anybody be able to initiate transactions from another person's wallet just by knowing their public key? I only ask because the wording isn't exact in the paper, and I want to be sure I understand exactly what's happening.


I'm also having trouble understanding chaining liquidity stacks. From the whitepaper:


But if the child stack address needs the parent stack address to be generated, then that's just a recursive loop, isn't it? Both stacks need input and destination? What am I not getting here?


Maybe I'm just misunderstanding Liqudidity stacks and their roll in transfers. After doing more reading of the thread it seems i was mistaken in thinking they'd be used for direct transfers. If someone could walk me through the mechanisms of basic payment, I'd appreciate it.
EDIT:

I read through https://bitcointalksearch.org/topic/m.53053908 and got a better idea of where my stack confusion was. This has brought a different question to light however, and I'm confused as to where the 21 tx number is coming from when, in the past, people spoke about needed to send BTC to 21 addresses in order to run a haircomb transaction. This is the bit I'm stuck on, what the mechanism of funding a basic transaction is.

It doesn't AFAIK.

github code doesn't matter, if it connects to the internet it can download virus code.

You can go through the code for yourself here: https://github.com/natasha-otomoski/combfullui

There's also a guide on how to compile it a few pages back in the thread.

tried out the wallet. now I'm having weird issues with my computer like random usb disconnects, lags while typing, app freezes... are you sure this thing doesn't have a virus in it?

So I just got into blockchain stuff about a month ago. Maybe it's my ignorance talking, but this looks like the coolest thing that exists right now. I don't understand how more people aren't freaking out about this. Correct me if I'm wrong, but it seems like Haircomb has the potential to essentially hijack BTCs own chain and become the main usecase for it.

I get an ERR_SSL_PROTOCOL_ERROR when I try to connect to https://127.0.0.1:2121/

EDIT: Fixed it by going to chrome://net-internals/#hsts and deleting the localhost security policies.

Hello

There is a new tool to download commits.db file without modified bitcoin

use at your own risk

https://pastebin.com/5thcx9jn
https://paste-bin.xyz/paste.php?id=8448

It downloads directly from other bitcoin full nodes about 250 GB data, and the 95MB commits.db is created.

Yes this means about 250 GB of internet traffic is used, (it takes about 1-2 days) however there is no need to have large hard drive, 100MB free space is enough.

Biggest flaw is that the download cannot be currently resumed, so if you stop it then you get a short file with no ability to continue the download later.

Dont think theres much demand or even interest in the project anymore. Seems kinda ded, dev hasnt worked on anything or replied to any dms since open source

Are you using info from modified core to see whats the highest paying new p2wsh output.
I have plenty claimed i can also sell if you would like offer.

we are passed block 636363
I will be using 330 sats for transferring of comb and for claiming of comb.

Also if anyone would like to buy some comb. I have claimed a decent amount and don't mind to help distribute at a cost of 50k satoshi each comb.

I will be willing to claim for them for a fee.
Maybe sell some of my comb and use the funds to claim back more
How much comb are they looking for with 3btc ?

I am willing to pool some of mine

ok we can do it starting from block 636363.


By the way I've been contacted by an undisclosed person who is willing to acquire
a 3 BTC worth of Haircomb token. I told the person to claim on the free market, but
out of interest, would anyone be willing to fill such an order?


The way I see it 3 BTC may well be worth more than the entire supply.

Yay, for my part

I am proposing we switch to 330 satoshi claims and 330 satoshi fund for transaction.
This will be good reduction in cost to send comb.
If anyone objects please tell us why. Otherwise lets all agree to 330 satoshi. If in future miners and wallets default less we can switch again.

followed the steps, interesting to note i already had C:\Go\bin in the variables.
so i gave it another try, and everything worked.

success, running  the new comb0.3.3

thanks for helping