Identifying and Resolving the Conflict Between 0-conf and Permissionless Innovation

  1. Any change to the minimum fee, or even variations in the fee structure
  2. Changes to OP_RETURN limits
  3. Multiple OP_RETURN outputs
  4. Any addition to the set of “standard” transaction templates
  5. Any changes to the allowed number of unconfirmed child or ancestor transactions

Solutions

Super-Standard Transactions

Tom Harding’s “super-standard” transaction proposal partly addresses this problem. With it, new features that create new types of transactions would not be considered 0-conf acceptable. But the subset of normal, everyday transactions would be 0-conf. The problem with this is that new features are never allowed to be 0-conf, at least not until every client agrees to implement them. And transitioning a new feature into the “super-standard” set (really, ANY changes to the definition of a super-standard transaction) needs to be coordinated to happen simultaneously across all clients, like a hard fork but with the added difficulty that old versions of client software do not fall away from the main chain.

Double-spend Proofs

What we really need is a way to flag a transaction to be relayed despite “is-standard” rules so that double-spends can be relayed to all nodes no matter their rules. However, a simple flag cannot work because anyone could set the flag, overriding a node’s relay policy and spamming the network. This is where the concept of a double spend proof finds real justification. It can be used to prove the existence of a double spend and be relayed network-wide relatively efficiently (as compared to the possible spam transaction it replaces).

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store