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

safron is just another huge cartel dump of a pre/flash/insta mine, in my opinion..  

lol you have an interesting post history.

Its a good coin but it has gone up a hell of a lot.. SFR is 1 /20th the mkt cap of BTCD so the hot money is going there now, as its much easier for it to increase in price than BTCD... Usually once you get a 60 - 70% fall from the peak you will start to move up again.

Nothing to worry about. Short-term investors cashing out and people are looking for faster profits somewhere else.

I've full trust in the developer team so I don't mind temporal price fluctuation

tried the above multiple times it still says i dont have mature coins

Sad to see the price is going down  Anyone know whats causing this? People lost interest?

Usually because jumping between the various SHA altcoins lets us rape the coin difficulties enough that it's about the same as BTC
I am exploring with a local BTC P2Pool node so that I can include BTC (and the various BTC merged coins such as NMC, IXC, DVC etc) in the SHA coin rotation.

Why are you not using a BTC stratum pass through to another pool like MP does? If nothing is more profitable than BTC... why aren't you mining BTC?

BTCDPool.com is again having a hashrate too low to effectively mine PPC.  PPC has 10 minute blocks, but yields basically ~0.2x BTC per solved block.  If we could get back even a tenth of a petahash for a few hours, it would be immensely profitable and would create a ton of buy pressure.  Especially with the pool able to switch in and out of PPC whenever the diff drops.

There were some stratum resets earlier when I was implementing PPC, not sure if that was what scared some of the miners away, but there hasn't been any for several hours now and there won't have to be any further ones as the pool is accepting PPC shares properly now.

BTCD is list on Bter voting.
Come on BTCDers.
https://bter.com/voting

okay awesome.

sorry about that, just uploaded a version that statically links in libwebsockets.a
hopefully the new version will work better

hey only one issue need to link the libraries currently get this error.

Okay, that's all I needed to know.
As long as things are clarified before funding starts, than I am all ears (and perhaps wallet) 

Great!

here is a test client: http://209.126.70.170/BTCD_client

its just for Mac and you need to have NXT running on testnet for proper operation
The test client is just a subset of the main pNXTd, I just couldnt figure out how to get it all sorted when it is a client and server on the same machine, so easiest to split it out.

Just open a browser to http://127.0.0.1:7777 and you will see a horribly ugly page of text forms
Its ugly but gives you direct access to the API

The first thing to do is make a password, its for testing so doesnt need to be high entropy, but for mainnet you want to use something like the following to generate a password:

openssl rand -base64 66

So, once you have a password, that actually means you have an account. The password direct maps to an account number. At this point you will need a few test NXT, just ask and I will send some

First step is to select a privacyServer, thats the first form.
put in your acct password and 209.126.70.170 for IP address
You should get a response like this:
[{"NXT":"1700913285397123524","pubkey":"22f1c1bebf6719cc19f23767a39bd39e36e2d8ddabd03b9b8de6edeacc8e627a","time":1406182060},{"token":"vb5lpi57ea2pb4cvjn7g1i2ffrso4j7p7ban3vfmhv7ftcbp7qs6q4et2fkd0d01h0q50i79335shn3 3brj8q152od6fdjeot91mgpbkohpgopuut00aftqgtp9cneornfq41besf0l3e2ca27th1uf1jqj31m 57"}]

If you do that means you are connected to the privacyServer

now you can create order books, submit bids/asks, get orderbooks, send chat messages, etc.
We probably need someone that can document the API
Most people will never need to access stuff at this level, it is the "command line" equivalent, but I know most people like GUI and that is how almost all will use this, but for the GUI to work the API needs to be solid.

For now, I dont really have any test instructions and there is not too much error checking, but hopefully it at least makes contact with the privacyServer and you can play around with it.

James

P.S. I make no uptime guarantees with the 209.126.70.170 server as I am always updating it, possibly with broken test version

I'm also on mac 10.9.3 and I've had success building pNXT on both my mac and ubuntu hosts 12. 13. 14.

Thanks!
I just want to be done with all of the major coding as soon as possible.
Its like when an idea gets in my head, I have to code it, otherwise it keeps nagging at me.

I will try to get a cool demo release next week with some ability to trade between accounts. How many people are on Mac's? It would be easiest for me during the early testing phase to not have to bother with Windows releases and just release the Mac app I am using and people can select my privacyServer and we can do some simple tests.

The InstantDEX infrastructure is not only very useful it will be the basis for most of the other features, so I really want to get a head start to finding bugs. I have a feeling InstantDEX revenues will be quite nice and that will provide the funding for the 500+ hubs.

When that is stable, then it is time to synchronize all the hubs so you can be connected to any privacyServer and get the same data stream. At some point I switch all this code from pNXT into BTCD daemon and various other housekeeping stuff. The exact order other than InstantDEX, I wont know until I get there. Each day I learn and based on that what I knew yesterday is a bit improved, so hopefully you can all be OK if sometimes things change. I only try to make it as good as possible.

James

James, your dedication is astonishing. I think I can speak for a large part of the community if I say we have 100% faith in you. Take your time, daily price is of little importance in these development stages. We hodl. Thank you for your unwavering energy in making BTCD the gem that it will be (and already is imho)

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 () len.809 to 8989816935121514892

sendmessage ([{"status":"1700913285397123524 sends direct encrypted sendmessage.() [] 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