Topic: BTCD is no more - page 190. (Read 1328507 times)

What's going on with the price?

@StealthCoin

it's better for me to earn 20%-30% in other coins once in a while, than to wait months for a particular coin to go 100%. i sold some coins to go into other coins. And I have secured my money. I am only trying my best to keep my money up even though many coins are declining in price over months.

Right now, for some reason no proof of work coins are profitable anymore for your gpus. Back in 2013, 1Mh/s scrypt would pay you $15 a day. Now its not even $1. Don't know when this whole decline of prices will stop, but I think the profitability is long gone. And now it's just 10 shitcoins/s speed of cryptocurrencies, which is retarded and people including me are losing money so fast. Because that most of the traders put money anywhere without even thinking. If we all just stick to the gold ol' coins, the whole altscene would have been different. All of the hyping up of one or two features offered by a coin to pump it until the feature releases and then dump it until it's of no value, even worse the selling of these vaporware everyday. This all needs to stop to recover from this shithole of altscene.  

The price is outside of anyone's control and no individual really has any idea when it will go up or down.

A good quote that sticks in my mind is, "the market can stay irrational longer than you can stay solvent", or something to that effect.

All I can really say is that at this point is progress is being made on the new tech daily and a lot of people are doing some great things.  However, we (the bitcoindark dev team) need to do a better job communicating the importance of the tech being developed to the market which would likely have a positive impact on price.  

We're working on getting better at that and hopefully this will allow the market to better reflect (in price) the value of btcd.

**I say hopefully because it is up to the market to realize this value:  BTCD will provide the most secure system of communication and transaction ever and be linked up to other coins unique features with a click of the superNET tab within the wallet client.  I don't know, does this have any value? 

I am not saying this is the ultimate and best time to sell your coins. But it's better for me to sell and earn in other coins.

But the fact that is not only btcd, but the rest of the altcoins as well that they're all declining. And no one knows when this will actually stop. So it's always better to trade sensibly, not to listen to people on forum who tell you that it's cheap. Anyone could sell at 0.01, that was fair price, compared to where it's now.

People posting comments like it's cheap and whales accumulating only make it alarming for me. Since every time someone starts the chants, price declines faster than before.

don't get me wrong, but every guy is saying the same thing "its so cheap now" and "whales are accumulating" why don't you buy it up?

don't know why every time someone says "this coin is long term, price doesn't matter" and "weak hands are selling" etc. makes me want to dump my bag and move on.
People need to stop this stupid mentality. Maybe it makes them feel better somehow that the price will move up again, because it's always whales and weak hands. But really, maybe it's just how market is going to be. It's been on a decline for month now.

thanks!
I think I just finished coding low level Telepathy transport layer. Since I am using UDP and many things can go wrong due to no fault of anybody (nodes dropping out, onion hopping to a node that is gone, etc) it is quite likely that a packet sent to a destination might not get there, but ones after it could. So I need to implement some sort of TCP like retry layer on top of UDP. Good thing I already did this earlier this year!

Due to the way the packets are sent, it is quite tricky to get it to work, but finally I managed to achieve this as follows:

When a contact is added (happens every init), the published public key from the NXT blockchain is used to create a shared secret between two accounts. These accounts are totally abstract and are not tied to any IP address at all and it also happens to be the key I use for the DHT traversal.

Now I could send an encrypted message between nodes to exchange the dead drop addresses, but I think using a non-predictable (to anybody else) but deterministically calculated address that only the two nodes can calculate is safe enough. Even if this is somehow compromised, it is only for a bootstrap to get a decent deaddrop address to use. Once the comms are established, then the deaddrop address to use can be updated at anytime and there is a way to get it to the other side.

Each message between the two nodes will get a sequence number and each also gets its own onetime AESpassword that is calculated as follows:

    sprintf(buf,"%llu.%d",(long long)nxt64bits,sequenceid);
    calc_sha256cat(AESpassword->bytes,(uint8_t *)buf,(int32_t)strlen(buf),shared,(int32_t)sizeof(bits256));
    init_hexbytes(AESpasswordstr,AESpassword->bytes,sizeof(bits256));
    return(conv_NXTpassword(secret.bytes,pubkey.bytes,AESpasswordstr));

sha256cat is H(m || sharedsecret) where m is the acct number of the sender with the sequenceid

So, this means the password can only be created by the two nodes who know the shared secret. I ran into a problem that the piggyback attachment was a totally encrypted blob with no header info at all. I could have put a onetime pubkey, but since I am using the sharedsecret for AES cipher I didnt want to venture into unsure crypto things. So to keep things totally encapsulated in the onetime AES cipher, I needed some other way to let the receiving end know who was sending it.

Remember that in Telepathy, there is no destination address that is actually real. It is an equidistant (in DHT space) address to N public IP privacyServers. N will hopefully be 20+ and one of these IP addresses is the actual destinations, but it can never divulge which one, so the bootstrap was tricky enough, but I solved that by putting it into the cloud at a location that is the curve25519 pubkey of the AES cipher. Another oneway function and this also combined with the need to protect the sender. After all if the sender is making DHT calls with his address in the JSON, even though it is protected by encryption, the DHT node that handles the hop has to decrypt it and if the attacker is controlling the node, then this leaks the fact that the sender sent to a specific deaddrop address. Far more leakage than I am comfortable with.

I just used the same address for all such Telepathy payload packets. But that is quite redundant and wastes precious space. Also, I use the sender's address as an authentication method and using a static address loses that. Luckily, this protection of the sender can be achieved while also providing authentication by using the "location" of the packet's sequenceid!

Now without modifying the encrpted attachment and without leaking any info, the receiver can use the "sender" field to figure out if a Telepathy packet is meant for him and most importantly what AES password to use. No need to brute force try all the possible contacts sequence id passwords, as we know what the "location"/"sender" will be for all the expected sequence ids from all the contacts.

Still have a few small issues like how to send back retry requests safely, but I am quite pleased at how all the pieces came together. I think I will be able to debug this tomorrow and at that point I will be able to send sequences of packets between any two contacts and have it reliably get there, well, assuming I can get all the bugs fixed. Realistically in complex network topologies there will be bugs, but so far so good.

As you can see, with a reliable low level packet transport, all sorts of things become very simple to do. Like file transfer (say telepod files!) or even low bandwidth audio. That would be cool, to be able to stream voice over Telepathy connection

I know this might seem like a lot of tech babble, so if you dont understand it, just ignore it. If you do understand it, plz feel free to point out any flaws. I tried hard to make sure there arent any, but with something like this it always helps to get as many eyes on the issue as possible

James

#### The following are the externally visible actions:
1. sending out a 1400 byte packet to a random node for the onion layered packet that contains the DHT storedata of the encrypted deaddrop address.

1b. some random hops later a random node will decrypt the DHT storedata and start a DHT sequence, which gets it to the secret location in the cloud.

2. sending out a 1400 byte DHT findvalue request for the secret address directly using the DHT sequence, so the DHT nodes will know that you requested something from the cloud. however, this will just look like all the other findvalue requests as it is just to a random address.

2b. the DHT nodes that are involved will find out the size of the encrypted data that you get. For now I am not making this all the same size, I probably should, but I need to first determine what the max size should be. At some point you get a 1400 byte packet back with the encrypted deaddrop address

3. you send 1400 by onion routed packets with the sender actually being the "location", so as long as the randomly selected nodes along the onion route are not colluding and sharing info about the source and destination, nobody will even know that you sent this packet out. The odds of the attacker control all randomly selected onion nodes is pretty small and they wont know for sure that you were not just forwarding, but in this worst case they will know that you sent some packets to a dead address.

4. your node participates in DHT routing following the same rules as all the other nodes. Even when you get a telepathy packet, there is no visible difference as any actions are deferred a bit and the output timing and even order of packets goint out of your node is randomized.

James

Awesome, keep up the good work.  Thanks for the hasty response.  I'll keep buying as the weeks go by then and Ill keep supporting your work

It is hard to get exact timeframes, but I am working doubletime 7 days a week until I get the tech done. Things are working on a ~20 node network now, though a bit buggy, but there has been quite a lot of new code so it just needs to be debugged. The designs I am feeling quite good about and feel that it will be state of the art in many areas, especially privacy. which after all is what we are trying to do.

If we can get some test programmers writing unit tests and help with troubleshooting, regression tests, then things will go quite a bit faster. As soon as the Telepathy networking is solid, then I will be able to code at a much faster pace. I am testing telepathic transmissions this weekend. I will know a lot more early next week.

longzai understands the API structure and is coding a GUI to that, BTCDdev is doing the Windows build, so all the parts are headed toward completion approx same time. Active testing by different crew will double or triple the speed of completion.

James

I just want to start off by saying I love everything about this coin.  Are there any timelines up ahead we should be reaching soon?

You would gain more respect for your views if you had the guts to use your real handle.
Though not much more.

Look what I just found on my parents kitchen table. 

All of a sudden for some unknown reason when I run ./m_unix its not finding ./BitcoinDarkd this also seems to have happened after downloading the nxt blockchain.

I can't find it in the file system.  Whats the command to bring it back?

Hmm touched 530k?

They've also been leaving the multipool to mine dogeblackcoin.... and here I thought we had a really smart bunch of investors... BTCD is cheap right now and the multipool users would benefit huge by keeping the hash rates higher to buy up as many as we can.

www.bitcoindark.ca

Cheers!

Actually the investment model james discusses makes a lot of sense. All of the coins in superNET are invested in each other financially, which incentivises them to work as a team (in order to experience a shared growth in value).

Some  people maybe are selling BTCD to buy CANN, MARYJ etc.  
I could not imagine a worse investment but their money their choice  

If they have not yet had a lesson than they will have a little painful  

Due to the uncertain situation of Bitcoin , considerable amounts of capital are leaving the altcoins market . This issue has a large impact on all altcoins market.
Also Robots hasn't an analysis of market sentiments. they doing buy and sell for earn some profit even at low prices . Of course we should not forget the negative activities of trolls and FUDs.
All these cases in total has created current situation for BTCD.

Working on it.

Thank you!
Is there a Windwos build available?
Does it work with dynamic IP addresses or DynDNS service?

This is the build instructions doc https://docs.google.com/document/d/1CGUgDAhimVhz7aHAnITeZGr2S4RiZPzF2LYZIWGbJ1E/

I've added another node yesterday night. Two of my nodes running the latest build.