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

Cool, thank you for taking the time to explain how this would be done. It's beyond my coding ability but I will try to work through the process and see how far I get.

Hi

Haircomb on litecoin is a possibility, it will be a separate coin (only on Litecoin assuming that's what you want).

I will just briefly write what is the minimal effort you need to do in order to kickstart such a coin.

First of all you need a white paper preferably you put some recent LTC block-hash into the
whitepaper to prevent a premine.

Briefly explain in your whitepaper the subsidy formula at minimum so that people at least
know how many tokens they claimed by a valid claim on a block.

You can code any subsidy formula in coinbase.go just recode the Coinbase(height uint64) function.

Just make sure there is not some kind of numeric overflow in 64bit monetary amount when you add too many subsidies to one wallet.

Next take SHA256(whitepaper.pdf) and put that into commitment.go file.

Next to actually claim you need to modify bech32get in sign.go to match litecoin format. I think just change "bc" to "ltc"

Recompile combfullui.exe

Next you can start modifying litecoin core. You need to modify it in the same manner the Natasha
modified bitcoin core.

Each time a block is added to a litecoin longest valid chain you need to call (for every long ltc address in the block)
the following endpoint of haircomb core.

http://127.0.0.1:2121/mining/mine/{commit}/{utxotag}

also at the end of block you need to call it one more time to flush it.

The flush comand has arbitrary 256bit commit (for instance FFFFFF... it's not used for anything) but it must have utxotag = 9999999999999999

You can be loading the commitments in the following manner:

suppose there was address funded on litecoin chain:

ltc1qguz6pay8hvv0qsd07wtptcfx5wjxa8tqququgurlvm2yfaj9txqsn8xsdv

mined for example in block 1673450

Now when your litecoin core adds this block to his longest valid chain the above address (output) in hex:

00204705a0f487bb18f041aff39615e126a3a46e9d600701c4707f66d444f6455981

you discard the 0020 from the beginning and call over http (also it needs to be uppercase because Natasha hated lowercase):

http://127.0.0.1:2121/mining/mine/4705A0F487BB18F041AFF39615E126A3A46E9D600701C4707F66D444F6455981/0167345000000001

the 00000001 at the end is some kind of iterator I think recent combfullui.exe after fork does not even use it for anything so
you can supply 0,1,2,3 from the block or whatever (which one long address inside the block it was) it just must be unique

then you flush it:

http://127.0.0.1:2121/mining/mine/FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF/9999999999999999


and now this commitment appears in the litecoin commits.db file (but only if the address was funded the 1st time!) and triggers
any transactions in the wallet that require it.

But you need to be loading blocks in the correct order obviously. You can't load block 123 and then 122.

Recompile litecoin core and sync it.

Go into your wallet generate a key and claim some litecomb. Fully save your wallet. Good luck.


Now there are many ways that can go wrong if this gets widely used and I don't actually encourage to do this.

For instance somebody can pay from litecomb key and somebody can replay that payment to haircomb on bitcoin.
secondly people can confuse addresses, pay litecomb to normal haircomb address and get glued coins
the coin can pump and dump and never recover causing financial loss
and many more things

but it will work for experimental purposes.

I think technically it could, but you'd have to run a full node of both chains at the same time. I'm not sure on how the claiming process would have to adapt though.

I'm very interested in running haircomb on Litecoin. What would it take for a port?

From a practical standpoint, it would make a much lower and more reasonable price acquisition floor for comb.

I can't tell right away, but would BTC-comb be compatible with LTC-comb? Could it be made compatible?

This is a really good point, the fact that you'd essentially be taking pressure off of the BTC economy and fees by having haircomb be a reward in a symbiotic relationship, that's really interesting. I was looking at the claim monopoly as a bad thing, but this makes sense in the wider environment when you include bitcoin.

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.