Radical idea for forward secrecy and instant wallet sync about research-lab HOT 13 OPEN

For a more practical commentary going over the actual issues in depth:

1. This is horrible for multisig. It makes every recipience a signature which greatly increases load.
2. It removes the ability to be offline and receive funds. The sender can clawback funds until they're received. This means even if someone shows you they sent you funds, that's not guaranteed unless you accept them with your private key.
3. It dramatically reduces performance thanks to the multiple Bulletproofs. While there a multi-round MPC Bulletproofs protocol exists, sarang has commented they don't believe Bulletproofs+ could have MPC.
4. Adoption of this must remain indistinguishable. Even if its solely an alternative, we lose out on performance per the previous point.

And then as a side note, I don't see how sending an incomplete transaction is better than an out proof to prove sending. They should be equivalent for that immediate goal. Incomplete transactions have a load of other complications however. For the only example I know of, as out proofs are already rarely used, the proposal is for a shop frontend to process a payment without the wallet's view key (which covers all addresses, not just the relevant ones, though there's of course commentary on derived view keys...). If you're in this niche use case, this proposal doesn't work for you. One of three cases occurs.

1. The store would now have to be trusted to receive funds, as in, it could steal XMR from you.
2. You're trusting the sender not to double spend.
3. You're forced to run a server with 24/7 uptime to receive funds.

All of these options are major decreases in UX.

The benefit in this is the privacy benefit which is immense. It could arguably be worth using distinct output range proofs. The detriments are as I stated, which may mean almost no adoptance. Accordingly, local wallet churning (which won't publish an address which could be broken under the DLP) may be the simplest solution to accomplish very similar results.

from research-lab.

Would this work for transactions with multiple recipients?

from research-lab.

Sending to N recipients requires N+1 transactions with this system.

First you create N outputs with the correct amounts for each recipient and a change output. Then you send one half-transaction to each recipient.

While this would increase the network load with additional tranactions, it mitigates the first two disadvantages (source of funds is hidden from the recipients and the recipients can make just 1 range proof because there is no change output from the sender).

from research-lab.

While I never want to suggest research shouldn't be accumulated, I don't think this has a path forward. Beyond the privacy implications on requiring buffer transactions, this is immediately comparable to Grin which failed horribly due to requiring IP-based addresses. Any attempt at this proposal would have to be as a non-distinguishable alternative to the current scheme, and it doesn't sound like this is (due to needing multiple range proofs). I do love the work against preventing DL-knowledgable parties from breaking privacy, which I see as the second biggest issue with privacy right now.

from research-lab.

this is immediately comparable to Grin which failed horribly due to requiring IP-based addresses

Grin/Mimblewimble requires a roundtrip to complete a transaction, i.e. sender -> recipient -> sender. This scheme only needs the sender -> recipient part, which makes it "fire and forget". You can use any asynchronous channel to pass the transaction to the recipient, e.g. e-mail.

non-distinguishable alternative to the current scheme, and it doesn't sound like this is (due to needing multiple range proofs)

Of course, if this was ever implemented, all transactions would need to look the same (2x range proofs or requiring the intermediate transaction).

from research-lab.

While there is a distinction regarding it not being round trip, I still don't believe that requirement can be successfully added to every transaction. When it comes to making every transaction having more range proofs... it's a massive slow down to support an alternate mode which has its own trade offs regarding privacy (while accomplishing privacy greatly desired and not currently offered...).

from research-lab.

Other than anonymous donations, what scenarios are there such that the sender doesn't notify the recipient via a communication side channel when they want to send Monero?

This honestly sounds like a great idea to me, and it solves the ux problem of proving you paid for something. Right now, you have to send an outproof, but if the recipient simply received a message from you via a verified communication channel that you use often, they automatically know it's you.

from research-lab.

This is horrible for multisig. It makes every recipience a signature which greatly increases load.

Fair point. This scheme shifts the trust requirement from address generation to payment acceptance, which may have security implications.

It removes the ability to be offline and receive funds.

No, it doesn't. You can receive offline, but you will only find out about the payment when you come online (and read your mailbox). I don't think there is any practical difference from the current situation. Do you consider a payment "received" if you don't know about it? Schrödinger would say no.

The sender can clawback funds until they're received.

Irrelevant. The recipient will consider the payment to be complete when the receiving transaction has enough confirmations.

It dramatically reduces performance thanks to the multiple Bulletproofs.

I would not be so confident to use the word "dramatically" without seeing some benchmarks.

The store would now have to be trusted to receive funds, as in, it could steal XMR from you.

I don't think this is much different from a store that generates subaddresses. It also has to be trusted to use the correct public spend key when generating addresses.

You're trusting the sender not to double spend.

No, as explained above. Double-spends are not considered valid payments and the recipient can easily verify if a payment has been double-spent or not. The only disadvantage is that you cannot accept zero-confirmation payments, but those already involve some level of trust with the current setup.

You're forced to run a server with 24/7 uptime to receive funds.

Not a practical disadvantage for any online commerce application. Doesn't matter for donations, which can be easily received by e-mail. E.g. my donation address would be

tevador+xmr1qkv5dy8fz2sh9g99knxyrfra98ph5ep8dlxtlaf7l6gxhcldmvmv@example.com

The sender can decode my public key by parsing the characters between + and @ and then send the payment to this e-mail address (encrypted with the public key), using a disposable mailbox.

local wallet churning (which won't publish an address which could be broken under the DLP) may be the simplest solution to accomplish very similar results

This will accomplish nothing. A future DLP-breaking adversary will still learn all payments (including amounts) recieved to any public address regardless of any subsequent churning.

from research-lab.

No, it doesn't. You can receive offline, but you will only find out about the payment when you come online (and read your mailbox). I don't think there is any practical difference from the current situation. Do you consider a payment "received" if you don't know about it? Schrödinger would say no.

There's a difference between being online with your key, able to complete the transaction, and able to verify a payment happened.

I don't think this is much different from a store that generates subaddresses. It also has to be trusted to use the correct public spend key when generating addresses.

Fair. I'll retract this and apologize for not thinking it through.

I don't think this is much different from a store that generates subaddresses. It also has to be trusted to use the correct public spend key when generating addresses.

There are models where payments are processed before the wallet key, or some middleware with some wallet key, comes online. Forcing them to be online makes this a synchronous protocol, and while not round trip as there's no response, may dramatically effect the UX. When you define it as synchronous, you're correct there's no double spends. I'm not advocating for a shift to a synchronous model however.

This will accomplish nothing. A future DLP-breaking adversary will still learn all payments (including amounts) recieved to any public address regardless of any subsequent churning.

The address churned to wouldn't be public as it'd be local. Privacy conscious users, adding an extra step locally without affecting the protocol, would achieve full plausible deniability. While it is a manual buffer TX, your own proposed scheme requires a buffer TX for privacy. Accordingly, while I think your proposal has merits in a variety of ways, I do think the simpler approach is a much more well-rounded suggestion.

And re: performance, while I have yet to run benchmarks, the multiexp should help dramatically here. The biggest issue would likely be the size, though the performance decrease wouldn't be ignorable. We can always say it's sufficiently low to be acceptable for sufficient gain however.

from research-lab.

There's a difference between being online with your key, able to complete the transaction, and able to verify a payment happened.

That difference is meaningless in practice. People use their view keys to detect incoming payments. The "receiving key" in this proposal is like a view key.

The address churned to wouldn't be public as it'd be local. Privacy conscious users, adding an extra step locally without affecting the protocol, would achieve full plausible deniability.

I fail to see how the churn protects you. It doesn't remove the original receiving transaction from the blockchain.

For example, if it's a donation address, the money flow would be donors -> donation address -> churn addresses. A DLP-breaking adversary can still locate and decrypt all of the donor -> donation address transactions including the amount that was received. There is no plausible deniability.

from research-lab.

It doesn't remove the original receiving transaction, but it puts up distance and severs the link. While you're right, for posted public addresses, it can be linked without issue, it prevents a person with 3 stores from having those 3 stores linked to them. But yes, this idea is much more comprehensive at privacy.

Also, there is a slight distinction with receiving keys and addresses. If you're a repeat user who reuses an address, the server can't alter an already sent address to hijack future payments.With a receiving key, the server can decide to take the incoming stream whenever. A lot of these distinctions become frivolous edge cases though (such as mine, as your privacy commentary is correct and important).

from research-lab.

Each output needs a separate range proof, which is less efficient

Wouldn't the sender be able to construct one range proof for all outputs at the time of sending assuming that the receiver agrees to the amount commitments that the sender provides (ostensibly alongside or inside the partial tx)? This would reduce flexibility for the receiver if they wanted to say, split their output into 5, but we wouldn't have to require separate range proofs.

from research-lab.

If we assume a two-way channel (e.g. most online merchants and physical PoS machines), we can make a F-S instant sync payment protocol that A) doesn't tell the receiver which enotes are spent, B) has bulletproofs aggregated like normal, C) can have multiple recipients in the same transaction, and C) allows recipients to perform regular Jamtis balance recovery in the case of lost channel info and/or wallet caches. Here's how it would work:

1. Receiver sends amount
2. Sender does input selection for given amount and sends input_context (this is a hash of the key image set for non-coinbase txs)
3. Receiver generates De, constructs a self-send enote for given input_context, and then sends all enote information and blinding factor (Ko, C, aenc, addr_tagenc, view_tag, De, ka)
4. Sender checks that C ?= amount H + ka G and includes all that enote information in transaction. They then complete and braodcast the transaction as normal by adding a change enote, signing, and generating proofs (notice that bulletproofs can be aggregated like normal w/ no privacy loss since the sender is constructing the proofs and already knows the send amount)
5. Receiver can either A) do normal Jamtis balance recovery or B) do instant sync using cached enote information from earlier to process the incoming transaction

One thing that is a bit tricky about this scheme is that the receiver can't do a normal payment proof since the receiver constructs a self-send enote. However, since we are doing a two-way channel, we can have the receiver actively sign the message (amount, input_context, Ko, C, aenc, addr_tagenc, view_tag, De, ka) and then that can be used as the payment proof later (assuming that that information matches what is on-chain).

This doesn't work well for payment to miners since input_context depends on the block height, so the back-and-forth would have to be redone every time the chain state changes.

This exposes the view-balance secret to the service running the recipient's invoice service. This might not be ideal, so a small tweak to Jamtis's internal send protocol can be used where the "generate-image" scalar private key is not derived from (and otherwise independent from) the symmetric secrets (X1, X2, X3) used to derive the incoming enote information, instead of them both being svb.

from research-lab.