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

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.

Whenever the market finally settles down and I have the time to actually work on COMB, I've got a few things in mind.

 - More accessible information regarding the mechanics of comb. I've tried to simplify it already, but it can be made easier for people to understand, especially if there are proper diagrams made.

 - LStack stack modifications. Right now if you make a multi-out transaction with 5 destinations, you're looking at including 5 LStacks in the data you give to the recipients; they make mono-directional main pipe that has lateral exit valves, each valve spitting out the amount required for that destination address. Instead, I think it makes more sense to switch over to a merkle tree design; LStack1 is made up of LStack2 and LStack3, NOT Destination1 and LStack2. If I'm not mistaken this should significantly cut down on wallet metadata in large transactions; the total metadata generated with the current system can be calculated with n = (x/2+0.5)*x, where x = destination count. The merkle tree variation generates about n = l*x, where l = the merkle tree layer count. If you shoot off a transaction with 4 total destinations, you're looking at a metadata value of 10 with the current method, but a metadata count of 8 with the merkle tree variant. Unless I'm missing something, this makes sense to implement. I realize there's a "fold the stack" option in the client currently, however I haven't looked into what it actually does mechanically, and it says that it should only be used for super large transactions, so I'm assuming it wouldn't help in situations like the previously described.

 - Light wallets. The three ways I see to work this are a) a trusted 3rd party comb node to host the commits files, b) a trusted 3rd party comb node to feed to commits to build your own commits file, or c) multiple 3rd party BTC nodes that your downloader connects to. I'm guessing C is probably going to be the way to go in the long run, but that involves a larger community I would assume.

 - Security. A guy on the TG made some good points about the vulnerabilities that the current method of command has, It makes sense to build a proper, secure RPC system going forwards; it also may make building a native GUI easier. I know that guy was working on a QT GUI, but I haven't heard anything in a while.

 - Pneumonic wallets. This can be done using a 21 word phrase, something like: key1 = SHA256(word1 CAT word1 CAT word2 CAT word3 ... word21), key2 = SHA256(word1 CAT word2 CAT word2 CAT word3 ... word21), etc. This would make secure backups much easier; currently a secure backup involves a) printing your private key to a paper wallet and b) storing a de-privatekeyed transaction history in multiple places on and offline. The trouble with this is that you have to print of your new private key each time you make a transaction. Switch to a pneumonic system and implementing deterministic wallet generation based on that phrase, similar the the way other cryptos have it currently implemented, would make the paper backup only necessary the one time; every transaction would only require the TX history backup.

I can't really speak to the more technical comp-sci possibilities of optimization, I haven't done enough reading to really comment yet.

combdownloader

Hello, two more off by one block problems were just now patched, I hope the problem is resolved forever.

Re-built the exe on Bitbucket cloud.

Who is affected

You are affected in case you used the first exe (that looks like it had 100 downloads and file size of 7 048 704 bytes).

Users who are syncing using rpc of bitcoin are unaffected.

Bitcoin core is unaffected in any way, you can keep that running.

Problem description

Block contents of block 481824 get loaded into position for block 481825,
Block contents of block 481825 get loaded into position for block 481826,
 etc up to the highest block
This means if you are claiming your claims will show up with delay of 1 block
Other glitches or effects are unknown, the wallet seems to be working despite the problem, but it's a problem that should be fixed.


How to fix

1. shut down combdownloader and also combfullui (of course save the wallet if needed)
2. while combfullui is off, delete the commits folder
3. get new combdownloader in any way that's comfortable for you, if you do not trust bitbucket then build it yourself
4. start combfullui and combdownloader
5. let it sync for a hour or so



Future of haircomb core project???

Anyone have some ideas that they want to pursue in haircomb core?
For example make this non fatal??


Implement rapid SHA256??? (github.com/minio/sha256-simd)

Fix remaining Natasha's bugs? Like the key for comb trade entries is huge? It should be shrink to 256bit?
Then make comb trades anonminisable?

Implement Karmarkar or similar for deep history anonymization?

You get the basics, yeah.

When it comes to the filesize, that is an issue that I don't really have an answer for, other than technological advances. However, I also view it as a positive because it offloads tx data from one chain that everybody needs to own, to a local file that only you need to know. To me this seems like a plus for scaling.

Earlier in the thread we talked a bit about the potential ways to reduce the commits-per-tx. Most of them would require a soft/hard fork of some kind, or sacrificing a little bit of your security, but they'd work. The core method that would work in comb's current form would be utilizing a centralized transaction wallet, through which multiple people would funnel their transactions, and the wallet owner would redirect them all to the appropriate locations. You can use deciders to make this process more secure.

Contracts that have deciders can have funds deposited into them; when the person who has the decider private key signs a number, that contract executes depending on the number signed. The contract has two resolution addresses that the funds can go too, known as the forwards address and the rollback address. A decider/contract address is generated from the related addresses and the public key of the decider. Signing a decider only takes 2 BTC commits.

Using this structure, if there is a dedicated centralized wallet, what I like to call a turbine, the following methodology can be used to mostly secure funds while reducing personal tx cost.

1. User makes a Decider_A.
2. User makes a Contract (Contract_1) with the Decider_A, the Turbine's wallet address as the forward address, and the User's backup wallet as the rollback address.
3. User deposits all their funds into Contract_1. This will now act as the users wallet until the User is ready to make a transaction.
4. When the user is ready, the user makes another Contract (Contract_2); this one also uses the Decider_A, the Turbine's next address as the rollback address, and whatever address the user wants to send their funds to as the forward address.
5. The user tell the Turbine Operator that they want to make a transaction, and shows the turbine operator the two Decider/Contracts that they made. The turbine operator can look at this and know that there can be one of 2 outcomes:
       a) the Decider is signed forwards; any funds from Contract_1 will go to the Turbine's Address, and any funds from Contract_2 will go to the user's destination address
       b) the Decider is signed rolback; any funds from Contract_1 will go to the User's backup address, and any funds from Contract_2 will go to the Turbine's next address.
6. Knowing this, the Turbine operator includes a LStack in it's next transaction cycle that will redirect X funds from the Turbine into the Contract_2 address, where X = the funds in Contract_1, minus the turbine's fee.
7. The user signs the decider.

This reduces your personal commit footprint down to 2 commits per tx. There is a bit of an attack vector though; information imbalance. The user could sign the decider to rollback, but not tell the Turbine that they did so. Doing this would lock up X turbine funds indefinitely. Theoretically in an ecosystem that required turbines to facilitate comb transactions, if the user ever used their comb in any other transaction the tx history would likely ripple out to other users of the turbine who weren't actively keeping the data from the turbine operator, and would eventually make its way to the turbine to unlock the funds. Another attack vector is just a kamikaze attack; just don't sign the decider.

All this can be done automatically and simply, provided that the correct infrastructure is built for it.