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

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!

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?

Glad to hear from you, the updates wishlist sounds promising

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

any updates?

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.

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?

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

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

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.

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!

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.

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?

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

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.

@natasha-otomoski
You have a very interesting name. 

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)

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

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.

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


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.