not sure about this
while it might be possible, it becomes quite dangerous.
with bitcoins, you can stack up a bunch of tx that each link to each other and it should all resolve properly. With NXT, the other nodes wont accept the tx if you didnt have enough to cover it prior to the current block

so, no one size fits all solution

James

I will separate out the trade clearing from the trading itself.
Similar to when you click on "Send", once it is sent to the network (barring rare events), it is just a matter of time to get onto the blockchain. But the funds have already been send the moment you click.

Does that make sense?

So, with InstantDEX, regardless of how long till the next block the two people trading with each other (directly) will both have broadcast their half of the tx to the network. Just a matter of time before it hits the blockchain.

Now, there will be a variety of ways to finalize the trade. Could be via NXT AE using MGW assets, could be direct wallet to wallet overlapped micropayment channels. That is totally decentralized and for any bitcoin fork that supports multisig. There are also ways of finalizing the trade via telepods and the upcoming ATOMIC.

James

P.S. Not sure if you understand that there are things like mgwBTC asset, which is 100% backed by multisig protected BTC,

BTCD and NXT both get same 5% revshare from SN
but NXT is 10x bigger marketcap, so the effect on BTCD will be a lot more

What is good for SN is good for NXT, but much better for BTCD. Also the 5% to NXT goes to fund their devs, while the 5% for BTCD will be used like a multipool, eg. whatever form the 5% is in (BTC, NXT) will be used to purchase BTCD so it can be sent directly to the staking accts. That is necessary to maintain privacy

James

P.S. a v0 wallet will be coming out soon, but it is just to add MGW support for production servers and it didnt make sense to go backwards with the GUI, so it is kind of an in-between release.

N*N topology does not scale at all. If that is how they are getting fast performance, then it will quickly bog down.

James

I dont know about python, but if anybody else does, the same porting could be done. Very cool idea by the way!

Now, another approach is to simply make a gateway to counterparty or etherium. There is no need to directly implement everything

James

why do you think InstantDEX is centralized?
InstantDEX itself is fully decentralized. If you are trading things that are backed by MGW assets, then since MGW is distributed (between centralized and decentralized) arguably there is some risk from the distributed (vs decentralized) nature of the asset. However, there are also other types of ways instantDEX will clear the trades, including direct peer to peer.

We are looking into NODE, until recently I dont think they had things working

James

how is " the suspected servers are unplugged briefly" done?

if the attacker is controlling the physical internet, then we can assume they can simply send in their staff to where you are and directly monitor what you are doing.

Since all comms are based on direct peer to peer comms, the truly paranoid just has to create onetime use private addresses. That side steps even this level of attack, as there isnt this constant activity that goes away

Telepathy/Teleport out of the box will provide corporate level privacy, as opposed to personal level. To get to total privacy, it will take additional layers of work

James

./BitcoinDarkd SuperNET '{"requestType":"pricedb","exchange":"bter","base":"BTCD","rel":"BTC"}'

turned out to be a lot of little details and I still have some DB deadlock cases to fix, but if you have only one active pair it seems to be working. not sure if all the data is getting into the DB, but the dbput is coming back without error.

so what is this pricedb API? it creates an entry in a small db file which is just a list of exchanges and trading pair that is active. The cool part is that for all active pairs, it automatically polls the prices from the exchange and creates a database file locally. This way, over time you will get price data to analyze, but more near term a way to see the current market price.

The exchanges that are supported are: "NXT", "bter", "bittrex", "cryptsy", "poloniex", "mintpal"
for NXT, only the currencies with MGW assets are supported, for the others, any trading pair the exchange supports is supported. [I think cryptsy only works with a hardcoded list for now]

James

The Pangea poker team has been assembled and this will definitely be an asset dividend this year.
Have a few others in the pipeline, but not sure if they will be ready this year

James

more press:

https://coinreport.net/little-crypto-asset-sanity-maidsafecoin-supernet-bitusd/

cross post of lionel preacherbot in NXT forum:

###
Free Talk Live Talks About Freemarket on Over 150 Radio Stations in the U.S.

The title says it all. I really enjoy Free Talk Live and they are syndicated on 157 radio stations in the U.S.
All of their episodes are free to download on their site.

Mondays episode includes a lengthy discussion on decentralization with Freemarket and Open Bazaar as the focus. You can find it here. http://www.freetalklive.com/content/podcast_2014_11_10 Awesome publicity!

crazy day today!
got distracted with half a dozen active new members of slack
also getting some good ideas of what needs to be done with API to support the most powerful use cases

still thinking through how to get everything working as a system. all the pieces are there and even got some working telepathic teleports, but need InstantDEX in the mix too.

I think I will do some easy coding today as this percolates

James

yes, UNITY holders will get dividends automatically

yes, this is the plan
not sure if it will make it into v1 though
so many things going on

just a draft

James

Amazing progress today!

The FreeMarket team joined the slack and also a poker project is coming together, v1 team is defining the deliverable, just feels like we are reaching critical mass of people.

James

made some progress today. The telepathy is not 100% reliable, but it is working most of the time when you are nice to it. Got things a lot more stable at the low level and that allowed a couple of BTC teleports, but this exposed some state machine bugs. Not surprising as it is quite tricky and first time the entire process is being tested all at the same time.

Need to think about how best to integrate the InstantDEX with the Teleport. I keep alternating days, working on one, then the other, pushing them closer and closer. One of these days I will be able to get them both playing nice with each other.

James

http://bitcoinmagazine.com/18167/what-is-the-supernet-jl777s-vision/

Got some press. I have most all of the API needed for v1 released coded and now entering the painful systems debugging stage. The nature of the work changes now to making bugfixes instead of writing new code and just getting everything to work at the same time, along with performance improvements

Still need more testers, but I am acting as the first tester since I rely on the API calls to get the basic functions working. Not sure which will finish first, my debugging or the GUI and websites, but probably pretty close race

James

had to figure out how to index into DB with duplicates properly, and also add in special cases to the DHT to support InstantDEX orderbooks.

finally got most of this solved, just need to verify it works properly.

The method is as follows:

A. an orderbook bid or ask is submitted using the standard DHT store and this is processed normally.

B. as this is processed, various nodes do a localstore into the public.db on their HDD. When this is done, the raw data is checked to see if it is an InstantDEX quote and if it is, an automatic update is triggered. This update allows one bid and one ask per account, which has the effect of preventing the orderbook stuffing.

At this point, the node that is closest to the key value of (baseid ^ relid) will have an up to date orderbook and the normal orderbook function should display it properly.

Of course, this does no good for most all people, so we also need to support returning the full orderbook via DHT findvalue call. The problem is that there is no automatic way to know if a key value is for an InstantDEX orderbook. So, using a similar method to overloading the findnode command with a datastr, I added a datastr to findvalue. This would just be the "orderbook" API command, which needed to have an "oldest" field added. what that allows is for the nodes that have data to send back to filter it so only the new data is sent.

When this is all debugged, all nodes will be able to get an up to date orderbook as quickly as a DHT command can be processed. Now, even if this is taking 10+ seconds, odds are that the same accounts are having the best offers and really that is the most important as the exact trade matching is done peer to peer.

James

thanks!
almost 100 people in slack and it seems most of the activity is there. We can sure use as much help as possible and you can help shape what gets released

James