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

Walley turned into Willy
it is playing the bid side and has pushed the bids up 10%
I think it is pushing things into its asks, when they fill it will probably change direction
probably the thing to do is not feed the bot and put orders that it fills on either side
eventually it will lose enough money and go to greener pastures

Is anyone else playing Where's Wally?
I'm waiting for a 0.005 order to get filled on Bittrex. It was partially filled last night, but now the order book has been flooded with small orders, only 1-10 BTCD each.

thank u must have missed that

Read up a couple pages back in the SuperNET thread. He did quiet some lengthy posts on it in there.

you are awesome ,what are your thought's on what is happening with blocknet

./b SuperNET '{"requestType":"placebid","assetA":"11060861818140490423","assetB":"4551058913252105307"}'

./b SuperNET '{"requestType":"placebid","obookid":"12008998766472701676","volume":"1.01","price":"0.006"}'
./b SuperNET '{"requestType":"placeask","obookid":"12008998766472701676","volume":"1.1","price":"0.005"}'
./b SuperNET '{"requestType":"getorderbooks"}'
./b SuperNET '{"requestType":"orderbook","obookid":"12008998766472701676","polarity":1}'
./b SuperNET '{"requestType":"orderbook","obookid":"12008998766472701676","polarity":-1}'

The above sequence creates an orderbook {"obookid":"12008998766472701676"}

{
    "numbooks":    1,
    "maxbooks":    1,
    "orderbooks":    [{
            "obookid":    "12008998766472701676",
            "assetA":    "4551058913252105307",
            "assetB":    "11060861818140490423",
            "numorders":    2,
            "maxorders":    2
        }]
}

the orderbook API allows display in either orientation:

{
    "orderbook":    "12008998766472701676",
    "assetA":    "4551058913252105307",
    "assetB":    "11060861818140490423",
    "polarity":    1,
    "bids":    [["0.00600000000", "1.01000000"]],
    "asks":    [["0.00500000000", "1.10000000"]]
}
{
    "orderbook":    "12008998766472701676",
    "assetA":    "4551058913252105307",
    "assetB":    "11060861818140490423",
    "polarity":    -1,
    "bids":    [["200.00000000000", "0.00550000"]],
    "asks":    [["166.66666666667", "0.00606000"]]
}

this orderbook is for BTCD/BTC assets. The InstantDEX is needed to automate the teleport process.
havent hooked it up to the network yet, just local orderbook, but should just be a matter of making some network calls
Just a few more API calls to test.

James

I would never mess with a coin whose dev uses such language

guys you need to checkout SCSY coin its creating the next big thing a crypto stock exchange

If you think wisely, you can manipulate bots for personal gain. 

Dealing with NAT connectivity issues and other messy networking, slow progress. So, I decided to just see what happens if I ran the following API:

./BitcoinDarkd SuperNET '{"requestType":"teleport","coin":"BTCD","amount":".0001","contact":"s0"}'
now I have about a dozen telepods on my s2 server and already added contacts on both for the other. Now once you have a contact, it is put into the database, so it automatically loads. also, both servers have no connection issues.

the teleport command uses a simple genetic algorithm to select the telepods to use:
start evolving.14 at 384601.546000
     hwm {"c":"BTCD","tpd":"{\"v\":\"0.00010000\",\"t\":1414326260,\"c\":1538090497,\"x\":\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\",\"p\":\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\",\"a\":\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\",\"o\":0,\"s\":\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\"}"}
-> evolved with bestn.1 0x7f952c0a7d50
finished evolving 1 at 384601.846000

Once it finds the telepod, it encrypts it using a shared key and a one time password:

private_publish({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) -> s0.7
decrypted.({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) len.479
location.374764261261180465

telepathic.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) len.495 -> 140279230066432 374764261261180465

Now it sends it over the network using a findnode command:
telepathic send to s0.7 via 8447171643292973228 using 374764261261180465 (af79ca8f7e1eee29af74a8db4a12a8527e41613d975f3406e61487b955e26797)

Basically it is pretending to be acct #374764261261180465 and searching for node 8447171643292973228
You have to keep in mind that the actual destination's node address is 10694781281555936856.

####################### on the s0 machine, it receives a findnode for 8447171643292973228
but while it processes it, it notices that it is "from" 374764261261180465, which just happens to be in its list of possible senders that means it is really the 7th message from the s2 server acct 13434315136155299987

myNXT.(374764261261180465) kademlia_find.(findnode) (8447171643292973228) data.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) mynode.0
updated.1 (8447171643292973228)
saved parsed decrypted.({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"})
DECRYPTED expected (s2.7) ({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) lastrecv.6 lastentry.191
updated.5 (s2)
(s2.7) pass.(af79ca8f7e1eee29af74a8db4a12a8527e41613d975f3406e61487b955e26797) | process_telepathic: key.(8447171643292973228) got.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) len.495 from 374764261261180465 dist 28 vs mydist srv 32 priv 32 | 209.12


So a telepod went from one computer to another without any node knowing the actual IP address for the destination! Then I realized that I didnt actually hook it up to the telepod processing, so the sent telepod is now in limbo. I guess this will help test the teleport cancelling logic.

Still quite messy and many loose ends, but the fundamental process is working if all the conditions are met. Now I have to get the telepathic transfers much more reliable and of course activate the reception side of teleport, eg. cloning.

James

P.S. wc *.c *.h ->    34611  118707 1286274 total, yes that is 34000+ lines of code mostly written by me and it doesnt include:  wc cstdlib/* gzip/* includes/* libtom/* platform/* -> 53810  236325 2181668 total
almost 90,000 lines of code is compiled into SuperNET, this is over and above the libwebsockets, libuv and other libraries

Not too worried about out-trading him - I'm a hodler by nature. But no one likes being outsmarted, especially by a bot.

I havent seen how he behaves on the buy cycle, so not sure
if we can predict how he will trade, then he can become a money pump
eg. pumping money into our wallets

they key is to figure out its algo

Thanks. I want to buy more BTCD (well, who wouldn't?) and don't have a lot of spare cash. Was wondering about the best strategy to beat Wally.

Our wally bot seems to want to set the price at .005
it pushes the price down to .005 and then it starts doing the same on the buy side
this bot has a lot of capital, probably funded by the massive gains it has made over the months
just look at the side of the orderbook that is changing all the time to see which way the bot is pushing

so it is playing a game of attrition. insisting the price is .005, until everybody just accepts it. then when enough people sell to it at that price, it will flip directions.

anyway, i dont have time to figure out how best to beat the bot. now that you know what it is doing, hopefully someone will figure out a strategy and we can all adopt it and break the bot

James

I got making telepods working, and sending them is just a matter of reliable communications. I have it automatically monitoring and changing the status of telepods. The accounting is a matter of scanning the database, which is in place, so making Telepathy is the critical path for Teleport now. Anyway, this is weekend so I think I deserve to do some fun coding, instead of work coding.

Got some INVALUABLE feedback from zahlen on Telepathy
No giant flaws, but now there is a way to have out privacy without massive redundancy

turns out I had been using a hamming DHT distance function instead of the more pure Kademlia xor value as a number metric
intuitively it seemed so much better to have bitweight being metric, probably due to my obsession over the privacy issues.

Anyway, I have confirmation that in a network topology with enough connections, my approach will get rapid convergence and minimal redundancy, while still allowing the destination node to process each packet.

Also, zahlen has some advanced math method to find deaddrop addresses efficiently, so for now I will just use a fixed distance address, but we will eventually have deaddrop addresses that are shared among all nodes that are inside an H-ball. that is all the nodes within distance H of the deaddrop address. So, the intended destination node can be any of the nodes inside the H ball.

by using the hamming distance metric, this maximizes the number of nodes inside the 64 dimensional H-ball.

The sender is protected by using multiple onion packets to inject a DHT search thread. These will be started from the known nodes that are maximally distant from each other and the deaddrop address, but with no direct relation to the sender. So, after a few hops, nobody will know who started the findnode thread. and each thread dead ends at one or more terminal nodes that are closest to the deaddrop address. Until then, the routing is the very steep "send only to nodes that are closer than me" method. I also put in a duplicate packet filter so you dont end up sending the same packet to the same destination. This means network traffic will be at most alpha * log 2 of N, where N is the total nodes in the network and alpha is some small number 3 to 7. the duplicate filter will usually reduce the packets required to reach the terminal node.

Now at the terminal node, it will send the packet to all the nodes within distance H, so all nodes in the H ball will be guaranteed to handle the packet. the duplicate filter will again limit things, but the max would be alpha*number in H-ball extra packets at the end.

So, it will be like fireworks that shoot to a point and make a starburst. with 3 to 7 for each telepathic transfer it will get the packet to the right node, but only the actual destination will know the packet was meant for him

Some possible issues with AES key exchange, but that is all in a single function, so if any changes are needed, just a matter of improving it.

Now, if you use DHT based torrent programs, you probably notice sometimes it takes forever to get a transfer started. This is because nodes get clumped into sets and these sets are not guaranteed to have any overlap. This is really the only issue remaining, but the design of having a whitelist of servers should solve this nicely as all nodes will have a shared subset of the whitelist nodes. and by starting each DHT search from maximally distant points, odds are quite good to find at least one path that reaches the destination node.

I will have to run simulations on various network topologies to verify this and this ties into having each node create a good map of the existing network. This doesnt have to be done quite at this stage, but we really should validate the larger network sizes before we deploy to much larger scale.

James

tl:dr Telepathy will be a fantastic improvement in privacy and it will scale to any sized network

I've placed some order at 0.0045 on bittrex and cryptsy for around 6 btc. I've made couple btc's last week while buying in the 0.0045-0.005 range and selling higher. I would not expect that the price is going below 0.004.

BTCD well on it's way down to the 0.004 range, if/when it crashes through the mini-wall at 0.00400001 I suspect we will be seeing the mid to low 0.002 range again shortly thereafter.  Think I'll be holding my satoshi's and placing a buy order much lower a bit later on assuming everything still seems to be progressing.  Whomever this bot belongs too it's one big ole pain in the tookis.

You know what they say in Texas: "Oil-well"

Hello all BitcoinDark supporters!

BitcoinDark has been added for trading on our online exchange.

BET trading is available with BitcoinDark.
https://alcurex.org/index.php/crypto/BTCD_BTC



All feedback on the exchange is very appreciated.

Happy trading!


ALCUREX OY is an online cryptocurrency exchange registered in Finland.
Business ID: 2612007-8 FINLAND

Just for the record it's good to have someone watching over us


Bots and Conspiracy! Do they really exist?

http://dailycoinnews.com/2014/11/01/bots-and-conspiracy-do-they-really-exist/

I pushed a version that supports both http and https, via 127.0.0.1:7776 and 127.0.0.1:7777 respectively
this is required to allow the GUI to access both SuperNET and BTCD from the same HTML.

I also added GUIpoll task in the SuperNET app, which will allow for unit tests and other programs to be written that uses feedback from the other nodes.

That was required so I can automate the laborious and error prone process of establishing a telepathic link between two nodes. I did manage to get it to work, but it required a lot of things to be done correctly and in the right sequence. Since we need to get the GUI and test programs done, it made sense to make this now.

So many details...

Anyway, I am getting some invaluable feedback on Telepathy from zahlen and will be incorporating that. Things are getting very close and I could get some manual point to point teleport working, but I'd rather get a semi-automated one if only to save time while debugging.

James