I understand that payments can be sent to the owner of any data without exposing any data about the owner (such as that various files have the same owner).
I don’t understand how you can route the payment without the data being associated with an owner in a way that allows ownership of different files to be associated with the same owner.
Please can someone explain how this works.
There are plenty of cool options for this. One is (and cc @joshuef )
This stops data being groups into owners at all. It’s possible easily as we use BLS
It’s a scheme very much like the old SQRL for web sites and the likes. I think SAFE will use this everywhere. So even different sites you visit you will use a unique ID.
Thanks David. Can you explain how the reverse process works, getting payment to owner without anyone being able to follow a similar process to identify a recipient identifier (eg wallet address)?
Seems to have really useful properties.
I’ve been naively designing a key exchange protocol the last couple of days, to allow people to exchange a couple of pieces of text offline and use it to create a private, shared space online for communicating and sharing. But my knowledge is limited, so although I have a decent simple solution, there may be better ways.
What you describe sounds useful to understand in this context.
The “message” to the key owner will go to a network address. He will pick that up and locally decrypt it. So the network has no visibility of the wallet.
@joshuef @Anselme and @bochaco are more familiar with the message part.
However with SNT users should immediately spend back to themselves. This does two things
With SNT part of the speed comes from simple checks
If it is not unique it’s a doublespend attempt. All nodes keep both spend attempts and basically kill the key by returning the signed spend attempts to any requestor. This is very powerful, as a single honest node is all that is needed to stop a doublespend.
However a person can pay another person and all is well. Both are happy, but the seller can later on (after acceptance of transaction, sending goods etc.) try another spend attempt to a new output, intentionally. He does this to cause trouble. In any case the simple solution and default for SAFE clients is to always spend any income to themselves once more.
Neat, thanks David. Next question… 
Is this messaging purely internal or will there be a messaging API. If the latter I should probably pause my design work until that’s described.
“Soon” please 
Unfortunately, I am not up to speed on the SNT messaging part. I think it is only for spends, so yes internal for now.
Any designs there mucho mucho appreciated as POC
The thing that immediately comes to mind here is that users don’t live on the net and receivers of SNT from content tips/payments may not even see that for days/weeks.
So this may create problems if this is a problem of timing.
W/r/t messaging, something I’ve been imagining is that, through DAG nodes, we can readily pull out certain Spends with certain metadata. So perhaps you tag tag a Spend with a data address owned by myself. Well I could pull this up, and see the spend and associated metadata (perhaps a link to a NetworkAddress) which I could grab and see if it’s interesting…
The above would hinge on either client DAG nodes for surfacing this info, or pheraps micro-tx to DAG nodes to grab data for you. This is still being poked and prodded to determine viability, but could be one path forwards there.
That! 
As an aside, I wonder if the node manager when starting up could have the option to have one node as a DAG node. Maybe option defaults to yes if person is starting 20 or more nodes on the machine. They could deselect it. Maybe its a configuration option that the user sets the default and then chooses when spinning up nodes. This might encourage more DAG nodes to be spun up
This is thanks to bls key derivation which allows to create a new key from an existing key with a derivation index. As long as this derivation index is kept secret between the sender and the recipient, the derived key is unlinkable to the original one. The flow:
MainPubkey, it is generated from your MainSecretKey which is your biggest secret.MainPubkey.DerivationIndex (a big number) and derive a UniquePubkey by combining your MainPubkey and this DerivationIndex. That’s the one time key @dirvine is talking about.UniquePubkey that no one can link back to your MainPubkey without the DerivationIndexDerivationIndex is then encrypted to your MainPubkey and shared publicly safely or sent to you along with some reference to the Tx (this is the Transfer which you get when you use safe wallet transfer).MainSecretKey and spend that money with the DerivedSecretKey which you can create by deriving your MainSecretKey with that DerivationIndexNow if someone wants to track which UniquePubkeys belong to your MainPubkey they will need to brute force and try all DerivationIndexes and that’s a 256 bit long number. (That’s equivalent to trying to guess a Bitcoin private key). Good Luck.
In the getting payment to owner use case, such regular Transfers will be used. As those Transfers contain the encrypted DerivationIndex one would need to guess that big number to follow a similar process.
By the way, all the above applies to every transfer on the Safe Network. I hope that makes things a bit clearer?
They will when they make a payment or pre process an order, though. But for sure some folk will receive when offline, whether they get the cash or not i up to the sender, which is really still the same as today.
Does this solution also protect against a brute force attack using a quantum computer?
Lets just say a 256 bit number represents all the matter in the milky way galaxy and then a ton more. There isn’t enough spin states to cover that in anything called reasonable on an astronomical scale.
Our galaxy, the Milky Way, contains approximately 100 to 400 billion stars. If we take this as 200 billion or 2 × 10^11 stars and assume that our sun is a reasonable average size we can calculate that our galaxy contains about (1.2 × 10^56) × (2 × 10^11) = 2.4 × 10^67 atoms.
The Hubble space telescope tells us that there are about 100 billion or 10^11 galaxies in the whole universe. So again, if we assume that our galaxy is average, we get that the number of atoms in the universe is about 2.4 × 10^67 × 10^11 = 2.4 × 10^78. Internet research gives answers of around number of atoms image 3
Actually then, a 256 number (approx 10^77) is 10 times to 10,000 times smaller than number of atoms in the known universe. But with 100,000,000,000 galaxies its still close LOL.
Just wanted to take a moment to highlight this excellent post (the whole post)! It’s super informative and highlights a few really important things that differ from blockchain.
In SN, a wallet is a single address. The blockchain idea of address reuse for privacy is not relevant here.
The sender chooses the destination for payment. This is different from blockchain where typically the recipient will send a request for payment which includes a unique address generated by the recipient. Although it’s worth being aware, this is a client-side convention. Nodes don’t have any care about this detail. It would also be possible for the normal blockchain-style transfer to work too.
Bitcoin has a lot of similar ideas for a single payment address, see List of Bitcoin Privacy Proposals. It’s something people want and is good to see it being implemented as the default transaction mechanism for SN.
Great post @Anselme, and looking forward to seeing this explained in the primer