From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org, Rhavar <rhavar@protonmail•com>
Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
Date: Sun, 2 Jul 2017 21:10:19 +0000 [thread overview]
Message-ID: <201707022110.21325.luke@dashjr.org> (raw)
In-Reply-To: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
This isn't BIP material, as it merely describes a local policy.
(BIP125 itself is also local policy, but one that involves standardisation
since it expresses how wallets interoperate with nodes with that policy.)
If you wish to suggest this policy change, you should just implement it and
open a merge/pull request on the applicable project.
Luke
On Sunday 02 July 2017 8:35:22 PM Rhavar via bitcoin-dev wrote:
> ==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
next prev parent reply other threads:[~2017-07-02 21:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-02 20:35 Rhavar
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 [this message]
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=201707022110.21325.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rhavar@protonmail$(echo .)com \
/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