Topic: [ANN] SuperNET NXT asset 12071612744977229797, SUPERNET KMD assetchain in summer - page 186. (Read 736772 times)

It's been moved to assets.

Yeah that's NOT the total amount. Crap !

That looks like just BTer. Overall it's over 5k btc.

i want me some of dem starbucks dividends

~CfA~

SuperNET already 33 on CoinMarketCap

Thanks

in the future, it could be that supernet has its own client?
I mean a purse for all currencies, with all the advantages
instead of having a button supernet on each client,
have a client where you can manage all currencies

I meant revenue streams, not voluntary transfers by users 

I thought Vericoin was working on this solution, but I may be wrong.

Re: fiat sucking (one of the purposes of SuperNET), which businesses will do this?
Some, like Coinomat, cater for crypto -> fiat. Others are broadly internal to crypto.
Are there any yet confirmed that will take money from fiat -> crypto, other than exchanges etc?
One suggestion would be to include Google ads alongside any others - not sure whether that's already planned. This would have to be dealt with via a trusted third party, like BTER or Coinomat - both of which are well-placed to convert the revenue to BTC and send to SuperNET already. This would represent a steady trickle of wealth from fiat to the cryptosphere, benefitting not just SuperNET but all of crypto. Ideally, a few different initiatives would turn the trickle into a constant stream.

What's the current up to date list of core coins that will be featured on launch?

I just came up with a possible way to have a probabilistic routing where nobody is actually sure of which account has which IP
Not sure if I can get it to always find the right path, so I will need to run some simulated topologies to see if this will work.

If it does, this will make it so that nobody will even know the exact path the packet will take as we only know that the original sender came from a path ending with the node that sent the packet on through.

If I can get this to get the packets to the destination, then it wont matter if the attacker has compromised large numbers of privacyServers as no server will even know what ipaddress is linked to which account! Even this info will be probabilistic.

This will take a bit of time to investigate, but to be able to route to the destination without knowing any specific IP address is a scalable way to get a bitmessage like broadcast to everyone but only the destination is able to decode the packet. If I can get the convergence toward the destination without including TTL or expiration info, then this is the best case

James

OK 

Please send your application to join SuperNET CORE to [email protected]

as soon as bter does the swap, then you will be able to withdraw it to your NXT acct

Can we send Unity, bter to asset NXT?
Or is it necessary to sell and repurchase?

Ty

Shifting to a UDP only transport really simplifies things. 800 lines of code just got deprecated away, so that is 800 less lines where any bugs can hide in.

It was just getting a bit too confusing with all the possible connection states and now it is more work to make everything into essentially a state machine, but most of that had to be done anyway.

No TCP means no TCP sockets to be locked up for long durations. Also, now that I scrubbed the packets of any useful info, I can just use random privacyServers for all comms. Originally, there was some small amount of trust required of the privacyServer, but over the months I have scrubbed all info leaks away.

Anyway, back to the coding cave I go

James

Please stop your scammer crews(barabbas+others) from going to our thread. Thanks

Thanks James. Was not sure if the NXT AE could handle that but I guess it can. Cool stuff!

This sybil attack thing bothered me, so I did some more research on it. For methods like coinjoin where you are mixing your funds with others, then clearly who you get matched up with is quite important. If the attacker is having a large percentage of all nodes, then the would be able to either prevent the transactions or glean info about the spendings

With Teleport, this is not very applicable as it is a sending from source to destination in an intact telepod. Any tampering with it would require cracking layered encryption through all the onion layers and such tampering would be quickly detected on the destination side.

When the M of N fragmenting is used, there is a random chance to forward or not forward, so if an attacker is trying to prevent the tx by not forwarding, this just increases the failure rate and presumably the M parameter will need to be adjusted to compensate. I am defaulting to M = 40% of N and so there is some headroom anyway, but this is something to keep note of as if the attacker can control 20% of all the nodes, then it would be evidenced by a higher than expected failure rate to receive enough packets.

There is no need for the attacker to make fake identities if they just want to be hosting a lot of privacyServer nodes. these nodes would then be able to determine who is sending what packet to whom. However, not knowing if this packet originated from the sender, nor if the next hop is the final destination, I do not believe there is much to be gained by this "sybil" attack. The routing can be blocked, but then the nodes would route around what looks like a malfunctioning privacyServer.

Maybe the fact that there has not been a followup post means that I actually wasnt an idiot about this

James

I will send the SuperNET assets to bter and they will swap them for the TOKEN, so it should be totally automatic. Actually with bter there wont be the issue of the TOKEN remaining after this swap.