Bitcoin Forum

Alternate cryptocurrencies => Announcements (Altcoins) => Topic started by: natasha-otomoski on October 25, 2019, 05:24:31 AM



Title: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 25, 2019, 05:24:31 AM
https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FmimHvpg.png&t=606&c=cinBfQ-bYXEqFg


https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FiKgkAnJ.png&t=606&c=_P3JRMxnMEgl_w (https://raw.githubusercontent.com/natasha-otomoski/haircomb/master/WhyTheCombOfNatashaOtomoskiHas21Teeth.txt)https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2Faas6oh0.png&t=606&c=pqOe-M4gHcGRIA (https://github.com/natasha-otomoski/haircomb/raw/master/combfullui)https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FaXbg8xM.png&t=606&c=BbkHgWpr9A9EfA (https://github.com/natasha-otomoski/haircomb/raw/master/combfullui.exe)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: tedngls on October 25, 2019, 09:22:58 AM
discord?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: AmoreJaz on October 25, 2019, 09:25:15 AM
what is this? a joke? not even a preann?
please give us more details. i suppose if you will release the mainnet this weekend, you have at least a working website, right?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: notsofast on October 25, 2019, 12:34:05 PM
Mainnet this weekend
No more ridonkulous name than Grin and Mimblewimble, really.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: morvillz7z on October 25, 2019, 02:31:14 PM
It's indeed a joke and a good one, look at op/project's name, it's related to a BTC puzzle game (https://bitcointalk.org/index.php?topic=5096267.0) posted earlier this year.
Probably someone is still sore he couldn't figure out the private key or didn't like the shit solution.

"OpHadTheIdeaWhileCombingHisHair" (1 letter short)  :D


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: lightbit on October 25, 2019, 03:26:40 PM
When smart people start to make jokes  ;D

Good one!  ;)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 25, 2019, 03:37:35 PM
Bear with me, It's my first time launching a coin.

Before I do the actual release (and it will be soon), let me provide first a few files.

This is the modified Bitcoin Core, it is used to sync the haircomb core wallet. Apply the files on top of 0.18.1. - compile it and review that the changes made are not malicious.

http://www.mediafire.com/file/s9ni7pjd0lb5566/bitcoin-modified-v0.18.1.zip/file


And here is the commits.db file. It's the coin's database.

http://www.mediafire.com/file/vqb2twui9t25ine/commits.zip/file

This is for people who don't want to slowly sync from zero, it is for people who trust me that I did the validation.





what is this? a joke? not even a preann?
please give us more details. i suppose if you will release the mainnet this weekend, you have at least a working website, right?

Yes, I will release the mainnet on the Bitcoin blockchain from my bedroom this weekend, to be more exact in several hours.

No there is no website. I'm the only one working on this coin - there simply was no time.

If anyone wants, you can make a nice website. ;D


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: lightbit on October 25, 2019, 04:15:03 PM
Make a discord server for COMB please. I can help you over there. Make one and share the link here, thanks! :)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: CjMapope on October 25, 2019, 04:38:23 PM
i think you lost me at "Quantum proof"
or maybe you mean "quantum proofs" O_o  haha  :D
idk, make a discord ill follow this one see where it goes
weekends here :D


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: electronicash on October 25, 2019, 04:47:43 PM
a joke he got after a hundred brush strokes.

give him a chance though. maybe he just forgot to past the codes with all the details there including infographics they did as a team. more jokes probably should be posted.
a joke of this has to be published quickly before someone else stole this joke. before someone else creates a thread with a similar name and similar concept.  

Haircomb - Mane and Tail


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 25, 2019, 05:28:15 PM
The wallet is not very pretty but it does the job.

https://i.postimg.cc/BZLDnsQg/screenshot.png

About max supply, the theoretical maximum is 12423823.18141419 COMB


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: keseoma on October 25, 2019, 05:42:00 PM
Bear with me, It's my first time launching a coin.

Before I do the actual release (and it will be soon), let me provide first a few files.

This is the modified Bitcoin Core, it is used to sync the haircomb core wallet. Apply the files on top of 0.18.1. - compile it and review that the changes made are not malicious.

http://www.mediafire.com/file/s9ni7pjd0lb5566/bitcoin-modified-v0.18.1.zip/file


And here is the commits.db file. It's the coin's database.

http://www.mediafire.com/file/vqb2twui9t25ine/commits.zip/file

This is for people who don't want to slowly sync from zero, it is for people who trust me that I did the validation.



Please github, but not mediafire, it's a file hosting website...


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 25, 2019, 06:59:35 PM
Please github, but not mediafire, it's a file hosting website...

Thanks. I've posted the wallet syncing code to github. https://github.com/natasha-otomoski/bitcoin

Hope everyone has their modified bitcoin core wallets ready to be able to sync their nodes.

Another thing people need to have ready is a small change of Bitcoin, using it to claim cheap combs when we release.


While we wait, keep the jokes up  ;D


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: TimeTeller on October 25, 2019, 09:50:27 PM
Please github, but not mediafire, it's a file hosting website...

Thanks. I've posted the wallet syncing code to github. https://github.com/natasha-otomoski/bitcoin

Hope everyone has their modified bitcoin core wallets ready to be able to sync their nodes.

Another thing people need to have ready is a small change of Bitcoin, using it to claim cheap combs when we release.


While we wait, keep the jokes up  ;D

If I may ask, what is your motivation in creating this coin?
Since the tone here is not so serious, I am assuming the quantum proof concept is not real?
And it seems that you are not interested in creating a website for this project, how can you provide a decent reference link to your project?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: lightbit on October 26, 2019, 01:01:10 AM
Please github, but not mediafire, it's a file hosting website...

Thanks. I've posted the wallet syncing code to github. https://github.com/natasha-otomoski/bitcoin

Hope everyone has their modified bitcoin core wallets ready to be able to sync their nodes.

Another thing people need to have ready is a small change of Bitcoin, using it to claim cheap combs when we release.


While we wait, keep the jokes up  ;D

When Discord? :D


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 26, 2019, 01:17:22 AM
If I may ask, what is your motivation in creating this coin?
Since the tone here is not so serious, I am assuming the quantum proof concept is not real?
And it seems that you are not interested in creating a website for this project, how can you provide a decent reference link to your project?

No, this is serious. Creating a website would add major delay to the release, but I am considering it.

When Discord? :D

I'm on tor, can't access discord. The comb community can create server but I'm afraid I won't be able to participate..


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: lightbit on October 26, 2019, 01:32:35 AM
If I may ask, what is your motivation in creating this coin?
Since the tone here is not so serious, I am assuming the quantum proof concept is not real?
And it seems that you are not interested in creating a website for this project, how can you provide a decent reference link to your project?

No, this is serious. Creating a website would add major delay to the release, but I am considering it.

When Discord? :D

I'm on tor, can't access discord. The comb community can create server but I'm afraid I won't be able to participate..

Well.. download discord.exe maybe? I can create one, sure. But if the dev is not participating, its no use. :)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: acty on October 26, 2019, 02:04:22 AM
it's mineable?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 26, 2019, 02:14:29 AM
Well.. download discord.exe maybe? I can create one, sure. But if the dev is not participating, its no use. :)

Yeah... If chat is required, we can meet on irc somewhere. That will be nice.


Anyways I have the likely to be final binary here:

051a9ca7a5d005d71b2441c67f0a963ed17426d4ceb04315931d9bf04a441002   combfullui

and whitepaper:

6afbac595c1d07a3d4c5179758f5bce4462a6c263f6e6dfcd942011433adaae7  WhyTheCombOfNatashaOtomoskiHas21Teeth.txt

I will post it on github + mediafire in about hour or two.


To claim your COMB tokens do the following steps when it's released:

1. run combfullui
2. navigate to http://127.0.0.1:2121
3. click wallet
4. click generate key
5. go to main page, fully save your wallet, enter file name, it will be created with suffix .dat
6. go back to wallet notice mine address near your key.
7. tip small amount of bitcoin to your mine address
8. if you are lucky, free COMB will be generated

it's mineable?

currently COMB can be claimed for free. Later it will be mineable.



Released.

https://github.com/natasha-otomoski/haircomb



There was a bug when you unsuccessfully claimed, the wallet tried to give you nonexistend combbase.

Fixed the bug. New release:

badb923894806afcf4263fbbe035b5ee60a02e80b2200d3adbe79743a5d09f69 combfullui


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: CjMapope on October 26, 2019, 05:12:03 PM
im gonna do my best to figure this out today haha
right now im just reading your "whitepaper" , its some interesting stuff, alot to wrap ones head around...
i think this one might be above my cryptographic skill level :D i might wait till others set it up here or theres more documentation

this is really interesting stuff tho man, i look forward to seeing where this goes :)



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bittraffic on October 26, 2019, 08:25:33 PM

I downloaded the modified bitcoin core zip file but find no exe file there and so is the comb file all I see is the combfullui.db How do I open the wallet?

Not a bitcoin core user actually but would like to try something new today.

im gonna do my best to figure this out today haha
right now im just reading your "whitepaper" , its some interesting stuff, alot to wrap ones head around...
i think this one might be above my cryptographic skill level :D i might wait till others set it up here or theres more documentation

this is really interesting stuff tho man, i look forward to seeing where this goes :)



He said this is Quantum proof, let us know your findings here. Only few projects have claimed such.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 26, 2019, 08:43:20 PM
!!EXCITING NEWS!!

More than 4.8 real spendable COMB tokens are now in circulation on the Bitcoin main network.

I cannot post picture because the lucky owner wished to stay anonymous. The secret??? 172 000 sats/kilobyte fee when claiming.

I am not aware about any more coins in existence so he probably owns the whole supply.  ;D

There is still time! More than 11 millions tokens remain to be generated. It will be enough for everybody.

NOT SO EXCITING

There is liquidity stack combbase bug. So don't use liquidity stacks. I will fix it asap.

I will try to do release for Windows soon.

Until then, the only way to generate your COMB and MINE (claiming) addresses is to use combfullui from github on LINUX.
Just run it and visit 127.0.0.1:2121 then generate your keys and:

ALWAYS SAVE YOUR WALLET MANUALLY - THERE IS NO AUTOSAVE FEATURE




Crasher bug fixed in the following binary release (on github):

5fa12b76377128555edb7340a83d8f7b119ebc4794bfb393610658077c9db207  combfullui

What should I do next about this project? Share your opinions.

- faucet
- project website
- windows wallet
- beautiful announcement thread
- paper wallet and token claim address generator website
- mobile wallet (android)

Whatever gets the most votes I'll consider doing it.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: salsa321 on October 27, 2019, 01:16:43 AM
Check DM


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 27, 2019, 07:59:03 AM
Check DM

I don't have discord or telegram, sorry. I am connecting using tor.
I have exceeded limit of DM messages. Everyone, contact me using email if you like. n a t a s h a - o t o m o s k i @ p r o t o n m a i l . c o m



Released windows wallet.

https://github.com/natasha-otomoski/haircomb


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: CjMapope on October 27, 2019, 05:11:51 PM
Check DM

I don't have discord or telegram, sorry. I am connecting using tor.
I have exceeded limit of DM messages. Everyone, contact me using email if you like. n a t a s h a - o t o m o s k i @ p r o t o n m a i l . c o m



Released windows wallet.

https://github.com/natasha-otomoski/haircomb

right on :)
it seems those who know what they are doing with this are gonna stay silent on helping us others tho
so distribution will prob end up centralized : /

oh well, thats crypto, good luck on your project man :)



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on October 27, 2019, 06:04:02 PM
right on :)
it seems those who know what they are doing with this are gonna stay silent on helping us others tho
so distribution will prob end up centralized : /

oh well, thats crypto, good luck on your project man :)

I will be helping everyone to the best of my knowledge. Dreaming about the future when COMB is worth 0.50$ each.  ;)

Currently the main thing you need to claim is combfullui, or combfullui.exe for windows. Your wallet does not need to be synced to claim.

Start it combfullui you haven't already. Visit http://127.0.0.1:2121 Click wallet on the main page. Generate a few keys. From the main page, save your wallet to a file. Go to wallet again, copy your mine address (the long address, starts with bc1)

Open bitcoin or your Bitcoin wallet. Your wallet must support segwit. Tip 0.00000546 BTC to your mine address.

Congrats you now have a chance to get free 1.6 COMB.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 01, 2019, 09:32:48 AM
What a great project. Natasha, you are very smart to create anonymous and quantum proof coin.

I've been claiming free COMB.  I've received 0.00000001 less COMB than expected according to the equation on the whitepaper.

Another thing I've noticed, the max supply on the whitepaper doesn't match the equation when you sum all blocks rewards.

It should be 12423823.39976706 COMB.

The edge cases also appear to be 0.00000001 less COMB than expected.




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 01, 2019, 09:58:34 AM
I've received 0.00000001 less COMB than expected

Yes. There is an equation bug in the wallet. I think the coin can still be fixed. Sure, it is a hard fork, but if we set the equation as defined in the whitepaper we end up with total theoretical max supply of 12423823.39976706 COMB.

Next thing that we will do is we burn 0.21835287 tokens by sending them to the 000000000000000000 address, so that the claim about max supply of 12423823.18141419 COMB remains true as well. (Even though the supply increased by the hard fork.)


Pushed updated wallets to github.

3a5d649eb2d69d380dcb96c6db5f71462f1f1adad333948ea60e547a1e7f3b10  combfullui
44616a37fd63dd69290b295741b67de60200abe751708b0eb27e5507d33f0fd1  combfullui.exe


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Grumo on November 02, 2019, 07:17:18 PM
how to sync wallet? the wallet is always at 0 blocks


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 02, 2019, 09:34:09 PM
how to sync wallet? the wallet is always at 0 blocks

Use the modified Bitcoin Core (https://github.com/natasha-otomoski/bitcoin) to sync the wallet. It takes about 2 hours with already downloaded bitcoin blockchain.

Alternatively get commits.db from another person (when their and your wallet is shutdown) and paste it to the same folder where there is combfullui.exe

Next start combfullui.exe and you are synced.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Grumo on November 02, 2019, 10:06:37 PM
how to sync wallet? the wallet is always at 0 blocks

Use the modified Bitcoin Core (https://github.com/natasha-otomoski/bitcoin) to sync the wallet. It takes about 2 hours with already downloaded bitcoin blockchain.

Alternatively get commits.db from another person (when their and your wallet is shutdown) and paste it to the same folder where there is combfullui.exe

Next start combfullui.exe and you are synced.
thanks now it worked


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 02, 2019, 10:13:57 PM
thanks now it worked

I'm glad to hear that.

We have several new things. We have rewards viewer site (https://natasha-otomoski.github.io/combplorer/) where anyone can see who claimed COMB recently.

There is also a paper wallet generator (https://natasha-otomoski.github.io/combplorer/combwallet.html).

Stay tuned for more!!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: XCASH on November 03, 2019, 02:21:02 AM


1. run combfullui
2. navigate to http://127.0.0.1:2121
3. click wallet
4. click generate key
5. go to main page, fully save your wallet, enter file name, it will be created with suffix .dat
6. go back to wallet notice mine address near your key.
7. tip small amount of bitcoin to your mine address
8. if you are lucky, free COMB will be generated

How small can the required amount of bitcoin be? Is one sat enough?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 03, 2019, 06:28:12 AM
How small can the required amount of bitcoin be? Is one sat enough?

546 sats is the minimum. Anyone can claim, even from exchanges/online wallets. Your wallet/exchange/faucet must support small payouts (all money sent is burned) and it must support segwit (to allow paying to bc1 long addresses).

Set a nice fee because I've noticed that some miners sort payments by fees. You have to be on top to win.

For people who don't have BTC, segwit faucet would be ideal for this purpose.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 06, 2019, 09:17:22 PM
Update - coin burn successful

To verify that the coin is done correctly, do the following:

1. Sync your wallet to block 602614 or more.
2. Import the following text file (coin history) to your wallet:

Code:
/stack/data/47B04436BBE7F6846DEA777D9596364A3B6134B85AC601242879ED389DE94C86000000000000000000000000000000000000000000000000000000000000000000000000014D2E17

3. View visible utxo set of your node at http://127.0.0.1:2121/utxo/
4. Verify that this is at the end:

Code:
     0000000000000000000000000000000000000000000000000000000000000000 0.21835287 COMB 

    47B04436BBE7F6846DEA777D9596364A3B6134B85AC601242879ED389DE94C86 1.38054520 COMB

This means coin is burned as promised and therefore there is no observable supply increase made by that hard fork.

Here is my commits.db if someone needs to skip syncing.

http://www.mediafire.com/file/17c7kvggck07c6p/commits.db/file


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 08, 2019, 12:23:20 AM
New release has been pushed that contains fix for crash after doing a transaction.

3e5dd53eca56ac8835f400fd35314e4ae840161c0faa40f434f537f4bf601d1a  combfullui
dfe880d883c9d472dd78cc6e44744bf12eb3c0033399a20e51dba0e3cf7ae512  combfullui.exe


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: salsa321 on November 08, 2019, 03:22:58 AM
New release has been pushed that contains fix for crash after doing a transaction.

3e5dd53eca56ac8835f400fd35314e4ae840161c0faa40f434f537f4bf601d1a  combfullui
dfe880d883c9d472dd78cc6e44744bf12eb3c0033399a20e51dba0e3cf7ae512  combfullui.exe


Is there any airdrop?or claim faucet?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 08, 2019, 06:45:52 PM
Is there any airdrop?or claim faucet?

Airdrop requires too many people with same type of addresses. Haircomb is completely new idea, there is no other coin that
uses this yet, so there is nobody we could airdrop to.

I could be wrong but haircomb is a lot like Bitcoin 10 years ago. New crypto, no airdrop, no ico or anything just a handful of early adopters claiming coins not because they know for sure that it will be worth millions someday but simply because it looks promising or fun or exciting (or whatever, everyone has their own reasons).

Therefore I think that we should fly under the radar in the beginning. We shall fill our bags with cheap comb just like Satoshi did with Bitcoin.

Faucet reminds me Raiblocks. If we have good captcha we can definitely donate some of our COMB to a well designed faucet.
But when faucet goes live, there should already be well tested android mobile wallet. People in less wealthy countries are mostly going to claim from their phones and so they need a good mobile wallet to cashout to.

There is no rush to get on exchange in my opinion. But if someone lists haircomb on an exchange I will be more than happy.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 09, 2019, 03:25:10 PM
Syncing guide - windows.

  • Are you expecting a haircomb payment and want to receive it to your own wallet?
  • Do you want to pay with your haircombs?
  • Do you want to create commits.db file yourself, so that you don't need to trust others to give you the correct file?
  • Do you want to monitor people claiming combs in real time?
Then you need synced haircomb core wallet. Learn how to do this using this guide.


Prerequisites. You should have more than 250GB free disk space. Should have reliable electricity supply, with no planned power loss.

1. Download combfullui.exe from github and place it to it's own folder
2. Download btc.zip (the modified bitcoin qt 0.18.1) and unzip it.

1472af7188352b3cb95770834b260c6c44631ec528351b9d2aae49ffb17ab683  btc.zip
https://www.mediafire.com/file/3lv9o890w2g4c68/btc.zip/file (https://www.mediafire.com/file/3lv9o890w2g4c68/btc.zip/file)

https://i.postimg.cc/8cBGqJBf/001.png

2. Run combfullui.exe, a window should appear. This window should not be closed. Leave it running.

https://i.postimg.cc/LXzjbg0Q/002.png

3. Go to btc/bin folder, you should see the modified bitcoin qt. It should have orange circle icon.

https://i.postimg.cc/RZZYc4bn/003.png

4. Run bitcoin-qt.exe, select your data dir (place it to the disk with 250GB free space).
5. When bitcoin main window synchronizes the headers and starts downloading blocks, restart it. You should see the intro window:

https://i.postimg.cc/ydGfXZtJ/004.png

6. You can let it sync for several days. When you get to block 486600 or more you can check https://127.0.0.1:2121 in browser, you should see on that it is now syncing the haircomb core with the required data.

https://i.postimg.cc/pVG9CBsc/005.png

7. If you are expert who copied over index chainstate and blocks from existing bitcoin installation, you will see the following Rescanning screen on startup:

https://i.postimg.cc/fRwRhtqS/006.png

It appears like there is no progress but there is. Simply wait patiently until Rescanning... is over and your core wallet appears.

8. Finally you get to the stage where only a few blocks remain. Wait until it's finished.

https://i.postimg.cc/JnQpvFsk/007.png

9. If you refresh your haircomb core browser observe that the blocks being synced are identical in the last stage.

https://i.postimg.cc/g2Rfcmr9/008.png

10. Finally it's synced. You should see the total number of blocks synced in haircomb core is same as on Bitcoin network.
You can also verify with other synced haircomb users that the fingerprint in their haircomb core is the same as yours.

https://i.postimg.cc/g2X6nBPb/009.png


general usage - shutdown

1. close bitcoin core, wait until the close window disappears.
2. go to 127.0.0.1:2121 and press safe shutdown. The wallet should close.

general usage - startup

1. start combfullui.exe
2. go to 127.0.0.1:2121, verify it is running
3. start bitcoin-qt.exe

general usage - commits.db database backup

1. shutdown bitcoin core, then safe shutdown combfullui.exe
2. copy commits.db to a backup location while the wallets are shutdown.





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 10, 2019, 04:42:35 PM
Syncing guide - windows.

1. Download combfullui.exe from github and place it to it's own folder
2. Download btc.zip (the modified bitcoin qt 0.18.1) and unzip it.

1472af7188352b3cb95770834b260c6c44631ec528351b9d2aae49ffb17ab683  btc.zip
https://www.mediafire.com/file/3lv9o890w2g4c68/btc.zip/file (https://www.mediafire.com/file/3lv9o890w2g4c68/btc.zip/file)
2. Run combfullui.exe, a window should appear. This window should not be closed. Leave it running.
3. Go to btc/bin folder, you should see the modified bitcoin qt. It should have orange circle icon.
4. Run bitcoin-qt.exe, select your data dir (place it to the disk with 250GB free space).
5. When bitcoin main window synchronizes the headers and starts downloading blocks, restart it. You should see the intro window:
6. You can let it sync for several days. When you get to block 486600 or more you can check https://127.0.0.1:2121 in browser, you should see on that it is now syncing the haircomb core with the required data.
7. If you are expert who copied over index chainstate and blocks from existing bitcoin installation, you will see the following Rescanning screen on startup:
It appears like there is no progress but there is. Simply wait patiently until Rescanning... is over and your core wallet appears.
8. Finally you get to the stage where only a few blocks remain. Wait until it's finished.
9. If you refresh your haircomb core browser observe that the blocks being synced are identical in the last stage.
10. Finally it's synced. You should see the total number of blocks synced in haircomb core is same as on Bitcoin network.
You can also verify with other synced haircomb users that the fingerprint in their haircomb core is the same as yours.


Hi! looking forward to this interesting project, I am on step 6, is there any way i can speed up this process? possibly download the blockchain on torrent and be able to sync faster? currently says estimated time left 6weeks.
Would love to get started faster.
Thank You


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 10, 2019, 04:59:27 PM
Hi! looking forward to this interesting project, I am on step 6, is there any way i can speed up this process? possibly download the blockchain on torrent and be able to sync faster? currently says estimated time left 6weeks.
Would love to get started faster.
Thank You

Hi I see..
Unfortunately this is how Bitcoin works (I'm not responsible for that) and only way to bypass the 250GB download is to get the files from another Bitcoin user.
The files you need is index folder chainstate folder and blk.dat rev.dat. Don't copy everything and especially don't copy other person's wallet.dat as yours. (They will see keys inside that wallet and when you deposit there they will steal your BTC).

Another option is to get commits.db from another user you trust. That file has like 30MB but fake file could mean you would see haircombs in your wallet that aren't actually real.

Hope that helps.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 10, 2019, 05:19:23 PM
Hi! looking forward to this interesting project, I am on step 6, is there any way i can speed up this process? possibly download the blockchain on torrent and be able to sync faster? currently says estimated time left 6weeks.
Would love to get started faster.
Thank You

Hi I see..
Unfortunately this is how Bitcoin works (I'm not responsible for that) and only way to bypass the 250GB download is to get the files from another Bitcoin user.
The files you need is index folder chainstate folder and blk.dat rev.dat. Don't copy everything and especially don't copy other person's wallet.dat as yours. (They will see keys inside that wallet and when you deposit there they will steal your BTC).

Another option is to get commits.db from another user you trust. That file has like 30MB but fake file could mean you would see haircombs in your wallet that aren't actually real.

Hope that helps.

Speed up a lot! less then 10hours to go, and gets faster.

Where does the satoshi go when attempting to claim? is this satoshi going to forever be locked/lost? (interesting if this decreasing circulating btc)
Is this coin stored in tx data on the first layer? so its not a side chain or 2nd layer, its a coin that lives on first layer btc chain in the tx data.
By running this edited qt client, is this also essentially running a full node for btc?

Looking forward to faucets to help distribute this.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 11, 2019, 05:28:11 AM
Speed up a lot! less then 10hours to go, and gets faster.

Where does the satoshi go when attempting to claim? is this satoshi going to forever be locked/lost? (interesting if this decreasing circulating btc)
Is this coin stored in tx data on the first layer? so its not a side chain or 2nd layer, its a coin that lives on first layer btc chain in the tx data.
By running this edited qt client, is this also essentially running a full node for btc?

Looking forward to faucets to help distribute this.

Yes, claim satoshis are provably burned. When someone is confirming payment and pays to those 21 addresses those coins sent there are also provably burned.

Yes tx data (outputs) is where the commitments are anchored in the host blockchain. Haircomb can be deployed atop any blockchain or consensus system that reaches consensus about a set of values.

Yeah haircomb users are running btc full nodes and they are indistinguishable from actual btc users. Contrast this with e.g. monero  where there is a separate network that can be monitored and / or traced.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 11, 2019, 11:25:57 AM
nice! now some question about claiming,
what is happening? does sending 546 sats guarantee a claim? or does it give a chance? whats the chance there?
does using more sats/byte give higher chance? or can use low sat/byte and just wait till miner accepts it.
if comb didnt get claimed can sending to same miner address give it another chance? or if comb are claimed, can u send again to same address or need to use a new one?

thnx

edit, so i read the white paper, and seems to answer some of my questions,
im wondering what would be the best strategy to claim comb
can only 1 comb claim be allowed per btc block? so would make no sense to try several attempts in the mempool, only one at a time.

any general tips on how to claim comb efficiently? paying highet sat/byte doesnt really make sense as that can be quite expensive, making comb cost more then $.50 just in tx fees to claim.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 11, 2019, 04:01:35 PM
I cannot give you the only true way to claim COMB, because there appear
to be many strategies or ideas that are viable.

Currently a good way is to claim it using an unrelated Bitcoin or haircomb
transaction that you are going to do anyways. It is a no-brainer to add the first
destination of 546 sats to participate in the COMB lottery. If everyone was
doing this the COMB claiming network would be very decentralized.

Faucet claiming is also nice option for people who use Bitcoin faucets.

There is a shady way to claim COMB when a tumbler operator claims combs using
every tumbling operation the customers make on the tumbler. I won't ever be
doing this, and it is probably illegal.

Exchanges can also claim COMB. Fair exchanges will split the COMB between
people who made withdrawals, unfair exchanges will keep the COMB for themselves.

Child pays for parent transactions are also an option. Claimer creates many lower
fees transactions that depend on each other. To pocket a good fee, miner has
to include several in the sequence. This produces a burst of transactions maybe
giving an increased chance that one of the burst transactions wins the reward.

Replace by-fee is worth studying. In this strategy the claimer monitors the
memory pool, looking for highest fee haircomb claiming transaction. Then the
claimer proceeds to set an even higher fee to their own claiming transaction.

Now many people do not know about COMB. Currently, yeah, if you do transactions
for the sole purpose of claiming COMB, then you are going to pay hefty fees.
This is because multiple pools appear to sort transactions by fees and you
have to be on the top to win.

But if a paradigm shift occurs (invention of a powerful quantum computers),
the price of comb could explode beyond everyone's expectations. Suddenly,
claiming there at the beginning wins each early adopter a hefty profit.

But a dump scenario could be also profitable. When Bitcoin miners start claiming
COMB (it is possible to place COMB claim to a Bitcoin coinbase bypassing any
ordinary claimers). Suddenly COMB price could collapse to new lows. Those who guess
and identify the real bottom correctly and buy will walk away with a 100%
guaranteed profit.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: TimeWarperHH on November 11, 2019, 06:38:10 PM
Are they any technical requirements to claim COMB? Can I claim also with a normal desktop PC with Win10?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 11, 2019, 08:38:45 PM
Are they any technical requirements to claim COMB? Can I claim also with a normal desktop PC with Win10?

claiming these comb is as easy as sending a 546 sats to a bc1 segwit address generated as the miner address and being the first in the block to make such a tx, this can be done from any segwit wallets.
but to see the comb in your wallet and to send them, you need to run a full node btc client modified. there is instructions for that above.

if anyone willing to start claiming comb, im interested to buy some for 1k sats per claim. can possibly negotiate a price


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: albertorm2 on November 12, 2019, 12:01:43 AM
Sorry If I am missunderstanding anything. I was about to send some comb to a friend of mine. Just as the whitepaper says, I had to pay 546 satoshi to each of these 21 numbers. This plus the fees makes the transaction fees too high.

How can that scale? Am I missing something? How are we going to get a functional faucet?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 12, 2019, 06:04:15 AM
Sorry If I am missunderstanding anything. I was about to send some comb to a friend of mine. Just as the whitepaper says, I had to pay 546 satoshi to each of these 21 numbers. This plus the fees makes the transaction fees too high.

Hello, we take scaling very seriously. Truth is users pay Bitcoin fees for their transfers, and you need to fund 21 addresses to confirm payment.

The good thing is anyone can pay to huge number of addresses, using one payment, at once, by using liquidity stacks. This is not only an idea, it is actually implemented and working (but not user friendly).

The way it works with 2 receivers is this:

Suppose you want to pay 2 users AAA BBB each 0.1 COMB Your change address is DDD.

So you create 2 liquidity stack entries the first uses DDD AAA addresses and pays to AAA 10000000 smallest units. The address of first liquidity stack becomes EEE.

Next you create another liquidity stack entry that uses EEE , BBB addresses and pays to BBB 10000000 smallest units. The address of this stack becomes then FFF.

And then you fund FFF stack using your comb.

This scales to any number of receivers, using one payment.


How can that scale? Am I missing something? How are we going to get a functional faucet?

I'm very proud about how scalable COMB is. Faucet/exchange is going to pay out a huge batch of COMB every hour/day and confirm tons of payments by funding 21 addresses once a hour/day.

Hope that helps.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: new@age on November 14, 2019, 05:24:51 AM
COMB is mineable?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 14, 2019, 06:26:12 AM
Anyone tested the wallet?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 14, 2019, 04:58:05 PM
COMB is mineable?

COMB is claimable on the Bitcoin main network. If the project becomes successful, will be mineable by using a generic SHA256d hardware in a specific Bitcoin pool that pays out COMB rewards.

Anyone tested the wallet?

Yes, I've tested it very thoroughly. Multiple people are running it as we speak.

I did not plant any backdoor / malware / phone home functionality. It simply opens a  web server on 127.0.0.1:2121 and reads/writes files in it's current folder that's all it does.

You can use your favourite sandbox/virtualization.

If you are worried about phone home you can run it offline. You only need commits.db all signing/payments/validation can be done purely offline.

I don't care



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 15, 2019, 08:38:23 PM
What's the most efficient way to claim COMB?
I've been trying to claim some but the wallet hasn't synced yet still so I can't see if I've successfully claimed any, but I generated a bunch of addresses in the wallet then used 'pay to many' to send 546 sats to each mining address, with a decent fee. Is there a better way? ???


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 15, 2019, 09:04:05 PM
What's the most efficient way to claim COMB?
I've been trying to claim some but the wallet hasn't synced yet still so I can't see if I've successfully claimed any, but I generated a bunch of addresses in the wallet then used 'pay to many' to send 546 sats to each mining address, with a decent fee. Is there a better way? ???

as far as i can understand, only 1 claim per block, and your tx has to be the first bc1 tx in the block to get the claim.
so claiming several in 1 tx wont work.
the best way would be when the blocks are more empty, and the sat/byte for the first bc1 tx is cheaper. you can also scout the mempool and overcut the highest bc1 tx so yours can be first. (this is because most miners put the tx's in order of highest fee first)
so ideally when the mempool is empty or more specifically bc1 tx are really cheap sat/byte then you can attempt to claim once per block.
if your tx is the first bc1 tx in the block then i understand your claim should be successful.

natasha can chime in and explain if im correct or not.

ive noticed some irregular mempool activity today, and some of those where tx's of 546 sats to bc1 addresses, coming from a binance wallet.
so seems like someone attempted to claim or it could of been them moving combs since that would require sending to 21 addresses.

im still learning myself, so feel free to correct me, just sharing what i think is going on.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 15, 2019, 10:00:55 PM
What's the most efficient way to claim COMB?
I've been trying to claim some but the wallet hasn't synced yet still so I can't see if I've successfully claimed any, but I generated a bunch of addresses in the wallet then used 'pay to many' to send 546 sats to each mining address, with a decent fee. Is there a better way? ???

as far as i can understand, only 1 claim per block, and your tx has to be the first bc1 tx in the block to get the claim.
so claiming several in 1 tx wont work.
the best way would be when the blocks are more empty, and the sat/byte for the first bc1 tx is cheaper. you can also scout the mempool and overcut the highest bc1 tx so yours can be first. (this is because most miners put the tx's in order of highest fee first)
so ideally when the mempool is empty or more specifically bc1 tx are really cheap sat/byte then you can attempt to claim once per block.
if your tx is the first bc1 tx in the block then i understand your claim should be successful.

natasha can chime in and explain if im correct or not.

ive noticed some irregular mempool activity today, and some of those where tx's of 546 sats to bc1 addresses, coming from a binance wallet.
so seems like someone attempted to claim or it could of been them moving combs since that would require sending to 21 addresses.

im still learning myself, so feel free to correct me, just sharing what i think is going on.

For some reason I thought you only had to outbid another Comb claimer for the fee to be first in the block but I just realised there would be no way to tell the difference between them right? But that sounds like it could get expensive since some people use high fees. I just used the slider on Electrum and ended up paying between 0.50 and $5 per tx. And yeah I saw the mempool thing too but seems unlikely since they moved so much?
Ah, I tried claiming some anyway I guess I'll just wait for the faucet if there ever is one unless anyone is selling then I will buy some. Guess we'll see what happens



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 15, 2019, 10:45:33 PM
the implications on if this actually takes off, this can be really huge for bitcoin.
one is that it will be a further btc sink, as if the 546 sat txs are actually verifiably burnt, then thats great for overall deflation of btc!
2nd is that, this can create a more competitive tx fee market, even if just for 1 claim per block, it can put a staple for atleast 1 tx pet block to have a higher fee, overall this helps support the security of the btc network since it helps create market for layer one fees.

im curious to see more prominent btc devs say on this project. as this could be a potentially huge advancement, having totally anonymous transfer on btc first layer, and creating further deflation, and ontop of that helping create a higher fee market, its a win win in every direction for btc. (atleast in my opinion)

if this takes off, we might even see different flavors of such tokens on the network, further increasing deflation, and also further creating more market for fees.
higher fees is essential imo for btc security long term.

im curious on how the supply mechanics of this comb token works, does the amount per claim change?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 15, 2019, 11:21:28 PM

im curious on how the supply mechanics of this comb token works, does the amount per claim change?


Don't know the mechanics of how or why it changes but the amount per claim seems to change slightly.

1.59906193   COMB
1.59906156   COMB
1.59906118   COMB

The last 4 digits at least. If you mean over time like halvening then I'm not sure

Edit: Read the whitepaper again.

"The supply has 8 decimal places, reward decreases at a subexponential rate. System scales with the number of inputs spent multiplied by the size of one signature (21 hashes). Using a Merkle tree segment signer can route coin to one of 65536 outputs by revealing two commitments (2 hashes), enabling atomic swaps and other constructs."


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 16, 2019, 04:29:53 PM
im looking to buy some comb, if anyone would be nice to sell some let me know, we can use an escrow if needed,
5k-10k sats per comb depending on amount, can also neg a better rate depending on quantity


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 16, 2019, 05:04:49 PM
im looking to buy some comb, if anyone would be nice to sell some let me know, we can use an escrow if needed,
5k-10k sats per comb depending on amount, can also neg a better rate depending on quantity

Pretty sure it costs more than that in fees to claim.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 16, 2019, 05:38:18 PM
im looking to buy some comb, if anyone would be nice to sell some let me know, we can use an escrow if needed,
5k-10k sats per comb depending on amount, can also neg a better rate depending on quantity

Pretty sure it costs more than that in fees to claim.

what do you think is a fair price? how bout 50k sats

edit: come to think of it, small transfers wouldnt be worth atm since alot of it would be to fees.
might have to just continue my luck on claiming instead.

edit2: what happens to a failed attempt? i see the mining address is not shown in the wallet anymore, can i still use the same mining address to try again?
or only can use a new one?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 16, 2019, 07:58:04 PM

what do you think is a fair price? how bout 50k sats

edit2: what happens to a failed attempt? i see the mining address is not shown in the wallet anymore, can i still use the same mining address to try again?
or only can use a new one?
Maybe some paid much less in fees so someone might sell for cheaper. I'd like to buy some Comb too but it seems we're pretty early.

You can't use the same mining address twice even if the first claim was unsuccessful. I wasted some btc attempting it (sent about 40txs, lol). And if someone else (a non Comb address) claims the Comb from the block then that Comb is burned since they can't access it. I think the best way to claim is by checking the mempool for the highest fee and then paying more than it, so if you know of any good sites to check for that then I'm interested to hear it.

Did you find out if when sending 1 Comb you have to send 546 sats to 21 addresses by the way? Pretty interesting if so because every time Comb is sent then BTC would be burnt simultaneously. I haven't tried to send any yet.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 16, 2019, 08:08:54 PM
looks like from natasha previous answer that yes to send comb from one address to another 21 burnt addresses need to be funded,
though it seems it doesnt have to be a single tx, and instead can be a multiple output tx, so funding 21 burnt addresses can be sending and receiving of multiple addresses,

yes we are early, ;)



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 17, 2019, 04:58:00 PM
ive noticed when shutting down the wallet, then turning it back on, it takes a long time "sending commitments press q to shutdown x%"
is this normal? does this always take a long time when restarting the client? is there anything that can be done to speed that up? i mean after having a fully synced node, and restarting same thing takes forever to load back up

edit:
looks like forgot about this step
"general usage - shutdown

1. close bitcoin core, wait until the close window disappears.
2. go to 127.0.0.1:2121 and press safe shutdown. The wallet should close.

general usage - startup

1. start combfullui.exe
2. go to 127.0.0.1:2121, verify it is running
3. start bitcoin-qt.exe

general usage - commits.db database backup

1. shutdown bitcoin core, then safe shutdown combfullui.exe
2. copy commits.db to a backup location while the wallets are shutdown."

will make sure to copy the commits.db this time, and shut down properly.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 17, 2019, 06:20:11 PM
Is there a way to check if you have successfully claimed or not without the wallet being synced? The Comb Rewards Viewer site seems to be broken (unless it requires the wallet to be synced).



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 17, 2019, 06:33:56 PM
Is there a way to check if you have successfully claimed or not without the wallet being synced? The Comb Rewards Viewer site seems to be broken (unless it requires the wallet to be synced).



only way i was able to check is from full sync. i had it going yesterday, but i guess the commits.db didnt save so resyncing it again today.

still not 100% sure how it exactly works, since ive noticed times when i used low sat/byte and i was really far down in the block, and had many other tx's to bc1 addresses that were also p2swh txs but i still got the claim. edit: meaning other txs payed higher fee and were ontop of mine and also to bc1 addresses and also p2swh but i still got the claim

so im wondering what explorer i can use to identify which exact type of tx will work for a claim, this way i can scout previous blocks and see whats going on to somehow predict the network activity that the next block might bring.

currently i used blockstream.info


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 17, 2019, 06:53:08 PM

only way i was able to check is from full sync. i had it going yesterday, but i guess the commits.db didnt save so resyncing it again today.

still not 100% sure how it exactly works, since ive noticed times when i used low sat/byte and i was really far down in the block, and had many other tx's to bc1 addresses that were also p2swh txs but i still got the claim. edit: meaning other txs payed higher fee and were ontop of mine and also to bc1 addresses and also p2swh but i still got the claim

so im wondering what explorer i can use to identify which exact type of tx will work for a claim, this way i can scout previous blocks and see whats going on to somehow predict the network activity that the next block might bring.

currently i used blockstream.info


I have a list of 3000 successful comb claims if you want I can email you it or something or post it in a pastebin 


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 17, 2019, 07:00:19 PM

only way i was able to check is from full sync. i had it going yesterday, but i guess the commits.db didnt save so resyncing it again today.

still not 100% sure how it exactly works, since ive noticed times when i used low sat/byte and i was really far down in the block, and had many other tx's to bc1 addresses that were also p2swh txs but i still got the claim. edit: meaning other txs payed higher fee and were ontop of mine and also to bc1 addresses and also p2swh but i still got the claim

so im wondering what explorer i can use to identify which exact type of tx will work for a claim, this way i can scout previous blocks and see whats going on to somehow predict the network activity that the next block might bring.

currently i used blockstream.info


I have a list of 3000 successful comb claims if you want I can email you it or something or post it in a pastebin 


what for?
ill sync my client it should be done in a few hours, and i will be more careful to save the commits.db and shut it down properly.

how do you know those 3000 are successful? if you dont have a fully synced node?
wow thats alot! what was your average price in fees did you use? sat/byte?
did you find any patterns or better times to claim?
any specific strategy you used?
how much sat per tx average per claim?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 17, 2019, 07:06:40 PM
what for?

ill sync my client it should be done in a few hours, and i will be more careful to save the commits.db and shut it down properly.

how do you know those 3000 are successful? if you dont have a fully synced node?
wow thats alot! what was your average price in fees did you use? sat/byte?
did you find any patterns or better times to claim?
any specific strategy you used?
how much sat per tx average per claim?

No no I don't mean I claimed that many, I don't know how many I claimed (maybe even 0) because my wallet isn't synced. But the addresses were posted somewhere else and I saved them so I could see what fee they used when I was trying to claim. The wallet will take too long for me to sync (slow connection and computer) so I gave up with that for now. But maybe they will help you work out what kind of txs work best when claiming. I tried looking when I was claiming but I'm not technically proficient enough to know if any were odd etc.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 17, 2019, 07:23:29 PM
what for?

ill sync my client it should be done in a few hours, and i will be more careful to save the commits.db and shut it down properly.

how do you know those 3000 are successful? if you dont have a fully synced node?
wow thats alot! what was your average price in fees did you use? sat/byte?
did you find any patterns or better times to claim?
any specific strategy you used?
how much sat per tx average per claim?

No no I don't mean I claimed that many, I don't know how many I claimed (maybe even 0) because my wallet isn't synced. But the addresses were posted somewhere else and I saved them so I could see what fee they used when I was trying to claim. The wallet will take too long for me to sync (slow connection and computer) so I gave up with that for now. But maybe they will help you work out what kind of txs work best when claiming. I tried looking when I was claiming but I'm not technically proficient enough to know if any were odd etc.

Sure make a pastebin. Would love to take a look at successful claims to see more info.
Are these your 3k attempts? or where did you find this list.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 17, 2019, 07:34:29 PM
PRUNING

Pruning is supported. Set prune=1 in your bitcoin-qt and restart it. This will enable manual prune.
Next open core command line and enter:

pruneblockchain 481822

Then wait till a number appears. Once it appears about 100 GB of ancient blockchain data was deleted.

This is especially useful/crucial for SSD disk users.


Next, 3 advises.

1. The commits.db should be backed up when both the wallet and bitcoin-qt is correctly shutdown. Not while it is running.

2. If you need to restore backup commits.db, do it when both the wallet and bitcoin-qt is correctly shutdown. Not while it is running.
 
3. The Sending commitments screen exists because haircomb core upon startup detected that your commits.db is corrupt and it is recreating a new one. Possible reasons:

  • you shut down your pc while core was running - don't ever do this
  • the wallet crashed due to problem that I caused - improbable - you will see error in the comb window and then it will close
  • you shut down your core improperly - don't ever do this

I also strongly advise everyone to manually fully save your wallet to a file as often as needed because the wallet has no auto save feature - it was easier to develop that wallet in this way.

I already dodged a bullet several times using this method.

it is you who is responsible for saving your own wallet to a files of your choice as often as needed but especially every time after creating new keys and new liquidity stacks.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 17, 2019, 11:51:59 PM
having an issue now where the qt client says "done loading" and just stays like that. i did everything correctly as far as i know and shut down the proper way, but on startup. after verifying blocks, just says done loading and either freezes there or just closes after some time.

edit:
might of corrupted the commits.
ill try give it another new sync, and will test again.
could be error on my part somewhere

edit2: fully synced everything working

edit3: can anyone graph the supply over time on a chart? for example desmos?
would love to see how the supply goes over time. to see how much will the reward claim be at 50k blocks from now, 100k blocks, ect.
to see how the reward is effected over time.
thanks!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 18, 2019, 09:38:10 PM
Hello. Recently I've been thinking a lot about this.

Suppose someone had 77.5 COMB what would that person do with them?

If you read this thread carefully then you probably know what I mean.

I know it would be really complicated and some people could pose like two people and so on.

But suppose the final list could be assembled. How would you deliver that list to the person and then back the transaction history?




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 18, 2019, 10:24:46 PM
Hello. Recently I've been thinking a lot about this.

Suppose someone had 77.5 COMB what would that person do with them?

If you read this thread carefully then you probably know what I mean.

I know it would be really complicated and some people could pose like two people and so on.

But suppose the final list could be assembled. How would you deliver that list to the person and then back the transaction history?




Re-read the whole thread.
Have no idea what your talking about.
 ;D


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 19, 2019, 04:20:39 PM
Hello. Recently I've been thinking a lot about this.

Suppose someone had 77.5 COMB what would that person do with them?

If you read this thread carefully then you probably know what I mean.

I know it would be really complicated and some people could pose like two people and so on.

But suppose the final list could be assembled. How would you deliver that list to the person and then back the transaction history?




You mean for a faucet or something?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 19, 2019, 04:55:28 PM
You mean for a faucet or something?

Yeah I'm thinking about paying 0.00000001 COMB to every single person alive. It's possible with today's tech. Only problem is getting the massive list of addresses.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 19, 2019, 07:31:06 PM
You mean for a faucet or something?

Yeah I'm thinking about paying 0.00000001 COMB to every single person alive. It's possible with today's tech. Only problem is getting the massive list of addresses.

even if you had 6billion addresses one for each person alive.
thats 6billion tx's that you need the btc network to do for you.
with 7 tx per second on avg, thats 604k tx per day, thats over 9k days, and over 27 years.
thats if you were the only one making txs on btc.

even if you give that double by making your tx's smaller somehow, thats still over 13years of blocks.
lets say you can even make your txs smaller then that by half, thats still over 6 years of blocks.


so even if you can make btc network produce 28tx's per second, and you had nobody else competing with you for block space. that would still take 6yrs of blocks.
this would cost an enormous amount in fees alone. aside from it not being practical in anyway.
unless theres something im completely missing.

so maybe its better to think of more realistic goals.

how does this even cross your mind?

makes me look at the whole project differently...


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 20, 2019, 04:05:33 PM
unless theres something im completely missing.

You (and others) might be thinking that I've completely lost my mind but let me reassure you that I am not crazy.

Yes, you're missing liquidity stacks. They are completely unusual feature in a crypto currency. Complete breakthrough.

In several years it's going to be completely normal to pay to 1000, 10000, or even 1 000 000 people using one payment, but currently that is not normal, it is not possible with almost all crypto currencies and this is why people do not think it's even possible.

But let me repeat again, it is actually possible.


Proof:

Suppose you want to pay 1000 people and you have their addresses.

You create a liquidity stack with 1000 entries, each entry specifies the next entry, the person's address, and the amount you pay to each of the people.

You end up with the first persons liquidity stack address.


Next you create a normal haircomb transaction from your address to the liquidity stack. NOT to the person. But to the liquidity stack!!!


This gives you 21 bc1q addresses that you need to fund on the bitcoin network.

Once these 21 addresses are funded on bitcoin blockchain (this is a small transaction) the 1000 people have been paid.


Only thing that remains is to give the transaction history to the 1000 people (the same to every person). But remember this does not happen on the blockchain, so it does not matter how large this history is.

Large history size is not a problem and there is no limit how huge the history can become.


When the receivers validate their coins they really own them.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 20, 2019, 09:24:46 PM
unless theres something im completely missing.

You (and others) might be thinking that I've completely lost my mind but let me reassure you that I am not crazy.

Yes, you're missing liquidity stacks. They are completely unusual feature in a crypto currency. Complete breakthrough.

In several years it's going to be completely normal to pay to 1000, 10000, or even 1 000 000 people using one payment, but currently that is not normal, it is not possible with almost all crypto currencies and this is why people do not think it's even possible.

But let me repeat again, it is actually possible.


Proof:

Suppose you want to pay 1000 people and you have their addresses.

You create a liquidity stack with 1000 entries, each entry specifies the next entry, the person's address, and the amount you pay to each of the people.

You end up with the first persons liquidity stack address.


Next you create a normal haircomb transaction from your address to the liquidity stack. NOT to the person. But to the liquidity stack!!!


This gives you 21 bc1q addresses that you need to fund on the bitcoin network.

Once these 21 addresses are funded on bitcoin blockchain (this is a small transaction) the 1000 people have been paid.


Only thing that remains is to give the transaction history to the 1000 people (the same to every person). But remember this does not happen on the blockchain, so it does not matter how large this history is.

Large history size is not a problem and there is no limit how huge the history can become.


When the receivers validate their coins they really own them.



That's interesting, sounds like you've really thought of everything. Where can I see liquidity stacks explained? But how will you give the coin history to everyone without essentially defeating the purpose of the privacy coin?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 20, 2019, 09:34:56 PM
noticed there has been a bunch of 546 sat txs surrounding this address lately 1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ

any idea if it has anything to do with comb? what other reason would there be for specifically so many 546 sat tx's

looks like the 90mb bomb from a few days ago also had something to do with 546 sat tx's (if not mistaken)



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 20, 2019, 09:36:07 PM

edit3: can anyone graph the supply over time on a chart? for example desmos?
would love to see how the supply goes over time. to see how much will the reward claim be at 50k blocks from now, 100k blocks, ect.
to see how the reward is effected over time.
thanks!

I'd like to see this too. I looked into it and tried using Desmos but didn't work, and I think the floor part is Javascript "Math.floor()" function but I'm not a programmer, could be totally wrong

"MAX(2.1-FLOOR((LOG(h)/LOG(2))^6)/100000000, 0)
max is 12423823.18141419
and h is block number can start at current block"



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 20, 2019, 09:45:05 PM
noticed there has been a bunch of 546 sat txs surrounding this address lately 1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ

any idea if it has anything to do with comb? what other reason would there be for specifically so many 546 sat tx's

looks like the 90mb bomb from a few days ago also had something to do with 546 sat tx's (if not mistaken)



I saw that but it's not to a bc1 address though? and a lot of exchanges send those small txs anyway to consolidate dust wallets. Binance did that a few days ago which is why the mempool spiked as it did, but yeah it was strange timing.
I think that's what the dev meant by it's only a matter of them sending to the Comb lottery first (in future), if Comb becomes popular then they have nothing to lose by doing so and if the coin is valuable then they stand to gain by claiming the block reward, as well as it creating a market for fees and everything else. It would make sense if the developer was a miner or affiliated with them or something, I personally don't believe it's just one person and a random 'interesting' project. Whoever released that whitepaper isn't just some random, in my opinion. But we will probably never know





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 20, 2019, 10:15:13 PM
noticed there has been a bunch of 546 sat txs surrounding this address lately 1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ

any idea if it has anything to do with comb? what other reason would there be for specifically so many 546 sat tx's

looks like the 90mb bomb from a few days ago also had something to do with 546 sat tx's (if not mistaken)



I saw that but it's not to a bc1 address though? and a lot of exchanges send those small txs anyway to consolidate dust wallets. Binance did that a few days ago which is why the mempool spiked as it did, but yeah it was strange timing.
I think that's what the dev meant by it's only a matter of them sending to the Comb lottery first (in future), if Comb becomes popular then they have nothing to lose by doing so and if the coin is valuable then they stand to gain by claiming the block reward, as well as it creating a market for fees and everything else. It would make sense if the developer was a miner or affiliated with them or something, I personally don't believe it's just one person and a random 'interesting' project. Whoever released that whitepaper isn't just some random, in my opinion. But we will probably never know





actually the bc1 tx is only for mining burn tip, meaning only when attempting to claim. but in the wallet when you want to send the comb somewhere, (and im assuming liquidity stacks as well) the tx's it asks you to send the 546 sats to fund for transfers ARE NOT BC1 addresses.
so its VERY probable that it has something to do with comb, it would make no other sense for SOOO many 546sat txs surrounding one specific address. or even generally 546sat specifically.

i agree on the idea that exchange has nothing to lose by adding this, and most likely would have such ideas since they are at the advantage for claiming.

what im curious about is if we can see when was the FIRST real claim of comb, can we trace it to AFTER the release of the wallet? if so then its fair game. but if by anychance there was ACTUAL comb claims BEFORE the release, then that would make the project lose credibility.

another interesting point is how under the table this whole project is at the moment. seems like there is not much reason to really go out and make it public, as that would DRAMATICALLY increase the competition. it would be way more advantageous to keep this more under the radar for the time being, to accumulate more while less competition and higher rewards.

trulying hoping that the release of the wallet was the first known claims and everything is honest. in that case, im predicting a quiet under the radar accumulation time, and then possibly more attention as more development is created.

ofcourse nobody knows and it could be nothing happens at all.

non the less there is potential for something great here (aslong as the release was completely honest and NO claims before the wallet release/ann thread)

if anyone has any ideas on how to help the project in the future, we can put our minds together and help out if needs be. though for now it seems to accumulate for cheap while we can is a better strategy, because if this actually adopts it will be VERY competitive and can easily be too expensive for any regular user to even attempt claiming.

when miners start to claim, it will be impossible for anyone other then the miners to claim. at that point the ONLY way you can get comb is buying from miners or previous other comb holders.

for now, anyone that is willing to spend 1-2$ can easily attempt and even successfully claim several times a day.

its most easy to claim when blocks are being found faster, as hashrate increases and difficulty poses to go up, blocks are being found faster, and not as many bc1 new outputs are even sent to the network, making cheap claims very possibly.

some of my cheapest claims are as low as 25sat/byte with total of under 6ksats for the total tx.

edit:grammer and proof read checks


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on November 20, 2019, 11:01:39 PM

actually the bc1 tx is only for mining burn tip, meaning only when attempting to claim. but in the wallet when you want to send the comb somewhere, (and im assuming liquidity stacks as well) the tx's it asks you to send the 546 sats to fund for transfers ARE NOT BC1 addresses.
so its VERY probable that it has something to do with comb, it would make no other sense for SOOO many 546sat txs surrounding one specific address. or even generally 546sat specifically.

what im curious about is if we can see when was the FIRST real claim of comb, can we trace it to AFTER the release of the wallet? if so then its fair game. but if by anychance there was ACTUAL comb claims BEFORE the release, then that would make the project lose credibility.


They could just be sending it yeah that's a good point, I thought something along those lines too but more to do with the fork that happened at the start but that could be unrelated. The only thing is.. the wallets sending the 546 txs have huge amounts of Btc in. That would be f*cking crazy for such an unknown project.
I've been claiming over the past few days but can't check how many yet, maybe one day I'll check and discover it's worth something haha ;D


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 20, 2019, 11:20:56 PM

They could just be sending it yeah that's a good point, I thought something along those lines too but more to do with the fork that happened at the start but that could be unrelated. The only thing is.. the wallets sending the 546 txs have huge amounts of Btc in. That would be f*cking crazy for such an unknown project.
I've been claiming over the past few days but can't check how many yet, maybe one day I'll check and discover it's worth something haha ;D

after you attempted a claim and its included in a block. take a look at that block and look from the top down, look for the first bc1 address output (also needs to be p2wsh, sometimes its P2WPKH, if im not mistaken those wont count), see if its new. if not keep going. until you see yours. if yours is the first new bc1 (p2wsh) then you most likely won.

at least in my experience that is how it worked so far. and you can change your sat/byte accordingly.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 21, 2019, 05:52:51 PM
We can approximate the theoretical maximal number of COMB in circulation using an
Euler mcLaurin formula. Initial assumption is that every block since genesis
is claimed.

Remember the number of smallest units issued in given block is:

MAX(210000000-FLOOR((LOG(h)/LOG(2))^6), 0)

We ignore the MAX and limit ourselves to block heights h from 1 to 21835313

Clearly the supply f(n) at height n is the sum of the above formula from 1 to n:

f(n) = SUM h = 1 -> n  { 210000000-FLOOR((LOG(h)/LOG(2))^6) }

We ignore the FLOOR because we are doing only an approximation.
The 210000000 constant can be put out with multiplier n:

f(n) = 210000000*n - SUM h = 1 -> n  { (LOG(h)/LOG(2))^6 }

The approximation is thus the formula:

f(n) = 210000000*n - ((n*log(n)*log(n)*log(n)*log(n)*log(n)*log(n) - (720 *n *log(n)) + (720 *n) - (6 *n *log(n)*log(n)*log(n)*log(n)*log(n))  + (30 *n *log(n)*log(n)*log(n)*log(n))  -(120 *n* log(n)*log(n)*log(n))  + (360 *n *log(n)*log(n)))*9 - 6492 + log(n)*log(n)*log(n)*log(n)*log(n)*log(n)*4.5)

This is the excel formula (enter it into cell B1):

= 210000000*A1 - ((A1*LN(A1)*LN(A1)*LN(A1)*LN(A1)*LN(A1)*LN(A1) - (720 *A1 *LN(A1)) + (720 *A1) - (6 *A1 *LN(A1)*LN(A1)*LN(A1)*LN(A1)*LN(A1))  + (30 *A1 *LN(A1)*LN(A1)*LN(A1)*LN(A1))  -(120 *A1* LN(A1)*LN(A1)*LN(A1))  + (360 *A1 *LN(A1)*LN(A1)))*9 - 6492 + LN(A1)*LN(A1)*LN(A1)*LN(A1)*LN(A1)*LN(A1)*4.5)


Picture:

https://i.postimg.cc/j5BBzZ6L/combsupply.png





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 21, 2019, 06:34:11 PM
which block # is genesis?

also can you help graph the reward amount?

how much comb will be reward at block 650k, 700k, 750k, ect.

Thank you


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 22, 2019, 02:56:37 AM
Block 601002 is the haircomb genesis... It's the block in whitepaper. This means that noone could have succesfully claimed before that block and all coins before the launch are thus provably burned.

No premine. I've started claiming just as everyone else only after the whitepaper+wallet was posted.

I've subtracted f(601002)  = from the previous formula to make it start from zero coins at block 601002

https://i.postimg.cc/tgwJ1kGv/combsupply2.png

I've zoomed in to the next 100 years period. Haircomb will operate over the course of 500 years.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 22, 2019, 06:19:27 PM
interesting, it looks like the reward decrease is very minimal and happens over VERY long period of time.
less then 7k new maximum amount of new comb per month on average
less then 82k new maximum amount of new comb per year
so in 5 years from now, we would have a maximum of less then 500k combs.

now considering almost more then 50% of blocks arent even claiming, (at the moment)
most likely less then 100 combs are being claimed per day.
the scarcity on comb is real.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 22, 2019, 09:00:55 PM
New version of haircomb core 0.1.0 is available.

46f26569feb991e055cd817b2f1177a517151464a2661ea4e09e6a274fb8940a  combfullui
240416ed1bbb82be0fe8de2481a00fa1cf5e6c3b360e93f85edf479c1e2143fb  combfullui.exe

What is new

Bug fix - Importing large wallet infinite loop.
Feature - Multipayments to large amount of people - easy to use user interface available.

Who must upgrade

Only users who need the fix or want to use multi payments must upgrade. The rest of users can stay on old version.

Compatibility

No hard fork, no soft fork
No change of commits.db format
No change of modified bitcoin-qt api (you can keep using the old modified bitcoin core that you already have)

Upgrading

1. Shutdown bitcoin-qt
2. Shutdown haircomb core (of course save your wallet like on every shutdown)
3. Create a new folder for the new version and move there your commits.db
4. Start haircomb core
5. Start bitcoin-qt

Downgrading

The same except in step 3 you start using the old version of combfullui

How to do multiplayments

Guide will be posted shortly. Don't try it until then.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 23, 2019, 07:00:00 AM
Multi payment guide

Import the coin to your wallet:

https://i.postimg.cc/4ykwb0b3/01.png

Generate another key in your wallet. This will be your change address.
Click pay next to coin. Change address selection will appear:

https://i.postimg.cc/4dBNzCT6/02.png

Click the multipay option with your correct change address.

https://i.postimg.cc/QxMSgcc1/04.png

You can now add the destinations. The amount entered is in the smallest unit (1 unit = 0.00000001 COMB)

https://i.postimg.cc/L4gjmvky/05.png

There can be arbitrarily many receivers limited only by the amount of RAM memory in your computer. The bitcoin fee paid is the same. If you have really powerful server and 77 COMB you can pay to 7 billion people.

Click do payment. Follow the instructions on the next screen. In particular save your wallet (from the main page) during this step.

https://i.postimg.cc/dt8HVJRS/06.png

We funded the 21addresses, and it confirmed. The payment is done.

Once it has 6 confirmations (not earlier!) you can go to main page, and export the coin history to file (right click , save as).

Post that coin history file to all the receivers.







Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 23, 2019, 05:39:08 PM
can you send comb to any btc address? or must it be an address generated from the comb client?
also once you send it and give the proof to someone, how do the receive and import it into comb client?
thanks!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 23, 2019, 07:09:30 PM
can you send comb to any btc address? or must it be an address generated from the comb client?

comb can be paid to haircomb addresses only. it cannot be paid to Bitcoin addresses such as 1xxxx 3xxxx or bc1xxxx.
The reason is the cryptography is very different.

Haircomb address consists of 64 numbers or letters A-F. It can be found in wallet, left to the COMB amount. (after you generate keys)

Another place to get an address is to use the haircomb paper wallet generator, this gives you both comb address and claiming address for one attempt in Bitcoin claiming (to that COMB address).

The user should keep the private key safe, in order to spend the funds from that address.
Private key looks like this /wallet/data/ followed by many characters.

also once you send it and give the proof to someone,


There are two ways to export they shall never be confused. If you confuse them the receiver will steal your money that you give him by accident.

First is fully save as: File name: from the main page. This saves the full wallet including everything and secret keys too. The resulting file appears next to combfullui.exe and you should never give that file to anyone.

Second is export coin history only. This saves things but without the private keys. The coins will be deanonymized to the receiver. They will able to see those coins. But they will not be able to steal coins unless they own the private key.

how do the receive and import it into comb client?
thanks!

There is only one import feature on the main page. It's universal. If the user sends you the coin history place it to a file. Then import that file.

You import your own wallets.dat using the same import feature.

Hope that helps


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 24, 2019, 05:01:21 AM
if there is a multi output tx, and one of the outputs is a never seen p2wsh, but its not the first output of the tx.
would that count to be a possible claim?
or only if its the first tx in the multi output?

thanks


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on November 24, 2019, 06:19:48 AM
if there is a multi output tx, and one of the outputs is a never seen p2wsh, but its not the first output of the tx.
would that count to be a possible claim?
or only if its the first tx in the multi output?

thanks

All never seen p2wsh outputs of tx have the potential to claim comb. Not only the first output of tx.

But output 0 is considered first, then output 1 and so on.. in the output order.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 25, 2019, 11:16:06 PM
https://blockchair.com/bitcoin/mempool/transactions?s=fee_per_kwu(desc)&q=has_witness(true)#
this will help sort current fees in mempool
enjoy


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on December 09, 2019, 02:06:59 AM
any news on whats going on?
anything you working on?
would it be a good idea to be more public about this project so its not looked like it was premine in the early days


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: mnightwaffle on December 16, 2019, 11:54:00 AM
couldn't I just go to:
https://txstreet.com/

from there View the live block, which right now is
https://www.blockchain.com/btc/block/0000000000000000000194594e2a29761b26bb9261dba2c17fe24467fe161a71

and then just find the highest bc1?

so right now the highest bc1 fee is 0.00040000 ($2.829)

So I'd have to outbid them to claim comb?

--

&
would it be difficult to make haircomb for BSV or even bch?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on December 17, 2019, 08:59:48 PM
Hello boys. The project is alive. I'm working on the liquidity stack loops. It will be done when the numbers tell me it's done and not earlier.

I'm working on it in my spare time and I am not paid but that is not the problem. Money won't accelerate the progress only brain power will. I feel that my coins going up in value eventually will be the best reward.

Yeah you have to outbid highest fee payer.

About the possibility of haircomb on BSV or on BCH, it's not directly possible since there is no segwit and thus no 256bit addresses that I am aware of.

Even if those coins had 256bit addresses it would be a not so great idea to run haircomb on it. The reason is it uses sha256 hashing and is prone to 51%/reorg attacks. And succesfull 51 % attack means recently-transacted coin destruction in the worst case (if the attacking miner knows the haircomb coins history)

Haircomb on Litecoin would be a possibility though, it's reasonably powerful, has segwit, and not prone to 51% attacks.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on December 20, 2019, 09:49:42 PM
couldn't I just go to:
https://txstreet.com/

from there View the live block, which right now is
https://www.blockchain.com/btc/block/0000000000000000000194594e2a29761b26bb9261dba2c17fe24467fe161a71

and then just find the highest bc1?

so right now the highest bc1 fee is 0.00040000 ($2.829)

So I'd have to outbid them to claim comb?

--

&
would it be difficult to make haircomb for BSV or even bch?

i took at look at txstreet.com but i cant see where i can see ONLY the highest with a p2wsh output, or even just to check the highest bc1 like you said. but theres nowhere to tick and see the txs in an organized form. unless im missing something. or if your talking about reading their data and organizing it yourself


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on December 27, 2019, 09:38:38 PM
Hello boys, this is an update. Next version seems doable (sometimes next year).

It will be a fork, version number will be 0.2.0.

It will make it possible to create liquidity stack coin loops. Briefly liquidity stack coin loop is when you pay using liquidity stack to an address that will eventually redirect the coin to the same liquidity stack. Under the current rules such coins will be destroyed.

I propose a new rule that will instead send the coin to the change address. This will enable entities to pay back to themselves using stealth address safely. Or to their own old addresses. The coins will simply fall down to their own change addresses and won't be destroyed.

After the fork we will most certainly see a flood of new features most importantly:

stealth addresses - basically you will have your main haircomb address with all your funds on it and have the ability to create any number of stealth addresses to receive coins to this your main address. Funds from others sent to the stealth address redirect to your backing address without fees and without revealing the backing address to anyone.

Stealth addresses are basically feeless redirect addresses.

safe operation of exchanges or custodians - using stealth addresses basically allows custodians or exchanges to operate safely. They generate new stealth address for every deposit for every customer. This fork (0.2.0) brings the new feature that when two customers on the same exchange pay to each other the coins won't be destroyed (due to loop) but simply fall back down to the exchange hot wallet as they should. This is why this fork is so important.




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 02, 2020, 01:26:09 PM
I'm ready. Are you boys ready?  Fork tomorrow or Saturday.

Any objections from major holders?

Please let everyone know.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 03, 2020, 07:02:39 AM

New version of haircomb core 0.2.0 is available.

4d9adaeb67238a9482fbfc4ce0ba8beb5f10233acea4727ad7c5da877e99bca5  combfullui
c783d53115e3c304ba09bef6b90fb4db40c37b0ffd90877149679382a4071568  combfullui.exe

What is new

Fork - liquidity stack output coin can loop back to the same liquidity stack safely

Who must upgrade

All users must upgrade. There is no observable change noticeable by end user
compared to the old 0.1.0 version, except for the underlying fork.

Compatibility

This is a fork
No change of commits.db format
No change of modified bitcoin-qt api (you can keep using the old modified bitcoin core that you already have)

Upgrading

1. Shutdown bitcoin-qt
2. Shutdown haircomb core (of course save your wallet like on every shutdown)
3. Create a new folder for the new version and move there your commits.db
4. Start haircomb core
5. Start bitcoin-qt

Downgrading

The same except in step 3 you start using the old version of combfullui





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 03, 2020, 01:54:18 PM
I'm ready. Are you boys ready?  Fork tomorrow or Saturday.

Any objections from major holders?

Please let everyone know.

how much comb to be considered a major holder?

no objection here.

upgraded and good to go.

thanks!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on January 04, 2020, 12:00:07 AM

Prerequisites. You should have more than 250GB free disk space. Should have reliable electricity supply, with no planned power loss.

1. Download combfullui.exe from github and place it to it's own folder
2. Download btc.zip (the modified bitcoin qt 0.18.1) and unzip it.
1472af7188352b3cb95770834b260c6c44631ec528351b9d2aae49ffb17ab683  btc.zip
2. Run combfullui.exe, a window should appear. This window should not be closed. Leave it running.
3. Go to btc/bin folder, you should see the modified bitcoin qt. It should have orange circle icon.
4. Run bitcoin-qt.exe, select your data dir (place it to the disk with 250GB free space).
5. When bitcoin main window synchronizes the headers and starts downloading blocks, restart it. You should see the intro window:
6. You can let it sync for several days. When you get to block 486600 or more you can check https://127.0.0.1:2121 in browser, you should see on that it is now syncing the haircomb core with the required data.
7. If you are expert who copied over index chainstate and blocks from existing bitcoin installation, you will see the following Rescanning screen on startup:
It appears like there is no progress but there is. Simply wait patiently until Rescanning... is over and your core wallet appears.
8. Finally you get to the stage where only a few blocks remain. Wait until it's finished.
9. If you refresh your haircomb core browser observe that the blocks being synced are identical in the last stage.
10. Finally it's synced. You should see the total number of blocks synced in haircomb core is same as on Bitcoin network.
You can also verify with other synced haircomb users that the fingerprint in their haircomb core is the same as yours



Hello there!

I just learned about this project and I am trying to sync the wallet.
I was past block 500k yet it wasn't synced up and commits.db file was empty.

I decided to restart the process just in case, it is approaching that block number again and the commits.db is still empty.

Should I still follow that procedure? (Besides getting the latest versions from the repo)

edit: will wait for 602614+ blocks as seen on post


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 04, 2020, 04:00:35 PM
Hello! I have version 0.2.1 ready!

It has an awesome feature - stealth addresses.

Hello there!

I just learned about this project and I am trying to sync the wallet.
I was past block 500k yet it wasn't synced up and commits.db file was empty.

I decided to restart the process just in case, it is approaching that block number again and the commits.db is still empty.

Should I still follow that procedure? (Besides getting the latest versions from the repo)

edit: will wait for 602614+ blocks as seen on post



Hello, there is a known limitation in the modified bitcoin core. When running completely for the first time, you should restart the bitcoin core after a while.

The reason is the code that activates the sending of the commits is coded in the intro window. And the intro window is not shown when you run exactly for the first time.

Or you can reset it when you fully sync, It's up to you. The point is seeing the intro window.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 04, 2020, 05:07:11 PM

Prerequisites. You should have more than 250GB free disk space. Should have reliable electricity supply, with no planned power loss.

1. Download combfullui.exe from github and place it to it's own folder
2. Download btc.zip (the modified bitcoin qt 0.18.1) and unzip it.
1472af7188352b3cb95770834b260c6c44631ec528351b9d2aae49ffb17ab683  btc.zip
2. Run combfullui.exe, a window should appear. This window should not be closed. Leave it running.
3. Go to btc/bin folder, you should see the modified bitcoin qt. It should have orange circle icon.
4. Run bitcoin-qt.exe, select your data dir (place it to the disk with 250GB free space).
5. When bitcoin main window synchronizes the headers and starts downloading blocks, restart it. You should see the intro window:
6. You can let it sync for several days. When you get to block 486600 or more you can check https://127.0.0.1:2121 in browser, you should see on that it is now syncing the haircomb core with the required data.
7. If you are expert who copied over index chainstate and blocks from existing bitcoin installation, you will see the following Rescanning screen on startup:
It appears like there is no progress but there is. Simply wait patiently until Rescanning... is over and your core wallet appears.
8. Finally you get to the stage where only a few blocks remain. Wait until it's finished.
9. If you refresh your haircomb core browser observe that the blocks being synced are identical in the last stage.
10. Finally it's synced. You should see the total number of blocks synced in haircomb core is same as on Bitcoin network.
You can also verify with other synced haircomb users that the fingerprint in their haircomb core is the same as yours



Hello there!

I just learned about this project and I am trying to sync the wallet.
I was past block 500k yet it wasn't synced up and commits.db file was empty.

I decided to restart the process just in case, it is approaching that block number again and the commits.db is still empty.

Should I still follow that procedure? (Besides getting the latest versions from the repo)

edit: will wait for 602614+ blocks as seen on post


make sure to follow proper steps on shutting down, at first i didnt notice them and corrupted the commits and needed to start over.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on January 04, 2020, 09:53:55 PM
Hello! I have version 0.2.1 ready!

It has an awesome feature - stealth addresses.

Hello, there is a known limitation in the modified bitcoin core. When running completely for the first time, you should restart the bitcoin core after a while.

The reason is the code that activates the sending of the commits is coded in the intro window. And the intro window is not shown when you run exactly for the first time.

Or you can reset it when you fully sync, It's up to you. The point is seeing the intro window.
make sure to follow proper steps on shutting down, at first i didnt notice them and corrupted the commits and needed to start over.

It is working this time, thanks!



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 05, 2020, 05:30:44 AM
when 0.2.1?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 05, 2020, 06:56:53 PM
Now hehe

New version of haircomb core 0.2.1 is available.

4be2076a5aac1b7672c1c545deed1e440e1db6c86ec8790b20bdbd3b37f8fc14  combfullui
bc6c59db6be63fd53dce5508b27b7be108d4c51b72d8bd8a1c558a421313d7ff  combfullui.exe

What is new

Stealth addresses - each wallet address has plenty of stealth addresses. You can
claim using them as well as receive funds. Before that or after that you can
sweep the funds into your main address.

Safety feature - history export now requires a minimum of 6 (or 7 - to be
determined?) confirmations in order to export your transaction. This means
that you will not expose your commits by accident and won't give a malicious
counterparty a chance to destroy your funds.

Who must upgrade

If you want to try the new features you should update. Otherwise you can stay at
0.2.0. But remember, there is a new safety feature so you perhaps should update.

Compatibility

Not a fork
No change of commits.db format
No change of modified bitcoin-qt api (you can keep using the old modified bitcoin core that you already have)

Upgrading

1. Shutdown bitcoin-qt
2. Shutdown haircomb core (of course save your wallet like on every shutdown)
3. Create a new folder for the new version and move there your commits.db
4. Start haircomb core
5. Start bitcoin-qt

Downgrading

The same except in step 3 you start using the old version of combfullui


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 06, 2020, 01:43:49 AM
is there a simple step procedure of sending comb from one user to another?
what would be the best way to go about sending comb?
thanks


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 06, 2020, 11:43:47 AM
The step by step guide was made for multi-payments. It works.

Main risks when transacting

Scammer trying to help you

  Never send your fully saved wallet to anyone. I will never ask you for your
  wallet, I will request only the transaction history.

Loss of funds due to paying to something that appears
to be an address but it is not an address - or mistyping an address or amount.


  This risk can be eliminated by never typing addresses manually. Pay attention
  to the amounts. Always enter amount in smallest unit (1 unit =0.00000001 COMB),
  never use decimal or thousands separators or spaces. Make sure you are not tired or
  under stress when entering the payment. Double check the total amount displayed.

Funds stuck due to overpaying

  Overpaying means when someone pays 10 COMB while only having 4 COMB in the key.
  What will happen the 4 COMB will be stuck pending for additional 6 COMB paid
  to the same liquidity stack. Never attempt to resolve the situation yourself
  by sending the missing amount. Always stop, fully save your wallet immediately
  once more (to be sure) and ask for assistance if this happens to you.
  If you overpay by a huge amount - for example you pay 9000000.00000000 COMB to
  someone, the funds are most likely effectively lost, but it depends how you
  paid and in what order in the transaction.

Loss of funds due to a confirmed doublespend - due to changing your
mind about the destinations while a transaction was ongoing.


  Unlike in Bitcoin, you cannot change your mind if the 21 addresses
  do not confirm on the blockchain. You need to retry paying again later to
  the same 21 addresses with higher fee. If you modify the transaction you get
  different 21 addresses, never show these to anyone and never pay to them.
  The point of no return is revealing the first 21 addresses made from a key
  to the public.


If you avoid these risks you will be fine


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: miknepa on January 08, 2020, 02:27:38 PM
Ok so how do i claim/buy/mine comb right now?,
i know you can't mine it,
and theoretically also not buy it,
but i'd really like to know how to get hold of comb right now,
i have btc (so sats) and i'd be ready to tip them but i don't know to where, i'm currently syncing my wallet (250gb download), can someone explain to me how to get comb?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 08, 2020, 04:39:50 PM
Ok so how do i claim/buy/mine comb right now?,
i know you can't mine it,
and theoretically also not buy it,
but i'd really like to know how to get hold of comb right now,
i have btc (so sats) and i'd be ready to tip them but i don't know to where, i'm currently syncing my wallet (250gb download), can someone explain to me how to get comb?

If you read through the thread there is information on this already.

But in short you generate an address through the wallet. And send 546 satoshi with a fee that will give you a chance of being the first unseen p2wsh in the block.
If you are the first p2wsh unseen in the block, you have successfully claimed the comb.

With the addition of stealth addresses you can just claim to each new stealth address and then sweep it to your main address.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 09, 2020, 10:34:10 AM
Only a heads up

Next version will be 0.2.2, It will contain a fixes for two medium severity issues.

One big area I want to focus on next is history minimization. It's a feature that allows you to only send history related to a specific coin to the person you are paying to.

History minimization anonymizes all unrelated coins.

I want to have basic history minimization in 0.2.2

As well as I want to work on jsonrpc console, that will be needed for an exchange integration


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 09, 2020, 06:26:45 PM
whats the best way to combine claims from separate generated addresses to a new main address?
now that we have stealth addresses attached to one address.
is there a good way i can combine previous claims to one address?
do i need to fund 21 addresses for each previous claim i would like to move?

or is there a way to make a liquidity stack with all previous claims to go into 1 address
by only funding 21 addresses one time?

the liquidity stacks and funding is a bit confusing still.
what does fold stack do? what does to payment do?

mainly would like to know if i want to send comb from several addresses, does each one need to fund 21 addresses or can liquidity stacks work for inputs as well as outputs?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 10, 2020, 07:12:34 AM
There is not and won't be any way to pay from multiple keys at once.

Our combs are on different keys too. We combine the comb by paying to another
address with comb on it when the mempool is empty and fees are cheap.

Or just wait until you need to pay to more people to make it worth the bitcoin
fee. For example you can sell the comb to different people for pennies.

You can as well claim more comb using the combining payment, simply use a claim
adress as the first address following by 21 commitments, in total 22 addresses.

fold stack - don't use this. it's an experimental feature that merges addresses
you entered so far into one liquidity stack address with their total amount.
It's only used when paying to millions of people or more.

do payment - it's used to continue with the payment when you are ready


New version of haircomb core 0.2.2 is available.

b8b6bb972119b07c570989314617af81a2329c5cd08770ac8404815675190198  combfullui
c9f50a3ed90190e0d33e64342178d2f8cbc70d9e7e64f4736ad6e9a7ad025454  combfullui.exe


What is new

Block reorganization bug fixes - 3 bug fixes - on reorg mine only combbases not all commits, remove combbase from combbases on reorg, set graph dirty on reorg
Loop detector bug fix - this is a safety feature that was fixed to avoid paying to loops
Liquidity stack trickle bug - fixes hang when someone paid to liquidity stack that has 0 amount that caused a loop

Who must upgrade

All users are highly recommended to upgrade because there are reorg fixes

Compatibility

Not a fork
No change of commits.db format
No change of modified bitcoin-qt api (you can keep using the old modified bitcoin core that you already have)

Upgrading

1. Shutdown bitcoin-qt
2. Shutdown haircomb core (of course save your wallet like on every shutdown)
3. Create a new folder for the new version and move there your commits.db
4. Start haircomb core
5. Start bitcoin-qt

Downgrading

The same except in step 3 you start using the old version of combfullui


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on January 11, 2020, 05:06:12 AM
has anyone sold/bought any haircomb yet? or are currently trying to sell them?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 11, 2020, 08:34:01 PM
has anyone sold/bought any haircomb yet? or are currently trying to sell them?


Neither but if someone looking to buy, i can arrange something and use the funds to further claim.
Ofcourse taking a fee because future claims aren't guaranteed.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 13, 2020, 01:25:26 AM
any chance somebody can help by creating a tool to monitor mempool live, and show highest fee unseen p2wsh. this way to help claiming. would help manual claiming tremendously. i assume eventually there will be bots automating this.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: op4 on January 13, 2020, 02:10:04 PM
has anyone sold/bought any haircomb yet? or are currently trying to sell them?


Neither but if someone looking to buy, i can arrange something and use the funds to further claim.
Ofcourse taking a fee because future claims aren't guaranteed.

What would you consider to be a fair price for comb at current state? how many sats do you think are spent in average before one gets a successful claim?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 13, 2020, 09:13:33 PM
has anyone sold/bought any haircomb yet? or are currently trying to sell them?


Neither but if someone looking to buy, i can arrange something and use the funds to further claim.
Ofcourse taking a fee because future claims aren't guaranteed.

What would you consider to be a fair price for comb at current state? how many sats do you think are spent in average before one gets a successful claim?

i think on average 101sat/vbyte fee usually is a successful claim 90% or more of the time. (aslong as mempool isnt being TOO active)
have had lower claims but they are hit or miss, so its almost not worth sometimes to spend attempting when the chance can be a fail. instead can just spend more and its usually successful. (this is also when nobody else is claiming, as if there is someone claiming and they are watching the blocks/mempool, they can easily just increase their fee to outbid you if wanted)

tho with a decent tool to watch the mempool live, it would make it alot easier to attempt claims and increase fees when seeing a new tx that enters that is a new p2wsh output.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 13, 2020, 10:53:38 PM
Hello I can real-time monitor max fee of all P2WSH output transactions in Bitcoin core. It is printed in console. I will add it to next version of modified bitcoin core.

After a block is mined the max fee in mempool is usually small, probably 15-30 sat/byte

But later some expensive transaction arrives and bumps it to like 150 sat/byte, sometimes up to 220 sat/byte

Then a block is mined.

Here is a patch:

Code:
diff --git a/src/txmempool.cpp b/src/txmempool.cpp
index 68f47d5cc..4ca668a15 100644
--- a/src/txmempool.cpp
+++ b/src/txmempool.cpp
@@ -332,6 +332,8 @@ CTxMemPool::CTxMemPool(CBlockPolicyEstimator* estimator) :
     // accepting transactions becomes O(N^2) where N is the number
     // of transactions in the pool
     nCheckFrequency = 0;
+
+    maxP2WSHFee.clear();
 }
 
 bool CTxMemPool::isSpent(const COutPoint& outpoint) const
@@ -399,6 +401,21 @@ void CTxMemPool::addUnchecked(const CTxMemPoolEntry &entry, setEntries &setAnces
     totalTxSize += entry.GetTxSize();
     if (minerPolicyEstimator) {minerPolicyEstimator->processTransaction(entry, validFeeEstimate);}
 
+    // check if it's P2WSH
+    for (unsigned int i = 0; i < tx.vout.size(); i++) {
+     CTxOut out = tx.vout[i];
+     CScript scriptPubKey = out.scriptPubKey;
+     if (scriptPubKey.IsPayToWitnessScriptHash()) {
+ CFeeRate P2WSHFee = CFeeRate(entry.GetFee(), entry.GetTxSize()); // entry.GetTxSize();
+ uint64_t feerate = (((uint64_t)P2WSHFee.GetFeePerK()) << 32 | (((base_blob<256>)tx.GetHash()).GetUint64(0) >> 32));
+ this->maxP2WSHFee.insert(feerate);
+ feerate = *(this->maxP2WSHFee.rbegin());
+ //::maxP2WSHFee = feerate >> 32;
+ printf("MAX FEE IN POOL: %lu\n", feerate >> 32);
+ break;
+     }
+    }
+
     vTxHashes.emplace_back(tx.GetWitnessHash(), newit);
     newit->vTxHashesIdx = vTxHashes.size() - 1;
 }
@@ -553,8 +572,25 @@ void CTxMemPool::removeForBlock(const std::vector<CTransactionRef>& vtx, unsigne
     for (const auto& tx : vtx)
     {
         uint256 hash = tx->GetHash();
-
         indexed_transaction_set::iterator i = mapTx.find(hash);
+
+
+     // check if it's P2WSH
+     for (unsigned int ii = 0; ii < tx->vout.size(); ii++) {
+     CTxOut out = tx->vout[ii];
+     CScript scriptPubKey = out.scriptPubKey;
+     if (scriptPubKey.IsPayToWitnessScriptHash()) {
+ CFeeRate P2WSHFee = CFeeRate((i)->GetFee(), (i)->GetTxSize()); // entry.GetTxSize();
+ uint64_t feerate = (((uint64_t)P2WSHFee.GetFeePerK()) << 32 | (((base_blob<256>)tx->GetHash()).GetUint64(0) >> 32));
+ this->maxP2WSHFee.erase(feerate);
+ feerate = *(this->maxP2WSHFee.rbegin());
+ //::maxP2WSHFee = feerate >> 32;
+ printf("MAX FEE IN POOL: %lu\n", feerate >> 32);
+ break;
+     }
+     }
+
+
         if (i != mapTx.end())
             entries.push_back(&*i);
     }
@@ -586,6 +624,7 @@ void CTxMemPool::_clear()
     blockSinceLastRollingFeeBump = false;
     rollingMinimumFeeRate = 0;
     ++nTransactionsUpdated;
+    maxP2WSHFee.clear();
 }
 
 void CTxMemPool::clear()
diff --git a/src/txmempool.h b/src/txmempool.h
index f7afaec8f..6fe7cff47 100644
--- a/src/txmempool.h
+++ b/src/txmempool.h
@@ -457,6 +457,8 @@ private:
 
 public:
 
+    std::set<uint64_t> maxP2WSHFee;
+
     static const int ROLLING_FEE_HALFLIFE = 60 * 60 * 12; // public only for testing
 
     typedef boost::multi_index_container<


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 15, 2020, 10:25:11 PM
Hi, someone just started claiming using a bot

Very interesting. Is your replace by fee coded properly?

How much btc are you willing to invest?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on January 16, 2020, 01:01:32 PM
Hi, someone just started claiming using a bot

Very interesting. Is your replace by fee coded properly?

How much btc are you willing to invest?
I suppose you aren't referring to me.
But I started claiming with my ''''bot'''' on Monday/Tuesday/Wednesday, but it's off now.

My implementation of replace-by-fee works, but it is not really well done.

As for the amount of btc.... not much since I have very little. But as long as the development continues I am willing to keep claiming.

As soon as I am confident with the performance of the bot I would share it.
But It needs a lot of cleaning to do.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 16, 2020, 11:17:14 PM
I will do a release 0.2.3 with new features: basic coin history anonymization (further improvements possible), used key detection

Used key detection will tell you about already spent coin when you open your wallet the next time, however currently your balance is not zeroed (it's actually zero).

Anonymization is nice it allows you to export history related to particular address only (not just complete wallet history).

Then will look at the Bitcoin core, we can try to release a 0.19.0.1 core. It will display the claims in real time in the info window. It's pretty cool to watch it.

Random fact: Claiming success rate is about 25%



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 17, 2020, 10:16:31 PM
New version of haircomb core 0.2.3 is available.

1b21c5135eb75338e98f7babafab7a29a41ae83002c21f7c581f05a63f141b5c  combfullui
34ba0f06ecbac4cdb3fb723cce2632d0f23c3b9de1620704df2e9fc82ef79aeb  combfullui.exe


What is new

Coin anonymization - enter address you paid to in the history page, a page with only the history related to the specific address will appear (in most cases this history is shorter than the full history)

Detection of spend coin when you load your wallet. This means you will be aware that particular money appears to be already spend. It will show you the block height as well as some address that you funded to spend the coin, this allows you to lookup yourself the spend on some explorer for instance.

I also added a feature that will enable to watch on Bitcoin core the mempool live. But that requires updating the Bitcoin core too (not available currently, will be later).

Who must upgrade

This is a feature only release. Only users that need the new 3 features can upgrade. Others can remain on 0.2.2 at will.

Compatibility

Not a fork
No change of commits.db format
No change of modified bitcoin-qt api (you can keep using the old modified bitcoin core that you already have)

Upgrading

1. Shutdown bitcoin-qt
2. Shutdown haircomb core (of course save your wallet like on every shutdown)
3. Create a new folder for the new version and move there your commits.db
4. Start haircomb core
5. Start bitcoin-qt

Downgrading

The same except in step 3 you start using the old version of combfullui


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on January 18, 2020, 09:43:07 PM
Sorry Kelozar I forgot to send the transaction to you.
Could you please allow DMs?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 18, 2020, 11:50:37 PM
Sorry Kelozar I forgot to send the transaction to you.
Could you please allow DMs?
User 'Fizbann' has not chosen to allow messages from newbies. You should post in their relevant thread to remind them to enable this setting.

i think i just changed mine to allow. you can try, let me know.
mostly looking to see if there is a chain or sends from a certain address. so i can watch if any unconfirmed and steer clear from claiming when you are.
greatly appreciate it!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 26, 2020, 09:32:09 AM
New version of modified Bitcoin Core (0.18.1) is available.

6f97ac8934b98c49ddb0b19adcfb040501b76dcb83be57c698076ccfb3cccc90  btc_0_18_1.zip

This is a feature only release, 0.19.0.1 is not used because it does not display the mempool statistics in the info window.

Requirement

This modified Bitcoin core requires the latest version (0.2.3) of Haircomb core. Please update, if you haven't already.

Features

Display all transactions that qualify to claim haircomb live in info window (TX) together with their fee and amount paid to the address.
Display new blocks live in info window (BLK) but only the transactions from the block that paid less
than 600 sats to the address (suspected haircomb claims).
Display current maximal haircomb claiming fee of all transactions that qualify to claim haircomb in the mempool.
Commits.db corruption prevention improvements.

Updating

1. Shut down the existing Modified Bitcoin Core if it is running
2. Start Haircomb Core if it is not running already.
3. Start the new Modified Bitcoin Core

Downgrading

The same except you stop the new Bitcoin Core version and start the old Bitcoin Core version.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 26, 2020, 01:54:42 PM
New version of modified Bitcoin Core (0.18.1) is available.

6f97ac8934b98c49ddb0b19adcfb040501b76dcb83be57c698076ccfb3cccc90  btc_0_18_1.zip

This is a feature only release, 0.19.0.1 is not used because it does not display the mempool statistics in the info window.

Requirement

This modified Bitcoin core requires the latest version (0.2.3) of Haircomb core. Please update, if you haven't already.

Features

Display all transactions that qualify to claim haircomb live in info window (TX) together with their fee and amount paid to the address.
Display new blocks live in info window (BLK) but only the transactions from the block that paid less
than 600 sats to the address (suspected haircomb claims).
Display current maximal haircomb claiming fee of all transactions that qualify to claim haircomb in the mempool.
Commits.db corruption prevention improvements.

Updating

1. Shut down the existing Modified Bitcoin Core if it is running
2. Start Haircomb Core if it is not running already.
3. Start the new Modified Bitcoin Core

Downgrading

The same except you stop the new Bitcoin Core version and start the old Bitcoin Core version.

how to build the core from the github?
i downloaded a clone zipped, but nowhere there does it have the same /bin folder with qt
thanks


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 26, 2020, 04:50:44 PM
Sorry I apologize.
Follow this link https://github.com/natasha-otomoski/bitcoin/releases (https://github.com/natasha-otomoski/bitcoin/releases)
Then click btc_0_18_1.zip

The file must have checksum of 6f97ac8934b98c49ddb0b19adcfb040501b76dcb83be57c698076ccfb3cccc90

Download, unzip this file and start it as usual. (Make sure your haircomb core is already running)

Source code is mostly for linux users.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Enema on January 26, 2020, 11:37:24 PM
Sorry I apologize.
Follow this link https://github.com/natasha-otomoski/bitcoin/releases (https://github.com/natasha-otomoski/bitcoin/releases)
Then click btc_0_18_1.zip

The file must have checksum of 6f97ac8934b98c49ddb0b19adcfb040501b76dcb83be57c698076ccfb3cccc90

Download, unzip this file and start it as usual. (Make sure your haircomb core is already running)

Source code is mostly for linux users.


Compile error :

Code:
 CXX      libbitcoin_server_a-txmempool.o
In file included from txmempool.cpp:22:
UrlRequest.h:267:6: error: #elif with no expression
 #elif
      ^
In file included from txmempool.cpp:22:
UrlRequest.h:62:81: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
                                decltype(_statusDescription) &statusDescription) throw(IncorrectStartLineException)
                                                                                 ^~~~~
UrlRequest.h:86:94: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
 Response(const std::string &startLine,decltype(_headers)&&headers,decltype(_body)&&body) throw(IncorrectStartLineException):
                                                                                          ^~~~~

In file included from txmempool.cpp:22:
UrlRequest.h:525:24: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
     Response perform() throw(HostIsNullException,Response::IncorrectStartLineException){
                        ^~~~~
make[2]: *** [Makefile:8389: libbitcoin_server_a-txmempool.o] Error 1
make[2]: Leaving directory '/bitcoin-0.18.1-prod/src'
make[1]: *** [Makefile:13010: all-recursive] Error 1
make[1]: Leaving directory '/Desktop/bitcoin-0.18.1-prod/src'
make: *** [Makefile:775: all-recursive] Error 1


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 28, 2020, 07:59:43 AM

Compile error :


Thanks a lot! There should be #else. Strangely the windows build passed OK and the resulting wallet is working fine.

FORK

I have become aware of an issue in the crypto currency and would like to perform a fork triggered at height 620000

The issue is affecting users who transact can become victim of double spend but only if the attacker knows how to do it. The attacker is the sender. Claiming only users are unaffected.

I will do soon a release 0.3.0 with the fork and fix already in it and once we upgrade we simply wait till 620000 and then I would disclose the issue.

I apologize for any inconvenience and would like to remind everyone that this is a new coin with completely new cryptography. Forks are to be expected. This is our third one. Hopefully the last one.

Thank you.


Fun fact: I have a birthday today.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on January 30, 2020, 09:55:34 PM
New version of haircomb core 0.3.0 is available.

8c35d7059a9d8dd23a5417a09704566918c95b2c54bec8828330b9fe1ad6b162  combfullui
ee7d8242047791a372354b94b7113d7e0d8559d74931366298664ef5178f1ba6  combfullui.exe


What is new

Fix for an unspecified issue - fork
Feature - compare commits.db file with other user interactively. Using this tool users can identify the root cause why their commits.db file may be incorrect and whose file is incorrect. If you find any corruption using this tool you are recommended to save your wallet, safe shut down your haircomb core and then delete your commits.db file. On the next start new file will be created using the "Sending commitments" window. It takes about a hour or two to create a new correct file.

Who must upgrade

All users must upgrade before the block 620000 deadline.

Compatibility

This is a fork
No change of commits.db format
No change of modified bitcoin-qt api (you can keep using the old modified bitcoin core that you already have)

Upgrading

1. Shutdown bitcoin-qt
2. Shutdown haircomb core (of course save your wallet like on every shutdown)
3. Create a new folder for the new version and move there your commits.db
4. Start haircomb core
5. Start bitcoin-qt

Downgrading

The same except in step 3 you start using the old version of combfullui

More details

It is safe to claim (regardless if you have upgraded or not).

It is safe to pay funds back to yourself inside your own wallets (regardless if you have upgraded or not).

It is considered dangerous to receive COMB payments from third parties without upgrading and until after the fork activates. So please upgrade, let everyone know and be patient.

The main reason why there is such a long delay is to ensure that 99% of users learn about the fork and upgrade before it. If there will be any users who miss this, then they must upgrade after the fork as soon as possible.

Forks are always a drama but I am personally more worried about people who run with corrupted commits.db file, due to shutting their haircomb core while modified bitcoin runs.

Never run modified bitcoin without haircomb. It causes silent corruptions. This is far more unrelated and more dangerous issue than the fork.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on January 31, 2020, 02:10:35 PM
"I am personally more worried about people who run with corrupted commits.db file, due to shutting their haircomb core while modified bitcoin runs."

Would creating a brand new fresh sync to make a new commits file fix this?
I wouldn't be too worried if anyone can just run a fresh new sync to solve this. (even if it may take some time for a new sync)



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on February 02, 2020, 03:54:18 PM
New version of haircomb core 0.3.1 is available.

5c5c1a9b9f97dbf38381bc09b94bccd3fc6dd59d3d0f14a7665c20eb6f421aab  combfullui
c931da7ba13ed5c2a1c2254896d7e76a438240116d1db2474e32d21a7cb2c878  combfullui.exe

What is new

Fix for an unspecified issue - fork
The previous proposed fork - 0.3.0 - contains multiple flaws. They are addressed in this release
Change to commits.db format to trigger at block 620000

Who must upgrade

All users must upgrade before the block 620000 deadline.

Compatibility

This is a fork
Change of commits.db format at block 620000. It will change automatically, but please don't run outdated versions like 0.3.0 after block 620000 again.
No change of modified bitcoin-qt api (you can keep using the old modified bitcoin core that you already have)

Upgrading

1. Shutdown bitcoin-qt
2. Shutdown haircomb core (of course save your wallet like on every shutdown)
3. Create a new folder for the new version and move there your commits.db
4. Start haircomb core
5. Start bitcoin-qt

Downgrading

The same except in step 3 you start using the old version of combfullui

My answer about bad commits.db file contents

Quote
Would creating a brand new fresh sync to make a new commits file fix this?
I wouldn't be too worried if anyone can just run a fresh new sync to solve this. (even if it may take some time for a new sync)

Yes the issue is easily fixed if the node operator becomes aware of the issue. Furthermore there is 99% no need to sync bitcoin from block 0. Simply sync the haircomb again. Bitcoin blockchain contents is most likely correct.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on February 15, 2020, 03:47:28 AM
looks like interest for this token has mostly been quiet now. have not seen any claims in the info window for days/weeks as well.
also price to claim has been rising due to mempool being more active now. im predicting mempool will continue to be more active as we continue this bull market on btc
good we have had the chance to claim for a bit cheaper earlier.
still looking forward to see what this coin can be worth in the future. in satoshi price ofcourse.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on February 15, 2020, 03:10:17 PM
looks like interest for this token has mostly been quiet now. have not seen any claims in the info window for days/weeks as well.
also price to claim has been rising due to mempool being more active now. im predicting mempool will continue to be more active as we continue this bull market on btc
good we have had the chance to claim for a bit cheaper earlier.
still looking forward to see what this coin can be worth in the future. in satoshi price ofcourse.
Indeed, lucky us that were able to claim when there wasn't much competition.
Now it's more expensive and less probable to win the claim.

Let's see if the updates keep coming






Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on February 25, 2020, 06:23:07 PM
Hello I am back from vacation. On the vacation I've been researching into a viability hash table for haircomb, one that works similar to a bloom filter and is append only (suitable for use in blockchain).
It won't be used anytime soon it remains on the will look at it later list perhaps forever.

In the coming days we will fork so I will explain the boring details of the fork and then, we get into the interesting parts we will be testing Amount Decided Later payments. They are very cool and allow for comb trades (trades between different haircomb tokens -- without an exchange)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: ~Trololoh~ on February 28, 2020, 01:11:04 AM
@natasha-otomoski
You have a very interesting name.  ;D

Ok, here's a 1BTC puzzle.

The question is the following:

WhyTheCombOfNatashaOtomoskiHas21Teeth?.txt

The solution is a 32 characters long plain-text (the private key).

Hint: 8 camel case english words, no special symbols

Happy puzzling!

G/cbms/K/DNzcRin5v2B03iXdbpdVoZbTebt7KG95j3FUqnJvcP9rDYcGpSV27RLspR7SlPjqma4h0tDAMwovIo=

txid 39ae730abf9190f1985a3600e35b6451efc51bfb885bc9d1c3b91d502de3907d


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on March 03, 2020, 10:30:13 PM
Hello. I am happy to report that the fork has today, starting with block
620000, activated successfully.



02C1 6A10: 00 61 99 99[28 91|00 00] 7C A7 4D 99 68 76 8F AA  .a..(... |.M.hv.. 
02C1 6A20: 4F 59 E1 1A 90 4B 91 D5  0C 5C 0A 12 F2 A4 4D 20  OY...K.. .\....M   
02C1 6A30: D3 EB 86 53 6A 8D C7 44  00 61 99 99[31 81|00 09] ...Sj..D .a..1... 
02C1 6A40: 7B BE 91 AA 86 D2 3D 54  B6 59 00 E6 AB 02 E0 87  {.....=T .Y...... 
02C1 6A50: 20 73 E5 D3 FE 45 AE 08  F6 4D 53 8F BF 0E 6D 7D   s...E.. .MS...m} 
02C1 6A60: 00 62 00 00[00 00 00 13] 9D 62 45 AB EA 11 07 CF  .b...... .bE..... 



Full disclosure: Since the beginning of the token the code contained a small
mistake. This mistake should I say flaw was in the utxo tag mechanism. Briefly
every long P2WSH address that you pay to in Bitcoin, since segwit activated,
is tagged along with the block number it occured in as well as the transaction
number within the block and the output number within the transaction. Due to
practical limitations the limit can't be infinite but a small limit of 9999 was
chosen for the transaction number as well as limit of 9999 was chosen for the
output number. The problem is related to what happens when the limit is exceeded.

Fortunately we were using string contatenation so the number did not overflow
into the block counter. But still, it was possible to within a block to send
money using a huge transaction to two destinations A and B according to an intended
rules of the network the funds should go to A, yet the wallet would send them to
B instead. Example:

Pay to address a1 output number 1001 does not overflow, stays 1001
Pay to address b1 output number 10000, gets overflown to 1000
The funds are attributed to B because 1000 < 1001 even though B was paid later
in the block. a1 and b1 are haircomb teeth we assume other teeth were exploited
in the same way.

But there is a worse behavior namely duplicate utxo tags were possible. In
a well designed coin this causes coinburns, in a badly designed coin this is
an inflation vulnerability. So, luckily, we suffered only from unintended
coinburns. But for other misdesigned wallets this could be problem in the future.
Example:

Pay to address a1 output number 1000 does not overflow, stays 1000
Pay to address b1 output number 10000, gets overflown to 1000

We get duplicate utxo tag. The funds are tie-burned even though B was paid later
in the block. a1 and b1 are haircomb teeth we assume other teeth were exploited
in the same way.

Solution: Merge the two limits into one larger block-internal limit of 99999999.
We take transactions out of the picture and whole block is considered to be one
huge transaction. Only a block specific output number is used beyond this point.

The new limit cannot be exceeded due to 1MB (virtually 4MB segwit) block cap.

Because adversaries cannot anymore exploit the issue and pay an unaware user
misattributed funds, this means the adversary cannot entrench the issue into the
economy.

So, you can start transacting whith anyone, now.






Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on March 03, 2020, 11:37:09 PM
Hello. I am happy to report that the fork has today, starting with block
620000, activated successfully.



02C1 6A10: 00 61 99 99[28 91|00 00] 7C A7 4D 99 68 76 8F AA  .a..(... |.M.hv.. 
02C1 6A20: 4F 59 E1 1A 90 4B 91 D5  0C 5C 0A 12 F2 A4 4D 20  OY...K.. .\....M   
02C1 6A30: D3 EB 86 53 6A 8D C7 44  00 61 99 99[31 81|00 09] ...Sj..D .a..1... 
02C1 6A40: 7B BE 91 AA 86 D2 3D 54  B6 59 00 E6 AB 02 E0 87  {.....=T .Y...... 
02C1 6A50: 20 73 E5 D3 FE 45 AE 08  F6 4D 53 8F BF 0E 6D 7D   s...E.. .MS...m} 
02C1 6A60: 00 62 00 00[00 00 00 13] 9D 62 45 AB EA 11 07 CF  .b...... .bE..... 



Full disclosure: Since the beginning of the token the code contained a small
mistake. This mistake should I say flaw was in the utxo tag mechanism. Briefly
every long P2WSH address that you pay to in Bitcoin, since segwit activated,
is tagged along with the block number it occured in as well as the transaction
number within the block and the output number within the transaction. Due to
practical limitations the limit can't be infinite but a small limit of 9999 was
chosen for the transaction number as well as limit of 9999 was chosen for the
output number. The problem is related to what happens when the limit is exceeded.

Fortunately we were using string contatenation so the number did not overflow
into the block counter. But still, it was possible to within a block to send
money using a huge transaction to two destinations A and B according to an intended
rules of the network the funds should go to A, yet the wallet would send them to
B instead. Example:

Pay to address a1 output number 1001 does not overflow, stays 1001
Pay to address b1 output number 10000, gets overflown to 1000
The funds are attributed to B because 1000 < 1001 even though B was paid later
in the block. a1 and b1 are haircomb teeth we assume other teeth were exploited
in the same way.

But there is a worse behavior namely duplicate utxo tags were possible. In
a well designed coin this causes coinburns, in a badly designed coin this is
an inflation vulnerability. So, luckily, we suffered only from unintended
coinburns. But for other misdesigned wallets this could be problem in the future.
Example:

Pay to address a1 output number 1000 does not overflow, stays 1000
Pay to address b1 output number 10000, gets overflown to 1000

We get duplicate utxo tag. The funds are tie-burned even though B was paid later
in the block. a1 and b1 are haircomb teeth we assume other teeth were exploited
in the same way.

Solution: Merge the two limits into one larger block-internal limit of 99999999.
We take transactions out of the picture and whole block is considered to be one
huge transaction. Only a block specific output number is used beyond this point.

The new limit cannot be exceeded due to 1MB (virtually 4MB segwit) block cap.

Because adversaries cannot anymore exploit the issue and pay an unaware user
misattributed funds, this means the adversary cannot entrench the issue into the
economy.

So, you can start transacting whith anyone, now.






anyway to make sure this was not exploited for inflation purpose in history?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on March 04, 2020, 08:00:27 PM
Feature - compare commits.db file with other user interactively. Using this tool users can identify the root cause why their commits.db file may be incorrect and whose file is incorrect. If you find any corruption using this tool you are recommended to save your wallet, safe shut down your haircomb core and then delete your commits.db file. On the next start new file will be created using the "Sending commitments" window. It takes about a hour or two to create a new correct file.
when i open comb 0.3.1 i get "incorrect file size" in the comb window but if i close and reopen it doesn't. is this commits.db problem and i should delete commits.db file and resync?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on March 04, 2020, 10:38:36 PM
Hello. That specific overflow issue (reason why we forked) has no ambiguity
associated. Either there is block before height 620000 with more than 9999 transactions or there isn't.
Either there is a huge transaction before height 620000 with more than 9999 outputs funded by it or there isn't.

Any such abnormality can be used as an evidence and deserves further research.

An inflation issue is a separate issue that would need to be triggered by two factors.
First it required a bug in the wallet that would not burn the coins when equal utxo tags existed.
But I've double checked the code and the operator used for comparison of the tags is correct. So the attacker's coins before height 620000 will get burned.
Secondly inflation issue requires the overflow issue to be abused to actually create the inflation.

I am taking this very seriously and I am actively looking for ways the attacker would approach this and testing my version of the code to see how strong it is.

The fork is step is right direction and is a result of this type of research, fixing a flaw that at first looked innocent but turned out more serious than expected. The simplification of coin rules is another benefit.







incorrect file size - is printed when the coin starts and it discovers the commits.db file was not properly closed. It is an error that may be caused by the user (with high certainity - possible reasons below) or by me when developing the coin (with small certainity)


You should know about the commits.db file that it can exist in one of two possible states: either it is properly closed, or it is not.

Properly closed commits.db file has a size of 40 x N + 32 bytes. Such a file is useful for backup.
Open commits.db file has a size of 40 x N bytes.

This means when you divide the current file size by 40 you get the remainder. And if the remainder is zero then the file is open. If it's 32 then file is correctly closed.

Here are some advices to run the coin correctly:

1. Before you run the coin you can of course check the file is properly closed (do the math). Don't run the coin if the file is open because that is evidence the coin may be still or already running or that you did not close the coin correctly the last time.

2. Don't run the coin from flash drive or a thumb drive. Always copy it to your desktop or to your documents and run it there.

3. Make sure you have windows 10 If you have windows 9 then not everything may be tested.

4. Safely close the coin before making a backup. The coin will properly close the file when you stop the wallet safely. Because open commits.db files are useless as backup. The coin will just print "incorrect file size" and the open file will be emptied.

5. Safely close the coin before shuting down your computer. It will NOT BE SUFFICIENT to press computer shutdown button - you must actually close the coin.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on March 05, 2020, 12:29:03 AM
suggestion, if we can add a counter somewhere that can show how much total claimed comb there is.
maybe look for one new 546 satoshi p2wsh output per block, and if there is one than assume that comb might of been claimed.
add up and see how much total possible comb claims there could be.
might not know exact numbers because a new 546 pwsh output might be or might not be a claim, no way or knowing, also it can be more satoshi also.
but for simplicity case we can assume a possible estimate number of circulating comb?
thanks!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on March 05, 2020, 01:02:40 AM
also if anyone wants to check
You are checking Bitcoin blocks 0 to 619520

Both you and your peer shall now see number 619520 here. Compare it.
Row 1. 0084516c0c023357c20e382fd9a9fc1bdfb9a6a0c4a1bd1e4d402533de7b4b50 71536 difference no data
Row 2. 002a02f181f689ab9f174547dc22ed0db25cff16a090005d661132694a244137 71078 difference no data
Row 3. 2098221674b91032e31d6720c5200e1a256da7eead839e068815e778c5dfa3cd 70977 difference no data
Row 4. 32df90d849147b26a391c10d0d68be1d7ebeb219011f08061238a4d2ae6f21ba 71397 difference no data
Row 5. 4cb4a8c8ba7a4c3ccf68078473ad414fabf98733ccd30d32f4001bdab791b7e3 71569 difference no data
Row 6. 06e407bb63c4cd623233ff361d73eb6750fce4b38bb54bd610baf45e0da3db6e 71012 difference no data
Row 7. 6bce68c37e2c12c607494da5dbc8270c7f90335d59e0b3bfc58cda4940f09846 71445 difference no data
Row 8. 754f1a99f626ba114ce3f028db12b08f976a9ba0701f0efbabd0c90cf401c3d9 70945 difference no data
Row 9. 89f73a956e813c7f7036dcd8eda775492e0d002a6d5e1c86e3dafd57b19cb94f 71421 difference no data
Row 10. 0ecbe39bc02b9017edad49802463023d39f01e3afc22c301cf0cb77f250250e7 71512 difference no data
Row 11. a42952473fc67b9bcc23b9b1aeb81d900d430870221a3b6a45582b0d7a64b904 71401 difference no data
Row 12. 00519f4ea8f4b7b502588809c28eee11fab64804d868e6c9e9a5b8291355ce07 71088 difference no data
Row 13. 004f6dc5f06e3c3deba0c6f4f63c5c84f0dc81758e061110b93d52ec4b1affb7 71698 difference no data
Row 14. 07f07e717f865bace994238b1d8604603914bb1dd77729569513d80d747fb921 71486 difference no data
Row 15. 06bec2feadfaf4b84d2431f17faf07934f10591ede3ee068bfb5d773501316a4 71122 difference no data
Row 16. f5069102cc8ff73aecb78e55b9071062080169a8f95f7d22d698557cc5a227f4 71085 difference no data

Additional information: Locator is b00619520

will update when new batch. feel free to compare and let me know what you guys get. I dont mind to run a fresh sync if I need to.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on March 05, 2020, 10:43:43 AM
also if anyone wants to check
You are checking Bitcoin blocks 0 to 619520

Both you and your peer shall now see number 619520 here. Compare it.
Row 1. 0084516c0c023357c20e382fd9a9fc1bdfb9a6a0c4a1bd1e4d402533de7b4b50 71536 difference no data
Row 2. 002a02f181f689ab9f174547dc22ed0db25cff16a090005d661132694a244137 71078 difference no data
Row 3. 2098221674b91032e31d6720c5200e1a256da7eead839e068815e778c5dfa3cd 70977 difference no data
Row 4. 32df90d849147b26a391c10d0d68be1d7ebeb219011f08061238a4d2ae6f21ba 71397 difference no data
Row 5. 4cb4a8c8ba7a4c3ccf68078473ad414fabf98733ccd30d32f4001bdab791b7e3 71569 difference no data
Row 6. 06e407bb63c4cd623233ff361d73eb6750fce4b38bb54bd610baf45e0da3db6e 71012 difference no data
Row 7. 6bce68c37e2c12c607494da5dbc8270c7f90335d59e0b3bfc58cda4940f09846 71445 difference no data
Row 8. 754f1a99f626ba114ce3f028db12b08f976a9ba0701f0efbabd0c90cf401c3d9 70945 difference no data
Row 9. 89f73a956e813c7f7036dcd8eda775492e0d002a6d5e1c86e3dafd57b19cb94f 71421 difference no data
Row 10. 0ecbe39bc02b9017edad49802463023d39f01e3afc22c301cf0cb77f250250e7 71512 difference no data
Row 11. a42952473fc67b9bcc23b9b1aeb81d900d430870221a3b6a45582b0d7a64b904 71401 difference no data
Row 12. 00519f4ea8f4b7b502588809c28eee11fab64804d868e6c9e9a5b8291355ce07 71088 difference no data
Row 13. 004f6dc5f06e3c3deba0c6f4f63c5c84f0dc81758e061110b93d52ec4b1affb7 71698 difference no data
Row 14. 07f07e717f865bace994238b1d8604603914bb1dd77729569513d80d747fb921 71486 difference no data
Row 15. 06bec2feadfaf4b84d2431f17faf07934f10591ede3ee068bfb5d773501316a4 71122 difference no data
Row 16. f5069102cc8ff73aecb78e55b9071062080169a8f95f7d22d698557cc5a227f4 71085 difference no data

Additional information: Locator is b00619520

will update when new batch. feel free to compare and let me know what you guys get. I dont mind to run a fresh sync if I need to.

I am syncing now again, will ping you once I am done


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on March 05, 2020, 08:28:34 PM
I see the same

Row 1. 0084516c0c023357c20e382fd9a9fc1bdfb9a6a0c4a1bd1e4d402533de7b4b50 71536 difference no data
Row 2. 002a02f181f689ab9f174547dc22ed0db25cff16a090005d661132694a244137 71078 difference no data
Row 3. 2098221674b91032e31d6720c5200e1a256da7eead839e068815e778c5dfa3cd 70977 difference no data
Row 4. 32df90d849147b26a391c10d0d68be1d7ebeb219011f08061238a4d2ae6f21ba 71397 difference no data
Row 5. 4cb4a8c8ba7a4c3ccf68078473ad414fabf98733ccd30d32f4001bdab791b7e3 71569 difference no data
Row 6. 06e407bb63c4cd623233ff361d73eb6750fce4b38bb54bd610baf45e0da3db6e 71012 difference no data
Row 7. 6bce68c37e2c12c607494da5dbc8270c7f90335d59e0b3bfc58cda4940f09846 71445 difference no data
Row 8. 754f1a99f626ba114ce3f028db12b08f976a9ba0701f0efbabd0c90cf401c3d9 70945 difference no data
Row 9. 89f73a956e813c7f7036dcd8eda775492e0d002a6d5e1c86e3dafd57b19cb94f 71421 difference no data
Row 10. 0ecbe39bc02b9017edad49802463023d39f01e3afc22c301cf0cb77f250250e7 71512 difference no data
Row 11. a42952473fc67b9bcc23b9b1aeb81d900d430870221a3b6a45582b0d7a64b904 71401 difference no data
Row 12. 00519f4ea8f4b7b502588809c28eee11fab64804d868e6c9e9a5b8291355ce07 71088 difference no data
Row 13. 004f6dc5f06e3c3deba0c6f4f63c5c84f0dc81758e061110b93d52ec4b1affb7 71698 difference no data
Row 14. 07f07e717f865bace994238b1d8604603914bb1dd77729569513d80d747fb921 71486 difference no data
Row 15. 06bec2feadfaf4b84d2431f17faf07934f10591ede3ee068bfb5d773501316a4 71122 difference no data
Row 16. f5069102cc8ff73aecb78e55b9071062080169a8f95f7d22d698557cc5a227f4 71085 difference no data

Additional information: Locator is b00619520


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on March 09, 2020, 01:38:13 AM
got myself a small stack of comb. not really sure what else i can do now.
don't know if its really worth claiming anymore, since already got a bunch if not more then anyone else.
claiming has been pretty quiet now, havent seen any for weeks. (other then my own)
is there anything we can do to help adoption and to spread awareness?
if anyone wants to build a faucet maybe we can all donate some comb to help seed it?



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on March 19, 2020, 09:21:21 AM
Deployment of the contract feature

Over the course of the next days and weeks we will be testing the contract facility.
This is possible because the user interface is almost ready for use.

This is not a new feature - it existed in the coin since launch. But so far it
has not been extensively used. In fact, no one used it yet on the main network.

We will be using two deciders for testing:

Decider: VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
Associated short decider: PVRSRIILNTNOUQMMNIPHSJOINSHGQSTMHTJGQIVHLKILOLHLIJMKMVMMVRMNISMT
Signed number: 65535
Comb trade contract decision: forward
Amount decided later contract decision: Nearly the max amount to exact amount address, remainder to change address

and

Decider: GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
Associated short decider: UVJKTHSUUTSHHNHROVSGVSINHHTMLGSMJIHRNIIPNJUMJRUITVNOUUKRUSLRUNOO
Signed number: 0
Comb trade decision: rollback
Amount decided later contract decision: Min amount to exact amount address, remainder to change address

What is decider? It is like a key that can sign a contract outcome. When the
outcome has not yet been signed you can get a short decider.
You then can create one or multiple contracts that use the decider. When later the
decider key holder signs with the decider key a long decider is created.

This long decider together with all contract information can then be used to
withdraw money from the contracts the decider is used in.


The deciders above are already decided, this means that:

1. there is no risk that I will not sign or lose key
2. you can test it alone, no need to wait for signing
3. you know the outcome in advance

But this is for test only, In real use the deciders will be undecided and only
later when the users pay to the contract the decider key holder signs the contract.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: bizbiz4 on April 23, 2020, 06:14:12 PM
any updates?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on April 28, 2020, 10:17:46 PM
A computer component malfunctioned (not the disk) and had to be replaced.
I've been too busy with my job that had not time to expect the delivery and
could not simply walk into a store and get it for fiat because COVID 19.

When I finally acquired it I struggled with the Linux drivers. My system has
been running unstable and finally downgrading seems to work around the problem.

I don't have COVID 19.

What needs to be done:

- write some kind of guide for people who want to test the contracts support

- test the 0.3.2 client contracts support without real funds

- we need to release 0.3.2 with the contracts support
  - comb trade
  - amound decided later payment

- public members can do the tests according to the guide to convince themselves that it works

- with real money but preferably with low amounts

- testing will also help to spread awareness because people will try themselves how it works

Next I will start something like my own "exchange" (actually a dex)

- write "exchange comb trade guide" for users

- no fees for me - it will be free of charge to use the dex

- I will publish a file with say 1000 deciders in it. This will mean I could theoretically decide 1000 comb trade contracts

  - will sign the file publicly and also put it on github

- risks:

  - two users paying to the same decider. Always ask me beforehand if it is okay by you to pay to a certain contract!!
  - someone 51% attacks the shitcoin we are trading against - solution: use "quality" shitcoins
  - I will be unable to access the web due some reasons - not a big problem but inconvience for the users - they will have to wait

- probably no web site

- no custody of users funds by me - I will only decide the contracts

- we can have ETH/COMB pair or SOME_SHITCOIN/COMB

- the shitcoin cannot have privacy features because then I will be unable to see if an address has been funded

- no BTC/COMB pair (It is pointless, people can just claim for the "official" fixed exchange rate)


Later the exchange experiment will be shut down

 - after a 1000 trades?? or earlier?

 - publish a new version of COMB core that allows anyone to run their own COMB exchange





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on April 30, 2020, 10:04:00 AM
I don't have COVID 19.
;)

Glad to hear from you, the updates wishlist sounds promising


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: HankePoster on April 30, 2020, 10:38:15 AM
Do you have any real-world use case or it's just another payment system token?
Moreover, you have only one member in the team where are others?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on April 30, 2020, 09:43:42 PM
cool update!

im most curious about what this means
- no BTC/COMB pair (It is pointless, people can just claim for the "official" fixed exchange rate)

last i checked there was no fixed exchange rate, nor anything official
would you mind explain this?

thanks!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 16, 2020, 10:23:36 AM
Hello I don't know about BTC/COMB trading (I'm not economist) but I've implemented the fixed continuously decreasing exchange rate in
between the Bitcoin fees paid for the winning slot and COMB reward.

I don't get how someone would want to sell comb below the claiming rate that they claimed the comb for in the first place.
I don't say it can't happen, just unlikely currently as anyone can claim rather than buy existing comb.

Haircomb core 0.3.2 released

57744a7a74181c3bccd2273c6385f3db7fdfc8a48a46903b7521a8974d030564  combfullui
fe39f430cb93118326b3417499c77641d6b7e1345573e5dfbbd4681af59c3679  combfullui.exe


What is new

Comb trade - possibility of comb trade from the user interface
Amount decided later payment - another example of "basic contract"

Who must upgrade

This update is purely optional - whoever wants to look at the new features can take a look

Compatibility

Not a fork
No change of commits.db format
No change of modified bitcoin-qt api (you can keep using the old modified bitcoin core that you already have)

Upgrading

1. Shutdown bitcoin-qt
2. Shutdown haircomb core (of course save your wallet like on every shutdown)
3. Create a new folder for the new version and move there your commits.db
4. Start haircomb core
5. Start bitcoin-qt

Downgrading

The same except in step 3 you start using the old version of combfullui


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 25, 2020, 08:35:13 PM
FIRST EVER COMB TRADE EVENT THIS WEEKEND

After some additional testing I must say that comb trades contracts look extremely good.

This means that we will perform the first ever COMB TRADE on bitcoin blockchain this weekend!!!!!

For this event I need two users:

Seller - will sell 1 COMB, maker
Buyer - will purchase 1 COMB for BITCOIN, taker

Both users must have:
Spare time during the weekend
Haircomb core and the modified bitcoin core installed and synced at friday
Available funds (seller needs only the 1 comb, buyer must have the proposed btc amount in their own btc wallet)


It will be done using a comb trade and I will act as the decider on the contract.

Full guide will be posted, and I will assist with the whole process.

Please start proposing how much BTC would you offer for 1 COMB


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 26, 2020, 01:59:49 AM
FIRST EVER COMB TRADE EVENT THIS WEEKEND

After some additional testing I must say that comb trades contracts look extremely good.

This means that we will perform the first ever COMB TRADE on bitcoin blockchain this weekend!!!!!

For this event I need two users:

Seller - will sell 1 COMB, maker
Buyer - will purchase 1 COMB for BITCOIN, taker

Both users must have:
Spare time during the weekend
Haircomb core and the modified bitcoin core installed and synced at friday
Available funds (seller needs only the 1 comb, buyer must have the proposed btc amount in their own btc wallet)


It will be done using a comb trade and I will act as the decider on the contract.

Full guide will be posted, and I will assist with the whole process.

Please start proposing how much BTC would you offer for 1 COMB

I am willing to sell 1 COMB for this test, if need a seller.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 26, 2020, 10:21:56 PM
I am willing to sell 1 COMB for this test, if need a seller.



Hello I've been notified that there is a person who is willing to purchase this 1 COMB using $1 worth  of NANO crypto-currency.

That person's COMB address is:

57791311603362245DF3BF9458F65A1023B0EEF58C81CAF98F4B767A57026F51

And Bitcoin claiming address is:

bc1qhaspvpd2xkm0r73cq5mluuwpds0dsfppezrufe9pggsllc6ckx4sfukmac

kelozar, will you install a NANO wallet and create a nano address? If you disagree, please find yourself a buyer!

If someone else wants to be buyer or seller please apply! My choice is still not final.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: JaoBadjap on May 27, 2020, 09:34:22 AM
still figuring out how the comb wallet works,
but working on it.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Aveatrex on May 27, 2020, 11:40:34 AM
I'm willing to help with buying for any major cryptocurrency.But I need a final decision so I don't waste my time with setting up the wallet etc. Let me know if you are decided and interested. You can contact me on  telegram for faster response: @Aveatrex


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 27, 2020, 06:04:54 PM
How many participants? Up to 16 buyers and 16 sellers can participate in the first ever comb trade. The trade will consist of up to 16 different comb contracts.

Who will be rewarded? If you are active on the friday and the contract with your counterparty goes successfully you will be rewarded 0.009 btc.

Information needed: everyone please post your btc address (for btc reward from me). Secondly, please offer the crypto currencies (it cannot be an anonymous coin). The COMB seller needs to have the wallet installed to receive the coin that you offer.

Comb buyer needs to provide their COMB address. It is uppercase and has digits and letters A-F. Please click wallet - key generate to create your address and then fully save your wallet to a file from the main page.

Comb seller needs to provide both COMB address (for return in case of unsuccessful trade) and their <insert coin name here> address that will be used to receive the offered coin during the trade.



Buyers:

[ NANO guy | 1 NANO ]
[ JaoBadjap  | ? COIN ]
[ Aveatrex | Any major crypto ]
[ BotchCamber | Bitcoin or Cruzbit ]

Sellers:

[ kelozar  | 1 COMB ]



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 27, 2020, 06:32:11 PM
please organize yourselves into buyer seller pairs and mail me the required information like your nickname and addresses.
 natasha-otomoski@protonmail.com


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 28, 2020, 02:04:18 AM
I am willing to sell 1 COMB for this test, if need a seller.



Hello I've been notified that there is a person who is willing to purchase this 1 COMB using $1 worth  of NANO crypto-currency.

That person's COMB address is:

57791311603362245DF3BF9458F65A1023B0EEF58C81CAF98F4B767A57026F51

And Bitcoin claiming address is:

bc1qhaspvpd2xkm0r73cq5mluuwpds0dsfppezrufe9pggsllc6ckx4sfukmac

kelozar, will you install a NANO wallet and create a nano address? If you disagree, please find yourself a buyer!

If someone else wants to be buyer or seller please apply! My choice is still not final.

Hello, Unfortunately I am willing to accept ONLY BTC
I can supply more then one buyer.
Will email natasha for details.

Edit: after reading natasha most recent reply I have some questions.

Question1, Will I need to make any btc onchain TX as the seller? and if so how many per trade? (this will help me determine fair price per comb)
Question2, If I am seller for more then one buyer, Will I be eligible for reward .009 btc more then one time? (this will help me determine fair price per trade)

In the case that the answer to my questions is I will NOT need to make any onchain TX, AND I will be eligible for reward per trade.
Then I am willing to accept any Major Crypto (NANO Included) and Any reasonable offer 1$ (As the reward from natasha will outweigh any cost I spent on claiming the comb)


Here is my address information.

address for .009 BTC reward (can use same address if reward multiplies per trade)
bc1q0d2d7g3gm3pxk7grtg5faqzc5upsz5ls2l6jhy

return comb address in case of unsuccessful trade (can use same address if multiple trade)
5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7

nano address for trade1
nano_1buf7xdgsskd4g94rkfut8xsri8u5fdjt4hz8kpuenb498c7ii6hgqr9gd4f

in the case of any other buyer,
here is some more address you can use as payment in btc
bc1qv9f5jd09rpxy3p8aw2d0mwzv7cxhw2pjy0e77s
bc1qy66xcyhr59r48hm6xheduvnkf8zn0mfny0l0f0
bc1qt6ay05zjzdd72hw44qpfcssvdtsvwe99h044wt
bc1qn0krmq9f2f6sffh97clg3c3r3r3l0eyfq2ss7y
bc1qqmnuhrg8u0uy80nvygjggpa06x0mrf207rz7e7

Any questions or if anything else is needed from me please let me know.
Thank you for this opportunity! Excited and very much looking forward!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: espercrypt on May 28, 2020, 03:25:26 AM
Nano trader here.  Just give me instructions and I can do the trade.  I have my wallet and funds ready.  Will be checking in tomorrow and periodically tonight.  Looking forward to seeing how this works in a trustless manner.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 28, 2020, 05:44:26 AM
Hello, hello it's me Natasha

Thank you for the interest all of you. The event will happen in 3 stages.

Stage 1: Everyone will post their own comb address. based on this we will calculate the contracts. Kelozar or the sellers (in general) will fund the comb trade contracts.


Stage 2: Once the transaction confirms (should take 7 blocks) we will make sure that the COMB tokens are in the contracts. Once this is proven people can send their coins (btc, nano) to sellers.


Stage 3: we will be watching the chain and nano dag to see who paid for the contract. Then I will sign the decider that will make the contracts decided in the forward (comb to the buyer) or rollback (comb back to the seller) direction.

Finally: when the decider confirms people can already withdraw the comb from the contract. The same information that was originally used to calculate the contract will be required. Another thing people gonna need to see their comb will be coin history file and up to date commits.db file (both will be posted)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: JaoBadjap on May 28, 2020, 03:13:09 PM
ill be active on Friday, but im having a hard time figuring the wallet out. still reading how do I do it.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: JaoBadjap on May 28, 2020, 03:14:33 PM

Buyers:

[ JaoBadjap  | ? COIN ]

Sellers:

[ kelozar  | 1 COMB ]



BTC


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 28, 2020, 05:52:44 PM
Hi everybody
Quick update.

Got details from natasha that I would need to have 3 comb (for the 3 potential buyers) on 1 key and would need to do 21 tx's on chain in that case.
Either way there is cost involved on my end.
Now additional to this my claim cost, and finally seeing how the mempool is more active these days.
Assuming fees on btc will continue to increase with mempool activity increasing, with the coming bullmarket in the future. Cost of claiming comb has gone up considerably.

Also I have not heard from natasha about the reward for this test. So I am taking this out of the equation for my calculations at the moment.

I will honor the 1 Nano tx because it was suggested by natasha, also to help test cross platform trades.

For the rest I would prefer BTC for now, I believe a fair price would be at a minimum 50k Satoshi per comb. (My belief is that cost to claim would be much higher and with a lower chance of success currently)
If anyone agrees to 50k Satoshi per comb, Feel free to add me as their seller.




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Aveatrex on May 28, 2020, 11:08:43 PM
My wallet is synced and ready to go for friday. Let me know what is the next step.


Also I have not heard from natasha about the reward for this test. So I am taking this out of the equation for my calculations at the moment.

So you're saying only the buyer is elligible for the reward? This doesn't make much sense as there is effort made from both buyer and seller. Both should be rewarded, and if natasha can't afford this I suggest making it 0.0045 BTC for buyer and 0.0045BTC for seller


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: espercrypt on May 29, 2020, 01:30:47 AM
I will have to generate a new wallet address then for the comb contract.  If I am understanding this correctly, this system works through an intermediate similar to an Escrow, who approves the transfer when the conditions have been met?  Or can this system automatically perform the swap based on conditional variables being met, such as in the case of a smart contract?  It would be very novel for a crypto agnostic dex if the latter is the case, and I could foresee a very real future for Haircomb if I am understanding it correctly.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 29, 2020, 02:18:14 AM
My wallet is almost synced and ready to go for friday. Let me know what is the next step.


Also I have not heard from natasha about the reward for this test. So I am taking this out of the equation for my calculations at the moment.

So you're saying only the buyer is elligible for the reward? This doesn't make much sense as there is effort made from both buyer and seller. Both should be rewarded, and if natasha can't afford this I suggest making it 0.0045 BTC for buyer and 0.0045BTC for seller

Yes it might be .0045 for each. or might just be .009 spread for all members.
Either way wanted to keep it out of my calculation since didn't get a direct answer and would still be willing to help test even if there was no reward.
Though if it was truly even .0045 for me on every member then it wouldn't matter what the buyers offer since it would pretty much cover all costs on my end, and we can potentially test out many crypto chains all in the first trade together.

You can add me as your seller if you are willing to pay 50k Satoshi.
You can pick any of my btc address that I pasted earlier in case other might want to as well they can pick a different address of mine for their trade.

I don't mind to spend a few bucks on help testing this.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: JaoBadjap on May 29, 2020, 05:31:21 AM
im gonna wait to clarify things up.
but for the moment this wallet is really giving me a hard time.
I hope natasha could clear things up specially for the reward.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: chainguru12 on May 29, 2020, 06:03:59 AM
Hello, hello it's me Natasha

Thank you for the interest all of you. The event will happen in 3 stages.

Stage 1: Everyone will post their own comb address. based on this we will calculate the contracts. Kelozar or the sellers (in general) will fund the comb trade contracts.


Stage 2: Once the transaction confirms (should take 7 blocks) we will make sure that the COMB tokens are in the contracts. Once this is proven people can send their coins (btc, nano) to sellers.


Stage 3: we will be watching the chain and nano dag to see who paid for the contract. Then I will sign the decider that will make the contracts decided in the forward (comb to the buyer) or rollback (comb back to the seller) direction.

Finally: when the decider confirms people can already withdraw the comb from the contract. The same information that was originally used to calculate the contract will be required. Another thing people gonna need to see their comb will be coin history file and up to date commits.db file (both will be posted)

is it too late for me to partake on this event??
please i need your response so that i can take of this process


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 29, 2020, 06:12:24 AM
The reward will be 0.009 btc for every person. I cannot pay in advance (or half) because of persons who could exit without doing their job.

PRELIMINARY FORM

Buyer user name: espercrypt
Seller user name: kelozar

Buyer comb address: 57791311603362245DF3BF9458F65A1023B0EEF58C81CAF98F4B767A57026F51
Seller comb address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7

Buyer crypto currency+amount: 1 NANO
Seller crypto currency+amount: 1 COMB

Seller purchased currency type and address: NANO,  nano_1buf7xdgsskd4g94rkfut8xsri8u5fdjt4hz8kpuenb498c7ii6hgqr9gd4f


 PRELIMINARY FORM

Buyer user name: JaoBadjap
Seller user name: kelozar

Buyer comb address: ?
Seller comb address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7

Buyer crypto currency+amount: 0.0005 BTC
Seller crypto currency+amount: 1 COMB

Seller purchased currency type and address: BTC,  bc1qv9f5jd09rpxy3p8aw2d0mwzv7cxhw2pjy0e77s


 PRELIMINARY FORM

Buyer user name: Aveatrex
Seller user name: kelozar

Buyer comb address: ?
Seller comb address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7

Buyer crypto currency+amount: 0.0005 BTC
Seller crypto currency+amount: 1 COMB

Seller purchased currency type and address: BTC,  bc1qy66xcyhr59r48hm6xheduvnkf8zn0mfny0l0f0

 PRELIMINARY FORM

Buyer user name: BotchCamber
Seller user name: kelozar

Buyer comb address: ?
Seller comb address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7

Buyer crypto currency+amount: 0.0005 BTC
Seller crypto currency+amount: 1 COMB

Seller purchased currency type and address: BTC,  bc1qt6ay05zjzdd72hw44qpfcssvdtsvwe99h044wt


 


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Aveatrex on May 29, 2020, 10:57:24 AM

 PRELIMINARY FORM

Buyer user name: Aveatrex
Seller user name: kelozar

Buyer comb address: ?
Seller comb address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7

Buyer crypto currency+amount: 0.0005 BTC
Seller crypto currency+amount: 1 COMB

Seller purchased currency type and address: BTC,  bc1qy66xcyhr59r48hm6xheduvnkf8zn0mfny0l0f0


Here's my comb address: 9926EA7AEB8A5C3A4E0BE5696EB2BC129E80FB1E471394B4BFFD1E2737CFEA21

The reward will be 0.009 btc for every person. I cannot pay in advance (or half) because of persons who could exit without doing their job.

You can use a reputed escrow on the forum to hold the funds until we do our job look here:https://bitcointalk.org/index.php?topic=2439910.0 (https://bitcointalk.org/index.php?topic=2439910.0)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 29, 2020, 06:18:14 PM
The event will begin in a few hours!!

I will be here continuously from this moment.

Important: once kelozar Pays to the contracts it will be impossible to add more
people to the first comb trade ever. Please provide your COMB address NOW to participate in
the event.

Buyers, please also provide your email address so we can later email you the proof that combs are in the contract.


The decider used will be: PPPNOHTJITSUPRVLGGTUJURTLGNGNIIJIKVPUULNMGTPNTTLRGJGOLQVPSHSRISS


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 29, 2020, 06:20:44 PM
hello everyone my node is fully synced and ready to go.
wanted to share the database integrity commits checker on my side.

Quote

If only some value is different, both users click difference next to that row.
Row 1. 0bafcf0639ddd8d9786349d376a2bfcb2429452bbce36c487fd59a3db96e32e5 99341 difference no data
Row 2. 1b1015f245e158e8de3ac67e65ad97b3fed886fb83cca6a30bda7fcca308adb6 98755 difference no data
Row 3. 2b6b3ac6c357dab555ce76a8fc7004ece8b65bea4373c74604a93d1b6622bf9e 99415 difference no data
Row 4. 369db081480383ad93d656e273e0e4b3cc8d23a680505672e8012d60ca090d5d 99637 difference no data
Row 5. 4918896cc811c6d3804ee2c8174e764fc42a5dda0b751f722a3cb2b5d3d1cafd 99673 difference no data
Row 6. 0b5b32bb0fbc91a8221715da38a3b4384dcaabe6cb6ebbce747fe38aaaf37f48 99624 difference no data
Row 7. 6a65dac8e5d8669cf69494cd10a0b7d920f33b5f67b6fd84e09301bfeb310661 99521 difference no data
Row 8. 7d50ca92461079b331d07cc463594fcecab4158b645e2b2871c6cd18b058516a 99183 difference no data
Row 9. 0d568e2f1e3d556aae10c9886992ef84160af97f4fc85014d2eea3b11bf58ad8 99670 difference no data
Row 10. 0bbfaf8b4e674e590b697691ba719fad516b9ce8234932ea68159f22f843bd50 100020 difference no data
Row 11. 05102abf6390fb0964f4d1339144e78232589af43688d829db3564c32513edb6 100108 difference no data
Row 12. 0347614142727ae744cdb6f9cdf943e9ff57d796276d89e4cad4d2baebe91da0 99118 difference no data
Row 13. cd70f1138c408203a90cd20e7c1e5a0baaa297e8228c6b2425165e3d11a2648c 99961 difference no data
Row 14. 01863534125044617eb68d87ec26887ce59c89f3e1ad9b755f2e61913ace08dd 99822 difference no data
Row 15. ec54116cad6231b5d2477bcb163ff08662959523c7e5f6c02f26de1b5983f10b 99219 difference no data
Row 16. 08c3c407bafbac77438739a3ac631c7852395f11ccd3b2f6cdc60ab46e853fa9 99140 difference no data

Additional information: Locator is b00631808



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 29, 2020, 06:46:27 PM

everyone - DO NOT PAY YET.

Purpose: to let other users to validate that the contract addresses are calculated correctly


Decider: PPPNOHTJITSUPRVLGGTUJURTLGNGNIIJIKVPUULNMGTPNTTLRGJGOLQVPSHSRISS


CONTRACT 1 - Comb trade contract - espercrypt - kelozar

1 NANO to be sent to nano_1buf7xdgsskd4g94rkfut8xsri8u5fdjt4hz8kpuenb498c7ii6hgqr9gd4f

Trade bit mask: 1
Forward COMB address: 57791311603362245DF3BF9458F65A1023B0EEF58C81CAF98F4B767A57026F51
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 7f61e315443c142bbf19a67a98ff76ec74f49c846a041ce0d86438b799751086
Address: 3C0D477D0E3F4994D7EFD00072E5360019B3467B2B87141ABC07856D748EBE2A

CONTRACT 2 - Comb trade contract - Aveatrex - kelozar

0.0005 BTC to be sent to bc1qy66xcyhr59r48hm6xheduvnkf8zn0mfny0l0f0

Trade bit mask: 2
Forward COMB address: 9926EA7AEB8A5C3A4E0BE5696EB2BC129E80FB1E471394B4BFFD1E2737CFEA21
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 2287276bad35bc7c881ef3f0bb0fe94c6cd976572186871fef1eb28df688e1af
Address: C8DE1F40036DEB9A0AB0B54C42DD049B208A7DBA63525421D7EAB48E474DED1A


No other users provided the information by now.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: espercrypt on May 29, 2020, 09:19:24 PM
updated contract address for the nano/haircomb trade:

2D599B8D2B0FE8644D9A71D32B12099A67CD7125600924ECAF819D7DD528249C bc1qexcmukut74fgaspld8wvzwq2ndc8cg3c5w7e6cremgwjh6xprkaqah92y6

will be checking in periodically as to when I am supposed to send, ty


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 29, 2020, 09:23:36 PM
updated contract address for the nano/haircomb trade:

2D599B8D2B0FE8644D9A71D32B12099A67CD7125600924ECAF819D7DD528249C bc1qexcmukut74fgaspld8wvzwq2ndc8cg3c5w7e6cremgwjh6xprkaqah92y6

will be checking in periodically as to when I am supposed to send, ty

Okay I will try to recalculate the contract address.

CONTRACT 1 - Comb trade contract - espercrypt - kelozar

1 NANO to be sent to nano_1buf7xdgsskd4g94rkfut8xsri8u5fdjt4hz8kpuenb498c7ii6hgqr9gd4f

Trade bit mask: 1
Forward COMB address: 2D599B8D2B0FE8644D9A71D32B12099A67CD7125600924ECAF819D7DD528249C
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 162f596697a97225936e3ae8e705b9cf143139ec53083ca942ebb6d64cb1f512
Address: 9115E7D6A2205FC959568072965DAD4CC525372B2AF30093B19F5040367BB9ED


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 29, 2020, 09:44:51 PM
CONTRACT 1 - Comb trade contract - espercrypt - kelozar

1 NANO to be sent to nano_1buf7xdgsskd4g94rkfut8xsri8u5fdjt4hz8kpuenb498c7ii6hgqr9gd4f

Trade bit mask: 1
Forward COMB address: 2D599B8D2B0FE8644D9A71D32B12099A67CD7125600924ECAF819D7DD528249C
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 162f596697a97225936e3ae8e705b9cf143139ec53083ca942ebb6d64cb1f512
Address: 9115E7D6A2205FC959568072965DAD4CC525372B2AF30093B19F5040367BB9ED

CONTRACT 2 - Comb trade contract - Aveatrex - kelozar

0.0005 BTC to be sent to bc1qy66xcyhr59r48hm6xheduvnkf8zn0mfny0l0f0

Trade bit mask: 2
Forward COMB address: 9926EA7AEB8A5C3A4E0BE5696EB2BC129E80FB1E471394B4BFFD1E2737CFEA21
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 2287276bad35bc7c881ef3f0bb0fe94c6cd976572186871fef1eb28df688e1af
Address: C8DE1F40036DEB9A0AB0B54C42DD049B208A7DBA63525421D7EAB48E474DED1A


This is finale correct?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 29, 2020, 10:01:07 PM

This is finale correct?

you can try send 1 comb to contract 2.

contract 1 is bad, you will need to provide new nano address It will be listed as contract 3.

hope that helps


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 29, 2020, 10:06:00 PM
UPDATE ON NANO CONTRACT!
DO NOT SEND NANO TO
Quote
nano_1buf7xdgsskd4g94rkfut8xsri8u5fdjt4hz8kpuenb498c7ii6hgqr9gd4f

Unfortunately I have rushed, and broadcasted to the original UN-REVISED nano contract 1

We will go with original plan, Natasha will judge nano as NOT DELIVERED, and the comb will be returned to my rollback address.

The new contract 9115E7D6A2205FC959568072965DAD4CC525372B2AF30093B19F5040367BB9ED
Is now INCORRECT!
I will NOT fund this contract because we will need to make new with a new NANO address of mine.

I have created a NEW nano address, Natasha will create a NEW contract.
Quote
nano_3bpa4t77kapqrgysm58egyh8t7ep8dsc88orqw4j7te6khpcqkp6rzb8c7zc

Great we can test the rollback feature as well!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 29, 2020, 10:16:54 PM

This is finale correct?

you can try send 1 comb to contract 2.

contract 1 is bad, you will need to provide new nano address It will be listed as contract 3.

hope that helps

Yes!
Broadcasted tx to fund contract 2
Will update when it is confirmed on chain.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 29, 2020, 10:17:20 PM
Hello espercrypt, If you want the honor the change of the comb address on the last minute, please DO NOT PAY to address of:

nano_1buf7xdgsskd4g94rkfut8xsri8u5fdjt4hz8kpuenb498c7ii6hgqr9gd4f

According to my calculation, we can do another contract. Important this one will use trade bit mask 4.


important: espercrypt do not pay nano yet. we are not yet in phase 2.


CONTRACT 3 - Comb trade contract - espercrypt - kelozar

1 NANO to be sent to nano_3bpa4t77kapqrgysm58egyh8t7ep8dsc88orqw4j7te6khpcqkp6rzb8c7zc

Trade bit mask: 4
Forward COMB address: 2D599B8D2B0FE8644D9A71D32B12099A67CD7125600924ECAF819D7DD528249C
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 3179dac8801e51172ca8084868d605cb460fd276e73941c790b5e23d381e9bac
Address: 99EF298E41C359C70E38AE7388D8DC11423587E0EC60AA993D927871E0CC50F3




CONTRACT 8 - Comb trade contract - BotchCamber - kelozar

0.0005 BTC to be sent to bc1qt6ay05zjzdd72hw44qpfcssvdtsvwe99h044wt

Trade bit mask: 8
Forward COMB address: 5DA32D5B06B5F2CAD971B6EFE5123F1FE282BED532B7D1573DADCCA117747635
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 3859e87d63876d0818c27820135fe7907c9ecbfe5c7ea32a233cc25c798f4677
Address: 4A681CAF9ED9ABB3958FF2731F31941B11CF9236A1A12B28593D40579AB4C205


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 30, 2020, 01:21:57 AM
update
PLEASE DO NOT SEND PAYMENTS YET!

all contracts on my end have been funded, broadcasted and included in the blockchain.

Quote
~
CONTRACT 2 - Comb trade contract - Aveatrex - kelozar

0.0005 BTC to be sent to bc1qy66xcyhr59r48hm6xheduvnkf8zn0mfny0l0f0

Trade bit mask: 2
Forward COMB address: 9926EA7AEB8A5C3A4E0BE5696EB2BC129E80FB1E471394B4BFFD1E2737CFEA21
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 2287276bad35bc7c881ef3f0bb0fe94c6cd976572186871fef1eb28df688e1af
Address: C8DE1F40036DEB9A0AB0B54C42DD049B208A7DBA63525421D7EAB48E474DED1A

~
CONTRACT 3 - Comb trade contract - espercrypt - kelozar

1 NANO to be sent to nano_3bpa4t77kapqrgysm58egyh8t7ep8dsc88orqw4j7te6khpcqkp6rzb8c7zc

Trade bit mask: 4
Forward COMB address: 2D599B8D2B0FE8644D9A71D32B12099A67CD7125600924ECAF819D7DD528249C
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 3179dac8801e51172ca8084868d605cb460fd276e73941c790b5e23d381e9bac
Address: 99EF298E41C359C70E38AE7388D8DC11423587E0EC60AA993D927871E0CC50F3

~
CONTRACT 8 - Comb trade contract - BotchCamber - kelozar

0.0005 BTC to be sent to bc1qt6ay05zjzdd72hw44qpfcssvdtsvwe99h044wt

Trade bit mask: 8
Forward COMB address: 5DA32D5B06B5F2CAD971B6EFE5123F1FE282BED532B7D1573DADCCA117747635
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 3859e87d63876d0818c27820135fe7907c9ecbfe5c7ea32a233cc25c798f4677
Address: 4A681CAF9ED9ABB3958FF2731F31941B11CF9236A1A12B28593D40579AB4C205

we don't need to worry about contract 1, as it seems i did not process the payment correctly. i can see the comb amount in full in my change address
(i am learning and testing this just like everyone here)

next we will wait for natasha

PLEASE DO NOT SEND PAYMENTS YET!



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Aveatrex on May 30, 2020, 01:32:52 AM

Buyers, please also provide your email address so we can later email you the proof that combs are in the contract.



Just send me a message here on bitcointalk.



Waiting for natasha to launch phase 2 so I can send payment to kelozar.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 30, 2020, 05:32:49 AM
Hello I've just verified that there is

1 COMB in contract C8DE1F40036DEB9A0AB0B54C42DD049B208A7DBA63525421D7EAB48E474DED1A
1 COMB in contract 99EF298E41C359C70E38AE7388D8DC11423587E0EC60AA993D927871E0CC50F3


I've just sent the proofs to users Aveatrex, espercrypt. You can save the proof into a txt file. You can then import
the text file into the fully synced haircomb core wallet.

Next, you open the UTXO SET, and scroll all the way down to the end. In the end you can see rows about the
contracts being funded. I've just checked it.



This means that that phase 2 is now open. Please transact the agreed trade amounts of NANO and BTC to kelozar.


BotchCamber: we are waiting for kelozar' s proof. But you paid prematurely so you will be treated specially.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Aveatrex on May 30, 2020, 06:22:16 AM
Transaction sent to bc1qy66xcyhr59r48hm6xheduvnkf8zn0mfny0l0f0.

Tx:https://www.blockchain.com/fr/btc/tx/0291ab3566981e78de509708509469046e9449fe1e3db351a64cca77503f5452 (https://www.blockchain.com/fr/btc/tx/0291ab3566981e78de509708509469046e9449fe1e3db351a64cca77503f5452)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 30, 2020, 10:43:24 AM
There is 1 COMB in contract 4A681CAF9ED9ABB3958FF2731F31941B11CF9236A1A12B28593D40579AB4C205

I have the coin history for this contract and I've verified it and it is real.

To BotchCamber: I will send you the history right now. Don't pay btc again since you alerady paid.

To espercrypt: please make the 1 NANO payment now to the right address, we are waiting for it. If unsure, please ask.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: espercrypt on May 30, 2020, 09:02:37 PM
1 Nano has been sent to nano_3bpa4t77kapqrgysm58egyh8t7ep8dsc88orqw4j7te6khpcqkp6rzb8c7zc

I confirm I received an email which stated 1 COMB is in my contact proof.

Thank you for letting me participate.  I have a question about the COMB protocol, what is the end goal of this project?  Is it to allow decentralized trades and potential DEX's to be built that are not limited to ERC-20 tokens?  If so, I can see this project playing a very important role in decentralizing the crypto space as a whole.  Happy to be a part of the project either way.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 30, 2020, 10:30:04 PM
hi everyone
i confirm i receive payment on all contracts
thank you for allowing me to help participate in the first nano contract on bitcoin blockchain!

~
CONTRACT 2 - Comb trade contract - Aveatrex - kelozar

0.0005 BTC to be sent to bc1qy66xcyhr59r48hm6xheduvnkf8zn0mfny0l0f0

Trade bit mask: 2
Forward COMB address: 9926EA7AEB8A5C3A4E0BE5696EB2BC129E80FB1E471394B4BFFD1E2737CFEA21
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 2287276bad35bc7c881ef3f0bb0fe94c6cd976572186871fef1eb28df688e1af
Address: C8DE1F40036DEB9A0AB0B54C42DD049B208A7DBA63525421D7EAB48E474DED1A

~
CONTRACT 3 - Comb trade contract - espercrypt - kelozar

1 NANO to be sent to nano_3bpa4t77kapqrgysm58egyh8t7ep8dsc88orqw4j7te6khpcqkp6rzb8c7zc

Trade bit mask: 4
Forward COMB address: 2D599B8D2B0FE8644D9A71D32B12099A67CD7125600924ECAF819D7DD528249C
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 3179dac8801e51172ca8084868d605cb460fd276e73941c790b5e23d381e9bac
Address: 99EF298E41C359C70E38AE7388D8DC11423587E0EC60AA993D927871E0CC50F3

~
CONTRACT 8 - Comb trade contract - BotchCamber - kelozar

0.0005 BTC to be sent to bc1qt6ay05zjzdd72hw44qpfcssvdtsvwe99h044wt

Trade bit mask: 8
Forward COMB address: 5DA32D5B06B5F2CAD971B6EFE5123F1FE282BED532B7D1573DADCCA117747635
Rollback COMB address: 5A986616B8F2F70BF575A58AEB4B35D5F4911FCF98B98A27D1B47A77045A05E7
Merkle root: 3859e87d63876d0818c27820135fe7907c9ecbfe5c7ea32a233cc25c798f4677
Address: 4A681CAF9ED9ABB3958FF2731F31941B11CF9236A1A12B28593D40579AB4C205


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Aveatrex on May 31, 2020, 01:14:20 AM
So next step is natasha signing the contract with the decider key so the funded comb get released right?

By the way here's my BTC address for the reward: 3NCS6HmYkwJmR36vCu4rnCzAsy8qSDHMPC


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on May 31, 2020, 07:28:25 AM
Hello the decider has 1 confirmation.


Important the wallet contains a problem - when decider person tries to decide the contract the wallet prints
wrong bitcoin addresses. I spotted the problem instantly and did not pay to the wrong addresses in the first trade.
I paid to the right addresses.

Until then don't use the deciders purse page of the wallet in the version 0.3.2.


the problem is fixed in my version and will be fixed in the next version.


Post your reward addresses.

EDIT:

success! It feels like I've built a lunar orbiter in my backyard. It flew.

Signed number: 14
Long decider: GGGUOGPNQLHOGSLHGNOVIIIKVVUKGKUGHITPIVROPRULGTPQTVIKPTLIHVINLLJNSNJLHHIPMPMSIGT QLKVVONMMMLHSPQGTKLOOJJGGIJVQKINVTVVSTIUOPVIMTJIVPRPN

withdraw your comb from the contracts now or anytime you want.
It's done


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Aveatrex on May 31, 2020, 09:57:35 AM
Successfully withdrawn 1 Comb. Mission accomplished!

Post your reward addresses.
3NCS6HmYkwJmR36vCu4rnCzAsy8qSDHMPC


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: JaoBadjap on May 31, 2020, 11:06:43 AM
I think I withdraw from the event.
my wallet is still out of sync
and I guess it will be around a couple of days until it finally syncs


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on May 31, 2020, 11:23:32 AM
Address for reward
bc1q0d2d7g3gm3pxk7grtg5faqzc5upsz5ls2l6jhy



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: espercrypt on June 01, 2020, 11:24:48 PM
WARNING

https://bitcointalk.org/index.php?topic=5252297.0

glad I didn't download this shit, christ


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: BlackR4ptor on June 02, 2020, 08:27:35 PM
Interesting project.

How do I claim COMB? What´s the price and market cap? Is it in any exchange yet?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on June 03, 2020, 05:58:11 PM
To claim combs you need to generate your key and then view it's stealth
addresses - you will see your long bitcoin mine addresses.

Simply tip 546 sats to successive mine addresses every time a block is mined.

Don't forget to fully save your wallet from the main page to a file.


To see your coins you need to sync using the modified bitcoin core.



About exchanges - we aren't listed anywhere yet, but it is not a huge problem
because the coin offers a comb trade facility, basically enabling something
similar to a decentralized exchange or an escrowing. The swaps are atomic as
long as the "decider person" is honest and even a dishonest "decider person" cannot
do much harm.

Comb trade can also be used for fair peer to peer bets (gambling)






This is a privacy coin.




My educated guess. Price is currently known to be anywhere between $1 and $10.
Market cap is on the order of $5000- $50000. There is about 5000 spendable coins.

If you see a higher figure about the spendable coins, this is because coins
before the first block could also be counted but they are provably burned.
(All the way back to the segwit start)
Another fact is that many Bitcoin users pay to the long addresses and unknowingly
burn newly generated COMBs, these COMBs are also provably lost as the
cryptography of Bitcoin used to generate ordinary bitcoin keys is very different.

These random users are forming the price floor.


There is no premine. (0 COMB is premined, I've claimed just like an ordinary user would)



The coin runs on the Bitcoin chain and provides roughly same degree of finality
of transactions.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: CryptoFamBoy on June 03, 2020, 07:58:13 PM
Is there any possibility to buy this coin without setting up any special node? (I am ready to use some alpha-wallet though)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 04, 2020, 01:53:11 PM
You can generate Comb address using wallet. But to be able to prove you received the comb, you would need a full node fully synced.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: CryptoFamBoy on June 04, 2020, 07:17:34 PM
Well, I think there is definitely a possibillity to check the receiving of coins through some trusted full node owner. I would like to buy some coins after (and if) the situation in the https://bitcointalk.org/index.php?topic=5252297.0 is cleared.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on June 05, 2020, 08:08:43 AM
Hello I've just released combfullui 0.3.3 open source on github.

Please make sure you have a copy.

I'm officially stepping down from the position of the lead developer.
My part of project seems complete and I will be happy to help
or watch others develop their own improved versions.


Thanks for your attention.

7cb6b988a4431db586979e3714751dc8ad934c89276955dd8a5157ed607529cd  PUBLIC_DOMAIN
49d5f5ec5b37a7ae9512148237c03068ee8f5d6c282c0cd0bb8f3017ebc3e0ed  anonminize.go
2808b6f4a6cff6362dceae04588c6eb194728f1d5184cce210fb44f5f63f0a2b  balance.go
6e37b41734eadd032a533a98a8f1c198f1d34f9afe136b278aab4c76cc4e9827  basic_contract.go
3dbe40b7860ea7d4caa396b5221ea636aaf08e8513521bbc04a0a88ae3e208aa  coinbase.go
0885da61b260e8b6dee54d73cde806c5f4007588a6bad082500f4c5085f31850  commitfile.go
517646c621a628d30e9cac103259fa6a47b145c92df579cbdbf1858bfb8f372a  commitment.go
53f119c27580daf40cd5c916d9fae3c037e58a9dda5f0a017e5ada268fb9461c  corruption_bisect.go
38d14c41508ca33975a63274950bdb5846a056b52fd53c4701db516a872d822c  cutwhere.go
53b261ccb57928dc5ba02fc0415a9a1769fa6ae608fe6a8e336e73f5fac0dd31  deciders_purse.go
e103b4f22d4a7bb539c81978ad9bb80d1ec47e0041e54902e9c40745ee38849e  deployment.go
7257186ac82b85e4cb58b8b17cb75de14028cadc3860741527d0cc6bff618dcb  dummyhttpwriter.go
b27f6aee1c1fb97a0b5b5a5cc942fba37656ba40f842fdb20aad51ca7def0dc0  export.go
cddc3bd767ef47ea828abaecd5a3d4622bf640db17e03de583648e6566b08a27  hexutil.go
5097b8d29f4ae30040d90ccafe9c759ba5385b0f006e7b979c30d6375f78e578  import.go
e4d2e000da8368a60a48ec7649f44ca94bb69bdbd8101efdc9be3aeb30c6821e  loopdetect.go
e2fa75c079b0b65bae7d3b23991da53c0f96afa98a9b28e4342146d2e1b70c1c  main.go
4647d5f90ae0b32755c96b33775176cc0c745bf8d27e704a4a7d5cebd9ff7826  mainpage.go
bd5ec8ab0815c9fae1b614e610d4f815ff56d1f591f1084a64f3793ae51fdcaa  merkle.go
68994237974102ea653537f923356decf6865be8c8a9cdc5d360cd3310ee8f4e  mine.go
19bb0e30bcf9488135f5134f33e0f18285fbf7d51ce702a4f3f19e35727d8a84  resetgraph.go
0b95c2afc533395db38fa8028d854e1b0f94508717888fee76eb4c138ef18f69  segmentmerkle.go
8120719d4fb1059ad657df54ad6ff40f9a247f8d136d2305f2072e81a17c4f85  segmentscoinbase.go
7b70655a65d0d3021447123f0f6e70f1fd07b13b4c41461ca9e86be0dbced4f3  segmentstack.go
53d677c9d05c61c8b87c026dd08bbda7b038eeae44d6dc5d3a0d1fe51db0375e  segmenttx.go
bd40a2100146b553c40c649b9461eed4fbd2e02297fef64e20212e673970fe61  sign.go
1c50c9ba0025569c57d2164612d71f7a24a07cb32b2d0897511ff1937015419e  stackbuilder.go
28a9c0198f47a9272f1580361601ab16b911ba4d5c961b680685327e34cbe122  stack.go
f33dbfe4a588366bd93108b4f31dde50ff456f882c74be2334fdff2b98651cf7  stackgui.go
21209fbce1077b646c5e18a4366f3a1cba822a480e6c416ccf8a7c899e7bacad  stealthgui.go
a23cde6642f7e622d7d88cdabbbc076e99e820b0d0f3f9d45f044b91a8c38c9d  txlegs.go
543b579c8ad8736a664a58a67ef88802e006290cefd841611bd53d34ea271e73  txrecv.go
4f1785c385e9301553497bb4158e33c560cc3b1305993a6990e9289b2ee86e59  used_key.go
732f71d1138e749a35bed6b9f1121c1c1d2698372161bf0cfc7ce9ba1896793f  utxo.go
ddf07711f28c1b164c495973f29d5227139ed89ef135bace47faf794bca9c482  utxotag.go
6a56339fc3aeee574a51bf363d3188270df36f7b153f71d29a9853c74e366b4c  wallet.go


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 05, 2020, 03:31:22 PM
Hello I've just released combfullui 0.3.3 open source on github.

Please make sure you have a copy.

I'm officially stepping down from the position of the lead developer.
My part of project seems complete and I will be happy to help
or watch others develop their own improved versions.


Thanks for your attention.

7cb6b988a4431db586979e3714751dc8ad934c89276955dd8a5157ed607529cd  PUBLIC_DOMAIN
49d5f5ec5b37a7ae9512148237c03068ee8f5d6c282c0cd0bb8f3017ebc3e0ed  anonminize.go
2808b6f4a6cff6362dceae04588c6eb194728f1d5184cce210fb44f5f63f0a2b  balance.go
6e37b41734eadd032a533a98a8f1c198f1d34f9afe136b278aab4c76cc4e9827  basic_contract.go
3dbe40b7860ea7d4caa396b5221ea636aaf08e8513521bbc04a0a88ae3e208aa  coinbase.go
0885da61b260e8b6dee54d73cde806c5f4007588a6bad082500f4c5085f31850  commitfile.go
517646c621a628d30e9cac103259fa6a47b145c92df579cbdbf1858bfb8f372a  commitment.go
53f119c27580daf40cd5c916d9fae3c037e58a9dda5f0a017e5ada268fb9461c  corruption_bisect.go
38d14c41508ca33975a63274950bdb5846a056b52fd53c4701db516a872d822c  cutwhere.go
53b261ccb57928dc5ba02fc0415a9a1769fa6ae608fe6a8e336e73f5fac0dd31  deciders_purse.go
e103b4f22d4a7bb539c81978ad9bb80d1ec47e0041e54902e9c40745ee38849e  deployment.go
7257186ac82b85e4cb58b8b17cb75de14028cadc3860741527d0cc6bff618dcb  dummyhttpwriter.go
b27f6aee1c1fb97a0b5b5a5cc942fba37656ba40f842fdb20aad51ca7def0dc0  export.go
cddc3bd767ef47ea828abaecd5a3d4622bf640db17e03de583648e6566b08a27  hexutil.go
5097b8d29f4ae30040d90ccafe9c759ba5385b0f006e7b979c30d6375f78e578  import.go
e4d2e000da8368a60a48ec7649f44ca94bb69bdbd8101efdc9be3aeb30c6821e  loopdetect.go
e2fa75c079b0b65bae7d3b23991da53c0f96afa98a9b28e4342146d2e1b70c1c  main.go
4647d5f90ae0b32755c96b33775176cc0c745bf8d27e704a4a7d5cebd9ff7826  mainpage.go
bd5ec8ab0815c9fae1b614e610d4f815ff56d1f591f1084a64f3793ae51fdcaa  merkle.go
68994237974102ea653537f923356decf6865be8c8a9cdc5d360cd3310ee8f4e  mine.go
19bb0e30bcf9488135f5134f33e0f18285fbf7d51ce702a4f3f19e35727d8a84  resetgraph.go
0b95c2afc533395db38fa8028d854e1b0f94508717888fee76eb4c138ef18f69  segmentmerkle.go
8120719d4fb1059ad657df54ad6ff40f9a247f8d136d2305f2072e81a17c4f85  segmentscoinbase.go
7b70655a65d0d3021447123f0f6e70f1fd07b13b4c41461ca9e86be0dbced4f3  segmentstack.go
53d677c9d05c61c8b87c026dd08bbda7b038eeae44d6dc5d3a0d1fe51db0375e  segmenttx.go
bd40a2100146b553c40c649b9461eed4fbd2e02297fef64e20212e673970fe61  sign.go
1c50c9ba0025569c57d2164612d71f7a24a07cb32b2d0897511ff1937015419e  stackbuilder.go
28a9c0198f47a9272f1580361601ab16b911ba4d5c961b680685327e34cbe122  stack.go
f33dbfe4a588366bd93108b4f31dde50ff456f882c74be2334fdff2b98651cf7  stackgui.go
21209fbce1077b646c5e18a4366f3a1cba822a480e6c416ccf8a7c899e7bacad  stealthgui.go
a23cde6642f7e622d7d88cdabbbc076e99e820b0d0f3f9d45f044b91a8c38c9d  txlegs.go
543b579c8ad8736a664a58a67ef88802e006290cefd841611bd53d34ea271e73  txrecv.go
4f1785c385e9301553497bb4158e33c560cc3b1305993a6990e9289b2ee86e59  used_key.go
732f71d1138e749a35bed6b9f1121c1c1d2698372161bf0cfc7ce9ba1896793f  utxo.go
ddf07711f28c1b164c495973f29d5227139ed89ef135bace47faf794bca9c482  utxotag.go
6a56339fc3aeee574a51bf363d3188270df36f7b153f71d29a9853c74e366b4c  wallet.go


can you upload compiled version as well like before? thanks


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 06, 2020, 12:04:30 PM
i would like to let everyone know that might not already
if you are looking to claim some combs and want to use less amount of satoshi
right now is one of the most optimal times
hashrate is increasing, that means blocks are found on average faster then 10mins
this leads to much lower fees on average
here is good site for hashrate
https://diff.cryptothis.com/
and these sites are good for mempool information
https://jochen-hoenicke.de/queue/#0,1w
https://mempool.space/

if anyone would like i can sell them some comb and claim some more to replenish, with a small fee for my time and fee to pay for the transfer (fund 21 tx's onchain)
its very possible to claim for an average of about 50k-100k satoshi per comb at the moment.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: CryptoFamBoy on June 06, 2020, 12:15:09 PM
@kelozar Wasn't it about 500 satoshi to claim a COMB? Why did it increase to 50000, which is 100 times more? Almost 5$ is pretty expensive for a new, unknown coin. 

I also would like the natasha (if it's her/his real name) to elaborate on the fake photo problem and why is she leaving the dev position now, at the stage where the project is not even close to the 1.0.0 stage?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 06, 2020, 12:36:39 PM
@kelozar Wasn't it about 500 satoshi to claim a COMB? Why did it increase to 50000, which is 100 times more? Almost 5$ is pretty expensive for a new, unknown coin. 

I also would like the natasha (if it's her/his real name) to elaborate on the fake photo problem and why is she leaving the dev position now, at the stage where the project is not even close to the 1.0.0 stage?

it is 546 satoshi to the mining address. but to successfully claim, you need to be the first new unseen p2wsh transaction in the block. (only 1 successful claim per btc block)
currently most miners organize the transactions with highest fee first. not all miners and not always, but more times then not aside from exceptions.
because alot of exchanges have some type of outputs that almost always have a new p2wsh tx in their batches for some reason. this means you need to pay higher fee then they do in order to be the first.
when the blocks are found longer then 10mins, there is a competition and other exchanges pay higher for some reason.
when the blocks are faster then 10 mins. it is possible to pay less (sometimes) and still be the first unseen p2wsh output, but not always.

the 50k is due to several things, first its the fee used to be the first p2wsh, 2nd is because sometimes you pay the fee but the miner included another transaction before yours in the block. also sometimes before the block is found you see higher fee being broadcasted so you are forced to either up your fee (and hope they dont use the previous broadcast), or up your fee and still not be the first for whatever other reason.
aside from this in order to transfer comb from 1 address to another, you need to fund 21 of those 546 transactions, which also cost fees.
also i am doing this all manually, so i am manually monitoring the mempool and this is time intensive as well as cost satoshi which doesnt even guarantee a claim.

dont get me wrong, there is times you can claim for 15k satoshi successfully, but there is times it could cost 100k+ to claim successfully, there is ways to try to lower your avg but due to things outside ones control you cant really be guaranteed anytime (atleast from what i have learned so far)

as far as the real name and photo
natasha otomoski is an anagram for satoshi nakamoto, (re-arrange the letters)
the photo is obviously fake but i assumed everyone knew that? if the creator is using an anagram of satoshi, and said they are using tor, they obviously care about their privacy.
so why would they put a real photo? also the photo is like a stock photo found online. its not even hard to find it. it was obvious to anyone RIGHT AWAY that this is not a real name nor real photo.

take it as you will, im not endorsing this project or vouching for the dev or the project. i am just experimenting here like everyone else.
hope this explains your questions, if you have any others dont hesitate to ask, i will help however i can

thats my 2combs.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: BlackR4ptor on June 10, 2020, 03:09:59 AM
@kelozar Wasn't it about 500 satoshi to claim a COMB? Why did it increase to 50000, which is 100 times more? Almost 5$ is pretty expensive for a new, unknown coin. 

I also would like the natasha (if it's her/his real name) to elaborate on the fake photo problem and why is she leaving the dev position now, at the stage where the project is not even close to the 1.0.0 stage?

Were you successful in claiming COMB without having to spend more than 546 satoshi? I´m willing to do all the install and sync process, but I agree $5 is too expensive for a unknown coin.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on June 10, 2020, 12:46:55 PM
@kelozar Wasn't it about 500 satoshi to claim a COMB? Why did it increase to 50000, which is 100 times more? Almost 5$ is pretty expensive for a new, unknown coin.  

I also would like the natasha (if it's her/his real name) to elaborate on the fake photo problem and why is she leaving the dev position now, at the stage where the project is not even close to the 1.0.0 stage?

Were you successful in claiming COMB without having to spend more than 546 satoshi? I´m willing to do all the install and sync process, but I agree $5 is too expensive for a unknown coin.

This has been explained plenty of times, but let's try again.

To make a successful claim, you need to tip at least 546 sats (no more are needed) to a new stealth address from your COMB wallet and that transaction must be the first one mined on the block with an unseen P2WSH output address.

If you are doing transactions with the only intent of claiming COMB the price is far from 546 sats since the fee of the transaction must be included on the price of the token.
The fee can range widely from the minimum fee possible for a transaction to be completed or as high as you want it to be to ensure the claim.

As kelozar says, currently the average COMB claiming transaction is paying ~50k in fees.
Usually, the longer a block is the bigger is the fee of the claiming transaction and the opposite happens on shorter blocks. But that's not a rule.

I think a fair price per COMB should address:
  546 sats tipped to a stealth address
+FEE accounting for the sats paid to be the claimer tx
+TIP since not all the claim attempts are successful

However, you could claim way cheaper COMBs. If you were making a regular BTC transaction you could include a tip to a stealth address so you have an 'almost free' chance to claim.

To make a COMB payment you need to fund 21 addresses with 546 that should also be included on the total transaction, not per COMB.

As for me, when claiming I usually waited 8-10 minutes of block time and then sent a transaction with a small increase in fees over the current claimer, as long as it wasn't higher than 60k sats. Most of the claims were made between 40k and 50k. Very few were achieved with <30k

Please, someone, correct me if I am wrong.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on June 10, 2020, 05:32:35 PM
Please note that my 546 sats recommendation is not a hard rule. In fact
amounts as low as 330 sats per output might be practical for ordinary users.


546 sats is only quoted because many sites quote it and it appears to be working
fine and the transactions did not have problem getting relayed or anything else.


It all depends on how dust is defined by the Bitcoin client and I have no
intention whatsoever to influence those rules. Please respect the Bitcoin rules.


Another concern about the 546/330 amount is that I am strongly convinced that
every Haircomb user needs to use the same amount for privacy reasons, to blend
into the crowd of other Haircomb users.


This means the migration to 330 sat claiming amount should be flag-day, if done.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on June 12, 2020, 09:09:22 AM
To compile haircomb core from source please do the following:


Download and install google go language from https://golang.org (https://golang.org)

Download and install git bash https://git-scm.com/downloads (https://git-scm.com/downloads)


Next, open git bash a black command window will appear.

Use these commands

Code:

cd Documents

git clone https://github.com/natasha-otomoski/combfullui.git

cd combfullui

go get github.com/gorilla/mux

go get github.com/sipa/bech32/ref/go/src/bech32

go build

start .


After this there should be folder combfullui in your Documents with combfullui.exe appeared inside

Please replace your old combfullui.exe with this new one.




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 12, 2020, 09:47:05 PM
when i try
go get github.com/gorilla/mux
it says
bash: go: command not found


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on June 13, 2020, 07:38:13 AM
Open control panel
Open System and Security
Open System
Open Advanced system settings
On the left open Advanced tab
Open Environmental Variables
Select System variables Path
Click Edit
Add new row "C:\Go\bin" (this must be the folder where go.exe was installed)


Close and open git bash again, run commands again without the git clone step that is already complete.


Code:
cd Documents

git clone https://github.com/natasha-otomoski/combfullui.git

Code:
cd combfullui

go get github.com/gorilla/mux

go get github.com/sipa/bech32/ref/go/src/bech32

go build

start .


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 13, 2020, 04:44:10 PM
followed the steps, interesting to note i already had C:\Go\bin in the variables.
so i gave it another try, and everything worked.

success, running  the new comb0.3.3

thanks for helping


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 15, 2020, 03:17:08 AM
I am proposing we switch to 330 satoshi claims and 330 satoshi fund for transaction.
This will be good reduction in cost to send comb.
If anyone objects please tell us why. Otherwise lets all agree to 330 satoshi. If in future miners and wallets default less we can switch again.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on June 15, 2020, 08:08:53 AM
I am proposing we switch to 330 satoshi claims and 330 satoshi fund for transaction.
This will be good reduction in cost to send comb.
If anyone objects please tell us why. Otherwise lets all agree to 330 satoshi. If in future miners and wallets default less we can switch again.
Yay, for my part


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: natasha-otomoski on June 16, 2020, 06:25:56 AM
ok we can do it starting from block 636363.


By the way I've been contacted by an undisclosed person who is willing to acquire
a 3 BTC worth of Haircomb token. I told the person to claim on the free market, but
out of interest, would anyone be willing to fill such an order?


The way I see it 3 BTC may well be worth more than the entire supply.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Fizbann on June 16, 2020, 09:14:13 AM
ok we can do it starting from block 636363.


By the way I've been contacted by an undisclosed person who is willing to acquire
a 3 BTC worth of Haircomb token. I told the person to claim on the free market, but
out of interest, would anyone be willing to fill such an order?


The way I see it 3 BTC may well be worth more than the entire supply.

I am willing to pool some of mine



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 16, 2020, 12:53:11 PM
ok we can do it starting from block 636363.


By the way I've been contacted by an undisclosed person who is willing to acquire
a 3 BTC worth of Haircomb token. I told the person to claim on the free market, but
out of interest, would anyone be willing to fill such an order?


The way I see it 3 BTC may well be worth more than the entire supply.

I will be willing to claim for them for a fee.
Maybe sell some of my comb and use the funds to claim back more
How much comb are they looking for with 3btc ?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on June 30, 2020, 12:28:29 AM
ok we can do it starting from block 636363.

we are passed block 636363
I will be using 330 sats for transferring of comb and for claiming of comb.

Also if anyone would like to buy some comb. I have claimed a decent amount and don't mind to help distribute at a cost of 50k satoshi each comb.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on September 15, 2020, 05:53:42 AM
Are you using info from modified core to see whats the highest paying new p2wsh output.
I have plenty claimed i can also sell if you would like offer.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on September 20, 2020, 03:30:04 PM
Dont think theres much demand or even interest in the project anymore. Seems kinda ded, dev hasnt worked on anything or replied to any dms since open source


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on October 17, 2020, 06:43:03 PM
Hello

There is a new tool to download commits.db file without modified bitcoin

use at your own risk

https://pastebin.com/5thcx9jn (https://pastebin.com/5thcx9jn)
https://paste-bin.xyz/paste.php?id=8448 (https://paste-bin.xyz/paste.php?id=8448)

It downloads directly from other bitcoin full nodes about 250 GB data, and the 95MB commits.db is created.

Yes this means about 250 GB of internet traffic is used, (it takes about 1-2 days) however there is no need to have large hard drive, 100MB free space is enough.

Biggest flaw is that the download cannot be currently resumed, so if you stop it then you get a short file with no ability to continue the download later.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on October 31, 2020, 08:28:54 PM
I get an ERR_SSL_PROTOCOL_ERROR when I try to connect to https://127.0.0.1:2121/

EDIT: Fixed it by going to chrome://net-internals/#hsts and deleting the localhost security policies.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 01, 2020, 04:43:04 AM
So I just got into blockchain stuff about a month ago. Maybe it's my ignorance talking, but this looks like the coolest thing that exists right now. I don't understand how more people aren't freaking out about this. Correct me if I'm wrong, but it seems like Haircomb has the potential to essentially hijack BTCs own chain and become the main usecase for it.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: desu2bdesu on November 01, 2020, 07:21:44 PM
tried out the wallet. now I'm having weird issues with my computer like random usb disconnects, lags while typing, app freezes... are you sure this thing doesn't have a virus in it?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 01, 2020, 08:44:25 PM
tried out the wallet. now I'm having weird issues with my computer like random usb disconnects, lags while typing, app freezes... are you sure this thing doesn't have a virus in it?

You can go through the code for yourself here: https://github.com/natasha-otomoski/combfullui

There's also a guide on how to compile it a few pages back in the thread.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: desu2bdesu on November 01, 2020, 09:03:20 PM
tried out the wallet. now I'm having weird issues with my computer like random usb disconnects, lags while typing, app freezes... are you sure this thing doesn't have a virus in it?

You can go through the code for yourself here: https://github.com/natasha-otomoski/combfullui

There's also a guide on how to compile it a few pages back in the thread.

github code doesn't matter, if it connects to the internet it can download virus code.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 01, 2020, 09:05:23 PM
tried out the wallet. now I'm having weird issues with my computer like random usb disconnects, lags while typing, app freezes... are you sure this thing doesn't have a virus in it?

You can go through the code for yourself here: https://github.com/natasha-otomoski/combfullui

There's also a guide on how to compile it a few pages back in the thread.

github code doesn't matter, if it connects to the internet it can download virus code.

It doesn't AFAIK.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 02, 2020, 01:40:25 AM
I still don't understand how the heck the haircomb transaction data is hosted within the bitcoin layer 1 data. If someone could explain that to me I'd appreciate it greatly.

EDIT: After doing some more reading I understand it better, however I'm confused about the wording in the whitepaper. I get that the transaction details are encoded into the segwit addresses of bitcoin transactions, you fund the generated segwit address with BTC to execute a transaction. The part I'm confused about is the wording or:


Quote
Liquidity stack is a triplet change address CH, output address OUT and output
amount (64bit). The liquidity stack address is simply SHA256(CH + OUT + out).

I'm assuming the change address is the a receiver's public key, and the output address is the sender's private key, correct? Otherwise wouldn't anybody be able to initiate transactions from another person's wallet just by knowing their public key? I only ask because the wording isn't exact in the paper, and I want to be sure I understand exactly what's happening.


I'm also having trouble understanding chaining liquidity stacks. From the whitepaper:

Quote
To chain liquidity stacks to form longer stack you use the child stack address
as the change address CH of the parent stack segment.

But if the child stack address needs the parent stack address to be generated, then that's just a recursive loop, isn't it? Both stacks need input and destination? What am I not getting here?


Maybe I'm just misunderstanding Liqudidity stacks and their roll in transfers. After doing more reading of the thread it seems i was mistaken in thinking they'd be used for direct transfers. If someone could walk me through the mechanisms of basic payment, I'd appreciate it.
EDIT:

I read through https://bitcointalk.org/index.php?topic=5195815.msg53053908#msg53053908 and got a better idea of where my stack confusion was. This has brought a different question to light however, and I'm confused as to where the 21 tx number is coming from when, in the past, people spoke about needed to send BTC to 21 addresses in order to run a haircomb transaction. This is the bit I'm stuck on, what the mechanism of funding a basic transaction is.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 03, 2020, 12:03:35 AM
I mostly answered my question reading the whitepaper again, but I still have something to clear up.

Quote
We have observed that signature is just 21 numbers. Suppose we want an anonymous
token. We take the hash commitment of each of these 21 numbers. It has to be
a different function than SHA256(x) because that would simply calculate the next
value in the hash chain. RIPEMD or SHA3 or whatever would work too, but, my
token uses for this SHA256(whitepaper + x) where + is concatenation.
This has the added benefit that every coin user implicitly signs-off the rules
of the token they are supposed to abide by (especially users who generate coins
will do this too, so that they know how many coins they just generated).

Commitments are then turned into P2WSH addresses and users "tip" to these
addresses to confirm the transaction. Transaction is just hash of two hashes:
source address and destination address. COMB Address is for example X (a pubkey),
or it can be some other type of address, like a liquidity stack or Merkle tree
segment[4].

I want to make sure my understanding is correct. The steps, as I read them, are as follows:

STAGE 1:
1. Take the first number of the signature of the sender's signature (n)
2. Hash n using SHA256(whitepaper + n)
3. Convert into a HostChain segwit address
4. Repeat for remaining digits

STAGE 2:
For each address generated in stage 1, find the hash of SHA256(source_address, destination_address), convert to segwit, and tip?

This seems incorrect. I'm confused by the following lines in the whitepaper:

Quote
Commitments are then turned into P2WSH addresses and users "tip" to these
addresses to confirm the transaction.
and
Quote
Transaction is just hash of two hashes:
source address and destination address. COMB Address is for example X (a pubkey)

The first line suggests you're turning the signature digits into segwit addresses before hashing again, which doesn't make sense to me and seems incorrect. The second line(s) suggest you're tipping to a hash of two keys. Is the "source address" supposed to be interpreted as ONE of the 21 generated hashs, and my putting step 3 in Stage 1 was a misunderstanding? This makes the most sense to me, but I want to be certain. The reason I placed step 3 in there is due to the order of the quoted lines, and the use of "source address."

Assuming that I'm correct about that, then another question I have is what's stopping somebody from tipping the same address to execute the transaction a second time? If Bob sends a portion of his fund to somebody using a liquidity stack, and the remainder go back to his wallet, what's to stop the recipient from just tipping the same segwit address again to initiate another, identical transaction? I understand in BTC the signature changes for each transaction entry, but I don't see how you get the same effect in the Haircomb system. Cryptography isn't my strong suit, if someone could tell me what I'm missing I'd appreciate it.

EDIT: Reading the whitepaper again, it seems like what probably happens is something like the following (this will also highlight what I'm not understanding yet):

1. Take the public key and run the signature function f(public_key, ???)
2. Take the signature and create a hash for each number as n in SHA256(whitepaper + n)
3. For each result, do SHA256(result + destination_wallet_public_key)
4. Convert those hash results to the addresses
5. Tip said addresses.

This makes the most sense to me. I still don't know what the ??? part of the signature function is though, and I don't understand the actual signature function itself, although I don't need to or expect to (at least, not for a while)



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 03, 2020, 06:58:38 AM
Alice owns 999 tokens on a haircomb public key bignum_0. She also knows the corresponding preimages bignum_1,bignum_2,bignum_3...bignum_19,bignum_20,bignum_21.
Bob generates an address bignum_22.
Alice wishes to pay and permanently redirect all her funds from bignum_0 to bignum_22. She calculates the "transaction" bignum_23=SHA256(bignum_0 concatenate bignum_22)
bignum_23 is inserted into the function CutCombWhere(), smallnum_1,smallnum_2,...,smallnum_21 = CutCombWhere(bignum_23)
All the small nums (smallnum_1,smallnum_2,...,smallnum_21) are unsigned integers less or equal to 59213 and for any specific CutCombWhere input they sum to 59213
Now Alice does the signature
bignum_24 = SHA256^(59213-smallnum_1)(bignum_1)
bignum_25 = SHA256^(59213-smallnum_2)(bignum_2)
bignum_26 = SHA256^(59213-smallnum_3)(bignum_3)
...
bignum_44 = SHA256^(59213-smallnum_21)(bignum_21)
The signature is then committed to using the whitepaper

bignum_45 = SHA256(whitepaper concatenate bignum_24)
bignum_46 = SHA256(whitepaper concatenate bignum_25)
bignum_47 = SHA256(whitepaper concatenate bignum_26)
...
bignum_65 = SHA256(whitepaper concatenate bignum_44)

Now bignum_45 ... bignum_65 is segwit encoded and propagated on chain. When there are sufficiently
many confirmations, the haircomb isn't in address bignum_0 anymore, it is now in the address bignum_22.

To prove to Bob that the haircomb is now in the address bignum_22, Alice does the following.

She gives bignum_24,bignum_25,bignum_26...bignum_44 to Bob. (The signature)
She gives bignum_0, bignum_22  to Bob. (The "transaction")
Additional proofs that the haircomb public key bignum_0 contained 999 tokens in the first place ("transaction history")

Now first of all Bob validates the transaction history and realizes that Alice really owned 999 tokens on a haircomb public key bignum_0

Secondly Bob checks if the signature is really commited to on chain and in which blocks and outputs it is buried (height of commitment). If it isn't buried,
the payment is rejected.

Bob independently calculates the "transaction", bignum_23=SHA256(bignum_0 concatenate bignum_22)
From this, Bob independently derives the same small nums (smallnum_1,smallnum_2,...,smallnum_21) using the CutCombWhere(bignum_23) just like Alice did.

And Bob can check for double spend by hashing the value bignum_24 smallnum_1 times. After every iteration he gets a different "X". Every different
SHA256(whitepaper concatenate "X") is looked up on-chain to see if there is conflict (if the conflict is buried earlier than our height of commitment).

Bob also checks for doublespend hashing the value bignum_25 smallnum_2 times.
Bob also checks for doublespend hashing the value bignum_26 smallnum_3 times.
...
Bob also checks for doublespend hashing the value bignum_44 smallnum_21 times.

Finally, a byproduct of this doublespend checking are the last values of "X" (bignum_66, bignum_67...bignum_86) for every one of the 21 teeth. Bob in the end checks,
to see if the Alice's haircomb itself is genuine.

bignum_0 = SHA256(bignum_66 concatenate bignum_67 concatenate ... concatenate bignum_86 )

and compares this bignum_0 with the bignum_0 from Alice.

If there was no double spend - the funds are now in Bob's possession (in the address bignum_22).



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 03, 2020, 08:54:11 PM
Wow, thank you so much for this! It's way more complicated than I initially thought, that's awesome! If I lay out how I read this, can you point out any mistakes I've made?

Alice has tokens on alice_public_key. She knows corresponding preimages(I don't know this term, can you define it for me?) apk_pi_1 through apk_pi_21, we'll say in an array called apk_pi_array. She wants to send all her funds to Bob's address bob_public_key. So. . .

1. txid = SHA256(alice_public_key CAT bob_public_key)
2. smallnums = CutCombWhere(txid) (Which produces an array of small numbers that sum up to 59213)
3. Generate a new BTC TX value by doing:
        N = 0
        SHA256(SHA256(59213-small_nums[N]), SHA256(apk_pi_array[N])) (How I intepreted SHA256^(59213-x)(y), let me know if I got the syntax wrong.)
        Encode the result to segwit.
    Repeat with N+=1 until the last loop of N = 20.

To validate Alice's starting balance, she gives Bob the entire TX history of the public_key she used to trade? Is the correct?

"in which blocks and outputs it is buried (height of commitment). If it isn't buried,the payment is rejected."
I don't understand what "buried (height of commitment)." mean in this context. I get the general idea I think, you're validating the position of the transaction on the Host Chain (?), but I want to understand 100% what you mean.


And Bob can check for double spend by hashing the value bignum_24 smallnum_1 times. After every iteration he gets a different "X". Every different
SHA256(whitepaper concatenate "X") is looked up on-chain to see if there is conflict (if the conflict is buried earlier than our height of commitment).

Bob also checks for doublespend hashing the value bignum_25 smallnum_2 times.
Bob also checks for doublespend hashing the value bignum_26 smallnum_3 times.
...
Bob also checks for doublespend hashing the value bignum_44 smallnum_21 times.

Finally, a byproduct of this doublespend checking are the last values of "X" (bignum_66, bignum_67...bignum_86) for every one of the 21 teeth. Bob in the end checks,
to see if the Alice's haircomb itself is genuine.

bignum_0 = SHA256(bignum_66 concatenate bignum_67 concatenate ... concatenate bignum_86 )

and compares this bignum_0 with the bignum_0 from Alice.

If there was no double spend - the funds are now in Bob's possession (in the address bignum_22).

I get the steps that Bob walks through here, but I'm not able to understand/appreciate the relationship between the numbers and functions used that allows for this to actually work. I'll figure it out in the future though, but for now I want to get the non-crypto steps locked in my head first. Thanks for being patient with me :)

Also, kelozar, I'm stuck on 2 PMs per day, I'll message you again they let me lol.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 04, 2020, 02:32:08 AM
haircomb corresponding preimages (bignum_1,bignum_2,bignum_3...bignum_19,bignum_20,bignum_21) are simply the private key of the haircomb.
They are 21 true random big numbers Alice generated when creating her wallet key.
alice_public_key = SHA256( SHA256_59213_times(bignum_1) CAT SHA256_59213_times(bignum_2) ... CAT SHA256_59213_times(bignum_21) )

Sorry my syntax is weird, but it's simply to run SHA256 many times on an input y. Example: SHA256^(2)(blockheader) is the mining function of Bitcoin.

In step 1 you are correct she does the txid from both the old and new public keys
In step 2 you are correct she does the small numbers that sum to 59213

What needs to happen next:

bignum_1 is hashed 59213-smallnum_1 times to get bignum_24
...
bignum_21 is hashed 59213-smallnum_21 times to get bignum_44

Example: Alice wishes to sign number zero because txid = 0 (txid=0x000000...00000000, in practice this won't happen, just an example)
 
step 2. CutCombWhere(0) = [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 59213]
step 3:
Alice hashes her first private key value "A" 59213-0 = 59213 times and gets resultA. SHA256(whitepaper CAT resultA) is stored on chain.
Alice hashes her second private key value "B" 59213-0 = 59213 times and gets resultB. SHA256(whitepaper CAT resultB) is stored on chain.
...
Alice hashes her last private key value "U" 59213-59213 = 0 times and gets resultU. SHA256(whitepaper CAT resultU) is stored on chain.


After 6 confirmations Alice reveals resultA....resultU to Bob.

Now Bob is able to verify the SHA256(whitepaper CAT result) is stored on chain for every result. He is also able to verify there is
no double spend, using the described method, this is sufficient for the crypto currency to work.


Another example:

Alice wishes to sign the largest 256-bit number txid=0xFFFFFFFFFFFF...FFFFFFFFFFFF

CutCombWhere(0xFFFFFFFFFFFF...FFFFFFFFFFFF) = [20749 2206 197 1147 1200 45 2983 1472 616 140 1230 3806 3140 1031 3025 1551 136 4753 123 1412 8251]

First private key value is hashed 38464 times.
Second private key value is hashed 57007 times.
...
Last private key value is hashed 50962 times.

This is how Alice is able to sign arbitrary 256-bit number txid.


About transaction history. If Alice is the first owner the history is just empty. Otherwise, it contains the proofs from all the previous coin owners of the coin.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 04, 2020, 02:56:24 PM
Quote
haircomb corresponding preimages (bignum_1,bignum_2,bignum_3...bignum_19,bignum_20,bignum_21) are simply the private key of the haircomb.
They are 21 true random big numbers Alice generated when creating her wallet key.
alice_public_key = SHA256( SHA256_59213_times(bignum_1) CAT SHA256_59213_times(bignum_2) ... CAT SHA256_59213_times(bignum_21) )

Alright, that makes sense.

Quote
Sorry my syntax is weird, but it's simply to run SHA256 many times on an input y. Example: SHA256^(2)(blockheader) is the mining function of Bitcoin.

Oh no problem, the now that I understand it it makes sense, SHA256 to the power of X on Y.

Quote
In step 1 you are correct she does the txid from both the old and new public keys
In step 2 you are correct she does the small numbers that sum to 59213

What needs to happen next:

bignum_1 is hashed 59213-smallnum_1 times to get bignum_24
...
bignum_21 is hashed 59213-smallnum_21 times to get bignum_44

Example: Alice wishes to sign number zero because txid = 0 (txid=0x000000...00000000, in practice this won't happen, just an example)
 
step 2. CutCombWhere(0) = [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 59213]
step 3:
Alice hashes her first private key value "A" 59213-0 = 59213 times and gets resultA. SHA256(whitepaper CAT resultA) is stored on chain.
Alice hashes her second private key value "B" 59213-0 = 59213 times and gets resultB. SHA256(whitepaper CAT resultB) is stored on chain.
...
Alice hashes her last private key value "U" 59213-59213 = 0 times and gets resultU. SHA256(whitepaper CAT resultU) is stored on chain.

Lol the more I understand the cooler it gets. So to be certain, it's not a single loop, it's nested loops? i.e.
   
    small_nums = [small_num1 . . . small_num21]
    big_nums = [big_num1 . . . big_num21]
    bignum_output_array = []

    n = 0, while n < 21:
       
        //setup the corresponding numbers
        hash_num = 59213-small_nums[n]
        bignum_output = big_nums[n]

        //Hash the bignum X times, where X is hash_num
        while hash_num >= 0:
            bignum_output = SHA256(bignum_output)
            hash_num -= 1
       
        bignum_output_array.append(bignum_output)
        n+=1



Quote
After 6 confirmations Alice reveals resultA....resultU to Bob.

Now Bob is able to verify the SHA256(whitepaper CAT result) is stored on chain for every result. He is also able to verify there is
no double spend, using the described method, this is sufficient for the crypto currency to work.


Another example:

Alice wishes to sign the largest 256-bit number txid=0xFFFFFFFFFFFF...FFFFFFFFFFFF

CutCombWhere(0xFFFFFFFFFFFF...FFFFFFFFFFFF) = [20749 2206 197 1147 1200 45 2983 1472 616 140 1230 3806 3140 1031 3025 1551 136 4753 123 1412 8251]

First private key value is hashed 38464 times.
Second private key value is hashed 57007 times.
...
Last private key value is hashed 50962 times.

This is how Alice is able to sign arbitrary 256-bit number txid.


About transaction history. If Alice is the first owner the history is just empty. Otherwise, it contains the proofs from all the previous coin owners of the coin.

So I guess one thing I still don't get, it what separates transactions that look the same?

1. Alice pays Bob (alice_pubkey_1 -> bob_pubkey_1)
2. Time passes. Bob needs to pay Alice now (bob_pubkey_1 -> alice_pubkey_1)
3. More time passes. Bob and Alice get in a fight, and stop being friends. Bob wants to steal his money back from Alice. Why can't he just tip the same segwit addresses that Alice tipped in the first tx(alice_pubkey_1 -> bob_pubkey_1)? I feel like I'm missing something about the transaction process, because what's stopping somebody from perfectly replicating a previous transaction? The only thing that seems to get encoded is the is the origin and destination of the funds.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 04, 2020, 07:29:46 PM
Yes I understand.

To explain, these simplest possible kinds of haircomb "transactions" aren't really transactions with 1 input and 1 output just
like in Bitcoin. The concept of the haircomb "transaction" is very different from Bitcoin.

It is more like a permanent redirect of all past, present and future funds.

1. Alice permanently redirects funds to Bob (alice_pubkey_1 -> bob_pubkey_1) and signs off the redirect on-chain
2. Bob permanently redirects funds to Alice (bob_pubkey_1 -> alice_pubkey_1) and signs off the redirect on-chain
3. Now where did the coins go? Clearly, the coins must be in some kind of an infinite loop now.

More precisely the coins are deleted by the wallet due to a coin-eating loop in the graph.

To prevent this problem the wallet contains a loop detector that is run before signing every transfer. So in reality it
will go like this:

1. Alice permanently redirects funds to Bob (alice_pubkey_1 -> bob_pubkey_1) and signs off the redirect on-chain
2. Bob tries to pay to alice_pubkey_1, coin loop detector is run
3. Bob's wallet warns Bob about the loop and does not let him to proceed.

Now, if you wish to pay someone using haircomb without permanently redirecting the funds you would use liquidity stack to do that.

Liquidity stack transactions are much more similar to Bitcoin transactions and they are known to not be affected by the permanent
redirect nature of the simple transaction at all.


But liquidity stacks are really difficult topic. To begin, you don't pay to Bob's address but you pay to a liquidity stack entry.
The liquidity stack entry then pays to Bob a specific number of coins and the change is redirected to a new hair comb (fresh public key) of Alice.




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 04, 2020, 08:29:41 PM
Quote
Yes I understand.

To explain, these simplest possible kinds of haircomb "transactions" aren't really transactions with 1 input and 1 output just
like in Bitcoin. The concept of the haircomb "transaction" is very different from Bitcoin.

It is more like a permanent redirect of all past, present and future funds.

1. Alice permanently redirects funds to Bob (alice_pubkey_1 -> bob_pubkey_1) and signs off the redirect on-chain
2. Bob permanently redirects funds to Alice (bob_pubkey_1 -> alice_pubkey_1) and signs off the redirect on-chain
3. Now where did the coins go? Clearly, the coins must be in some kind of an infinite loop now.


More precisely the coins are deleted by the wallet due to a coin-eating loop in the graph.

To prevent this problem the wallet contains a loop detector that is run before signing every transfer. So in reality it
will go like this:

1. Alice permanently redirects funds to Bob (alice_pubkey_1 -> bob_pubkey_1) and signs off the redirect on-chain
2. Bob tries to pay to alice_pubkey_1, coin loop detector is run
3. Bob's wallet warns Bob about the loop and does not let him to proceed.

Woah. Ok I can understand that conceptually, but it'll take be a bit to get a good visual for it in my head lol. That's super cool.

So wait, then if Alice pays Bob (alice_pubkey_1 -> bob_pub_key_1), you're saying it binds the accounts together in a way? So in the future, if Chris pays Alice using the same public key that Alice used to pay Bob (chris_pubkey_1 -> alice_pubkey_1), would the funds go to bob_pubkey_1? I'm visualizing it like water in a tube, the end being capped off by whatever the last public_key in the chain in. Put water in the beginning of the tube (Chris->Alice) and it flows down to the bottom. Add an extension to the bottom of the tube(Bob->Daisy), and all the collected water flow down to whatever the next bottom is. Is this correct? If it is, this flowing effect would also apply to all deposits into the top of the tube (Chris) that were made using liquidity stacks, yes?


Quote
Now, if you wish to pay someone using haircomb without permanently redirecting the funds you would use liquidity stack to do that.

Liquidity stack transactions are much more similar to Bitcoin transactions and they are known to not be affected by the permanent
redirect nature of the simple transaction at all.

But liquidity stacks are really difficult topic. To begin, you don't pay to Bob's address but you pay to a liquidity stack entry.
The liquidity stack entry then pays to Bob a specific number of coins and the change is redirected to a new hair comb (fresh public key) of Alice.

Yea I got the application of them to some degree from going through the explanations in the thread and the whitepaper, the whole stack-chaining process is interesting, but there are definitely large chunks of my understanding missing, of what exactly is happening lol, e.g. I have no idea what "Deciders" do.  But is my question in the other post not still valid when using Liquidity stacks?

1. Alice pays Bob 1 comb using a stack defined as SHA256(alice_pubkey_1, bob_pubkey_1, 1*), and the payment process as outlined above.
2. Bob wants to take more of Alice's money, he tips the same addresses that Alice did when she transferred to the liquidity stack.

Actually, going back and reading the thread, is this what the purpose of Deciders is? To validate liquidity stack based transactions? I can't see any real explanation regarding them, all I've got is what I've been able to infer from the trade event that took place. From what I'm reading, it seems as if they're used to execute specific functions/events during transfers, potentially after the funds have hit the liquidity stack? The fact that there's a "forward" decider and "rollback" decider is what gives me this impression, however looking at the Wallet UI itself, I have no idea how to use them.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 05, 2020, 10:15:50 AM
Yes you are right about comb transaction, it's just like a water pipeline in between two addresses.

Liquidity stack entry is like an open tap on the pipeline that pays specific number of coins to Bob.
After that the tap closes.

The scenario in which Alice permanently redirects funds to Bob is possible. But it is not done in practice
precisely, as you correctly noticed, is to avoid Alice losing control of future incoming payments to her old address.

Quote
2. Bob wants to take more of Alice's money, he tips the same addresses that Alice did when she transferred to the liquidity stack.

Tipping the same addresses has no effect. Only the first time tips to a certain segwit address triggers an action.

And there are no funds in Alice's old address anymore. Everything is either inside liquidity
stack, inside Bob's wallet and or inside Alice's new address.

So, to pay Bob 1 coin alice signs the transaction:

txid = SHA256(alice_old_address CAT SHA256(alice_new_address CAT bob_address CAT 1 coin))

but not what you wrote:

txid = SHA256(alice_old_address CAT SHA256(alice_old_address CAT bob_address CAT 1 coin))

because this would cause 1 coin to go to Bob and the remaining Alice's coins would get looped in a coin eating loop.


The exciting thing about the liquidity stack is how no matter how many receivers there are, only the 21 addresses need to be funded.

For the first time in history Alice can literally pay to millions of people on the Bitcoin chain. Here's how:


stack0 = alice_new_address

stack1 = SHA256(stack0 CAT person1 CAT 0.00000001 coin)
stack2 = SHA256(stack1 CAT person2 CAT 0.00000001 coin)
stack3 = SHA256(stack2 CAT person3 CAT 0.00000001 coin)
....
stack999999 = SHA256(stack999998 CAT person999999 CAT 0.00000001 coin)
stack1000000 = SHA256(stack999999 CAT person1000000 CAT 0.00000001 coin)

txid = SHA256(alice_old_address CAT stack1000000)

When Alice signs txid and commits to it with 6 confirmations, her 0.01 coin gets paid to 1000000 people (0.00000001 coin each).


Deciders are a different matter altogether.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 05, 2020, 02:11:44 PM
Yes you are right about comb transaction, it's just like a water pipeline in between two addresses.

Liquidity stack entry is like an open tap on the pipeline that pays specific number of coins to Bob.
After that the tap closes.

The scenario in which Alice permanently redirects funds to Bob is possible. But it is not done in practice
precisely, as you correctly noticed, is to avoid Alice losing control of future incoming payments to her old address.

Quote
2. Bob wants to take more of Alice's money, he tips the same addresses that Alice did when she transferred to the liquidity stack.

Tipping the same addresses has no effect. Only the first time tips to a certain segwit address triggers an action.

Okay this answers that question, and the question that immediately arises is of course that wouldn't this prevent Alice ever paying Bob the same amount of money twice? But you answered it already with:

Quote
And there are no funds in Alice's old address anymore. Everything is either inside liquidity
stack, inside Bob's wallet and or inside Alice's new address.

So, to pay Bob 1 coin alice signs the transaction:

txid = SHA256(alice_old_address CAT SHA256(alice_new_address CAT bob_address CAT 1 coin))

but not what you wrote:

txid = SHA256(alice_old_address CAT SHA256(alice_old_address CAT bob_address CAT 1 coin))

because this would cause 1 coin to go to Bob and the remaining Alice's coins would get looped in a coin eating loop.

Okay so that makes sense. Liquidity stacks also operate like connected pipes forever, they just have a threshold for how many funds are siphoned off every time the "water" passes through. So if Alice redirects back to her original address, the water is still in the same pipe, and just gets looped forever, siphoning off X water every pass.

Then my next question is, where does Alice's new_address come from? Are you saying that Alice has to generate and save a new wallet every time she wants to move any amount of funds to people?


Quote
The exciting thing about the liquidity stack is how no matter how many receivers there are, only the 21 addresses need to be funded.

For the first time in history Alice can literally pay to millions of people on the Bitcoin chain. Here's how:


stack0 = alice_new_address

stack1 = SHA256(stack0 CAT person1 CAT 0.00000001 coin)
stack2 = SHA256(stack1 CAT person2 CAT 0.00000001 coin)
stack3 = SHA256(stack2 CAT person3 CAT 0.00000001 coin)
....
stack999999 = SHA256(stack999998 CAT person999999 CAT 0.00000001 coin)
stack1000000 = SHA256(stack999999 CAT person1000000 CAT 0.00000001 coin)

txid = SHA256(alice_old_address CAT stack1000000)

When Alice signs txid and commits to it with 6 confirmations, her 0.01 coin gets paid to 1000000 people (0.00000001 coin each).


Deciders are a different matter altogether.

Yea the combined transaction process is awesome, it makes more sense too now that I understand the pipe analogy (lol literally LIQUIDity stacks). It helps to imagine the funds as permanently in motion, just impeded by a lack of place to go, until a "transaction" opens a valve and they just flow down to the next guided place.

I'll leave decider questions for after I properly understand this process then. Thank you again for your explanations, I have a TON of questions, and this is way faster and easier than having to try and dive through the code myself and try to build an understand from that alone with no assistance.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 05, 2020, 06:38:36 PM
Liquidity stacks have a threshold for how many funds are siphoned
off FIRST TIME the "water" passes through. Any additional time
the same or different water passes through, the stack output is already
satisfied and the water simply flows down towards the CH (change address or the next stack entry).

Siphoning off X water every pass would not work well, because then you could
form a coin eating loop with X water forever getting siphoned into the OUT returning back into the same stack.

The way the wallet works is secure in this manner. The worst thing the Alice can do from the user interface
is to pay to alice_old_address, forming the liquidity stack loop and this loop is not coin eating.

Example:

txid = SHA256(alice_old_address CAT SHA256( alice_new_address CAT alice_old_address CAT 1 coin ))

Her coin will simply take one full loop and fall into the alice_new_address:

1. 999 coins depart from alice_old_address into the stack
2. The stack discovers that 999 >=1 coin arrived.
3. The stack triggers and temporarily puts 998 coins into the alice_new_address and 1 coin into alice_old_address
4. There is now 1 coin into alice_old_address, it flows back into the stack
5. The stack discovers that 1 coin arrived but stack is already used.
6. The stack temporarily adds the 1 coin to alice_new_address (reason: stack already used)
7. There are now 999 coins in alice_new_address, coin propagation ends

See? Everything is safe for the end user even though 1 coin took a loop. She simply paid to herself.

Quote
Alice has to generate and save a new wallet every time she wants to move any amount of funds to people?

Yes. She needs to save the new private key carefully on disk before every time she pays. She also needs to carefully save the complete liquidity
stack she intends to pay to on disk before she pays. Both objects are stored inside her new wallet.

If she were to lose the stack after she pays to it the funds will be lost. The reason is, she has no proof to give to Bob.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 05, 2020, 07:40:47 PM
Quote
Liquidity stacks have a threshold for how many funds are siphoned
off FIRST TIME the "water" passes through. Any additional time
the same or different water passes through, the stack output is already
satisfied and the water simply flows down towards the CH (change address or the next stack entry).

Siphoning off X water every pass would not work well, because then you could
form a coin eating loop with X water forever getting siphoned into the OUT returning back into the same stack.

The way the wallet works is secure in this manner. The worst thing the Alice can do from the user interface
is to pay to alice_old_address, forming the liquidity stack loop and this loop is not coin eating.

Example:

txid = SHA256(alice_old_address CAT SHA256( alice_new_address CAT alice_old_address CAT 1 coin ))

Her coin will simply take one full loop and fall into the alice_new_address:

1. 999 coins depart from alice_old_address into the stack
2. The stack discovers that 999 >=1 coin arrived.
3. The stack triggers and temporarily puts 998 coins into the alice_new_address and 1 coin into alice_old_address
4. There is now 1 coin into alice_old_address, it flows back into the stack
5. The stack discovers that 1 coin arrived but stack is already used.
6. The stack temporarily adds the 1 coin to alice_new_address (reason: stack already used)
7. There are now 999 coins in alice_new_address, coin propagation ends

See? Everything is safe for the end user even though 1 coin took a loop. She simply paid to herself.

Okay so liquidity stacks only siphon once, then afterwards that essentially act as a normal wallet that's been connected to another wallet downstream, right? So if Chris then came and payed out X combs like:

SHA256(chris_1, SHA256(alice_new_address CAT alice_old_address CAT X))

All of Chris's combs would end up in alice_new_address.

Quote
Quote
Alice has to generate and save a new wallet every time she wants to move any amount of funds to people?

Yes. She needs to save the new private key carefully on disk before every time she pays. She also needs to carefully save the complete liquidity
stack she intends to pay to on disk before she pays. Both objects are stored inside her new wallet.

If she were to lose the stack after she pays to it the funds will be lost. The reason is, she has no proof to give to Bob.

Alright, it makes sense that it would work like this, although it'd be a pain for the user to operate. Correct me if I'm wrong, but the steps to pay anybody are:

1. Save old wallet
2. Generate new wallet
3. Save new wallet
4. Copy new wallet public key to clipboard
5. Import old wallet
6. Begin payment process with the new wallet public key on the clipboard.

I wonder if there's a UI way to make the user experience easier. Like, when you initiate a payment, there's a form on the UI that has a place to enter output/output amount like normal, but instead of just a field to paste the new change address, there'd also be a button that said "Generate New Wallet Address" or something like that. Clicking it would make a popup appear that just had a name entry field, and if you put in a name and hit ok, it would generate a new wallet.dat file with a new private key, save it with the name you put in, and then automatically fill the change address field with that wallet's public key. That way you could still enter in all the details manually if you wanted, but from a normal user's convenience perspective, you take all 6 of the steps from before and combine them into one single button press.

I wanna try and build a basic GUI for the wallet first, but something like this makes sense to do next. Can you foresee any problems if this was to be implemented?


More questions about transactions; the 21 hostchain TX requirement. First, are these all required to be entirely separate transactions, or can you batch transact them? I.e. Do you have to pay 21*TX_fee? From what I've read and got from speaking with Kelozar, you can't batch transact them, and if this is true, I'm curious as to the reason for it, but also if you could batch those transactions in such a manner that you'd be able to roll for more haircomb claims? I.e. one TX per hostchain block, then have the first TX in the list be the mining address, and the second be the TX signature address?

Another question is why can't Alice just give Bob the old wallet's private keys? Every transaction burns the previous wallet effectively, correct? If this is the case, then even if Bob had the private keys, what could he actually use them for? The wallet is already connected in the system to dump any funds it receives.

EDIT 3: Think I get the double spend bit now. If the funds were spent before, then at least ONE of that transaction's hash chain results would be greater than the corresponding result for the current transaction hash chain, and he'd find it, because of the totalling up to 59213 rule with he small numbers.

My question still stands though, why can't Alice just give the private keys to Bob, if she's making a new wallet after ever TX anyways? Am I misunderstanding something about the new wallet process?

EDIT 4: Cleared up a bunch of verbal diarrhea to make the post more readable.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 06, 2020, 09:50:36 PM
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


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 06, 2020, 10:45:35 PM
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.



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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 08, 2020, 05:24:45 AM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 10, 2020, 12:33:39 AM

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.


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.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 10, 2020, 05:12:07 AM

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.


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.



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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 10, 2020, 05:22:41 PM
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/


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 11, 2020, 03:16:42 PM
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/


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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 12, 2020, 05:27:16 PM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 14, 2020, 06:12:38 PM
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!"


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 28, 2020, 01:16:04 AM
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).


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 29, 2020, 01:22:27 AM
My BTC finally synced and I got to claim :D

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?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: kelozar on November 29, 2020, 06:24:20 PM
My BTC finally synced and I got to claim :D

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?

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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 29, 2020, 09:18:22 PM

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.


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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: notsofast on December 02, 2020, 08:44:44 PM
Hello boys. The project is alive. I'm working on the liquidity stack loops. It will be done when the numbers tell me it's done and not earlier.

I'm working on it in my spare time and I am not paid but that is not the problem. Money won't accelerate the progress only brain power will. I feel that my coins going up in value eventually will be the best reward.

Yeah you have to outbid highest fee payer.

About the possibility of haircomb on BSV or on BCH, it's not directly possible since there is no segwit and thus no 256bit addresses that I am aware of.

Even if those coins had 256bit addresses it would be a not so great idea to run haircomb on it. The reason is it uses sha256 hashing and is prone to 51%/reorg attacks. And succesfull 51 % attack means recently-transacted coin destruction in the worst case (if the attacking miner knows the haircomb coins history)

Haircomb on Litecoin would be a possibility though, it's reasonably powerful, has segwit, and not prone to 51% attacks.

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?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on December 03, 2020, 02:07:45 AM

I can't tell right away, but would BTC-comb be compatible with LTC-comb? Could it be made compatible?

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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on December 03, 2020, 02:18:42 AM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: notsofast on December 03, 2020, 01:29:21 PM
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.


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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on January 04, 2021, 03:28:50 PM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: haircombint on February 01, 2021, 11:23:45 PM
Made a telegram for COMB for those interested. t.me/comb_talk


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 06, 2021, 12:02:46 AM
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


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 07, 2021, 01:40:31 AM
RakeCOMB v0.2.0 is out.
https://github.com/nixed18/RakeCOMB/releases/tag/v0.2.0

Changes:
Add the ability to perform transactions and view previous transaction information.

There are some modifications to how RakeCOMB performs when compared with HaircombCore; RakeCOMB prevents you from using a previously burnt address as the Change Address for future transactions. I can't think why this wouldn't be appropriate, but if I've missed something, let me know.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 12, 2021, 03:31:54 PM
I've been trying to figure out exactly how the deciders and contracts function mechanistically. Below I've included a diagram of my current understanding of the structure of the two, which I believe is correct. (This is of a non-stacked object, hence the "000...000")

https://i.imgur.com/nyvGjXA.png

I'm stuck on how the actual mechanism works. I don't understand how Natasha managed to sign multiple contracts with the same decider. This is even more perplexing when you look at her post in which she states:

Quote
- I will publish a file with say 1000 deciders in it. This will mean I could theoretically decide 1000 comb trade contracts

This makes me think you can decide more contracts than 1 using the same decider, so long as you decide them all simultaneously. But I don't understand how that would work. My assumption is that as the decider, you're committing 2 numbers to the BTC chain; the hashchain CCW() results for both of the long decider numbers. But unless you where structuring the associated merkle trees in such a manner that the same two commits would trigger all of them simultaneously to respond the way you wanted, I don't see how that's possible.

My other assumption was that, looking at the image I posted, the short decider is either SHA256(000...000 + N_1 + N_2), or just SHA256(N_1 + N_2).

Another thing I don't understand is the need for the merkle tree. The wallet only lets you input 2 addresses for each contract; the Forward Address and the Rollback address. Is this just a limitation of the current wallet design, which can be expanded upon to include all 65536 destinations in a single contract?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on February 14, 2021, 08:57:49 PM
There is an unanswered question about Alice spending coins before she received them, it comes as a surprise
to an ordinary Bitcoiner, that you can even do this (and it definitely looks like a money creation from thin
air problem at first sight).

The scenario is spending a 0 COMB key and paying out say 1 COMB to your friend using the liquidity
stack output and then later (optionally) funding that 0 COMB key with 1 COMB.

Why there is no pay button for 0 COMB keys?

because it seems pointless spending 0 COMB. You can access the underlying URL manually and then you can then spend 0 COMB keys.

Why can't I pay out 2 COMB from a 1 COMB key? Or pay out 1 COMB from a 0 COMB key?

This is a safeguard to prevent users from accidentally having their money stuck in a pending liquidity stack.

If users can bypass these checks, why there is not a money creation from thin air problem at the consensus layer?

Because haircomb money must be created from comb-base only. If you spend a 0 COMB key paying
out a 1 COMB to your friend, he sees that there is no comb-base associated that filled the original
wallet with 1 COMB in the history given to the friend.
In effect the friend will see no incoming funds at all until the comb rules are full-filled. They will be full-filled when
the history is merged with another history paying the reuqired funds from comb-base.
It does not matter who merges the histories, or in what order the histories were made, it only matters that
the final merged history gets posted to the final recipient somehow.

So yes, in effect, you can spend funds before you have them. But they will only become available to the final
party only at the moment they get paid to you and the histories get merged and posted to the final party.

It's pretty uninteresting (to be honest), so let's change the topic to comb trades.

Preliminaries: Comb trades use 16-level-65536-leaf merkle tree as a building block. They also use a decider as a building block. Merkle
tree is well understood, but I need to explain decider.

It is a postquantum signature scheme to sign a small number 0-65535.

Basically you roll 2 256bit true random numbers, and you save them carefully on disk. That is the decider private key. That private key can also
be stored in-wallet.

From the private key you calculate two hash chains of 65535 hashes. Then you hash 3 values one of which is just 256bit zero. This is a chaining
value to be explained later. Currently you can assume it will be zero. The other two values are the tips of the hash chains.

So you hash the 3 values and you get a "decider public key" also known as "short decider." You can give the short decider to other people.
It is like an address except it isn't, it is hexadecimal 256 bit number but uses different alphabet G-V

The user received a short decider from the decider person. The user wants to make the contract address.

To make the contract address just hash "short decider" CAT "merkle root".

WHAT MERKLE LEAVES TO USE

There is a trick, instead of providing 65536 different addresses as the 65536 leaves wich are useless from the business perspective
the user uses just a "forward" address and a "rollback" address repeatedly. These kinds of binary contracts with exactly 2 outcomes
are important for all kinds of trades.

So to fill the 65536 leaves of the merkle tree the user uses a pattern of just 2 addresses. There are 16 useful patterns. They are:

1. rollback (1 time), forward (1 time), rollback (1 time), forward (1 time), ... (total 65536 times)
2. rollback, rollback (2 times), forward, forward (2 times), ... (total 65536 times)
3. rollback, rollback, rollback, rollback  (4 times), forward, forward, forward, forward (4 times)... (total 65536 times)
...
...
...
16. rollback (32768 times), forward (32768 times) (total 65536 times)

The counter-party also does the same calculation to arrive at the exactly same merkle root. And because both parties trust the decider
person, they both use the decider person's "short decider", to arrive and cross-check the exact contract address.

These patterns each have the additional property, that, if you are flipping just 1 bit, exactly one comb-trade-bit's outcome is changing.

So imagine you sign the 16bit number to be "1" instead of "0" what happens? Only in the pattern 1 the outcome (the leaf address) changed from
rollback to forward. Other contracts remain unaffected (remain "rollback").

This is why 16 comb trade bits exist, this is how 1 decider is able to control up to 16 binary comb trades between 32 trading parties, to be settled
at the same time.


Obviously you can simply use 1 decider for 1 comb trade. Using 1 decider for 16 contracts is just an optimalization to squeeze more commerce into
Bitcoin's tiny block space.


You (the decider person) can sign using the decider just you would with a haircomb, that is, you commit-to from the two hash-chains
a commitments of two values at the depths that sums to 65535.
If you fail to do this, you will burn the key, e.g. the scheme is one-time-only.

Then you (or somebody) tips the two commitments using 330 sats.

When there are 6+ confirmations you can reveal the "signature" also known as a "long decider"

The signature is just a signed value n (16-bit) CAT value at depth n CAT value at depth 65535-n in some encoding.

The user adds the proof that the decider had signed a number n together with a proof of n-th merkle branch to their wallet. The wallet
accepts the combined proof as a coin history entry and moves the funds from the contract address to the merkle leaf address.

The leaf address can be again one of the 3 address types e.g. haircomb public key/liquidity stack entry/contract address.

But the leaf address can also be another merkle root, this is the chained merkle tree scenario in which the decider is not hashed
with the 256 bit zero but with another chained short decider to form a linked list of deciders.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 14, 2021, 10:44:11 PM
There is an unanswered question about Alice spending coins before she received them, it comes as a surprise
to an ordinary Bitcoiner, that you can even do this (and it definitely looks like a money creation from thin
air problem at first sight).

The scenario is spending a 0 COMB key and paying out say 1 COMB to your friend using the liquidity
stack output and then later (optionally) funding that 0 COMB key with 1 COMB.

Why there is no pay button for 0 COMB keys?

because it seems pointless spending 0 COMB. You can access the underlying URL manually and then you can then spend 0 COMB keys.

Why can't I pay out 2 COMB from a 1 COMB key? Or pay out 1 COMB from a 0 COMB key?

This is a safeguard to prevent users from accidentally having their money stuck in a pending liquidity stack.

If users can bypass these checks, why there is not a money creation from thin air problem at the consensus layer?

Because haircomb money must be created from comb-base only. If you spend a 0 COMB key paying
out a 1 COMB to your friend, he sees that there is no comb-base associated that filled the original
wallet with 1 COMB in the history given to the friend.
In effect the friend will see no incoming funds at all until the comb rules are full-filled. They will be full-filled when
the history is merged with another history paying the reuqired funds from comb-base.
It does not matter who merges the histories, or in what order the histories were made, it only matters that
the final merged history gets posted to the final recipient somehow.

So yes, in effect, you can spend funds before you have them. But they will only become available to the final
party only at the moment they get paid to you and the histories get merged and posted to the final party.

Ok this makes sense and lines up with what I understood; the wallet is essentially building the plumbing of the wallet on every boot and spawning the coins in their claimed addresses, then seeing where they end up. Pre-connecting B->C before A->B won't show any funds in C, because there weren't any in B. Once you connect A->B, then they'll show in C.

Quote
It's pretty uninteresting (to be honest), so let's change the topic to comb trades.

Preliminaries: Comb trades use 16-level-65536-leaf merkle tree as a building block. They also use a decider as a building block. Merkle
tree is well understood, but I need to explain decider.

It is a postquantum signature scheme to sign a small number 0-65535.

Basically you roll 2 256bit true random numbers, and you save them carefully on disk. That is the decider private key. That private key can also
be stored in-wallet.

From the private key you calculate two hash chains of 65535 hashes. Then you hash 3 values one of which is just 256bit zero. This is a chaining
value to be explained later. Currently you can assume it will be zero. The other two values are the tips of the hash chains.

So you hash the 3 values and you get a "decider public key" also known as "short decider." You can give the short decider to other people.
It is like an address except it isn't, it is hexadecimal 256 bit number but uses different alphabet G-V

The user received a short decider from the decider person. The user wants to make the contract address.

To make the contract address just hash "short decider" CAT "merkle root".

This makes sense, it's what I understood from the whitepaper, just like a normal transaction.

Quote
WHAT MERKLE LEAVES TO USE

There is a trick, instead of providing 65536 different addresses as the 65536 leaves wich are useless from the business perspective
the user uses just a "forward" address and a "rollback" address repeatedly. These kinds of binary contracts with exactly 2 outcomes
are important for all kinds of trades.

So to fill the 65536 leaves of the merkle tree the user uses a pattern of just 2 addresses. There are 16 useful patterns. They are:

1. rollback (1 time), forward (1 time), rollback (1 time), forward (1 time), ... (total 65536 times)
2. rollback, rollback (2 times), forward, forward (2 times), ... (total 65536 times)
3. rollback, rollback, rollback, rollback  (4 times), forward, forward, forward, forward (4 times)... (total 65536 times)
...
...
...
16. rollback (32768 times), forward (32768 times) (total 65536 times)

The counter-party also does the same calculation to arrive at the exactly same merkle root. And because both parties trust the decider
person, they both use the decider person's "short decider", to arrive and cross-check the exact contract address.

These patterns each have the additional property, that, if you are flipping just 1 bit, exactly one comb-trade-bit's outcome is changing.

Holy crap.

Quote
So imagine you sign the 16bit number to be "1" instead of "0" what happens? Only in the pattern 1 the outcome (the leaf address) changed from
rollback to forward. Other contracts remain unaffected (remain "rollback").

This is why 16 comb trade bits exist, this is how 1 decider is able to control up to 16 binary comb trades between 32 trading parties, to be settled
at the same time.


Obviously you can simply use 1 decider for 1 comb trade. Using 1 decider for 16 contracts is just an optimalization to squeeze more commerce into
Bitcoin's tiny block space.

So essentially the infrastructure exists to combine an large amount of 3rd-party trades into a single operation. That's awesome.

Quote
You (the decider person) can sign using the decider just you would with a haircomb, that is, you commit-to from the two hash-chains
a commitments of two values at the depths that sums to 65535.
If you fail to do this, you will burn the key, e.g. the scheme is one-time-only.

Then you (or somebody) tips the two commitments using 330 sats.

When there are 6+ confirmations you can reveal the "signature" also known as a "long decider"

The signature is just a signed value n (16-bit) CAT value at depth n CAT value at depth 65535-n in some encoding.

Ok so the long decider isn't just the hashchain heads of the short decider then, that makes sense. Do you think that the signed value n needed to be included in the signature? Couldn't you determine that value based on the other 2 signature values? I guess that it doesn't really matter if you include the signed value N, but it saves computing power on the wallet side, so it makes sense to include it.

Quote
The user adds the proof that the decider had signed a number n together with a proof of n-th merkle branch to their wallet. The wallet
accepts the combined proof as a coin history entry and moves the funds from the contract address to the merkle leaf address.

The leaf address can be again one of the 3 address types e.g. haircomb public key/liquidity stack entry/contract address.

But the leaf address can also be another merkle root, this is the chained merkle tree scenario in which the decider is not hashed
with the 256 bit zero but with another chained short decider to form a linked list of deciders.

To extend the amount of contracts that can be signed exponentially, while only increasing the amount of commitments needed linearly? If I'm understanding that correctly, it's hilarious and amazing.

EDIT: I may be wrong on the above statement? I need to spend more time visualizing the expansion process, it's difficult to do. My gut thought now though is that it would just double the amount of contracts available, but if that's the case then why would you even bother stacking trees like that?

EDIT2: Thinking about it more it makes sense that it's exponential. A tree with 4 tips can hold 2 patterns, a tree with 16 tips can hold 4, if the pattern threshold is just the square root of the tip count (not sqrt, po2 I guess)  then my initial assumption was correct. That's crazy.

One question and then I'll walk through an applied example to make sure I'm not missing anything. The following quote:
Quote
To make the contract address just hash "short decider" CAT "merkle root".

If the decider person wanted to sign multiple contracts at the same time, then the user wouldn't be the person choosing the Merkle Tree pattern, correct? It would have to be the decider person, to make sure that all the contracts they were deciding were all on different bits, right?

Okay so walkthrough time:

Alice wants to send COMB to Bob, and Cindy wants to send COMB to Dan. Xavier will be the decider person. Alice, Bob, Cindy, and Dan all give Xavier their addresses; Alice=Rollback_1, Bob=Forward_1,  Cindy=Rollback_2, Dan=Rollback_2. As there are only 2 contracts being decided, there's no need for nested Merkle Trees, so Xavier generates the two Decider private keys and then gives the Short_Decider (000...000 CAT hashchain_tip_1 CAT hashchaintip_2) Alice, Bob, Cindy, and Dan. He also generates 2 Merkle Trees, one for Alice and Bob's contract (Tree_AB) and one for Cindy and Dan's contract (Tree_CD), and gives them to their respective participants. They then each generate the COMB Address that their contract's Sender will deposit COMB into, for Alice and Bob it's SHA256(Short_Decider CAT Tree_AB) and for Cindy and Dan its SHA256(Short_Decider CAT Tree_CD). Tree_AB is using pattern 1 (01010101...) and Tree_CD is using pattern 2 (00110011...)

Alice and Cindy both deposit their COMB into their respective contract addresses, eager to get their shitcoins. I'll go over each of the possibilities below. (Using N min = 0, max = 65535:

1. Bob and Dan both deposit their shitcoins, as requested: Xavier signs N=3, Tree_AB = 010(1)... and Tree_CD = 001(1)..., COMB goes to Forward_1 and Forward_2

2. Bob loses his shitcoin wallet keys, but Dan makes his shitcoin deposit: Xavier signs N=2, Tree_AB = 01(0)1... and Tree_CD = 00(1)1..., COMB goes to Rollback_1, Forward_2

3. Bob deposits his shitcoins, but Dan accidently sends all his shitcoins to a scammer: Xavier signs N=1, Tree_AB = 0(1)01... and Tree_CD = 0(0)11..., COMB goes to Forward_1, Rollback_2

4. Bob and Dan both listen to Elon Musk and buy DOGE instead: Xavier signs N=0, Tree_AB = (0)101... and Tree_CD = (0)011..., COMB goes to Rollback_1, Rollback_2

Is this correct?

P.S. It's good to hear from you again, thank you :)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 18, 2021, 08:51:22 AM
I just learned about the centralized wallets. Natasha is a genius. Giant economic pumps, driving comb through them to run the payment system, with people using deciders as their wallets. But Watashi, my friend, I realized you are wondrously wrong about something!

Quote
instead of providing 65536 different addresses as the 65536 leaves wich are useless from the business perspective

This is true if you are a person who is deciding a contract for other people. But what if you are a person deciding a contract for YOURSELF???

Rather than send the funds from the pump to a decider with only 2 options(1 back to the Pump and 1 back to your private wallet) you could have a contract with 65536 options! You could include multiple different pump options, in case the one you normally used happened to rugpull, or even just go down temporarily for some reason. You could have multiple leaves with different liquidity stack combinations of payments you might have to make in the future (this one is a bit of a stretch, but it works well for repeated, static cost events, stuff like going to a physical therapist).

But then I realized something else. These pumps can be automated! They can be completely automated, through the use of decider contracts!!! A pump would have a certain threshold of funds that it could accommodate, for example lets say a specific Pump can accommodate 10000 COMB. This Pump would have to keep 10000 COMB on it to maintain operation. A Client would then approach the Pump and tell it that they wanted to send X COMB to a location, via the Pump. They would also approach a third party, also an automated system, to facilitate the contract as the Contractor. The Contractor would communicate with the Pump and the Client, and build a contract that would send the stored funds either to the Pump, or back to the Client. The Client pays the COMB into the contract. Once the contract has been funded, the Pump then runs its next cycle, and pays the same amount of COMB that's in the contract to the address the Client wanted it sent to. Once the Contractor gets the transaction history from the Pump and verifies that the funds have in fact gone to the specified location, it Decides the contract in favour of the Pump.

If the Client doesn't pay the contract, the Pump just doesn't send the COMB to the address. If the Pump doesn't send the comb to the address, the Contractor decides in favour of the client, and the funds go to the clients backup address!!! The Pump can only accept the amount of COMB in contacts per cycle that it has on hand, as it's required to prepay all the contracts before they'd be settled in the Pump's favour.

Let me know if I've fucked anything up. I think this'll work. The integration with the BTC chain means that you wouldn't even have to rely on an oracle system I think. Let me know if I've gone full schizo here lol.

EDIT: I can't make up my mind about which sounds better, Pump or Turbine. Pump is more apt mechanically, but, as it was pointed out to me, isn't great in a financial connotation. Turbine also suggests automation, whereas Pump does not, and Turbine sounds grandiose and cool.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 19, 2021, 03:54:48 PM
I've been thinking a lot about how to remove a 3rd party from COMB/COMB swaps, and while I can get close, I can't figure out a way to solve one final issue.

The methodology I've been using relies on adding a new object type to the programming of COMB. Right now I'm calling them Witnesses. The way a Witness would function is similar to a Decider/Contract, however rather than trigger based off of the Decider signing a number to determine the destination of the funds, a Witness would trigger off of witnessing another event take place. Let me explain via example.

Alice and Bob want to perform a COMB for COMB swap. Alice first creates a Decider/Contract (dc_1) where she is the decider, and the contract addresses are: forward = bob_2, rollback = alice_2. Alice pays her COMB into dc_1, and then sends Bob the transaction history proving that the Decider/Contract is valid and that she has funded it. Bob then creates a Witness. I haven't figured out the exact syntax yet, but it would need to include a forward address, a rollback address, and the object address that it was witnessing. In this case those details would be forward = alice_2, rollback = bob_2, and witnessing = dc_1. Bob then pays his COMB into witness_1. Bob sends his transaction history to Alice. Alice then sees that a witness_1 is both funded and is witnessing dc_1. She now decides dc_1 as FORWARD.

When she decides dc_1, she commits the sign number to the BTC chain in the form of the two bc1 addresses. If I'm not missing anything, the Witness will be able to see this, and verify, using the information that Alice has, that dc_1 has been signed FORWARD, and will ALSO act as if it has been signed forward. This will release the funds on witness_1 into alice_2. Then Alice sends the TX history to Bob, and once he has it he'll have enough information to verify how the Decider was signed, and he'll get the funds out of the Decider.

There's a problem though. What if Alice is an asshole, and decides to just not give Bob the TX history after she's signed the Decider and gotten the COMB out of the Witness? She doesn't actually gain anything extra from this, but a malicious actor could screw over their counter-party by dong this.

This is the problem I don't have a good solution to. However, there may bee some financial trickery that can get "around" this problem. I'll make a post a little later once I've fleshed it out. Also keep in mind I have no idea of the feasibility or mathematically implications of including more objects into the Haircomb code. If I've missed any potential problems here, let me know.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 19, 2021, 11:24:10 PM
The idea I had before to circumvent the problem didn't pan out, but I think I have a different solution. Rather than use a Decider/Contract and a Witness, you would use two Paired Witnesses. The Paired Witnesses would also utilize a hash based lock and key, where SHA256(key) = lock.

A Paired Witness would be constructed using the following steps.

1. pwit_id = SHA256(forward, rollback, lock)

2. address = SHA256(pwit_id, target)

In place of the target you would fill in the other Witness ID in the pairing, i.e. pwit1_add = SHA256(pwit1_id, pwit2_id), pwit2_add = SHA256(pwit2_id, pwit1_id)

The information that both parties would get, in addition to the transaction info proving the counterparty's deposit of funds into the counterparty's generated pwit_address, would be the information making up the counterparty's pwit_address, i.e. forward, rollback, lock, and target. A user could then confirm that the counterparty had deposited funds into the address that was Paired with their Witness. In order to unlock a Witness, the Witness's Key must be committed to the BTC chain, as well as the key to the other Witness that it has been paired with. Due to the simplicity of the lock, it would be easy to determine the key just by looking at the committed P2WSH addresses on the BTC chain if the counterparty decided not to send you the TX information proving that they had committed the Key. And said counterparty MUST commit the key, because otherwise their funds remain in the Witness.

Currently the structure doesn't use the rollback address, however it can be used if you give either party a method of terminating the swap. The first method that comes to mind would be using another lock and key, and detecting which one came first on the BTC chain, but there are certainly others, and I haven't thought about which would be better.

Let me know if something I've described wouldn't work.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 20, 2021, 04:32:07 PM
I've combined the above three posts into an idea. If this works, it would reduce the cost of transacting on the BTC chain from 21 transactions down to (21+X)/X, where X is the amount of transactions being batched together. It would also be done in a completely trustless manner, without the use of third parties. First I will establish the two new COMB objects that are required to make this work. Note: It is possible to accomplish the same structure of motion in the current system, however it costs (21+2X)/X, and relies on trusting a 3rd party.


Objects Required

-- Witness
A Witness would operate similarly to the previously described Witnesses. This Witness would act as a Paired Witness, but rather than being paired up with another, corresponded Witness, it would be targeting something called a Lockbox. The information a Witness would require is a forward address, a rollback address, and the target address (the address of the Lockbox it is Witnessing)

-- Lockbox
A Lockbox will operate similarly to the previously described Paired Witness, in the manner that it uses the same Lock/Key system that the Paired Witness uses. You can think of it as essentially a mini Decider; rather than 65355 destinations, a Lockbox has 2. Because the Lockbox only has 2, we can sign the Lockbox using a single commit. The Lockbox would be made up of a forward address, a rollback address, two locks, a YES lock, a NO lock, the height of the BTC block at which the Lockbox becomes valid, and optionally the height of a BTC block that the Lockbox expires on. To unlock a Lockbox, the controller would commit one of the two keys to the BTC chain. If the controller commits both Keys, the Key that appears on the first BTC block will be considered valid. If they both appear on the same block, then YES lock will be considered valid. If a Key appears on the blockchain before the stated start_block, it will be discounted, and only the other Key will be a valid commit. If an expiry block is specified and subsequently reached without any keys being committed, it will act as a NO key sign.


Walkthrough

A Client wishes to send funds using a turbine. They send their funds to a Lockbox, the address of which is built from SHA256(turbine_1, client_2, yes_lock, no_lock, start_height, expiry_height) . The Client then sends their transaction history to the Turbine, proving that their funds have been deposited into lockbox_1. First, if the current BTC height is greater than the stated start_height, the Turbine most check each of the previous blocks between then and now, to confirm that a Key has not already been signed during this time. The Turbine then creates a Witness, built from SHA256(client_2, turbine_2, lockbox_1). The Turbine deposits the same amount of funds into witness_1 that the Client has deposited into lockbox_1, and sends the Client the information proving it. Once this has been establish on the Client's end, the Client commits lockbox_1's YES key to the BTC chain. Due to the ease of calculation, whether the Client ends up being a good guy and sharing the information with the Turbine is irrelevant, the Turbine should be able to deduce the the Lockbox's status simply by trying P2WSH addresses from the BTC chain until one fits the lock, and then trying the rest of the Keys on the block until it can confirm that 1 or two keys were committed on this block, and can move forwards from there.

Here is a diagram of the process: https://i.imgur.com/TR67aWN.png


You may say that this does not reduce costs, because a Client must pay to put their funds into the Lockbox. However, this only needs to happen once, on initial Turbine cycle entry. They can specify a Turbine address, and no matter how many cycles go by before they initiate a contract with the Turbine, the funds will always flow to the currently active Turbine wallet. When a Client initiates a contract with a Turbine, they can specify that they want the destination of their funds to be a Liquidity Stack, the OUT address being a payment they wish to make, but the CHANGE address being directed to ANOTHER Lockbox. The Client should also specify a Merkle tree as the output of their Lockboxes, one that has options to go to other Turbines in case there's a problem with this one in the future, or to a private wallet as a final backup measure. By chaining Lockboxes together, after the initial transaction from a Private Wallet to a Lockbox, each additional transaction will only require one BTC commit, so long as the Client continues to go Lockbox->Turbine->Lockbox->Turbine. Each cycle that they participate in, they have the opportunity to make payments.


One hiccup in the scheme is that a Client will no longer be able to receive funds or claim COMB on their old, private wallets. They will have to give other parties the address of the current lockbox they are waiting in, and once they initiate an atomic swap with a Turbine they will have to begin receiving funds into the new Lockbox address.

Another potential weakness, albeit an odd one, is if a malicious Client decides to suicide-bomb the Turbine. If the Client deposits X funds into a Lockbox with no expiry height, and the Turbine then deposits X funds into a Witness targeting that Lockbox, the Client has the option of just never signed either key. This will cause both the Turbine and the Client to lose access to X funds. The Turbine can avoid this possibility however, if it decides to only accept contracts with people who's funds are in a Lockbox that has a defined expiry height.


I don't know if this will work yet, because there are areas of operation that I am not currently educated enough on to understand. Will this require too much processing? The amount can be reduced by storing the Key's address with the history of the lockbox in the wallet, once the operation has been concluded, however future wallets would need to confirm that the other key was not signed in between the start height of the contract and the height of the committed Key. I also don't know enough about the processing of COMB objects internally, i.e. why Decider/Contracts use different number system. I'm assuming it's because they are not supposed to have COMB deposited into them, and so it differentiates them from addresses that ae supposed to have COMB deposited into them, but I'm not sure, so it's a variable I have to consider.


If, however, this WOULD work, it would open up a ton of possibilities I think. The fact that you could have multiple Witnesses all witnessing a single Lockbox seems like it would be a VERY powerful tool, though I have not thought about how it could be used yet.

If anybody can confirm or deny that this would work, I would appreciate it.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on February 22, 2021, 12:52:01 PM
If hard fork is an option, I think the same basic goal of reducing the 21 addresses in many cases can be reached differently:

Hot cash address.

Hot cash address can be SHA calculated from a secret fallback address and an enough decider to sign 16 bits.

Hot cash address operation.

If the user signs 16 bit signed number zero the system flows the coins from the hot cash address to the fallback.

If the user signs a non zero value n: the money will flow to the n-th address that was commited to on chain
after the fallback address was commited to on chain. (or before if n is negative)


Hot cash paying

1. the user who owns funds on a hot cash address commits the fallback address to the chain to start the relative offset period.
2. the user commits the liquidity stack commitment where the user wishes to pay.
.. wait 6 confirmations ...
3. the user subtracts the relative positions of the two previous commitments: n = position2 - position1, and signs n, if n fits in a 16 bit signed int.
.. wait 6 confirmations ...
4. funds are now paid to the liquidity stack.


This would cost 4 addresses funded per hot cash cycle.


Possible problems:
 - the user does not wait 6 confirmations & attacker manipulates the relative order
   - result: all funds stolen
   - solution: wait longer
 - the attacker manipulates the order to make the distance |n| greater than 32767
   - by inserting your 2 commitments into their transaction(s) that confirm before yours and in which the values are more apart
   - result: transaction does not go through
   - solution: sign 0 to go to fallback / replace by fee outbid the attacker



The advantage could then be that the user needs not to approach another player in the form of turbine, can do everything purely alone.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 22, 2021, 06:01:57 PM
That's a pretty cool way to de-couple destinations from their direct address, using block order. It's slower than Turbines (unless my walkthrough is incorrect), and more expensive, but the fact that you can do it solo and aren't merging TX histories with everybody in the cycle is a huge upside, not to mention the potential problems of a Turbine going down in an ecosystem that's still building to multiple Turbine options. The fact that no infrastructure is required is huge.  What do you think about centralized wallets in general, hard fork or not? I feel like if they're an inevitability due to the convenience and 0 TX fees, not everybody cares about security and privacy, and that it makes sense to try and make options for them that are as secure and convenient as possible.

Looking at the current extrapolation of Haircomb with no forks, if you agree that Turbines would be inevitable then we're looking at

a) 4 commits per semi-safe transaction (My_Funds->My_Decider(Store Here), My_Funds->Oracle_Decider, Turbine_Funds->My_Destination, Oracle_Decider_Funds->Turbine.)
b) 2 commits per less-safe transaction (My_Funds->Oracle_Decider(Store Here), Turbine_Funds->My_Destination, Oracle_Decider_Funds->Turbine.)
c) 0 commits per not-safe transaction (Permanent Turbine Storage).

So the core ecosystem would require trust to participate on a frequent basis. I think that forks make sense in this case, introducing other options could go a long way.

Do you think there's a way that, if forked, we could update Haircomb without needing to fork again? The problem is ofc that a wallet needs to process every transaction in the chain, so backwards compatibility can't work like BTC, but do you think there's a way to circumnavigate it? I have some ideas but they aren't mature yet.

EDIT: Thinking about it more, I really can't stress enough the benefit of 0 infrastructure. Turbines will take AGES to get up and running properly, and they'll rely extremely heavily on the surrounding environment. Hot Cashes Addresses will be way easier to implement, and helping bridge the gap to the point that Turbines are actually working will be enormous. And even then, if you value your independence the extra fee may very well be worth it, depending on the price.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 24, 2021, 04:06:59 AM
I've been thinking a lot about how to avoid hard forks in the future, and I might have a solution. It's too early to tell. The problem with backwards compatibility in Haircomb is that it's impossible with a system based on static smart contracts; if a client doesn't have the smart contract for a history, they can't import it. How do you provide new code to a Haircomb client, while also keeping it completely anonymous, and only ever speaking with the BTC chain??


Do

This is a theory demonstration for Do, a programming language that consists of smart contract code hidden within the BTC blockchain. This fork to introduce Do would introduce a new wallet entry /type, /contract. When a wallet runs into the /contract code, it would check to see if it currently had the contract code compiled in its database. If it did not, it would find the contract code, located on the BTC block chain, and pull and compile it. It could then process and understand the transaction. The methodology for storing Do on the BTC chain is as follows.

1. Write a Do contract. The contracts can be written using native functions that are contained within every Haircomb client, such as math functions, SHA256, or GetCommit related functions. They can also be written by referencing other custom contracts that have been created.

2. Get the contract's ID. This is created by concatenating a nonce and the script of the contract.

3. Build the commits necessary to commit the code to the BTC chain. It's easier to show an example than to explain:

Code:
ID = SHA256(  NONCE if A > B:  )
code commits:
SHA256(ID + if + 0)
SHA256(ID + A + 1)
SHA256(ID + > + 2)
SHA256(ID + B + 3)
SHA256(ID + DO + 4)
SHA256(ID + END + 5)

While it is obviously incomplete code, you can see the commit process in action. Concatenate the contract ID, the chunk, and the chunk index, then SHA256.

4. Once the contract commits have been generated, commit them to the BTC chain. They must be committed in index order.

5. When a Haircomb client that does not know this script receives a TX history that contains it, it searches for the location of the contract ID on the chain. This marks the beginning of the contract. Haircomb then begins checking each consecutive P2WSH address in the BTC chain, and for each one it check if the address = SHA256(ID + WORD + INDEX) The ID is the contract ID, the INDEX is the current chunk index, and the WORD is the current keyword that is being checked. It runs this script for each keyword it knows, on each P2WSH, until it finds a correct answer. In the above example it would find that SHA256(ID + if + 0) == currently tested address. Then it adds 1 to the INDEX value, and repeats. It does this until it finds the WORD END, at which point it knows the script has finished.

In order to embed contracts within other contract code, we can't reference them by ID. If we did, Haircomb would never be able to guess them, because their ID is a random 256bit number. Instead, we can reference them using a native function called BuildGetObject(index, args). Index is the index of the contract ID, and args is an array with the arguments used to build that function when the code is actually being processed (I'll explain shortly). Because all Haircomb nodes know BuildGetObject, they know that the first argument of BuildGetObject will be the index of an Object they need to get.  NOTE: During this reading, if you see a reference to another object written during build func as simply something like Object(args), know that in practice it would be committed as BuildGetObject(index, [object_args]).

I'll refer to the main script as a Contract, and the thing it creates during processing as an Object. Some rules for Objects:

Objects have variable CONNECT_TO, it is an address, if any, that their funds flow into down the chain
Objects have variable ACTIVE, when active if they are payed funds they call their run(), if inactive they pay the funds to their CONNECT_TO address and skip their run() code.
Objects have an AMOUNT, which is how much COMB they currently have stored. Only relevant in some cases
Objects are built in build code by referencing their Contract ID location on chain, and are run in run code by referencing the individual instance of the built object.
If an Object finishes run() and it has a CONNECT_TO address, it automatically sends all of its funds there.

Some example of native functions might be:
Code:
SHA256(content):
returns the hash of content

GetCommitHeight(address):
returns the height of the address, if it exists. If not, return 0

GetCommitIndex(address):
returns the index of the address if it exists. If not, return 0

GetCommitsByHeight(height, height):
returns all unseen P2WSH in between the two heights

GetCommitsByIndex(index, index):
returns all unseen P2WSH in between the two indices.

PayTo(dest, amount):
Subtracts amount on funds and puts them in the destination. If the dest.AMOUNT < amount, this function will NOT fire. Not needed on
        standard, 100% payments, just use CONNECT_TO

BuildGetObject(index, [args]):
Gets the ID of the references contract, and if it isn't already compiled in storage, compile it. Then build with it. Store with its index.

A bunch of Math functions (+, /, >, etc.)

Note: This next part I'm sketchy about, as I don't know if Haircomb uses temporal methodology like I have laid out here, or if it uses an algorithmic, atemporal process. If it does though, I have 0 idea how it deals with liquidity stacks then, but if I can figure it out I can easily convert this into an atemporal system. A temporal system feels like it'd be super slow, so I'm hoping I'm wrong here

When a wallet is processing a TX history, first it initializes the all the transactions in the history as objects. Next, it spawns the combbase. As the comb trickles into an object, it will trigger the run(x) function, where X = the amount of comb that has entered the object. Once the object's run() has completed, if the comb can trickle further it will, trigger more run(), until finally it cannot trickle any more. Then the next combase will trickle, and so on, until no comb can trickle further.

I have built some already existing and or theorized Haircomb contracts to show an example. When I use the syntax struct, I am referring to an array of values that is created directly from the build() function arguments. Struct as in structure.

1. Liquidity Stack
Code:
build(int256, int256, int64) #change_add, send_add, send_threshold)
run(int64):
AMOUNT += run[0]     # Increase stored amount
if AMOUNT > struct[2]:     # If stored > threshold
execute([struct[0], struct[1], struct[2], AMOUNT])     # send COMB

execute(args):
PayTo(args[1], args[2])
ACTIVE = FALSE
CONNECT_TO = args[0]

2. Hot Cash Address (Decider is built with left_object, tip1, tip2)
Code:
build(int256, Decider.build(int256, int256, int256), [int16, int256, int256])     # Fallback, decider(), longdecider, unCAT
run(int64):
AMOUNT += run[0]
if struct[1].run(struct[2]):     # If signature checks out
if struct[2][0] == 0:
execute(struct[0])     # If signed 0, fallback
else:
execute(struct[2][0])     # Go forward

execute(args):
CONNECT_TO(args[0])
ACTIVE = FALSE

3. Lock
Code:
build(int256)
run(commit):     # commits are sent as [commit, index]
if SHA256(run[0][0]) == struct[0]:     # If key
execute([TRUE])

execute(args):
return args[0]

4. TimedLockbox
Code:
build([int256, int256], [Lock.build(keyhash), Lock.build(keyhash)], int32, int32)) 	
run(int64):
AMOUNT += run[0]
for commit in GetCommits(struct[2], struct[3]):
if struct[1][0].run(commit[0]):     # Run NO Lock with commit[0], if NO key found
for this_commit in GetCommits(commit[1], commit[1]):     # Check for YES in rest of block
if struct[1][1].run(this_commit[0]):     # If YES in same block
execute(struct[0][1])     # YES
else:
execute([struct[0][0]])     # NO
elif struct[1][1].run(commit[0]):     # Run YES Lock with commit[0], if YES key found
if not commit[1] > struct[2]+1):     # If not greater than first block
execute(struct[0][1])
else:
for this_commit in GetCommits(struct[2]+1, commit[1]-1):     # Check prev height commits
if struct[1][0].run(this_commit[0]):     # IF NO before
execute(struct[0][0])     # NO
else:
execute(struct[0][1]  )   # YES

execute(args):
CONNECT_TO = args[0]
ACTIVE = FALSE

I'm not a good enough coder to know if this'll work yet. But it seems like the logic is there. If we can break everything down into tiny pieces, we can open up the door for completely open-sourced creativity. Anybody could make any contract they wanted to, and if they completely mess up, they'd just be losing their money. And if we did it right, there'd never need to be a fork again.

Let me know how you think this could be attacked or exploited. I don't know enough yet to know if this will really work, but thinking about what it could accomplish if it did makes me want to try.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 24, 2021, 04:26:42 PM
Some more thoughts:

1. I just used whitespace as syntax because that's what I'm used to, it makes more sense to use brackets IMO.

2. Modifying the AMOUNT from within an object's run() is moronic, that's a function that needs to be 100% under the control of the Haircomb Client; you'd PayTo(dest, amount) from object_A, and then the dest object would get its AMOUNT credited by Haircomb and then run.

3. I think it makes the most sense to modify all inherent variables using a native function.

Modified Liquidity Stack example:

Code:
build(int256, int256, int64) 
run(int64){
if (AMOUNT > struct[2]){
execute([struct[0], struct[1], struct[2]])
                }
}

execute(args){
PayTo(args[1], args[2])
SetActive(FALSE)
ConnectTo(args[0])
        }
     

I think it makes sense to include the amount that was paid to the Object as an argument in run(), as it opens the doors for contracts that could be based on the size of an individual payment.

While it's impossible to actually calculate the cost of committing a contract yet as there's a lot to be worked out with what information the interpreter would need or not need, looking at the Liquidity Stack code you can get a guess of 69 commitments total.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on February 25, 2021, 12:58:21 PM

Code:
GetCommitsByHeight(height, height):
returns all unseen P2WSH in between the two heights

GetCommitsByIndex(index, index):
returns all unseen P2WSH in between the two indices.
   

These two are BAD. Too slow - if someone requests the complete range in a buggy contract to make a wallet killer contract.

You must instead ask the prover to give you a specific example commitment as a free variable (that you would
otherwise be searching using the for loop) and check the height or position of it. This is why I think that for loops should be banned.


Making time/height locks in general should be banned as they cannot be enforced by consensus in principle due to slippery slope.



Another bug that can't occur is balance instability. No matter in what order you load
the history, you should see the same account balances. Therefore implementing custom (possibly wrong) liquidity stacks should be banned.

Also some kind of bugs in the contract can't be tolerated - such as double spending.
One tiny double spend hole could collapse the entire currency. Thus making a custom haircomb (possibly wrong) primitive too should be banned.


That said I am hopeful that the general idea will be good in the end. Something like this perhaps.


Merkle transaction:

Code:
ARGCOUNT = 21
ADDRESS = SHA256(SHORTDECIDER(ARG[1...3]) CAT ARG[21] )
CONDITION = ENTRENCHED_DECIDER(ARG[2...3]) && ARG[21] == MERKLE_ROOT(DECIDER_SIGNS(ARG[2...3]), ARG[4...20])
CONNECT_TO = ARG[1] == 0 ? ARG[20] : MERKLE(ARG[1], ARG[20])

Hot cash:

Code:
ARGCOUNT = 4
ADDRESS = SHA256(ARG[1...3])
CONDITION = ENTRENCHED_DECIDER(ARG[2...3]) && (DECIDER_SIGNS(ARG[2...3]) == 0 ||
((ENTRENCHED(ARG[1]) && ENTRENCHED(ARG[4]) && DECIDER_SIGNS(ARG[2...3]) == (CHAINPOSITON(ARG[4]) - CHAINPOSITON(ARG[1])))))
CONNECT_TO = DECIDER_SIGNS(ARG[2...3]) == 0 ? ARG[1] : ARG[4]

Some kind of lock:

Code:
ARGCOUNT = 4
ADDRESS = SHA256(ARG[1...4] )
CONDITION = ENTRENCHED(ARG[1]) || ENTRENCHED(ARG[2])
CONNECT_TO = (ENTRENCHED(ARG[1]) && ENTRENCHED(ARG[2])) ?
(CHAINHEIGHT(ARG[1]) < CHAINHEIGHT(ARG[2]) ? ARG[3] : ARG[4] ) :
(ENTRENCHED(ARG[1]) ? ARG[3] : ARG[4] )



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 25, 2021, 04:26:29 PM

Code:
GetCommitsByHeight(height, height):
returns all unseen P2WSH in between the two heights

GetCommitsByIndex(index, index):
returns all unseen P2WSH in between the two indices.
   

These two are BAD. Too slow - if someone requests the complete range in a buggy contract to make a wallet killer contract.

You must instead ask the prover to give you a specific example commitment as a free variable (that you would
otherwise be searching using the for loop) and check the height or position of it. This is why I think that for loops should be banned.

Oh crap, yeah that's garbage.

Quote
Making time/height locks in general should be banned as they cannot be enforced by consensus in principle due to slippery slope.

I'm not sure what you mean by this. My understanding was that the Haircomb client would have to be able to tell what block a commitment was on, in order to spawn the COMB to 1 address per block. Is this incorrect? Does the client just get the BTC to tell it which address was the highest in the block, and then discard that information? I think I'm missing your point entirely here.


Quote
Another bug that can't occur is balance instability. No matter in what order you load
the history, you should see the same account balances. Therefore implementing custom (possibly wrong) liquidity stacks should be banned.

This is what I meant by atemporal vs temporal. How does the basic Haircomb client handle liquidity stacks then? I haven't been able to figure it out. I would've phrased the code in an atemporal way if I had known how to fit LStacks in with that methodology.

A shell could be written to process in a temporal way though, I think. You'd load all the objects into the shell at once, and then loop through over and over until the funds couldn't trickle any more. That seems like garbage though.

Quote
Also some kind of bugs in the contract can't be tolerated - such as double spending.
One tiny double spend hole could collapse the entire currency. Thus making a custom haircomb (possibly wrong) primitive too should be banned.

So you think it's too risky? There are too many bug possibilities? The way I had it laid out to prevent double spending was to run everything through a native shell within the Haircomb client that would do all the processing and currency motion. I didn't see how you'd be able to write a contract that could cause a double spend in that instance, the shell would know the balances of each object within it, because it did all the math to determine them based on the COMB spawns. If an object requests a transaction that doesn't mathematically make any sense to do, then the shell won't do it, and will break with an error. I was hoping keeping everything completely compartmentalized would work in this regard.

Hell, with an atemporal system, the objects wouldn't even be able to request fund transfer at all; it'd just be them connecting to each other. Then the shell spawns the COMB and calculates the trickle.


Quote
That said I am hopeful that the general idea will be good in the end. Something like this perhaps.


Merkle transaction:

Code:
ARGCOUNT = 21
ADDRESS = SHA256(SHORTDECIDER(ARG[1...3]) CAT ARG[21] )
CONDITION = ENTRENCHED_DECIDER(ARG[2...3]) && ARG[21] == MERKLE_ROOT(DECIDER_SIGNS(ARG[2...3]), ARG[4...20])
CONNECT_TO = ARG[1] == 0 ? ARG[20] : MERKLE(ARG[1], ARG[20])

Hot cash:

Code:
ARGCOUNT = 4
ADDRESS = SHA256(ARG[1...3])
CONDITION = ENTRENCHED_DECIDER(ARG[2...3]) && (DECIDER_SIGNS(ARG[2...3]) == 0 ||
((ENTRENCHED(ARG[1]) && ENTRENCHED(ARG[4]) && DECIDER_SIGNS(ARG[2...3]) == (CHAINPOSITON(ARG[4]) - CHAINPOSITON(ARG[1])))))
CONNECT_TO = DECIDER_SIGNS(ARG[2...3]) == 0 ? ARG[1] : ARG[4]

Some kind of lock:

Code:
ARGCOUNT = 4
ADDRESS = SHA256(ARG[1...4] )
CONDITION = ENTRENCHED(ARG[1]) || ENTRENCHED(ARG[2])
CONNECT_TO = (ENTRENCHED(ARG[1]) && ENTRENCHED(ARG[2])) ?
(CHAINHEIGHT(ARG[1]) < CHAINHEIGHT(ARG[2]) ? ARG[3] : ARG[4] ) :
(ENTRENCHED(ARG[1]) ? ARG[3] : ARG[4] )

So how do you see nested objects and returns working? Or do you not? My hope was that it'd be possible to take previously committed contracts and include them in your new contract by reference. Maybe I'm misunderstanding your code. I'm interpreting ENTRENCHED(ARG) as a function to check if the ARG is an address that has been committed on the chain. Ergo CHAINHEIGHT() is a function to check the height of an address that has been committed. These make sense to be included as native functions. What I don't understand is your use of ENTRENCHED_DECIDER(), whether it's being called as a native function or as a reference to a custom, previously committed function.

EDIT: After going over it a few more times it looks more like you're using ENTRECHED_DECIDER() as a reference to custom object, I was just thrown off at first. Something I realized is that we can (I think) implement multi-sig transactions via a Locking mechanism. The syntax you have listed would need to be broken down into a more basic TRUE/FALSE return object as a lock, but it can then be combined with another object. I'll try to type it up, but my syntax might be borked, so no judgement lol. I also have no idea what the way to phrase RETURN would be, so I'm just going to label it as RETURN = for now.

So the lock would be like
Code:
# Either Key_NO (1) or Key_YES (2) committed
# if both committed: if Key_NO has a smaller index than Key_YES (aka it's higher) return FALSE, else return TRUE
# else if just Key_NO is commited, return FALSE, else return TRUE

ARGCOUNT = 2
ADDRESS = SHA256(ARG[1, 2] )
CONDITION = ENTRENCHED(ARG[1]) || ENTRENCHED(ARG[2])
RETURN = (ENTRENCHED(ARG[1]) && ENTRENCHED(ARG[2])) ?
(CHAINHEIGHT(ARG[1]) < CHAINHEIGHT(ARG[2]) ? FALSE : TRUE ) :
                (ENTRENCHED(ARG[1]) ? FALSE : TRUE )

You could inject this into something like a Hot Cash contract, to create a Multi-Sig Hot Cash contract. The Hot Cash must both be signed normally, and have the lock signed as yes. If the lock is signed as no at any point, whether the Hot Cash has been signed or not, the funds go to the Fallback Address. You can add on multiple Locks too, if any of them are signed No then fallback, if half of them are signed No, w/e, it's up to you to use the contract that fits your needs. I'm having a little trouble deciphering the exact semantics of the Hot Cash code here, but when I figure it out I'll post a Multi-Sig version.

Breaking the Lock up like this also, by happenstance, would allow it to act as a CHAINHEIGHT comparison object lol. You wouldn't code it into a future contract, you could just use ENTRENCHED_LOCK(ARG1, ARG2) ? STUFF : OTHER_STUFF.

If you're worried about the temporal bit, just remember that the child contracts wouldn't be listed in the TX history as a separate object. They'd get loaded and processed at the same time as their parent.

What do you think about assigning variables for use within an object? You could have contracts that return multiple variables that way. Or do you think that that's being lazy?

EDIT2: I just realized the problem with the Lock script is that it doesn't use the bruteforce method to allow another party to open it even if they aren't given the TX history. This means it can't be included as a sub-object of another object, at least not as is, because in order to prove that you'd payed the funds into the contract you'd have to give the counterparty the keys to the lock so they could build the contract address and confirm you'd payed to it. It can't even be used as a mini-decider, because again, in order to prove to the counterparty that the address you payed into was indeed a Lock, you'd need to give them the keys to it in order for them to build the address, so they could just commit said keys for whatever answer they wanted.

Could we do range pulls if there was a hard range that the client would accept? So if you went to make a Lock contract, and tried to specify a range of activation that was further than the hard limit, the client would just say no. And if someone hacked together a TX history that had a Lock with a range that was too long, the receiving client would just refuse to process it. If you ran all requests for a range through a client based function, then you could hard cap the range pull, couldn't you?

EDIT3: And I realized again that you could just make a TX history with a bunch of range pulls in a row or something. Alright, I guess there'll have to be a different way to atomic swap.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on February 25, 2021, 09:44:27 PM
slippery slope for decentralized time-locks

1. suppose you have invisible but time-locked 1 COMB that goes to your address "A" in year 2100
2. you mod your wallet to see 1 TIMELOCK_COMB in address A
3. other impatient users likewise mod their wallet to see their own TIMELOCK_COMB
4. now the group of impatient users can start trading TIMELOCK_COMB among themselves
5. TIMELOCK_COMB accepted by all just like a normal COMB.
6. 1 TIMELOCK_COMB = 1 COMB
7. most users just mod their wallet and rename TIMELOCK_COMB to COMB. Timelock no longer exists.

Now certainly time-locks are possible but only if you agree the funds will be nuked if spent prematurely. That does not
sound like a safe primitive.

Another way to have time-locks is to have a central party to generate liquidity stacks to a provided addresses used as CHANGE and
using true random number as OUT, and zero as TRESHOLD, and the central party just reveals the OUT later (at the specific time).


balance stability proof - very boring  ;D


no matter in what order you're adding spends and stacks, if you flow the money after every new add, after
you're done adding those edges, the trickling will converge at the same final balances.

1. For no stacks, it's fairy simple. There's no way to split money so money can only merge or stay separated or
flow in loops which cause it to self destruct or the money just reaches the final destinations along the payment edges
(once you add all your edges - no matter in what order).

2. For every stack that got triggered we can just imagine there is no stack but replace the stack with an additional
combbase creating it's threshold in the
OUT address, plus a "minus threshold" special combbase in SOURCE, plus a normal SOURCE -> CHANGE payment edge. Then the
rough proof from step 1 applies.

3. For every stack that did not get triggered, well, there is no edge. The STACK SOURCE just acts like a
final destination for funds.


Lastly:

I'm sorry for just using argument numbers in my code. I could've used relevant variable names.

If you wanna pay Alice 5 bux from your contract you simply CONNECT_TO liquidity stack SHA256(CHANGE CAT ALICE CAT 5 BUX).

This way you can "invoke" any number of subcontracts by CONNECT_TO their respective addresses or a stack of them.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 25, 2021, 10:03:42 PM
slippery slope for decentralized time-locks

1. suppose you have invisible but time-locked 1 COMB that goes to your address "A" in year 2100
2. you mod your wallet to see 1 TIMELOCK_COMB in address A
3. other impatient users likewise mod their wallet to see their own TIMELOCK_COMB
4. now the group of impatient users can start trading TIMELOCK_COMB among themselves
5. TIMELOCK_COMB accepted by all just like a normal COMB.
6. 1 TIMELOCK_COMB = 1 COMB
7. most users just mod their wallet and rename TIMELOCK_COMB to COMB. Timelock no longer exists.

Now certainly time-locks are possible but only if you agree the funds will be nuked if spent prematurely. That does not
sound like a safe primitive.

Another way to have time-locks is to have a central party to generate liquidity stacks to a provided addresses used as CHANGE and
using true random number as OUT, and zero as TRESHOLD, and the central party just reveals the OUT later (at the specific time).


balance stability proof - very boring  ;D

This makes sense. I guess they'd just forge P2WSH sigs in their wallets, and then replace them with real ones as the real ones were created. That's actually pretty funny lol.

Quote
no matter in what order you're adding spends and stacks, if you flow the money after every new add, after
you're done adding those edges, the trickling will converge at the same final balances.

1. For no stacks, it's fairy simple. There's no way to split money so money can only merge or stay separated or
flow in loops which cause it to self destruct or the money just reaches the final destinations along the payment edges
(once you add all your edges - no matter in what order).

2. For every stack that got triggered we can just imagine there is no stack but replace the stack with an additional
combbase creating it's threshold in the
OUT address, plus a "minus threshold" special combbase in SOURCE, plus a normal SOURCE -> CHANGE payment edge. Then the
rough proof from step 1 applies.

3. For every stack that did not get triggered, well, there is no edge. The STACK SOURCE just acts like a
final destination for funds.


I still don't understand, this all sounds like temporal phrasing. To me "did not" implies you let the funds converge there, and see what happens, then response accordingly. If you load a random liquidity stack in the middle of the contract and then never come back to check it after loading the other pieces, how would you know whether it got enough funds to trigger? If this is the methodology that's used, then the proposal in my first post seems like it would still fit in with this; you load all the pieces in their correct placements, then spawn COMB in a spawn stack. Every time COMB enters an object, it would trigger that object's run(). I don't see how that's different from this description.

Quote
Lastly:
I'm sorry for just using argument numbers in my code. I could've used relevant variable names.

If you wanna pay Alice 5 bux from your contract you simply CONNECT_TO liquidity stack SHA256(CHANGE CAT ALICE CAT 5 BUX).

This way you can "invoke" any number of subcontracts by CONNECT_TO their respective addresses or a stack of them.

Would you be willing to re-label the example Hot Cash using specific terminology for the ARGs that would be used? Even if it's just adding an ARG1 = X, ARG2 = y, etc. at the top.

EDIT: Also, by sub-contracts I didn't mean further down the chain, I meant nested within the main contract. I detailed some examples of use-cases of these, in order to reduce the amount of commits you need to store the code on the BTC chain, or to do stuff like Multi-Sig.

EDIT2: The thing that I can't wrap my head around about your syntax is that there's no separated build and run phase. I can't figure out how someone is supposed to verify that funds have been paid into an address that is composed of what the payer SAYS it is. Your syntax only has the option to completely execute on an object and have its funds go somewhere; what if I want to verify that something will happen if I do something else? I'd want to be able to import information about the payment to an object, without receiving the information that'd trigger the object. I don't see how this can be accomplished simply with the way you've laid things out.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on February 26, 2021, 11:23:33 AM
Buggy primitive: coin halver

Code:
run(int64){
AMOUNT += run[0]
execute(DESTINATION1, FLOOR(AMOUNT/2), DESTINATION2, CEILING(AMOUNT/2))
}

execute(args){
PayTo(args[1], args[2])
PayTo(args[3], args[4])
}


Proof that this coin halver is buggy (there is no final balance stability):

1. Load first history entry that pays 0.0000001 COMB to coin halver
2. Load another history entry that pays 0.0000001 COMB to coin halver
3. Load coin halver
4. ???
DESTINATION1 = 0.0000001  COMB
DESTINATION2 = 0.0000001  COMB


1. Load first history entry that pays 0.0000001 COMB to coin halver
2. Load coin halver
3. Load another history entry that pays 0.0000001 COMB to coin halver
4. ???
DESTINATION1 = 0.0000000  COMB
DESTINATION2 = 0.0000002  COMB


Now it is not true that only the inventor of a buggy primitive loses money, what's worse that
the inventor will defraud others. In this case by sending history 1 to the DESTINATION1 user
and by sending history 2 to the DESTINATION2 user. Collectively they will see more money than there is.

This is why we need to be proving final balance stability and other virtuous properties about every
new primitive added to the currency.

We need to prove that (except on chain reorgs):
a. CONDITION can change to being TRUE only after being FALSE. (Or CONDITION be TRUE all the time)
b. if CONDITION is TRUE, CONNECT_TO address calculated cannot suddenly change. This means it must be impractical
   to come up with two DISTINCT argument vectors so that ADDRESS1 == ADDRESS2 and CONDITION1 == CONDITION2 == TRUE and
   CONNECT_TO1 != CONNECT_TO2



Fixed the hot cash.

Code:
ARGCOUNT = 6
256bit ARG[1] = Fallback address
256bit ARG[2] = Value at the end of the hashing sequence (to sign with the left leg of the decider)
256bit ARG[3] = Value at the end of the hashing sequence (to sign with the right leg of the decider)
256bit ARG[4] = Destination address.. A free variable (not hashed to the address)
256bit ARG[5] = Value needed to be commited on chain, a free variable (to sign with the left leg of the decider)
256bit ARG[6] = Value needed to be commited on chain, a free variable (to sign with the right leg of the decider)

ADDRESS = SHA256(ARG[1] CAT ARG[2] CAT ARG[3])
CONDITION = ENTRENCHED(ARG[5]) && ENTRENCHED(ARG[6]) &&
(IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES(ARG[2...3], 0, ARG[5...6]) ||
((ENTRENCHED(ARG[1]) && ENTRENCHED(ARG[4]) && IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES(ARG[2...3],
(CHAINPOSITON(ARG[4]) - CHAINPOSITON(ARG[1]), ARG[5...6])))))
CONNECT_TO = IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES(ARG[2...3], 0, ARG[5...6]) ? ARG[1] : ARG[4]


a. assume TRUE == IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES(ARG[2...3], 0, ARG[5...6]).
     CONDITION = ENTRENCHED(ARG[5]) && ENTRENCHED(ARG[6])
     the CONDITION is just TRUE because those preimages ARG[5], ARG[6] needed to be entrenched
   assume FALSE == IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES(ARG[2...3], 0, ARG[5...6])
     CONDITION = ENTRENCHED(ARG[5]) && ENTRENCHED(ARG[6]) &&
      (((ENTRENCHED(ARG[1]) && ENTRENCHED(ARG[4]) && IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES(ARG[2...3],
      (CHAINPOSITON(ARG[4]) - CHAINPOSITON(ARG[1]), ARG[5...6])))))
     only 16bit numbers are signeable by the decider therefore to make the CONDITION TRUE:
      - CHAINPOSITON(ARG[4]) - CHAINPOSITON(ARG[1]) must fit into 16bit int.
      - CONDITION forces all of the values ARG[5], ARG[6], ARG[1], ARG[4] to be entrenched in order to become TRUE
        - this turns them into CONSTANTS
          - this turns the CONDITION into CONSTANTLY TRUE.          

b. the CONNECT_TO can only change if IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES changes.
   by ADDRESS1 == ADDRESS2 we have ARG1[2...3] == ARG2[2...3]
   this forces ARG1[5...6] == ARG2[5...6] by 0 being a constant:
   therefore IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES cannot change.
   therefore CONNECT_TO cannot change.




Guess this primitive  ;D


Code:
ARGCOUNT = 3
256bit ARG[1] = ALICE_ADDRESS
256bit ARG[2] = BOB_ADDRESS
256bit ARG[3] = ARBITRARY 256bit number
ADDRESS = SHA256(ARG[1] CAT ARG[2] CAT ARG[3])
CONDITION = TRUE
CONNECT_TO = SHA256( SHA256( SHA256(ARG[1] CAT ARG[2] CAT (ARG[3]+1)) CAT ARG[1] CAT 0.00000001 COMB  ) CAT ARG[2] CAT 0.00000001 COMB )


a. CONDITION is always TRUE (end of proof)
b. by contradiction: ADDR1 != ADDR2 || CONNECT_TO1 == CONNECT_TO2
     if ADDR1 != ADDR2:
       then by SHA256 collision resistance ARGS1 == ARGS2:
         but ARGS1 != ARGS2 if we want to prove something
     if CONNECTTO1 == CONNECTTO2:
       then by SHA256 collision resistance ARGS1 == ARGS2:
         but ARGS1 != ARGS2 if we want to prove something
   and so: ADDR1 == ADDR2 && CONNECT_TO1 != CONNECT_TO2
   and therefore: CONNECT_TO1 != CONNECT_TO2
  
EDIT1: added code blocks.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 26, 2021, 08:20:50 PM
OH CRAP I didn't even consider floor(), I understand now. That's spooky. God dammit, I thought I was good at breaking things.


Okay so I understand your layout of the Hot Cash now, thank you for labelling, it helped a lot. Last night I went through and made the following as an example of a Multi-Sig Hot Cash (included an updated version after text), and it has some small differences, but also I think I learned why custom signers won't work; anything that does SHA()^X is a potential weapon.

I think it's important to include in the CONTRACT what the expected type of an argument is; I worry that there'd be a way to cause a problem if someone hacked together a contract history with mismatched types, and the receiver just tried to run it anyways without realizing that it was invalid. It feels too loosey-goosey.

What I think is interesting about your Hot Cash contract is that it runs on receiving a destination address. The version I had made would request a GetCommitAtIndex(X), and had the Decider function return a TRUE or FALSE for if the listed number was signed, then the client would go get the INDEX if it was true. Yours makes more sense I think, because at the cost of 256bits of space you're saving the computer work to find the address. It's also clever to not store the signed int, but to just infer it, so I stole that lol. Do you think there's a problem in general with a GetCommitAtIndex() function? Or would it work to have as an option in other instances?

There's a potential problem with doing nested objects with arguments in TX history data; what if you have two nested objects, and the commits of the second one have occurred, but not the first? I think to deal with this it makes sense to use something like 000...000 in place of just leaving an argument slot empty. The example below will demonstrate, although it's still using the flawed custom Decider for it's nested objects.


Non-Nested Custom Decider
Code:
ARG = [
int256,   # 1 - Hashtip_1
int256,   # 2 - Hashtip_2
int16,    # 3 - SignedInt (Free)
int256,   # 4 - CommittedVal_1 (Free)
int256,   # 5 - CommittedVal_2 (Free)
]

#VALID(ARG) checks that it isn't 000...000

ADDRESS = SHA256(ARG[1] CAT ARG[2])
CONDITION = VALID(ARG[4]) && VALID(ARG[5]) && ENTRENCHED(ARG[4]) && ENTRENCHED(ARG[5])
RETURN = SHA256(ARG[4])^(65535-ARG[3]) == ARG[1] && SHA256(ARG[5])^(ARG[3]) == ARG[2] ? TRUE : FALSE


Multi-Sig Hot Cash
Code:
ARG = [
int256,   # 1 - Reference to NN Decider Contract
int256,   # 2 - Fallback Address
int256,   # 3 - Decider1_HashTip_1 (Alice)
int256,   # 4 - Decider1_HashTip_2 (Alice)
int256,   # 5 - CommittedVal1_1 (Alice) (FREE)
int256,   # 6 - CommittedVal1_1 (Alice) (FREE)
int256,   # 7 - Decider2_HashTip_1 (Bob)
int256,   # 8 - Decider2_HashTip_2 (Bob)
int256,   # 9 - CommittedVal2_1 (Bob) (FREE)
int256,   # 10 - CommittedVal2_1 (Bob) (FREE)
int256,   # 11 - Forward Address (FREE)
]

ADDRESS = SHA256(ARG[2] CAT ARG[3] CAT ARG[4] CAT ARG[7] CAT ARG[8])
CONDITION = (  ENTRENCHED(ARG[5]) && ENTRENCHED(ARG[6]) && BUILD_GET_OBJECT(ARG[1], ARG[3..4], 0, ARG[5...6])  ) ||                   #If Alice has signed 0
   (  ENTRENCHED(ARG[9]) && ENTRENCHED(ARG[10]) && BUILD_GET_OBJECT(ARG[1], ARG[7...8], 0, ARG[9...10])  ) ||                #If Bob has signed 0
   (  ENTRENCHED(ARG[2]) && ENTRENCHED(ARG[11]) && ENTRECHED(ARG[5]) && ENTRENCHED(ARG[6]) &&                                #If Alice and Bob have both signed the same non-0 number
            (  BUILD_GET_OBJECT(ARG[1], ARG[3..4], (CHAINPOS(ARG[11]) - CHAINPOS(ARG[2])), ARG[5...6]) &&
            (  ENTRENCHED(ARG[9]) && ENTRENCHED(ARG[10]) && BUILD_GET_OBJECT(ARG[1], ARG[7...8],  (CHAINPOS(ARG[11]) - CHAINPOS(ARG[2])), ARG[9...10])  )  )  )  
RETURN = BUILD_GET_OBJECT(ARG[1], ARG[3..4], 0, ARG[5...6]) || BUILD_GET_OBJECT(ARG[1], ARG[7...8], 0, ARG[9...10]) ? ARG[2] : ARG[11]

Let me know what you think about using 000...000 to indicate an empty field in the data. In this case, if Alice hadn't signed anything, but Bob had signed 0, he'd need to indicate in the TX history that Alice hadn't signed anything.

Or is this too sketchy? I'm trying to think if this could be exploited via the asymmetry that comes with TX histories. In this instance lets say they had the Multisig to make purchases using their combined funds; Alice and Bob put 10 COMB each into the Hot Cash, and then they now have purchasing power of 20 COMB. If either of them signs 0, the 20 COMB goes to an LStack that splits the COMB back up and send 10 to Alice and 10 to Bob. It gets a little messed up when you consider that Bob could sign the TX to 0 and then just not tell Alice. Now she still thinks that the wallet has 20 COMB. I don't think that she can't actually generate COMB with it, which is good.

I think to make this contract secure for both parties, in addition to the information you currently have to sign, you'd also have to commit to an address to signal that the Hot Cash has been burnt, and a decision has been made. So rather than using a contract like the one above, where two people have separate Deciders, there's probably a better way to do it where the contract has a killswitch address also. Both parties know the killswitch. If the killswitch is ever committed to before both Deciders sign a number together, then the transaction would go to the Fallback, but if both Deciders signed the same number with their Deciders before the killswitch was committed, then the funds would go to the Forward. This would actually make the code smaller I think, and it'd definitely make it cheaper to back out of the arrangement.

What do you think about the RETURN function? I used it in the "main" contract too, because if the Interpreter is the one who is acting as the parent of the sequence, then they know to take a RETURN from a main contract to be the CONNECT_TO address.



Quote
Guess this primitive  ;D


Code:
ARGCOUNT = 3
256bit ARG[1] = ALICE_ADDRESS
256bit ARG[2] = BOB_ADDRESS
256bit ARG[3] = ARBITRARY 256bit number
ADDRESS = SHA256(ARG[1] CAT ARG[2] CAT ARG[3])
CONDITION = TRUE
CONNECT_TO = SHA256( SHA256( SHA256(ARG[1] CAT ARG[2] CAT (ARG[3]+1)) CAT ARG[1] CAT 0.00000001 COMB  ) CAT ARG[2] CAT 0.00000001 COMB )


a. CONDITION is always TRUE (end of proof)
b. by contradiction: ADDR1 != ADDR2 || CONNECT_TO1 == CONNECT_TO2
     if ADDR1 != ADDR2:
       then by SHA256 collision resistance ARGS1 == ARGS2:
         but ARGS1 != ARGS2 if we want to prove something
     if CONNECTTO1 == CONNECTTO2:
       then by SHA256 collision resistance ARGS1 == ARGS2:
         but ARGS1 != ARGS2 if we want to prove something
   and so: ADDR1 == ADDR2 && CONNECT_TO1 != CONNECT_TO2
   and therefore: CONNECT_TO1 != CONNECT_TO2
 


That looks kinda like an LStack to me, but I'm confused about the ARG[3]+1. By ARBITRARY 256BIT number, I read that as you can put in w/e number you want. But if that was the case, then all the deposited money except for 0.00000002 COMB would just be stuck in the last stack unless you had put enough funds there to trigger it. So clearly I'm misunderstanding something lol.

EDIT: On an unrelated note, I was thinking more about your Hot Cashes, and I realized that if you're making regular payments it'll only be 3 BTC TXes per cycle, because you can just re-use the same fallback address as you did the last time!


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 27, 2021, 05:00:44 AM
Crap crap crap, I just realized there's a MAJOR problem with the precedent that the Multi-Sig would allow.

 - Alice and Bob pay into a contract that has "If EITHER decider signs a non-0 number, all funds go to the corresponding address
 - Alice signs her Decider Key sending to Chris's Address. She doesn't tell Bob.
 - Bob signs his Decider key sending to Danny's Address. He doesn't tell Alice.'

Now Chris and Danny both have 100% of the funds that Alice and Bob payed in, doubling the COMB. That's not good.

Is there a way to program the client to detect a bad contract like this? Is that what you were showing in your post, and I'm just too much of a baby-brain to notice?

EDIT: Something you could do would be to not allow OR statements in the condition. Rephrasing the Hot Cash to this would fit that requirement:

Code:
ARGCOUNT = 6
256bit ARG[1] = Fallback address
256bit ARG[2] = Value at the end of the hashing sequence (to sign with the left leg of the decider)
256bit ARG[3] = Value at the end of the hashing sequence (to sign with the right leg of the decider)
16bit ARG[4] = Int to be signed, a free variable
256bit ARG[5] = Value needed to be commited on chain, a free variable (to sign with the left leg of the decider)
256bit ARG[6] = Value needed to be commited on chain, a free variable (to sign with the right leg of the decider)

ADDRESS = SHA256(ARG[1] CAT ARG[2] CAT ARG[3])
CONDITION = ENTRENCHED(ARG[5]) && ENTRENCHED(ARG[6]) &&
IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES(ARG[2...3], ARG[4], ARG[5...6])
CONNECT_TO = GET_COMMIT_AT_INDEX(GET_INDEX_OF_COMMIT(ARG[1]) - ARG[4])

Would rephrasing in this manner work for all instances? All contracts would have to be phrased with no IF/ELSE statements in the CONNECT_TO/RETURN, and no OR statements in the CONDITION. All you have are fact-checks. You could still do a multi-sig like this, but it'd REQUIRE communication between both parties.

Except what if Alice just decided they wanted to send all the funds to a destination of their choice, so they just went ahead and signed their Decider to point at said destination. In the basic case of requiring both parties to sign, Bob now has to either sign in agreement with Alice, or just trap the funds in there forever. There's gotta be a clever way around this, without breaking the contracts.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 27, 2021, 08:38:26 PM
Alright I have a multi-sig proposal but it requires a new native object: Binary Decider.

Binary Decider can only choose Forward or Rollback, and requires a single commit to do so.

https://i.imgur.com/pZLbFE2.png

User generates a key, a random 256bit int. Generate the BDecider Root by doing SHA256( SHA256(Rollback_Address CAT Key) CAT SHA256(Forward_Address CAT Key) ) ). Include the Root, Rollback, and Forward in the contract. When you want to Decide, commit either SHA256(Rollback_Address CAT Key) or SHA256(Forward_Addres CAT Key) to the BTC chain. Then give the person your key. Whichever commit appears first on the chain is the one used.

This can also be used to sign a miscellaneous YES or NO, for use in Custom Contracts. Instead of doing a Rollback Address do 000...000, and instead of a Forward Address do 000...001. See the Multi-Sig example below:


Code:
ARGCOUNT = 6
256bit ARG[1] = Fallback address
256bit ARG[2] = Value at the end of the hashing sequence (to sign with the left leg of the decider)
256bit ARG[3] = Value at the end of the hashing sequence (to sign with the right leg of the decider)\
256bit ARG[4] = BDecider Lock
16bit ARG[5] = Int to be signed, a free variable
256bit ARG[6] = Value needed to be commited on chain, a free variable (to sign with the left leg of the decider)
256bit ARG[7] = Value needed to be commited on chain, a free variable (to sign with the right leg of the decider)
256bit ARG[8] = BDecider Key, a free variable

ADDRESS = SHA256(ARG[1] CAT ARG[2] CAT ARG[3] CAT ARG[4])
CONDITION = ENTRENCHED(ARG[7]) && ENTRENCHED(ARG[8]) &&                                                     # If both Decider vals have been entrenched
   IF_DECIDER_SIGNS_VALUE_USING_PREIMAGES(ARG[2...3], ARG[5], ARG[6...7]) &&                       # And the Decider is signed with them
            IF_BDECIDER_UNLOCKED(ARG[4], 000...000, 000...001, ARG[8])                                      # And the BDecider is unlocked
CONNECT_TO = GET_COMMIT_AT_INDEX(GET_INDEX_OF_COMMIT(ARG[1] - (ARG[4] * BDECIDER_UNLOCK(ARG[4], 000...000, 000...001, ARG[8]))))

IF_BDECIDER_UNLOCKED returns a TRUE or FALSE, but BDECIDER_UNLOCK returns the address itself. Because the contract stipulates the two addresses of the BDecider are 0 and 1 respectively, BDECIDER_UNLOCK can only return one of those.

The CONNECT_TO takes the index of the fallback, modify it by the signed value, then multiply it by either 0 or 1. In this way the second signature is required to sign off, but in a way that it impossible to burn any COMB; either they sign a 1 to not modify the displacement that indicates the Forward Address, or they sign a 0, to making the displacement guaranteed to be modified to 0, aka the Fallback Address.

I do worry that including raw 256bit digits in the contract maybe a problem, so if we wanted to limit raw number size inclusion this could be re-written to have those address become part of the entire contract address instead.

LMK what you think about not using IFs or ORs.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 28, 2021, 12:53:33 AM
So, am I missing something, or can you sign 16 bit numbers with the Binary Decider method?

1. Make a merkle tree that has 131,072 leaves, and the leaf pattern is 0, key, 1, key, 2, key . . . 65,533, key 65,534, key, 65,535, key.
2. Include the merkle root in the address of the object to use this signed number.
3. If the leaves are level 0, commit one of the level 1 numbers to the chain, i.e. SHA256(58 CAT key)
4. After 6 confirmations, reveal the key.

You just signed a 16 bit value with 1 commit.

EDIT: I'm clearly missing something, because if you could just reveal the key then you could instead just do a 65536 long hash chain, commit one of the numbers, and reveal the key. The commit that appeared first on the chain would be the real one. So why isn't this how things are decided?

Back on topic, assuming that I was correct and there was no way to escape the requirement of limiting the contacts to no OR, IF, or ELSE statements, there's still problem phrasing. I think it can be dealt with via the interpreter, but I'm not sure how yet.

Code:
ARGS = 2
int256 ARG[1] = Address
int256 ARG[2] = Address (Free)
ADDRESS = SHA(ARG[1]+1)
CONDITION = TRUE
CONNECT_TO = ARG[2]

The interpreter needs a way to determine that this is all jacked up. The possibility exists to include a more specific variable type, address, and require the CONNECT_TO statement to utilize this address in some regard. It could also NOT be a free variable.

Depending on what you allow though, this could happen:
Code:
ARGS = 2
address ARG[1] = Address
int256 ARG[2] = Address (Free)
ADDRESS = SHA(ARG[1]+1)
CONDITION = TRUE
CONNECT_TO = (ARG[1] * 0) + ARG[2]

So clearly that can't be the only thing involved in the solution.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on February 28, 2021, 12:27:17 PM
yes all schemes that rely on your single commited DECIDER, are more subsceptible to short-lived 51% attacks.

1. Wealthy Alice buys a lolipop worth 0.01$ from a 51% Miner
2. They wait 6 confirmations
3. Wealthy Alice gives a "single commited decider private key" to her entire wallet to a 51% Miner as part of a coin history for the 0.01$ payment.
4. 51% miner reorgs the last 6 confirmations and loots Wealthy Alice's entire wallet

If the 51% miner would be able to sell the lolipops to say 90% of the HODLERS, it'd be able to loot 90% COMB in existence.

Sure you might say a 51% miner might reorg the whole chain to the point when just 10% of the current COMB existed
and steal 90% of COMB that way, but that would be a long-range 51% attack, much more costly and risky for the attacker.


I think multisig is doable if forked, for instance up to 3 party multisig.

Total number of commits on chain is rather fat. 21 * CEIL(n/2) for up to n-party multisig.


Code:
ARGCOUNT = 69 = 23*n
ARG[1] comb 1 pubkey
ARG[2] comb 2 pubkey
ARG[3] comb 3 pubkey
ARG[4...24] comb 1 sig, free
ARG[25...45] comb 2 sig, free
ARG[46...66] comb 3 sig, free
ARG[67] destination voted by comb 1, free
ARG[68] destination voted by comb 2, free
ARG[69] destination voted by comb 3, free

ADDRESS = SHA256(ARG[1] CAT ARG[2] CAT ARG[3])
CONDITION = MAJORITY(
    ENTRENCHED(ARG[4...24]) && COMBSIGNS(ARG[1], ARG[4...24], ARG[67]),
    ENTRENCHED(ARG[25...45]) && COMBSIGNS(ARG[2], ARG[25...45], ARG[68]),
    ENTRENCHED(ARG[46...66]) && COMBSIGNS(ARG[3], ARG[46...66], ARG[69]))
CONNECT_TO = BITMAJORITY(ARG[67], ARG[68], ARG[69])
WHERE:
MAJORITY(a,b,c) = (a && b) || (a && c) || (b && c)
BITMAJORITY(a,b,c) = (a & b) | (a & c) | (b & c)

Possible problems:
- If a super-majority of keys does not sign exactly the same destination each, then all funds get destruct.
- Strong pressure to follow the decision of the first signer, because signer who already signed can not change their mind anymore.








Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on February 28, 2021, 03:17:05 PM
I see I see, that makes sense, thanks for the explanation.

Dammmmmm gurl, thassum phat commitz.

You could still do a multi-sig Hot Cash but using multiple Deciders. If a Decider that works liked they do now but could only sign 1 or 0 was implemented, you could do the exact same process as the multi-sig Hot Cash I laid out before. Even if a new binary Decider wasn't included you could still accomplish it with 2 normal Deciders, but then you run into the same problems that you did in your full-wallet multi-sig, that being that there's a strong pressure to follow the leader because your funds will get destroyed if you all disagree.

Do you think that a new variable type "address" makes sense? If you gave the Interpreter instructions that modifying the address in any way (i.e. address*0) would turn it into a normal int256, and then also told it to ONLY accept addresses as CONNECT_TO variables, it covers some ground but I don't think it's enough. Essentially the only way to have addresses in the contract would be to either A) Include them as listed "address" in the non-free variable slots, so they're hard coded into the object's address, or B) create them using native functions like GET_ADDRESS_AT_INDEX().

But I still see there being problems if someone were to make a contract like:

Code:
ARGS = 2
address ARG[1] = Address
int16 ARG[2] = index_displacement (FREE)
ADDRESS = SHA(ARG[1]+1)
CONDITION = TRUE
CONNECT_TO = GET_COMMIT_AT_INDEX(GET_COMMIT_INDEX(ARG[1]) + ARG[2])

Now you just hand out multiple txes with different displacements >:(

There's gotta be a good way to gate contracts like this.



Thinking more about your Hot Cash, two thoughts:

1. I think they aren't actually Hot until you spend them. You could make a Hot Cash with a specific fallback address, and then just never commit that address to the chain until you're ready to do your first spend. So that's pretty cool.
2. I ran a script last night that pulled how many new P2WSH addresses were on each block. Over 70 blocks, it averaged out to 36 new P2WSH addresses per block. While that's a small sample size, even if we multiplied that number by 10, you're looking at 360 new addresses per block. That's 51,840 new P2WSH per day, if you were making multiple payments in a single day you could get away with reusing a fallback address for a good chunk of your day, most of the waking hours. And that's with the overestimation included lol.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on March 01, 2021, 02:14:39 AM
Alright I have the beginnings to interpreter law, but nothing concrete yet.

As established, values can be separated into two types, Locked and Free. Free values can be input via a TX history input, and have no inherent ties to the contract, save for a reference to their argument slot. Locked values are more varied; they can be either included the contract themselves as predefined constants, such as raw integers used to multiply, or can be injected into the contract on its creation, by becoming part of the address that makes up this particular instance of the contract.

Problems arise when free values can be inserted into areas of the contract and affect the outcome while being completely untethered from the contract itself. See the example below.

Code:
ARGS = 2
int256 ARG[1] = Address
int256 ARG[2] = Address (Free)
ADDRESS = SHA(ARG[1]+1)
CONDITION = TRUE
CONNECT_TO = ARG[2]

This contract determines the CONNECT_TO solely based off of a free value. This is unstable.


One methodology that might be able to restrain free value usage is to require free values to be in some way tethered to a locked value. This could be done through a pointing process, in which a contract must specify which locked value the free value will be used by. This pointing process can then be used to provide a filter to these free values; free values cannot be included in the contract unless they are done so via integration through the locked value that points to them. To illustrate my point (hah), I'll use a version of a Hot Cash contract.

Code:
ARGCOUNT = 6
256bit ARG[1] = Fallback address
256bit ARG[2] = Value at the end of the hashing sequence (to sign with the left leg of the decider)
256bit ARG[3] = Value at the end of the hashing sequence (to sign with the right leg of the decider)
256bit ARG[4] = Value needed to be commited on chain, a free variable (to sign with the left leg of the decider)
256bit ARG[5] = Value needed to be commited on chain, a free variable (to sign with the right leg of the decider)

ADDRESS = SHA256(ARG[1] CAT ARG[2] CAT ARG[3])
CONSTRUCTS = [DECIDER(ARG[2], ARG[3], ARG[4], ARG[5])]
CONDITION = ENTRENCHED(ARG[4]) && ENTRENCHED(ARG[5]) &&
CONSTRUCTS[1]
CONNECT_TO = GET_COMMIT_AT_INDEX(GET_INDEX_OF_COMMIT(ARG[1]) - CONSTRUCTS[1]])

In this example, DECIDER() will return the number that has been signed, based off of the the input values. If it cannot calculate a value, it will return nil. If it can calculate a value, but the DECIDER has already been used to sign a previous number, it will also return nil. Returning some value that is not false or nil will act as a TRUE statement for the CONDITION, and allow the contract to move onto the CONNECT_TO phase. Once there, the DECIDER() will again return the signed number, and the contract will complete based on said number.

In this example, the free values are never allowed to interact with the main contract itself. They are REQUIRED to be filtered through a native contract. This seems like it could be a core methodology that can secure contracts; by requiring free values to be processed through a native object like this, we can restrict the outcome. This can potentially even expand to nested custom contracts; free values could extend through multiple layers, as long as they were required to be processed directly through a native object to be used.

I'm not sure I'm happy with the syntax though, let me know what you think. Is there a way to break this system?


EDIT: Another phrasing option:

Code:
ARGCOUNT = 6
256bit ARG[1] = Fallback address
256bit ARG[2] = Value at the end of the hashing sequence (to sign with the left leg of the decider)
256bit ARG[3] = Value at the end of the hashing sequence (to sign with the right leg of the decider)
256bit ARG[4] = Value needed to be commited on chain, a free variable (to sign with the left leg of the decider)
256bit ARG[5] = Value needed to be commited on chain, a free variable (to sign with the right leg of the decider)

CONSTRUCTS = [DECIDER(ARG[2], ARG[3], ARG[4], ARG[5])]
ADDRESS = SHA256(ARG[1] CAT CONSTRUCT[1].ADDRESS)
CONDITION = ENTRENCHED(ARG[4]) && ENTRENCHED(ARG[5]) &&
CONSTRUCTS[1]
CONNECT_TO = GET_COMMIT_AT_INDEX(GET_INDEX_OF_COMMIT(ARG[1]) - CONSTRUCTS[1]])

There may be consequences to having ARG[2] and ARG[3] hashed prior to hashing in the main address, I'm not sure.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on March 10, 2021, 04:30:18 PM
The way I laid out to commit the contracts to the BTC chain has an attack vector. If you are a malicious actor, you can scan the mempool for new transactions coming in with P2WSH addresses, and then test out those transactions as if they were contract IDs. If they were, you could insert your own instructions into the contract by setting a higher fee and getting your transaction on the next block.

Rather than initiating a contract commit using the contract ID directly, you could instead initiate by using SHA256(ID CAT START CAT 0), and then continue inputting the instructions starting with index = 1.

This brings up another question though, what about 51% attacks? You need to reveal the contract ID to tx receivers, so if they had enough power/the contract was recent enough they could go back and rewrite the contract. Do you think that this is a risk to worry about?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on March 21, 2021, 03:16:38 PM
I may have found a bug with the Haircomb Core's reorg code, but it may just be the way I'm testing it, I'm not sure. I'm gonna PM you Watashi.

EDIT: Looking at it a bit more, if it’s an actual bug and not just something I’m messing up it doesn’t seem to be exploitable in any way, and it would explain the random crashes that some people have had. Doesn’t hurt to be safe though.

EDIT2: I patched the bug, it seems to be working fine now on windows. If someone would be willing to test it on a Linux machine I'd appreciate it, I can help you through the re-org steps on BTC's regtest if you need assistance. The repo is here: https://github.com/nixed18/combfullui

The bug fix is in commitfile.go, there are a bunch of other changes with comments and some testing values though.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 02, 2021, 05:32:48 PM
I've been working on integrating an RPC based commits puller into Haircomb and I've run into a bit of a crossroads. In order for it to work well I'll need to rework the storage mechanics of the commits, and I have two options: move over to an established database format (I've been using LevelDB for now), or rework the current storage mechanism of a single, custom file.

The rework is needed to store block hashes with the commits themselves; storing the block hashes is required to detect when the BTC chain orphans a block/blocks, to trigger a commits unmine. Previously this was detected internally by the modded BTC client, however switching to using the BTC's RPC means that this won't work, and reorgs must be detected manually. It only makes sense to store the block hashes with the commits themselves, working with a single database is going to be easier to account for all variable events rather than working with two separate databases simultaneously.

The problem arises with deciding how to move forward. We were talking about it on the telegram, and we can't really figure out why Natasha would have gone with a custom db system like she did; it seems like it would have been incredibly easy to implement a pre-existing db structure into Haircomb (and from my experience with LevelDB, it was very easy). This makes me think that I'm missing something important about why Haircomb uses this custom structure, but I don't know what it'd be.  If I had to guess, it'd be the encryption. I'm not sure how relevant the encryption of the commits file is to the security of Haircomb though. You could probably use an established db structure that utilizes encryption, however I don't know how quickly you'd be able to iterate through the dataset, which could significantly slow down Haircomb's load times.

So I see two ways of moving forward:

1. Switch to an established DB system.
I've been using the Go implementation of LevelDB that can be found here: https://github.com/syndtr/goleveldb. It works fairly well from my limited experience with it, and has similar load times to the current system. I've been storing the block hashes under the UTXO tag 99999999 CAT BLOCKHEIGHT. The database organizes by numerical order of the key, so this clumps all the hashes at the end of the database, and allows me to iterate through the stored commits on load without a problem.

2. Modify the current system.
This could be done by changing the flush system from using FFF...FFF, 999...999 to instead using BLOCKHASH, 99999999 CAT BLOCKHEIGHT, the same format as previously mentioned. All that's needed to identify a flush entry in the commits file is the end of a block is the 99999999 block height in the UTXO tag, which means that both the FFF...FFF and the second portion of the UTXO tag are available to use as data storage. We should be able to just slot these into the existing commits.db file and, on load, process them into their own memory storage.

I've got a prototype working for option 1, but I don't want to put the effort in to finalize it yet without properly going over whether it's the right path to take. It's a much easier implementation than option 2, however you do lose the current aes encryption that is implemented. You also gain a more stable storage format though, which means less corrupting, though there may be ways to reduce the corruption risk in the current system. There may also be fast, encrypted databases that I'm not currently aware of though. I'd appreciate any thoughts that anybody has on the matter.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 07, 2021, 01:57:18 AM
I'm a big dummy, I just realized that there isn't actually any database encryption, the aes is just used for the file fingerprint. Took me long enough. Knowing this, I'm gonna start merging the RPC puller and new DB format into the Haircomb code, hopefully I'll have a decent test version out in the next couple of weeks.

On a different note, another thing I can't believe I didn't realize sooner was that you can do a better version of atomic swapping COMB using the same decider for two contracts, without any new tech required.

1. Alice sends 10 COMB to Contract_1, which is composed of Decider_1 and a pattern_0 merkle tree with Alice_1/Turbine_1.

2. After Alice proves that she's deposited the funds, the Turbine then sends 10 COMB to Contract_2, which is composed of Decider_1, and a pattern_0 merkle tree with Turbine_2/Alice_2


If Alice signs the key true, Alice's funds go to Turbine_1, and the turbine's funds go to Alice_2. If she signs it false, Alice's funds go to Alice_1, and the Turbine's funds go to Turbine_2.


This means that Alice has complete control over her funds and doesn't have to trust a 3rd party to hold them or oversee the trade, and also reduces the trade cost to 2 BTC commits. There's still a problem though; information imbalance. Alice can wait until the Turbine has deposited its funds, then sign the Decider false to rollback. Now Alice has access to her funds (because she can see the TX history of the Decider that unlocked them), but until she gives the long decider to the Turbine the turbine funds are still locked up from the Turbine's view. This is a problem. It would be less of a problem if the turbine was the one who had the information advantage, because they're the ones with a reputation to uphold, however Alice is anonymous; there's no real incentive for her to act in good faith. Technically there isn't a reason for her to actually do this (she gains nothing from the process), but it's still an attack vector for those who just like to watch things burn.

From my thinking so far, the only way to deal with the information advantage in general is to a) rely on the reputation of the information holder to ensure that they supply the tx history, or b) figure out a way to communicate the information over the only way that Haircomb nodes communicate; the BTC chain. Both options kinda stink, but option b stinks more; the solution I proposed before was the brute-force based lockbox, but I have a feeling that it could be exploited and used as an attack vector. It also requires a fork, which, while not out of the question because both Hot Cashes and the scripting implementation would be sick, is less than ideal. I don't know how to deal with it in this circumstance though.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on April 18, 2021, 05:54:25 PM
thoughts about leveldb in combfullui:

overall I will stay by your core dev decision to implement this db into haircomb,
although there are some disadvantages known to me.

here are my thoughts about decisions you might be facing at this point

1. keep supporting commits.db or drop it?

   - the new leveldb haicomb core in my opion should not be able to read
   commits.db at all and only be able to write it, and only write it in case
   the user manually clicks downgrade to old commits.db format.

   - the reason for this is that we cannot realistically assume that commits.db
   is consistent.
   
   - full header data need to be present to allow meaningful sync resume support.
   
   - another reason is we need additional data in the leveldb format (complete BTC
   block headers). There is no way to magically recreate this data that do not
   exist in the old format. (e.g while we are able to download the current BTC
   headers we have no way to know/verify that those blocks contain the commitments on file)
   
   - therefore, full resync will be required to use the new leveldb comb full ui.
   
   - commits.db will live and remain working on on legacy/natasha branch.


2. change of port from :2121 to something else

   - yes. we want to people who physically own 1 pc to run both versions in
   parallel, as well as testers to push blocks to both nodes using a hacked syncer.

3. remove the whole /miner/mine api.

   - definitely, we must recreate it correctly (under a different name)

   - there should be:
     - a call to return ALL/THE TOPMOST on chain block headers the combfullui is currently synced to (not just current height).
     - a call to rollback (reorg the chain) to a specific header hash (block hash) + it's height (uint64).
     - a call to start uploading one forward block, into this call the syncer will submit the new 80byte new block header.
     - a call to upload one commitment. parameters:
       - commitment (256bit), blockhash(256bit), height(uint64), tx number (uint32), txout number(uint32), total order
         number of the commitment within block including previously seen and unseen commitments (uint32).
     - a flush forward block command, paramters: blockhash(256bit), height(uint64), previously UNSEEN,SEEN commitment count in the block ([2]uint32)
     - a call to trigger to write out the legacy commits.db file.

4. a Bitcoin blockchain syncer will be integrated or not?
     - at first not, it will talk to combfullui using the above api
     - later it will be integrated into the same exe but still talking to 127.0.0.1 (localhost) using the same api
     - finally syncer can be made to communicate internally and the api deprecated (so that there will be no miner api at all)
     - the syncer will trust an external BTC full node about the longest valid chain selection (i.e. the one ran by the comb node operator) and
       only SPV validate the blocks.
     - only one syncer running at a time will be supported, if multiple ones are detected wanting to push a block, the non first one will be ignored.

Finally, disadvantages of leveldb:
     - it's multiple files / difficult to share P2P
       - probably just rar/7zip it
     - multiple writing/reading processes at the same time unsupported
       - leveldb combfullui must be that single writing process.
       - syncing while wallet is off WILL NOT BE SUPPORTED.
       - use of 3rd party tools that work on leveldb files MUST BE DISCOURAGED
     - when 2 users sync to the same height their leveldb will not be bit-for-bit identical (commits.db will be)
       - we must keep the support for the AES checksum for UI purposes.
       


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 19, 2021, 06:00:25 AM
thoughts about leveldb in combfullui:

overall I will stay by your core dev decision to implement this db into haircomb,
although there are some disadvantages known to me.

here are my thoughts about decisions you might be facing at this point

1. keep supporting commits.db or drop it?

   - the new leveldb haicomb core in my opion should not be able to read
   commits.db at all and only be able to write it, and only write it in case
   the user manually clicks downgrade to old commits.db format.

   - the reason for this is that we cannot realistically assume that commits.db
   is consistent.
  
   - full header data need to be present to allow meaningful sync resume support.
  
   - another reason is we need additional data in the leveldb format (complete BTC
   block headers). There is no way to magically recreate this data that do not
   exist in the old format. (e.g while we are able to download the current BTC
   headers we have no way to know/verify that those blocks contain the commitments on file)
  
   - therefore, full resync will be required to use the new leveldb comb full ui.
  
   - commits.db will live and remain working on on legacy/natasha branch.


I hadn't thought about maintaining support for the old commits.db but it makes sense to do. The problem though is that, as you brought up, the old commits data relied on the Modded BTC node to trigger reorgs; it can't detect them by itself. Are you suggesting also combining this with a second, separate database so that people could run the old commits.db format while also using the built in RPC puller, or just that they'd have the option to go back to the legacy system of requiring the Modded BTC?

Quote
2. change of port from :2121 to something else

   - yes. we want to people who physically own 1 pc to run both versions in
   parallel, as well as testers to push blocks to both nodes using a hacked syncer.

This makes a ton of sense.

Quote
3. remove the whole /miner/mine api.

   - definitely, we must recreate it correctly (under a different name)

   - there should be:
     - a call to return ALL/THE TOPMOST on chain block headers the combfullui is currently synced to (not just current height).
     - a call to rollback (reorg the chain) to a specific header hash (block hash) + it's height (uint64).
     - a call to start uploading one forward block, into this call the syncer will submit the new 80byte new block header.
     - a call to upload one commitment. parameters:
       - commitment (256bit), blockhash(256bit), height(uint64), tx number (uint32), txout number(uint32), total order
         number of the commitment within block including previously seen and unseen commitments (uint32).
     - a flush forward block command, paramters: blockhash(256bit), height(uint64), previously UNSEEN,SEEN commitment count in the block ([2]uint32)
     - a call to trigger to write out the legacy commits.db file.


I agree entirely, although for testing purposes I have it currently left on in my build, it's been invaluable for testing to allow me to manually enter in commits. I also had a more extensive COMB RPC planned, it makes complete sense to include something like that, though I'll probably wait to include it until after the DB stuff I'm working on right now is finalized.

EDIT: I'm curious as to the structure of some of these. Right now I don't have it working to walk step by step through the commit upload process, to be as safe as possible. Allowing manual, commit upload means allowing interblock commit segregation; you could theoretically end up with an incomplete storage of a block's commits and not know it. The way I have it running currently is to upload every commit in a block, then upload the block hash immediately afterwards. When you load Haircomb, it scans all the commits for matching block hashes; if a commit doesn't have a block hash that matches its height, it's considered orphaned and deleted. By batching the processes together and only storing the hash AFTER all block commits have been recorded means that you shouldn't ever end up with incomplete blocks.


Quote
4. a Bitcoin blockchain syncer will be integrated or not?
     - at first not, it will talk to combfullui using the above api (done, but it was using the legacy api to mine blocks.)
     - later it will be integrated into the same exe but still talking to 127.0.0.1 (localhost) using the same api (done, again though with the legacy api)
     - finally syncer can be made to communicate internally and the api deprecated (so that there will be no miner api at all) (done)
     - the syncer will trust an external BTC full node about the longest valid chain selection (i.e. the one ran by the comb node operator) and
       only SPV validate the blocks. (done)
     - only one syncer running at a time will be supported, if multiple ones are detected wanting to push a block, the non first one will be ignored. (pretty much done)

See included, once I'm done a little more testing on the reorg code I'll upload the code to github and provide a link. There's still a lot to do to properly secure it all and make it less sloppy, but the framework is there and it works.

Quote
Finally, disadvantages of leveldb:
     - it's multiple files / difficult to share P2P
       - probably just rar/7zip it
     - multiple writing/reading processes at the same time unsupported
       - leveldb combfullui must be that single writing process.
       - syncing while wallet is off WILL NOT BE SUPPORTED.
       - use of 3rd party tools that work on leveldb files MUST BE DISCOURAGED
     - when 2 users sync to the same height their leveldb will not be bit-for-bit identical (commits.db will be) (This is true, but I think with the AES it'll be okay.)
       - we must keep the support for the AES checksum for UI purposes. (This has been kept working successfully during my testing so far)

When you say reading processes, can you elaborate? I'm assuming you're referring to securing the DB during comb operation so that we don't run into any data-race type scenarios, which makes complete sense. I'm also curious as to your emphasis on "syncing while wallet is off WILL NOT BE SUPPORTED," as while I agree it makes the most sense to run everything through Haircomb's prebuilt mining code, I think that you could likely get it running fine without doing that. I'm curious as to your concern, I'm clearly missing something.

I'll test the reorg stuff over the next few days, then I'll get a build up for testing. Thanks for the feedback!

EDIT: One bonus to note with leveldb is that, at least in my trials, commit file build and load times are reduced to like 66% from their previous times. I realize that if there's any sacrifice to security to get this then obviously it's not worth doing, however it is a nice bonus.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 20, 2021, 02:27:12 AM
Alright, I've got a test version up here: https://github.com/nixed18/combfullui

A release is available to be downloaded, or people can build it themselves.

For simplicity I'm gonna refer to the normal version as legacycomb and the test version as mergedcomb


Build

Do the same steps as the normal combfullui (https://bitcointalk.org/index.php?topic=5195815.msg54605575#msg54605575) but with two differences:

1. Make sure you don't install in the same folder as your normal combfullui; after cd Documents, type in mkdir combfullui_rpctest, then type in cd combfullui_rpctest

2. Type in "go get github.com/syndtr/goleveldb/leveldb" to install LevelDB


Set up bitcoin.conf

1. Navigate to the directory where you have stored your BTC blockchain. By default it is stored in C:\Users\YourUserName\Appdata\Roaming\Bitcoin on Windows. You'll know you're there when you see blocks and chainstate folders, along with some .dat files for stuff like the mempool, peers, etc.

2. Look for a file named "bitcoin.conf". If one doesn't exist, make one by right clicking the whitespace and going New>TextFile. Then rename this file to "bitcoin.conf"

3. Open "bitcoin.conf" in Notepad and add the following two entries, replacing XXXXX with what you want your log info to be. This is only used to your BTC node.
Code:
rpcuser=XXXXX
rpcpassword=XXXXX

4. Save and exit


Set up config.txt

1. Navigate to the directory you installed mergedcomb

2. Create a text file called "config.txt". Launching the program will automatically create this file if you don't.

3. Open "config.txt" in Notepad, and add the following lines, replacing the XXXXX with the same values that you used in your "bitcoin.conf".
Code:
btcuser=XXXXX
btcpass=XXXXX

4. Save and exit. If mergedcomb was open during this edit, you must restart the program for your changes to take effect.

Note: There are two further options that you can use in the config: "btcmode=" and "port=". The only valid value for "btcmode=" is "regtest", any other entry will result in a normal boot. "port=" sets the port that the mergedcomb listens on, set it to a normal number lol I haven't made the proper processing for it to reject letters yet.


Run

Assuming you're using an unmodded BTC, you can run either the BTC or the mergedcomb first, it doesn't matter. While the mergedcomb is running, it'll keep checking if there's a BTC server running on your machine, and if so, will attempt to connect with it. When you run BTC, either run bitcoind.exe OR run bitcoin-qt.exe with "-server" as an argument.

AFAIK this version is compatible with any recent BTC build. It is also compatible with the Modded BTC, however you either must run it in tandem with legacycomb, or modify mergedcomb's port to be 2121. The Modded BTC must be able to communicate with a Haircomb client to start. The default port for mergedcomb is 3232 btw.

Merged comb should begin mining automatically, assuming that the BTC chain is up to date. BTC's RPC doesn't like to respond to queries while it's validating blocks, mining progress may be slow or non-existent before the BTC chain is all caught up.


Notes

This is essentially a proof of structure, so approach it as such. There's more to do, listed below, but it makes sense to finalize the structure before refining anything.

A brief overview:

Mining: Mergedcomb pings BTC until it is told there's a change in the chain, mergedcomb then sets up a mining config with the start height, target height, and direction (mine or unmine), and begins pulling blocks. Block info is funneled through the miner, which first mines all the commits in the next block, which is done by triggering miner_mine_commits_internal() as usual. Then once all the commits have been stored, the miner stores the block hash under the key 99999999 CAT blockheight. If unmining, the miner REMOVES the hash first, then begins unmining the commits. This ordering should minimize the possibility of incorrect block content while also storing the hash. This is important for DB cleaning, which happens on load.

Loading: Mergedcomb iterates through every entry in levelDB. Entries are stored in numerical ordering, which is convenient. First, check that the commit entry belongs to a block who's hash has been stored. If it has, move it to an array for said block. Once a new block is reached, all the commits in the old block array. Continue until you reach the hashes, aka block 99999999, then stop. If a commit's block does NOT have a stored hash, then it and every other commit after the fact are all marked as orphaned, and so are any hashes for those blocks (i.e. if block 6 does not have a stored hash, all the commits on block 6, 7, 8, 9, etc. are all considered bad and must be redownloaded). After pulling all the orphaned commits and hashes, delete the from the db without mining them. In the future this can be made more efficient, but for now it makes sense from a safety perspective.

This setup should, barring manually messing around with the commits files or ​manually inputting commits, prevent any problems. The hash is always stored/removed as the seal, even if the mine/unmine process is interrupted by a crash the next time you boot that block's commits will all be orphaned, as they won't have a stored hash, and will get negated and remined.

Note: currently mergedcomb contains some code I haven't tested for cleaning orphaned blocks. The code has been tested for cleaning the most recent block, but what has not been fully tested yet is the multi-block cleaning that would be trigger by messing removing a block hash that's halfway down the chain. I'll test it over the next couple of days, this is just a heads up there may be some problems if you try to mess with it.


Testing with BTC's regtest mode has been implemented, not Testnet yet though. As this whole modification doesn't make any changes to the transaction processing code, regtest will work for simulating chainstate changes and how they affect the database. A separate commitsdb is created specifically for regtest, so you don't need to worry about overwriting the normal one.


TODO:
​ - Implement block by block fingerprinting. This will allow for 100% certainty that no problems have occurred in the commits file, and will also potentially allow for selective block repairs if commits get corrupted/orphaned, rather than bruteforcing every commit above the problem.

 - Better comms structure. The channel communication isn't built on a solid foundation because it doesn't need to be yet. If it is projected that it'll need to expand to become a more substantial part of the system, then reorganizing it properly is a good idea.

 - Better datatype management. I need to go through and make a few things more uniform and consistent I think, I haven't done any optimization in this regard.

 - More thorough error management testing. Right now it seems to work alright, but I haven't gone through it enough to be 100% confident in it yet. This also includes better logging for debugging.

 - Memory management. I need to go through the best way to negate this, probably combine this with datatype management lol.

Overall there's a lot to be done to format everything and make it less sloppy, but like I said this is really a structure proof before doing stuff like that.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on April 21, 2021, 08:22:09 AM
Hello,

the config file didn't work out of the box on Linux, a one-liner was needed to add break in the parsing.

https://textbin.net/rrkcxerx0z

Now, the concept of pulling blocks over RPC is solid, I didn't know it was practical or doable. Great job there.

That said the implementation has it's flaws, I fixed two of them.

First of all the shutting down of goroutines using the run boolean had a race, so I've added a RWMutex to guard it.
I've changed the boolean to integer so that later when we want to start it again we just keep increasing it on every startup or shutdown.
The goroutine will just compare it's own copy of the integer to know if it should run or not.


Secondly, the parsing of the bitcoin block had a serious problem. The block/transaction was getting parsed into map[string]interface{}.
Problem is maps don't guarantee ordering by key when getting looped.
This could've caused reordering of commitments in some conditions. Whoops.

So I've put there a Block struct that contained slice of tx and tx contains slice of outputs. Problem solved, as slices are ordered.

You should recreate your databases after this fix just to be sure.

EDIT:
Another problem was that you weren't using pointer receivers when programming in an object oriented way. To highlight the problem:
Code:
func (a A) X() {}
fixed as:
Code:
func (a *A) X() {}
The lack of pointer receivers makes copy of the a each time which makes the original not writable, and could lead to other subtle glitches.

Further potential improvements

* Remove the mining/miner api. Only keep the height view set to 99999999 to make sure Modified BTC Does not troll us when we run at port :2121 set on config.
* Write complete block in batch instead of writing every commitment separately. Basically, you can open new leveldb.Batch object then write to it all the commitments. Then, even if computer hard shutdowns due to power loss the leveldb should guarantee that the final block either did or didn't get written completely.
* Change utxo tag to 128bit (Commit position is basically a position of the current commitment is in the block sequentially taking both seen and unseen commitments into account):
Code:
type UtxoTag struct {
    Height uint64
    CommitPositionInBlock uint32
    TransactionNum uint16
    OutputNum uint16
}
* Change on-disk block key to Height uint64 as opposed to Block hash. Then you can distinguish block keys and Commitment keys by their length.
* Implement the block-specific checksum. (Probably a SHA256 of all the commits in the block concatenated in their order). The block-specific checksum can be prepended to the block value whose key is uint64 on-disk:
* Implement storage of block headers. BTC header having 80byte should be recreated from the information provided via the RPC api and put to the database. This makes is feasible to resume the download using a specialized tool that I have in development (the tool will also require access to an API endpoint that will return ALL or the HIGHEST block header).





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 21, 2021, 06:06:19 PM
Hello,

the config file didn't work out of the box on Linux, a one-liner was needed to add break in the parsing.

https://textbin.net/rrkcxerx0z

Weird. I get why the fix works, but I think the problem source may be that I put the "finished := false" within the for loop by accident. The reason I delay the break is because if the config doesn't have an empty line at the end, it looks like it'd break before actually parsing the last line. If you move the "finished := false" to before the for loop and remove the break you inserted, does it still cause a problem on Linux? Am I mistaken about the early break not causing problems on config files with no empty final line?

EDIT: I made a mistake that was included in the first version I uploaded to github, I've since corrected it but if you downloaded a version before I did then this might be the issue.
https://github.com/nixed18/combfullui/commit/3074fbd709e9602eeaccd639dfcb63dcad7dee66

If you've still got that "continue" on line 70, that's what causing the permaloop.

Quote
Now, the concept of pulling blocks over RPC is solid, I didn't know it was practical or doable. Great job there.

That said the implementation has it's flaws, I fixed two of them.

First of all the shutting down of goroutines using the run boolean had a race, so I've added a RWMutex to guard it.
I've changed the boolean to integer so that later when we want to start it again we just keep increasing it on every startup or shutdown.
The goroutine will just compare it's own copy of the integer to know if it should run or not.


My understanding was that, because its creating a new Index instance for each mine_start() to use as a reference, mine_start() instance 1 and mine_start() instance 2 (and all their respective sub-routines) would never be referencing the same run value. Was I incorrect on this?

Quote
Secondly, the parsing of the bitcoin block had a serious problem. The block/transaction was getting parsed into map[string]interface{}.
Problem is maps don't guarantee ordering by key when getting looped.
This could've caused reordering of commitments in some conditions. Whoops.

So I've put there a Block struct that contained slice of tx and tx contains slice of outputs. Problem solved, as slices are ordered.

You should recreate your databases after this fix just to be sure.

Yea that'd be bad. I haven't had it happen yet, all my fingerprints (that I've tested at least) have matched up, but I didn't know that that was a possibility. More reading for me lol.

EDIT: It's been a while since I wrote the initial interp code, but from reading it again it doesn't look like it's pulling the relevant TX sections into map[string]interface{}, but that it's pulling them into []interface{}. This was done for both the initial array of TXes in the block, and the array of outputs in the TX (https://github.com/nixed18/combfullui/blob/master/miner.go, lines 420 and 427). Even if I'm right and it's stable as is, it's still probably worth moving over to a struct system; from what I've read it's faster than using map[string]interface{}.

EDIT2: Could I see your struct implementaion? I've been unable to reuse make_bitcoin_call() without having it output an interface/map[string]interface{} value, and at that point I can't convert back to a struct without marshalling and unmarshalling the JSON for a second time. That seems slow.

EDIT3: I was able to do it by unmarshalling the "result" json into another json.RawMessage, then unmarshalling again. No clue if it's faster but it works, and lets make_bitcoin_call() be used for multiple return values, so that's cool.

Quote
EDIT:
Another problem was that you weren't using pointer receivers when programming in an object oriented way. To highlight the problem:
Code:
func (a A) X() {}
fixed as:
Code:
func (a *A) X() {}
The lack of pointer receivers makes copy of the a each time which makes the original not writable, and could lead to other subtle glitches.

Gotcha, I didn't know you could do that, that's pretty sick.

Quote
Further potential improvements

* Remove the mining/miner api. Only keep the height view set to 99999999 to make sure Modified BTC Does not troll us when we run at port :2121 set on config.
* Write complete block in batch instead of writing every commitment separately. Basically, you can open new leveldb.Batch object then write to it all the commitments. Then, even if computer hard shutdowns due to power loss the leveldb should guarantee that the final block either did or didn't get written completely.
* Change utxo tag to 128bit (Commit position is basically a position of the current commitment is in the block sequentially taking both seen and unseen commitments into account):
Code:
type UtxoTag struct {
    Height uint64
    CommitPositionInBlock uint32
    TransactionNum uint16
    OutputNum uint16
}
* Change on-disk block key to Height uint64 as opposed to Block hash. Then you can distinguish block keys and Commitment keys by their length.
* Implement the block-specific checksum. (Probably a SHA256 of all the commits in the block concatenated in their order). The block-specific checksum can be prepended to the block value whose key is uint64 on-disk:
* Implement storage of block headers. BTC header having 80byte should be recreated from the information provided via the RPC api and put to the database. This makes is feasible to resume the download using a specialized tool that I have in development (the tool will also require access to an API endpoint that will return ALL or the HIGHEST block header).

This gets into next-step territory; modifying the actual miner_mine_commit_internal() process. Cool.

While building the API to get headers, another thing to consider adding is the option to pull commits in a json format. While I don't know about pulling ALL the commits in one go, considering there's like over 3.5 million of them rofl, pulling them in chunks/pages might be practical. It'd allow other programs (i.e. ClaimVision) to access the commits file locally for use, without having to use an html parser to deal with (127.0.0.1:3232/utxo/).

EDIT: I'm confused about your last bit;
Quote
* Change on-disk block key to Height uint64 as opposed to Block hash. Then you can distinguish block keys and Commitment keys by their length.
* Implement storage of block headers. BTC header having 80byte should be recreated from the information provided via the RPC api and put to the database. This makes is feasible to resume the download using a specialized tool that I have in development (the tool will also require access to an API endpoint that will return ALL or the HIGHEST block header).

Right now the block hash information is stored to check for reorgs as the value, not the key. Are you referring to value here? Just making sure, but you're suggesting that we toss block hashes and just use the headers to check for reorgs, right? Why store the block height as a 64-bit, wouldn't a 32-bit be fine?

The way I'm reading the commit proposal is as follows

On-Disk Commits
Code:
KEY: 000000000000006889790000000300000001
VALUE: C78B5DBA7CAD6FA564D60BCF3099D0C80FD4CB75CD1A0FB261A568E35B8F6905

The On-Disk Hashes are currently just
Code:
KEY: 9999999900688979
VALUE: 0000000000000000001103f2f1f374ee8bf36c64949fcd53e47d0174cf063329

Is the replacement format you're suggesting below?
Code:
KEY: 00000000000000688979
VALUE: 010000009500c43a25c624520b5100adf82cb9f9da72fd2447a496bc600b0000000000006cd862370395dedf1da2841ccda0fc489e3039de5f1ccddef0e834991a65600ea6c8cb4db3936a1ae3143991








Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on April 23, 2021, 12:01:24 PM
yes I am right about the run boolean, there was really a race condition bug, I found it using:

 go build -race

The reader of that boolean must take the mutex too, not just the writer.

Sorry I was wrong, you aren't actually looping over the map[string]interface{}, just lookup one value. Thus it's safe.

Yes we need block height ON DISK to be uint64. This is because there will be fast altcombs (with block time 1 second or faster). If we don't do this, we are just repeating the Nakamoto 32bit timestamp bug. (Bitcoin Timestamp Year 2106 Overflow)


Utxo tag IN MEMORY can stay in it's current format for now. ([2]uint32). Can be bumped to match on disk format later.

I also think that the LEVELDB integers (inside keys) should be actual binary (big endian=starting by zeroes from the left) not in Binary coded decimals.
This will ensure that the transaction counter and output counter (both uint16) will be capped at 65535 not 9999.


Inside leveldb blocks (uint64 keys), you can store both the new 32byte block checksum and block header (80byte) concatenated.

The new 32byte block checksum will be SHA256 of Key 1 CAT Commitment 1 CAT Key 2 Commitment 2 CAT etc (all the keys and previously unseen commitments inside the block)




He=BTC Full node

1. read his best hash. if same as our best hash, end, otherwise start loop:
2. read his height
(optional) if his height is 0, feed him all our block headers (by submitheader) starting from genesis+1 and goto 2 (continue loop).
3. read his best hash, if different than read previously goto 2 (continue loop). else goto 4 (break loop).
4. read our block header at his height+do the header's hash.
5. if our hash at his height == his best hash from steps 1 & 3, reorg to his height, end.
6. if his height was less or equal to ours, launch the seek reorg height-by-height backwards procedure, then reorg to it's result. then fast forward, end.
7. read his hash at our height, if equal to ours top hash, fast forward, end.
8. launch the seek reorg height-by-height backwards procedure, then reorg to it's result, then fast forward, end.




seek reorg height-by-height backwards:
1. keep checking his hash at decreasing height until it matches our hash at that height.
2. return the height of highest match.
note: can be done using bisection just keep trying the central height between "highest match"+1 and "lowest non-match"-1.
if the central height was a match, increase "highest match" integer. If the central height was not a match, decrease "lowest non-match" integer. in both cases set the integer to central height and pick a new central height. Terminate when "highest match"+1 == "lowest non-match". This search is efficient even without goroutines.



fast forward:
1. check his hash at our height +1, +2, +3, ....
2. download that block(s).
3. apply them in order from lowest.
4. if applying any block fails, terminate all goroutines and end.
note: can be done by multiple goroutines, if the goroutine's downloaded block is
at current height +1 she will try applying it. otherwise she puts it into a shared map keyed by height and tries
applying the current height+1 block from the map (if it's there).
once the goroutine successfully applies her lowest block, she inspects the map to see if there's another lowest block.
if yes she applies that block too, if no, she goes to check another hash and download another block.
note 2: no need to have unlimited goroutines, just have like 6 of them and wait for them to apply everything using a wait group.
note 3: works without the use of channels, just needs a mutex protected shared map and two shared integer counters (all protected by the same mutex).







Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 23, 2021, 03:12:56 PM
There was a bug in the initial release. When I added in the mining redundancy prevention, I forgot to modify the start block to reflect that, so it misses mining the very first comb commit. This will NOT show up in the AES fingerprint, as it doesn't take into account the height of the commit, only the commits themselves and the order they're loaded, but it will give an inaccurate number for how many total comb have been spawned.

I'll have a newer version up in the next couple of days, I want to test out the struct-based reading first. The correction is to just change the number in the following code to 481823, inst4ead of 481824
Code:
if !u_config.regtest && curr_height < 481824 {
curr_height = 481824
}

yes I am right about the run boolean, there was really a race condition bug, I found it using:

 go build -race

The reader of that boolean must take the mutex too, not just the writer.

That I see and I've fixed, but I was wondering about your change from a bool to an incrementing int.


Quote
Sorry I was wrong, you aren't actually looping over the map[string]interface{}, just lookup one value. Thus it's safe.

I already swapped over to structs. It feels better using more static typing anyways, so I'll run a few commit-build benchmarks and make sure it doesn't slow anything down. If it does then we can switch back.

Quote
Yes we need block height ON DISK to be uint64. This is because there will be fast altcombs (with block time 1 second or faster). If we don't do this, we are just repeating the Nakamoto 32bit timestamp bug. (Bitcoin Timestamp Year 2106 Overflow)

Utxo tag IN MEMORY can stay in it's current format for now. ([2]uint32). Can be bumped to match on disk format later.


Gotcha, that makes sense.

Quote
I also think that the LEVELDB integers (inside keys) should be actual binary (big endian=starting by zeroes from the left) not in Binary coded decimals.
This will ensure that the transaction counter and output counter (both uint16) will be capped at 65535 not 9999.

My understanding was the the fork Natasha did fixes the 9999 max by combining the two into one number. If you look at the formatting of commits that have been processed after the fork, IIRC they're all merged to be stored as one large number. Natasha described it here: https://bitcointalk.org/index.php?topic=5195815.140

I may be misunderstanding something about the fix though.

Quote
Inside leveldb blocks (uint64 keys), you can store both the new 32byte block checksum and block header (80byte) concatenated.

The new 32byte block checksum will be SHA256 of Key 1 CAT Commitment 1 CAT Key 2 Commitment 2 CAT etc (all the keys and previously unseen commitments inside the block)

Oh store them together, that makes way more sense lol.


Quote
He=BTC Full node

1. read his best hash. if same as our best hash, end, otherwise start loop:
2. read his height
(optional) if his height is 0, feed him all our block headers (by submitheader) starting from genesis+1 and goto 2 (continue loop).
3. read his best hash, if different than read previously goto 2 (continue loop). else goto 4 (break loop).
4. read our block header at his height+do the header's hash.
5. if our hash at his height == his best hash from steps 1 & 3, reorg to his height, end.
6. if his height was less or equal to ours, launch the seek reorg height-by-height backwards procedure, then reorg to it's result. then fast forward, end.
7. read his hash at our height, if equal to ours top hash, fast forward, end.
8. launch the seek reorg height-by-height backwards procedure, then reorg to it's result, then fast forward, end.

seek reorg height-by-height backwards:
1. keep checking his hash at decreasing height until it matches our hash at that height.
2. return the height of highest match.
note: can be done using bisection just keep trying the central height between "highest match"+1 and "lowest non-match"-1.
if the central height was a match, increase "highest match" integer. If the central height was not a match, decrease "lowest non-match" integer. in both cases set the integer to central height and pick a new central height. Terminate when "highest match"+1 == "lowest non-match". This search is efficient even without goroutines.

The bisect option makes sense, however the nature of the BTC chain, at least right now, means it's INSANELY likely that a reorg will occur within the fist 2 blocks of the chain edge. I think it makes the most sense to just iterate down the chain, and if the reorg isn't found within the first X iterations then it switches to a bisect search.


Quote
fast forward:
1. check his hash at our height +1, +2, +3, ....
2. download that block(s).
3. apply them in order from lowest.
4. if applying any block fails, terminate all goroutines and end.
note: can be done by multiple goroutines, if the goroutine's downloaded block is
at current height +1 she will try applying it. otherwise she puts it into a shared map keyed by height and tries
applying the current height+1 block from the map (if it's there).
once the goroutine successfully applies her lowest block, she inspects the map to see if there's another lowest block.
if yes she applies that block too, if no, she goes to check another hash and download another block.
note 2: no need to have unlimited goroutines, just have like 6 of them and wait for them to apply everything using a wait group.
note 3: works without the use of channels, just needs a mutex protected shared map and two shared integer counters (all protected by the same mutex).

This is essentially what the current mining system does. The blocks are requested in incremental order as the counter ticks up, but the order it receives and reads in is not fixed. Unfortunately the chokepoint is not how quickly we can read the blocks, but how quickly the BTC can spit them out at us. Although the funneling method you described seems way better than having a bunch of loops checking a timer over and over again, so if that was your intent then nvm that makes sense lol.

You have it written that the goroutine that makes the call is also the one that does the mining. Do you think that this is better than having one dedicated routine to query the map and mine the blocks, and just have the callers dump their blocks in the map? I guess that it makes sense that you're removing a loop that is essentially doing nothing most of the time, waiting for blocks to come in.

I think I get what you're trying to build here, like building a skeleton of the BTC chain and then filling in the blanks as it goes along. Like I said, unfortunately right now the biggest limiter from what I can tell is BTC's speed at supplying the information. But structurally it makes sense.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on April 24, 2021, 03:21:39 PM
I have here a skeleton for the sleep-less channel-less downloading of blocks, could it be integrated? I don't think its a big change.

https://goplay.space/#Yl0k34__XjH

Your explanation about sequential reorg is fine then, let's keep linear.

To finalize the format I think we need to also pull block headers since genesis using getblockheader I think.

Thinking about it, perhaps to simplify things, it would be ok to have a mutex protected global in memory map keyed by blockhash containing the block height.

You know, what you previously did in the level db, but just in memory. In the level db, on disk, there would be the other direction (from height to full header).

Then on startup, the leveldb can be looped over and values cached to memory.

Advice about the migration to the new utxo tag:

1. put the on disk utxo tag struct to the code
2. write a function convert the on disk utxo tag to the old utxo tag (the height is just casted to uint32, based on height before/after fork fill the txnum and outnum or split the output order num uint32 into two uint16 dividing/remaindering by 10000 and return them in the old struct)
2. when downloaded the block, generate the on disk utxo tag and store it next to the commitment.
3. when going to mine the block, don't pass the utxo tag as string but simply as on disk utxo tag struct
4. the strictly_monotonic_vouts_bugfix_fork_height if inside miner_mine_commit_internal can then be removed.
5. all the remaining functions just look at height
6. finally put the old version of the utxo tag to the main map (commits map[[32]byte]utxotag) where the old code does
7. but serialize the new on-disk version of the utxo tag to level db.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 24, 2021, 06:34:51 PM
I have here a skeleton for the sleep-less channel-less downloading of blocks, could it be integrated? I don't think its a big change.

https://goplay.space/#Yl0k34__XjH

Woah that use of the next_mine/next_download variables is cool. Yea I'll try to hook it up, it might take me a sec to fully understand but it looks good.


Quote
Your explanation about sequential reorg is fine then, let's keep linear.

To finalize the format I think we need to also pull block headers since genesis using getblockheader I think.

Can we hard-code the header for block 481822 into haircomb and just use that? It won't work for regtest though, so we can potentially code an option to pull from genesis for those blocks, but if we keep a hard coded pseudo genesis haircomb block then we can cut down of the data storage and the build time. The only risk is somebody 51%ing the entire BTC chain back to 481821, right?

I used 481824 in my code because that's the first block that a commit ever appears on, but Natasha's Modded BTC pulls from 481822 so it makes sense to start from there.


Quote
Thinking about it, perhaps to simplify things, it would be ok to have a mutex protected global in memory map keyed by blockhash containing the block height.

You know, what you previously did in the level db, but just in memory. In the level db, on disk, there would be the other direction (from height to full header).

Then on startup, the leveldb can be looped over and values cached to memory.

Makes sense, a million blocks will only add like 40 mb of memory. But key = hash and value = height, or the other way around? The current leveldb is key = height, value = hash.

Quote
Advice about the migration to the new utxo tag:

1. put the on disk utxo tag struct to the code
2. write a function convert the on disk utxo tag to the old utxo tag (the height is just casted to uint32, based on height before/after fork fill the txnum and outnum or split the output order num uint32 into two uint16 dividing/remaindering by 10000 and return them in the old struct)
2. when downloaded the block, generate the on disk utxo tag and store it next to the commitment.
3. when going to mine the block, don't pass the utxo tag as string but simply as on disk utxo tag struct
4. the strictly_monotonic_vouts_bugfix_fork_height if inside miner_mine_commit_internal can then be removed.
5. all the remaining functions just look at height
6. finally put the old version of the utxo tag to the main map (commits map[[32]byte]utxotag) where the old code does
7. but serialize the new on-disk version of the utxo tag to level db.

This is way better than what I was thinking, I figured we'd have to go through and mod all the code to use a new UTXOtag lol.

I'll try to implement a rough version of this and your new pull code over the next little bit, but I want to confirm the new UTXO struct first. Previously you laid out the following:

Code:
type UtxoTag struct {
    Height uint64
    CommitPositionInBlock uint32
    TransactionNum uint16
    OutputNum uint16
}

Do we need to include the CommitPositionInBlock? I'm not sure what the advantage is to including this.

I'm also concerned about the removal of the fork, because I'm not sure why it was implemented as a fork rather than an entire change like you're proposing here, so the unknown is spooky. But we'll be able to test if this is a problem via fingerprinting, so it should be fine to experiment with.

I'm also going to include the block hash in the block commits fingerprint, unless you think there's a problem doing it. This way there's an explicit tying of the commits to the block header itself, it feels better for some reason.

EDIT: I modded your code to be able to operate from high to low for unmining: https://goplay.space/#2_WoPvMPlLQ. I'll finish merging it tomorrow hopefully.

EDIT2: Running a speed test on the merged code.

EDIT3: As it stands the current code is super slow. I think this is because the info pulling and info mining are tied together; if there are a bunch of blocks queued up to be mined, mining them locks all the other downloaders from depositing their payload and pinging the BTC node for more. In order for this to be fast, the BTC node needs to be under 100% load all the time, which it isn't right now.

EDIT4: I modded the code to have separate mining/pulling processes. It still seems slower for some reason, however my pc is acting up and the old version also seems somewhat slower so I can't really trust it, you might want to give it a shot and see how quick it is for you in comparison. Code's up on my github.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on April 26, 2021, 04:41:28 AM


what needs to happen when reorg back to a specific height (target height):

1. lock the commit_cache_mutex and commits_mutex,
2. make the  utxo tag correspond to the target height, set it's txnum=0, outnum=0, direction=false.
3. Run a for loop from the max height down towards target height:
4. - loop over the commits map. For each commit (key) whose height is equal to the currently unrolled height:
5. - - delete it from the combbases map, if it was there also call segments_coinbase_unmine() at that commit and unrolled height.
6. - - delete it from the commits map.
7. - - if used keys feature is enabled call used_key_commit_reorg(key, currently_unrolled_height)
8. - - call merkle_unmine(key)
9. - - also call the block of code in mine.go starting with txleg_mutex.RLock() and ending with txleg_mutex.RUnlock(), probably refactored to a separate function.
10. - - set unwritten = true if unwritten at least 1 commit
11. - don't do the thing below for every commit (key) anymore, but just for every height:
12. - if unwritten && enable_used_key_feature {used_key_height_reorg(reorg_height);}
13. don't do the thing below for every height anymore, but just once for the entire long range reorg:
14. commit_rollback = nil // to be sure
15. commit_rollback_tags = nil // to be sure
16. lazyopen = false // to be sure
17. resetgraph() // to reflow the entire balance graph
18. Truncate from LEVELDB everything above target height using a batch.
19. adios (unlock the 2 mutexes from step 1)


the nice thing is that you will be able to reorg back to any height, calling this new function once, not just 1 block back.




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 27, 2021, 01:56:41 AM


what needs to happen when reorg back to a specific height (target height):

1. lock the commit_cache_mutex and commits_mutex,
2. make the  utxo tag correspond to the target height, set it's txnum=0, outnum=0, direction=false.
3. Run a for loop from the max height down towards target height:
4. - loop over the commits map. For each commit (key) whose height is equal to the currently unrolled height:
5. - - delete it from the combbases map, if it was there also call segments_coinbase_unmine() at that commit and unrolled height.
6. - - delete it from the commits map.
7. - - if used keys feature is enabled call used_key_commit_reorg(key, currently_unrolled_height)
8. - - call merkle_unmine(key)
9. - - also call the block of code in mine.go starting with txleg_mutex.RLock() and ending with txleg_mutex.RUnlock(), probably refactored to a separate function.
10. - - set unwritten = true if unwritten at least 1 commit
11. - don't do the thing below for every commit (key) anymore, but just for every height:
12. - if unwritten && enable_used_key_feature {used_key_height_reorg(reorg_height);}
13. don't do the thing below for every height anymore, but just once for the entire long range reorg:
14. commit_rollback = nil // to be sure
15. commit_rollback_tags = nil // to be sure
16. lazyopen = false // to be sure
17. resetgraph() // to reflow the entire balance graph
18. Truncate from LEVELDB everything above target height using a batch.
19. adios (unlock the 2 mutexes from step 1)


the nice thing is that you will be able to reorg back to any height, calling this new function once, not just 1 block back.




It doesn't look like you can batch unwrite with this leveldb, just batch write. Let me know if I'm missing something. It should be fine; if the first thing removed from the commitsdb is the associated headers, then even if the process crashes mid-reorg the on-start orphan clean-up should take care of the rest. I'll just pull the relevant commit keys when I'm iterating through the commits map, then remove them from the commitsdb afterwards one by one.

I'm also not sure what you mean by "2. make the  utxo tag correspond to the target height, set it's txnum=0, outnum=0, direction=false." What utxo tag? EDIT: Do you mean the commit_currently_loaded?

I'm assuming you mean the tx_leg code in the the commits_rollback section, not the commits_cache section, correct?

This won't unmine in order of commits within the same block, but that's obvious so I'm assuming its fine.

EDIT2: I got the reorg working, but I ran a full pull and something's wrong with the way I implemented the mining code it seems like, so I'll have to figure that out.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on April 28, 2021, 04:53:17 AM
okay if you can't batch unwrite, we will need to clean up at startup.

take a look at this newminer.go

https://pastebin.com/raw/2RCREVsy (https://pastebin.com/raw/2RCREVsy)


and here is a test RPC server that serves test blocks, the initial height is 500000

https://goplay.space/#2TGEZUC9ezM (https://goplay.space/#2TGEZUC9ezM)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 28, 2021, 05:41:31 AM
okay if you can't batch unwrite, we will need to clean up at startup.

take a look at this newminer.go

https://pastebin.com/raw/2RCREVsy (https://pastebin.com/raw/2RCREVsy)


and here is a test RPC server that serves test blocks, the initial height is 500000

https://goplay.space/#2TGEZUC9ezM (https://goplay.space/#2TGEZUC9ezM)

Holy crap, I was planning on making a JSON api where we could just type out fake block info in a text file, but that's way better. That's awesome.

I actually removed the multi-directional mining because I think it makes more sense to reorg based on stored values. In some unknown case where a commit is stored in a block that gets reorged, but the commit isn't real and doesn't exist on the block, the commit won't get unmined. I guess that maybe this won't matter in the end; storing block fingerprints means this should be detected on start up, but just iterating through the commitsdb and removing all commits that have a height above the reorg target seems like the most simple and effective way to go.

The reorg code I'm using atm is here, your instructions were helpful: https://pastebin.com/raw/HFERMEvy. I had to make some changes to the check/find so they're included, as well as the main() so the integration code is there too. The CommitsLvlDbUnWrite is just a delete func based on the given key.

Let me know if you think there's any advantage to having the multidirectional mine option.

EDIT: Implemented the miner, I'll run a speed test tonight after my BTC catches up. Currently using your reorg but like I said, let me know what you think about just pulling straight from the DB.

EDIT2: Modded the DB load to push the block hashes to the map: https://pastebin.com/raw/31ieUe73

EDIT3: Made some minor rough changes to the fake blocker to receive commands. Right now it's just changing the speed it runs at and pausing/starting it; https://pastebin.com/raw/eqZkJTRY

EDIT4: Ran a full build test; the miner took ~10 hours, so it's as fast the the previous versions, and you fixed whatever was wrong with my variation, so yay!

EDIT5: I got the first bit of the fingerprint/block metadata code working. Right now it doesn't check the fingerprint on load, but it does store the block metadata (fingerprint, hash, height) on mine and load it on load. Code's on my github, there were too many scattered changes to drop it in a pastebin. The miner.go have been removed, and the relevant bits merged into newminer.go. Let me know what you think about the straight-to-db reorg vs the multi-dir mine reorg.

EDIT6: Added fingerprint checking, code's on the github. There's a TON of datatype switching that can be optimized/removed later, but it works for now. I also modded the initial fingerprinting so that now the final fingerprint includes the hash of the block too.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on April 30, 2021, 06:55:45 AM
With interest I looked at the code.

do we intend to support both bidirectional mining and the new and much more
performant handle_reorg function? I suppose the answer is yes, I mean both
codes do pretty much the same thing and it makes sense to let the user choose.

And, supporting both codes using a config option will mean in case we fuckup
we can just tell users to reconfigure their clients instead of upgrading.

Now here is an example of problem that I have in mind (when using the old bidirectional unmining):

1. get_block_info_for_height() is wrong. That code absolutely must request
the block that needs to be reorged by it's block height and hash read from the db/ram.
Because BTC node might switched to different (better) block chain branch.
At that point a call to getblockhash(500000) will return block 500000 from the better
chain that BTC is on, not from the worse chain that we are on (assuming the reorg is
deeper than 500000).

2. the infinite loop inside get_block_info_for_height() should be removed,
we should just return error on any failure, that will terminate the 6 goroutines and
the downloader will reconsider what to do next after 1 second in the main loop.

But being a new function, I notice the imperfection in handle_reorg(), namely
it corrupts the aes checksum, because it erases commitments in random order,
I think the simplest fix would be to sort each block's commitments by their
utxo tag in decreasing order. So, once temp_commits_map gets populated:

Code:
for height := range temp_commits_map {
sort.Slice(temp_commits_map[height], func (i, j int) (less bool) {
return utag_cmp(
&temp_commits_map[height][i].tag,
&temp_commits_map[height][j].tag) > 0;
} )
}

3. I also think I know why the bidirectional unmining is now slow because there is the
function CommitLvlDbUnWriteVal which loops over the entire db I think it can be
eliminated instead:

Code:
CommitLvlDbUnWrite(key, serializeutxotag(ctag))


4. we need to set direction_mine_unmine to UNMINE when reorging (this was previously
done by adding 5000000 to height but thats ugly), in miner_mine_commit_internal:
Code:
	var direction_mine_unmine = utag_mining_sign(tag)
if dir == -1 && direction_mine_unmine == UTAG_MINE  {
direction_mine_unmine = UTAG_UNMINE
}

5. At this point when you set your fake block simulator to quickly reorg blocks,
it will eventually return to the initial situation with checksum of zero

also the database at that point should be cleared. But I still see inside db
the blocks hashes starting at 9999. These need clearing too.





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on April 30, 2021, 04:21:05 PM
With interest I looked at the code.

do we intend to support both bidirectional mining and the new and much more
performant handle_reorg function? I suppose the answer is yes, I mean both
codes do pretty much the same thing and it makes sense to let the user choose.

And, supporting both codes using a config option will mean in case we fuckup
we can just tell users to reconfigure their clients instead of upgrading.


That's a good idea lol, I hadn't considered just running them both xD

I'm just going to use "reorg_type" for both the struct key and the config.txt entry. Ideally we set one as the default and have the second as a fallback, so that unless it was needed the user wouldn't have to care about the entry. Which do you think makes more sense to be the default? Miner or direct?

Quote
Now here is an example of problem that I have in mind (when using the old bidirectional unmining):

1. get_block_info_for_height() is wrong. That code absolutely must request
the block that needs to be reorged by it's block height and hash read from the db/ram.
Because BTC node might switched to different (better) block chain branch.
At that point a call to getblockhash(500000) will return block 500000 from the better
chain that BTC is on, not from the worse chain that we are on (assuming the reorg is
deeper than 500000).

2. the infinite loop inside get_block_info_for_height() should be removed,
we should just return error on any failure, that will terminate the 6 goroutines and
the downloader will reconsider what to do next after 1 second in the main loop.

These both make sense. The way I had it operating before was that a failed BTC call would trigger the btc_manager to send a signal to the miner that would turn "run" off, and then each loop cycle the get_block_info_for_height() would check that run value, and if it was off then it would shut itself down. Looking back on it though it feels a bit overcomplicated.

Quote
But being a new function, I notice the imperfection in handle_reorg(), namely
it corrupts the aes checksum, because it erases commitments in random order,
I think the simplest fix would be to sort each block's commitments by their
utxo tag in decreasing order. So, once temp_commits_map gets populated:

Code:
for height := range temp_commits_map {
sort.Slice(temp_commits_map[height], func (i, j int) (less bool) {
return utag_cmp(
&temp_commits_map[height][i].tag,
&temp_commits_map[height][j].tag) > 0;
} )
}

Oof yea that's not great. In the future we can jump store the commits but this works for now.

Quote
3. I also think I know why the bidirectional unmining is now slow because there is the
function CommitLvlDbUnWriteVal which loops over the entire db I think it can be
eliminated instead:

Code:
CommitLvlDbUnWrite(key, serializeutxotag(ctag))

Yea I added this func for handle_reorg for this exact reason, the code I used was

Code:
func CommitLvlDbUnWrite(address [32]byte, tag []byte) {
err := commitsdb.Delete(tag, nil)
if err != nil {
log.Fatal("Commit UnWrite Error: ", err)
}

// begin aes

var aestmp [32]byte

var aes, err5 = aes.NewCipher(address[0:])
if err5 != nil {
println("ERROR: CANNOT USE CIPHER")
return
}

aes.Decrypt(aestmp[0:16], database_aes[0:16])
aes.Encrypt(aestmp[16:32], database_aes[16:32])

for i := 8; i < 16; i++ {
aestmp[i], aestmp[8+i] = aestmp[8+i], aestmp[i]
}

aes.Decrypt(database_aes[0:16], aestmp[0:16])
aes.Encrypt(database_aes[16:32], aestmp[16:32])

// end aes

}


Quote
4. we need to set direction_mine_unmine to UNMINE when reorging (this was previously
done by adding 5000000 to height but thats ugly), in miner_mine_commit_internal:
Code:
	var direction_mine_unmine = utag_mining_sign(tag)
if dir == -1 && direction_mine_unmine == UTAG_MINE  {
direction_mine_unmine = UTAG_UNMINE
}

Especially considering you wanted to add like 14 digits to the height number, yea adding 50000000 might not be so effective xD

Although if we're getting rid of the +50000000 method then we should probably just straight up remove the utag_mining_sign(tag) portion of the code; it won't serve any function. We'll need to change the flush detection as well at that point.






Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 01, 2021, 12:14:37 AM
There was a bug in the metadata loading process; if there were no commits in a block, the block's metadata would be skipped during loading, and the next attempt at pushing a blocks metadata would push a higher block that was expected and cause a crash. I've updated the CommitLvlDbLoad() with a fix, code is here: https://pastebin.com/qt2EGK0y

In the future a full refactor would make sense once we start including headers; first we can load all the metadata into a temp map, checking as we go along that a) the metadata for a block exists, and b) the headers match up and connect properly for the whole chain. Any break in either of those triggers the orphaning to be set at that height. Then we can go back and load the commits, comparing against their appropriate temp-loaded block metadata; unmatching fingerprint means that orphan mark would be triggered. After we've loaded all the non-orphaned commits, and removed any orphans and their block's metadata, we can then load the remaining blocks into their final map.

Actually I guess we could just load the metadata straight into their map and then remove any orphaned ones, that makes more sense.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 01, 2021, 05:27:25 PM
1. metadata and the complexity on initial commits db load is caused by not using
the proper keys for information.

- Block key in database should be just height uint64 in bytes, not prefixed by 99999.
- Commitment key should be the 128bit utxo tag in bytes (it too starts with 64bit height).

Then you can load everything using one NewIterator loop over the whole db because
block and its commitments are sorted by height and are alternating. You don't need any maps/lists or lookups whatsoever.

So when you see a block (a 64bit key) you flush the previous block (if any) and open a new Sha256 writer for checksum.
When you see a commitment (a 128bit key) you keep mining it as well hashing it into checksum writer.
Now, when you see a 1+ higher block you verify the previous block's checksum matches what you squeeze out of Sha256 writer.
Eventually, the whole db will be loaded or you will experience some kind of an error.
Make sure to check the checksum and flush last block when complete database is loaded (if the db contained at least 1 block of course).

In case of an error:

- A new function needs to be written that will clear commit_cache, commit_tag_cache
while commit_cache_mutex is taken.

- delete all commits and the block at the errored height using a new iterator with just that height as prefix.

- Then you should flip to deletion mode, that is continue the original iterator loop,
just keep deleting everything having a 64bit/128bit key at higher than the errored height.

2. the whole ping_btc_loop+miner_command_channel+miner_output_channel thing should be deleted.
It just makes our normal goroutine stuck communicating a pointless thing inside set_connected(false) when I restart BTC.
btc_is_connected should be a mutexed timestamp integer and set_connected(true) should set it to current time each time BTC responds.
Then, if btc_is_connected is a recent timestamp (not older than 2 seconds) we are CONNECTED.

3. slow CommitLvlDbUnWriteVal is still in place

4. get_block_info_for_height was not fixed. It can't contain loop and must get hash from internal source when dir = -1 NOT from the BTC.

5. what about "case 1" (ourhash_at_btc_height == hash)? Use switch u_config.reorg_type to use handle_reorg_direct in that scenario too.

6. When parsing block, we need to copy PBH (string `json:"previousblockhash"`) to the parsed block.
The function miner (func miner) needs to be modified to return error. It will return error when
PBH is not equal to the topmost block hash in case we are mining with direction 1 and there is at least one (previous=topmost) block already.
The above mentioned previous block error needs to be handled in all three places, there are two places in downloader(): handle them using 
stop_run();return. The remaining place is in mine_blocks(), there, just break the loop in case of this error.

7. I don't know whether direct / miner reorg_type should be the default. That depends on you and your confidence about which one is more
production ready.




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 02, 2021, 01:15:42 AM
1. metadata and the complexity on initial commits db load is caused by not using
the proper keys for information.

- Block key in database should be just height uint64 in bytes, not prefixed by 99999.
- Commitment key should be the 128bit utxo tag in bytes (it too starts with 64bit height).

Then you can load everything using one NewIterator loop over the whole db because
block and its commitments are sorted by height and are alternating. You don't need any maps/lists or lookups whatsoever.

So when you see a block (a 64bit key) you flush the previous block (if any) and open a new Sha256 writer for checksum.
When you see a commitment (a 128bit key) you keep mining it as well hashing it into checksum writer.
Now, when you see a 1+ higher block you verify the previous block's checksum matches what you squeeze out of Sha256 writer.
Eventually, the whole db will be loaded or you will experience some kind of an error.
Make sure to check the checksum and flush last block when complete database is loaded (if the db contained at least 1 block of course).

In case of an error:

- A new function needs to be written that will clear commit_cache, commit_tag_cache
while commit_cache_mutex is taken.

- delete all commits and the block at the errored height using a new iterator with just that height as prefix.

- Then you should flip to deletion mode, that is continue the original iterator loop,
just keep deleting everything having a 64bit/128bit key at higher than the errored height.


I would've thought that the keys would have been ordered in numerical order, not "alphabetical" (so to speak lol), but that makes sense.

Quote
2. the whole ping_btc_loop+miner_command_channel+miner_output_channel thing should be deleted.
It just makes our normal goroutine stuck communicating a pointless thing inside set_connected(false) when I restart BTC.
btc_is_connected should be a mutexed timestamp integer and set_connected(true) should set it to current time each time BTC responds.
Then, if btc_is_connected is a recent timestamp (not older than 2 seconds) we are CONNECTED.

The problem with this is that BTC likes to stall on RPC responses if it's busy validating blocks. If all we're doing is alerting the user to the BTC connection status, then I can just modify the current loop to only run if the timestamp has been longer than X seconds so that the other calls can also trigger it.

Quote
3. slow CommitLvlDbUnWriteVal is still in place

4. get_block_info_for_height was not fixed. It can't contain loop and must get hash from internal source when dir = -1 NOT from the BTC.

5. what about "case 1" (ourhash_at_btc_height == hash)? Use switch u_config.reorg_type to use handle_reorg_direct in that scenario too.

6. When parsing block, we need to copy PBH (string `json:"previousblockhash"`) to the parsed block.
The function miner (func miner) needs to be modified to return error. It will return error when
PBH is not equal to the topmost block hash in case we are mining with direction 1 and there is at least one (previous=topmost) block already.
The above mentioned previous block error needs to be handled in all three places, there are two places in downloader(): handle them using  
stop_run();return. The remaining place is in mine_blocks(), there, just break the loop in case of this error.

I have some time now so I'll bang out all of this stuff over the couple of days.

Quote
7. I don't know whether direct / miner reorg_type should be the default. That depends on you and your confidence about which one is more
production ready.

Lol as far as I'm concerned none of it is yet, but I guess for now I'll go with the mining one because that seems like it's more dynamically integrated and could have more shifting variables, so I'm more likely to mess something up that'll affect it and be aware that it's happened


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 02, 2021, 02:46:37 PM
I would've thought that the keys would have been ordered in numerical order, not "alphabetical" (so to speak lol), but that makes sense.

huh I think it just orders in raw bytes, it would be shame to have blocks wrong-ordered IF leveldb sorts by UTF-8.

The problem with this is that BTC likes to stall on RPC responses if it's busy validating blocks. If all we're doing is alerting the user to the BTC connection status, then I can just modify the current loop to only run if the timestamp has been longer than X seconds so that the other calls can also trigger it.

Yeah those stalls in the GUI are really annoying. I think I fixed it somehow, you know that outer loop in new_miner_start (newminer.go)

This is a standalone test of BTC behavior I needed to check. It can be integrated to comb.

https://goplay.space/#E5EVTWCocOD

Basically I sleep 1/10seconds, then call waitfornewblock RPC. That RPC is almost exactly what we need:

1. it waits until a block added to chain with configurable timeout
2. it returns height+hash in one call! awesome.

One last annoyance is the db completely getting erased when BTC is syncing + at lower height + at the same
chain branch that comb is.

That can be fixed by not reorging in case 1 when btc_is_caught_up=false. Basically we would wait for BTC to reach it's headers height and THEN reorg if needed.

Tell me what you think that is, if there is a worry that the longest valid (heaviest) blockchain would be actually few block shorter than the one comb is on.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 02, 2021, 06:42:28 PM
huh I think it just orders in raw bytes, it would be shame to have blocks wrong-ordered IF leveldb sorts by UTF-8.

You're almost certainly right about this, my lack of computing experience is what led me to assume something that wasn't byte related lol. It'd be idiotic to have a DB that took values in a byte format only to store them in some other ordering.

Quote
Yeah those stalls in the GUI are really annoying. I think I fixed it somehow, you know that outer loop in new_miner_start (newminer.go)

This is a standalone test of BTC behavior I needed to check. It can be integrated to comb.

https://goplay.space/#E5EVTWCocOD

Basically I sleep 1/10seconds, then call waitfornewblock RPC. That RPC is almost exactly what we need:

1. it waits until a block added to chain with configurable timeout
2. it returns height+hash in one call! awesome.

Oh cool, I didn't know that that was a call that existed. That makes everything much simpler lol.

Quote
One last annoyance is the db completely getting erased when BTC is syncing + at lower height + at the same
chain branch that comb is.

That can be fixed by not reorging in case 1 when btc_is_caught_up=false. Basically we would wait for BTC to reach it's headers height and THEN reorg if needed.

Tell me what you think that is, if there is a worry that the longest valid (heaviest) blockchain would be actually few block shorter than the one comb is on.

Maybe the best way to handle this is to just let the user know with a warning, but don't reorg. Similar to how the user gets told that the comb chain is way behind, so balances may look wrong, we can just display a warning like "Commits DB is ahead of the BTC chain. If you are rebuilding the BTC chain please wait for a full resync before operating to make sure your commits are accurate." Or something like that.

EDIT: I slotted in that code, along with the other small fixes mentioned before. Over the next bit I'll do a bit of testing, then move on to refactoring the metadata storage format and processing.

EDIT2: Made a minor change to the code, new parse_wait_for_block() is here: https://pastebin.com/raw/psXFsZbU
If you launch Haircomb before launching the BTC, and then launch the BTC, Haircomb's first (few?) RPC results will be "null", but not be detected as an error. This changes that.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 03, 2021, 07:55:37 PM
new  parse_wait_for_block looks good!

I went ahead and implemented the proposed format into the leveldb as well as the use of leveldb.Batch. The leveldb options
are also in use namely to disable compression and enable Sync (this is needed for db to survive power loss - was not tested actually
doing the computer power loss, but should work).

commitfilelvldb.go

https://pastebin.com/raw/c1GDhpAy

mine.go

https://pastebin.com/raw/bM50zwAR

newminer.go

https://pastebin.com/raw/4GrvKpUq

utxotag.go

https://pastebin.com/raw/7rDLYNRY

Overall I've fixed a few bugs:

1. In miner(), when reorging with direction -1 the second topmost block must be compared with previous hash, not the topmost, and the termination condition should be one_or_no_blocks()
2. miner() again, it should Put the block only with direction +1
3. rare race condition in mine_blocks. A local copy of next_download variable is needed to terminate the for loop, because if we use the global one, the goroutines that we spawn may increase that same global next_download, which could then lead to two goroutines to download a certain height and mine the same block twice.


What remains is, use btc_is_caught_up_mutex on the main page, remove mining subrouter s3 from main.go, clear stale code from commitfile.go


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 04, 2021, 01:19:00 AM
new  parse_wait_for_block looks good!

I went ahead and implemented the proposed format into the leveldb as well as the use of leveldb.Batch. The leveldb options
are also in use namely to disable compression and enable Sync (this is needed for db to survive power loss - was not tested actually
doing the computer power loss, but should work).

commitfilelvldb.go

https://pastebin.com/raw/c1GDhpAy

mine.go

https://pastebin.com/raw/bM50zwAR

newminer.go

https://pastebin.com/raw/4GrvKpUq

utxotag.go

https://pastebin.com/raw/7rDLYNRY

Overall I've fixed a few bugs:

1. In miner(), when reorging with direction -1 the second topmost block must be compared with previous hash, not the topmost, and the termination condition should be one_or_no_blocks()
2. miner() again, it should Put the block only with direction +1
3. rare race condition in mine_blocks. A local copy of next_download variable is needed to terminate the for loop, because if we use the global one, the goroutines that we spawn may increase that same global next_download, which could then lead to two goroutines to download a certain height and mine the same block twice.


What remains is, use btc_is_caught_up_mutex on the main page, remove mining subrouter s3 from main.go, clear stale code from commitfile.go

Holy cow dude, talk about industrious rofl. A lot of this stuff is Golang that I don't know yet, so that's great for me, time to do some learning lol. I guess now I'll start expanding the fake_block code.

One thing to note, your code removed the duration from the WaitForBlock struct, I re-added it in when merging. Looking at the code more it seems like I could've also just removed the duration check from the parse_wait_for_block() function though, I guess it's not exactly used now.

One thing I noticed recently, that may be an issue, every now and then when I was testing stuff in regtest the Haircomb mining loop wouldn't trigger the BTC rpc. It started happening after implementing the new waitfornewblock call; I'm not sure if a problem that's unique to regtest or not, but it's something to look out for. The solution was just to restart the BTC, everything started working again no problem.

I've pushed the code to my github so if anybody else is reading and wants to test it, go right ahead. I've just commented out some of the incompatible commitfile.go and left the rest in there for possible future inclusion of that legacy commit file option you were talking about before.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 04, 2021, 09:20:25 PM
last things

1. make log file optional and specify the log file name in config.txt, if none or by default don't log.
2. config file should also be optional, we will change the default port to 2121 again, users are used to it.
3. Default rpc password / username should be empty string. It can be used no problem with BTC if you set
that in BTC config (if someone is in rush and doesn't care about security/syncing they won't be making a config file).
4. up the version counter for beta in deployment.go (need to increase it every time when releasing something,
because otherwise there would be versions in the wild that we won't be able to tell what it is later, it's ok to
skip versions)

minor things

message about use 546 sats to claim, change to 330 sats, (it's cheaper).

the message on the main page "COMB height is greater than BTC" is by itself ok but should be reworded,
probably something like "COMB height is different than BTC".

check_btc_is_caught_up() had no boolean result, check it before release, go build should pass

remove fmt.Println(hash), fmt.Println(segments_stack) from stack.go, it just
spams every time I sweep coins. It's not needed.

in general, turn our debug statements that we added so far into log printing or something,

When releasing beta, the less printing on console the better. Except when the coin
crashes. When a new dev joins he/she can put their own debug prints and see them,
not search for their own prints in a pile of spam.

Testnet tools:

To decode bc1 address into witness program:

http://bitcoin.sipa.be/bech32/demo/demo.html (http://bitcoin.sipa.be/bech32/demo/demo.html)

To encode witness program back, but into testnet tb1 address (can be used to claim tesntet comb).

https://bc-2.jp/tools/bech32demo/index.html (https://bc-2.jp/tools/bech32demo/index.html)

Bitcoin command for testnet (prune needs to be high, because with low prune the BTC
will escape from and Comb will get fall behind unable to sync the blocks - "wrong height" ):

Code:
./bitcoin-qt -server -prune=55000 -rpcuser= -rpcpassword= -rpcport=8332 -testnet

Can generate brainwallet for testnet using:

http://127.0.0.1:2121/wallet/brain/<number of keys>/<brainpass> (http://127.0.0.1:2121/wallet/brain/<number of keys>/<brainpass>)

We've already synced with testnet. Let's hit faucet, get some testnet bitcoins, and claim some testnet comb.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 05, 2021, 02:08:57 AM
Testnet tools:

To decode bc1 address into witness program:

http://bitcoin.sipa.be/bech32/demo/demo.html (http://bitcoin.sipa.be/bech32/demo/demo.html)

To encode witness program back, but into testnet tb1 address (can be used to claim tesntet comb).

https://bc-2.jp/tools/bech32demo/index.html (https://bc-2.jp/tools/bech32demo/index.html)

Bitcoin command for testnet (prune needs to be high, because with low prune the BTC
will escape from and Comb will get fall behind unable to sync the blocks - "wrong height" ):

Code:
./bitcoin-qt -server -prune=55000 -rpcuser= -rpcpassword= -rpcport=8332 -testnet

Can generate brainwallet for testnet using:

http://127.0.0.1:2121/wallet/brain/<number of keys>/<brainpass> (http://127.0.0.1:2121/wallet/brain/<number of keys>/<brainpass>)

We've already synced with testnet. Let's hit faucet, get some testnet bitcoins, and claim some testnet comb.

Well that's useful.

I've done all the other stuff, but I don't see how you're getting BTC to run properly with a blank rpc user/pass. If the bitcoin.conf has "rpcuser=" and "rpcpassword=", it's smart enough to know nothing is there and instead spawn and use a cookie file for the relevant info.

Unless I'm missing something, if we want to allow the user to operate COMB without using a config, then we need to set default info (i.e. "user" and "pass") and tell them to insert those into the bitcoin.conf file. I've set it up and modded the error message, but let me know if I'm missing something.

I also just merged the "btc is behind" alert into the "wallet isn't synced" alert, let me know if you think it should be more specific or not.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 05, 2021, 10:23:31 AM
blank credentials by default are needed when:

 - when running offline/no reason/intention to sync
 - when syncing using a future tool (to be developed), that tool would run on :8332
   and serve blocks from the Bitcoin P2P network. That won't require the BTC RPC/server
   option, and by extension our config file won't be needed.

in any case new_miner_start() must go, even with blank credentials

the blank credentials cannot be entered into bitcoin's config file. that's exactly
what we need! the user who is capable to edit config files won't be able to do the
wrong thing but will instead be forced to set identical strong credentials in both files.

can't comment on merged main page non synced messages, I don't see the code.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 05, 2021, 01:54:28 PM
blank credentials by default are needed when:

 - when running offline/no reason/intention to sync
 - when syncing using a future tool (to be developed), that tool would run on :8332
   and serve blocks from the Bitcoin P2P network. That won't require the BTC RPC/server
   option, and by extension our config file won't be needed.

in any case new_miner_start() must go, even with blank credentials

the blank credentials cannot be entered into bitcoin's config file. that's exactly
what we need! the user who is capable to edit config files won't be able to do the
wrong thing but will instead be forced to set identical strong credentials in both files.

Right now new_miner_start() runs without credentials, it's the make_bitcoin_call() that stalls out without them. I may be taking your statement too literally here though lol. As far as I am aware, there is no way to connect to BTC over RPC WITHOUT a username and password. There are currently 3 options;

1. Config username and password. What we've been using so far.

2. Cookie file. In the absence of a username and password in its config, BTC will generate a .cookie file that has a username and password to use in it. While we could pull the username and password automatically from said file, we'd still need the user to indicate the path to that file. The only option I see, other than having the user place combfullui in the same folder as .cookie, is to use a config file to communicate the path.

3. RPCAuth. This is just a more complicated version of user/pass that generates a config entry for you, which you then have to place in your bitcoin.conf file.



Quote
can't comment on merged main page non synced messages, I don't see the code.

Code:
if height < uint64(fakeheight) || (check_connected() && last_known_btc_height!= -1 && last_known_btc_height < int(our_top_block().Height)) {
fmt.Fprintf(w, `<h1>Wallet appears to be out of sync. Displayed balances are incorrect until wallet is fully synced:</h1>`)
}

I pushed the code so its on my github now, sorry I blanked before lol.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 05, 2021, 03:20:17 PM
I will ask you differently, do you wanna take responsibility for angry users
who had their BTC wallets wiped clean by malware running on other computers on their network, because they
have typed "user" & "pass" into their bitcoin.conf, just like your software recommended.

I also considered the solution in which we generate a random long user + pass on startup,
but it's worth shit because it changes every startup and nobody will be arsed to change
it every time (in bitcoin.conf).

What we want is zero configuration. That will be possible by a middle man software. As follows:

1. user downloads bitcoin from bitcoin.org and starts it
2. user downloads a middle man software that don't exist today but will later (once we do it)
3. user downloads haircomb core
4. user starts all 3 programs above
5. haircomb core starts syncing no config needed.

this will be possible because:
1. haircomb core will request blocks from port 8332 (RPC PORT)
2. middle man SW that listens on port 8332 will redirect the requests to port 8333 where the Bitcoin
is already listening on the peer to peer network. (In the correct format). This is true by default
on Bitcoin core, without any configuration.
3. Bitcoin normally transmits the blocks to middleman (in a special format, NOT in JSON)
4. Middleman transits the required blocks to the comb core (in JSON)


What are the possible obstacles to this zero configuration????

1. Bitcoin already running on 8332. The middle man will then fail to run. The middle man program
will recommend to delete both BTC and COMB config files.

2. Old version of comb ( the one we are developing right now) will fail to run without a config file!! (this problem needs to be solved RN)

3. Old version of comb recommending the wrong thing when config file have blank credentials or not found. It must not fail with error and it must keep connecting to the middle man with blank credentials despite of the credentials being blank.

4. Middleman software not being available (this will be solved soon)

5. Blank credentials not being testable - sure, not on BTC, but the fake block simulator will serve you something even with blank credentials.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 05, 2021, 04:50:02 PM
I will ask you differently, do you wanna take responsibility for angry users
who had their BTC wallets wiped clean by malware running on other computers on their network, because they
have typed "user" & "pass" into their bitcoin.conf, just like your software recommended.

I also considered the solution in which we generate a random long user + pass on startup,
but it's worth shit because it changes every startup and nobody will be arsed to change
it every time (in bitcoin.conf).

This is where using the BTC .cookie file makes sense, but the user still needs to provide the path in some way.

Quote
What we want is zero configuration. That will be possible by a middle man software. As follows:

1. user downloads bitcoin from bitcoin.org and starts it
2. user downloads a middle man software that don't exist today but will later (once we do it)
3. user downloads haircomb core
4. user starts all 3 programs above
5. haircomb core starts syncing no config needed.

this will be possible because:
1. haircomb core will request blocks from port 8332 (RPC PORT)
2. middle man SW that listens on port 8332 will redirect the requests to port 8333 where the Bitcoin
is already listening on the peer to peer network. (In the correct format). This is true by default
on Bitcoin core, without any configuration.
3. Bitcoin normally transmits the blocks to middleman (in a special format, NOT in JSON)
4. Middleman transits the required blocks to the comb core (in JSON)


I understand this, but I don't see how it'll be possible to completely eliminate the need for config files right now, before the middleware is developed.

Quote
What are the possible obstacles to this zero configuration????

1. Bitcoin already running on 8332. The middle man will then fail to run. The middle man program
will recommend to delete both BTC and COMB config files.

2. Old version of comb ( the one we are developing right now) will fail to run without a config file!! (this problem needs to be solved RN)

3. Old version of comb recommending the wrong thing when config file have blank credentials or not found. It must not fail with error and it must keep connecting to the middle man with blank credentials despite of the credentials being blank.

4. Middleman software not being available (this will be solved soon)

5. Blank credentials not being testable - sure, not on BTC, but the fake block simulator will serve you something even with blank credentials.

The current version of COMB I have up does not require the config to run, only to access the BTC RPC. I'm not sure exactly what you're trying to convey here; if what you're saying is that the current version of COMB MUST be able to access the BTC and pull blocks without any sort of config file, then I'd love to hear how you think it could be done, because I don't see how to accomplish that. Unless you're suggesting a modification to the current program so that it DOESN'T use the RPC, and instead pulls over 8333 then converts to JSON, but that's just the middleware solution.

So again, I'm not 100% sure exactly what you're proposing the steps forwards are; accessing the BTC RPC requires authentication, either the user provides said authentication or they can't pull over the BTC RPC. We can either attempt to make the provision of the authentication easier, or circumvent the RPC via the P2P network. The most non-intrusive way to have the COMB client and the BTC client communicate is using the .cookie file, but COMB needs to know where that file will be. This means that a) the user will have to provide a path to their BTC data dir, via config file or some other means, or b) the user will have to place combfullui WITHIN the BTC data dir. We can set up either of these options, but you seem fairly adamant that COMB should not require a config file in the slightest, which just leaves the user dumping combfullui in the same directory as the .cookie file.

The reason that the BTC call fails with blank creds isn't anything hard coded into COMB; BTC just doesn't return a usable value. Right now the only time that COMB will say "Hey, put in credentials" is if it attempts to contact BTC and gets a bad response back.

EDIT: We could also create an option to submit the BTC datadir path via the COMB UI, and then have COMB save the path to a file in a hidden directory like APPDATA or something. Then the user doesn't have to create a txt file and paste the path in there, but they still have to find the path and paste in in the browser somewhere so I dunno if it's really that much better.

EDIT2: In the same vein as the previous example, we can combine it with your suggestion; on startup COMB generates a random user/pass, then references a path to the bitcoin.conf, and edits bitcoin.conf to contain rpcuser=x and rpcpassword=y. This just seems like a more convoluted version of the cookie solution though, and would also require the user to always start COMB BEFORE BTC, like before.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 05, 2021, 05:32:10 PM
the change 2 minutes ago looks good

☑ default credentials are blank
☑ user warned to configure both programs with the same credentials when comms fails
☑ we'll find any bugs during beta testing

feel free to tag the beta!



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 06, 2021, 01:49:42 PM
Haircomb Core v0.3.4-beta.1 is up here: https://github.com/nixed18/combfullui/releases/tag/0.3.4-beta.1

Build (Optional)

Do the same steps as the normal combfullui (https://bitcointalk.org/index.php?topic=5195815.msg54605575#msg54605575) but with two differences:

1.1. Rather than cloning a github repo, click on "Code" and download the zip file located here: https://github.com/nixed18/combfullui/tree/338d2775d1a5d894259ed1c6b728e251ef432b5a. Move that folder into the location you want to build COMB and extract it, and continue with the build instructions.
 
2. Type in "go get github.com/syndtr/goleveldb/leveldb" to install LevelDB


Set up bitcoin.conf

1. Navigate to the directory where you have stored your BTC blockchain. By default it is stored in C:\Users\YourUserName\Appdata\Roaming\Bitcoin on Windows. You'll know you're there when you see blocks and chainstate folders, along with some .dat files for stuff like the mempool, peers, etc.

2. Look for a file named "bitcoin.conf". If one doesn't exist, make one by right clicking the whitespace and going New>TextFile. Then rename this file to "bitcoin.conf"

3. Open "bitcoin.conf" in Notepad and add the following two entries, replacing XXXXX with what you want your log info to be. This is only used for your BTC node's RPC access.
Code:
rpcuser=XXXXX
rpcpassword=XXXXX

4. Save and exit


Set up config.txt

1. Navigate to the directory you installed the Haircomb beta.

2. Create a text file called "config.txt".

3. Open "config.txt" in Notepad, and add the following lines, replacing the XXXXX with the same values that you used in your "bitcoin.conf".
Code:
btcuser=XXXXX
btcpass=XXXXX

4. Save and exit. If Haircomb was open during this edit, you must restart the program for your changes to take effect.


Run

Assuming you're using an unmodded BTC, you can run either BTC or Haircomb first, it doesn't matter. While Haircomb is running, it'll keep checking if there's a BTC server running on your machine, and if so, will attempt to connect with it. When you run BTC, either run bitcoind.exe OR run bitcoin-qt.exe with "-server" as an argument. It is also compatible with Natasha's modded BTC, but just remember to launch Haircomb BEFORE the modded BTC.

Watashi has provided instructions and resources to run the beta using the BTC testnet, those can be found here: https://bitcointalk.org/index.php?topic=5195815.msg56935798#msg56935798


The current version's default port is 2121, this can be changed in the config.txt file with the entry "port=XXXX", replacing XXXX with a valid port number. Selecting the direct reorg handle to test can be done by inserting "reorg_type=miner" into your config.txt


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 06, 2021, 01:53:37 PM
Watashi, the program you're working on, am I correct in assuming it's similar to the other program you published a while ago in that it would remove the need for a full node to be running to sync from, and would instead request blocks from peers? If so, then am I also correct in assuming that it will likely take longer to do a full commits build?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 08, 2021, 11:39:39 AM
Yeah, In case the local node is a full node, the sync would take nearly the same time.
In case the local node is a pruned node, some blocks would have to be pulled over the network, this sync would be slower and capped by the local internet speed.

TESTING

☑ Successful / unsuccessful claiming works.
☑ Transaction works.
☑ Naive double spend is caught correctly.
☑ Liquidity stack loops working.
☑ Coin loop detection worked ok so far.

2 minor severity issues - both existing in the Natasha version too

Issue 1 - Brain wallet keys not added to the used key feature.

Problem: when creating a brain wallet using the HTTP call, the keys that get
generated aren't added to the used key feature. This means once the keys become
used, node restarted and brain wallet re-generated, it will not be visible that
the used key is already spent.

In function: wallet_generate_brain

Solution: copy the "if enable_used_key_feature" lines from the normal key generator
(key_load_data_internal) into wallet_generate_brain too.

Issue 2 - Used keys balance should be forced to be 0 COMB on the user interface on detected outgoing key spend

Problem: when a key is spent, but the transaction is not added to the node using the link, the node will keep
displaying the old balance - the old key balance (nonzero) will be visible even in the event of 1+  confirmations.

Discussion: This is not a consensus issue, if the user attempts double spending using the nonzero balance,
the double spend will get caught and dropped normally.

In function: wallet_view

Solution: In the wallet printing loop, move the used_key_feature block above printing the wallet key+balance row. Inside the used_key_feature block,
set the balance (bal) to zero if outgoing spend got recognized. Finally, print the outgoing spend row below the walled key+balance row from a temp variables.

While we're fixing this, we may also hide the pay button in case of reorg to save user from accidentally double-spending.
 
Reference wallet.go
https://pastebin.com/raw/cLdG5pB3 (https://pastebin.com/raw/cLdG5pB3)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 08, 2021, 09:09:34 PM
I'm investigating a max severity crasher issue in comb trades facility (merkle.go)

In the mean time, all users must cease using comb trades for any sort of commerce.

I have a preliminary fix, here:

merkle.go https://pastebin.com/raw/CUUnVbEe
txlegs.go https://pastebin.com/raw/vgfRjNYF

it's a rather large overhaul of the facility.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 09, 2021, 12:46:50 AM
I haven't done any real diving into the tx portion of COMB yet, so I'm afraid I won't be much help here.

I ask about the block pulling because I'm curious if it makes sense to aim for, in the future, segmented orphan repair. Right now if a block is corrupted the entire chain after said block is discarded; using the current block-by-block fingerprinting, as well as including the hash of the previous block's metadata, it seems viable to allow Haircomb to just discard only the corrupted blocks, and redownload them.

I'm not sure if I'm being paranoid or making up corruption scenarios that don't exist though, so I dunno if it's actually worth doing or not right now.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 09, 2021, 11:48:00 AM
well I see, in my opinion repairing 1 block doesn't make sense, purely because
a) BTC node isn't guaranteed to be present
b) even if BTC node is present, how do you know it won't send the wrong information again
c) even if it sends the right information, you will need to download all the blocks after that blocks
anyway, for example in case a previously unseen commitment abc...123 was fixed by being "removed" from block 500000 (because it isn't there), all
the 500000+ blocks need to be inspected to confirm that abc...123 doesn't appear there again to "add it" (make it previously unseen in a later block).
d) so you can pretty much repair only errors that are fixed by "adding" commitments, and you will still need to fix up later blocks to remove from them
e) all of this makes it pretty narrow scoped as opposed to node operator simply copying over the "right" database to the node from a known good backup.


here is my final fix for the high severity problem. Only difference between the preliminary fix and this is the removal of the mutex commits_mutex locks+unlocks in the two cases (merkle_mine+merkle_unmine) where it's being held already and it would just cause a deadlock.

merkle.go https://pastebin.com/raw/SR2Y83Qt (https://pastebin.com/raw/SR2Y83Qt)
txlegs.go https://pastebin.com/raw/vgfRjNYF (https://pastebin.com/raw/vgfRjNYF)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 09, 2021, 02:42:33 PM
well I see, in my opinion repairing 1 block doesn't make sense, purely because
a) BTC node isn't guaranteed to be present
b) even if BTC node is present, how do you know it won't send the wrong information again
c) even if it sends the right information, you will need to download all the blocks after that blocks
anyway, for example in case a previously unseen commitment abc...123 was fixed by being "removed" from block 500000 (because it isn't there), all
the 500000+ blocks need to be inspected to confirm that abc...123 doesn't appear there again to "add it" (make it previously unseen in a later block).
d) so you can pretty much repair only errors that are fixed by "adding" commitments, and you will still need to fix up later blocks to remove from them
e) all of this makes it pretty narrow scoped as opposed to node operator simply copying over the "right" database to the node from a known good backup.


here is my final fix for the high severity problem. Only difference between the preliminary fix and this is the removal of the mutex commits_mutex locks+unlocks in the two cases (merkle_mine+merkle_unmine) where it's being held already and it would just cause a deadlock.

merkle.go https://pastebin.com/raw/SR2Y83Qt (https://pastebin.com/raw/SR2Y83Qt)
txlegs.go https://pastebin.com/raw/vgfRjNYF (https://pastebin.com/raw/vgfRjNYF)

I was thinking more along the line of some unseen problem causing a corruption in the commits db, not a wrong input from the BTC. So the scenario would assume that, at one point, Haircomb did have a full, correct commits db file, and then something happened to cause one or more blocks to become corrupted. But you're right, it makes a lot more sense just to restore form a backup in this case.

EDIT: Updated the github and have a new release for the patches, I haven't had a chance to properly test it yet though.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 15, 2021, 12:54:28 PM
I've been testing busily and found numerous problems. Let's start with the simpler ones.

used_key.go - used_key_add_new_minimal_commit_height - when deleting from slices l is always 31

instead of:

Code:
l := len(v) - 1

there needs to be the length of the actual slice:

Code:
l := len(used_height_commits[min_height]) - 1

and

Code:
l := len(used_commit_keys[min_commit]) - 1

Explanation: taking length of v which is a hash (always of size 32) is not the intention.

newminer.go - handle_reorg_direct - off by one error in direct mode causes "holes" in database

the fix is rather simple:

Code:
iter := commitsdb.NewIterator(&util.Range{Start: new_height_tag(uint64(target_height)+1), Limit: new_height_tag(uint64(height+1))}, nil)


newminer.go - miner - when reorging we need to provide the height of previous block (not of the reorged one) to become the topmost block

Code:
       // Flush
       var commit_fingerprint hash.Hash
       if dir == -1 {
               commit_fingerprint = miner_mine_commit_pulled("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF",
                       new_flush_utxotag(uint64(parsed_block.height)-1), 0)
       } else if dir == 1 {
               commit_fingerprint = miner_mine_commit_pulled("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF",
                       new_flush_utxotag(uint64(parsed_block.height)), 0)
       }

Explanation:  the current reorged one 's previous block height should become the topmost by posttag() inside miner_mine_commit_internal(). If we don't do this,
the check "error: mined first commitment must be on greater height" will wrongly prevent one block after a reorg to get mined in miner mode.

There are a threading problems as well, that I will explain in a later post.





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 19, 2021, 02:59:07 PM
I committed the changes, I'll wait until you go over the threading problem before building a new release. I'm waist deep in some work stuff but I'll do my best to keep up lol.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 19, 2021, 09:03:30 PM
Ah, the thread thing.

Sorry for not having an exact solution you can apply right now.

It's caused by segments_transaction_mutex and
segments_merkle_mutex mutexes. They protect mainly the maps that tell you
where money should go from transaction address, for merkle transaction (comb trade)
the map is named e0_to_e1 and for haircomb transaction the map is named
segments_transaction_next. The key in both maps is some kind of used (spent) address,
and the value is the next address where all that money should move next.
Actually segments_transaction_next contains the txid too.

Because the logic is the same - the locking should be the same but it isn't, that's the bug.
When you look at segmenttx.go and segmentmerkle.go - that is the money trickling
code.

There are two avenues to fix this one would be simply surround each read from the map(s)
with RLock RUnlock.
This option sounds right for consensus-non-critical paths like inside:
Code:
segments_transaction_loopdetect()
segments_transaction_backgraph()
segments_merkle_loopdetect()
segments_merkle_backgraph()

This is easy.

Another part is to NOT surround each read from the map with RLock RUnlock but instead
the whole invocation of the trickling  is guarded at the highest level.
This part sounds right for consensus critical like balance calculation. This will prevent
somebody to add new transactions while the money is still being propagated along the graph.
Once the dust settles, the queued new transaction adding gets the green light.

Example from txrecv.go, there are other similar top-level places that call into trickling code.
Code:
if newactivity == 2097151 {

Lock(segments_transaction_mutex)

segments_transaction_next[actuallyfrom] = txidandto

Unlock(segments_transaction_mutex)

RLock(segments_transaction_mutex)
RLock(segments_merkle_mutex)

var maybecoinbase = commit(actuallyfrom[0:])
if _, ok1 := combbases[maybecoinbase]; ok1 {
// ...invoke coinbase trickling in case the haircomb was a coinbase
segments_coinbase_trickle_auto(maybecoinbase, actuallyfrom)
}

//..invoke cash trickling here:
segments_transaction_trickle(make(map[[32]byte]struct{}), actuallyfrom)

RUnlock(segments_merkle_mutex)
RUnlock(segments_transaction_mutex)

}
The reason why both read mutexes are taken is that transaction can pay to merkle
transaction which could cause transaction money trickling become merkle tx money trickling.




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 22, 2021, 08:57:05 AM
Here are changes for fixing the racing problems.

1. segmentmerkle.go remove all uses of segments_merkle_mutex RLock() and
RUnlock(), toplevel callers will have to lock that
instead.

code omitted

2. anonminize.go, add 2 mutexes rlock and runlock around segments_coinbase_backgraph:
Code:
	for combbase := range bases {
segments_transaction_mutex.RLock()
segments_merkle_mutex.RLock()

segments_coinbase_backgraph(backgraph, make(map[[32]byte]struct{}), target, combbase)

segments_merkle_mutex.RUnlock()
segments_transaction_mutex.RUnlock()

}
   
3. loopdetect.go, add 2 mutexes rlock and runlock to loopdetect() function:
Code:
func loopdetect(norecursion, loopkiller map[[32]byte]struct{}, to [32]byte) (b bool) {
segments_transaction_mutex.RLock()
segments_merkle_mutex.RLock()

var type3 = segments_stack_type(to)
if type3 == SEGMENT_STACK_TRICKLED {
b = segments_stack_loopdetect(norecursion, loopkiller, to)
}
var type2 = segments_merkle_type(to)
if type2 == SEGMENT_MERKLE_TRICKLED {
b = segments_merkle_loopdetect(norecursion, loopkiller, to)
}
var type1 = segments_transaction_type(to)
if type1 == SEGMENT_TX_TRICKLED {
b = segments_transaction_loopdetect(norecursion, loopkiller, to)
} else if type1 == SEGMENT_ANY_UNTRICKLED {
} else if type1 == SEGMENT_UNKNOWN {
}
segments_merkle_mutex.RUnlock()
segments_transaction_mutex.RUnlock()
return b
}

4. merkle.go commits mutex MUST be taken when call merkle_scan_one_leg_activity() here:
Code:
	commits_mutex.RLock()
var allright1 = merkle_scan_one_leg_activity(q1)
var allright2 = merkle_scan_one_leg_activity(q2)

if allright1 && allright2 {
reactivate_txid(false, true, tx)
}

commits_mutex.RUnlock()
return true, e[0]
and add 2 mutexes rlock and runlock:

      
Code:
if newactivity {
segments_transaction_mutex.Lock()
segments_merkle_mutex.Lock()
if old, ok1 := e0_to_e1[e[0]]; ok1 && old != e[1] {

fmt.Println("Panic: e0 to e1 already have live path")
panic("")
}

e0_to_e1[e[0]] = e[1]
segments_merkle_mutex.Unlock()
segments_transaction_mutex.Unlock()

segments_transaction_mutex.RLock()
segments_merkle_mutex.RLock()

var maybecoinbase = commit(e[0][0:])
if _, ok1 := combbases[maybecoinbase]; ok1 {
segments_coinbase_trickle_auto(maybecoinbase, e[0])
}

segments_merkle_trickle(make(map[[32]byte]struct{}), e[0])

segments_merkle_mutex.RUnlock()
segments_transaction_mutex.RUnlock()

}
      
      
5. mine.go add write locking:

Code:
        if *tx == (*txidto)[0] {
                segments_transaction_mutex.Lock()
                segments_transaction_next[actuallyfrom] = *txidto
                segments_transaction_mutex.Unlock()
                return false
        }

change 2 add toplevel locking:

Code:
	segments_transaction_mutex.RLock()
segments_merkle_mutex.RLock()

var maybecoinbase = commit(actuallyfrom[0:])
if _, ok1 := combbases[maybecoinbase]; ok1 {
segments_coinbase_trickle_auto(maybecoinbase, actuallyfrom)
}

segments_transaction_trickle(make(map[[32]byte]struct{}), actuallyfrom)

segments_merkle_mutex.RUnlock()
segments_transaction_mutex.RUnlock()

change 3:

Code:
	segments_transaction_mutex.RLock()

var val = segments_transaction_data[*tx][i]

segments_transaction_mutex.RUnlock()

change 4:

Code:
	if oldactivity == 2097151 {
segments_transaction_mutex.Lock()
       
var actuallyfrom = segments_transaction_data[*tx][21]

segments_transaction_untrickle(nil, actuallyfrom, 0xffffffffffffffff)

delete(segments_transaction_next, actuallyfrom)

segments_transaction_mutex.Unlock()
}


6. stack.go surround stack trickle with mutexes:

Code:
	segments_transaction_mutex.RLock()
segments_merkle_mutex.RLock()

segments_stack_trickle(make(map[[32]byte]struct{}), hash)

segments_merkle_mutex.RUnlock()
segments_transaction_mutex.RUnlock()


7. txrecv.go tx_receive_transaction_internal(), take both mutexes:

Code:
	segments_transaction_mutex.Lock()
segments_merkle_mutex.Lock()
   
and

Code:
	segments_merkle_mutex.Unlock()
segments_transaction_mutex.Unlock()





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 29, 2021, 02:44:08 PM
Sorry I wasn't very helpful on this end, I'll commit the changes and build a new release later today.

EDIT: Jesus christ, I spent so long just looking at the mining code I forgot how complex the guts of this thing actual are. I gotta get more familiar with it.

I've added the changes and committed it to github, if I didn't mess anything up then I'll build a new release. How did you figure out that this was an issue? Was it just code scanning, or did you generate a crash during testing?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 31, 2021, 05:41:24 PM
The racing problems- I'm catching them while running go build -race and reorging blocks and loading wallets at the same time.


Now there is a mistake at line 231 in merkle.go - there needs to be commits_mutex.RUnlock()

That's all. I've also tested the nested comb trades. They work properly.

I'm ok with the final version - can be released (if there is nothing else) -_-


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on May 31, 2021, 09:49:12 PM
The racing problems- I'm catching them while running go build -race and reorging blocks and loading wallets at the same time.


Now there is a mistake at line 231 in merkle.go - there needs to be commits_mutex.RUnlock()

That's all. I've also tested the nested comb trades. They work properly.

I'm ok with the final version - can be released (if there is nothing else) -_-

Fixed. I've committed and uploaded a build; https://github.com/nixed18/combfullui/releases/tag/v0.3.4

Now to update the documentation, then on to light client server stuff.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on June 27, 2021, 06:59:20 AM
Hello, the comb downloader started to sync correctly, so I thought I would share it.

https://bitbucket.org/watashi564/combdownloader/src/master/ (https://bitbucket.org/watashi564/combdownloader/src/master/)

If possible, It would be great to have it moved over to github and make a release!
The usage is pretty simple, the user just runs combdownloader.exe and the community series combfullui.exe and any recent version of bitcoin core.
It will make 8 connections to the bitcoin core (this could perhaps be decreased)
Then it will start pulling blocks into the comb wallet.


There is a distinct possibility to use this in a "lite" mode, that is without having bitcoin core installed. Although then the user would need to
download over +100gb of data still, of which +100 mb would be retained, so I don't know what the benefit would be.

To use in lite mode perhaps the ip address in main.go could be made configurable. That way you can connect to any online bitcoin core in the bitcoin swarm.


EDIT: Important! please do not use this comb downloader just yet. There is an off-by-one error in the code, it syncs block 481824 into the slot for height 481825 etc...

Each block gets synced at the wrong height (1 block higher) The wallet appears to be working fine despite of this error, and you will not lose any funds.

Problem will manifest if the user switches to a correct syncing method, that will cause a loss of one block chain block.

If you've used this comb downloader please delete your commits folder, to recover from the problem.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on July 02, 2021, 02:11:32 PM
Hello, the comb downloader started to sync correctly, so I thought I would share it.

https://bitbucket.org/watashi564/combdownloader/src/master/ (https://bitbucket.org/watashi564/combdownloader/src/master/)

If possible, It would be great to have it moved over to github and make a release!
The usage is pretty simple, the user just runs combdownloader.exe and the community series combfullui.exe and any recent version of bitcoin core.
It will make 8 connections to the bitcoin core (this could perhaps be decreased)
Then it will start pulling blocks into the comb wallet.


There is a distinct possibility to use this in a "lite" mode, that is without having bitcoin core installed. Although then the user would need to
download over +100gb of data still, of which +100 mb would be retained, so I don't know what the benefit would be.

To use in lite mode perhaps the ip address in main.go could be made configurable. That way you can connect to any online bitcoin core in the bitcoin swarm.


EDIT: Important! please do not use this comb downloader just yet. There is an off-by-one error in the code, it syncs block 481824 into the slot for height 481825 etc...

Each block gets synced at the wrong height (1 block higher) The wallet appears to be working fine despite of this error, and you will not lose any funds.

Problem will manifest if the user switches to a correct syncing method, that will cause a loss of one block chain block.

If you've used this comb downloader please delete your commits folder, to recover from the problem.

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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on July 08, 2021, 12:07:07 PM
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?




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on July 08, 2021, 04:18:40 PM
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?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on July 09, 2021, 07:52:48 AM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: Yliz on August 07, 2021, 11:47:08 PM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on August 31, 2021, 02:39:20 AM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on September 11, 2021, 10:02:39 PM
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?





Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on September 21, 2021, 01:31:57 AM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on September 21, 2021, 06:08:42 PM
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.

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

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

Quote
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. ;D

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

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

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

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


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



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: haircombint on October 25, 2021, 02:33:46 AM
Has anyone floated the idea of Wrapped COMB?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on November 01, 2021, 04:55:57 PM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 22, 2021, 10:30:29 PM
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 ^_^




Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on December 09, 2021, 07:53:30 PM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on December 09, 2021, 08:02:05 PM
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.



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: haircombint on December 21, 2021, 08:10:44 PM
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


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on December 23, 2021, 09:30:48 PM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: duelform on February 24, 2022, 10:59:46 AM
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/libcomb)
https://github.com/dyoform/combcore (https://github.com/dyoform/combcore)
https://github.com/dyoform/combcore-gui (https://github.com/dyoform/combcore-gui)

Binaries are here (Qt is statically linked on the windows release):
https://github.com/dyoform/combcore/releases (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


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on April 01, 2022, 09:18:47 AM
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).


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: duelform on April 03, 2022, 09:23:29 AM
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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on September 30, 2022, 07:42:15 PM
Android wallet app released a little while ago :O

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

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



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on October 10, 2022, 04:45:58 PM
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  ;D



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on October 10, 2022, 11:53:18 PM
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  ;D




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.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 10, 2022, 09:41:00 PM
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).


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on November 16, 2022, 06:59:50 AM
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


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on January 05, 2023, 10:52:26 AM
Haircomb Core 0.3.6 available

https://bitbucket.org/watashi564/combfullui-0.3.5-liqtree/downloads/ (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/ (https://bitbucket.org/watashi564/combdownloader/downloads/)

Combapp 0.0.3 available on F-Droid

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


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on May 10, 2023, 06:48:55 AM
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


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: creamcookie on July 12, 2023, 10:00:40 AM
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:

Quote
"Only if the amount at the liquidity stack input reaches the stack internal threshold, the observer considers that liquidity stack as triggered. After triggering, the threshold amount is moved to stack output, and a stack transaction connects the liquidity stack to liquidity stack change. If users didn't honor this rule then Haircomb couldn't function as a currency. That's why all users do honor the rule."

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?



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on October 10, 2023, 12:37:47 PM
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



Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on October 15, 2023, 05:01:45 PM
Combfullui 0.4.1 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui-0.4.0-bugfix/releases


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


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


Users can newly install the haircomb full node as a docker container.
https://hub.docker.com/r/haircombs/haircomb


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: BotchCamber on January 22, 2024, 06:46:20 PM
hi, all

is this project still current? i'm looking for interesting ideas for quantum resistance and scaling on the bitcoin blockchain, haircomb is the only one that i remember but it seems pretty dead these days.

hope the project can be revived someday. is natasha still out there?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on January 22, 2024, 07:57:21 PM
hi, all

is this project still current? i'm looking for interesting ideas for quantum resistance and scaling on the bitcoin blockchain, haircomb is the only one that i remember but it seems pretty dead these days.

hope the project can be revived someday. is natasha still out there?

Haircomb is still chugging along, most of the general discussion happens in the Telegram channel.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: nixed on January 22, 2024, 08:08:05 PM
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:

Quote
"Only if the amount at the liquidity stack input reaches the stack internal threshold, the observer considers that liquidity stack as triggered. After triggering, the threshold amount is moved to stack output, and a stack transaction connects the liquidity stack to liquidity stack change. If users didn't honor this rule then Haircomb couldn't function as a currency. That's why all users do honor the rule."

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?

Haircomb, like Bitcoin, is a protocol; the best comparison is to a secret handshake. If someone attempts to do a secret handshake with you, but at step 5 instead of high fiving you they try to chestbump you, you won't go along with it because you know what the correct sequence of actions is. Haircomb is also a privacy coin; when your stack "triggers", the proof of the triggering is broadcast out, but only the relevant people can read it. When you validate a transaction history, you go through and check that the proof of a stack triggering is real, for the entire transaction history. You don't have to trust that it triggered, you require your counterparty to prove it to you. In order to know a stack has triggered, you need to know a) that the stack exists, and b) the amount of verifiable funds have been transferred into it.

The best comparison to BTC is looking at when you figure out which funds are where; because BTC is a public ledger, everybody who receives a BTC block immediately verifies the blocks contents and updates their record of who has what money. With Haircomb, rather than keeping a constantly updated database, you only ever calculate fund that you own/are about to own, and instead of doing it every BTC block, you do it whenever your balance is about to be updated. BTC works off of constant data processing, Haircomb works off of delaying the data processing for you until it's required.

As for how the stack can split funds while each wallet can only have one output; the stack is not a wallet. It's its own type of smart contract that operates using different rules.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: BotchCamber on January 22, 2024, 09:08:44 PM
hi, all

is this project still current? i'm looking for interesting ideas for quantum resistance and scaling on the bitcoin blockchain, haircomb is the only one that i remember but it seems pretty dead these days.

hope the project can be revived someday. is natasha still out there?

Haircomb is still chugging along, most of the general discussion happens in the Telegram channel.

You guys need a community page or a dedicated forum of some kind, I see a lot of memes and there is technical discussion on the telegram but there isn't much outreach for new users or engagement.

Its a shame haircomb is so niche now that interest with QR and scaleability is growing in the crypto community.

It would be nice to see some comb interaction with the bitcoin virtual machines or tokenisation projects to help onboard more people.


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on January 24, 2024, 04:30:44 AM
Combfullui 0.4.2 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui-0.4.1-pricechart/releases


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


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


Haircomb docker 0.0.8 released.
https://hub.docker.com/r/haircombs/haircomb


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: BotchCamber on January 25, 2024, 05:01:44 PM
nice

is the advice for claiming in this thread still current or is there a new guide?


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: 0dayalerts on January 30, 2024, 09:13:27 PM
Attention, malicious video file in telegram comb_talk.  ;D


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: BotchCamber on February 04, 2024, 03:33:56 AM
Attention, malicious video file in telegram comb_talk.  ;D

thanks for the warning, i nearly lost all my bald coin


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: cUfZz8 on February 27, 2024, 08:00:24 PM
Interesting concept! Of the privacy aspect read the whitepaper and gives me a quantum anonymous Mimble-Wimble powers

A balance/dynamic inflation on coin supply emission which is ok in my vision. Too much heavy inflation is no good in my opinion, though (IAM not always 100% accurate on crypto currency matters. And I'm no expert on side of blochain or coding. Iam moderate experienced in the basic know hows. Iam a basic end user. Liking to ease of use for digital money/bitcoin).

I have tried the honeycomb application "software" some days ago (I don't remember everything entirely) but what I do remember is that honeycomb script file in process of connecting with the bitcoin core Blockchain. I got excited at first but realised this is not a standalone honeycomb Blockchain system.

So yeah, it's okay, I don't have good understanding but the technology behind this is maybe good?

my hard-drive capacity is not enough to generate a bitcoin core address. i dont have bitcoins sofware it's out-dated. but my hadware is up-to-date for this current time


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on March 05, 2024, 06:21:00 PM
Combfullui 0.4.3 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui-0.4.2-maintenance/releases (https://codeberg.org/watashi564/combfullui-0.4.2-maintenance/releases)


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


Combapp 0.0.9 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases (https://codeberg.org/watashi564/combapp/releases)


Haircomb docker 0.0.9 released.
https://hub.docker.com/r/haircombs/haircomb (https://hub.docker.com/r/haircombs/haircomb)

New website for haircomb introduction and claiming:
https://haircomber.com (https://haircomber.com)


Title: Re: [ANN][COMB] Haircomb - Quantum proof, anonymity and more
Post by: watashi-kokoto on March 30, 2024, 06:50:28 PM
Combfullui 0.5.0 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui-0.4.3-nodowntime/releases (https://codeberg.org/watashi564/combfullui-0.4.3-nodowntime/releases)

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

Combapp 0.1.0 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases (https://codeberg.org/watashi564/combapp/releases)

Haircomb docker 0.1.0 released.
https://hub.docker.com/r/haircombs/haircomb (https://hub.docker.com/r/haircombs/haircomb)