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

law enforcement can always simply break down your door and confiscate your computer and torture you to get you to divulge your passwords. What I am doing does not prevent this. law enforcement has to go through your physical door, no backdoors in any of my code!

In any case this is non-communications as who did you really contact by sending packets to addresses that nobody actually uses? If a packet falls into a dead drop, did anybody decrypt it?

James

This is pretty cool
Today I happened to read this article: http://www.bbc.co.uk/news/technology-29567782
in which the head of Europol's Cybercrime Centre says, "There is confusion among the good guys on the internet between anonymity and privacy. I don't think they are the same. I think that you have right to privacy but that doesn't mean that you have the right to anonymity."

The increasing trend towards greater encryption of online communications is not acceptable, he said.

"Imagine in the physical world if you were not able to open the trunk of a car if you had a suspicion that there were weapons or drugs inside... we would never accept this.

"I think that should also count for the digital world. I hate to talk about backdoors but there has to be a possibility for law enforcement, if they are authorised, to look inside at what you are hiding in your online world."

couldnt sleep due to this idea!

have to tweak the Kademlia DHT calls a bit as this was not part of the original method, but I almost have it solved

The really cool part is that all this privacy of the IP<->account is extra protection as the telepods themselves are not directly linked to your published accounts. But what extra protection it is!

Imagine you are trying to figure out who is sending packets to each other, this is really required to be able to make any sort of linkage. With the Internet, basically all comms are tagged with the IP address, so if the attacker has packet level data, then they can see who you are talking to. With encryption, they cant tell what you are saying, now they wont be able to tell who is talking to who.

A. Alice and Bob publish their public keys to the cloud
B. Alice and Bob exchange the deaddrop addresses (actually I have an improvement on this, but let us use B. for now)
C. Alice and Bob send fragments of each packet to random deaddrop addresses
D. All the nodes process these packets normally, but they end up in a dead end as no node actually uses these deaddrop addresses. Ideally the deaddrop addresses are equidistant from a large number of nodes, but they are random distances from Alice and Bob so the possible nodes that are Alice and Bob are dozens if not 100+, basically random guessing.
E. It just so happens that both Alice and Bob's nodes were close enough (using XOR metric) so that their nodes processed at least M/N of the packets from C and decrypted them as they were handled.

F. Attacker gets a new job

For those who thought the DHT was a waste of time and a distraction from completing Teleport, please realize the magnitude of this breakthrough. Whatever extra time it takes (and it is not clear we will lose much time overall as Windows build, GUI and larger network are still not in place) will be well worth it as with this deaddrop level of privacy, it is safe to say that there is nothing that compares to this. At least nothing I am aware of. Maybe somebody knows of something remotely as good as this?

Originally I didnt think I could actually solve this part of the puzzle, so I made the Teleport design strong enough in other parts so that even if the IP<->acct relation was leaked, it wouldnt matter. Before Teleport was dark, now it is invisible. I guess we got a cloaking device

James

P.S. I realize B is the weakest link now as this is the only "direct" contact between Alice and Bob, granted it is via onion routed same sized packets, but I have an idea to make this part invisible also.

That is an entirely different level of crazy.
Way to go james!

running some simulations and when we get to ~500 nodes, within a few minutes I am finding a deaddrop address that has the exact distance to ~20 nodes. this is at distance 24, which I believe is about 1/256 of total nodes and with a K factor of 7 even without any special relaxing of distance requirements, the packets will automatically arrive at your IP

The larger the distance, the easier it is to find matches. At bigger distances, 10% or even more of the sample set are exact matched. The good thing is that when the total network size is small, we can just cache all the nodes so big distance wont matter.

I also got it so that each node creates a list of addresses to match against and when the network is bigger, each node will hav a slightly different list it will be optimizing against.

It looks like we can have a set of deaddrop addresses that each have exact distance match to 10 to 100 public privacy servers and also decent distances to a lot of other nodes. Then we can choose 64 of these deaddrop addresses to establish a super secure link.

Since the only one that actually knows the IP address is the person running the node, I think that short of it being compromised there is no practical way of correlating your IP address. keep in mind that packets are sent to 64 different deaddrop addresses that dont really exist, so I am not sure how anybody would setup a sybil attack or any other attack to link your IP address to your acct.

Now even if somehow this info leaked, just knowing your acct # and IP address is still not enough as you would be transacting with telepods which themselves have no acct linked to you. Since people had a hard time understanding the simpler form of Teleport, I fear that few will be able to understand the new deaddrop approach. Hopefully somebody will provide some feedback on its weaknesses, if it has any.

I feel this is a fundamental improvement in privacy. In all prior versions, there was at least a statistical linkage of your acct # with IP address. Now, all that is happening is that packets are being sent to dead addresses so there is nothing to correlate. Other than the distances to the other nodes, but with the mining of equidistant addresses, this only gives a statistical correlation, and that is a dynamically changing thing, especially with the randomized sending of packets to the set of deaddrop addresses.

This is a bit of unexpected extra work, but the qualitative increase in privacy is well worth it. Not sure if you realize that this does the "impossible", routing packets to someone on the Internet (IP) without knowing their IP address and without broadcasting or wasting bandwidth.

Imagine being able to send email to someone without knowing their email address and without spamming everyone. This is on that level of crazy.

James

pushed new version with bugfixes and is a bit incompatible with new version
please update with:
./m_unix

Each node runs a public IP privacy server. this means people will be able to link your IP to your servers' acct number, so it is suggested to just use an acct without anything in it, maybe a few NXT just so you can lock it in as yours.

This IP/acct will then participate in the DHT routing for all SuperNET packets.

To transact privately, you let people you are dealing with know your public acct. this is another throwaway acct, but it is used for authenticating that it is really you doing the transactions.

Here comes the magic!

Each session, you generate a new keypair and without the current keypair's public key, nobody can transact with you. So you publish your session's pubkey into the cloud. Now anybody that knows your public NXT acct can get your current pubkey. If you want to prevent this, you can encrypt the pubkey and only share this with a small number of people, but divulging the pubkey is not so bad, so additional steps are for the truly cautious.

For super private comms, both parties generate a "sphere" of deaddrop acct numbers that minimizes the distance difference between your privacyServer's acct # and its neighbors. What this means is that even if the deaddrop acct number(s) are compromised, there is no direct link to your IP address. This exchange is done under encryption and is automated process and only needs to be done once per session.

Each side would split up each packet into M of N fragments, M of N chosen so enough of the packets are within the maxdistance limit of being routed the DHT packets. From the natural DHT routing process, your server will route these M of N packets to the closest nodes to each deaddrop acct #, but there is not even an acct behind the deaddrop acct. it is just an address that just happens to be close to your server's address, but far enough away that it could be close enough to any number of other IP addresses. Using M of N, allows the sphere of addresses to be significantly larger than what is hardcoded to be routed to your node. This is build into the DHT, eg. sphere of radius 28, and all packets destination within 24 bits guaranteed delivery.

Now the packets that are flowing through are fully encrypted so only your node can decrypt it. Output packets are randomly delayed so timing analysis cant determine if your node decrypted it or not based on packet traffic. All packets (other than ping) are fixed size 1400 byte UDP packets. Using UDP prevents TCP DOS attack locking up the sockets for the tcp timeout.

James

TL:DR it is possible to transact with someone without ANYBODY actually knowing the IP address of the destination, and therefore very private comms are possible. If these comms happen to have telepods and funds are being transacted, then commerce can happen using this method.

Come on now, that's not very nice. It's possible it was a legitimate question.

No, BTCD is very different from litecoindark. Please read the op of this thread and check out the website: bitcoindark.org

It's like comparing skateboard to spaceship  
You must be retarded. Here is your answer.I can also write it in your topic if you want to
https://bitcointalksearch.org/topic/m.9166053

Is BTCD like litecoindark?

addet bitcoindark to our altcoin info - news - etc site...

https://bitcointalk.org/index.php?topic=684090.7200

greetz

Very interesting

This is great news!!

Hi,

I am currently working on the following plan.

There is a need for at least to kind of nodes. There are SuperNET privacy nodes and (Hallmarked) nxt nodes, mostly run by persons on a VPS.

For these nodes, it’s currently the case that you have to buy the VPS, install the necessary packages and build the coin wallets and libraries/API’s. Building a privacy node is still quite cumbersome and daunting for most users. When you look at what you need to do, I would say it will slow down adoption if people have to go through all this.
This does apply more for a SuperNET privacy node then a simple NRS node for NXT. But still, for both nodes I think it would help to ease things way more, so people can buy a VPS and start right away, and get up and running in no time.

What to think of all people who have their nodes running and need to keep it secure too. Some firewalling, ddos prevention, encryption, hardening of ssh, hardening of various Operating System tools and monitoring tools and all that.

The situation is now:

User buys a VPS. The user tries to find a manual and starts configuring. In the case of SuperNET nodes, they will likely get stuck along the way, and have to try to get through it.
Personalise the installation: Create accounts and passwords.
When it’s build, they can run the node, but as things do change, they have to update quite regularly. In the case of a NRS wallet, it’s less frequent, but still they need to update it.
When running the node, it should be kept up to date. When exploits and vulnerabilities arise, the user should act on that.
This node is still not secured, unnecessary services are running, no firewall is set up, no hardening on services and operating system is done AT ALL. It’s only a base setup of Linux and there is nothing done to harden it. Everything should still be done, following 10 page tutorials of how to make sure the machine is secured.
And then, still, there is nothing in place to keep it secured, and no monitoring is set up.


What if, the situation would become streamlined like this, how cool would that be:


User buys a VPS. User signs up for the Master node and gets an acknowledgementTurns on the VPS, start a script.
Drink coffee while the machine is completely installed. Personalise the installation. Create accounts and passwords.

That’s it!

Simple as that.



From now on, the user has it’s machine updated (if they wish) and don’t need to look at all the things that change, new releases and updating of the machine.
Also, a complete firewalled and secured node is  there, and lots of things are hardened on the machine, secured and unnecessary stuff is removed and all configuration to make and keep the machine secure is done for you.



I worked out this concept and it can be implemented for these Privacy nodes and NRS (hallmarked) nodes. It will be a breeze for a user to get this VPS up and running.


How will all this work?

There will be a master configuration server. There can be one, but there can be more of them for redundancy. 1,3, or 5 or whatever seems appropriate.
This master server will be setup completely to build and deliver the configuration for the nodes. It will contain configuration for NRS nodes and Privacy nodes, but I can also deliver this service for other type of coins which need nodes with wallets (and possibly other stuff).

This server has to be build, everything that will be done on a node, will be setup here in scripts, separated in various modules. These modules will contain the software which is needed and all configuration changes in such a way to get these nodes in a certain state. I can easily differentiate different kind of nodes and these nodes can get the software and configuration they need. I can reuse the needed modules and differentiate between node configurations where needed. When adding a new kind of node for a new wallet or a new type of server, I can add this to the configuration. Also, when some company/idea connected to NXT (or another crypto currency) they can talk to me to see if they can have their node configuration automated too. It can then be added to my master server and nodes can be created for it in no time.

When I’ve finished a complete node configuration I can easily deliver 100 nodes in one day, if necessary. It depends on how fast you can buy VPSes and turn them on
When someone requests a certain node, I only need to add it to my master server and when the node identifies itself with the master server, once acknowledged it gets it complete configuration pushed and the server will get its state as it should be. And the node will be kept current and secured, for the future.

Also, it’s possible to set up  different Linux distributions with this concept. It means extra work in the beginning but once done, other distributions can be set up too.

Security configuration and updating is a continuous job and can be done centrally.

All wallets will be packaged in the needed package formats. A repository will be created via Ubuntu PPA, so ANY node, also nodes that are not setup via this master-client concept can then install these packages simply via apt-get. So people who are not interested in this whole concept, can simply get these wallet packages with apt-get and can also update the wallets packages simply via apt-get, when a new release has come out.
Packaging the wallets will be quite some work, but once done, I can try to keep them up to date.

All this is part of a bigger plan I’’m working on. I will write about that soon.
I actually wanted to publish this part equally with the whole plan, but I started building this master - clientnode concept already, because SuperNET is in need of 50 to 100 servers to get launched.

This pilot phase will help NXT and SuperNET hopefully because setting up Privacy and NRS nodes will be as easy as pushing a button.



Frohike

Klapper that is exactly what I was thinking. I was gathering quotes to build a system such as yours but with more monitoring built in so we can tell if a node needs an upgrade or if it goes down.

If you are building it already there is no point duplicating the process.

0.00800000 for btcd in bittrex. expect 0.01 in nex 3 days

Thanks！
I did save it as "BitcoinDark.conf“, with contest:
------------------------------------
addnode=107.170.59.196
addnode=146.185.188.6
addnode=74.91.20.250:39997
addnode=54.85.50.15:50288
addnode=186.94.211.104:49543
addnode=107.170.148.50:14631
addnode=65.129.66.246:57762
addnode=31.220.4.41
addnode=98.226.66.65
addnode=193.219.117.63
addnode=62.210.141.204
addnode=128.199.172.165
addnode=192.99.143.114
addnode=178.20.169.208
addnode=195.34.100.2:42038
addnode=5.101.107.239:60056
------------------------------------

It did sync, but stuck at block 100001.

You are professional ripper, your topic in public Rippers

edit the config file in notepad, and be very careful to save it as "all files" not "txt file"  in dialgue box.  safest is to create a completely new notepad file that has never been saved as txt, paste in config, and save as all files / .conf