Skip to content

Latest commit

 

History

History
82 lines (55 loc) · 3.21 KB

0000-onesided.md

File metadata and controls

82 lines (55 loc) · 3.21 KB
Raw
  • Title: onesided
  • Authors: John Tromp
  • Start date: September 7, 2020
  • RFC PR: Edit if merged: mimblewimble/grin-rfcs#0000
  • Tracking issue: [Edit if merged with link to tracking github issue]

Summary

Allow for non-interactive transactions in cases where payment proofs are not needed.

Motivation

The current 2 round interaction required for building a transaction is somewhat cumbersome when requiring manual intervention. In particular, the initiator has to wait an arbitrary time between sending their first and receiving the second message.

Community-level explanation

Interaction can be minimized by splitting a transaction into two parts: a sending transaction and a receiving transaction, similar to transactions in nano currency [1]. The sending transaction produces a 1-of-2 output whose blinding factor is a secret shared between sender and receiver. The shared secret is constructed in a Diffie-Hellman key exchange, using known secp256k1 public keys. The receiving transaction spends the 1-of-2 output into a 1-of-1 output under the sole control of the receiver. The payment is not considered complete until the receiving transaction confirms.

Reference-level explanation

[TODO]

Drawbacks

Transactions require double the fees and kernels. Doesn't allow for payjoins. The major drawback though is that payment proofs are not possible, as a 3rd party could never distinguish between the sender spending the 1-of-2 and the receiver spending the 1-of-2. Therefore, these one sided payments are only useful where payment proofs are redundant. This includes tipping, donations, and any case where a recveiver fully trusts the sender, like children receiving pocket money from their parents.

Rationale and alternatives

Alternative proposals [2] [3] [4] avoid the transaction splitting, but require a departure from pure Mimblewimble while complicating the consensus model and possibly weakening the security model.

[6] argues for maintaining the simplicity and elegance of pure MW.

By using malleable signatures that don't commit to the public key (the public excess in kernels), a 1 round interaction protocol may be possible within the pure MW consensus model [5].

Prior art

[TODO]

Unresolved questions

Future possibilities

[TODO]

References

[1] Nano docs

[2] DavidBurkett gist

[3] eprint

[4] Grin forum

[5] Grin forum

[6] Grin forum