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

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.

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.

deep reorgs are mostly prevented by a lack of testing and code, it really begs
to be tested on testnet/regtest, see what happens on reorg and just fix things.

Of course when testing on testnet/regtest you need to temporarily disable the
difficulty checking and set the correct ports.

performance wise, it's currently capped by fiber speed and remote node's disk
speed. Haircomb core pulls 5 blocks at the same time and this causes
comb downloader to also pull them concurrently from arbitrary connections.

If we create connection to enough distinct nodes the total disk speed of them
will almost surely dominate the fiber/dsl speed of the internet connection
This will cause the internet connection to be maxed up and that's insane yeah.

Security wise it'll be alright. The headers are checked for hashing difficulty
when pulled. Blocks are checked for merkle tree transaction presence when pulled.
Obviously it's a some kind of SPV model. There is no guarantee the longest chain
is actually a bitcoin chain, because adversary can mine an invalid block with a
double spend and serve it to us if we trust it. Mining an invalid blocks has
a cost associated.

For casual use when the user just wants to try claiming haircomb it'll be fine.
The security can be improved by syncing a local pruned node and trusting it's
headers, while pulling blocks remotely.

I think only the first app that starts using port 8332 can do so. So for
comb downloader to work you have to start bitcoin not in rpc mode.

What's currently preventing deep reorgs?

Looking at the previous direct RPC block pulling method, the limiting factor was how fast the BTC node could spit out block data. Theoretically, if you had access to multiple BTC nodes that you trusted, you could get a MUCH faster full build of your commits file, right? That's pretty sick if it's true, though again the question is how to enable that while maintaining as much security as possible.

Another question that pops up is the port management; the combunity release connects to port 8332, and from the reading I've done the combdownloader hosts on 8332, so that makes sense. But what happens when BTC tries to host on 8332, like it normally would? Do you have to launch the downloader before the BTC, or modify BTC's default RPC port to something other than 8332? Or have I missed something about how the downloader is operating?

I understand that the remote btc node can be pretty attractive, precisely because
of haircomb's small disk consumption. We just should be careful about the
security model, because there are real security disadvantages.

Now, the details:
It's a two ended shop. On the back end it maintains 8 connections to the bitcoin
wire network. The first connection pulls and difficulty-validates all the btc
headers (this is what the system then trusts is the longest chain). There's also
a blockhash checkpoint built-in (can be made configurable). All the connections
are capable of pulling in complete raw btc blocks. They're pre segwit-blocks,
so they're capped at 1MB (there are missing signatures). Validation is SPV at best,
unable to catch blocks with doublespends/theft as invalid, but still powerful
enough to recognize bcash blocks as invalid. Tx merkle tree is also checked.

pulling commits over the RPC is done imitating actual bitcoin rpc api. There's
just the minimum information needed only, basically just the relevant comb
outputs, plus some info from the block header, so it's kind of small.

To connect experimentally to a remote node, change the ip in main.go, domain
name is fine too. Just decrease the connections from 8 to like 2, real bitcoin
nodes don't like when you connect to them too many times. Ipv6 can also be used
[ipv6]:8333. The first connection j == 0 will be the header puller.

Possible improvements:

1. make the addnode ip configurable
2. make the checkpoint configurable
3. make the connection count configurable
4. cruiser connection, this will be the initial connection that won't be
used to pull anything, just to discover IPs of nodes, once enough IPs are known,
N real connections are made to random nodes and to different ones on disconnect.
5. currently reorgs deeper than 2 blocks are impossible.. fix this?

Cool! How does it handle the comb client trying to pull commits over the RPC?

Also just confirming, but it can maintain an up-to-date commits file without hosting a local node if you plug in an IP of a trusted BTC node? I know some people on the telegram were saying it's a bit of an inconvenience to run a BTC full node just to use Haircomb, even if it's just because of the HD space it takes up. Setting it up so they don't need to, even if it DOES still take bandwidth to download the commits, would still probably be pretty attractive to them.