* [bitcoin-dev] BIP-21 amendment proposal: -no125 @ 2017-12-05 19:24 Sjors Provoost 2017-12-05 19:39 ` Luke Dashjr 2017-12-05 19:40 ` CryptAxe 0 siblings, 2 replies; 8+ messages in thread From: Sjors Provoost @ 2017-12-05 19:24 UTC (permalink / raw) To: Bitcoin Dev; +Cc: Matt Corallo [-- Attachment #1: Type: text/plain, Size: 1373 bytes --] 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 [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] BIP-21 amendment proposal: -no125 2017-12-05 19:24 [bitcoin-dev] BIP-21 amendment proposal: -no125 Sjors Provoost @ 2017-12-05 19:39 ` Luke Dashjr 2017-12-05 20:00 ` Sjors Provoost 2017-12-11 18:19 ` Peter Todd 2017-12-05 19:40 ` CryptAxe 1 sibling, 2 replies; 8+ messages in thread From: Luke Dashjr @ 2017-12-05 19:39 UTC (permalink / raw) To: Sjors Provoost; +Cc: Bitcoin Dev, Matt Corallo On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote: > 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. 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. > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] BIP-21 amendment proposal: -no125 2017-12-05 19:39 ` Luke Dashjr @ 2017-12-05 20:00 ` Sjors Provoost 2017-12-05 20:06 ` CryptAxe 2017-12-11 18:19 ` Peter Todd 1 sibling, 1 reply; 8+ messages in thread From: Sjors Provoost @ 2017-12-05 20:00 UTC (permalink / raw) To: Bitcoin Dev, CryptAxe, Luke Dashjr; +Cc: Matt Corallo [-- Attachment #1: Type: text/plain, Size: 1433 bytes --] CryptAxe wrote: > 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. Luke Dashjr wrote: >> 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 [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] BIP-21 amendment proposal: -no125 2017-12-05 20:00 ` Sjors Provoost @ 2017-12-05 20:06 ` CryptAxe 0 siblings, 0 replies; 8+ messages in thread From: CryptAxe @ 2017-12-05 20:06 UTC (permalink / raw) To: Sjors Provoost; +Cc: Bitcoin Protocol Discussion, Matt Corallo [-- Attachment #1: Type: text/plain, Size: 585 bytes --] On Dec 5, 2017 12:00 PM, "Sjors Provoost" <sjors@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) [-- Attachment #2: Type: text/html, Size: 1733 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] BIP-21 amendment proposal: -no125 2017-12-05 19:39 ` Luke Dashjr 2017-12-05 20:00 ` Sjors Provoost @ 2017-12-11 18:19 ` Peter Todd 2017-12-23 16:25 ` Matt Corallo 1 sibling, 1 reply; 8+ messages in thread From: Peter Todd @ 2017-12-11 18:19 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion; +Cc: Matt Corallo [-- Attachment #1: Type: text/plain, Size: 1097 bytes --] On Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashjr via bitcoin-dev wrote: > On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote: > > 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. > > 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] BIP-21 amendment proposal: -no125 2017-12-11 18:19 ` Peter Todd @ 2017-12-23 16:25 ` Matt Corallo 2017-12-23 18:33 ` Paul Iverson 0 siblings, 1 reply; 8+ messages in thread From: Matt Corallo @ 2017-12-23 16:25 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion, Peter Todd via bitcoin-dev, Luke Dashjr [-- Attachment #1: Type: text/plain, Size: 1999 bytes --] While the usability of non-RBF transactions tends to be quite poor, there are some legitimate risk-analysis-based reasons why people use them (eg to sell BTC based on a incoming transaction which you will need to convert to fiat, which has low cost if the transaction doesn't confirm), and if people want to overpay on fees to do so, no reason not to let them, including if the merchant is willing to CPFP to do so. Honestly, I anticipate very low usage of such a flag, which is appropriate, but also strongly support including it. If things turn out differently with merchants reducing the usability of BTC without taking over the CPFP responsibility we could make the option imply receiver-pays-fee, but no reason to overcomplicate it yet. On December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >On Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashjr via bitcoin-dev >wrote: >> On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote: >> > 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. >> >> 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 [-- Attachment #2: Type: text/html, Size: 2466 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] BIP-21 amendment proposal: -no125 2017-12-23 16:25 ` Matt Corallo @ 2017-12-23 18:33 ` Paul Iverson 0 siblings, 0 replies; 8+ messages in thread From: Paul Iverson @ 2017-12-23 18:33 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2964 bytes --] Allowing a "no-RBF" flag serves only to fool new users into believing that 0-conf is more secure than it is. There is already too much confusion about this point. In Bitcoin was assume that miners are profit-maximizing agents, and so we must assume that (flag or not) miners will replace transactions from mempool with conflicts paying a higher fee. From that viewpoint, full RBF is already "de facto" policy in Bitcoin. So I agree with Luke and Peter: remove the flag and make all transactions RBF as "de jure" policy too. At the same time, we need more outreach and education to clarify the risks of 0-conf, and we need to show miners how they can earn more profits by adopting full RBF. Paul. On Sat, Dec 23, 2017 at 8:25 AM, Matt Corallo via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > While the usability of non-RBF transactions tends to be quite poor, there > are some legitimate risk-analysis-based reasons why people use them (eg to > sell BTC based on a incoming transaction which you will need to convert to > fiat, which has low cost if the transaction doesn't confirm), and if people > want to overpay on fees to do so, no reason not to let them, including if > the merchant is willing to CPFP to do so. > > Honestly, I anticipate very low usage of such a flag, which is > appropriate, but also strongly support including it. If things turn out > differently with merchants reducing the usability of BTC without taking > over the CPFP responsibility we could make the option imply > receiver-pays-fee, but no reason to overcomplicate it yet. > > On December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> On Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashjr via bitcoin-dev wrote: >> >>> On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote: >>> >>>> 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. >>>> >>> >>> 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. >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 4172 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] BIP-21 amendment proposal: -no125 2017-12-05 19:24 [bitcoin-dev] BIP-21 amendment proposal: -no125 Sjors Provoost 2017-12-05 19:39 ` Luke Dashjr @ 2017-12-05 19:40 ` CryptAxe 1 sibling, 0 replies; 8+ messages in thread From: CryptAxe @ 2017-12-05 19:40 UTC (permalink / raw) To: Sjors Provoost, Bitcoin Protocol Discussion; +Cc: Matt Corallo [-- Attachment #1: Type: text/plain, Size: 1927 bytes --] 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" < bitcoin-dev@lists•linuxfoundation.org> wrote: > 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 > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 3013 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-12-23 18:33 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-05 19:24 [bitcoin-dev] BIP-21 amendment proposal: -no125 Sjors Provoost 2017-12-05 19:39 ` Luke Dashjr 2017-12-05 20:00 ` Sjors Provoost 2017-12-05 20:06 ` CryptAxe 2017-12-11 18:19 ` Peter Todd 2017-12-23 16:25 ` Matt Corallo 2017-12-23 18:33 ` Paul Iverson 2017-12-05 19:40 ` CryptAxe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox