Discussion:
BIP-21 amendment proposal: -no125
Add Reply
Sjors Provoost via bitcoin-dev
2017-12-05 19:24:04 UTC
Reply
Permalink
Raw Message
One way to reduce fees is to encourage usage of Replace-By-Fee, BIP 125 [0]. It allows wallets to recommend lower fees, because if a transaction gets stuck due to underestimation, the fee can easily be bumped.

Bitcoin Core has had support for RBF for a while, and as of v0.15.0 recommends lower fees [1] when the user chooses to use RBF.

I recently submitted a pull request that would turn on RBF by default, which triggered some discussion [2]. To ease the transition for merchants who are reluctant to see their customers use RBF, Matt Corallo suggested that wallets honor a no125=1 flag.

So a BIP-21 URI would look like this: bitcoin:175t...45W?amount=20.3&no125=1

When this flag is set, wallets should not use RBF, regardless of their default, unless the user explicitly overrides the merchant's preference.

Afaik adding this flag won't break existing BIP-21 support. It doesn't use the req- prefix, because it's optional. I'm also not aware of any ad hoc standards that use no125 in BIP-21-ish URIs.

- Sjors

P.S. I'd similarly suggest adding a bech32 param, but that's for another discussion

[0] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
[1] https://bitcoincore.org/en/2017/09/01/release-0.15.0/#better-fee-estimates
[2] https://github.com/bitcoin/bitcoin/pull/11605
[3] https://github.com/bitcoin/bitcoin/issues/11828
Luke Dashjr via bitcoin-dev
2017-12-05 19:39:32 UTC
Reply
Permalink
Raw Message
Post by Sjors Provoost via bitcoin-dev
I recently submitted a pull request that would turn on RBF by default,
which triggered some discussion [2]. To ease the transition for merchants
who are reluctant to see their customers use RBF, Matt Corallo suggested
that wallets honor a no125=1 flag.
bitcoin:175t...45W?amount=20.3&no125=1
When this flag is set, wallets should not use RBF, regardless of their
default, unless the user explicitly overrides the merchant's preference.
This seems counterproductive. There is no reason to ever avoid the RBF flag.
I'm not aware of any evidence it even reduces risk of, and it certainly
doesn't prevent double spending. Plenty of miners allow RBF regardless of the
flag, and malicious double spending doesn't benefit much from RBF in any case.
Post by Sjors Provoost via bitcoin-dev
P.S. I'd similarly suggest adding a bech32 param, but that's for another discussion
Bech32 addresses are just normal addresses. What need is there for a param?

Luke
Sjors Provoost via bitcoin-dev
2017-12-05 20:00:01 UTC
Reply
Permalink
Raw Message
Perhaps instead of a flag that can be used to disable a specific operation, there should be a "-ignoredflags=x,y,z" section of the URI that can be used to ignore whatever BIP this might also be useful for in the future?
I don't think all BIPs lend themselves to this pattern. Can you think of another example? I also suspect each ignored flag requires carefully defined behavior, so it's probably better to spell that out in the BIP.

I also wouldn't be surprised if this BIP will get superseded in its entirety in the not too distant future; I believe there's some earlier discussion on this list about variations on BIP-71. So I don't think there will be many additional params in the future that warrant abstraction.
Post by Sjors Provoost via bitcoin-dev
P.S. I'd similarly suggest adding a bech32 param, but that's for another discussion
Bech32 addresses are just normal addresses. What need is there for a param?
Luke
Most wallets consider bech32 addresses to be invalid. This would allow merchants to display a backwards compatible P2SH address and allow modern wallets to use bech32. In fact, this should be encouraged because it's slightly cheaper for the recipient to spend these funds (but not worth even a tiny increase in shopping cart abandonment).

Once the new format has sufficient adoption, merchants can simply drop support for old wallets and not use this parameter.

Sjors
CryptAxe via bitcoin-dev
2017-12-05 20:06:31 UTC
Reply
Permalink
Raw Message
On Dec 5, 2017 12:00 PM, "Sjors Provoost" <***@sprovoost.nl> wrote:

...

I don't think all BIPs lend themselves to this pattern. Can you think of
another example?


Not right now, just seemed like a good idea to consider making it useful
for more than one thing (maybe CT or something else could use it in the
future?).

I also suspect each ignored flag requires carefully defined behavior, so
it's probably better to spell that out in the BIP.

Sjors


Agreed, no reason they couldn't reuse the same section of the payment
request URI though. (And define that behavior in the BIP)
Peter Todd via bitcoin-dev
2017-12-11 18:19:43 UTC
Reply
Permalink
Raw Message
Post by Luke Dashjr via bitcoin-dev
Post by Sjors Provoost via bitcoin-dev
I recently submitted a pull request that would turn on RBF by default,
which triggered some discussion [2]. To ease the transition for merchants
who are reluctant to see their customers use RBF, Matt Corallo suggested
that wallets honor a no125=1 flag.
bitcoin:175t...45W?amount=20.3&no125=1
When this flag is set, wallets should not use RBF, regardless of their
default, unless the user explicitly overrides the merchant's preference.
This seems counterproductive. There is no reason to ever avoid the RBF flag.
I'm not aware of any evidence it even reduces risk of, and it certainly
doesn't prevent double spending. Plenty of miners allow RBF regardless of the
flag, and malicious double spending doesn't benefit much from RBF in any case.
I'll second the objection to a no-RBF flag.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
CryptAxe via bitcoin-dev
2017-12-05 19:40:42 UTC
Reply
Permalink
Raw Message
Perhaps instead of a flag that can be used to disable a specific operation,
there should be a "-ignoredflags=x,y,z" section of the URI that can be used
to ignore whatever BIP this might also be useful for in the future?

On Dec 5, 2017 11:34 AM, "Sjors Provoost via bitcoin-dev" <
Post by Sjors Provoost via bitcoin-dev
One way to reduce fees is to encourage usage of Replace-By-Fee, BIP 125
[0]. It allows wallets to recommend lower fees, because if a transaction
gets stuck due to underestimation, the fee can easily be bumped.
Bitcoin Core has had support for RBF for a while, and as of v0.15.0
recommends lower fees [1] when the user chooses to use RBF.
I recently submitted a pull request that would turn on RBF by default,
which triggered some discussion [2]. To ease the transition for merchants
who are reluctant to see their customers use RBF, Matt Corallo suggested
that wallets honor a no125=1 flag.
So a BIP-21 URI would look like this: bitcoin:175t...45W?amount=20.
3&no125=1
When this flag is set, wallets should not use RBF, regardless of their
default, unless the user explicitly overrides the merchant's preference.
Afaik adding this flag won't break existing BIP-21 support. It doesn't use
the req- prefix, because it's optional. I'm also not aware of any ad hoc
standards that use no125 in BIP-21-ish URIs.
- Sjors
P.S. I'd similarly suggest adding a bech32 param, but that's for another discussion
[0] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
[1] https://bitcoincore.org/en/2017/09/01/release-0.15.0/#
better-fee-estimates
[2] https://github.com/bitcoin/bitcoin/pull/11605
[3] https://github.com/bitcoin/bitcoin/issues/11828
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...