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

I finally had some time to work on a GUI over the past week.

RakeCOMB v0.1.0 can be found here: https://github.com/nixed18/RakeCOMB

Current Functionality:
 - Save and Import wallets
 - Receive transfers
 - Browse accounts and stealth addresses
 - Generate new accounts
 - Incomplete commits validation
 - Safe shutdown

Place the exe and then pck in the same folder as your .dat files so the Import can detect them.
Transaction initiation and TX History browsing are planned for the next version. Let me know if you have any thoughts.

Also, if anybody can identify what font Natasha used in her first post's infographic, I'd appreciate it

Made a telegram for COMB for those interested. t.me/comb_talk

I have a couple questions about the way the coin history and wallet work.

1. If I receive comb to a stealth address that's already been swept, the wallet realize this and automatically drop the comb in my main wallet, or should I never reuse a stealth address like this?

2. Related to the previous, if Bob sends comb to Cindy, and then Alice sends comb to Bob's old wallet, can she just give the coin history to Cindy and have it transfer into Cindy's wallet? I realize this is an odd process that would most likely never occur organically, but it's interesting to think about.

EDIT: Looking into the way that the wallet files are store, it seems like the answer to the first question is yes, it would work to receive at previously swept addresses, however I'm still not sure about the second question's answer.

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