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

miners will be side mining comb some day if this becomes successful.
it seems like there is several stages, first stage anyone can claim. second stage mostly batched txs of exchanges will include and they will be predominant claims. third stage miners will add the comb tx to their btc block reward and side mining comb while mining btc.
this has always been the idea that eventually miners will most likely start mining. (adding the comb reward for themselves)
by then comb has to have already be valuable.

this helps miners because in the event that in the future their btc rewards are very small, comb rewards might be bigger then the btc reward. (if comb actually gets adoption) this can help miners incentivize and keep securing btc.
another good point is because claiming comb or sending comb burns btc. it creates a deflation on btc and rising the value of btc slowly too.

but yeah if you look at previous discussions, i think we all pretty much assumed that if comb becomes more adopted. miners will eventually claim the reward for themselves. if that ever happens that would mean comb has become successful enough for them to even care about it.

i dont think changing the rules is needed. natasha thought this through initially most likely and knew that someday if this takes off miners will be claiming.
thats why claiming now can actually be a good idea, cost/reward ratio. worst case u burn a bit of satoshi and make the remaining satoshis that much more valuable. best case that comb takes off and it was an asymetrical bet.

My BTC finally synced and I got to claim

A little tip for anybody else claiming for the first time, don't claim from a service like Ledger or Armory. For privacy reasons they redirect all of your that wasn't spend through to another public address, which means you end up paying 50% more than you would have to normally. This wouldn't be too much of a difference normally, but if you're claiming you're running high fees as well, so it's a bit much.

I had a thought about the claiming mechanism, in regards to future proofing against miners. Right now the system can be exploited by miners because they get to choose the tx order, and haircomb always gives comb to the first wallet in order, right? What if, instead of giving haircomb to the very first wallet, it gave it to a pseudo random wallet on the block. The first thing I thought of was doing something like taking the time that the block was found, i.e. 15:24:30, and looking at the minutes and seconds of the block to get a % value, based on how close it is to the next 10 minute increment. In this case the value would be 45%, looking at 24:30. Then, you'd look at the transaction outputs in the block, and find the unseen segwit address that was located closest to the 45% mark. So for example, in a block that had 1,624 transactions, the marked transaction would be tx #731 (round up from 1624*0.45=730.8 ). Then check the transactions beside that one, #730 and #732, and so on, until you hit an unseen segwit.

The problem with this is that a miner could technically write a script to rearrange the order of the transactions in the block every second. So instead of referencing the time that the current block was mined, what about referencing the time that the NEXT block is found? So if I tried to claim block 660000, I wouldn't actually know if I had been successful until block 660001 was mined, and that time could be referenced to determine the lotto winner on the previous block. This poses two obvious problems though; chance of claim and hard forking.

Right now, in the early stages of haircomb, people can actually try to claim via TX fee value. If this method was introduced, it'd be much more difficult to claim, even if you were purposefully attempting to. However, when haircomb gets more widely accepted, and people are through in claim attempts every time they perform a BTC transaction, you see more consistent claiming as a whole community.

The other worry is that it'd require a hardfork to implement. It's pretty early in haircomb's life, which would make it easier to do, however I dunno if it's something Natasha would want.

Any thoughts on this claiming methodology? Any problems with it I overlooked?

I'm compiling a list of questions, but a more immediate one that comes to mind that I want to confirm is when you send a multistack transaction, you'll need to send each stack recipient the transaction info, correct? What I don't understand is how someone who's halfway down the stack has enough information to confirm the transaction. For example:

Alice has 10 comb, wants to give 2 each to Bob, Chris, Dan, and Emily.

Stack_1 = SHA256(Alice_1 CAT Bob_1 CAT 2)
Stack_2 = SHA256(Stack_1 CAT Chris_1 CAT 2)
Stack_3 = SHA256(Stack_2 CAT Dan_1 CAT 2)
Stack_4 = SHA256(Stack_3 CAT Emily_1 CAT 2)

TX Key = SHA256(Alice_1 CAT Stack_4)

Is there more information given when transferring the TX history of a liquidity stack? Previously it was stated that, for a basic connection, the information that was given was the wallet addressed that made the TX Key, the history of the sending wallet, and the signature of the transaction (senders secret_keys hashed X times). In this example given, wouldn't you have to give everybody more information than that? Using just that info, I don't see how even Emily can confirm that she's received funds, as she'd need the Stack_3 address, and the amount sent to her, in order to confirm that the Stack_4 address was actually correct and contained her address. In a transaction like this, does the information given contain each liquidity stack address, as well as the amount sent to each of the stacks? This would make sense I think, because then you could just go down each stack address and check to see if SHA256(Alice_1 CAT my_address CAT amount) or SHA256(prevstack_address CAT my_address CAT amount) matched up with any of the liquidity stacks. Is this the case, or am I missing something?

EDIT: Looking at it more, wouldn't the receiver in a stack actually need all the information of every stack before them in the chain? So in the example I gave, Chris would need (Dan_1, 2), (Emily_1, 2).

Well, somebody made a website for haircomb: https://haircomb.mystrikingly.com/

I love the "About Us" at the bottom. "No Mission" and "We're not Hiring!"

agree best way to claim is bot that scans mempool. if new p2wsh output is under a certain threshold then attempt claim. if not try again after block is found. could also add some logic if you got outbid, to attempt outbid few times under a higher threshold.

That's a ton of data on those sites, thanks. I realize the best way to claim is always just gonna be a bot that is constantly checking and claiming if the price is under a certain threshold, but I think for someone who doesn't have access to that, theoretically you could establish a bit of a pattern in the hash rate levels and from that get certain times of day/week that are more likely to have cheaper claims. The question really is whether or no it's worth all the work, because it may be that just randomly checking the mempool will provide a negligible difference in claim price lol.

You cant really know bitcoins hashrate. All you can do is try to give an estimate based on how fast blocks are found on avg in past. Like last 50 Blocks last 100 blocks ect or how ever moving avg you want to use.
Bitcoins difficulty adjustment comes every 2016 blocks. So in the event where the difficulty adjustment was negative and a bunch of new hardware went online. Or there was alot of new hashrate right after a difficulty adjustment. Sure you can have blocks more often then 10mins on avg.

But more important is how full the blocks are and how backlogged the mempool is. Atleast for avg tx costs. Here is a good view to see the mempool.
https://jochen-hoenicke.de/queue/#0,24h

In the case of haircomb, it really depends on if there is someone sending new unseen p2wsh outputs and what fee they use as standard, and at what interval are they sending. So yeah faster blocks “can” help but your assuming avg tx cost is low because mempool is clear. And also assuming no1 is sending a high unseen p2wsh every 5-10mins.

Theres a few variables going on.

edit: looks like mempool.space has an upgrade to their charts now, showing similar data.
i still like jochen site better
https://mempool.space/graphs#2h

best climate for claiming comb (outside of specific high fee new p2wsh senders) is to look for times where the mempool is mostly clear and only cheap txs 1sat/vbyte ect.
thats just general. either way havent claimed or synced up in a while. so there might be bots claiming these days. if anyone is actively claiming or watching comb claims. please show some data. would love to see it. thanks!

edit2: if you want to watch hashrate estimates and difficulty adjustment estimates here is some more good data
https://diff.cryptothis.com/
https://bitcoin.clarkmoody.com/dashboard/

Still waiting on the BTC download, at one point it crashed and refused to load so I had to start it all over again. 44% done and the ETA is like 10 days, no clue why it's taking so long, but my impatience is killing me lol.

You could probably predict the best times to claim/transfer based on timing hash rate spikes. BTC changes its mining difficulty based on the rate of blocks being found, right? So if you could plot the average hash rate for every 10 minutes or so, then you could see when the total hash rate spikes, and blocks would start to be found faster, but the mining difficulty wouldn't ramp up until the next few blocks were found and it could actually detect the faster block speed. That'd be the best time to interact with haircomb I think.

The few times I've checked mempool.space and gone down the list checking segwit addresses, I typically see somewhere in a range of 450-650 sats/vB. But that's just randomly checking, not trying to time it for the cheapest claims.

not sure exactly how the decider and contracts work. but it seems like its a one way contract. where decider might need to be a "trusted" party?
maybe not. but decider seems like they say either contract will be accepted or declined. in the case of declined then the comb goes back to the original sender.
if accepted then comb is transferred to the recipient.

we might need more info on the decider and contracts to work out the details.

have you fully synced up and practiced claiming? have you seen the avg cost to claim atm yet?
let us know how that goes as im curious to know what is the avg cost atm

actually at the time of writing this, it seems like the mempool has been completely emptied! thats amazing news and would mean you can most likely claim for the cheapest amount, aslong as there is no1 else overbidding  you or anyone else sending a new p2wsh every block at a much higher rate.

it also means its a great time to consolidate any comb to a liquidity stack or to send any comb. would be the cheapest when the mempool is empty like right now!
can most likely send that 21 tx batched for 1sat/vbyte and get included would be cool.
ofcourse cant predict mempool activity for future perfectly but if we get a nice mempool clear even once a week on weekends like we had the whole year. would be great.

keep us posted on your journey.

I just spent a while trying to figure out how to reduce the transaction count, and the more tried the more I realized just how well the system is built.

I can't really make heads or tails of the Decider's and Contracts though. From the context of the thread I get they're involved with the trading process, I'm just not sure how exactly.

This makes sense, I forgot that it's sats/vB, there isn't a flat fee or anything. Thanks! It still should save some amount of money though, you're limiting the amount of times you have to pay for your account that's actually paying the tips. And yea I'm getting a little ahead of myself, I'm just impatient, the initial BTC download is taking forever.

I believe you CAN batch tx them. If im not mistaken i did batch them once

Edit:
You can only claim once per block, so batching claims would not work, if you are successful only the first will be a claim.
You CAN batch tx for the send proof 21tx. But since your paying fees for each utxo, your still paying fees for each output utxo you are creating. Even batched it will still be 21 outputs. Your paying for that data to be stored in the block chain. And for the miners to store that data in the next block for you. Not sure if its much cheaper or not batched. But i can confirm that i did batch my 21 txs for my comb transfers.

As far as ui your questions will be easier when you sync and see how the ui works.
The ui generates new addresses for you under a liquidity stack. So for example you can claim or attempt to claim for each new mining address that are all under 1 liquidity stack. Or you can do for different ones. But attempt one claim per block for reason i explained above.
No need to generate new address as the ui already generates many for you under each liquidity stack. But if you want a new liquidity stack you can generate a new address. Make sure to save the wallet file every time and have backups as well. Youll see how it works when u sync and try it.

There can definetly be more work added for the ui for claiming/ liquidity stacks. Ect
And i guess for the dex part too since idk if its even possible in the ui atm. As natasha was the only that did it so far.

Ui takes a bit to learn but it does work and its not too hard to figure out. Knowing whats going on behind the scenes and reading all the precautions written earlier. Those will help navigating ui.

Edit2:
To explainer easier think of it as wallet has address1. But each address1 can be a liquidity stack that has its own addresses2 that will automatically be connected to the address1.
Address1 has many address2 for liquidity stacks. So no need to “create” new ones you will see theres many many pages of addresses2 for each address1. All those addresses2 are all connected to the address1 liquidity stack.

Generating a new address1 is possible, its a simple click in the ui. Which will give you also many address2 for that new address1.

Address1 means the first addresses you see think of them as wallets inside your wallet. And then address2 is all the addresses that are inside each wallet. But all this is saved under 1 wallet file. So all the wallets inside and all the liquidity stack addresses for each wallet.

Youll see more when you sync up. Its easier to see then explain for me.

This is my experience from using testing ect. I have no professional knowledge of this or understanding whats going on so anything i say can be wrong. Just giving my experience/understanding

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.