Can you point out the inaccurate parts of this crude drawing
- Do you actually send funds to a 'transporter' first or was that term just used to describe the originator?
- When you create a telepod do you actually withdraw BTCD from your address into the telepod's address?
- Im confused about what data is actually in the telepod
I actually create an account label called transporter. This account is only used by the create_traceable_telepod function. As the name implies this is a publicly recorded tx. The recommendation is to directly withdraw to the transporter address from an offshore exchange or from some mixing service. Now maybe we get people who dont mind others knowing that they have created a bunch of telepods, in that case just transfer funds to the transporter account and create_traceable_telepods.
I expect that there will be people that will sell aged telepods via InstantDEX so others wont have to make any public record about creating a telepod. Still working out details on how InstantDEX can allow blockchain verified but private swaps of the initial traceable telepods. Even without that this is only an issue for the first transaction after telepod creation, but you might have noticed I just dont stop until it is as perfect as I can make it. That is the nice thing about software, you get as many do-overs as possible. Too bad golf doesnt work that way too.
The telepod creation is a "normal" transaction as far as the blockchain is concerned, and funds are taken from the transporter unspent outputs into a telepod. I put in there all the information that is needed to deal with teleporting. Since you asked, here is the telepod structure:
struct telepod
{
uint32_t filenum,xfered,height,sentheight,crc,totalcrc,cloneblock,confirmheight;
int16_t cloneout;
uint16_t len_plus1,tbd2,tbd3,tbd4,tbd5;
int8_t inhwm,ischange,saved,dir,gotack,spentflag,tbd6,tbd7;
struct transporter_log *log;
struct telepod *abortion,*clone;
double sentmilli,recvmilli,completemilli;
char clonetxid[MAX_COINTXID_LEN],cloneaddr[MAX_COINADDR_LEN];
uint64_t destnxt64bits,unspent,modified,satoshis; // everything after modified is used for crc
uint16_t podsize,vout,spad;
uint8_t pad,pad2,extraspace[255],sharei;
char coinstr[8],txid[MAX_COINTXID_LEN],coinaddr[MAX_COINADDR_LEN],script[128];
unsigned char privkey_shares[];
};
See, isnt it simple!
all the tbd, pad and extraspace are just filler so I can add more fields (the ones I am not smart enough to know I need yet) without changing the size or location within an existing telepod. Now this is just the thing that holds a standard denomination, there is a transporter log structure that binds a bunch of telepods into a single transaction. You can think of them as the high level packet and the telepods are the low level, which needs to support the onion routing, radomization of paths/retransmit, and retry if there is timeout, validating the cloning on the blockchain and some other things.
your diagram shows the worst case of telepod creator sending to telepod extractor and it also doesnt really show the M of N or onion routing, but other than that I think it is pretty close.
James
P.S. The cloning appears on the blockchain, in fact other than telepod creation and cloning and extraction, nothing else is on the blockchain. Ah, also forgot about trusted teleports, that is where there is no cloning before it is sent to the next person
P.P.S. key exit path of trading the telepod back to the creator to create a self-canceling loop of creation + cloning events
Poll
