I'll be setting up the system with pure crypto to crypto exchanging in the next few days.
The darknet option will be temporarily disabled, trustscore will default to 1 (0 is untrusted, 10 is fully trusted).
The system is setup to directly feed the ticker data from BTC-e into the primary channel and treat it as actual offers.
It will attempt to order match and clear transactions immediately, then it will attempt to refund each transaction within an hour during the testing period.
Trustscore gains (and losses) will carry over from testing to live.
Out the gate I'll be supporting BTC/LTC as the first pair on this and will introduce other currencies as the modules for them become ready.
Since I'm using the RPC API for BTC & LTC and I suspect other currencies use the same/similar API, are there any requests for other wallets?
Ok it's probably time to explain trustscore.
Trustscore is our way of tracking credibility.
Every time a transaction is agreed to by two nodes, a hash of the transaction is generated and signed by both nodes.
This information contains the publickeys of both sides and the currencies to each side but not the amounts.
This is signed and broadcast to the network and kept by all nodes.
It looks something like
UTC Timestamp
BTC|sender|recipient
LTC|sender|recipient
TXHASH
SIGHASH1 (timestamp+line1+line2)
SIGHASH2 (timestamp+line1+line2)
Once broadcast, each party to the transaction gets 1 credit.
Credits are valid for 1 year then they expire out, that way no one needs to have gigs of trustscore blocks on hand.
Trustscore goes up logarithmically, from 0 to 1 takes 10 transactions, from 1 to 2 takes 100 etc.
Trustscore gains are limited to no more than 1 point gained rolling 7 day period regardless of the number of transactions performed.
Also the time the last transaction was performed factors into it.
If you go 1 week without any transactions your trustscore drops an entire point for each week of inactivity, but this can be gained back after 7 days of daily activity.
If either node has a problem with the transaction (for instance once side fails to live up to their end) a "dispute" is notated by referencing the previous hash and announcing it as a dispute to the network, where it is added to the rest of the trustchain.
timestamp
TXHASH
recipientID
SIGHASH
Disputes stay on the record for 1 year and they drag you down to the next lowest trust point.
Thus if you were a 3 and you get a dispute you are now a 2.
In this instance 900 credits would be essentially wiped out for 1 dispute.
To negate the risk of bad actors, only 1 dispute can be lodged per trading pair.
It is expected that if you have a dispute that you stop trading with that node, the client implements this behaviour by default but it can be overridden.
A dispute affects both equally in that it drags them both down by a whole point, this ensures that only disputes which are "worthwhile" will be reported.
There is no dispute resolution method, once filed it's there for a year.
The default settings prevent the client from trading with a node that has a dispute open in the last 30 day rolling period, however existing relationships are not directly effected, just the risk model.
Now here is how the client implements risk modelling.
The trustscore translates directly into a percentage of assets at risk. 0 is completely untrusted, 1 is 1%, 2 is 2% etc.
It will cap at 10%, thus at no time is a trade to go through for more than 10% of liquid assets.
This can be overridden in the configuration and settings panel. In fact for someone to get to 10 they would have to have 10,000,000,000 successful transactions with no disputes, so it can be considered safe.
In the next version trustscore will be broken out by currency pair and settlement method which will be much more informative, but right now we have a single combined score.
That's it for now folks.
PM me if you want access during the testing period.