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

Okay so liquidity stacks only siphon once, then afterwards that essentially act as a normal wallet that's been connected to another wallet downstream, right? So if Chris then came and payed out X combs like:

SHA256(chris_1, SHA256(alice_new_address CAT alice_old_address CAT X))

All of Chris's combs would end up in alice_new_address.


Alright, it makes sense that it would work like this, although it'd be a pain for the user to operate. Correct me if I'm wrong, but the steps to pay anybody are:

1. Save old wallet
2. Generate new wallet
3. Save new wallet
4. Copy new wallet public key to clipboard
5. Import old wallet
6. Begin payment process with the new wallet public key on the clipboard.

I wonder if there's a UI way to make the user experience easier. Like, when you initiate a payment, there's a form on the UI that has a place to enter output/output amount like normal, but instead of just a field to paste the new change address, there'd also be a button that said "Generate New Wallet Address" or something like that. Clicking it would make a popup appear that just had a name entry field, and if you put in a name and hit ok, it would generate a new wallet.dat file with a new private key, save it with the name you put in, and then automatically fill the change address field with that wallet's public key. That way you could still enter in all the details manually if you wanted, but from a normal user's convenience perspective, you take all 6 of the steps from before and combine them into one single button press.

I wanna try and build a basic GUI for the wallet first, but something like this makes sense to do next. Can you foresee any problems if this was to be implemented?


More questions about transactions; the 21 hostchain TX requirement. First, are these all required to be entirely separate transactions, or can you batch transact them? I.e. Do you have to pay 21*TX_fee? From what I've read and got from speaking with Kelozar, you can't batch transact them, and if this is true, I'm curious as to the reason for it, but also if you could batch those transactions in such a manner that you'd be able to roll for more haircomb claims? I.e. one TX per hostchain block, then have the first TX in the list be the mining address, and the second be the TX signature address?

Another question is why can't Alice just give Bob the old wallet's private keys? Every transaction burns the previous wallet effectively, correct? If this is the case, then even if Bob had the private keys, what could he actually use them for? The wallet is already connected in the system to dump any funds it receives.

EDIT 3: Think I get the double spend bit now. If the funds were spent before, then at least ONE of that transaction's hash chain results would be greater than the corresponding result for the current transaction hash chain, and he'd find it, because of the totalling up to 59213 rule with he small numbers.

My question still stands though, why can't Alice just give the private keys to Bob, if she's making a new wallet after ever TX anyways? Am I misunderstanding something about the new wallet process?

EDIT 4: Cleared up a bunch of verbal diarrhea to make the post more readable.

Liquidity stacks have a threshold for how many funds are siphoned
off FIRST TIME the "water" passes through. Any additional time
the same or different water passes through, the stack output is already
satisfied and the water simply flows down towards the CH (change address or the next stack entry).

Siphoning off X water every pass would not work well, because then you could
form a coin eating loop with X water forever getting siphoned into the OUT returning back into the same stack.

The way the wallet works is secure in this manner. The worst thing the Alice can do from the user interface
is to pay to alice_old_address, forming the liquidity stack loop and this loop is not coin eating.

Example:

txid = SHA256(alice_old_address CAT SHA256( alice_new_address CAT alice_old_address CAT 1 coin ))

Her coin will simply take one full loop and fall into the alice_new_address:

1. 999 coins depart from alice_old_address into the stack
2. The stack discovers that 999 >=1 coin arrived.
3. The stack triggers and temporarily puts 998 coins into the alice_new_address and 1 coin into alice_old_address
4. There is now 1 coin into alice_old_address, it flows back into the stack
5. The stack discovers that 1 coin arrived but stack is already used.
6. The stack temporarily adds the 1 coin to alice_new_address (reason: stack already used)
7. There are now 999 coins in alice_new_address, coin propagation ends

See? Everything is safe for the end user even though 1 coin took a loop. She simply paid to herself.


Yes. She needs to save the new private key carefully on disk before every time she pays. She also needs to carefully save the complete liquidity
stack she intends to pay to on disk before she pays. Both objects are stored inside her new wallet.

If she were to lose the stack after she pays to it the funds will be lost. The reason is, she has no proof to give to Bob.

Okay this answers that question, and the question that immediately arises is of course that wouldn't this prevent Alice ever paying Bob the same amount of money twice? But you answered it already with:


Okay so that makes sense. Liquidity stacks also operate like connected pipes forever, they just have a threshold for how many funds are siphoned off every time the "water" passes through. So if Alice redirects back to her original address, the water is still in the same pipe, and just gets looped forever, siphoning off X water every pass.

Then my next question is, where does Alice's new_address come from? Are you saying that Alice has to generate and save a new wallet every time she wants to move any amount of funds to people?



Yea the combined transaction process is awesome, it makes more sense too now that I understand the pipe analogy (lol literally LIQUIDity stacks). It helps to imagine the funds as permanently in motion, just impeded by a lack of place to go, until a "transaction" opens a valve and they just flow down to the next guided place.

I'll leave decider questions for after I properly understand this process then. Thank you again for your explanations, I have a TON of questions, and this is way faster and easier than having to try and dive through the code myself and try to build an understand from that alone with no assistance.

Yes you are right about comb transaction, it's just like a water pipeline in between two addresses.

Liquidity stack entry is like an open tap on the pipeline that pays specific number of coins to Bob.
After that the tap closes.

The scenario in which Alice permanently redirects funds to Bob is possible. But it is not done in practice
precisely, as you correctly noticed, is to avoid Alice losing control of future incoming payments to her old address.


Tipping the same addresses has no effect. Only the first time tips to a certain segwit address triggers an action.

And there are no funds in Alice's old address anymore. Everything is either inside liquidity
stack, inside Bob's wallet and or inside Alice's new address.

So, to pay Bob 1 coin alice signs the transaction:

txid = SHA256(alice_old_address CAT SHA256(alice_new_address CAT bob_address CAT 1 coin))

but not what you wrote:

txid = SHA256(alice_old_address CAT SHA256(alice_old_address CAT bob_address CAT 1 coin))

because this would cause 1 coin to go to Bob and the remaining Alice's coins would get looped in a coin eating loop.


The exciting thing about the liquidity stack is how no matter how many receivers there are, only the 21 addresses need to be funded.

For the first time in history Alice can literally pay to millions of people on the Bitcoin chain. Here's how:


stack0 = alice_new_address

stack1 = SHA256(stack0 CAT person1 CAT 0.00000001 coin)
stack2 = SHA256(stack1 CAT person2 CAT 0.00000001 coin)
stack3 = SHA256(stack2 CAT person3 CAT 0.00000001 coin)
....
stack999999 = SHA256(stack999998 CAT person999999 CAT 0.00000001 coin)
stack1000000 = SHA256(stack999999 CAT person1000000 CAT 0.00000001 coin)

txid = SHA256(alice_old_address CAT stack1000000)

When Alice signs txid and commits to it with 6 confirmations, her 0.01 coin gets paid to 1000000 people (0.00000001 coin each).


Deciders are a different matter altogether.

Woah. Ok I can understand that conceptually, but it'll take be a bit to get a good visual for it in my head lol. That's super cool.

So wait, then if Alice pays Bob (alice_pubkey_1 -> bob_pub_key_1), you're saying it binds the accounts together in a way? So in the future, if Chris pays Alice using the same public key that Alice used to pay Bob (chris_pubkey_1 -> alice_pubkey_1), would the funds go to bob_pubkey_1? I'm visualizing it like water in a tube, the end being capped off by whatever the last public_key in the chain in. Put water in the beginning of the tube (Chris->Alice) and it flows down to the bottom. Add an extension to the bottom of the tube(Bob->Daisy), and all the collected water flow down to whatever the next bottom is. Is this correct? If it is, this flowing effect would also apply to all deposits into the top of the tube (Chris) that were made using liquidity stacks, yes?



Yea I got the application of them to some degree from going through the explanations in the thread and the whitepaper, the whole stack-chaining process is interesting, but there are definitely large chunks of my understanding missing, of what exactly is happening lol, e.g. I have no idea what "Deciders" do.  But is my question in the other post not still valid when using Liquidity stacks?

1. Alice pays Bob 1 comb using a stack defined as SHA256(alice_pubkey_1, bob_pubkey_1, 1*), and the payment process as outlined above.
2. Bob wants to take more of Alice's money, he tips the same addresses that Alice did when she transferred to the liquidity stack.

Actually, going back and reading the thread, is this what the purpose of Deciders is? To validate liquidity stack based transactions? I can't see any real explanation regarding them, all I've got is what I've been able to infer from the trade event that took place. From what I'm reading, it seems as if they're used to execute specific functions/events during transfers, potentially after the funds have hit the liquidity stack? The fact that there's a "forward" decider and "rollback" decider is what gives me this impression, however looking at the Wallet UI itself, I have no idea how to use them.

Yes I understand.

To explain, these simplest possible kinds of haircomb "transactions" aren't really transactions with 1 input and 1 output just
like in Bitcoin. The concept of the haircomb "transaction" is very different from Bitcoin.

It is more like a permanent redirect of all past, present and future funds.

1. Alice permanently redirects funds to Bob (alice_pubkey_1 -> bob_pubkey_1) and signs off the redirect on-chain
2. Bob permanently redirects funds to Alice (bob_pubkey_1 -> alice_pubkey_1) and signs off the redirect on-chain
3. Now where did the coins go? Clearly, the coins must be in some kind of an infinite loop now.

More precisely the coins are deleted by the wallet due to a coin-eating loop in the graph.

To prevent this problem the wallet contains a loop detector that is run before signing every transfer. So in reality it
will go like this:

1. Alice permanently redirects funds to Bob (alice_pubkey_1 -> bob_pubkey_1) and signs off the redirect on-chain
2. Bob tries to pay to alice_pubkey_1, coin loop detector is run
3. Bob's wallet warns Bob about the loop and does not let him to proceed.

Now, if you wish to pay someone using haircomb without permanently redirecting the funds you would use liquidity stack to do that.

Liquidity stack transactions are much more similar to Bitcoin transactions and they are known to not be affected by the permanent
redirect nature of the simple transaction at all.


But liquidity stacks are really difficult topic. To begin, you don't pay to Bob's address but you pay to a liquidity stack entry.
The liquidity stack entry then pays to Bob a specific number of coins and the change is redirected to a new hair comb (fresh public key) of Alice.

Alright, that makes sense.


Oh no problem, the now that I understand it it makes sense, SHA256 to the power of X on Y.


Lol the more I understand the cooler it gets. So to be certain, it's not a single loop, it's nested loops? i.e.
   
    small_nums = [small_num1 . . . small_num21]
    big_nums = [big_num1 . . . big_num21]
    bignum_output_array = []

    n = 0, while n < 21:
       
        //setup the corresponding numbers
        hash_num = 59213-small_nums[n]
        bignum_output = big_nums[n]

        //Hash the bignum X times, where X is hash_num
        while hash_num >= 0:
            bignum_output = SHA256(bignum_output)
            hash_num -= 1
       
        bignum_output_array.append(bignum_output)
        n+=1




So I guess one thing I still don't get, it what separates transactions that look the same?

1. Alice pays Bob (alice_pubkey_1 -> bob_pubkey_1)
2. Time passes. Bob needs to pay Alice now (bob_pubkey_1 -> alice_pubkey_1)
3. More time passes. Bob and Alice get in a fight, and stop being friends. Bob wants to steal his money back from Alice. Why can't he just tip the same segwit addresses that Alice tipped in the first tx(alice_pubkey_1 -> bob_pubkey_1)? I feel like I'm missing something about the transaction process, because what's stopping somebody from perfectly replicating a previous transaction? The only thing that seems to get encoded is the is the origin and destination of the funds.

haircomb corresponding preimages (bignum_1,bignum_2,bignum_3...bignum_19,bignum_20,bignum_21) are simply the private key of the haircomb.
They are 21 true random big numbers Alice generated when creating her wallet key.
alice_public_key = SHA256( SHA256_59213_times(bignum_1) CAT SHA256_59213_times(bignum_2) ... CAT SHA256_59213_times(bignum_21) )

Sorry my syntax is weird, but it's simply to run SHA256 many times on an input y. Example: SHA256^(2)(blockheader) is the mining function of Bitcoin.

In step 1 you are correct she does the txid from both the old and new public keys
In step 2 you are correct she does the small numbers that sum to 59213

What needs to happen next:

bignum_1 is hashed 59213-smallnum_1 times to get bignum_24
...
bignum_21 is hashed 59213-smallnum_21 times to get bignum_44

Example: Alice wishes to sign number zero because txid = 0 (txid=0x000000...00000000, in practice this won't happen, just an example)
 
step 2. CutCombWhere(0) = [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 59213]
step 3:
Alice hashes her first private key value "A" 59213-0 = 59213 times and gets resultA. SHA256(whitepaper CAT resultA) is stored on chain.
Alice hashes her second private key value "B" 59213-0 = 59213 times and gets resultB. SHA256(whitepaper CAT resultB) is stored on chain.
...
Alice hashes her last private key value "U" 59213-59213 = 0 times and gets resultU. SHA256(whitepaper CAT resultU) is stored on chain.


After 6 confirmations Alice reveals resultA....resultU to Bob.

Now Bob is able to verify the SHA256(whitepaper CAT result) is stored on chain for every result. He is also able to verify there is
no double spend, using the described method, this is sufficient for the crypto currency to work.


Another example:

Alice wishes to sign the largest 256-bit number txid=0xFFFFFFFFFFFF...FFFFFFFFFFFF

CutCombWhere(0xFFFFFFFFFFFF...FFFFFFFFFFFF) = [20749 2206 197 1147 1200 45 2983 1472 616 140 1230 3806 3140 1031 3025 1551 136 4753 123 1412 8251]

First private key value is hashed 38464 times.
Second private key value is hashed 57007 times.
...
Last private key value is hashed 50962 times.

This is how Alice is able to sign arbitrary 256-bit number txid.


About transaction history. If Alice is the first owner the history is just empty. Otherwise, it contains the proofs from all the previous coin owners of the coin.

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