For those of you worried about all the data the privacyServer will collect on you, stop worrying
other than your IP address and what accts you are in contact with, there is really not much else the privacyServer gets to see. And as discussed before there are ways to minimize or eliminate any downside with both of these (proxy server and extra layer of onion routing)
So the privacyServer gets to see stuff like this:
ONIONIZE: np.0x7ff740002e40 NXT.8989816935121514892 8989816935121514892 pubkey.6eddccdbaf6f08bf encode len.809 -> new len.865 + 42 = 907
sendmessage (<encrypted>) len.809 to 8989816935121514892
sendmessage ([{"status":"1700913285397123524 sends direct encrypted sendmessage.(<encrypted>) [<encrypted>] to 8989816935121514892 pending"},{"token":"vb5lpi57ea2pb4cvjn7g1i2ffrso4j7p7ban3vfmhv7ftcbp7qjak4et74bqje81s7krug8htg3nha3
o0n4aahulm9kt05rcm581qg00uhug2mn5443av4vn88preune1apsm5hjoek7t6arrpgj7oma5m9kir
i1"}]) len.303 to 8989816935121514892
The destination account number and size of packet. It sure makes debugging super hard, as I have no way of seeing what data the server is getting and so until all the encryption/decryption was flawless, it was very much stumbling in the dark. [yes, observant readers notice now the encryption/decryption is flawless at least for two layer loopback onion routing]
But this sort of details are not why I am posting. I wanted to announce that the first matched trade was completed!
I will skip the dozen steps that led to:
{"result":"tradecompleted","txid":"
6544081069274036129","signedtx":"0201aaa63e01d00225c5fed2690701cf06f267e7c227b1a3c0dfa9c6fc3cdb593b3af6f16d65302
f8c71b555df3ec27c000000000000000000e1f50500000000000000000000000000000000000000
0000000000000000000000000000000000ff1355c269aef4947f6a3842931f8d8e85b01a9abe8c7
9643dc61a3aeca83e0def1c3d96818b0ef6a727eed397cb4803c3af78dde94fa209bd914790a0aa
12ca444a53bf9828e869e80300000000000031007b22617373657442223a2231363339323939383
439333238343339353338222c2271747942223a2231303030303030227d","othertxid":"
7139578165401755004"}
These two transactions are on the actual NXT testnet and they decode as follows:
{
"fullHash": "a1f76f7b0f3fd15a1da4113729f6ec855ddf27b9175f9bfd081279af67951e6b",
"confirmations": 6,
"transaction": "
6544081069274036129",
"block": "2448711563708809301",
"attachment": {
"asset": "7631394205089352260",
"quantityQNT": "1000",
"comment": "{\"assetB\":\"1639299849328439538\",\"qtyB\":\"1000000\"}"
},
"recipient": "8989816935121514892",
"sender": "8989816935121514892",
"timestamp": 20883114,
"height": 163875,
}
{
"referencedTransactionFullHash": "a1f76f7b0f3fd15a1da4113729f6ec855ddf27b9175f9bfd081279af67951e6b",
"confirmations": 6,
"transaction": "
7139578165401755004",
"block": "7001348228112354675",
"attachment": {
"asset": "1639299849328439538",
"quantityQNT": "1000000",
"comment": "{\"assetA\":\"7631394205089352260\",\"qtyA\":\"1000\"}"
},
"recipient": "8989816935121514892",
"sender": "8989816935121514892",
"timestamp": 20883114,
"height": 163876,
}
You will notice that these two transactions are the opposite of each other. The comment field has what each transaction wants in return. Also key is that the second transaction has a referencedTransactionFullHash, which matches the fullHash of the first tx. This is how the two are linked, so the second transaction would wait until the first transaction was seen on the blockchain. In order to give assurance to the other party that the transaction was indeed submitted, not only is the txid sent back, but also the signed tx bytes. this way both parties can broadcast the transaction that they like, eg. the one where they get stuff. I am automating all this so it all just works, but the worst an attacker can do by changing the code is to prevent the broadcast of the first tx or the second tx. If he stops the first one from going out, the second one never happens and will expire. If he stops the second from from going out, well why would he, thats the transaction that gives him his half, so in order to collect on that he has to broadcast his tx.
What does all this mean???
It means InstantDEX can now matchup exact trades and get them to trade nearly atomically. There is a remote possibility that if you are trading with the next node that will forge a NXT block that he could do some nasty things, its very complicated and really more a theoretical thing since only accounts with a large balance are likely to forge the next block. [noashh plz note] Still I will add in a check to see if you are trading against the node that will forge next (NXT will allow this to be known) and then simply prevent any trading with that node, so we will sidestep even this theoretical attack.
Now we are getting to higher and higher level code, so what I write is far removed from the brain tangling onion routing and dark packets I cant even see anything in. Next on the list is, let me think,...
OK, I guess next on the list is the infrastructure to be able to support the simple tradebots. Now this might sound pretty simple, but there are actually quite a few different pieces that are needed. I dont want to tell you about all of them yet as I still want to buy some more cheap BTCD
It will probably take me into the weekend to get to where you can command your own tradebot.
James
Poll
