* [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
@ 2017-07-02 20:35 Rhavar
2017-07-02 20:56 ` Gregory Maxwell
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Rhavar @ 2017-07-02 20:35 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]
==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
[-- Attachment #2: Type: text/html, Size: 2348 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
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 16:25 ` Rhavar
2017-07-02 21:10 ` Luke Dashjr
2017-07-04 11:50 ` Andreas Schildbach
2 siblings, 2 replies; 10+ messages in thread
From: Gregory Maxwell @ 2017-07-02 20:56 UTC (permalink / raw)
To: Rhavar; +Cc: bitcoin-dev
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
2017-07-02 20:56 ` Gregory Maxwell
@ 2017-07-02 21:01 ` Rhavar
2017-07-03 2:28 ` Gregory Maxwell
2017-07-03 16:25 ` Rhavar
1 sibling, 1 reply; 10+ messages in thread
From: Rhavar @ 2017-07-02 21:01 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
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:10 ` Luke Dashjr
2017-07-04 11:50 ` Andreas Schildbach
2 siblings, 0 replies; 10+ messages in thread
From: Luke Dashjr @ 2017-07-02 21:10 UTC (permalink / raw)
To: bitcoin-dev, Rhavar
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
2017-07-02 21:01 ` Rhavar
@ 2017-07-03 2:28 ` Gregory Maxwell
2017-07-03 3:02 ` Rhavar
0 siblings, 1 reply; 10+ messages in thread
From: Gregory Maxwell @ 2017-07-03 2:28 UTC (permalink / raw)
To: Rhavar; +Cc: bitcoin-dev
On Sun, Jul 2, 2017 at 9:01 PM, Rhavar <rhavar@protonmail•com> wrote:
> 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).
Perhaps I am not following what you're saying here.
If the receiver is paying a higher feerate than your replacement,
he'll get it confirmed as fast or faster than your replacement in any
case.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
2017-07-03 2:28 ` Gregory Maxwell
@ 2017-07-03 3:02 ` Rhavar
2017-07-03 4:17 ` James Hilliard
0 siblings, 1 reply; 10+ messages in thread
From: Rhavar @ 2017-07-03 3:02 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3074 bytes --]
> Perhaps I am not following what you"re saying here.
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
It actually doesn't really matter much.
Let's say I want to pay Alice and Bob (unrelated entities), so I send it to them (together) with a low-fee transaction of paying 50 sat/byte. After an hour it's obvious that it's not confirmed (maybe there was a big backlog, or no blocks mined), so I want to replace my small transaction with one that pays 70 sat/byte.
But in the mean time, Alice has swept her wallet (or used a service that has done so) and generated 50KB of descendant transactions paying 40 sat/byte (i.e. total fees of 0.02 BTC or $50).
According to the BIP125 rules, I would need to pay for the cost of invalidating all the transactions (an absolute higher amount of fee) along with the replay cost of the descendant transactions.
So in this case, for me to fee bump the transaction I'm looking at throwing away $50 because of descendant transactions that were totally out of my control. If I don't fee bump, I violate my promise to Bob to pay in a timely manner (and also probably Alice, as it wasn't in her control she was using an exchange that did this).
If I guarantee to fee bump, the amount I risk is effectively unbounded. And even if the descendant transactions have a higher fee rate, and are assisting by CPFP boosting my transaction -- it very well might not be enough.
--
The idea of this proposal comes from the problems *in practice* of trying to low-ball fee estimation with scheduled continuous fee bumps until it confirms. At the moment it's not viable, but if this proposal was adopted then it would be.
Personally I think it's of critical piece of having a stable fee market. Fee estimation is a fools game, even the new and improved fee estimation in master today was suggesting x30 fees to what was required (and I successfully made transactions with). People (and especially services) being able to be able to dynamically increase their fees sanely when dealing with withdrawals (and especially batched ones) will go a long way to helping the overall ecosystem.
-Ryan
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
> Local Time: July 2, 2017 9:28 PM
> UTC Time: July 3, 2017 2:28 AM
> 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 9:01 PM, Rhavar <rhavar@protonmail•com> wrote:
>> 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).
> Perhaps I am not following what you"re saying here.
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
[-- Attachment #2: Type: text/html, Size: 4082 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
2017-07-03 3:02 ` Rhavar
@ 2017-07-03 4:17 ` James Hilliard
0 siblings, 0 replies; 10+ messages in thread
From: James Hilliard @ 2017-07-03 4:17 UTC (permalink / raw)
To: Rhavar; +Cc: bitcoin-dev
This seems like something that might be better dealt with by modifying
the RBF eviction policy to calculate feerate separation between the
transactions in the mempool and opportunistically evict the sweep
transaction+parent if it has a sufficiently different feerate from the
bumped fee replacement. Basically you allow the fee bumped replacement
to evict the sweep transaction+parent if there is more than 1MB of
transactions(or whatever the block size/weight limit is) of
transactions between the sweep transaction+parent feerate and bumped
fee replacement feerate. This way the sweep transaction parent only
gets replaced if it is unlikely that miners would ever produce a block
template with transactions at the sweep transaction+parent feerate at
the same time as the replacement transaction feerate. From the miners
point of view this give a higher fee block template overall since it
would be unlikely that one would see transactions with the feerate of
both the CPFP sweep and the replacement parent in the same block
template.
On Sun, Jul 2, 2017 at 10:02 PM, Rhavar via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
> It actually doesn't really matter much.
>
> Let's say I want to pay Alice and Bob (unrelated entities), so I send it to
> them (together) with a low-fee transaction of paying 50 sat/byte. After an
> hour it's obvious that it's not confirmed (maybe there was a big backlog, or
> no blocks mined), so I want to replace my small transaction with one that
> pays 70 sat/byte.
>
> But in the mean time, Alice has swept her wallet (or used a service that has
> done so) and generated 50KB of descendant transactions paying 40 sat/byte
> (i.e. total fees of 0.02 BTC or $50).
>
> According to the BIP125 rules, I would need to pay for the cost of
> invalidating all the transactions (an absolute higher amount of fee) along
> with the replay cost of the descendant transactions.
>
> So in this case, for me to fee bump the transaction I'm looking at throwing
> away $50 because of descendant transactions that were totally out of my
> control. If I don't fee bump, I violate my promise to Bob to pay in a
> timely manner (and also probably Alice, as it wasn't in her control she was
> using an exchange that did this).
>
> If I guarantee to fee bump, the amount I risk is effectively unbounded. And
> even if the descendant transactions have a higher fee rate, and are
> assisting by CPFP boosting my transaction -- it very well might not be
> enough.
>
> --
>
> The idea of this proposal comes from the problems *in practice* of trying to
> low-ball fee estimation with scheduled continuous fee bumps until it
> confirms. At the moment it's not viable, but if this proposal was adopted
> then it would be.
>
> Personally I think it's of critical piece of having a stable fee market. Fee
> estimation is a fools game, even the new and improved fee estimation in
> master today was suggesting x30 fees to what was required (and I
> successfully made transactions with). People (and especially services) being
> able to be able to dynamically increase their fees sanely when dealing with
> withdrawals (and especially batched ones) will go a long way to helping the
> overall ecosystem.
>
>
> -Ryan
>
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable
> transactions
> Local Time: July 2, 2017 9:28 PM
> UTC Time: July 3, 2017 2:28 AM
> 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 9:01 PM, Rhavar <rhavar@protonmail•com> wrote:
>> 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).
>
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
2017-07-02 20:56 ` Gregory Maxwell
2017-07-02 21:01 ` Rhavar
@ 2017-07-03 16:25 ` Rhavar
1 sibling, 0 replies; 10+ messages in thread
From: Rhavar @ 2017-07-03 16:25 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
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:10 ` Luke Dashjr
@ 2017-07-04 11:50 ` Andreas Schildbach
2017-07-05 13:52 ` Rhavar
2 siblings, 1 reply; 10+ messages in thread
From: Andreas Schildbach @ 2017-07-04 11:50 UTC (permalink / raw)
To: bitcoin-dev
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
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
2017-07-04 11:50 ` Andreas Schildbach
@ 2017-07-05 13:52 ` Rhavar
0 siblings, 0 replies; 10+ messages in thread
From: Rhavar @ 2017-07-05 13:52 UTC (permalink / raw)
To: Andreas Schildbach; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-07-05 13:53 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox