Pages:
Author

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

full member
Activity: 532
Merit: 132
still figuring out how the comb wallet works,
but working on it.
copper member
Activity: 82
Merit: 5
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.
newbie
Activity: 71
Merit: 0
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.
copper member
Activity: 82
Merit: 5
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
copper member
Activity: 82
Merit: 5
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
newbie
Activity: 71
Merit: 0
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!
jr. member
Activity: 42
Merit: 1
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?
newbie
Activity: 11
Merit: 0
I don't have COVID 19.
Wink

Glad to hear from you, the updates wishlist sounds promising
copper member
Activity: 82
Merit: 5
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



newbie
Activity: 17
Merit: 0
any updates?
copper member
Activity: 82
Merit: 5
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.

newbie
Activity: 71
Merit: 0
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?

copper member
Activity: 82
Merit: 5
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
newbie
Activity: 11
Merit: 0
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
newbie
Activity: 71
Merit: 0
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.
newbie
Activity: 71
Merit: 0
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!
copper member
Activity: 82
Merit: 5
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.
newbie
Activity: 17
Merit: 0
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?
newbie
Activity: 71
Merit: 0
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?
copper member
Activity: 82
Merit: 5
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.




Pages:
Jump to: