[ANN][COMB] Haircomb - Quantum proof, anonymity and more

[nixed]

Forgive me if some of this stuff has been explained or if I'm wrong, but I feel like there's not enough simplified information about what Haircomb does or why it'd be valuable, at least for people who aren't very experienced with these things. If I understand claiming, you send a specific amount to your own generated BTC address, but the transaction also needs to be at the front of a BTC block in order to successfully claim. So that'd mean right now we can claim with the highest transaction fee, although some day miners can just put their own transaction at the front of a block to claim it themselves since they organize the blocks. Is that correct? That seems like it could help a ton with mining incentive, but what about the use of COMB itself? It's private, but at what cost? COMB holders basically each have their own piece of the ledger and each need to have synced BitcoinCore running in order to use COMB. That doesn't seem ideal when the core is ~400GB. Even at a smaller size, it's not as easy to use as other cryptocurrencies. Is it possible for that to change at some point or is that just how it is since we'd each own our transaction data? Is there a way for it to be easier to use in the future? Then there's liquidity stacks. They seem really interesting - a transaction with infinite outputs could help a ton with scaling in certain scenarios, but starting that first liquidity stack still requires BTC transactions and can't scale beyond BTC's capabilities. Is there any way the initial input could scale better? There's also deciders/decider's purse that I see, I'm not sure how that correlates with any of this. Do I understand COMB for the most part? I'd like to know where I'm wrong and what could fix the problems I think I see. This token is very interesting, but it's hard to understand.

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.

[watashi-kokoto]

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??

Code:

log.Fatal("phone btc ERROR 3", err)

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?

[nixed]

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.

[watashi-kokoto]

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

Code:

0F0E688DE2A26B76BFF276135FB4840C810E18B270FD09E63BC211217E753ED9 100000 natashas (overflow change)
0F0E688DE2A26B76BFF276135FB4840C810E18B270FD09E63BC211217E753ED9 100000 natashas
63F37CCA1EB621F575CA6B4D95948A1109D1D1745F647E58DC3DAB289A910992 100000 natashas
63F37CCA1EB621F575CA6B4D95948A1109D1D1745F647E58DC3DAB289A910992 100000 natashas
5DFE381BEBA1937BAC3244340D7F111CA6732AD2CAA2B4EDAFC16BDA9DC27A8C 155955007 natashas

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

And this is the history:

Code:

/stack/data/0F0E688DE2A26B76BFF276135FB4840C810E18B270FD09E63BC211217E753ED90F0E688DE2A26B76BFF276135FB4840C810E18B270FD09E63BC211217E753ED900000000000186A0
/stack/data/98A92408F4C2B9BF817D2E56272F3989BB73F9704DFE050761E1AD371401707063F37CCA1EB621F575CA6B4D95948A1109D1D1745F647E58DC3DAB289A91099200000000000186A0
/stack/data/598C1FF51C3BA66D3304B7C52E2E1EDE86F50961103DF1C6ADEFC0EFFCCCA38F63F37CCA1EB621F575CA6B4D95948A1109D1D1745F647E58DC3DAB289A91099200000000000186A0
/stack/data/25344EDEF7F5080B5C27A3D37EDAE7CE63BF9100DF6A8B9808CE668ED436603F5DFE381BEBA1937BAC3244340D7F111CA6732AD2CAA2B4EDAFC16BDA9DC27A8C00000000094BAF3F

Now my opinions to very insightful comment by nixed.

More accessible information regarding the mechanics of comb.

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

LStack stack modifications

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.

Light wallets

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.

Light wallets a)

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

Light wallets b)

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.

Light wallets c)

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.

- Security

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.

- Pneumonic wallets

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.

[haircombint]

Has anyone floated the idea of Wrapped COMB?

[nixed]

Has anyone floated the idea of Wrapped COMB?

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.

[watashi-kokoto]

Has anyone floated the idea of Wrapped COMB?

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 ^_^

[nixed]

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.

[watashi-kokoto]

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.

[haircombint]

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

[watashi-kokoto]

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.

[duelform]

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:

Code:

check_commits_exist([]commit) -> []commit
        returns commits that are missing from the commit set
        
check_commits_older_than([]commit, commit) -> bool
        return true if any of the commits in the array are older than the commit
        
get_coinbase(commit) -> uint64
        returns the amount of nats awarded to commit (0 if not a coinbase)

get_height() -> uint64
        return the current block height

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

[watashi-kokoto]

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.

Code:

	fmt.Printf("rewarded\n")
	balance_coinbases[c] = reward
	balance[c] += reward
	return true

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:

Code:

	//now propagate the coinbase to the construct
	balance_redirect(c, a)

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).

[duelform]

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.

[nixed]

Android wallet app released a little while ago :O

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

KNOWN ISSUE ARE AS FOLLOWS:

Still the limitation that user needs to manually save wallets from mainpage

Unable to upgrade from my version 0.0.1 to fdroid signed version 0.0.1 "App not installed as package conflicts with an existing package"

NOTE: This only applied to new android. The two instances of apps get installed perfectly fine (side by side) on an old android.


if you hit uninstall the app or clear storage ... Wallets are lost forever

Settings / Core / Core wallet directory option to store wallets on sdcard don't work on new android.

NOTE: Works fine on old android

Additional info: only thing that will happen is that commits folder gets created with 0byte LOCK file inside. After this leveldb crashes.

If you do this accidentally press Settings / Core / Reset directory to internal. After this you can use the internal folder normally on your new android phone.

Default options are mostly useless, but harmless. Wallet loading should be switched to All in order to load wallets. My btc full node needs to be set by the user manually. Reorganization type, you can switch it to the new Direct mode to have fast reorgs.

On first startup, and on every future upgrades (0.0.1 to 0.0.2 etc) need to hit the Install button on the mainpage

untested on every version of android (except 7, 12). Definitely not works on phones without ARMv8

More than 800MB of RAM required.

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.

[watashi-kokoto]

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 

[nixed]

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 

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.

[watashi-kokoto]

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).

[watashi-kokoto]

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

[watashi-kokoto]

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/