From: Rhavar <rhavar@protonmail•com>
To: Gregory Maxwell <greg@xiph•org>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
Date: Mon, 03 Jul 2017 12:25:33 -0400 [thread overview]
Message-ID: <iDdhZQY7PDg6PB_wvTYaeE9iovhulpKLTM8RQAUo1JD1lioXXIMA3pZud54PXMf9njV0leui0N7AeXjjD6ANTlnam7B26AsgSH7cBIxMfNo=@protonmail.com> (raw)
In-Reply-To: <CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3742 bytes --]
I was told my arguments are a bit incoherent, so I'll try again:
> Beyond being paternalistic the issue I see with your proposal is that
> its contrary to miner income-- you"re asking miners to ignore these
> spends that otherwise they could accept.
It is no more paternalistic than non BIP125 transactions. First of all, I'd like to emphasis we're talking about very small amounts of money, either way it's not going to matter too much as no one is going to care.
> This seems unstable-- some
> people would ignore your rule even if it were otherwise widely
> adopted, leading to the network behavior having higher volatility.
Actually, I believe the opposite. The problematic unconfirmed BIP125 descendants tend to be low fee rate sweeps, that won't be mined any time soon anyway. Miners who ignored that, but instead took the replacement transaction would be able to put it in a block and make more money. The low fee rate sweep will eventually be recreated anyway, with a slightly different set of inputs.
Thus I believe miners who used my policy would make more than miners who didn't.
But the reality is that if my proposal was deployed, people would stop spending from bip125 outputs until they confirm, in the first place. There's no good reason to do so, so no incentive to try route around the network. The only reason people do so now is because they can, and there's no harm in doing so (for things like sweep transactions, where you don't care if you need to keep redoing it). My proposal would drastically simplify feebump logic, and make fee bumps actually predictable.
As a concrete example: bitcoin core's feebump command completely breaks when there exists descendant transactions, and for it it would would not only require a fair bit of logic but a change in interface (so the user can control how much they're willing to lose)
I believe this proposal offers a huge amount of benefits for users/services wanting to make use of bip125 for feebumping, which will result in a more stable fee market. While creating extremely little to no disadvantages.
Unless someone can think of a legitimate use case that spending unconfirmed bip125 transactions is useful?
-Ryan
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
> Local Time: July 2, 2017 3:56 PM
> UTC Time: July 2, 2017 8:56 PM
> From: greg@xiph•org
> To: Rhavar <rhavar@protonmail•com>
> bitcoin-dev@lists•linuxfoundation.org <bitcoin-dev@lists•linuxfoundation.org>
> On Sun, Jul 2, 2017 at 8:35 PM, Rhavar via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> 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.
> I don"t really see how this is desirable: Just replace it-- the
> receiver foolishly spent it at its own peril, spending a unconfirmed
> payment from a third party is something that Core never does, it"s
> reckless unless you"re doing something like CPFPing it to yourself,
> which is harmless (either it"ll work, or it"ll fail and you"ll be fine
> with that).
> Beyond being paternalistic the issue I see with your proposal is that
> its contrary to miner income-- you"re asking miners to ignore these
> spends that otherwise they could accept. This seems unstable-- some
> people would ignore your rule even if it were otherwise widely
> adopted, leading to the network behavior having higher volatility.
> Instead, perhaps a BIP that very strongly advises parties to not spend
> unconfirmed outputs from third parties while making a payment to third
> parties would achieve your end?
[-- Attachment #2: Type: text/html, Size: 4966 bytes --]
next prev parent reply other threads:[~2017-07-03 16:25 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 [this message]
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='iDdhZQY7PDg6PB_wvTYaeE9iovhulpKLTM8RQAUo1JD1lioXXIMA3pZud54PXMf9njV0leui0N7AeXjjD6ANTlnam7B26AsgSH7cBIxMfNo=@protonmail.com' \
--to=rhavar@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)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