Mike Burr - log

[BT®] gyges.money

#idonnoisstupid

I decided to whoa golly start a project with these values.

We're talking "registered a domain" serious.

No, I do not want to troll the man. You should stop and think about how dangerous and regulated you want mathematics and software to be considered. We're just invented computers practically yesterday and we've already got a long, ugly, stupid record of trying to regulate ideas.

I think this is a bunch of blue-hair, busy-body nobodies ruining what could be a bright and totes chill future world. With sociopaths at their lead. What could go wrong?

I am an extremist that thinks there's no overdoing pure mental exploration of any topic. Right, NSA?

So, if you are down with the big brother scene then feel free to start taking notes.

I just want to explore a silly topic. Have a direction for all my heat and light.

Common, back on topic with me.

I have ideas sketched out but I'm always welcome to just talk shop with anyone who's interested. Ideas in and of themselves are harmless. Let's explore.

In practical terms, I imagine a system where some person with a computer of some sort can take some crypto currency, of any kind, that they actually own, send it to some address within the same blockchain, have it "laundered", and have more or less the same value of some other crypto fall into their wallet on another chain, reliably, without worrying about getting robbed.

I think such a system is just a few million lines of code away from being a reality. As for the practical implications of this, well, they just are. Why would you chose to just eschew any effort to make it a reality? On what grounds would you say, "shut er down, mayor!!"

Very, very, very broadly, I see it working in the following way:

  • A network of nodes, as always. These nodes serve "clients" (which are not just another node and are as simple as possible). When a client wishes to launder some value, they send it to "the network" and one or more nodes serve the request (but for simplicity, I will assume that only one node handles the request.)

The node at this point actually receive the crypto value being transferred. Without a far different scheme, that seems inevitable (but other schemes are out there!) The nodes all hold a balance and can send or receive value across multiple chains. Their only purpose is to spread things out as randomly as possible. Money goes in, money comes out. The balance stays "about here" for some optimal "here".

The nodes' job is to take money coming in, swish it about among some different chains, and send money out (thereby fulfilling client requests.)

The client just sends a certain amount of value and a tuple: (chain_id, dst_addr). The nodes' job is to make sure that the request gets fulfilled: all (value, dst_chian_id, dst_addr) tuples ultimately receive their funds. That three tuple ("come to think of it") is all the information required. It's just that the first parameter is associated with actual value being transferred from client to node. It's just a quantity denoting the value actually included in the request from the src_chain_id (which is implied because the network used to transfer the money was src_chain_id, and so is the src_addr.)

It's very important that the (dst_chain_id, dst_addr) tuple be handled for what it is: an illegal request to launder money! (* jurisdiction depending). The node should throw this information away. That's obviously a huge hitch: you are implicitly trusting any and all nodes to dutifully throw that away. Obviously a pickle.

The node could wait for some value to come in from the opposite direction.

Here's a para-digm: The clients do two things with the node, in order: first they send the above described request. Then, afterwards, they send what will be the "fee" from the (dst_chain_id, dst_addr). That way control of dst_addr is proven to the node, which hopefully prevents money from getting lost from time to time.

We could even say

Hi, I am client. Here is value from the src chain along with a code. You will receive this unique code from another chain. It will be "sent" to you, along with your fee for doing me this solid.

We've only moved the problem, however. The node can still know and record the (src_addr, dst_addr) tuple. It might be helpful to think of this tuple is the toxic waste that should be expunged and/or protected somehow. It's the fecal football.

Is there some crypto magic that can come to the rescue here?

BTW, I may have yeeted myself into thinking there needs to be some kind of cyberman "network" of these things. If done properly, what do we lose by having Just a Bunch Of Nodes and a public directory?

Help, CyberMan!


Update! Dumb Ideas!

Couldn't the Tor network scheme be applied to this? Instead of data, we have "value", which is fungible. Importantly.

We could decide that there is a "universal" currency that we use to keep track of balances and such. When a client adds value to the system (with a (dst_chain_id, dst_addr) tuple), a node will do a spot conversion of (src_chain_id, quantity) into our universal accounting system. The idea is, there will be slop, there will of course be fees paid, but the conversion will take place quickly enough so that fluctuations in value are negligible.

Our selected currency could have some nice "stability" features, so it itself doesn't fluctuate unpredictably. It's only fair then, when you put value into the system, you're temporarily giving up ownership of it, and the src_chain_id is rapidly changing in value with respect to everything else, the client should therefore only expect that the spot value, when they click the [Illegally Launder] button, is used to record what they put in.

All that aside, it will mean only one currency to keep up with, and therefore the system itself can have a ledger with balances, addresses and whatnot.

This probably means you should get back an address for where your money is sitting on this "working" token of value that the system uses.

Let's give it a name: Gyges, of course. "I have 7 Gyges", "what is Gyges' value today?"

You get an address and there it sits, you can see it on the block explorer, until it gets processed, at which point, that address's balance should go to zero and your dst_addr balance should go up, again, using a spot quote for dst_chain_id vs GYG (pronounced "guy-juh", like "garage" replacing the R with an "I" sound. Of course.)

Another weird thought I had. We have a "mempool" -- requests to launder money. Once we have assembled a "block" (that is, a load of laundry), nodes can take turns shuffling, adding, removing transactions so that the result of the transactions remains the same as the original, but layer upon layer of "mixing" is included. Could they be analogous to routing in Tor? There's encryption wrapping and re-wrapping each scrambling of the ledger (which always has the same results as the original ledger, but noise has been added.) :shrug: One of those, "I swear there is a there here", but ignorance keeps it just a hunch.

What would be a real nugget excavation would be if we could find a mathematically sound way for the client to "hide" the (dst_chain_id, dst_addr)! I feel that there is a "trick" a cleverer person could uncover.

- 1 toast