Intro
Currently there is a significant use case of 0-Conf acceptance of
transactions. Merchants and service providers are fully aware of the risks
related to 0-conf. Full RBF if it would be significantly enabled would most
likely make 0-conf not possible and significantly limit this current use
case. A primary motivation for full RBF is to enable an increase of fee of
trxs and enable faster acceptance in Block should it be required.

Motivation
To enable full RBF adoption without this impeding the 0-conf use case. This
can be done by enabling the primary use of case full RBF i.e increase the
fee, while keeping the outputs of TRX1 to be included within TRX2.

Method
TRX1 is the trx first published and held in Mempool, TRX2 is the trx which
comes to replace TRX1.

In order for a TRX2 to  replace TRX1 in the Mempool it will require the
following

   - 1. Outputs (addresses and amounts) are the same TRX1 and TRX2

Or


   - 2. TRX2 Outputs include Outputs of TRX1 i.e TRX2 has additional
   Outputs to TRX1

Both cases would require the addition of at least one Input in order to
increase the fee.

In such a case 0-conf acceptance of TRX1 will result in a harmless double
spend since TRX1 will not be included in the valid UTXO set; however
the address beneficiaries of TRX1 will still be credited by TRX2.

This rule would enable the increasing of network fees post publication of
trx without the loss of 0-conf use case.

Drawbacks
Does require access to another Input inorder to take advantage of Full RBF.


Summary
Access to OptinRBF and FullRBF(with above limitation) would give actors
full access to increasing fees as an option. The 0-conf whose risks are
very much understood in the market can continue to exist as is, with the
0-conf ongoing choices being continuing to be available to actors.
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz