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

Combfullui 0.4.0 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui-0.3.8-features/releases


Combdownloader 0.1.1 released. Upgrade is optional.
https://codeberg.org/watashi564/combdownloader-ng/releases


Combapp 0.0.6 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases



As always, you can experiment with a live instance:
https://core.haircomb.org

I don't understand some of the details of how liquidity stack works in Haircomb cryptocurrency. In the documentation it says that a stack is a construct, and "Constructs are stored off-chain in your wallet".

Is the stack object supposed to be created on the payer's or the payee's machine?

What happens when I send funds to a multipay stack which was created on another machine which is currently offline? Does it mean that all the payments that are defined by the stack will not happen until that machine is back online?

I have also seen in a discussion:


I didn't understand some details in this explanation.
How is the stack able to implement the transfer of the input funds to two addresses? I thought that in Haircomb we can only have no more than one directed edge coming out of an address.

I did not understand who "the observer" who decides when the stack should trigger is, and I did not understand the statement "all users do honor the rule." Does it mean that all users can see that the stack splits the input correctly? Does it not require that they could see the input amount (which should be hidden from most users)?
Or does it only refer to the user who owns the stack object? If so, why should we all trust him?

Combapp 0.0.4 available on F-Droid

https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/

New in version 0.0.4
CombApp 0.0.4

- New UI on port 21212
- RAM Pruning
- V2 Disk format (downgrade not possible after upgrade)
- Combdownloader 0.0.13
- Haicromb Core 0.3.7

Haircomb Core 0.3.7 available
Combdownloader 0.0.15 available with windows timers fix


Future development and all bitbucket repos will move on to:

https://codeberg.org/watashi564

Haircomb Core 0.3.6 available

https://bitbucket.org/watashi564/combfullui-0.3.5-liqtree/downloads/

Note: To fix bitbucket downloads page, a small bump to 0.3.6.1 was required.
The code for 0.3.6 and 0.3.6.1 is identical.

Combdownloader 0.0.12 available

https://bitbucket.org/watashi564/combdownloader/downloads/

Combapp 0.0.3 available on F-Droid

https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/

All known issues are patched in  Haicromb Core patched 0.3.5.1
code here:  https://bitbucket.org/watashi564/combfullui-0.3.4-testnet
Combapp 0.0.2 is available with the fix for android,
 here: https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/
All users must upgrade

I am investigating a security issue, in all versions of haircomb core. The latest git version is believed to be patched.

The attack is that certain commitment orderings could lead to doublespends. The real rule should be that all commitments above the frontier
need to have utxo tag greater than the greatest (most recent) utxo tag on the frontier.

This is true for both haircomb, decider.

I don't know if someone (else) knew about this and could doublespend, if so, the fixed version will siphon the attacker funds out from the economy (if there are any such funds).

Focusing on the accelerator stuff early makes sense to me. Turbine stuff is neat and all, but it only really becomes relevant once it becomes too expensive to normally transaction COMB on the BTC chain; this likely will take a while.

The thing I'm starting to look at is adding in the liquidity trees. It's just a basic coding change, it shouldn't be too crazy, but free history filesize is important to have early IMO.

Hello. The app release is very good, should run on most phones with armv8.

Get it on F-droid:

https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/

As mentioned above, there are number of known issues (mainly manifesting on newer phones).

Important:

Future development of haircomb core

I want to integrate accelerators more into haircomb core. I hope to have the current accelerator hash
the user is synced to shown on the main page.

A separate html page will be published that shows the current accelerator hash from the blockchair api. Said page can be hosted on public server etc.

I want to make haircomb core to work on phones with less RAM. Towards that end, we'll try integrating cuckoo filter.

Anyone wants to change something in haircomb core?? Speak up!

Future development of related projects

There are multiple ideas floating around about what to do next, like the accelerator network, about doing the turbine, eternal file etc.
We want to make sure these ideas are well understood but in the end it matters what ecosystem a coin provides, even without quantum computers etc.


So, let's try our best 

Android wallet app released a little while ago :O

https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/


I need to do the reading on the accelerators, I'm not up to the level of discussion that dyoform and watashi were having on it yet.

We talked about this on TG/matrix, but I will reply here for posterity.

Yes that is a consensus change.
When creating libcomb I wanted a simpler abstraction of how Haircomb works and part of that was simplifying claims into two seperate systems:

• The first commit in a block is given a reward
• If A is revealed then a balance edge is created from commit(A) to A.

This has the side effect that commit(A) is a stealth address for A. I also talked about this change in the combcore docs.
For the initial release I didn't want to have consensus changes from natasha's so removed this functionality, but as you point out the changes remain for claims.

I will change this to match natashas on the next release and sometime in the future we can discuss possible consensus changes (probably after libcomb has a test suite).

TLDR, I forgot to fully revert a consensus change to match natasha's before releasing libcomb.

Hello, there seems to be a consensus problem in libcomb

When you spawn a comb base, you write it to the balance map at the combbase commitment.


The problem is, that someone can pay coins to the combbase commitment. If the coinbase winning address is then revealed, not only the reward but also the coins that were paid to there will be awarded:



This is also problematic because final balance will depend on the order of operations, which it can't (operation reveal combbase, operation pay to combbase commitment)


In Natasha's version, payment to combbase commitment is a coinburn, the paid coins won't come out (just the reward, using the balance_do call in segments_coinbase_trickle).

So i've reimplemented Haircomb (no actual forks yet)
First off its been separated into 3 parts that are fairly isolated from each other: libcomb, combcore, and combcore-qt. Which is the library, the daemon and the GUI respectively.
There's a couple of reasons for the rewrite, the big one is to reduce complexity in the high stakes areas so devs can read/audit the important code much more easily.
Another is to make the codebase more approachable, if you want to develop a GUI you don't need to be digging around in important signing code etc.
Finally its so more features can be added relatively painlessly (P2P mining, integrated DEX, lightwallets, auctions, etc have all been talked about).

https://github.com/dyoform/libcomb
https://github.com/dyoform/combcore
https://github.com/dyoform/combcore-gui

Binaries are here (Qt is statically linked on the windows release):
https://github.com/dyoform/combcore/releases

I mention most of the important changes in the combcore readme. If you can read code then libcomb is where all the important stuff is, its also very small (only ~1k lines) and as simple as I could make it. I should also say that the current system of mutex's is going to be replaced when i implement P2P, so there may be race conditions etc (none that ive seen though).

Right now im preparing libcomb to optionally operate in lightwallet mode. The idea is that combcore will have a public API that other people can query so they dont have to deal with storing commits.

Currently the API is smaller than i thought it would be, only:
This will be mostly superseded by P2P commit mining/validating when that gets implemented however it will require storing the commit DB (~1gb), which still might not be possible for some people

It's a good idea to have a twitter handle, can be used for instance to air some announcements, etc.

I am not on telegram anymore, got locked out from my account, so might be a good idea to kick my old telegram account.

I'm currently on the matrix bridge, under the handle watashicombdev.

Need to investigate a doublespend in a testnet experimental client I've posted earlier on that bitbucket.

https://twitter.com/HaircombToken

New Haircomb twitter account! If anyone wants access to the account, message me your twitter @ and I can give you permissions to tweet under the @HaircombToken handle

yes, depending on how intrusive the fork is, It may be something to think about while it's still early.

I'm on the chat room, will be there for a few days, to discuss mainly a potential next release and resumption of haircomb core development.

Duelform on the TG had a really interesting idea about embedding a decentralized atomic swap system for BTC->COMB directly into the protocol. I'm hoping he posts about it here in greater detail, but it's something interesting to consider to potentially spur adoption.

It's a fork though, which sucks.

You mean like Etherbrush? ^_^

It's possible to replicate/simulate haircomb cryptography in Ethereum yielding a separate haircomb-like currency (on ethereum).

In a nutshell you need 3 gobal static mappings in the contract.

Mapping from uint256 to [2]uint - the commitment set

Mapping from uint256 to uint64 - the accounts table

Mapping from uint256 to uint256 - accounts redirect table - flow graph of currency

Then you need some public accesor to add commitments. anyone can call with their uint256 value
to insert it into the commitment set. the [2]uint are assigned automatically, first is block height (block.number)
the second is a counter from 1 that increments and resets to 1 when block.number is detected to be higher.

Next when someone chooses to reveal their claim, they reveal {X uint256, H uint} so that sha3(whitepaper+X) maps to {H, 1}. when that
happens new money are generated and inserted to the accounts table according to subsidy formula (can be the original, a new dope one,
or one based on halvings). you can then change the value {H, 1} to {H, 0} in the commitment set to prevent the claimer from doing this
twice.

Next you need 4 public functions to replay comb histories into the contract.

- Trickle function. User inserts uint256, if account and redirect table contains that uint256 key, all money from account
"redirect key" is hopped to account "redirect value".

- Haircomb function. If validated (using the normal haircomb doublespend detection), creates a redirect from the haircomb
public key to the destination address.

- Liquidity stack function. The user inserts CH uint256, OUT uint256, AMT uint64. If validated that HASH=sha3(CH cat OUT cat AMT)
contains >= AMT coins in the account table, AMT coins are immediately moved to OUT, and redirect from HASH to CH is created.

- Merkle function. The user inserts decider + merkle path. Decider is validated (using the normal decider doublespend detection).
If valid, a redirect is inserted from the sha3(decider address cat merkle root) to merkle leaf that was proved using the Nth merkle
path, so that N was signed using the decider.

Bonus points:

- implement some ERC20 api so that people can insert their ethereum shitcoins and turn them to haircombs somehow, or just trade them.

- implement a hidden mint function and rug other users ^_^

Stuff like wrapped comb and light wallets, while likely not relevant in a decade or so, would probably be helpful for kickstarting adoption right now. I don't know enough about the proof of reserve system that wrapped btc uses to really comment if it's something that's feasible for a private coin like haircomb though.

Has anyone floated the idea of Wrapped COMB?

Wow! First multiclaim ever performed. These are the recipients:


Overflow change is the stack bottom, slightly less coin got paid there.

And this is the history:





Now my opinions to very insightful comment by nixed.


I agree completely, any help in this area is badly needed. Especially things like how to spend a comb key is too undocumented.


I completely agree, when people will start paying/claiming to more than say 100 people often, it starts to be preferable to use liquidity trees, not only for efficiency, but also for the small privacy benefit- you can reveal a different sub-tree to each recipient.


Custodial wallets (like a website that owns your comb instead of you) can reach much higher scale than on bitcoin and much more securely, this is why they will be needed. Many will rug though.


Hosting the commit file will take like 265MB (currently). Maybe just tar it and dump it on some upload/torrent site once a year.


Yes the sync UTXO set without full blockchain syncing problem is the same as Bitcoin's. Bad thing, it isn't solved,
good thing if it will ever solved, it will automatically solve our problem. Why? Comb commitment set is a subset of Bitcoin UTXO set.

Nakamoto proposed SPV sync (Just trust the most proof of work chain bro) solution is problematic and the problems of it are well known.


With comb downloader you can already do the pulling of the blocks from arbitrary local or remote nodes in parallel (see addnode switch). The incoming blocks are checked for presence in the
chain. The problem is which node you set as the longest proof of work chain provider node. I highly recommend at all times to use your own BTC nodes that you control. This is by default 127.0.0.1:8333
Anyway the switch is --my-btc-full-node

The problem is of course wasted traffic, many GB just to get a 265MB file is currently insane. It will start to get better when (if) COMB transactions start dominating the BTC on chain traffic.


Yeah it's just on local-host, but open port isn't OK in the long run. It would be a good idea to secure it using a throwaway COMB keys (1 key per request and sign the next key) plus probably also a post quantum encryption

The disadvantage would be the client would need to be able to perform the cryptography and it would cease to be simple to use.



Yes there is a brain-wallet feature to generate N keys from a password. But it's not exposed anywhere. There is a "problem" if a rat gets to your seed then they can choose to not rug you immediately, but
wait until you make more keys and rug everything later. If you gen a new key each time you can break this tie.

You also need to hash the seed using a password-grade function which is not done currently.

I think truecrypt/veracrypt is nice for now for paranoid person. Just don't forget the password.