Skip to content

Instantly share code, notes, and snippets.

@phyro
Last active February 11, 2022 09:17
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save phyro/8b40342c825edbf1ebdb2f198f1ed6f6 to your computer and use it in GitHub Desktop.
Save phyro/8b40342c825edbf1ebdb2f198f1ed6f6 to your computer and use it in GitHub Desktop.
N-sided txs

Transactions building

One-sided transactions

Most known and common way of transacting is through one-sided transactions. Here the sender constructs the transaction alone which then gets broadcasted to the network.

Pros:

  • The receiver does not need to be involved in transaction building
  • The only connection requirement is to broadcast the transaction to one of the nodes
  • People are used to it
  • Easier integration for services

Cons:

  • The receiver can't contribute to the transaction with their own inputs/outputs which leads to common-input-ownership problem
  • The receiver can't say "no" to the transaction
  • Limited to layer1
  • Coins can be sent accidentally to void (an address nobody owns)

Two-sided transactions

Both the sender and the receiver construct the transaction together.

Pros:

  • The receiver can add inputs/outputs which allows a payjoin
  • The possible transaction set is a superset of transactions that can be built as one-sided transactions
  • Impossible to send coins to void
  • Interactivity can allow the receiver to say "no" to a transaction
  • Enables full wallet control because a user can decide both what is sent AND what is received
  • Full interactivity is possible which gets rid of the dusting attack and limits the UTXO spoofing
  • Uniform experience across 1st and 2nd layer, since latter necessitates interaction
  • Payment can be tied to payment proof specifying what receiver considers payment to be for

Cons:

  • The sender and the receiver MUST have a way to communicate with each other (this isn't required in one-sided txs)
  • Transaction building requires a "ping-pong" between the sender and the receiver which adds a layer where additional issues can happen e.g. network issues
  • People are not used to that
  • Services need to do the integration correctly (this should be a one time thing hopefully)

My summary

Two-sided (interactive) transactions aren't that bad if the flow can be done in a simple/intuitive way. One-sided transactions are much simpler, but I think they have a very big issue which is that the receiver can't say "no" to the transactions. This is similar to walking through town and have tourists opening your wallet and throwing in pennies with chips to trace their spending. Two-sided transactions aren't without problems either, it's a tradeoff at the end of the day.

@johndavies24
Copy link

Nice summary! I would only suggest that a couple of the pros of 2 sided seem to revolve around controlling what your wallet receives, I see the distinction in some but not all. Also, layer 2 interactivity is much different than layer 1. Maybe the most basic layer 2 is different, but any layer 2 developed with today's tools only requires interaction at opening/closing (and maybe some disputes), but intervening state changes do not (at least not in a manner similar to grin layer 1).

But also, there are likely a large set of benefits from interactive transactions that we haven't even thought of yet. Grin might be too minimalistic to take advantage of some of them but maybe some might win out in the value added vs complexity added. I can't think of many right now, but it just seems having 2+ parties signing opens doors for things you couldn't do otherwise. Maybe it makes multisig easier or like layer 2 just simply more natural feeling. Maybe users could conduct an exchange of Grin for an exchange of data and have both payment and data delivery cryptographically secure/provable. Point is that there are likely a lot of cool things one could do with interactivity

@phyro
Copy link
Author

phyro commented Sep 5, 2020

Thanks. Yeah, some of the pros of two-sided transactions are definitely connected e.g. allow the receiver to say "no" to a transaction which Enables full wallet control which means we get rid of the dusting attack and limits the UTXO spoofing. I've listed them separately because they are different ideas, they do all get resolved just by making the receiver manually confirm stuff though.

I can't comment on layer2 much because I don't know how it works exactly, perhaps someone else can add to this.

I agree, interactive transactions are probably not yet fully explored - we'll likely be learning about more options over the years. I wouldn't be surprised if we found new interesting schemes that would only be possible in an interactive setting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment