From: Daniel Lipshitz <daniel@gap600•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case
Date: Sun, 11 Dec 2022 22:24:00 +0200 [thread overview]
Message-ID: <CACkWPs_F94t9Q8TfyYYGxQANUT78SWFGkTOh6qRwnt=6ct7aig@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3511 bytes --]
next reply other threads:[~2022-12-11 20:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 20:24 Daniel Lipshitz [this message]
2022-12-13 4:20 ` Yuval Kogman
2022-12-13 8:08 ` Daniel Lipshitz
2022-12-13 9:59 ` John Carvalho
2022-12-13 11:33 ` Daniel Lipshitz
2022-12-13 14:00 ` Lucas Ontivero
2022-12-13 14:08 ` Daniel Lipshitz
2022-12-13 21:41 ` Peter Todd
2022-12-13 21:58 ` Daniel Lipshitz
2022-12-16 21:14 ` Peter Todd
2022-12-18 8:06 ` Daniel Lipshitz
2023-01-13 23:53 ` Peter Todd
2023-01-14 20:15 ` Daniel Lipshitz
2023-01-16 10:19 ` Daniel Lipshitz
2023-01-17 17:07 ` Erik Aronesty
2023-01-17 17:27 ` Daniel Lipshitz
2023-02-04 16:27 ` Peter Todd
2023-02-06 12:08 ` Daniel Lipshitz
2022-12-14 8:12 ` Daniel Lipshitz
2022-12-14 17:41 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACkWPs_F94t9Q8TfyYYGxQANUT78SWFGkTOh6qRwnt=6ct7aig@mail.gmail.com' \
--to=daniel@gap600$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox