[ANN][COMB] Haircomb - Quantum proof, anonymity and more

[kelozar]

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.

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 ?

[kelozar]

ok we can do it starting from block 636363.

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.

[kelozar]

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.

[kelozar]

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

[watashi-kokoto]

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.

[nixed]

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.

[nixed]

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.

[desu2bdesu]

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?

[nixed]

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?

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.

[desu2bdesu]

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?

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.

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

[nixed]

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?

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.

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

It doesn't AFAIK.

[nixed]

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:

Liquidity stack is a triplet change address CH, output address OUT and output
amount (64bit). The liquidity stack address is simply SHA256(CH + OUT + out).

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:

To chain liquidity stacks to form longer stack you use the child stack address
as the change address CH of the parent stack segment.

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://bitcointalk.org/index.php?topic=5195815.msg53053908#msg53053908 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.

[nixed]

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

We have observed that signature is just 21 numbers. Suppose we want an anonymous
token. We take the hash commitment of each of these 21 numbers. It has to be
a different function than SHA256(x) because that would simply calculate the next
value in the hash chain. RIPEMD or SHA3 or whatever would work too, but, my
token uses for this SHA256(whitepaper + x) where + is concatenation.
This has the added benefit that every coin user implicitly signs-off the rules
of the token they are supposed to abide by (especially users who generate coins
will do this too, so that they know how many coins they just generated).

Commitments are then turned into P2WSH addresses and users "tip" to these
addresses to confirm the transaction. Transaction is just hash of two hashes:
source address and destination address. COMB Address is for example X (a pubkey),
or it can be some other type of address, like a liquidity stack or Merkle tree
segment[4].

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:

Commitments are then turned into P2WSH addresses and users "tip" to these
addresses to confirm the transaction.

and

Transaction is just hash of two hashes:
source address and destination address. COMB Address is for example X (a pubkey)

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)

[watashi-kokoto]

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).

[nixed]

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.

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 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.

[watashi-kokoto]

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.

[nixed]

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) )

Alright, that makes sense.

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.

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

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.

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

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.

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.

[watashi-kokoto]

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.

[nixed]

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.

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?

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.

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.

[watashi-kokoto]

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.

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.

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.