OK, Seems XTC community does not want to be listed on btc38.com.

people might be selling unity to sell their NXT. you can still sell at a profit from ICO if you got in early enough

i think it's because supernet hasn't released anything yet and the quick buck investors are bored with it

waiting 4 days at most

sure mate, why not. it's needed. chat later

Thanks Frango! This is a great step forward to make the POM reality!

This is really exiting, so I am currently working on implementing the game API. The current implementation is going well (I think I am at 40% progress), but takes time to implement well. This is slightly delayed because of personal / work matters, but I will finish the API the next weeks!

After that we need more devs involved to spread the workload. Therefore we decided as a team Marcetin takes the lead from now to make sure new features won't delay. Since I hold most of the knowledge, I will make sure Marcetin and new devs can get going.

I "wasted" a bit of time recently while I waited for more servers to come online for expanded DHT testing and bruteforced some interesting curve25519 properties. https://bitcointalk.org/index.php?topic=820614.msg9170663#msg9170663
Also got a good education from andytoshi who really knows all this crypto math.

Anyway, as it often happens I get lucky and as I was battling the issue of how to do the key exchange and deaddrop address exchanges, the recent curve25519 lessons solved it nicely with the basic shared secret that automatically comes from curve25519.

On one node:
./b SuperNET '{"requestType":"addcontact","handle":"jl777","acct":"NXT-P3K3-M9XB-5MDG-DVNT8"}'
shared.(ad021e641e6c65e357921fe8348f4d0718f7f81e89a058071d0e73fb3873)
ADD.(jl777 -> NXT-P3K3-M9XB-5MDG-DVNT8)
{"result":"(jl777) acct.(NXT-P3K3-M9XB-5MDG-DVNT8) (12927190866050319905) has pubkey.(45ec94823354d56c549b475c5e3ffd49c9c2cf4a366deed809bfba38dd756318)"}

On another node:
./b SuperNET '{"requestType":"addcontact","handle":"s0","acct":"NXT-Z6JT-5TB6-EXSL-48JPG"}'
shared.(ad021e641e6c65e357921fe8348f4d0718f7f81e89a058071d0e73fb3873)
ADD.(s0 -> NXT-Z6JT-5TB6-EXSL-48JPG)
input.({"requestType":"addcontact","handle":"s0","acct":"NXT-Z6JT-5TB6-EXSL-48JPG"}') -> ({"result":"(s0) acct.(NXT-Z6JT-5TB6-EXSL-48JPG) (2834459742776037913) has pubkey.(7b689a7b0035bcaa944ac5d38415ebbe81a9fa2f3f3cb3898872a5075bed1a15)"})

I decided to just use the same pubkeys that is in the NXT blockchain. Since I can directly generate the pubkey and privkey and already auto-generate accounts via linked addresses, just by using a single coin address, you can get a universal pubkey that SuperNET can use to encrypt things to your node.

The blue shared secret is something that only the two nodes are able to generate and so now not only can I encrypt the comms directly between the two nodes, I can find a key to store these comms in the cloud without worry about it being spoofed, plus even if the address is figured out somehow, it has to be encrypted and only from the specific other party.

Another key advantage to using the permanent pubkeys is that now transactions can happen in non-realtime. This was one of the few weaknesses of Teleport, but now things would just progress as far as they can as each party is online. Basically, the cloud becomes a virtual fully encrypted bi-directional peer to peer communications channel for arbitrary data.

All built on top of onion routed Telepathy DHT comms to non-existent deaddrop addresses with an encrypted attachment. Also at the DHT level, all these Telepathy requests will look like they are coming from the same account. There is no need to authenticate the outer part of the packet as it will be fully authenticated inside the attachment. I think the fact that it decrypts using the shared secret is enough authentication, hopefully someone will correct me if I am wrong on this assumption.

I already have all packets the same size (1400 bytes) and they are randomly delayed/shuffled to prevent timing analysis and with nobody knowing the actual destination I believe we have unlinkable IP addresses while using IP packets.

The cloud location where the deaddrop addresses are exchanged will be calculated based on:
sha256(sha256(acct || sharedsecret))
The inside hash value will be the encryption key for the contents using AES. Maybe I will reverse that, yes that seems a bit better to make the encryption key one step beyond the location.

So a lot of progress!

James

Honestly that is why I jumped into this freshcoin. I have also invested lots of money and lost it mostly in frauds. That is why this system uses transparent and real influence on price coin. That is like in real world exchanges. I understand that there is distrust and that would be all the time because people lost lot of money on other coins. We are suffer the consequences of that other coins frauds.

I will show our agreements and also there are other side (game developers) who also can convince you that we are doing on things.

15th of October is start as I said it is not the end of something. We need to work now as much as we can from now on! We will need more developers for sure!

after doing the following API (one on each computer):
./BitcoinDarkd SuperNET '{"requestType":"mindmeld","myname":"yourhandle","other":"otherhandle"}'
./BitcoinDarkd SuperNET '{"requestType":"mindmeld","myname":"otherhandle","other":"yourhandle"}'

The following happens:

38 28 33 33 40
28 32 31 27 28
33 31 29 32 35
33 27 32 33 31
40 28 35 31 30
dist from privateaddr above -> bestmetric 0.632 avedist 31.8
31 28 33 33 40
28 31 31 27 28
33 31 30 32 35
33 27 32 32 31
40 28 35 31 31
bestaddr.3397518935526591714 bestmetric 0.632
Other pubkey.(c330e6542defef123504ebe247603008df234859ee55225d1124534462436b1b)
10694781281555936856 8894667849638377372 13434315136155299987 17572279667799017517 18429876966171494368 mytxid.7232362215934077752 othertxid.6762902089573300365 | myaddr.2834459742776037913

############# other node

28 31 28 27 28
31 35 33 32 35
28 33 40 33 40
27 32 33 35 31
28 35 40 31 34
dist from privateaddr above -> bestmetric 0.632 avedist 31.8
31 31 28 27 28
31 32 33 32 35
28 33 31 33 40
27 32 33 30 31
28 35 40 31 31
bestaddr.7112391407263245770 bestmetric 0.632
Other pubkey.(ffe89032a5d457014b02c704a7b19eede4cfce1fc83fa554f0e875098d06240f)
8894667849638377372 13434315136155299987 10694781281555936856 17572279667799017517 18429876966171494368 mytxid.6762902089573300365 othertxid.7232362215934077752 | myaddr.5558871420373351853

I am displaying the distance from the actual private address (red) in the top matrix and the distance from the deaddrop address (blue) in the bottom matrix. In DHT the distance is really the only useful information about an address. The red address is NEVER sent publicly, only the publickey is put into the cloud in a location based on the handles the two people use, so it is "published" as anybody can access them, but generally public keys are public so this is much less info than normal.

Once both sides exchange public keys, they then can encrypt and only then are the deaddrop addresses exchanged. Notice the difference in the account numbers red vs blue. what is more important is that the distance of the blue addresses from the other nodes:

31 31 30 32 31
31 32 31 30 31
 
as opposed to the red addresses:

38 32 29 33 30
28 35 40 35 34

Keep in mind the average distance is 31.8, so let us assume that someone the blue address is compromised. What does it divulge?

It is pretty much equal distance from all the other nodes (including the actual source and destination), so it is like camouflauge. Even if the attacker got the blue address, it certainly cant lead to the red address and it just ends up saying equal chance for any of the nodes to be yours, basically useless guessing. As the network grows, the effect becomes stronger, though finding addresses that are equidistant from a large number of addresses becomes more and more difficult so there will be an eventual cap on the anon set from this.

Notice that not only is the IP address not known, but the destination acct address is not known either, in fact there is no actual destination account, that is how I know it cant be divulged. The destination is the publickey that is generated each session (or transaction), so if there is no account, then it cant be correlated to the IP address. Even when there are a small number of nodes, there is privacy with this method and I believe that is quite unique.

This does raise the issue of spoofing, so there will need to be authentication of some public account before any transactions are done, but there is now an automatic cloud based public key exchange based on user handles, no crazy long numbers to deal with.

James

I pushed a new version with findaddress API

./b SuperNET '{"requestType":"findaddress","refaddr":"8894667849638377372","dist":24,"numthreads":20,"duration":6000,"list":["13434315136155299987","8894667849638377372","10694781281555936856","18429876966171494368","16163006958863727986","1838354277347686608","17572279667799017517","14815310753561302584"]}'

The refaddr is your privacyServer's NXT address, dist is the distance in bits (after xor), numthreads is the number of parallel tasks doing the search, duration is in seconds and list is the reference list of public server addressees

This will run in the background until the time runs out and it will print out a password and stats for your super private account. I havent done the storing in encrypted file or anything else yet. while it is running, if it finds a better acct, it will print:

>>>>>>>>>>>>>>> new best (super secret password) ...

so you can always search for this and get decent accounts to use while the findaddress keeps working in the background. It is kind of like mining! But what it is doing is actually very useful. It is finding the perfect address for you to use by making it look like an address that could be linked to any of the other public servers.

Due to the way the accounts are created, bruteforce random guessing is the best way to find such an address. This is a good thing as it means that the encryption is quite good. After all if the distance between the mined acct and the reference account went to zero, we have effectively hacked it!

The search is creating an N dimensional space where each dimension is the distance from one of the server accts in the list. The metric function is a bit more complicated, but conceptually we want a point in N-space that is equidistant from as many public nodes as possible. With the current number of nodes being so small, it is hard to come up with any address that meets this criteria, but at a distance of 24, given enough time, it should be possible to find an address that is +/- 3 distance from most of the list.

I am hoping that with more nodes, it will be possible to find addresses that are around 20 bits distant and still have the above characteristic.

Now why on earth do we care about such things?

The reason is that this solves the "last mile" problem of how to establish totally private comms without resorting to broadcasting to everybody. My coding the DHT is what allowed me to solve this, so those that think these seemingly unrelated things are slowing down the progress, it is quite the opposite. It is helping achieve the ultimate goal!

To understand how this allow comms without divulging the IP address, requires a bit of background on DHT, especially the Kademlia XOR distance method. Using XOR as a distance function sounds so simple, but it has some very powerful mathematical properties. Namely, you can know if another node is closer or farther away from the desired location, totally in the abstract. Imagine that you start searching for something. It gets a delivery address (in the abstract not IP). Now you find all the nodes you know about that are closest to this address and ask them to deliver it. You only know they are closer to the destination that you are.

That's it!

Of course a lot more details, but this is emergent behavior, eg. out of very simple behavior at the local level, some powerful global functionality emerges. Imagine you got the packet from someone that was farther away than you are. Now you do the same thing and the packet keeps getting closer and closer to the destination. Finally it gets to the nodes that are as close as possible that are in the network.

All the SuperNET nodes are part of this "bucket brigade", each passing the packet one step closer to the destination. This means that your node is also going to be involved in this and everybody knows your public server's acct and IP address. If not because you publish it, but if they wanted to the attacker can do sybil attacks and get this info. It is simply unavoidable to get an account linked to the IP address if you are transacting with it.

However, we have the private address that only people you transact with know. Your privacyServer's acct is known along with its IP address, but as long as you are careful with who finds out your privateaddress, then it is just an address that happens to be equidistant from N other privacy servers. Which one? Could be any of them as the way the DHT works is that it replicates the info to all the nodes closest to the destination, which in this case is your address. Taking advantage of this property of the DHT and the fact that your privacyServer will be handling the routing allows packets that are encrypted to your private address to be received by your computer and you can decrypt it as it is sent on to the closer nodes.

As the network grows, it will become harder and harder even to identify the set of possible nodes your private address belongs to. So even if your private address is compromised, there isnt a way to link it to any IP address!

James

Nope...still have coins there that I can't get.

First off I remind you I am just a simple C programmer and not a cryptographer. If anybody has the math background to confirm or deny my experimental finding, please post!

I was experimenting with Curve25519 yesterday and I observed a very useful property that allows the creation of multisig. https://forum.thesupernet.org/index.php?topic=154.msg1262#msg1262

Now I doubt it was just in the few cases that I discovered that works. I bruteforce searched thousands of combinations and found a very simple relationship that I believe can be used for arbitrary M of N signatures.

The fundamental property of Curve25519 is that if A and B know each others public key, they can create a shared secret. Let A and B be the private keys and a and b the public keys:

curve25519(A,b) == curve25519(B,a)

I searched and searched on the Internet to find little actual useful info, so I started with the above and my intuition and searched for combinations that created the same result and there were many, but the simplest and clearest was:

Add C and c to the above and denote S_ab to being the result of curve25519(A,b) or curve25519(B,a) (they are the same)

curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)!

This relationship is quite useful and it is probably obvious to anybody familiar with curve25519 so maybe I am just getting excited over nothing, but the recommendation is to immediately hash the output S_ab. Presumably to avoid any low entropy sections of the point and once you do this, the above relationship does not work as you end up totally scrambling the location of the point in the finite field. I call this the rawsharedkey and maybe it has been explored in depth so we can get some math proofs of the above relationship.

We also know that curve25519(A,curve25519(B,curve25519(C,seed))) is equal to all the permutations of order, I think this is because the field forms an abelian group, but it has been a long time since I did any abstract algebra so I probably have the terms wrong. It is just a fancy way of saying the order doesnt matter.

So how to use these math properties to make multisig?

Since S_xy is constant for each set of keypairs for each node, these values can actually be cached locally. Of course this means that the presence of S_xy in the output does not mean that either X or Y actually signed anything. Turns out this is fine, as the final step requires the signing node to actively participate and the final output can be processed till the dogs come home:

sha256(seed ^ curve25519(A,S_bc))
sha256(seed ^ curve25519(B,S_ac))
sha256(seed ^ curve25519(C,S_ab))

all the above produce the identical result and proves that A, B and C all signed it with the seed (which should have a timestamp in it) and since it goes through sha256 the output gives no useful info about A, B or C. I am not sure if S_xy is leaking any info to the nodes that get access to it, but I dont think so as it is the output of curve25519 and that's supposed to be hard to reverse.

Since it is safe to publish the final number, A, B and C publish it and everybody can verify if 0, 1, 2 or 3 signers signed it. The enforcement of following the result is beyond the scope of this thread, but this can be put into the NXT core and each node can just use the above to verify whether the payment should be released

Now, how can this be generalized? I feel strongly that the "triangle" relationship can be generalized, but so far my experimental results are not finding the right sequence.

Let me ramble a bit, that sometimes helps

Starting with the fundamental triangle:
curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)

Let us replace C,c with D, d:
curve25519(A,S_bd) == curve25519(B,S_ad) == curve25519(D,S_ab)

The problem is these are different values as it is S_ab combined with C vs D, however, we can use the priv/pub equivalence:

curve25519(d,curve25519(C,S_ab)) ?? curve25519(c,curve25519(D,S_ab))

nope, that didnt work, but as expected:

curve25519(D,curve25519(C,S_ab)) == curve25519(C,curve25519(D,S_ab))
which means:

curve25519(D,curve25519(C,S_ab)) ==  curve25519(C,curve25519(D,S_ab))  == curve25519(B,curve25519(D,S_ac))  == curve25519(A,curve25519(D,S_bc))

Hey! That means there is a 4 signer solution, but this requires multiple signings and then correlations, so not exactly what I am looking for. Anyway I hope to get some math help here so an efficient M of N multisig using curve25519 is possible. Experimentally I found the triangle relationship, which I am not sure if it is trivially obvious or something significant.

James

Super star

We are looking for a
C++ Developer to help with the QT Wallet
and a
Python Developer for Open Bazaar integration

we are in touch with a couple of people but
the more the better as nothing is confirmed.
The idea is to outsource a couple of projects so Evan can concentrate on his development and does
not have to deal with the other things around.
Yes Evan is aware of this and agrees that it would be helpful to outsource !

I'm signed up and ready!

Darkcoin now Trading on Europe’s most secure Exchange !

ccedk.com, a Danish exchange renowned for its security, have announced that they are now accepting Darkcoin. Trading with Darkcoin will include, amongst others, trading pairs such as the Euro and the Russian ruble
opening up further possibilities for Darkcoin's increasing popularity.

ccedk.com is presented as the first crime-free cryptocurrency trading platform. Boasting a dual-language English/Russian interface it is aimed at a wide audience, but has often been overlooked. Notably there are plans for further interfaces in Spanish, Portuguese, German, French, Danish and Chinese suggesting expansion is on the horizon.

Their security-conscious approach is likely to be welcomed as cryptocurrency users become more cautious in the face of well-known exchange collapses such as Mt. Gox. To counter such a possibility ccedk.com keeps a reserve fund, amounting to thirty-percent of the crypto currencies revenue, to protect their customers in the case of losses. This is a major innovation akin to how major banks refund the victims of fraud that grants customers a degree of security in the event of being targeted by criminal elements. As more and more users of cryptocurrencies begin to enter the marketplace it is important that more institutions take financial security into consideration.

In terms of trading the site has promised Skrill integration in the coming months which will make depositing fiat a breeze. Also impressive is the range of fiat currencies which can be used including Danish/Norwegian kroner, British pounds, US dollars and Euros, accounts can be funded SWIFT wire transfers, SEPA, and Deposit and withdraw in RUB/UAH/EUR/USD, using more than 150 payment options in terms of funding with the Payment Service Provider Payee!
One notable feature of ccedk.com is the remarkable degree of transparency on offer. They are confident enough to post the details of their lawyer and they are clear that they will follow the Single Euro Payment Area (SEPA) regulations to help integrate cryptocurrency trading into the mainstream, including its regulations. With this layer of legal adherence a core feature of the site it is clear that ccedk.com will emerge as one of the safest exchanges and is surely a strong recommendation when tempting newcomers into the world of cryptocurrency.

It is worth noting that the security of ccedk.com can be usefully combined with the privacy offered by specific cryptocurrencies and, in particular, that of Darkcoin. This coin already has a large following in Europe and is
gaining further traction in Russia, Ukraine, Poland and many others. In this manner ccedk.com is the perfect home for Darkcoin trading given its dual-language interface. Darkcoin, which anonymizes transactions if one chooses, has slowly emerged as the major alternative to Bitcoin and with new innovations appearing daily it is grow even further. As Darkcoin enters the mainstream alongside secure and transparent exchanges such as ccedk.com we will find ourselves in the mature position of combining financial security with financial privacy opening up cryptocurrency to ever wider adoption.

https://www.ccedk.com/drk-btc

https://darkcointalk.org/threads/darkcoin-news-drk-now-trading-on-europes-most-secure-exchange.2634/