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: Sun, 02 Jul 2017 17:01:19 -0400 [thread overview]
Message-ID: <i0RP2rjFVA8h3PMYT7lbELniTxCKKpcjayO9cRygp2qVyURqIbGPMXvJ1RVjgsJIRU9HcE4-ud2Vt5d8qYWGKfDxE1jeFtbRMSim5Mis-6c=@protonmail.com> (raw)
In-Reply-To: <CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]
> I don"t really see how this is desirable: Just replace it-
That's not really realistic. In practice some receivers do big sweeps and include unconfirmed inputs. Replacing the transaction means you need to pay the cost of the sweep, which you probably don't want to do (can be in the order of $100s of dollars).
> Beyond being paternalistic the issue I see with your proposal is thatits contrary to miner income
This applies to pretty much all non-standard transactions.
-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: 2928 bytes --]
next prev parent reply other threads:[~2017-07-02 21:01 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 [this message]
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='i0RP2rjFVA8h3PMYT7lbELniTxCKKpcjayO9cRygp2qVyURqIbGPMXvJ1RVjgsJIRU9HcE4-ud2Vt5d8qYWGKfDxE1jeFtbRMSim5Mis-6c=@protonmail.com' \
--to=rhavar@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=greg@xiph.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