Topic: BTCD is no more - page 448. (Read 1328490 times)

A Chinese translation should be prioritized I think. Maybe put a bounty offer on the website for a good Chinese translation? Just thinking out loud 

check out megacoin website, so nice and supports so many languages.

As long as we get support for the whales from China so they can get more involved.

Hey guys - the automated payouts on BTCDPool.com didn't go through because the API had an issue with one of the exchanges.  I am just fixing that, then the payment will be fully automated again.
Sorry, I was away from the computer for the last ~10 hours.

As soon as we get the site done will post for translator, so i will count on you

I can translate to Dutch if you like..

Finally got a loopback trade offer. Thankfully now that I got this sequence debugged, most other sequences should just work. Had to fiddle a lot with protocol level stuff today.

on_client_udprecv 209.126.70.170/6777 nread.1060 flags.0 | total 789
got crc of 3959bc4c vx packet_crc 3959bc4c
deonionize >>>>> pubkey.71e2a7d5c0bcebf vs mypubkey.11319cbc2ab6e6dd (40) -> 1014 3f6
payload_len.1014 err.0 new len.958
decrypted len.958 dest.(8989816935121514892)
deonionize >>>>> pubkey.11319cbc2ab6e6dd vs mypubkey.11319cbc2ab6e6dd (40) -> 916 394
payload_len.916 err.0 new len.860
decrypted2 len.860 dest.(8989816935121514892)

What we see here is a doubly encrypted UDP packet coming in. The first encryption layer was by the privacyServer who just encrypted the raw data that it was sent to route to 8989816935121514892. The second encryption layer was done by the originator of this request, which in this case happens to be the same acct 8989816935121514892, but as far as the software is concerned it could have been anybody to anybody. What you dont see here is that the first attempt errored out because there was not public key on file, so a request had to be made to the server and a response received with the public key.

This explains why so little progress today, this is pretty tricky code!

set UDP.0x100307950 209.126.70.170/6777
29109850111697 pNXT_json_commands sender.(8989816935121514892) valid.1 | size.15 | command.(processutx)
PARSED OFFER.({"sender":"8989816935121514892","timestamp":20810867,"height":2147483647,"amountNQT":"0","verify":false,"subtype":1,"attachment":{"asset":"7631394205089352260","quantityQNT":"1000","comment":"{\"assetB\":\"1639299849328439538\",\"qtyB\":\"1000000\"}"},"recipientRS":"NXT-CWEE-VXCV-697E-9YKJT","feeNQT":"100000000","senderPublicKey":"25c5fed2690701cf06f267e7c227b1a3c0dfa9c6fc3cdb593b3af6f16d65302f","type":2,"deadline":720,"senderRS":"NXT-CWEE-VXCV-697E-9YKJT","recipient":"8989816935121514892"})

Now what we see above is the parsed output of the raw transaction bytes that were sent. It basically proposes trading 0.1 BTCD for .01 BTC. I will use this data to create an atomic swap, but that will have to wait for tomorrow. All this onion stuff tired me out.

I hope for better production tomorrow. At least I am getting very close to where all the system issues are debugged and I can just write code that does things. That I am very fast at doing, not like this slow laborious debugging.

James

As long as there is enough support for translating it, it wont be a problem to be done in multilanguage

Even better.

Well done guys.

Hope you guys make it multi language, would help the site very much.

Keep up the good work.

IceColdTommy and Gitbknowsall are currently working on a new website.  

The current one is very basic and she's served us well, but where we're going and what we plan on implementing we're gonna need a much more sophisticated and functional website.

We're also working on implementing a donation based bounty system at the moment, to encourage more community participation, which will help us to assess our needs and generate new ideas.

How long did you mine with 600gh? If you were mining 24hr you should get approx. 7-8btcd

should fix total number of coins on website...

People might still think its 22mill and just dumping.

http://www.cryptoarticles.com/crypto-news/bitcoindark-lots-of-growth-potential-if-done-right

at what price calculates multipool?

corrected

i have 200gh pointed at http://dark.xpool.ca/ and that earnt me a whole 1.16 BTCD for a 24 hour period..... seems a tad low. Not even worth the power consumption at that rate.

Yeah, mining x11 at xpool.ca only got 0.09 BTCD in more than 12 hours with 6.4 MH/s - does not seem worth it.

The code detected pubkey was missing so:

client sendmessage ([{"requestType":"getpubkey","NXT":"8989816935121514892","addr":"8989816935121514892","time":1406099070},{"token":"d79fth95u83cu087m4js5pr7oqktvg537dctmf7sclmv3thq7lq3ubpg6r172rg1672q8pjokm4t3gj j6pd7vts2inrrjb8vg14pau8dlg6ghe6i6o8rd4jan1qrvbu9nme1p1d6fg5ii04lo56md871vfualm rj"}]) len.279 to 1700913285397123524

8989816935121514892 is my test client
1700913285397123524 is the privacyServer

The server gets the above command and generates:
json_handler returns.({"requestType":"publishaddrs","pubkey":"9d390ba6881e5e213c0a90b70906e557806f6eb2327edfcf27d7fadcc5978602","NXT":"8989816935121514892","BTCD":"","pNXT":"","BTC":""})

to send back to the client. The JSON with "requestType":"getpubkey" are the convention the 127.0.0.1:7777 API uses, so by creating the same format text I avoid having to do another command parser. But, it gets super tricky, due to possibility of nesting and local/remote calls, etc. Anyway, I now have a handy function that takes a JSON command and sends:

server sendmessage ([{"requestType":"publishaddrs","pubkey":"9d390ba6881e5e213c0a90b70906e557806f6eb2327edfcf27d7fadcc5978602","NXT":"8989816935121514892","BTCD":"","pNXT":"","BTC":""},{"token":"vb5lpi57ea2pb4cvjn7g1i2ffrso4j7p7ban3vfmhv7ftcbp7lq3u4etehumqug10lm8a51lqac1rk3 8mf13pj29cilflm4khn6en5j3tfn0emnpsfhs15jbevt3f2k22mmdj3p1ck8retiklkkduo769673so df"}]) len.340 to 8989816935121514892

I just notice the "time" field is missing from the request, just fixed that in the source.

And the client gets it:
QUEUEALLMESSAGES.({"requestType":"publishaddrs","pubkey":"9d390ba6881e5e213c0a90b70906e557806f6eb2327edfcf27d7fadcc5978602","NXT":"8989816935121514892","BTCD":"","pNXT":"","BTC":""}) size.0

So a LOT of work just to send a message to myself, but this proves out the encryption/decryption code pretty good in the 2 layer onion case. I have a feeling each additional layer will create new more confusing cases to deal with. But not today. I can now finally deal with receiving a tradeoffer.

James

Thanks for the kind words. It helps especially when I am battling against some confusing bugs. All this onion routing stuff is messing me up. maybe because I am doing a loopback test, but I almost have it doing a query for a public key that comes back from the server. Once that is done, then I can finally encrypt the packet to the destination (ignoring that I still dont broadcast public keys, but that is not a worry).

Its basically just hooking up a tangled set of wires where all the colors are the same, but you need to match it up exact.

Ah, test run is done, gotta go

how you can tell at a speed of 600 GH , get only 1.6 BTCD?
http://btcd.xpool.ca lol

James, your updates are like strange beautiful music. Strange because I can't fully comprehend the technicalities, beautiful because I know you are delivering non stop. I am not surprised the market cap held up so nice while I was sleeping. Keep working your magic, I only hold BTCD and XC because both coins have excellent devs to back up the claims. Investing in coins without proper devs is gambling, so I feel safe here.