From: Andreas Schildbach <andreas@schildbach•de>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
Date: Tue, 4 Jul 2017 13:50:30 +0200 [thread overview]
Message-ID: <ojfve0$jq6$1@blaine.gmane.org> (raw)
In-Reply-To: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
Your BIP would take away the only way the *receiver* has to raise the
fee: CPFP. And the receiver is arguably the more important party in this
question. After all the sender has no real incentive for his payment to
be confirmed; it's receiver who has.
On 07/02/2017 10:35 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
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
next prev parent reply other threads:[~2017-07-04 11:50 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
2017-07-04 11:50 ` Andreas Schildbach [this message]
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='ojfve0$jq6$1@blaine.gmane.org' \
--to=andreas@schildbach$(echo .)de \
--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