At first sounds simple, then becomes confusing, then almost simple, but always some extra twists to prevent the feeling of full understanding.
This is extremely accurate. At first I thought teleporting was very straight forward and only saw it as a glorified way of constantly creating new addresses. Then I got lost in hyperspace and forgot that whatever is in telepods still exist and I didn't see much point to it. Now I'm back to straightforward with the occasional feeling of hopelessness. What is most interesting to me is that it seems like having privacy in the network/hyperspace is only one small feature. I feel like managing a network off of the blockchain that can interact with other blockchains will potentially simplify most features other developers are trying to do, while also making those features available in all other supported coins (if they meet whatever the BTCD requirements are).
I would like to see in practical methods how anybody can deanonymize the teleport economy. That has been my focus, to make it as difficult as possible, to find the weakest link and make it stronger. Once I get the M of N info leak fixed, other than the creation/extraction points, the following is the info that is available for our attacker:
0. telepod creation/extraction and cloning events are seen on the blockchain, some amount of first two are compromised
1. IP addresses of all BTCD nodes (they can just run dozens of nodes and tally the peer data)
2. using 1, they can setup packet sniffers to capture all the data coming/going from your IP address (this is expensive)
3. using 2, they can see some percentage of packet destination for next hop and also the hop that sent it to you
4. by monitoring the Internet, telephone they can occasionally get info on some teleports, eg. you email someone and tell them you will teleport them 100 BTC tomorrow.
5. by using 0 and 4, a statistical model can be created. Starting from the compromised telepod creations, the probability distribution of which acct is controlling which telepod will be created. This model is continually updated as more data comes in and at first due to the small size of BTCD network, they can brute force correlate some significant percentage of tx. BTCD is classified as an interesting but not a threat to their higher ups
6. BTCD network grows, trusted teleports are added and what used to get some results in 5 starts degrading. As the teleport activity grows, the brute forcing is no longer possible, instead of having just 10 possible telepods for each compromised transfer it keeps getting worse and worse, now it is at 50 telepods and rising. When the trusted teleports reached a critical level (I am estimating 10%), it was as if a lot of the tx just disappeared. In fact, cloning events have dropped significantly, so either BTCD network usage is actually down, or much more than 10% is via trusted teleports. Some new assessment needs to be sent to higher ups, but without 1:1 correlation between teleporting and cloning events and entirely new statistical model will need to be developed. Where was that job offer from the private sector company, ah, good, I think I will submit for holidays and get a new job. This problem will be for someone else.
7. New guy on the job, after some time recommends to focus resources on specific suspected criminals with physical surveillance. It is just not cost effective to deanonymize the teleport non-blockchain, the petabyte HDD system is almost full of all the white noise M of N packets and our Quantum Computer is taking days just to peel one layer. Let us hope only a small percentage of people use teleporting as we cant sell the database to the other agencies if everybody started using it.
The latter parts are my fictionalized projection of what I think will happen. I am designing teleport to be resistant to this level of scrutiny and analysis and while nothing will be able to prevent physical surveillance from cracking anything, no govt has the resources to do this for all people. And that is my point. bitcoin tech is presented as anonymous and it could be, but it isnt. and this allows govts to use the tech they have to investigate criminals to be turned on everyone! without any additional manpower (just more CPU and HDD), they can start building a database on everyone. And they are. They laugh at bitcoin being anonymous and in senate hearing say things like, "we are not concerned with transparent protocols like bitcoin". Transparent protocols! If you believe that govt agencies are not doing this level of analysis, then personal level privacy is all you need. However if you dont want some low paid govt worker to be able to type in your name and get EVERY crypto tx you ever made, then BTCD is the crypto to use. You will get a "suspected teleporter" notation and any telepods you created will be tagged with your name, but they will know that like the person that goes to a bank and withdraws cash, it is meaningless what happens to the cash after you spent it. They cant even find the telepod after a few teleports as it will rapidly be possible for your telepod to be controlled by anybody in the BTCD network.
Once we achieve this, then the agencies can go back to hunting criminals instead of treating all people like possible criminals just because they have crypto.
This might just be me not understanding your network but how exactly does the network interface with other blockchains to do everything needed for teleporting - generating addresses/deposits and all that? Are telepods that are filled with other coins still managed right from the BTCD wallet?
I put the vast majority of MGW code, repurposed, into teleporting. The foreign telepods will be visible both in the wallet of the other coin and also via my API, and presumably in the web GUI for BTCD. You will also be able to issue command line to get listing of telepods
James
Yeah I have no doubt it will be nearly impossible for someone to crack and understand every layer to teleporting. What I meant by privacy being a feature of the process is that there are still a lot of other things that can be done with the telepods, while also providing anonymity.
You will be able to view telepods from the wallet of a different coin? Really? That seems pretty crazy.. how is that possible?
I think this bad drawing might be more accurate of a trusted teleport between two people. It is assuming that privacy servers are being used.
also #BTCDBreakout
the whole all nodes calculating telepod dividends will really mess up any attempts to use packet traffic for anything.
you cant see the full telepod, just the balance, it sure wasnt easy to allow this without having the wallet wanting to rescan the entire blockchain for each telepod! My MGW experience came in super handy, would have taken months to just deal with the basic raw transaction issues.
I merged the privacyServer code into each and every node! By default you connect to 127.0.0.1 (localhost) privacyServer, which is actually your own computer, but internally it believes it is talking to a privacyServer, and it actually is. Now in this setup, your IP is not shielded, so I would degrade its privacy level to personal, regardless of whatever else you do. [note: personal privacy is where I would classify most all of the other anon solutions]
so to get to corporate level, you need to use a separate privacyserver that you control, or subscribe to, that you dont care if the IP address is known.
Due to all the background "noise" of packets, I am just sending back the status without pushing it through M of N, but it still goes through the onion layers.
The protocol is:
1a. sender sends a transporter log to receiver
1b. receiver gets it and sends back confirmation to sender
2a. when sender gets the confirmation, the telepods are sent out in reasonably rapid succession, though I put in some random delay on the time scale of packet transit, eg. seconds.
2b. as the receiver gets a telepod, it sends back individual confirmations
3. when the sender gets a telepod confirmation it puts it in the verify on blockchain stage
4. when all the telepods are received a completed transporter log status is sent back
5. receiver sends back "trusted teleport" or clones each telepods at random times within the clonesmear parameter
5b. once a telepod is cloned, the receiver puts the clone in the verify on blockchain stage
6. when the receiver gets verification on the blockchain (or its trusted), the sender's balance is credited with the telepod amount
6b. when the sender gets verification on the blockchain (or its trusted), it updates balances with the telepod amount
Error handling:
1. if the transporter log isnt confirmed, then after a timeout, the teleport sequence is just aborted. nothing really happened, so this is easy.
2. if the sender does not get back confirmation of a specific telepod after a timeout, it should resend. [still need to code this]
3. if the sender does not see confirmation on the blockchain after the max clonesmear window as reported by the receiver, [not sure what to do here...]
4. if the sender does not receive a completed transporter log before timeout, [this is messy, still working out best handling]
so I dont even start the process till both sides have agreement on what is going to happen. Then I push through the telepods as fast as can be reasonably done without saturating and also creating a noticeable signal for the bandwidth monitoring attacker. Once the receiver confirms safe deliver of the telepods, now things are much less vulnerable to lost internet connections, etc. and should just be matter of time before the receiver trusts/clones all telepods.
So, there is a definite pending transfer period whose progress is seen on the blockchain. Only the sender can even know what to look for as no other node knows what telepods the sender has (they better not!).
I imagine the GUI could display some sort of progress bar for each pending teleport and there could be quite a few pending at once, especially if you use safe clonesmear times like one hour. This sounds long, but really 6 BTC blocks or just one long one can take an hour, so not so crazy long.
This is the high level simplified version of the Teleport protocol. Every packet that is transmitted is pushed through the onion/broadcast mechanism and this is totally plug and play, so happens transparently to the higher levels other than the Rfactor (in JSON .conf file). Due to data explosion I cap Rfactor at 3 and it could be 0, 1, 2, or 3 extra hops added to the basic -> privacy server -> [hops] -> destination. This means that all requests, statuses, etc. go through this mechanism.
There is a slight info leak due to difference in packet size. this can be used to do some analysis to detect the general type of packet that is being sent. I really need to pad all packets to be the same size. OK, I will make a note to myself.
Wait, I already did on line 31 in teleport.h
// make all packets the same size (option)
The M of N happens in 2a (writing this I just got an idea to make things better!) currently I serially process each telepod and generate the N fragments and send them to the transmission code. Now maybe there isnt a way to tell which telepod is being sent as a fragment, but just in case, I will generate all telepod fragments upfront, make them all the same size and then send them out in random order.
The reconstruction will work as is, since it is event driven and reconstructs a telepod when it receives enough fragments. [I need some error handling in case it cant reconstruct properly, but maybe I can just rely on sender to retransmit]
I hope this makes sense and any feedback on error handling is appreciated. I am most concerned about partially complete teleports as it creates a unique situation (in crypto) of a partial payment. I guess we might need a way to cancel the balance, or to somehow create a payment to make up for shortfall. proper accounting is a real pain and not exactly rocket science but when money is involved, it is quite important to get it perfect
James
Poll
