public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Rhavar <rhavar@protonmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
Date: Wed, 05 Jul 2017 09:52:53 -0400	[thread overview]
Message-ID: <AIK82sl0aj6Nb9p42__7yPriddfF7G2iz-2m5wSTkNSwYmbmUMBUpNbWRdzMnsyc6KQXBo152-aL8cPnp3ymhMB8x9aZRjI_dOb_ehOvbnE=@protonmail.com> (raw)
In-Reply-To: <ojfve0$jq6$1@blaine.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 3254 bytes --]

Thanks Andreas, that's actually a pretty good use-case I didn't think of.
Perhaps you could make the rule: "To spend from an unconfirmed BIP125 output, the transaction feerate needs to be higher than its unconfirmed parent's effective feerate."
It doesn't totally solve the problem, but I think in practice would do a good job (most of the problematic descendants tends to be low feerate sweeps). It would also preserve the ability for receivers to use CPFP if they wish.

-Ryan

> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
> Local Time: July 4, 2017 6:50 AM
> UTC Time: July 4, 2017 11:50 AM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: bitcoin-dev@lists.linuxfoundation.org
> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 4883 bytes --]

      reply	other threads:[~2017-07-05 13:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-02 20:35 [bitcoin-dev] BIP proposal: No chaining off replaceable transactions 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
2017-07-05 13:52   ` Rhavar [this message]

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='AIK82sl0aj6Nb9p42__7yPriddfF7G2iz-2m5wSTkNSwYmbmUMBUpNbWRdzMnsyc6KQXBo152-aL8cPnp3ymhMB8x9aZRjI_dOb_ehOvbnE=@protonmail.com' \
    --to=rhavar@protonmail.com \
    --cc=andreas@schildbach.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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