From: Rhavar <rhavar@protonmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
Date: Sun, 02 Jul 2017 16:35:22 -0400 [thread overview]
Message-ID: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]
==Abstract==
BIP125 allows transactions to opt into replaceability with a primary use case
of allowing users to increase the fees of unconfirming transactions, helping create
a more efficient fee market place.
However this goal is hindered when the receiver of a transaction spends from the
unconfirmed output, which exposes the sender to the awkward position of needing
to pick between needing to pay an effectively unbounded amount of money as per the BIP125 rules, or not fee bump at all.
This is especially problematic in the case of batched sends in which there are
multiple independent receivers. In practice this means wallets and services can not effectively low ball the fee of transactions, with the intention of fee bumping due to the risk of the receiver spending or sweeping it before it confirms.
In order to support a healthy fee marketplace, this proposal aims to increase
the utility of bip125 by making transactions that spend an unconfirmed BIP125
output non-standard.
==Summary==
This policy specifies a max chain depth of 1 for any BIP125 transactions.
==Impact==
Receivers of BIP125 transactions will need to wait until the transaction
has confirmed before spending from it. This will not be significantly different
than it is currently as they receivers need to be monitoring for replacements.
If senders want to make further transactions before the BIP125 transaction confirms,
and need to utilize the change of the transaction: they will need to replace the
transaction with a one that makes the other send in "pass through" style or first
finalize the BIP125 transaction and then chain from the spend normally.
-Ryan
[-- Attachment #2: Type: text/html, Size: 2348 bytes --]
next reply other threads:[~2017-07-02 20:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-02 20:35 Rhavar [this message]
2017-07-02 20:56 ` Gregory Maxwell
2017-07-02 21:01 ` Rhavar
2017-07-03 2:28 ` Gregory Maxwell
2017-07-03 3:02 ` Rhavar
2017-07-03 4:17 ` James Hilliard
2017-07-03 16:25 ` Rhavar
2017-07-02 21:10 ` Luke Dashjr
2017-07-04 11:50 ` Andreas Schildbach
2017-07-05 13:52 ` Rhavar
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='uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com' \
--to=rhavar@protonmail$(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