public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

• * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
         [not found] <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
  @ 2022-10-19 14:29 ` Sergej Kotliar
    2022-10-19 14:45   ` Erik Aronesty
                       ` (5 more replies)
    0 siblings, 6 replies; 33+ messages in thread
  From: Sergej Kotliar @ 2022-10-19 14:29 UTC (permalink / raw)
    To: bitcoin-dev
  
  [-- Attachment #1: Type: text/plain, Size: 7152 bytes --]
  
  Hi all,
  
  Chiming in on this thread as I feel like the real dangers of RBF as default
  policy aren't sufficiently elaborated here. It's not only about the
  zero-conf (I'll get to that) but there is an even bigger danger called the
  american call option, which risks endangering the entirety of BIP21 "Scan
  this QR code with your wallet to buy this product" model that I believe
  we've all come to appreciate. Specifically, in a scenario with high
  volatility and many transactions in the mempools (which is where RBF would
  come in handy), a user can make a low-fee transaction and then wait for
  hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
  up, user can cancel his transaction and make a new - cheaper one. The
  biggest risk in accepting bitcoin payments is in fact not zeroconf risk
  (it's actually quite easily managed), it's FX risk as the merchant must
  commit to a certain BTCUSD rate ahead of time for a purchase. Over time
  some transactions lose money to FX and others earn money - that evens out
  in the end. But if there is an _easily accessible in the wallet_ feature to
  "cancel transaction" that means it will eventually get systematically
  abused. A risk of X% loss on many payments that's easy to systematically
  abuse is more scary than a rare risk of losing 100% of one occasional
  payment. It's already possible to execute this form of abuse with opt-in
  RBF, which may lead to us at some point refusing those payments (even with
  confirmation) or cumbersome UX to work around it, such as crediting the
  bitcoin to a custodial account.
  
  To compare zeroconf risk with FX risk: I think we've had one incident in 8
  years of operation where a user successfully fooled our server to accept a
  payment that in the end didn't confirm. To successfully fool (non-RBF)
  zeroconf one needs to have access to mining infrastructure and probability
  of success is the % of hash rate controlled. This is simply due to the fact
  that the network currently won't propagage the replacement transaction to
  the miner, which is what's being discussed here. American call option risk
  would however be available to 100% of all users, needs nothing beyond the
  wallet app, and has no cost to the user - only upside.
  
  Bitrefill currently processes 1500-2000 onchain payments every day. For us,
  a world where bitcoin becomes de facto RBF by default, means that we would
  likely turn off the BIP21 model for onchain payments, instruct Bitcoin
  users to use Lightning or deposit onchain BTC to a custodial account that
  we have.
  This option is however not available for your typical
  BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
  from other merchants or payment providers how they see this new behavior
  and how they would counteract it.
  
  Currently Lightning is somewhere around 15% of our total bitcoin payments.
  This is very much not nothing, and all of us here want Lightning to grow,
  but I think it warrants a serious discussion on whether we want Lightning
  adoption to go to 100% by means of disabling on-chain commerce. For me
  personally it would be an easier discussion to have when Lightning is at
  80%+ of all bitcoin transactions. Currently far too many bitcoin users
  simply don't have access to Lightning, and of those that do and hold their
  own keys Muun is the biggest wallet per our data, not least due to their
  ease-of-use which is under threat per the OP. It's hard to assess how many
  users would switch to Lightning in such a scenario, the communication
  around it would be hard. My intuition says that the majority of the current
  85% of bitcoin users that pay onchain would just not use bitcoin anymore,
  probably shift to an alt. The benefits of Lightning are many and obvious,
  we don't need to limit onchain to make Lightning more appealing. As an
  anecdote, we did experiment with defaulting to bech32 addresses some years
  back. The result was that simply users of the wallets that weren't able to
  pay to bech32 didn't complete the purchase, no support ticket or anything,
  just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
  implemented a wallet selector to allow modern wallets to pay to bech32
  while other wallets can pay to P2SH. This type of thing  is clunky, and
  requires a certain level of scale to be able to do, we certainly wouldn't
  have had the manpower for that when we were starting out. This why I'm
  cautious about introducing more such clunkiness vectors as they are
  centralizing factors.
  
  I'm well aware of the reason for this policy being suggested and the
  potential pinning attack vector for LN and other smart contracts, but I
  think these two risks/costs need to be weighed against eachother first and
  thoroughly discussed because the costs are non-trivial on both sides.
  
  Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
  After interacting with users during high-fee periods I've come to not
  appreciate RBF as a solution to that issue. Most users (80% or so) simply
  don't have access to that functionality, because their wallet doesn't
  support it, or they use a custodial (exchange) wallet etc. Of those that
  have the feature - only the power users understand how RBF works, and
  explaining how to do RBF to a non-power-user is just too complex, for the
  same reason why it's complex for wallets to make sensible non-power-user UI
  around it. Current equilibrium is that mostly only power users have access
  to RBF and they know how to handle it, so things are somewhat working. But
  rolling this out to the broad market is something else and would likely
  cause more confusion.
  CPFP is somewhat more viable but also not perfect as it would require lots
  of edge case code to handle abuse vectors: What if users abuse a generous
  CPFP policy to unstuck past transactions or consolidate large wallets. Best
  is for CPFP to be done on the wallet side, not the merchant side, but there
  too are the same UX issues as with RBF.
  In the end a risk-based approach to decide on which payments are
  non-trivial to reverse is the easiest, taking account user experience and
  such. Remember that in the fiat world card payments have up to 5%
  chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
  1 in a million" accepted transactions successfully reversed. These days we
  have very few support issues related to bitcoin payments. The few that do
  come in are due to accidental RBF users venting frustration about waiting
  for their tx to confirm.
  "In theory, theory and practice are the same. In practice, they are not"
  
  All the best,
  Sergej Kotliar
  CEO Bitrefill.com
  
  
  -- 
  
  Sergej Kotliar
  
  CEO
  
  
  Twitter: @ziggamon <https://twitter.com/ziggamon>
  
  
  www.bitrefill.com
  
  Twitter <https://www.twitter.com/bitrefill> | Blog
  <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
  
  
  -- 
  
  Sergej Kotliar
  
  CEO
  
  
  Twitter: @ziggamon <https://twitter.com/ziggamon>
  
  
  www.bitrefill.com
  
  Twitter <https://www.twitter.com/bitrefill> | Blog
  <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
  
  [-- Attachment #2: Type: text/html, Size: 15458 bytes --]
  
  ^ permalink raw reply	[flat|nested] 33+ messages in thread

• • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
      2022-10-19 14:29 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Sergej Kotliar
    @ 2022-10-19 14:45   ` Erik Aronesty
      2022-10-19 15:43   ` Jeremy Rubin
                         ` (4 subsequent siblings)
      5 siblings, 0 replies; 33+ messages in thread
    From: Erik Aronesty @ 2022-10-19 14:45 UTC (permalink / raw)
      To: Sergej Kotliar, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 1482 bytes --]
    
    > Currently Lightning is somewhere around 15% of our total bitcoin
    payments. This is very much not nothing, and all of us here want Lightning
    to grow, but I think it warrants a serious discussion on whether we want
    Lightning adoption to go to 100% by means of disabling on-chain commerce.
    
    Is this about disabling "on-chain instant commerce"?
    
     - Waiting for confirmation on-chain before shipping a product won't
    change, normally it's 15 minutes or so.  This doesn't change that.
    
     - An easy way to cancel/rbf a transaction doesn't exist - like you said,
    there's no UX for this now, and I don't anticipate one being broadly used
    except by inter-exchange transfers, etc.
    
    So what does this change?
    
     - In the rare event that an RBF transaction is received where the fee
    level means confirmation times will be slow a merchant will have to wait
    very long for at least 1 confirmation, the merchant should alert the user
    that the transaction may take longer than the BTC FX rate guarantee window,
    and may require additional funds if FX rates change.
    
     - Users with wallets that support RBF can now be encouraged to accelerate
    the tx, with help and advice depending on their wallet, in order to lock in
    the FX rates
    
     - 0 conf is still viable strategy for releasing an order, as long as fees
    are very high, and it's very likely to be included in the next block.
     More fee analysis is needed to validate 0 conf and mitigate risks, but now
    it is, at least, more "honest" to the true risks.
    
    [-- Attachment #2: Type: text/html, Size: 1736 bytes --]
    
    ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
      2022-10-19 14:29 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Sergej Kotliar
      2022-10-19 14:45   ` Erik Aronesty
    @ 2022-10-19 15:43   ` Jeremy Rubin
      2022-10-19 15:51     ` Greg Sanders
      2022-10-19 16:04     ` Sergej Kotliar
      2022-10-20  1:37   ` Antoine Riard
                         ` (3 subsequent siblings)
      5 siblings, 2 replies; 33+ messages in thread
    From: Jeremy Rubin @ 2022-10-19 15:43 UTC (permalink / raw)
      To: Sergej Kotliar, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 7874 bytes --]
    
    If they do this to you, and the delta is substantial, can't you sweep all
    such abusers with a cpfp transaction replacing their package and giving you
    the original txn?
    
    On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > Hi all,
    >
    > Chiming in on this thread as I feel like the real dangers of RBF as
    > default policy aren't sufficiently elaborated here. It's not only about the
    > zero-conf (I'll get to that) but there is an even bigger danger called the
    > american call option, which risks endangering the entirety of BIP21 "Scan
    > this QR code with your wallet to buy this product" model that I believe
    > we've all come to appreciate. Specifically, in a scenario with high
    > volatility and many transactions in the mempools (which is where RBF would
    > come in handy), a user can make a low-fee transaction and then wait for
    > hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
    > up, user can cancel his transaction and make a new - cheaper one. The
    > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
    > (it's actually quite easily managed), it's FX risk as the merchant must
    > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
    > some transactions lose money to FX and others earn money - that evens out
    > in the end. But if there is an _easily accessible in the wallet_ feature to
    > "cancel transaction" that means it will eventually get systematically
    > abused. A risk of X% loss on many payments that's easy to systematically
    > abuse is more scary than a rare risk of losing 100% of one occasional
    > payment. It's already possible to execute this form of abuse with opt-in
    > RBF, which may lead to us at some point refusing those payments (even with
    > confirmation) or cumbersome UX to work around it, such as crediting the
    > bitcoin to a custodial account.
    >
    > To compare zeroconf risk with FX risk: I think we've had one incident in 8
    > years of operation where a user successfully fooled our server to accept a
    > payment that in the end didn't confirm. To successfully fool (non-RBF)
    > zeroconf one needs to have access to mining infrastructure and probability
    > of success is the % of hash rate controlled. This is simply due to the fact
    > that the network currently won't propagage the replacement transaction to
    > the miner, which is what's being discussed here. American call option risk
    > would however be available to 100% of all users, needs nothing beyond the
    > wallet app, and has no cost to the user - only upside.
    >
    > Bitrefill currently processes 1500-2000 onchain payments every day. For
    > us, a world where bitcoin becomes de facto RBF by default, means that we
    > would likely turn off the BIP21 model for onchain payments, instruct
    > Bitcoin users to use Lightning or deposit onchain BTC to a custodial
    > account that we have.
    > This option is however not available for your typical
    > BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
    > from other merchants or payment providers how they see this new behavior
    > and how they would counteract it.
    >
    > Currently Lightning is somewhere around 15% of our total bitcoin payments.
    > This is very much not nothing, and all of us here want Lightning to grow,
    > but I think it warrants a serious discussion on whether we want Lightning
    > adoption to go to 100% by means of disabling on-chain commerce. For me
    > personally it would be an easier discussion to have when Lightning is at
    > 80%+ of all bitcoin transactions. Currently far too many bitcoin users
    > simply don't have access to Lightning, and of those that do and hold their
    > own keys Muun is the biggest wallet per our data, not least due to their
    > ease-of-use which is under threat per the OP. It's hard to assess how many
    > users would switch to Lightning in such a scenario, the communication
    > around it would be hard. My intuition says that the majority of the current
    > 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
    > probably shift to an alt. The benefits of Lightning are many and obvious,
    > we don't need to limit onchain to make Lightning more appealing. As an
    > anecdote, we did experiment with defaulting to bech32 addresses some years
    > back. The result was that simply users of the wallets that weren't able to
    > pay to bech32 didn't complete the purchase, no support ticket or anything,
    > just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
    > implemented a wallet selector to allow modern wallets to pay to bech32
    > while other wallets can pay to P2SH. This type of thing  is clunky, and
    > requires a certain level of scale to be able to do, we certainly wouldn't
    > have had the manpower for that when we were starting out. This why I'm
    > cautious about introducing more such clunkiness vectors as they are
    > centralizing factors.
    >
    > I'm well aware of the reason for this policy being suggested and the
    > potential pinning attack vector for LN and other smart contracts, but I
    > think these two risks/costs need to be weighed against eachother first and
    > thoroughly discussed because the costs are non-trivial on both sides.
    >
    > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
    > After interacting with users during high-fee periods I've come to not
    > appreciate RBF as a solution to that issue. Most users (80% or so) simply
    > don't have access to that functionality, because their wallet doesn't
    > support it, or they use a custodial (exchange) wallet etc. Of those that
    > have the feature - only the power users understand how RBF works, and
    > explaining how to do RBF to a non-power-user is just too complex, for the
    > same reason why it's complex for wallets to make sensible non-power-user UI
    > around it. Current equilibrium is that mostly only power users have access
    > to RBF and they know how to handle it, so things are somewhat working. But
    > rolling this out to the broad market is something else and would likely
    > cause more confusion.
    > CPFP is somewhat more viable but also not perfect as it would require lots
    > of edge case code to handle abuse vectors: What if users abuse a generous
    > CPFP policy to unstuck past transactions or consolidate large wallets. Best
    > is for CPFP to be done on the wallet side, not the merchant side, but there
    > too are the same UX issues as with RBF.
    > In the end a risk-based approach to decide on which payments are
    > non-trivial to reverse is the easiest, taking account user experience and
    > such. Remember that in the fiat world card payments have up to 5%
    > chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
    > 1 in a million" accepted transactions successfully reversed. These days we
    > have very few support issues related to bitcoin payments. The few that do
    > come in are due to accidental RBF users venting frustration about waiting
    > for their tx to confirm.
    > "In theory, theory and practice are the same. In practice, they are not"
    >
    > All the best,
    > Sergej Kotliar
    > CEO Bitrefill.com
    >
    >
    > --
    >
    > Sergej Kotliar
    >
    > CEO
    >
    >
    > Twitter: @ziggamon <https://twitter.com/ziggamon>
    >
    >
    > www.bitrefill.com
    >
    > Twitter <https://www.twitter.com/bitrefill> | Blog
    > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
    >
    >
    > --
    >
    > Sergej Kotliar
    >
    > CEO
    >
    >
    > Twitter: @ziggamon <https://twitter.com/ziggamon>
    >
    >
    > www.bitrefill.com
    >
    > Twitter <https://www.twitter.com/bitrefill> | Blog
    > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    
    [-- Attachment #2: Type: text/html, Size: 16607 bytes --]
    
    ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
        2022-10-19 15:43   ` Jeremy Rubin
      @ 2022-10-19 15:51     ` Greg Sanders
        2022-10-19 16:04     ` Sergej Kotliar
        1 sibling, 0 replies; 33+ messages in thread
      From: Greg Sanders @ 2022-10-19 15:51 UTC (permalink / raw)
        To: Jeremy Rubin, Bitcoin Protocol Discussion; +Cc: Sergej Kotliar
      
      [-- Attachment #1: Type: text/plain, Size: 8549 bytes --]
      
      Isn't the extreme of this that the merchant tries to lock in gains on the
      upswing via CPFP, and users on the downswing, both doing scorched earth,
      tossing the delta to fees?
      
      Seems like a MAD situation?
      
      On Wed, Oct 19, 2022 at 11:44 AM Jeremy Rubin via bitcoin-dev <
      bitcoin-dev@lists•linuxfoundation.org> wrote:
      
      > If they do this to you, and the delta is substantial, can't you sweep all
      > such abusers with a cpfp transaction replacing their package and giving you
      > the original txn?
      >
      > On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
      > bitcoin-dev@lists•linuxfoundation.org> wrote:
      >
      >> Hi all,
      >>
      >> Chiming in on this thread as I feel like the real dangers of RBF as
      >> default policy aren't sufficiently elaborated here. It's not only about the
      >> zero-conf (I'll get to that) but there is an even bigger danger called the
      >> american call option, which risks endangering the entirety of BIP21 "Scan
      >> this QR code with your wallet to buy this product" model that I believe
      >> we've all come to appreciate. Specifically, in a scenario with high
      >> volatility and many transactions in the mempools (which is where RBF would
      >> come in handy), a user can make a low-fee transaction and then wait for
      >> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
      >> up, user can cancel his transaction and make a new - cheaper one. The
      >> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
      >> (it's actually quite easily managed), it's FX risk as the merchant must
      >> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
      >> some transactions lose money to FX and others earn money - that evens out
      >> in the end. But if there is an _easily accessible in the wallet_ feature to
      >> "cancel transaction" that means it will eventually get systematically
      >> abused. A risk of X% loss on many payments that's easy to systematically
      >> abuse is more scary than a rare risk of losing 100% of one occasional
      >> payment. It's already possible to execute this form of abuse with opt-in
      >> RBF, which may lead to us at some point refusing those payments (even with
      >> confirmation) or cumbersome UX to work around it, such as crediting the
      >> bitcoin to a custodial account.
      >>
      >> To compare zeroconf risk with FX risk: I think we've had one incident in
      >> 8 years of operation where a user successfully fooled our server to accept
      >> a payment that in the end didn't confirm. To successfully fool (non-RBF)
      >> zeroconf one needs to have access to mining infrastructure and probability
      >> of success is the % of hash rate controlled. This is simply due to the fact
      >> that the network currently won't propagage the replacement transaction to
      >> the miner, which is what's being discussed here. American call option risk
      >> would however be available to 100% of all users, needs nothing beyond the
      >> wallet app, and has no cost to the user - only upside.
      >>
      >> Bitrefill currently processes 1500-2000 onchain payments every day. For
      >> us, a world where bitcoin becomes de facto RBF by default, means that we
      >> would likely turn off the BIP21 model for onchain payments, instruct
      >> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
      >> account that we have.
      >> This option is however not available for your typical
      >> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
      >> from other merchants or payment providers how they see this new behavior
      >> and how they would counteract it.
      >>
      >> Currently Lightning is somewhere around 15% of our total bitcoin
      >> payments. This is very much not nothing, and all of us here want Lightning
      >> to grow, but I think it warrants a serious discussion on whether we want
      >> Lightning adoption to go to 100% by means of disabling on-chain commerce.
      >> For me personally it would be an easier discussion to have when Lightning
      >> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
      >> users simply don't have access to Lightning, and of those that do and hold
      >> their own keys Muun is the biggest wallet per our data, not least due to
      >> their ease-of-use which is under threat per the OP. It's hard to assess how
      >> many users would switch to Lightning in such a scenario, the communication
      >> around it would be hard. My intuition says that the majority of the current
      >> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
      >> probably shift to an alt. The benefits of Lightning are many and obvious,
      >> we don't need to limit onchain to make Lightning more appealing. As an
      >> anecdote, we did experiment with defaulting to bech32 addresses some years
      >> back. The result was that simply users of the wallets that weren't able to
      >> pay to bech32 didn't complete the purchase, no support ticket or anything,
      >> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
      >> implemented a wallet selector to allow modern wallets to pay to bech32
      >> while other wallets can pay to P2SH. This type of thing  is clunky, and
      >> requires a certain level of scale to be able to do, we certainly wouldn't
      >> have had the manpower for that when we were starting out. This why I'm
      >> cautious about introducing more such clunkiness vectors as they are
      >> centralizing factors.
      >>
      >> I'm well aware of the reason for this policy being suggested and the
      >> potential pinning attack vector for LN and other smart contracts, but I
      >> think these two risks/costs need to be weighed against eachother first and
      >> thoroughly discussed because the costs are non-trivial on both sides.
      >>
      >> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
      >> After interacting with users during high-fee periods I've come to not
      >> appreciate RBF as a solution to that issue. Most users (80% or so) simply
      >> don't have access to that functionality, because their wallet doesn't
      >> support it, or they use a custodial (exchange) wallet etc. Of those that
      >> have the feature - only the power users understand how RBF works, and
      >> explaining how to do RBF to a non-power-user is just too complex, for the
      >> same reason why it's complex for wallets to make sensible non-power-user UI
      >> around it. Current equilibrium is that mostly only power users have access
      >> to RBF and they know how to handle it, so things are somewhat working. But
      >> rolling this out to the broad market is something else and would likely
      >> cause more confusion.
      >> CPFP is somewhat more viable but also not perfect as it would require
      >> lots of edge case code to handle abuse vectors: What if users abuse a
      >> generous CPFP policy to unstuck past transactions or consolidate large
      >> wallets. Best is for CPFP to be done on the wallet side, not the merchant
      >> side, but there too are the same UX issues as with RBF.
      >> In the end a risk-based approach to decide on which payments are
      >> non-trivial to reverse is the easiest, taking account user experience and
      >> such. Remember that in the fiat world card payments have up to 5%
      >> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
      >> 1 in a million" accepted transactions successfully reversed. These days we
      >> have very few support issues related to bitcoin payments. The few that do
      >> come in are due to accidental RBF users venting frustration about waiting
      >> for their tx to confirm.
      >> "In theory, theory and practice are the same. In practice, they are not"
      >>
      >> All the best,
      >> Sergej Kotliar
      >> CEO Bitrefill.com
      >>
      >>
      >> --
      >>
      >> Sergej Kotliar
      >>
      >> CEO
      >>
      >>
      >> Twitter: @ziggamon <https://twitter.com/ziggamon>
      >>
      >>
      >> www.bitrefill.com
      >>
      >> Twitter <https://www.twitter.com/bitrefill> | Blog
      >> <https://www.bitrefill.com/blog/> | Angellist
      >> <https://angel.co/bitrefill>
      >>
      >>
      >> --
      >>
      >> Sergej Kotliar
      >>
      >> CEO
      >>
      >>
      >> Twitter: @ziggamon <https://twitter.com/ziggamon>
      >>
      >>
      >> www.bitrefill.com
      >>
      >> Twitter <https://www.twitter.com/bitrefill> | Blog
      >> <https://www.bitrefill.com/blog/> | Angellist
      >> <https://angel.co/bitrefill>
      >> _______________________________________________
      >> 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: 17426 bytes --]
      
      ^ permalink raw reply	[flat|nested] 33+ messages in thread

    • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
        2022-10-19 15:43   ` Jeremy Rubin
        2022-10-19 15:51     ` Greg Sanders
      @ 2022-10-19 16:04     ` Sergej Kotliar
        2022-10-19 16:08       ` Greg Sanders
        1 sibling, 1 reply; 33+ messages in thread
      From: Sergej Kotliar @ 2022-10-19 16:04 UTC (permalink / raw)
        To: Jeremy Rubin; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 8953 bytes --]
      
      It's an interesting idea, presumably it would work w the new package relay.
      Scorched earth bidding war is definitely fine to deter this type of abuse.
      Need to consider it more thoroughly from all sides tho. CPFP on the server
      side generally has a couple of downsides:
      * Requires a hot wallet to receive bitcoin
      * an entity that is reliably known to do CPFP can be abused by people
      looking to consolidate utxos, which can be quite costly. Might be solvable
      with a set of conditionals, and bad UX for abusers is less of a concern :)
      
      Will follow up after more deliberation, thanks!
      
      
      On Wed, 19 Oct 2022 at 17:43, Jeremy Rubin <jeremy.l.rubin@gmail•com> wrote:
      
      > If they do this to you, and the delta is substantial, can't you sweep all
      > such abusers with a cpfp transaction replacing their package and giving you
      > the original txn?
      >
      > On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
      > bitcoin-dev@lists•linuxfoundation.org> wrote:
      >
      >> Hi all,
      >>
      >> Chiming in on this thread as I feel like the real dangers of RBF as
      >> default policy aren't sufficiently elaborated here. It's not only about the
      >> zero-conf (I'll get to that) but there is an even bigger danger called the
      >> american call option, which risks endangering the entirety of BIP21 "Scan
      >> this QR code with your wallet to buy this product" model that I believe
      >> we've all come to appreciate. Specifically, in a scenario with high
      >> volatility and many transactions in the mempools (which is where RBF would
      >> come in handy), a user can make a low-fee transaction and then wait for
      >> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
      >> up, user can cancel his transaction and make a new - cheaper one. The
      >> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
      >> (it's actually quite easily managed), it's FX risk as the merchant must
      >> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
      >> some transactions lose money to FX and others earn money - that evens out
      >> in the end. But if there is an _easily accessible in the wallet_ feature to
      >> "cancel transaction" that means it will eventually get systematically
      >> abused. A risk of X% loss on many payments that's easy to systematically
      >> abuse is more scary than a rare risk of losing 100% of one occasional
      >> payment. It's already possible to execute this form of abuse with opt-in
      >> RBF, which may lead to us at some point refusing those payments (even with
      >> confirmation) or cumbersome UX to work around it, such as crediting the
      >> bitcoin to a custodial account.
      >>
      >> To compare zeroconf risk with FX risk: I think we've had one incident in
      >> 8 years of operation where a user successfully fooled our server to accept
      >> a payment that in the end didn't confirm. To successfully fool (non-RBF)
      >> zeroconf one needs to have access to mining infrastructure and probability
      >> of success is the % of hash rate controlled. This is simply due to the fact
      >> that the network currently won't propagage the replacement transaction to
      >> the miner, which is what's being discussed here. American call option risk
      >> would however be available to 100% of all users, needs nothing beyond the
      >> wallet app, and has no cost to the user - only upside.
      >>
      >> Bitrefill currently processes 1500-2000 onchain payments every day. For
      >> us, a world where bitcoin becomes de facto RBF by default, means that we
      >> would likely turn off the BIP21 model for onchain payments, instruct
      >> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
      >> account that we have.
      >> This option is however not available for your typical
      >> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
      >> from other merchants or payment providers how they see this new behavior
      >> and how they would counteract it.
      >>
      >> Currently Lightning is somewhere around 15% of our total bitcoin
      >> payments. This is very much not nothing, and all of us here want Lightning
      >> to grow, but I think it warrants a serious discussion on whether we want
      >> Lightning adoption to go to 100% by means of disabling on-chain commerce.
      >> For me personally it would be an easier discussion to have when Lightning
      >> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
      >> users simply don't have access to Lightning, and of those that do and hold
      >> their own keys Muun is the biggest wallet per our data, not least due to
      >> their ease-of-use which is under threat per the OP. It's hard to assess how
      >> many users would switch to Lightning in such a scenario, the communication
      >> around it would be hard. My intuition says that the majority of the current
      >> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
      >> probably shift to an alt. The benefits of Lightning are many and obvious,
      >> we don't need to limit onchain to make Lightning more appealing. As an
      >> anecdote, we did experiment with defaulting to bech32 addresses some years
      >> back. The result was that simply users of the wallets that weren't able to
      >> pay to bech32 didn't complete the purchase, no support ticket or anything,
      >> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
      >> implemented a wallet selector to allow modern wallets to pay to bech32
      >> while other wallets can pay to P2SH. This type of thing  is clunky, and
      >> requires a certain level of scale to be able to do, we certainly wouldn't
      >> have had the manpower for that when we were starting out. This why I'm
      >> cautious about introducing more such clunkiness vectors as they are
      >> centralizing factors.
      >>
      >> I'm well aware of the reason for this policy being suggested and the
      >> potential pinning attack vector for LN and other smart contracts, but I
      >> think these two risks/costs need to be weighed against eachother first and
      >> thoroughly discussed because the costs are non-trivial on both sides.
      >>
      >> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
      >> After interacting with users during high-fee periods I've come to not
      >> appreciate RBF as a solution to that issue. Most users (80% or so) simply
      >> don't have access to that functionality, because their wallet doesn't
      >> support it, or they use a custodial (exchange) wallet etc. Of those that
      >> have the feature - only the power users understand how RBF works, and
      >> explaining how to do RBF to a non-power-user is just too complex, for the
      >> same reason why it's complex for wallets to make sensible non-power-user UI
      >> around it. Current equilibrium is that mostly only power users have access
      >> to RBF and they know how to handle it, so things are somewhat working. But
      >> rolling this out to the broad market is something else and would likely
      >> cause more confusion.
      >> CPFP is somewhat more viable but also not perfect as it would require
      >> lots of edge case code to handle abuse vectors: What if users abuse a
      >> generous CPFP policy to unstuck past transactions or consolidate large
      >> wallets. Best is for CPFP to be done on the wallet side, not the merchant
      >> side, but there too are the same UX issues as with RBF.
      >> In the end a risk-based approach to decide on which payments are
      >> non-trivial to reverse is the easiest, taking account user experience and
      >> such. Remember that in the fiat world card payments have up to 5%
      >> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
      >> 1 in a million" accepted transactions successfully reversed. These days we
      >> have very few support issues related to bitcoin payments. The few that do
      >> come in are due to accidental RBF users venting frustration about waiting
      >> for their tx to confirm.
      >> "In theory, theory and practice are the same. In practice, they are not"
      >>
      >> All the best,
      >> Sergej Kotliar
      >> CEO Bitrefill.com
      >>
      >>
      >> --
      >>
      >> Sergej Kotliar
      >>
      >> CEO
      >>
      >>
      >> Twitter: @ziggamon <https://twitter.com/ziggamon>
      >>
      >>
      >> www.bitrefill.com
      >>
      >> Twitter <https://www.twitter.com/bitrefill> | Blog
      >> <https://www.bitrefill.com/blog/> | Angellist
      >> <https://angel.co/bitrefill>
      >>
      >>
      >> --
      >>
      >> Sergej Kotliar
      >>
      >> CEO
      >>
      >>
      >> Twitter: @ziggamon <https://twitter.com/ziggamon>
      >>
      >>
      >> www.bitrefill.com
      >>
      >> Twitter <https://www.twitter.com/bitrefill> | Blog
      >> <https://www.bitrefill.com/blog/> | Angellist
      >> <https://angel.co/bitrefill>
      >> _______________________________________________
      >> bitcoin-dev mailing list
      >> bitcoin-dev@lists•linuxfoundation.org
      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >>
      >
      
      -- 
      
      Sergej Kotliar
      
      CEO
      
      
      Twitter: @ziggamon <https://twitter.com/ziggamon>
      
      
      www.bitrefill.com
      
      Twitter <https://www.twitter.com/bitrefill> | Blog
      <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
      
      [-- Attachment #2: Type: text/html, Size: 21518 bytes --]
      
      ^ permalink raw reply	[flat|nested] 33+ messages in thread

    • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
          2022-10-19 16:04     ` Sergej Kotliar
        @ 2022-10-19 16:08       ` Greg Sanders
          0 siblings, 0 replies; 33+ messages in thread
        From: Greg Sanders @ 2022-10-19 16:08 UTC (permalink / raw)
          To: Sergej Kotliar, Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 9678 bytes --]
        
        Another downside is that the sender may not opt into a non-pinnable future
        format like "V3 transactions", making CPFP difficult. They may spend a lot
        of fees to do this however, so maybe we're really reaching here.
        
        On Wed, Oct 19, 2022 at 12:07 PM Sergej Kotliar via bitcoin-dev <
        bitcoin-dev@lists•linuxfoundation.org> wrote:
        
        > It's an interesting idea, presumably it would work w the new package relay.
        > Scorched earth bidding war is definitely fine to deter this type of abuse.
        > Need to consider it more thoroughly from all sides tho. CPFP on the server
        > side generally has a couple of downsides:
        > * Requires a hot wallet to receive bitcoin
        > * an entity that is reliably known to do CPFP can be abused by people
        > looking to consolidate utxos, which can be quite costly. Might be solvable
        > with a set of conditionals, and bad UX for abusers is less of a concern :)
        >
        > Will follow up after more deliberation, thanks!
        >
        >
        > On Wed, 19 Oct 2022 at 17:43, Jeremy Rubin <jeremy.l.rubin@gmail•com>
        > wrote:
        >
        >> If they do this to you, and the delta is substantial, can't you sweep all
        >> such abusers with a cpfp transaction replacing their package and giving you
        >> the original txn?
        >>
        >> On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
        >> bitcoin-dev@lists•linuxfoundation.org> wrote:
        >>
        >>> Hi all,
        >>>
        >>> Chiming in on this thread as I feel like the real dangers of RBF as
        >>> default policy aren't sufficiently elaborated here. It's not only about the
        >>> zero-conf (I'll get to that) but there is an even bigger danger called the
        >>> american call option, which risks endangering the entirety of BIP21 "Scan
        >>> this QR code with your wallet to buy this product" model that I believe
        >>> we've all come to appreciate. Specifically, in a scenario with high
        >>> volatility and many transactions in the mempools (which is where RBF would
        >>> come in handy), a user can make a low-fee transaction and then wait for
        >>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
        >>> up, user can cancel his transaction and make a new - cheaper one. The
        >>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
        >>> (it's actually quite easily managed), it's FX risk as the merchant must
        >>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
        >>> some transactions lose money to FX and others earn money - that evens out
        >>> in the end. But if there is an _easily accessible in the wallet_ feature to
        >>> "cancel transaction" that means it will eventually get systematically
        >>> abused. A risk of X% loss on many payments that's easy to systematically
        >>> abuse is more scary than a rare risk of losing 100% of one occasional
        >>> payment. It's already possible to execute this form of abuse with opt-in
        >>> RBF, which may lead to us at some point refusing those payments (even with
        >>> confirmation) or cumbersome UX to work around it, such as crediting the
        >>> bitcoin to a custodial account.
        >>>
        >>> To compare zeroconf risk with FX risk: I think we've had one incident in
        >>> 8 years of operation where a user successfully fooled our server to accept
        >>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
        >>> zeroconf one needs to have access to mining infrastructure and probability
        >>> of success is the % of hash rate controlled. This is simply due to the fact
        >>> that the network currently won't propagage the replacement transaction to
        >>> the miner, which is what's being discussed here. American call option risk
        >>> would however be available to 100% of all users, needs nothing beyond the
        >>> wallet app, and has no cost to the user - only upside.
        >>>
        >>> Bitrefill currently processes 1500-2000 onchain payments every day. For
        >>> us, a world where bitcoin becomes de facto RBF by default, means that we
        >>> would likely turn off the BIP21 model for onchain payments, instruct
        >>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
        >>> account that we have.
        >>> This option is however not available for your typical
        >>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
        >>> from other merchants or payment providers how they see this new behavior
        >>> and how they would counteract it.
        >>>
        >>> Currently Lightning is somewhere around 15% of our total bitcoin
        >>> payments. This is very much not nothing, and all of us here want Lightning
        >>> to grow, but I think it warrants a serious discussion on whether we want
        >>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
        >>> For me personally it would be an easier discussion to have when Lightning
        >>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
        >>> users simply don't have access to Lightning, and of those that do and hold
        >>> their own keys Muun is the biggest wallet per our data, not least due to
        >>> their ease-of-use which is under threat per the OP. It's hard to assess how
        >>> many users would switch to Lightning in such a scenario, the communication
        >>> around it would be hard. My intuition says that the majority of the current
        >>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
        >>> probably shift to an alt. The benefits of Lightning are many and obvious,
        >>> we don't need to limit onchain to make Lightning more appealing. As an
        >>> anecdote, we did experiment with defaulting to bech32 addresses some years
        >>> back. The result was that simply users of the wallets that weren't able to
        >>> pay to bech32 didn't complete the purchase, no support ticket or anything,
        >>> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
        >>> implemented a wallet selector to allow modern wallets to pay to bech32
        >>> while other wallets can pay to P2SH. This type of thing  is clunky, and
        >>> requires a certain level of scale to be able to do, we certainly wouldn't
        >>> have had the manpower for that when we were starting out. This why I'm
        >>> cautious about introducing more such clunkiness vectors as they are
        >>> centralizing factors.
        >>>
        >>> I'm well aware of the reason for this policy being suggested and the
        >>> potential pinning attack vector for LN and other smart contracts, but I
        >>> think these two risks/costs need to be weighed against eachother first and
        >>> thoroughly discussed because the costs are non-trivial on both sides.
        >>>
        >>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
        >>> After interacting with users during high-fee periods I've come to not
        >>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
        >>> don't have access to that functionality, because their wallet doesn't
        >>> support it, or they use a custodial (exchange) wallet etc. Of those that
        >>> have the feature - only the power users understand how RBF works, and
        >>> explaining how to do RBF to a non-power-user is just too complex, for the
        >>> same reason why it's complex for wallets to make sensible non-power-user UI
        >>> around it. Current equilibrium is that mostly only power users have access
        >>> to RBF and they know how to handle it, so things are somewhat working. But
        >>> rolling this out to the broad market is something else and would likely
        >>> cause more confusion.
        >>> CPFP is somewhat more viable but also not perfect as it would require
        >>> lots of edge case code to handle abuse vectors: What if users abuse a
        >>> generous CPFP policy to unstuck past transactions or consolidate large
        >>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
        >>> side, but there too are the same UX issues as with RBF.
        >>> In the end a risk-based approach to decide on which payments are
        >>> non-trivial to reverse is the easiest, taking account user experience and
        >>> such. Remember that in the fiat world card payments have up to 5%
        >>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
        >>> 1 in a million" accepted transactions successfully reversed. These days we
        >>> have very few support issues related to bitcoin payments. The few that do
        >>> come in are due to accidental RBF users venting frustration about waiting
        >>> for their tx to confirm.
        >>> "In theory, theory and practice are the same. In practice, they are not"
        >>>
        >>> All the best,
        >>> Sergej Kotliar
        >>> CEO Bitrefill.com
        >>>
        >>>
        >>> --
        >>>
        >>> Sergej Kotliar
        >>>
        >>> CEO
        >>>
        >>>
        >>> Twitter: @ziggamon <https://twitter.com/ziggamon>
        >>>
        >>>
        >>> www.bitrefill.com
        >>>
        >>> Twitter <https://www.twitter.com/bitrefill> | Blog
        >>> <https://www.bitrefill.com/blog/> | Angellist
        >>> <https://angel.co/bitrefill>
        >>>
        >>>
        >>> --
        >>>
        >>> Sergej Kotliar
        >>>
        >>> CEO
        >>>
        >>>
        >>> Twitter: @ziggamon <https://twitter.com/ziggamon>
        >>>
        >>>
        >>> www.bitrefill.com
        >>>
        >>> Twitter <https://www.twitter.com/bitrefill> | Blog
        >>> <https://www.bitrefill.com/blog/> | Angellist
        >>> <https://angel.co/bitrefill>
        >>> _______________________________________________
        >>> bitcoin-dev mailing list
        >>> bitcoin-dev@lists•linuxfoundation.org
        >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >>>
        >>
        >
        > --
        >
        > Sergej Kotliar
        >
        > CEO
        >
        >
        > Twitter: @ziggamon <https://twitter.com/ziggamon>
        >
        >
        > www.bitrefill.com
        >
        > Twitter <https://www.twitter.com/bitrefill> | Blog
        > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >
        
        [-- Attachment #2: Type: text/html, Size: 22529 bytes --]
        
        ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
      2022-10-19 14:29 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Sergej Kotliar
      2022-10-19 14:45   ` Erik Aronesty
      2022-10-19 15:43   ` Jeremy Rubin
    @ 2022-10-20  1:37   ` Antoine Riard
      2022-10-20 14:11     ` Sergej Kotliar
      2022-10-20  4:05   ` Peter Todd
                         ` (2 subsequent siblings)
      5 siblings, 1 reply; 33+ messages in thread
    From: Antoine Riard @ 2022-10-20  1:37 UTC (permalink / raw)
      To: Sergej Kotliar, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 11835 bytes --]
    
    Hi Sergej,
    
    Thanks for the insightful posting, especially highlighting the FX risk
    which was far from being evident on my side!
    
    I don't know in details the security architecture of Bitrefill zeroconf
    acceptance system, though from what I suppose there is at least a set of
    full-nodes well-connected across the p2p network, on top of which some
    mempools reconciliation is exercised
    and zeroconf candidate sanitize against. While I believe this is a far-more
    robust deployment against double-spend attempts, there is still the ability
    for a sophisticated attacker to "taint" miner mempools, and from then
    partition judiciously the transaction-relay network to game such
    distributed mempool monitoring system. There is also the possibility of an
    attacker using some "divide-and-conquer" transaction broadcast algorithm to
    map Bitrefill monitoring point, though as far as I'm aware such algorithm
    has not been discussed. I agree with all of that, easier said than done.
    
    (Which let me think that such distributed mempool monitoring system should
    be provide some enhanced security even in a full-rbf world, that they would
    require far more resources than the average node from the p2p network as a
    whole might be a counter-argument for their social acceptance, however I'm
    also thinking that a robust Lightning infrastructure of the future might
    require multiple mempool/transaction-relay endpoints, at least to reduce
    cross-layer mapping links, though conversation for another day...).
    
    About the FX risk itself, this is far from being isolated from 0conf, as
    Lightning payments themselves might still have a time lapse between the
    issuance of invoices and the settlement of the HTLC at the payee endpoint.
    In fact this volatility concern is endured by anyone using Bitcoin
    regularly in interface with the fiats worlds, i.e everyone excepted the
    long-term store of wealth crowd. From a merchant perspective, effectively,
    the options to cover themselves against this risk are simple. One could
    take positions directly in traditional financial derivatives, like doing
    participants in international trades, though it would require an educated
    manpower on the merchant side. Or leveraging some stablecoins derivatives
    system, coming with its own technical complexity and social trust hazards.
    Another direction would be to clearly define the responsibility between
    merchants or users, on whom is the FX risk. If it's on users, they should
    be the one RBFing/CPFPing to increase the merchant address output, beyond
    the fact "dynamic pricing" would be a weird UX, it would require liveliness
    from the wallets until block confirmation (introducing here many
    requirements of a LN wallet). If it's on the merchants, they could be the
    ones CPFPing thanks to package relay, though it would come again with some
    engineering complexity and overhead blockspace cost (and the first version
    of package relay likely won't enable CPFP batching for concerns of
    potential bandwidth/CPU DoS).
    
    On the efficacy of RBF, I understand the current approach of assuming
    "manual" RBFing by power users ill UX thinking. I hope in the future to
    have automatic fee-bumping implemented by user wallets, where a fee-bumping
    budget and a confirmation preference are pre-defined for all payments, and
    the fee-bumping logic "simply" enforcing the user policy, ideally based on
    historical mempool data. True fact: we don't have such logic in consumer
    wallets today. Or at least only rudimentary in the backend of LN
    implementations, and only for time-sensitive on-chain claims for now (or at
    least speaking for LDK). If we take the history of browsers as a
    comparison, while we might be out of the Lynx-style phase of wallets, we
    might still be more in the late Netscape kind of thing than something like
    Chrome today. In other words, there are many directions for improvements
    for users' wallets.
    
    All that said, I learn to converge that as a community we would be better
    off to weigh deeper the risks/costs between 0confs applications and
    contracting protocols in light of full-rbf.
    
    Best,
    Antoine
    
    Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> a écrit :
    
    > Hi all,
    >
    > Chiming in on this thread as I feel like the real dangers of RBF as
    > default policy aren't sufficiently elaborated here. It's not only about the
    > zero-conf (I'll get to that) but there is an even bigger danger called the
    > american call option, which risks endangering the entirety of BIP21 "Scan
    > this QR code with your wallet to buy this product" model that I believe
    > we've all come to appreciate. Specifically, in a scenario with high
    > volatility and many transactions in the mempools (which is where RBF would
    > come in handy), a user can make a low-fee transaction and then wait for
    > hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
    > up, user can cancel his transaction and make a new - cheaper one. The
    > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
    > (it's actually quite easily managed), it's FX risk as the merchant must
    > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
    > some transactions lose money to FX and others earn money - that evens out
    > in the end. But if there is an _easily accessible in the wallet_ feature to
    > "cancel transaction" that means it will eventually get systematically
    > abused. A risk of X% loss on many payments that's easy to systematically
    > abuse is more scary than a rare risk of losing 100% of one occasional
    > payment. It's already possible to execute this form of abuse with opt-in
    > RBF, which may lead to us at some point refusing those payments (even with
    > confirmation) or cumbersome UX to work around it, such as crediting the
    > bitcoin to a custodial account.
    >
    > To compare zeroconf risk with FX risk: I think we've had one incident in 8
    > years of operation where a user successfully fooled our server to accept a
    > payment that in the end didn't confirm. To successfully fool (non-RBF)
    > zeroconf one needs to have access to mining infrastructure and probability
    > of success is the % of hash rate controlled. This is simply due to the fact
    > that the network currently won't propagage the replacement transaction to
    > the miner, which is what's being discussed here. American call option risk
    > would however be available to 100% of all users, needs nothing beyond the
    > wallet app, and has no cost to the user - only upside.
    >
    > Bitrefill currently processes 1500-2000 onchain payments every day. For
    > us, a world where bitcoin becomes de facto RBF by default, means that we
    > would likely turn off the BIP21 model for onchain payments, instruct
    > Bitcoin users to use Lightning or deposit onchain BTC to a custodial
    > account that we have.
    > This option is however not available for your typical
    > BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
    > from other merchants or payment providers how they see this new behavior
    > and how they would counteract it.
    >
    > Currently Lightning is somewhere around 15% of our total bitcoin payments.
    > This is very much not nothing, and all of us here want Lightning to grow,
    > but I think it warrants a serious discussion on whether we want Lightning
    > adoption to go to 100% by means of disabling on-chain commerce. For me
    > personally it would be an easier discussion to have when Lightning is at
    > 80%+ of all bitcoin transactions. Currently far too many bitcoin users
    > simply don't have access to Lightning, and of those that do and hold their
    > own keys Muun is the biggest wallet per our data, not least due to their
    > ease-of-use which is under threat per the OP. It's hard to assess how many
    > users would switch to Lightning in such a scenario, the communication
    > around it would be hard. My intuition says that the majority of the current
    > 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
    > probably shift to an alt. The benefits of Lightning are many and obvious,
    > we don't need to limit onchain to make Lightning more appealing. As an
    > anecdote, we did experiment with defaulting to bech32 addresses some years
    > back. The result was that simply users of the wallets that weren't able to
    > pay to bech32 didn't complete the purchase, no support ticket or anything,
    > just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
    > implemented a wallet selector to allow modern wallets to pay to bech32
    > while other wallets can pay to P2SH. This type of thing  is clunky, and
    > requires a certain level of scale to be able to do, we certainly wouldn't
    > have had the manpower for that when we were starting out. This why I'm
    > cautious about introducing more such clunkiness vectors as they are
    > centralizing factors.
    >
    > I'm well aware of the reason for this policy being suggested and the
    > potential pinning attack vector for LN and other smart contracts, but I
    > think these two risks/costs need to be weighed against eachother first and
    > thoroughly discussed because the costs are non-trivial on both sides.
    >
    > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
    > After interacting with users during high-fee periods I've come to not
    > appreciate RBF as a solution to that issue. Most users (80% or so) simply
    > don't have access to that functionality, because their wallet doesn't
    > support it, or they use a custodial (exchange) wallet etc. Of those that
    > have the feature - only the power users understand how RBF works, and
    > explaining how to do RBF to a non-power-user is just too complex, for the
    > same reason why it's complex for wallets to make sensible non-power-user UI
    > around it. Current equilibrium is that mostly only power users have access
    > to RBF and they know how to handle it, so things are somewhat working. But
    > rolling this out to the broad market is something else and would likely
    > cause more confusion.
    > CPFP is somewhat more viable but also not perfect as it would require lots
    > of edge case code to handle abuse vectors: What if users abuse a generous
    > CPFP policy to unstuck past transactions or consolidate large wallets. Best
    > is for CPFP to be done on the wallet side, not the merchant side, but there
    > too are the same UX issues as with RBF.
    > In the end a risk-based approach to decide on which payments are
    > non-trivial to reverse is the easiest, taking account user experience and
    > such. Remember that in the fiat world card payments have up to 5%
    > chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
    > 1 in a million" accepted transactions successfully reversed. These days we
    > have very few support issues related to bitcoin payments. The few that do
    > come in are due to accidental RBF users venting frustration about waiting
    > for their tx to confirm.
    > "In theory, theory and practice are the same. In practice, they are not"
    >
    > All the best,
    > Sergej Kotliar
    > CEO Bitrefill.com
    >
    >
    > --
    >
    > Sergej Kotliar
    >
    > CEO
    >
    >
    > Twitter: @ziggamon <https://twitter.com/ziggamon>
    >
    >
    > www.bitrefill.com
    >
    > Twitter <https://www.twitter.com/bitrefill> | Blog
    > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
    >
    >
    > --
    >
    > Sergej Kotliar
    >
    > CEO
    >
    >
    > Twitter: @ziggamon <https://twitter.com/ziggamon>
    >
    >
    > www.bitrefill.com
    >
    > Twitter <https://www.twitter.com/bitrefill> | Blog
    > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    
    [-- Attachment #2: Type: text/html, Size: 20222 bytes --]
    
    ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
        2022-10-20  1:37   ` Antoine Riard
      @ 2022-10-20 14:11     ` Sergej Kotliar
        2022-10-21  1:04       ` Antoine Riard
        0 siblings, 1 reply; 33+ messages in thread
      From: Sergej Kotliar @ 2022-10-20 14:11 UTC (permalink / raw)
        To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 11823 bytes --]
      
      On Thu, 20 Oct 2022 at 03:37, Antoine Riard <antoine.riard@gmail•com> wrote:
      
      > Hi Sergej,
      >
      > Thanks for the insightful posting, especially highlighting the FX risk
      > which was far from being evident on my side!
      >
      > I don't know in details the security architecture of Bitrefill zeroconf
      > acceptance system, though from what I suppose there is at least a set of
      > full-nodes well-connected across the p2p network, on top of which some
      > mempools reconciliation is exercised
      > and zeroconf candidate sanitize against. While I believe this is a
      > far-more robust deployment against double-spend attempts, there is still
      > the ability for a sophisticated attacker to "taint" miner mempools, and
      > from then partition judiciously the transaction-relay network to game such
      > distributed mempool monitoring system. There is also the possibility of an
      > attacker using some "divide-and-conquer" transaction broadcast algorithm to
      > map Bitrefill monitoring point, though as far as I'm aware such algorithm
      > has not been discussed. I agree with all of that, easier said than done.
      >
      
      There is a long list of countermeasures that can be built to reduce these
      attacks, but to be frank we've only implemented a small subset of these and
      not had any issues, so even a lower level of security is more than fine
      today to have basically zero abuse. If issues arise we could implement more
      of the countermeasures as appropriate to the abuse that has happened in the
      wild.
      
      
      > On the efficacy of RBF, I understand the current approach of assuming
      > "manual" RBFing by power users ill UX thinking. I hope in the future to
      > have automatic fee-bumping implemented by user wallets, where a fee-bumping
      > budget and a confirmation preference are pre-defined for all payments, and
      > the fee-bumping logic "simply" enforcing the user policy, ideally based on
      > historical mempool data. True fact: we don't have such logic in consumer
      > wallets today.
      >
      
      In deed. And the vast majority of bitcoin users don't even have access to
      any RBF functionality today, so we're not even seeing gradual development
      of these things yet. I think this fact needs to be taken into account when
      designing breaking changes to bitcoin policy. Had these things been in
      place and widely used the conversation would have been much easier.
      
      Fundamentally, my view is that all the UX problems related to RBF alone are
      sufficient of an issue to hold off on rolling out these upgrades for the
      foreseeable future and think of other ways of solving the pinning issue and
      other issues w the current policy. Might be that it's just a fundamental
      goal conflict that different people want different behavior but I remain
      optimistic for creative solutions from both sides. UX issues are soft as
      opposed to theoretical attack vectors which are hard and binary, we need
      find a way to weigh "even though it doesn't happen it can theoretically be
      hacked" against "many users find it confusing and stressful" which is not a
      trivial assessment to do.
      
      All that said, I learn to converge that as a community we would be better
      > off to weigh deeper the risks/costs between 0confs applications and
      > contracting protocols in light of full-rbf.
      >
      
      In deed. And as you wrote in a different message, I agree that it's
      unfortunate that there isn't more interaction between the mailing list and
      services and companies using this stuff day-to-day. Not that it's anyone's
      fault in particular, let's try from all sides to find more ways to create
      more interaction on these topics. I've pinged a few colleagues that work on
      payments in the space and hope they will chime in more in this forum!
      
      All the best,
      Sergej
      
      
      > Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
      > bitcoin-dev@lists•linuxfoundation.org> a écrit :
      >
      >> Hi all,
      >>
      >> Chiming in on this thread as I feel like the real dangers of RBF as
      >> default policy aren't sufficiently elaborated here. It's not only about the
      >> zero-conf (I'll get to that) but there is an even bigger danger called the
      >> american call option, which risks endangering the entirety of BIP21 "Scan
      >> this QR code with your wallet to buy this product" model that I believe
      >> we've all come to appreciate. Specifically, in a scenario with high
      >> volatility and many transactions in the mempools (which is where RBF would
      >> come in handy), a user can make a low-fee transaction and then wait for
      >> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
      >> up, user can cancel his transaction and make a new - cheaper one. The
      >> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
      >> (it's actually quite easily managed), it's FX risk as the merchant must
      >> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
      >> some transactions lose money to FX and others earn money - that evens out
      >> in the end. But if there is an _easily accessible in the wallet_ feature to
      >> "cancel transaction" that means it will eventually get systematically
      >> abused. A risk of X% loss on many payments that's easy to systematically
      >> abuse is more scary than a rare risk of losing 100% of one occasional
      >> payment. It's already possible to execute this form of abuse with opt-in
      >> RBF, which may lead to us at some point refusing those payments (even with
      >> confirmation) or cumbersome UX to work around it, such as crediting the
      >> bitcoin to a custodial account.
      >>
      >> To compare zeroconf risk with FX risk: I think we've had one incident in
      >> 8 years of operation where a user successfully fooled our server to accept
      >> a payment that in the end didn't confirm. To successfully fool (non-RBF)
      >> zeroconf one needs to have access to mining infrastructure and probability
      >> of success is the % of hash rate controlled. This is simply due to the fact
      >> that the network currently won't propagage the replacement transaction to
      >> the miner, which is what's being discussed here. American call option risk
      >> would however be available to 100% of all users, needs nothing beyond the
      >> wallet app, and has no cost to the user - only upside.
      >>
      >> Bitrefill currently processes 1500-2000 onchain payments every day. For
      >> us, a world where bitcoin becomes de facto RBF by default, means that we
      >> would likely turn off the BIP21 model for onchain payments, instruct
      >> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
      >> account that we have.
      >> This option is however not available for your typical
      >> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
      >> from other merchants or payment providers how they see this new behavior
      >> and how they would counteract it.
      >>
      >> Currently Lightning is somewhere around 15% of our total bitcoin
      >> payments. This is very much not nothing, and all of us here want Lightning
      >> to grow, but I think it warrants a serious discussion on whether we want
      >> Lightning adoption to go to 100% by means of disabling on-chain commerce.
      >> For me personally it would be an easier discussion to have when Lightning
      >> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
      >> users simply don't have access to Lightning, and of those that do and hold
      >> their own keys Muun is the biggest wallet per our data, not least due to
      >> their ease-of-use which is under threat per the OP. It's hard to assess how
      >> many users would switch to Lightning in such a scenario, the communication
      >> around it would be hard. My intuition says that the majority of the current
      >> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
      >> probably shift to an alt. The benefits of Lightning are many and obvious,
      >> we don't need to limit onchain to make Lightning more appealing. As an
      >> anecdote, we did experiment with defaulting to bech32 addresses some years
      >> back. The result was that simply users of the wallets that weren't able to
      >> pay to bech32 didn't complete the purchase, no support ticket or anything,
      >> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
      >> implemented a wallet selector to allow modern wallets to pay to bech32
      >> while other wallets can pay to P2SH. This type of thing  is clunky, and
      >> requires a certain level of scale to be able to do, we certainly wouldn't
      >> have had the manpower for that when we were starting out. This why I'm
      >> cautious about introducing more such clunkiness vectors as they are
      >> centralizing factors.
      >>
      >> I'm well aware of the reason for this policy being suggested and the
      >> potential pinning attack vector for LN and other smart contracts, but I
      >> think these two risks/costs need to be weighed against eachother first and
      >> thoroughly discussed because the costs are non-trivial on both sides.
      >>
      >> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
      >> After interacting with users during high-fee periods I've come to not
      >> appreciate RBF as a solution to that issue. Most users (80% or so) simply
      >> don't have access to that functionality, because their wallet doesn't
      >> support it, or they use a custodial (exchange) wallet etc. Of those that
      >> have the feature - only the power users understand how RBF works, and
      >> explaining how to do RBF to a non-power-user is just too complex, for the
      >> same reason why it's complex for wallets to make sensible non-power-user UI
      >> around it. Current equilibrium is that mostly only power users have access
      >> to RBF and they know how to handle it, so things are somewhat working. But
      >> rolling this out to the broad market is something else and would likely
      >> cause more confusion.
      >> CPFP is somewhat more viable but also not perfect as it would require
      >> lots of edge case code to handle abuse vectors: What if users abuse a
      >> generous CPFP policy to unstuck past transactions or consolidate large
      >> wallets. Best is for CPFP to be done on the wallet side, not the merchant
      >> side, but there too are the same UX issues as with RBF.
      >> In the end a risk-based approach to decide on which payments are
      >> non-trivial to reverse is the easiest, taking account user experience and
      >> such. Remember that in the fiat world card payments have up to 5%
      >> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
      >> 1 in a million" accepted transactions successfully reversed. These days we
      >> have very few support issues related to bitcoin payments. The few that do
      >> come in are due to accidental RBF users venting frustration about waiting
      >> for their tx to confirm.
      >> "In theory, theory and practice are the same. In practice, they are not"
      >>
      >> All the best,
      >> Sergej Kotliar
      >> CEO Bitrefill.com
      >>
      >>
      >> --
      >>
      >> Sergej Kotliar
      >>
      >> CEO
      >>
      >>
      >> Twitter: @ziggamon <https://twitter.com/ziggamon>
      >>
      >>
      >> www.bitrefill.com
      >>
      >> Twitter <https://www.twitter.com/bitrefill> | Blog
      >> <https://www.bitrefill.com/blog/> | Angellist
      >> <https://angel.co/bitrefill>
      >>
      >>
      >> --
      >>
      >> Sergej Kotliar
      >>
      >> CEO
      >>
      >>
      >> Twitter: @ziggamon <https://twitter.com/ziggamon>
      >>
      >>
      >> www.bitrefill.com
      >>
      >> Twitter <https://www.twitter.com/bitrefill> | Blog
      >> <https://www.bitrefill.com/blog/> | Angellist
      >> <https://angel.co/bitrefill>
      >> _______________________________________________
      >> bitcoin-dev mailing list
      >> bitcoin-dev@lists•linuxfoundation.org
      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >>
      >
      
      -- 
      
      Sergej Kotliar
      
      CEO
      
      
      Twitter: @ziggamon <https://twitter.com/ziggamon>
      
      
      www.bitrefill.com
      
      Twitter <https://www.twitter.com/bitrefill> | Blog
      <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
      
      [-- Attachment #2: Type: text/html, Size: 24787 bytes --]
      
      ^ permalink raw reply	[flat|nested] 33+ messages in thread

    • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
          2022-10-20 14:11     ` Sergej Kotliar
        @ 2022-10-21  1:04       ` Antoine Riard
          0 siblings, 0 replies; 33+ messages in thread
        From: Antoine Riard @ 2022-10-21  1:04 UTC (permalink / raw)
          To: Sergej Kotliar; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 16843 bytes --]
        
        > There is a long list of countermeasures that can be built to reduce these
        > attacks, but to be frank we've only implemented a small subset of these
        and
        > not had any issues, so even a lower level of security is more than fine
        > today to have basically zero abuse. If issues arise we could implement
        more
        > of the countermeasures as appropriate to the abuse that has happened in
        the
        > wild.
        
        From reading one of your other mail, apparently 60% of Bitrefill payments
        are non-rbfable on-chain transactions and as such fine for zeroconf. What
        I'm wondering is, in case of a wide majority of the full-nodes supporting
        full-rbf, if any incoming transaction traffic could be risk-managed
        well-enough thanks to some additional countermeasures to be
        zeroconf-acceptable ?
        
        We can be technically creative here. One could think of some overlay
        monitoring between zeroconf merchants, where mempooldiffs are exchanged to
        observe if any acceptance candidate is double-spent inside some other
        participant's mempool. Of course, the reconciliation rate would need to be
        pretty high to still ensure an "instant payment" UX, though the bandwidth
        overhead should be okay as we assume full-node enterprise hosts. I don't
        think such functionality would be used by any full-node, it might leverage
        p2p extensions but it would be some differentiated services on top of the
        usual messages. This is just an idea, and the concrete 0conf acceptance
        flow problem needs to be better specified.
        
        > Fundamentally, my view is that all the UX problems related to RBF alone
        are
        > sufficient of an issue to hold off on rolling out these upgrades for the
        > foreseeable future and think of other ways of solving the pinning issue
        and
        > other issues w the current policy. Might be that it's just a fundamental
        > goal conflict that different people want different behavior but I remain
        > optimistic for creative solutions from both sides. UX issues are soft as
        > opposed to theoretical attack vectors which are hard and binary, we need
        > find a way to weigh "even though it doesn't happen it can theoretically be
        > hacked" against "many users find it confusing and stressful" which is not
        a
        > trivial assessment to do.
        
        Seriously, solving the pinning issues for contracting protocols already
        busy few of the most brilliant bitcoin developers almost full-time. If we
        had straightforward and backward compatible with all classes of current
        Bitcoin applications, we would go for it. Of course, it doesn't mean we
        should close the problem of space exploration, and if someone can come up
        with solutions offering equivalent trade-offs, I'm all to listen. This is
        still an open question if we would have to allow a subset of transactions
        to be full-rbf, to fully achieve the semantics of v3 transactions, or at
        least if we would like to protect currently open Lightning channels. Hard
        problems here.
        
        While I'm hearing the uncertainty of an easy assessment weighting between
        favoring UX issues or solving hard theoretical attacks, those latter
        concerns I've been serious enough among the Lightning development community
        to take it as one of the top engineering issues among all those last years.
        From my experience, pentesting in a "black-box" fashion of some subset of
        LN vulnerabilities, they turn out as really practical after a few days of
        hacking if you know where to hit. Moreover, it should be underscored that
        the attacker incentive model between targeting a 0conf merchant like
        Bitrefill and a sizable Lightning infrastructure is a bit different. On one
        side, you will pocket free gift cards that are likely traceable to
        real-world identities, or cancellable by calling out the issuers. On the
        other side, you get a stack of free satoshis, easily fungible among all
        other coins. As such, we might foresee far more exploitations against LN,
        once the network has caught up in terms of volume and stakes to compare
        with the most advanced Defi smart contract platforms in the wider
        cryptocurrencies ecosystem, attracting today sophisticated attackers. Or at
        least, I'm worried by such an outcome playing out for LN if we're too slow
        on rolling out mitigations...
        
        All that said, from my perspective upgrading mempool policy doesn't seem
        incompatible with a parallel effort to improve the UX problems of RBF, by
        automatic fee-bumping logic in a transparent way for the end-users. Like
        you said, we should be all optimistic on creative solutions, and
        communicate better between merchants and devs on the problem space.
        
        Looking forward to having more interactions on these topics in the future!
        
        Best,
        Antoine
        
        Le jeu. 20 oct. 2022 à 10:12, Sergej Kotliar <sergej@bitrefill•com> a
        écrit :
        
        >
        >
        > On Thu, 20 Oct 2022 at 03:37, Antoine Riard <antoine.riard@gmail•com>
        > wrote:
        >
        >> Hi Sergej,
        >>
        >> Thanks for the insightful posting, especially highlighting the FX risk
        >> which was far from being evident on my side!
        >>
        >> I don't know in details the security architecture of Bitrefill zeroconf
        >> acceptance system, though from what I suppose there is at least a set of
        >> full-nodes well-connected across the p2p network, on top of which some
        >> mempools reconciliation is exercised
        >> and zeroconf candidate sanitize against. While I believe this is a
        >> far-more robust deployment against double-spend attempts, there is still
        >> the ability for a sophisticated attacker to "taint" miner mempools, and
        >> from then partition judiciously the transaction-relay network to game such
        >> distributed mempool monitoring system. There is also the possibility of an
        >> attacker using some "divide-and-conquer" transaction broadcast algorithm to
        >> map Bitrefill monitoring point, though as far as I'm aware such algorithm
        >> has not been discussed. I agree with all of that, easier said than done.
        >>
        >
        > There is a long list of countermeasures that can be built to reduce these
        > attacks, but to be frank we've only implemented a small subset of these and
        > not had any issues, so even a lower level of security is more than fine
        > today to have basically zero abuse. If issues arise we could implement more
        > of the countermeasures as appropriate to the abuse that has happened in the
        > wild.
        >
        >
        >> On the efficacy of RBF, I understand the current approach of assuming
        >> "manual" RBFing by power users ill UX thinking. I hope in the future to
        >> have automatic fee-bumping implemented by user wallets, where a fee-bumping
        >> budget and a confirmation preference are pre-defined for all payments, and
        >> the fee-bumping logic "simply" enforcing the user policy, ideally based on
        >> historical mempool data. True fact: we don't have such logic in consumer
        >> wallets today.
        >>
        >
        > In deed. And the vast majority of bitcoin users don't even have access to
        > any RBF functionality today, so we're not even seeing gradual development
        > of these things yet. I think this fact needs to be taken into account when
        > designing breaking changes to bitcoin policy. Had these things been in
        > place and widely used the conversation would have been much easier.
        >
        > Fundamentally, my view is that all the UX problems related to RBF alone
        > are sufficient of an issue to hold off on rolling out these upgrades for
        > the foreseeable future and think of other ways of solving the pinning issue
        > and other issues w the current policy. Might be that it's just a
        > fundamental goal conflict that different people want different behavior but
        > I remain optimistic for creative solutions from both sides. UX issues are
        > soft as opposed to theoretical attack vectors which are hard and binary, we
        > need find a way to weigh "even though it doesn't happen it can
        > theoretically be hacked" against "many users find it confusing and
        > stressful" which is not a trivial assessment to do.
        >
        > All that said, I learn to converge that as a community we would be better
        >> off to weigh deeper the risks/costs between 0confs applications and
        >> contracting protocols in light of full-rbf.
        >>
        >
        > In deed. And as you wrote in a different message, I agree that it's
        > unfortunate that there isn't more interaction between the mailing list and
        > services and companies using this stuff day-to-day. Not that it's anyone's
        > fault in particular, let's try from all sides to find more ways to create
        > more interaction on these topics. I've pinged a few colleagues that work on
        > payments in the space and hope they will chime in more in this forum!
        >
        > All the best,
        > Sergej
        >
        >
        >> Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
        >> bitcoin-dev@lists•linuxfoundation.org> a écrit :
        >>
        >>> Hi all,
        >>>
        >>> Chiming in on this thread as I feel like the real dangers of RBF as
        >>> default policy aren't sufficiently elaborated here. It's not only about the
        >>> zero-conf (I'll get to that) but there is an even bigger danger called the
        >>> american call option, which risks endangering the entirety of BIP21 "Scan
        >>> this QR code with your wallet to buy this product" model that I believe
        >>> we've all come to appreciate. Specifically, in a scenario with high
        >>> volatility and many transactions in the mempools (which is where RBF would
        >>> come in handy), a user can make a low-fee transaction and then wait for
        >>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
        >>> up, user can cancel his transaction and make a new - cheaper one. The
        >>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
        >>> (it's actually quite easily managed), it's FX risk as the merchant must
        >>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
        >>> some transactions lose money to FX and others earn money - that evens out
        >>> in the end. But if there is an _easily accessible in the wallet_ feature to
        >>> "cancel transaction" that means it will eventually get systematically
        >>> abused. A risk of X% loss on many payments that's easy to systematically
        >>> abuse is more scary than a rare risk of losing 100% of one occasional
        >>> payment. It's already possible to execute this form of abuse with opt-in
        >>> RBF, which may lead to us at some point refusing those payments (even with
        >>> confirmation) or cumbersome UX to work around it, such as crediting the
        >>> bitcoin to a custodial account.
        >>>
        >>> To compare zeroconf risk with FX risk: I think we've had one incident in
        >>> 8 years of operation where a user successfully fooled our server to accept
        >>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
        >>> zeroconf one needs to have access to mining infrastructure and probability
        >>> of success is the % of hash rate controlled. This is simply due to the fact
        >>> that the network currently won't propagage the replacement transaction to
        >>> the miner, which is what's being discussed here. American call option risk
        >>> would however be available to 100% of all users, needs nothing beyond the
        >>> wallet app, and has no cost to the user - only upside.
        >>>
        >>> Bitrefill currently processes 1500-2000 onchain payments every day. For
        >>> us, a world where bitcoin becomes de facto RBF by default, means that we
        >>> would likely turn off the BIP21 model for onchain payments, instruct
        >>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
        >>> account that we have.
        >>> This option is however not available for your typical
        >>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
        >>> from other merchants or payment providers how they see this new behavior
        >>> and how they would counteract it.
        >>>
        >>> Currently Lightning is somewhere around 15% of our total bitcoin
        >>> payments. This is very much not nothing, and all of us here want Lightning
        >>> to grow, but I think it warrants a serious discussion on whether we want
        >>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
        >>> For me personally it would be an easier discussion to have when Lightning
        >>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
        >>> users simply don't have access to Lightning, and of those that do and hold
        >>> their own keys Muun is the biggest wallet per our data, not least due to
        >>> their ease-of-use which is under threat per the OP. It's hard to assess how
        >>> many users would switch to Lightning in such a scenario, the communication
        >>> around it would be hard. My intuition says that the majority of the current
        >>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
        >>> probably shift to an alt. The benefits of Lightning are many and obvious,
        >>> we don't need to limit onchain to make Lightning more appealing. As an
        >>> anecdote, we did experiment with defaulting to bech32 addresses some years
        >>> back. The result was that simply users of the wallets that weren't able to
        >>> pay to bech32 didn't complete the purchase, no support ticket or anything,
        >>> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
        >>> implemented a wallet selector to allow modern wallets to pay to bech32
        >>> while other wallets can pay to P2SH. This type of thing  is clunky, and
        >>> requires a certain level of scale to be able to do, we certainly wouldn't
        >>> have had the manpower for that when we were starting out. This why I'm
        >>> cautious about introducing more such clunkiness vectors as they are
        >>> centralizing factors.
        >>>
        >>> I'm well aware of the reason for this policy being suggested and the
        >>> potential pinning attack vector for LN and other smart contracts, but I
        >>> think these two risks/costs need to be weighed against eachother first and
        >>> thoroughly discussed because the costs are non-trivial on both sides.
        >>>
        >>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
        >>> After interacting with users during high-fee periods I've come to not
        >>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
        >>> don't have access to that functionality, because their wallet doesn't
        >>> support it, or they use a custodial (exchange) wallet etc. Of those that
        >>> have the feature - only the power users understand how RBF works, and
        >>> explaining how to do RBF to a non-power-user is just too complex, for the
        >>> same reason why it's complex for wallets to make sensible non-power-user UI
        >>> around it. Current equilibrium is that mostly only power users have access
        >>> to RBF and they know how to handle it, so things are somewhat working. But
        >>> rolling this out to the broad market is something else and would likely
        >>> cause more confusion.
        >>> CPFP is somewhat more viable but also not perfect as it would require
        >>> lots of edge case code to handle abuse vectors: What if users abuse a
        >>> generous CPFP policy to unstuck past transactions or consolidate large
        >>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
        >>> side, but there too are the same UX issues as with RBF.
        >>> In the end a risk-based approach to decide on which payments are
        >>> non-trivial to reverse is the easiest, taking account user experience and
        >>> such. Remember that in the fiat world card payments have up to 5%
        >>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
        >>> 1 in a million" accepted transactions successfully reversed. These days we
        >>> have very few support issues related to bitcoin payments. The few that do
        >>> come in are due to accidental RBF users venting frustration about waiting
        >>> for their tx to confirm.
        >>> "In theory, theory and practice are the same. In practice, they are not"
        >>>
        >>> All the best,
        >>> Sergej Kotliar
        >>> CEO Bitrefill.com
        >>>
        >>>
        >>> --
        >>>
        >>> Sergej Kotliar
        >>>
        >>> CEO
        >>>
        >>>
        >>> Twitter: @ziggamon <https://twitter.com/ziggamon>
        >>>
        >>>
        >>> www.bitrefill.com
        >>>
        >>> Twitter <https://www.twitter.com/bitrefill> | Blog
        >>> <https://www.bitrefill.com/blog/> | Angellist
        >>> <https://angel.co/bitrefill>
        >>>
        >>>
        >>> --
        >>>
        >>> Sergej Kotliar
        >>>
        >>> CEO
        >>>
        >>>
        >>> Twitter: @ziggamon <https://twitter.com/ziggamon>
        >>>
        >>>
        >>> www.bitrefill.com
        >>>
        >>> Twitter <https://www.twitter.com/bitrefill> | Blog
        >>> <https://www.bitrefill.com/blog/> | Angellist
        >>> <https://angel.co/bitrefill>
        >>> _______________________________________________
        >>> bitcoin-dev mailing list
        >>> bitcoin-dev@lists•linuxfoundation.org
        >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >>>
        >>
        >
        > --
        >
        > Sergej Kotliar
        >
        > CEO
        >
        >
        > Twitter: @ziggamon <https://twitter.com/ziggamon>
        >
        >
        > www.bitrefill.com
        >
        > Twitter <https://www.twitter.com/bitrefill> | Blog
        > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
        >
        
        [-- Attachment #2: Type: text/html, Size: 29957 bytes --]
        
        ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
      2022-10-19 14:29 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Sergej Kotliar
                         ` (2 preceding siblings ...)
      2022-10-20  1:37   ` Antoine Riard
    @ 2022-10-20  4:05   ` Peter Todd
      2022-10-21 19:35     ` Peter Todd
      2022-10-20  7:22   ` Anthony Towns
      2022-10-23 19:20   ` David A. Harding
      5 siblings, 1 reply; 33+ messages in thread
    From: Peter Todd @ 2022-10-20  4:05 UTC (permalink / raw)
      To: Sergej Kotliar, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 2541 bytes --]
    
    On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
    > Hi all,
    > 
    > Chiming in on this thread as I feel like the real dangers of RBF as default
    > policy aren't sufficiently elaborated here. It's not only about the
    > zero-conf (I'll get to that) but there is an even bigger danger called the
    > american call option, which risks endangering the entirety of BIP21 "Scan
    > this QR code with your wallet to buy this product" model that I believe
    > we've all come to appreciate. Specifically, in a scenario with high
    > volatility and many transactions in the mempools (which is where RBF would
    > come in handy), a user can make a low-fee transaction and then wait for
    > hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
    > up, user can cancel his transaction and make a new - cheaper one. The
    
    I just checked this, and Bitrefill accepts transactions with RBF enabled.
    
    > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
    > (it's actually quite easily managed), it's FX risk as the merchant must
    > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
    > some transactions lose money to FX and others earn money - that evens out
    > in the end. But if there is an _easily accessible in the wallet_ feature to
    > "cancel transaction" that means it will eventually get systematically
    
    ...and I checked this with Electrum on Android, which has a handy "Cancel
    Transaction" feature in the UI to easily cancel a payment. Which I did. You
    should have a pending payment from this email, and unsurprisingly I don't have
    my gift card. :)
    
    The ship has already sailed on this. I'd suggest accepting Lightning, which
    drastically shortens the time window involved.
    
    FWIW, fixedfloat.com already deals with this call option risk by charging a
    higher fee (1% vs 0.5%) for conversions where the exact destination amount has
    been locked in; the default is for the exact destination amount to be picked at
    the moment of confirmation.
    
    > abused. A risk of X% loss on many payments that's easy to systematically
    > Bitrefill currently processes 1500-2000 onchain payments every day. For us,
    > a world where bitcoin becomes de facto RBF by default, means that we would
    
    Electrum is RBF by default. So does Green Wallet, and many other wallets,  as
    well as many exchanges. Most of those wallets/exchanges don't even have a way
    to send a transaction without RBF. This ship has sailed.
    
    -- 
    https://petertodd.org 'peter'[:-1]@petertodd.org
    
    [-- Attachment #2: signature.asc --]
    [-- Type: application/pgp-signature, Size: 488 bytes --]
    
    ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
        2022-10-20  4:05   ` Peter Todd
      @ 2022-10-21 19:35     ` Peter Todd
        0 siblings, 0 replies; 33+ messages in thread
      From: Peter Todd @ 2022-10-21 19:35 UTC (permalink / raw)
        To: Sergej Kotliar, Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 527 bytes --]
      
      On Thu, Oct 20, 2022 at 12:05:33AM -0400, Peter Todd wrote:
      > ...and I checked this with Electrum on Android, which has a handy "Cancel
      > Transaction" feature in the UI to easily cancel a payment. Which I did. You
      > should have a pending payment from this email, and unsurprisingly I don't have
      > my gift card. :)
      
      FYI I asked around and in addition to Electrum, BlueWallet, Simple Bitcoin
      Wallet, and Specter Wallet all implement tx cancelation. Probably more.
      
      -- 
      https://petertodd.org 'peter'[:-1]@petertodd.org
      
      [-- Attachment #2: signature.asc --]
      [-- Type: application/pgp-signature, Size: 488 bytes --]
      
      ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
      2022-10-19 14:29 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Sergej Kotliar
                         ` (3 preceding siblings ...)
      2022-10-20  4:05   ` Peter Todd
    @ 2022-10-20  7:22   ` Anthony Towns
      2022-10-20 12:37     ` Sergej Kotliar
      2022-10-23 19:20   ` David A. Harding
      5 siblings, 1 reply; 33+ messages in thread
    From: Anthony Towns @ 2022-10-20  7:22 UTC (permalink / raw)
      To: Sergej Kotliar, Bitcoin Protocol Discussion
    
    On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
    > The
    > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
    > (it's actually quite easily managed),
    
    You mean "it's quite easily managed, provided the transaction doesn't
    opt-in to rbf", right? At least, that's what I understood you saying last
    time; ie that if the tx signals rbf, then you just don't do zeroconf no
    matter what other trustworthy signals you might see:
    
      https://twitter.com/ziggamon/status/1435863691816275970
    
    (rbf txs seem to have increased from 22% then to 29% now)
    
    > it's FX risk as the merchant must
    > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
    > some transactions lose money to FX and others earn money - that evens out
    > in the end.
    
    > But if there is an _easily accessible in the wallet_ feature to
    > "cancel transaction" that means it will eventually get systematically
    > abused. A risk of X% loss on many payments that's easy to systematically
    > abuse is more scary than a rare risk of losing 100% of one occasional
    > payment. It's already possible to execute this form of abuse with opt-in
    > RBF,
    
    If someone's going to systematically exploit your store via this
    mechanism, it seems like they'd just find a single wallet with a good
    UX for opt-in RBF and lowballing fees, and go to town -- not something
    where opt-in rbf vs fullrbf policies make any difference at all? 
    
    It's not like existing wallets that don't let you set RBF will suddenly
    get a good UX for replacing transactions just because they'd be relayed
    if they did, is it?
    
    > To successfully fool (non-RBF)
    > zeroconf one needs to have access to mining infrastructure and probability
    > of success is the % of hash rate controlled.
    
    I thought the "normal" avenue for fooling non-RBF zeroconf was to create
    two conflicting txs in advance, one paying the merchant, one paying
    yourself, connect to many peers, relay the one paying the merchant to
    the merchant, and the other to everyone else.
    
    I'm just basing this off Peter Todd's stuff from years ago:
    
    https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
    
    https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
    
    > Currently Lightning is somewhere around 15% of our total bitcoin payments.
    
    So, based on last year's numbers, presumably that makes your bitcoin
    payments break down as something like:
    
       5% txs are on-chain and seem shady and are excluded from zeroconf
      15% txs are lightning
      20% txs are on-chain but signal rbf and are excluded from zeroconf
      60% txs are on-chain and seem fine for zeroconf
    
    > This is very much not nothing, and all of us here want Lightning to grow,
    > but I think it warrants a serious discussion on whether we want Lightning
    > adoption to go to 100% by means of disabling on-chain commerce.
    
    If the numbers above were accurate, this would just mean you'd go from 60%
    zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
    
    > For me
    > personally it would be an easier discussion to have when Lightning is at
    > 80%+ of all bitcoin transactions.
    
    Can you extrapolate from the numbers you've seen to estimate when that
    might be, given current trends? Or perhaps when fine-for-zeroconf txs
    drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
    work the same in a fullrbf world.
    
    > The benefits of Lightning are many and obvious,
    > we don't need to limit onchain to make Lightning more appealing. 
    
    To be fair, I think making lightning (and coinjoins) work better is
    exactly what inspired this -- not as a "make on-chain worse so we look
    better in comparison", but as a "making lightning work well is a bunch
    of hard problems, here's the next thing we need in order to beat the
    next problem".
    
    > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
    > After interacting with users during high-fee periods I've come to not
    > appreciate RBF as a solution to that issue. Most users (80% or so) simply
    > don't have access to that functionality, because their wallet doesn't
    > support it, or they use a custodial (exchange) wallet etc. Of those that
    > have the feature - only the power users understand how RBF works, and
    > explaining how to do RBF to a non-power-user is just too complex, for the
    > same reason why it's complex for wallets to make sensible non-power-user UI
    > around it. Current equilibrium is that mostly only power users have access
    > to RBF and they know how to handle it, so things are somewhat working. But
    > rolling this out to the broad market is something else and would likely
    > cause more confusion.
    > CPFP is somewhat more viable but also not perfect as it would require lots
    > of edge case code to handle abuse vectors: What if users abuse a generous
    > CPFP policy to unstuck past transactions or consolidate large wallets. Best
    > is for CPFP to be done on the wallet side, not the merchant side, but there
    > too are the same UX issues as with RBF.
    
    I think if you're ruling out both merchants and users being able to add
    fees to a tx to get it to confirm, then you're going to lose either way.
    Txs will either expire because they've been stuck for more than a week,
    and be vulnerable to replacement at that point anyway, or they'll be
    dropped from mempools because they've filled up and they were the lowest
    fee tx, and be vulnerable to replacement for that reason. In the expiry
    case, the merchant can rebroadcast the original transaction to keep it
    alive, perhaps with a good chance of beating an attacker to the punch,
    but in the full mempool case, you could only do that if you were also
    CPFPing it, which you already ruled out.
    
    Cheers,
    aj
    
    
    ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
        2022-10-20  7:22   ` Anthony Towns
      @ 2022-10-20 12:37     ` Sergej Kotliar
        2022-10-20 14:14       ` Ruben Somsen
                               ` (2 more replies)
        0 siblings, 3 replies; 33+ messages in thread
      From: Sergej Kotliar @ 2022-10-20 12:37 UTC (permalink / raw)
        To: Anthony Towns; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 12590 bytes --]
      
      On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian•com.au> wrote:
      
      > On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
      > wrote:
      > > The
      > > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
      > > (it's actually quite easily managed),
      >
      > You mean "it's quite easily managed, provided the transaction doesn't
      > opt-in to rbf", right? At least, that's what I understood you saying last
      > time; ie that if the tx signals rbf, then you just don't do zeroconf no
      > matter what other trustworthy signals you might see:
      >
      >   https://twitter.com/ziggamon/status/1435863691816275970
      >
      > (rbf txs seem to have increased from 22% then to 29% now)
      >
      
      Yeah. Our share of RBF is a bit lower than that as many RBF transactions
      are something other than consumer purchases, and most consumer purchases
      can't do RBF
      
      
      > > it's FX risk as the merchant must
      > > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
      > > some transactions lose money to FX and others earn money - that evens out
      > > in the end.
      >
      > > But if there is an _easily accessible in the wallet_ feature to
      > > "cancel transaction" that means it will eventually get systematically
      > > abused. A risk of X% loss on many payments that's easy to systematically
      > > abuse is more scary than a rare risk of losing 100% of one occasional
      > > payment. It's already possible to execute this form of abuse with opt-in
      > > RBF,
      >
      > If someone's going to systematically exploit your store via this
      > mechanism, it seems like they'd just find a single wallet with a good
      > UX for opt-in RBF and lowballing fees, and go to town -- not something
      > where opt-in rbf vs fullrbf policies make any difference at all?
      >
      
      Sort of. But yes once this starts being abused systemically we will have to
      do something else w RBF payments, such as crediting the amount in BTC to a
      custodial account. But this option isn't available to your normal payment
      processor type business.
      
      Also worth keeping in mind that sometimes "opportunity makes the thief".
      Currently only power-user wallet have that feature and their market share
      is relatively small, mainly electrum stands out. But if this is available
      to all users everywhere then it will start being abused and we'll have to
      then direct all payments to custodial account, or some other convoluted
      solution.
      
      
      > It's not like existing wallets that don't let you set RBF will suddenly
      > get a good UX for replacing transactions just because they'd be relayed
      > if they did, is it?
      >
      > > To successfully fool (non-RBF)
      > > zeroconf one needs to have access to mining infrastructure and
      > probability
      > > of success is the % of hash rate controlled.
      >
      > I thought the "normal" avenue for fooling non-RBF zeroconf was to create
      > two conflicting txs in advance, one paying the merchant, one paying
      > yourself, connect to many peers, relay the one paying the merchant to
      > the merchant, and the other to everyone else.
      >
      > I'm just basing this off Peter Todd's stuff from years ago:
      >
      >
      > https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
      >
      >
      > https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
      >
      >
      
      Yeah, I know the list still rehashes a single incident from 10 years ago to
      declare the entire practice as unsafe, and ignores real-world data that of
      the last million transactions we had zero cases of this successfully
      abusing us.
      
      
      > > Currently Lightning is somewhere around 15% of our total bitcoin
      > payments.
      >
      > So, based on last year's numbers, presumably that makes your bitcoin
      > payments break down as something like:
      >
      >    5% txs are on-chain and seem shady and are excluded from zeroconf
      >   15% txs are lightning
      >   20% txs are on-chain but signal rbf and are excluded from zeroconf
      >   60% txs are on-chain and seem fine for zeroconf
      >
      
      Numbers are right. Shady is too strong a word, it's mostly transactions
      with very low fee, or high purchase amount, or many dependent unconfirmed
      transactions, stuff like that. In some cases we do a human assessment of
      the support ticket and often just pass them through.
      
      
      > > This is very much not nothing, and all of us here want Lightning to grow,
      > > but I think it warrants a serious discussion on whether we want Lightning
      > > adoption to go to 100% by means of disabling on-chain commerce.
      >
      > If the numbers above were accurate, this would just mean you'd go from 60%
      > zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
      >
      
      Point is that RBF transactions are unsafe even when waiting for a
      confirmation, which Peter Todd trivially proved in the reply next to this.
      The reliable solution is to reject all RBF payments and direct those users
      to custodial accounts. There are other variants to solve this with varying
      degree of convolutedness. RBF is a strictly worse UX as proven by anyone
      accepting bitcoin payments at scale.
      
      
      > > For me
      > > personally it would be an easier discussion to have when Lightning is at
      > > 80%+ of all bitcoin transactions.
      >
      > Can you extrapolate from the numbers you've seen to estimate when that
      > might be, given current trends?
      >
      
      Not sure, it might be exponential growth, and the next 60% of Lightning
      growth happen faster than the first 15%. Hard to tell. But we're likely
      talking years here..
      
      
      >
      > > The benefits of Lightning are many and obvious,
      > > we don't need to limit onchain to make Lightning more appealing.
      >
      > To be fair, I think making lightning (and coinjoins) work better is
      > exactly what inspired this -- not as a "make on-chain worse so we look
      > better in comparison", but as a "making lightning work well is a bunch
      > of hard problems, here's the next thing we need in order to beat the
      > next problem".
      >
      
      In deed. The fact that the largest non-custodial Lightning wallet started
      this thread should be an indicator that despite these intentions the
      solution harms more than it fixes.
      Transactions being evicted from mempool is solved by requiring a minimum
      fee rate, which we do and now seems to have become a standard practice.
      Theoretically we can imagine them being evicted anyway but now we're
      several theoreticals deep again when discussing something that will cause
      massive problems right away. In emergency situations CPFP and similar can
      of course be done manually in special circumstances.
      
      Cheers
      Sergej
      
      
      On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian•com.au> wrote:
      
      > On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
      > wrote:
      > > The
      > > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
      > > (it's actually quite easily managed),
      >
      > You mean "it's quite easily managed, provided the transaction doesn't
      > opt-in to rbf", right? At least, that's what I understood you saying last
      > time; ie that if the tx signals rbf, then you just don't do zeroconf no
      > matter what other trustworthy signals you might see:
      >
      >   https://twitter.com/ziggamon/status/1435863691816275970
      >
      > (rbf txs seem to have increased from 22% then to 29% now)
      >
      > > it's FX risk as the merchant must
      > > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
      > > some transactions lose money to FX and others earn money - that evens out
      > > in the end.
      >
      > > But if there is an _easily accessible in the wallet_ feature to
      > > "cancel transaction" that means it will eventually get systematically
      > > abused. A risk of X% loss on many payments that's easy to systematically
      > > abuse is more scary than a rare risk of losing 100% of one occasional
      > > payment. It's already possible to execute this form of abuse with opt-in
      > > RBF,
      >
      > If someone's going to systematically exploit your store via this
      > mechanism, it seems like they'd just find a single wallet with a good
      > UX for opt-in RBF and lowballing fees, and go to town -- not something
      > where opt-in rbf vs fullrbf policies make any difference at all?
      >
      > It's not like existing wallets that don't let you set RBF will suddenly
      > get a good UX for replacing transactions just because they'd be relayed
      > if they did, is it?
      >
      > > To successfully fool (non-RBF)
      > > zeroconf one needs to have access to mining infrastructure and
      > probability
      > > of success is the % of hash rate controlled.
      >
      > I thought the "normal" avenue for fooling non-RBF zeroconf was to create
      > two conflicting txs in advance, one paying the merchant, one paying
      > yourself, connect to many peers, relay the one paying the merchant to
      > the merchant, and the other to everyone else.
      >
      > I'm just basing this off Peter Todd's stuff from years ago:
      >
      >
      > https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
      >
      >
      > https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
      >
      > > Currently Lightning is somewhere around 15% of our total bitcoin
      > payments.
      >
      > So, based on last year's numbers, presumably that makes your bitcoin
      > payments break down as something like:
      >
      >    5% txs are on-chain and seem shady and are excluded from zeroconf
      >   15% txs are lightning
      >   20% txs are on-chain but signal rbf and are excluded from zeroconf
      >   60% txs are on-chain and seem fine for zeroconf
      >
      > > This is very much not nothing, and all of us here want Lightning to grow,
      > > but I think it warrants a serious discussion on whether we want Lightning
      > > adoption to go to 100% by means of disabling on-chain commerce.
      >
      > If the numbers above were accurate, this would just mean you'd go from 60%
      > zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
      >
      > > For me
      > > personally it would be an easier discussion to have when Lightning is at
      > > 80%+ of all bitcoin transactions.
      >
      > Can you extrapolate from the numbers you've seen to estimate when that
      > might be, given current trends? Or perhaps when fine-for-zeroconf txs
      > drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
      > work the same in a fullrbf world.
      >
      > > The benefits of Lightning are many and obvious,
      > > we don't need to limit onchain to make Lightning more appealing.
      >
      > To be fair, I think making lightning (and coinjoins) work better is
      > exactly what inspired this -- not as a "make on-chain worse so we look
      > better in comparison", but as a "making lightning work well is a bunch
      > of hard problems, here's the next thing we need in order to beat the
      > next problem".
      >
      > > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
      > > After interacting with users during high-fee periods I've come to not
      > > appreciate RBF as a solution to that issue. Most users (80% or so) simply
      > > don't have access to that functionality, because their wallet doesn't
      > > support it, or they use a custodial (exchange) wallet etc. Of those that
      > > have the feature - only the power users understand how RBF works, and
      > > explaining how to do RBF to a non-power-user is just too complex, for the
      > > same reason why it's complex for wallets to make sensible non-power-user
      > UI
      > > around it. Current equilibrium is that mostly only power users have
      > access
      > > to RBF and they know how to handle it, so things are somewhat working.
      > But
      > > rolling this out to the broad market is something else and would likely
      > > cause more confusion.
      > > CPFP is somewhat more viable but also not perfect as it would require
      > lots
      > > of edge case code to handle abuse vectors: What if users abuse a generous
      > > CPFP policy to unstuck past transactions or consolidate large wallets.
      > Best
      > > is for CPFP to be done on the wallet side, not the merchant side, but
      > there
      > > too are the same UX issues as with RBF.
      >
      > I think if you're ruling out both merchants and users being able to add
      > fees to a tx to get it to confirm, then you're going to lose either way.
      > Txs will either expire because they've been stuck for more than a week,
      > and be vulnerable to replacement at that point anyway, or they'll be
      > dropped from mempools because they've filled up and they were the lowest
      > fee tx, and be vulnerable to replacement for that reason. In the expiry
      > case, the merchant can rebroadcast the original transaction to keep it
      > alive, perhaps with a good chance of beating an attacker to the punch,
      > but in the full mempool case, you could only do that if you were also
      > CPFPing it, which you already ruled out.
      >
      > Cheers,
      > aj
      >
      
      
      -- 
      
      Sergej Kotliar
      
      CEO
      
      
      Twitter: @ziggamon <https://twitter.com/ziggamon>
      
      
      www.bitrefill.com
      
      Twitter <https://www.twitter.com/bitrefill> | Blog
      <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
      
      [-- Attachment #2: Type: text/html, Size: 20950 bytes --]
      
      ^ permalink raw reply	[flat|nested] 33+ messages in thread

    • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
          2022-10-20 12:37     ` Sergej Kotliar
        @ 2022-10-20 14:14       ` Ruben Somsen
          2022-10-20 14:17         ` Sergej Kotliar
          2022-10-20 19:58       ` Anthony Towns
          2025-05-02 10:06       ` [bitcoindev] " Anthony Towns
          2 siblings, 1 reply; 33+ messages in thread
        From: Ruben Somsen @ 2022-10-20 14:14 UTC (permalink / raw)
          To: Bitcoin Protocol Discussion; +Cc: Sergej Kotliar, Anthony Towns
        
        [-- Attachment #1: Type: text/plain, Size: 14107 bytes --]
        
        Hi,
        
        There is a reasonable tradeoff one can make to get eventual settlement
        assurance prior to confirmation: lock up the funds with a counterparty in a
        2-of-2 multisig with a timelock back to the owner. As long as the timelock
        has not expired and the recipients trust the counterparty not to sign
        double spends, transactions that are spent from this multisig can be
        considered instant. In cases where the counterparty and the recipient are
        the same person, this solution is trustless. Since merchant purchases tend
        to be low-value, the counterparty risk (facilitating double spends) seems
        acceptable. GreenAddress provided such a service in 2015 or so, but the
        idea got abandoned.
        
        Personally, I find this solution much more tenable than relying on spurious
        network assumptions about what will be propagated and mined.
        
        Best regards,
        Ruben
        
        
        
        On Thu, Oct 20, 2022 at 2:44 PM Sergej Kotliar via bitcoin-dev <
        bitcoin-dev@lists•linuxfoundation.org> wrote:
        
        > On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian•com.au> wrote:
        >
        >> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
        >> wrote:
        >> > The
        >> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
        >> > (it's actually quite easily managed),
        >>
        >> You mean "it's quite easily managed, provided the transaction doesn't
        >> opt-in to rbf", right? At least, that's what I understood you saying last
        >> time; ie that if the tx signals rbf, then you just don't do zeroconf no
        >> matter what other trustworthy signals you might see:
        >>
        >>   https://twitter.com/ziggamon/status/1435863691816275970
        >>
        >> (rbf txs seem to have increased from 22% then to 29% now)
        >>
        >
        > Yeah. Our share of RBF is a bit lower than that as many RBF transactions
        > are something other than consumer purchases, and most consumer purchases
        > can't do RBF
        >
        >
        >> > it's FX risk as the merchant must
        >> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
        >> > some transactions lose money to FX and others earn money - that evens
        >> out
        >> > in the end.
        >>
        >> > But if there is an _easily accessible in the wallet_ feature to
        >> > "cancel transaction" that means it will eventually get systematically
        >> > abused. A risk of X% loss on many payments that's easy to systematically
        >> > abuse is more scary than a rare risk of losing 100% of one occasional
        >> > payment. It's already possible to execute this form of abuse with opt-in
        >> > RBF,
        >>
        >> If someone's going to systematically exploit your store via this
        >> mechanism, it seems like they'd just find a single wallet with a good
        >> UX for opt-in RBF and lowballing fees, and go to town -- not something
        >> where opt-in rbf vs fullrbf policies make any difference at all?
        >>
        >
        > Sort of. But yes once this starts being abused systemically we will have
        > to do something else w RBF payments, such as crediting the amount in BTC to
        > a custodial account. But this option isn't available to your normal payment
        > processor type business.
        >
        > Also worth keeping in mind that sometimes "opportunity makes the thief".
        > Currently only power-user wallet have that feature and their market share
        > is relatively small, mainly electrum stands out. But if this is available
        > to all users everywhere then it will start being abused and we'll have to
        > then direct all payments to custodial account, or some other convoluted
        > solution.
        >
        >
        >> It's not like existing wallets that don't let you set RBF will suddenly
        >> get a good UX for replacing transactions just because they'd be relayed
        >> if they did, is it?
        >>
        >> > To successfully fool (non-RBF)
        >> > zeroconf one needs to have access to mining infrastructure and
        >> probability
        >> > of success is the % of hash rate controlled.
        >>
        >> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
        >> two conflicting txs in advance, one paying the merchant, one paying
        >> yourself, connect to many peers, relay the one paying the merchant to
        >> the merchant, and the other to everyone else.
        >>
        >> I'm just basing this off Peter Todd's stuff from years ago:
        >>
        >>
        >> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
        >>
        >>
        >> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
        >>
        >>
        >
        > Yeah, I know the list still rehashes a single incident from 10 years ago
        > to declare the entire practice as unsafe, and ignores real-world data that
        > of the last million transactions we had zero cases of this successfully
        > abusing us.
        >
        >
        >> > Currently Lightning is somewhere around 15% of our total bitcoin
        >> payments.
        >>
        >> So, based on last year's numbers, presumably that makes your bitcoin
        >> payments break down as something like:
        >>
        >>    5% txs are on-chain and seem shady and are excluded from zeroconf
        >>   15% txs are lightning
        >>   20% txs are on-chain but signal rbf and are excluded from zeroconf
        >>   60% txs are on-chain and seem fine for zeroconf
        >>
        >
        > Numbers are right. Shady is too strong a word, it's mostly transactions
        > with very low fee, or high purchase amount, or many dependent unconfirmed
        > transactions, stuff like that. In some cases we do a human assessment of
        > the support ticket and often just pass them through.
        >
        >
        >> > This is very much not nothing, and all of us here want Lightning to
        >> grow,
        >> > but I think it warrants a serious discussion on whether we want
        >> Lightning
        >> > adoption to go to 100% by means of disabling on-chain commerce.
        >>
        >> If the numbers above were accurate, this would just mean you'd go from 60%
        >> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
        >>
        >
        > Point is that RBF transactions are unsafe even when waiting for a
        > confirmation, which Peter Todd trivially proved in the reply next to this.
        > The reliable solution is to reject all RBF payments and direct those users
        > to custodial accounts. There are other variants to solve this with varying
        > degree of convolutedness. RBF is a strictly worse UX as proven by anyone
        > accepting bitcoin payments at scale.
        >
        >
        >> > For me
        >> > personally it would be an easier discussion to have when Lightning is at
        >> > 80%+ of all bitcoin transactions.
        >>
        >> Can you extrapolate from the numbers you've seen to estimate when that
        >> might be, given current trends?
        >>
        >
        > Not sure, it might be exponential growth, and the next 60% of Lightning
        > growth happen faster than the first 15%. Hard to tell. But we're likely
        > talking years here..
        >
        >
        >>
        >> > The benefits of Lightning are many and obvious,
        >> > we don't need to limit onchain to make Lightning more appealing.
        >>
        >> To be fair, I think making lightning (and coinjoins) work better is
        >> exactly what inspired this -- not as a "make on-chain worse so we look
        >> better in comparison", but as a "making lightning work well is a bunch
        >> of hard problems, here's the next thing we need in order to beat the
        >> next problem".
        >>
        >
        > In deed. The fact that the largest non-custodial Lightning wallet started
        > this thread should be an indicator that despite these intentions the
        > solution harms more than it fixes.
        > Transactions being evicted from mempool is solved by requiring a minimum
        > fee rate, which we do and now seems to have become a standard practice.
        > Theoretically we can imagine them being evicted anyway but now we're
        > several theoreticals deep again when discussing something that will cause
        > massive problems right away. In emergency situations CPFP and similar can
        > of course be done manually in special circumstances.
        >
        > Cheers
        > Sergej
        >
        >
        > On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian•com.au> wrote:
        >
        >> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
        >> wrote:
        >> > The
        >> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
        >> > (it's actually quite easily managed),
        >>
        >> You mean "it's quite easily managed, provided the transaction doesn't
        >> opt-in to rbf", right? At least, that's what I understood you saying last
        >> time; ie that if the tx signals rbf, then you just don't do zeroconf no
        >> matter what other trustworthy signals you might see:
        >>
        >>   https://twitter.com/ziggamon/status/1435863691816275970
        >>
        >> (rbf txs seem to have increased from 22% then to 29% now)
        >>
        >> > it's FX risk as the merchant must
        >> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
        >> > some transactions lose money to FX and others earn money - that evens
        >> out
        >> > in the end.
        >>
        >> > But if there is an _easily accessible in the wallet_ feature to
        >> > "cancel transaction" that means it will eventually get systematically
        >> > abused. A risk of X% loss on many payments that's easy to systematically
        >> > abuse is more scary than a rare risk of losing 100% of one occasional
        >> > payment. It's already possible to execute this form of abuse with opt-in
        >> > RBF,
        >>
        >> If someone's going to systematically exploit your store via this
        >> mechanism, it seems like they'd just find a single wallet with a good
        >> UX for opt-in RBF and lowballing fees, and go to town -- not something
        >> where opt-in rbf vs fullrbf policies make any difference at all?
        >>
        >> It's not like existing wallets that don't let you set RBF will suddenly
        >> get a good UX for replacing transactions just because they'd be relayed
        >> if they did, is it?
        >>
        >> > To successfully fool (non-RBF)
        >> > zeroconf one needs to have access to mining infrastructure and
        >> probability
        >> > of success is the % of hash rate controlled.
        >>
        >> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
        >> two conflicting txs in advance, one paying the merchant, one paying
        >> yourself, connect to many peers, relay the one paying the merchant to
        >> the merchant, and the other to everyone else.
        >>
        >> I'm just basing this off Peter Todd's stuff from years ago:
        >>
        >>
        >> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
        >>
        >>
        >> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
        >>
        >> > Currently Lightning is somewhere around 15% of our total bitcoin
        >> payments.
        >>
        >> So, based on last year's numbers, presumably that makes your bitcoin
        >> payments break down as something like:
        >>
        >>    5% txs are on-chain and seem shady and are excluded from zeroconf
        >>   15% txs are lightning
        >>   20% txs are on-chain but signal rbf and are excluded from zeroconf
        >>   60% txs are on-chain and seem fine for zeroconf
        >>
        >> > This is very much not nothing, and all of us here want Lightning to
        >> grow,
        >> > but I think it warrants a serious discussion on whether we want
        >> Lightning
        >> > adoption to go to 100% by means of disabling on-chain commerce.
        >>
        >> If the numbers above were accurate, this would just mean you'd go from 60%
        >> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
        >>
        >> > For me
        >> > personally it would be an easier discussion to have when Lightning is at
        >> > 80%+ of all bitcoin transactions.
        >>
        >> Can you extrapolate from the numbers you've seen to estimate when that
        >> might be, given current trends? Or perhaps when fine-for-zeroconf txs
        >> drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
        >> work the same in a fullrbf world.
        >>
        >> > The benefits of Lightning are many and obvious,
        >> > we don't need to limit onchain to make Lightning more appealing.
        >>
        >> To be fair, I think making lightning (and coinjoins) work better is
        >> exactly what inspired this -- not as a "make on-chain worse so we look
        >> better in comparison", but as a "making lightning work well is a bunch
        >> of hard problems, here's the next thing we need in order to beat the
        >> next problem".
        >>
        >> > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
        >> > After interacting with users during high-fee periods I've come to not
        >> > appreciate RBF as a solution to that issue. Most users (80% or so)
        >> simply
        >> > don't have access to that functionality, because their wallet doesn't
        >> > support it, or they use a custodial (exchange) wallet etc. Of those that
        >> > have the feature - only the power users understand how RBF works, and
        >> > explaining how to do RBF to a non-power-user is just too complex, for
        >> the
        >> > same reason why it's complex for wallets to make sensible
        >> non-power-user UI
        >> > around it. Current equilibrium is that mostly only power users have
        >> access
        >> > to RBF and they know how to handle it, so things are somewhat working.
        >> But
        >> > rolling this out to the broad market is something else and would likely
        >> > cause more confusion.
        >> > CPFP is somewhat more viable but also not perfect as it would require
        >> lots
        >> > of edge case code to handle abuse vectors: What if users abuse a
        >> generous
        >> > CPFP policy to unstuck past transactions or consolidate large wallets.
        >> Best
        >> > is for CPFP to be done on the wallet side, not the merchant side, but
        >> there
        >> > too are the same UX issues as with RBF.
        >>
        >> I think if you're ruling out both merchants and users being able to add
        >> fees to a tx to get it to confirm, then you're going to lose either way.
        >> Txs will either expire because they've been stuck for more than a week,
        >> and be vulnerable to replacement at that point anyway, or they'll be
        >> dropped from mempools because they've filled up and they were the lowest
        >> fee tx, and be vulnerable to replacement for that reason. In the expiry
        >> case, the merchant can rebroadcast the original transaction to keep it
        >> alive, perhaps with a good chance of beating an attacker to the punch,
        >> but in the full mempool case, you could only do that if you were also
        >> CPFPing it, which you already ruled out.
        >>
        >> Cheers,
        >> aj
        >>
        >
        >
        > --
        >
        > Sergej Kotliar
        >
        > CEO
        >
        >
        > Twitter: @ziggamon <https://twitter.com/ziggamon>
        >
        >
        > www.bitrefill.com
        >
        > Twitter <https://www.twitter.com/bitrefill> | Blog
        > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >
        
        [-- Attachment #2: Type: text/html, Size: 22429 bytes --]
        
        ^ permalink raw reply	[flat|nested] 33+ messages in thread

      • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
            2022-10-20 14:14       ` Ruben Somsen
          @ 2022-10-20 14:17         ` Sergej Kotliar
            0 siblings, 0 replies; 33+ messages in thread
          From: Sergej Kotliar @ 2022-10-20 14:17 UTC (permalink / raw)
            To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion, Anthony Towns
          
          [-- Attachment #1: Type: text/plain, Size: 15075 bytes --]
          
          It's a good idea in theory, the issue is that most wallets and services
          bitcoin users use today to send bitcoin don't use solutions to that. So we
          end up with "you need to use X wallet to buy stuff", which is equivalent to
          "you need to use a Lightning wallet to buy stuff"
          
          On Thu, 20 Oct 2022 at 16:14, Ruben Somsen <rsomsen@gmail•com> wrote:
          
          > Hi,
          >
          > There is a reasonable tradeoff one can make to get eventual settlement
          > assurance prior to confirmation: lock up the funds with a counterparty in a
          > 2-of-2 multisig with a timelock back to the owner. As long as the timelock
          > has not expired and the recipients trust the counterparty not to sign
          > double spends, transactions that are spent from this multisig can be
          > considered instant. In cases where the counterparty and the recipient are
          > the same person, this solution is trustless. Since merchant purchases tend
          > to be low-value, the counterparty risk (facilitating double spends) seems
          > acceptable. GreenAddress provided such a service in 2015 or so, but the
          > idea got abandoned.
          >
          > Personally, I find this solution much more tenable than relying on
          > spurious network assumptions about what will be propagated and mined.
          >
          > Best regards,
          > Ruben
          >
          >
          >
          > On Thu, Oct 20, 2022 at 2:44 PM Sergej Kotliar via bitcoin-dev <
          > bitcoin-dev@lists•linuxfoundation.org> wrote:
          >
          >> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian•com.au> wrote:
          >>
          >>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
          >>> wrote:
          >>> > The
          >>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
          >>> > (it's actually quite easily managed),
          >>>
          >>> You mean "it's quite easily managed, provided the transaction doesn't
          >>> opt-in to rbf", right? At least, that's what I understood you saying last
          >>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
          >>> matter what other trustworthy signals you might see:
          >>>
          >>>   https://twitter.com/ziggamon/status/1435863691816275970
          >>>
          >>> (rbf txs seem to have increased from 22% then to 29% now)
          >>>
          >>
          >> Yeah. Our share of RBF is a bit lower than that as many RBF transactions
          >> are something other than consumer purchases, and most consumer purchases
          >> can't do RBF
          >>
          >>
          >>> > it's FX risk as the merchant must
          >>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
          >>> > some transactions lose money to FX and others earn money - that evens
          >>> out
          >>> > in the end.
          >>>
          >>> > But if there is an _easily accessible in the wallet_ feature to
          >>> > "cancel transaction" that means it will eventually get systematically
          >>> > abused. A risk of X% loss on many payments that's easy to
          >>> systematically
          >>> > abuse is more scary than a rare risk of losing 100% of one occasional
          >>> > payment. It's already possible to execute this form of abuse with
          >>> opt-in
          >>> > RBF,
          >>>
          >>> If someone's going to systematically exploit your store via this
          >>> mechanism, it seems like they'd just find a single wallet with a good
          >>> UX for opt-in RBF and lowballing fees, and go to town -- not something
          >>> where opt-in rbf vs fullrbf policies make any difference at all?
          >>>
          >>
          >> Sort of. But yes once this starts being abused systemically we will have
          >> to do something else w RBF payments, such as crediting the amount in BTC to
          >> a custodial account. But this option isn't available to your normal payment
          >> processor type business.
          >>
          >> Also worth keeping in mind that sometimes "opportunity makes the thief".
          >> Currently only power-user wallet have that feature and their market share
          >> is relatively small, mainly electrum stands out. But if this is available
          >> to all users everywhere then it will start being abused and we'll have to
          >> then direct all payments to custodial account, or some other convoluted
          >> solution.
          >>
          >>
          >>> It's not like existing wallets that don't let you set RBF will suddenly
          >>> get a good UX for replacing transactions just because they'd be relayed
          >>> if they did, is it?
          >>>
          >>> > To successfully fool (non-RBF)
          >>> > zeroconf one needs to have access to mining infrastructure and
          >>> probability
          >>> > of success is the % of hash rate controlled.
          >>>
          >>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
          >>> two conflicting txs in advance, one paying the merchant, one paying
          >>> yourself, connect to many peers, relay the one paying the merchant to
          >>> the merchant, and the other to everyone else.
          >>>
          >>> I'm just basing this off Peter Todd's stuff from years ago:
          >>>
          >>>
          >>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
          >>>
          >>>
          >>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
          >>>
          >>>
          >>
          >> Yeah, I know the list still rehashes a single incident from 10 years ago
          >> to declare the entire practice as unsafe, and ignores real-world data that
          >> of the last million transactions we had zero cases of this successfully
          >> abusing us.
          >>
          >>
          >>> > Currently Lightning is somewhere around 15% of our total bitcoin
          >>> payments.
          >>>
          >>> So, based on last year's numbers, presumably that makes your bitcoin
          >>> payments break down as something like:
          >>>
          >>>    5% txs are on-chain and seem shady and are excluded from zeroconf
          >>>   15% txs are lightning
          >>>   20% txs are on-chain but signal rbf and are excluded from zeroconf
          >>>   60% txs are on-chain and seem fine for zeroconf
          >>>
          >>
          >> Numbers are right. Shady is too strong a word, it's mostly transactions
          >> with very low fee, or high purchase amount, or many dependent unconfirmed
          >> transactions, stuff like that. In some cases we do a human assessment of
          >> the support ticket and often just pass them through.
          >>
          >>
          >>> > This is very much not nothing, and all of us here want Lightning to
          >>> grow,
          >>> > but I think it warrants a serious discussion on whether we want
          >>> Lightning
          >>> > adoption to go to 100% by means of disabling on-chain commerce.
          >>>
          >>> If the numbers above were accurate, this would just mean you'd go from
          >>> 60%
          >>> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
          >>>
          >>
          >> Point is that RBF transactions are unsafe even when waiting for a
          >> confirmation, which Peter Todd trivially proved in the reply next to this.
          >> The reliable solution is to reject all RBF payments and direct those users
          >> to custodial accounts. There are other variants to solve this with varying
          >> degree of convolutedness. RBF is a strictly worse UX as proven by anyone
          >> accepting bitcoin payments at scale.
          >>
          >>
          >>> > For me
          >>> > personally it would be an easier discussion to have when Lightning is
          >>> at
          >>> > 80%+ of all bitcoin transactions.
          >>>
          >>> Can you extrapolate from the numbers you've seen to estimate when that
          >>> might be, given current trends?
          >>>
          >>
          >> Not sure, it might be exponential growth, and the next 60% of Lightning
          >> growth happen faster than the first 15%. Hard to tell. But we're likely
          >> talking years here..
          >>
          >>
          >>>
          >>> > The benefits of Lightning are many and obvious,
          >>> > we don't need to limit onchain to make Lightning more appealing.
          >>>
          >>> To be fair, I think making lightning (and coinjoins) work better is
          >>> exactly what inspired this -- not as a "make on-chain worse so we look
          >>> better in comparison", but as a "making lightning work well is a bunch
          >>> of hard problems, here's the next thing we need in order to beat the
          >>> next problem".
          >>>
          >>
          >> In deed. The fact that the largest non-custodial Lightning wallet started
          >> this thread should be an indicator that despite these intentions the
          >> solution harms more than it fixes.
          >> Transactions being evicted from mempool is solved by requiring a minimum
          >> fee rate, which we do and now seems to have become a standard practice.
          >> Theoretically we can imagine them being evicted anyway but now we're
          >> several theoreticals deep again when discussing something that will cause
          >> massive problems right away. In emergency situations CPFP and similar can
          >> of course be done manually in special circumstances.
          >>
          >> Cheers
          >> Sergej
          >>
          >>
          >> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian•com.au> wrote:
          >>
          >>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
          >>> wrote:
          >>> > The
          >>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
          >>> > (it's actually quite easily managed),
          >>>
          >>> You mean "it's quite easily managed, provided the transaction doesn't
          >>> opt-in to rbf", right? At least, that's what I understood you saying last
          >>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
          >>> matter what other trustworthy signals you might see:
          >>>
          >>>   https://twitter.com/ziggamon/status/1435863691816275970
          >>>
          >>> (rbf txs seem to have increased from 22% then to 29% now)
          >>>
          >>> > it's FX risk as the merchant must
          >>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
          >>> > some transactions lose money to FX and others earn money - that evens
          >>> out
          >>> > in the end.
          >>>
          >>> > But if there is an _easily accessible in the wallet_ feature to
          >>> > "cancel transaction" that means it will eventually get systematically
          >>> > abused. A risk of X% loss on many payments that's easy to
          >>> systematically
          >>> > abuse is more scary than a rare risk of losing 100% of one occasional
          >>> > payment. It's already possible to execute this form of abuse with
          >>> opt-in
          >>> > RBF,
          >>>
          >>> If someone's going to systematically exploit your store via this
          >>> mechanism, it seems like they'd just find a single wallet with a good
          >>> UX for opt-in RBF and lowballing fees, and go to town -- not something
          >>> where opt-in rbf vs fullrbf policies make any difference at all?
          >>>
          >>> It's not like existing wallets that don't let you set RBF will suddenly
          >>> get a good UX for replacing transactions just because they'd be relayed
          >>> if they did, is it?
          >>>
          >>> > To successfully fool (non-RBF)
          >>> > zeroconf one needs to have access to mining infrastructure and
          >>> probability
          >>> > of success is the % of hash rate controlled.
          >>>
          >>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
          >>> two conflicting txs in advance, one paying the merchant, one paying
          >>> yourself, connect to many peers, relay the one paying the merchant to
          >>> the merchant, and the other to everyone else.
          >>>
          >>> I'm just basing this off Peter Todd's stuff from years ago:
          >>>
          >>>
          >>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
          >>>
          >>>
          >>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
          >>>
          >>> > Currently Lightning is somewhere around 15% of our total bitcoin
          >>> payments.
          >>>
          >>> So, based on last year's numbers, presumably that makes your bitcoin
          >>> payments break down as something like:
          >>>
          >>>    5% txs are on-chain and seem shady and are excluded from zeroconf
          >>>   15% txs are lightning
          >>>   20% txs are on-chain but signal rbf and are excluded from zeroconf
          >>>   60% txs are on-chain and seem fine for zeroconf
          >>>
          >>> > This is very much not nothing, and all of us here want Lightning to
          >>> grow,
          >>> > but I think it warrants a serious discussion on whether we want
          >>> Lightning
          >>> > adoption to go to 100% by means of disabling on-chain commerce.
          >>>
          >>> If the numbers above were accurate, this would just mean you'd go from
          >>> 60%
          >>> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
          >>>
          >>> > For me
          >>> > personally it would be an easier discussion to have when Lightning is
          >>> at
          >>> > 80%+ of all bitcoin transactions.
          >>>
          >>> Can you extrapolate from the numbers you've seen to estimate when that
          >>> might be, given current trends? Or perhaps when fine-for-zeroconf txs
          >>> drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
          >>> work the same in a fullrbf world.
          >>>
          >>> > The benefits of Lightning are many and obvious,
          >>> > we don't need to limit onchain to make Lightning more appealing.
          >>>
          >>> To be fair, I think making lightning (and coinjoins) work better is
          >>> exactly what inspired this -- not as a "make on-chain worse so we look
          >>> better in comparison", but as a "making lightning work well is a bunch
          >>> of hard problems, here's the next thing we need in order to beat the
          >>> next problem".
          >>>
          >>> > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
          >>> > After interacting with users during high-fee periods I've come to not
          >>> > appreciate RBF as a solution to that issue. Most users (80% or so)
          >>> simply
          >>> > don't have access to that functionality, because their wallet doesn't
          >>> > support it, or they use a custodial (exchange) wallet etc. Of those
          >>> that
          >>> > have the feature - only the power users understand how RBF works, and
          >>> > explaining how to do RBF to a non-power-user is just too complex, for
          >>> the
          >>> > same reason why it's complex for wallets to make sensible
          >>> non-power-user UI
          >>> > around it. Current equilibrium is that mostly only power users have
          >>> access
          >>> > to RBF and they know how to handle it, so things are somewhat working.
          >>> But
          >>> > rolling this out to the broad market is something else and would likely
          >>> > cause more confusion.
          >>> > CPFP is somewhat more viable but also not perfect as it would require
          >>> lots
          >>> > of edge case code to handle abuse vectors: What if users abuse a
          >>> generous
          >>> > CPFP policy to unstuck past transactions or consolidate large wallets.
          >>> Best
          >>> > is for CPFP to be done on the wallet side, not the merchant side, but
          >>> there
          >>> > too are the same UX issues as with RBF.
          >>>
          >>> I think if you're ruling out both merchants and users being able to add
          >>> fees to a tx to get it to confirm, then you're going to lose either way.
          >>> Txs will either expire because they've been stuck for more than a week,
          >>> and be vulnerable to replacement at that point anyway, or they'll be
          >>> dropped from mempools because they've filled up and they were the lowest
          >>> fee tx, and be vulnerable to replacement for that reason. In the expiry
          >>> case, the merchant can rebroadcast the original transaction to keep it
          >>> alive, perhaps with a good chance of beating an attacker to the punch,
          >>> but in the full mempool case, you could only do that if you were also
          >>> CPFPing it, which you already ruled out.
          >>>
          >>> Cheers,
          >>> aj
          >>>
          >>
          >>
          >> --
          >>
          >> Sergej Kotliar
          >>
          >> CEO
          >>
          >>
          >> Twitter: @ziggamon <https://twitter.com/ziggamon>
          >>
          >>
          >> www.bitrefill.com
          >>
          >> Twitter <https://www.twitter.com/bitrefill> | Blog
          >> <https://www.bitrefill.com/blog/> | Angellist
          >> <https://angel.co/bitrefill>
          >> _______________________________________________
          >> bitcoin-dev mailing list
          >> bitcoin-dev@lists•linuxfoundation.org
          >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >>
          >
          
          -- 
          
          Sergej Kotliar
          
          CEO
          
          
          Twitter: @ziggamon <https://twitter.com/ziggamon>
          
          
          www.bitrefill.com
          
          Twitter <https://www.twitter.com/bitrefill> | Blog
          <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
          
          [-- Attachment #2: Type: text/html, Size: 27215 bytes --]
          
          ^ permalink raw reply	[flat|nested] 33+ messages in thread

      • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
          2022-10-20 12:37     ` Sergej Kotliar
          2022-10-20 14:14       ` Ruben Somsen
        @ 2022-10-20 19:58       ` Anthony Towns
          2022-10-20 21:05         ` David A. Harding
                                   ` (3 more replies)
          2025-05-02 10:06       ` [bitcoindev] " Anthony Towns
          2 siblings, 4 replies; 33+ messages in thread
        From: Anthony Towns @ 2022-10-20 19:58 UTC (permalink / raw)
          To: Sergej Kotliar, Bitcoin Protocol Discussion
        
        On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
        > > If someone's going to systematically exploit your store via this
        > > mechanism, it seems like they'd just find a single wallet with a good
        > > UX for opt-in RBF and lowballing fees, and go to town -- not something
        > > where opt-in rbf vs fullrbf policies make any difference at all?
        > Sort of. But yes once this starts being abused systemically we will have to
        > do something else w RBF payments, such as crediting the amount in BTC to a
        > custodial account. But this option isn't available to your normal payment
        > processor type business.
        
        So, what I'm hearing is:
        
         * lightning works great, but is still pretty small
         * zeroconf works great for txs that opt-out of RBF
         * opt-in RBF is a pain for two reasons:
            - people don't like that it's not treated as zeroconf
            - the risk of fiat/BTC exchange rate changes between
              now and when the tx actually confirms is worrying
              even if it hasn't caused real problems yet
        
        (Please correct me if that's too far wrong)
        
        Maybe it would be productive to explore this opt-in RBF part a bit
        more? ie, see if "we" can come up with better answers to some question
        along the lines of:
        
         "how can we make on-chain payments for goods priced in fiat work well
          for payees that opt-in to RBF?"
        
        That seems like the sort of thing that's better solved by a collaboration
        between wallet devs and merchant devs (and protocol devs?), rather than
        just one or the other?
        
        Is that something that we could talk about here? Or maybe it's better
        done via an optech workgroup or something?
        
        If "we'll credit your account in BTC, then work out the USD coversion
        and deduct that for your purchase, then you can do whatever you like
        with any remaining BTC from your on-chain payment" is the idea, maybe we
        should just roll with that design, but make it more decentralised: have
        the initial payment setup a lightning channel between the customer and
        the merchant with the BTC (so it's not custodial), but do some magic to
        allow USD amounts to be transferred over it (Taro? something oracle based
        so that both parties are confident a fair exchange rate will be used?).
        
        Maybe that particular idea is naive, but having an actual problem to
        solve seems more constructive than just saying "we want rbf" "but we
        want zeroconf" all the time?
        
        (Ideally the lightning channels above would be dual funded so they could
        be used for routing more generally; but then dual funded channels are
        one of the things that get broken by lack of full rbf)
        
        > > I thought the "normal" avenue for fooling non-RBF zeroconf was to create
        > > two conflicting txs in advance, one paying the merchant, one paying
        > > yourself, connect to many peers, relay the one paying the merchant to
        > > the merchant, and the other to everyone else.
        > > I'm just basing this off Peter Todd's stuff from years ago:
        > > https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
        > > https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
        > Yeah, I know the list still rehashes a single incident from 10 years ago to
        > declare the entire practice as unsafe, and ignores real-world data that of
        > the last million transactions we had zero cases of this successfully
        > abusing us.
        
        I mean, the avenue above isn't easy to exploit -- you have to identify
        the merchant's node so that they get the bad tx, and you have to connect
        to many peers so that your preferred tx propogates to miners first --
        and probably more importantly, it's relatively easy to detect -- if the
        merchant has a few passive nodes that the attacker doesn't know about
        it, and uses those to watch for attempted doublespends while it tries
        to ensure the real tx has propogated widely. So it doesn't surprise me
        at all that it's not often attempted, and even less often successful.
        
        > > > Currently Lightning is somewhere around 15% of our total bitcoin
        > > > payments.
        > > So, based on last year's numbers, presumably that makes your bitcoin
        > > payments break down as something like:
        > >    5% txs are on-chain and seem shady and are excluded from zeroconf
        > >   15% txs are lightning
        > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
        > >   60% txs are on-chain and seem fine for zeroconf
        > Numbers are right. Shady is too strong a word,
        
        Heh, fair enough.
        
        So the above suggests 25% of payments already get a sub-par experience,
        compared to what you'd like them to have (which sucks, but if you're
        trying to reinvent both money and payments, maybe isn't surprising). And
        going full rbf would bump that from 25% to 85%, which would be pretty
        terrible.
        
        > RBF is a strictly worse UX as proven by anyone
        > accepting bitcoin payments at scale.
        
        So let's make it better? Building bitcoin businesses on the lie that
        unconfirmed txs are safe and won't be replaced is going to bite us
        eventually; focussing on trying to push that back indefinitely is just
        going to make everyone less prepared when it eventually happens.
        
        > > > For me
        > > > personally it would be an easier discussion to have when Lightning is at
        > > > 80%+ of all bitcoin transactions.
        > > Can you extrapolate from the numbers you've seen to estimate when that
        > > might be, given current trends?
        > Not sure, it might be exponential growth, and the next 60% of Lightning
        > growth happen faster than the first 15%. Hard to tell. But we're likely
        > talking years here..
        
        Okay? Two years is very different from 50 years, and at the moment there's
        not really any data, so people are just going to go with their gut...
        
        If it were growing in line with lightning capacity in BTC, per
        bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
        perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
        getting from 15% to 80% would then be about 8 years. 
        
        Presumably that's a laughably terrible model, of course. But if we had
        some actual numbers where we can watch the progress, it might be a lot
        easier to be patient about waiting for lightning adoption to hit 80%
        or whatever, and focus on productive things in the meantime?
        
        Cheers,
        aj
        
        
        ^ permalink raw reply	[flat|nested] 33+ messages in thread

      • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
            2022-10-20 19:58       ` Anthony Towns
          @ 2022-10-20 21:05         ` David A. Harding
            2022-10-20 21:07         ` Greg Sanders
                                     ` (2 subsequent siblings)
            3 siblings, 0 replies; 33+ messages in thread
          From: David A. Harding @ 2022-10-20 21:05 UTC (permalink / raw)
            To: Anthony Towns, Bitcoin Protocol Discussion; +Cc: Sergej Kotliar
          
          On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:
          > On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via 
          > bitcoin-dev wrote:
          >> AJ previously wrote:
          >> > presumably that makes your bitcoin
          >> > payments break down as something like:
          >> >    5% txs are on-chain and seem shady and are excluded from zeroconf
          >> >   15% txs are lightning
          >> >   20% txs are on-chain but signal rbf and are excluded from zeroconf
          >> >   60% txs are on-chain and seem fine for zeroconf
          >> Numbers are right. [...]
          > 
          > [...]
          > 
          > So the above suggests 25% of payments already get a sub-par experience 
          > [...]
          > going full rbf would bump that from 25% to 85%, which would be pretty
          > terrible.
          
          Is it worth considering incremental steps between opt-in only (BIP125) 
          and replace anything full RBF?  For example, in addition to opt-in RBF 
          rules, treat any transaction with a txid ending in `0x1` as replacable?  
          I assume 1/16th (6.25%) of transactions would match that pattern (some 
          of which already opt-in to RBF, so the net effect would be smaller).  
          This would have the following advantages:
          
          1. We could see if miners are willing to enable unsignaled RBF at all
          
          2. We could gather more evidence on how the change affects zeroconf 
          businesses and everyday users, hopefully without requiring they make 
          immediate and huge changes
          
          3. Any wallet authors that oppose unsignaled RBF can opt-out by grinding 
          their txids, at least until full RBF is accomplished
          
          4. We can increase the percentage of transactions subject to unsignaled 
          RBF in later releases of Bitcoin Core, steadily moving the system 
          towards full RBF without any sudden leaps (assuming nobody builds a 
          successful relay and mining network with less restrictive replacement 
          rules)
          
          I don't think this directly helps solve the problems with non-replacable 
          transactions suffered by contract protocols since any adversary can 
          opt-out of this scheme by grinding their txid, but I do think there's an 
          advantage in transitioning slowly when people are still depending on 
          previous behaviors.
          
          Thanks,
          
          -Dave
          
          
          ^ permalink raw reply	[flat|nested] 33+ messages in thread

        • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
            2022-10-20 19:58       ` Anthony Towns
            2022-10-20 21:05         ` David A. Harding
          @ 2022-10-20 21:07         ` Greg Sanders
            2022-10-20 22:02           ` Eloy
            2022-10-21 12:02           ` Sergej Kotliar
            2022-10-20 22:13         ` Peter Todd
            2022-10-21 11:56         ` Sergej Kotliar
            3 siblings, 2 replies; 33+ messages in thread
          From: Greg Sanders @ 2022-10-20 21:07 UTC (permalink / raw)
            To: Anthony Towns, Bitcoin Protocol Discussion; +Cc: Sergej Kotliar
          
          [-- Attachment #1: Type: text/plain, Size: 7410 bytes --]
          
          > If it were growing in line with lightning capacity in BTC, per
          bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
          perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
          getting from 15% to 80% would then be about 8 years.
          
          I'd caution against any metrics-based approach like this, unless it's
          simply used for ballparking potential adoption curves to set a a timeframe
          people can live with.
          
          A large number of coins/users sit on custodial rails and this would
          essentially encumber protocol developers to those KYC/AML institutions. If
          Binance decides to never support Lightning in favor of BNC-wrapped BTC,
          should this be an issue at all for reasoning about a path forward?
          
          Hoping to be wrong,
          Greg
          
          
          
          On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
          bitcoin-dev@lists•linuxfoundation.org> wrote:
          
          > On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
          > wrote:
          > > > If someone's going to systematically exploit your store via this
          > > > mechanism, it seems like they'd just find a single wallet with a good
          > > > UX for opt-in RBF and lowballing fees, and go to town -- not something
          > > > where opt-in rbf vs fullrbf policies make any difference at all?
          > > Sort of. But yes once this starts being abused systemically we will have
          > to
          > > do something else w RBF payments, such as crediting the amount in BTC to
          > a
          > > custodial account. But this option isn't available to your normal payment
          > > processor type business.
          >
          > So, what I'm hearing is:
          >
          >  * lightning works great, but is still pretty small
          >  * zeroconf works great for txs that opt-out of RBF
          >  * opt-in RBF is a pain for two reasons:
          >     - people don't like that it's not treated as zeroconf
          >     - the risk of fiat/BTC exchange rate changes between
          >       now and when the tx actually confirms is worrying
          >       even if it hasn't caused real problems yet
          >
          > (Please correct me if that's too far wrong)
          >
          > Maybe it would be productive to explore this opt-in RBF part a bit
          > more? ie, see if "we" can come up with better answers to some question
          > along the lines of:
          >
          >  "how can we make on-chain payments for goods priced in fiat work well
          >   for payees that opt-in to RBF?"
          >
          > That seems like the sort of thing that's better solved by a collaboration
          > between wallet devs and merchant devs (and protocol devs?), rather than
          > just one or the other?
          >
          > Is that something that we could talk about here? Or maybe it's better
          > done via an optech workgroup or something?
          >
          > If "we'll credit your account in BTC, then work out the USD coversion
          > and deduct that for your purchase, then you can do whatever you like
          > with any remaining BTC from your on-chain payment" is the idea, maybe we
          > should just roll with that design, but make it more decentralised: have
          > the initial payment setup a lightning channel between the customer and
          > the merchant with the BTC (so it's not custodial), but do some magic to
          > allow USD amounts to be transferred over it (Taro? something oracle based
          > so that both parties are confident a fair exchange rate will be used?).
          >
          > Maybe that particular idea is naive, but having an actual problem to
          > solve seems more constructive than just saying "we want rbf" "but we
          > want zeroconf" all the time?
          >
          > (Ideally the lightning channels above would be dual funded so they could
          > be used for routing more generally; but then dual funded channels are
          > one of the things that get broken by lack of full rbf)
          >
          > > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
          > create
          > > > two conflicting txs in advance, one paying the merchant, one paying
          > > > yourself, connect to many peers, relay the one paying the merchant to
          > > > the merchant, and the other to everyone else.
          > > > I'm just basing this off Peter Todd's stuff from years ago:
          > > >
          > https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
          > > >
          > https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
          > > Yeah, I know the list still rehashes a single incident from 10 years ago
          > to
          > > declare the entire practice as unsafe, and ignores real-world data that
          > of
          > > the last million transactions we had zero cases of this successfully
          > > abusing us.
          >
          > I mean, the avenue above isn't easy to exploit -- you have to identify
          > the merchant's node so that they get the bad tx, and you have to connect
          > to many peers so that your preferred tx propogates to miners first --
          > and probably more importantly, it's relatively easy to detect -- if the
          > merchant has a few passive nodes that the attacker doesn't know about
          > it, and uses those to watch for attempted doublespends while it tries
          > to ensure the real tx has propogated widely. So it doesn't surprise me
          > at all that it's not often attempted, and even less often successful.
          >
          > > > > Currently Lightning is somewhere around 15% of our total bitcoin
          > > > > payments.
          > > > So, based on last year's numbers, presumably that makes your bitcoin
          > > > payments break down as something like:
          > > >    5% txs are on-chain and seem shady and are excluded from zeroconf
          > > >   15% txs are lightning
          > > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
          > > >   60% txs are on-chain and seem fine for zeroconf
          > > Numbers are right. Shady is too strong a word,
          >
          > Heh, fair enough.
          >
          > So the above suggests 25% of payments already get a sub-par experience,
          > compared to what you'd like them to have (which sucks, but if you're
          > trying to reinvent both money and payments, maybe isn't surprising). And
          > going full rbf would bump that from 25% to 85%, which would be pretty
          > terrible.
          >
          > > RBF is a strictly worse UX as proven by anyone
          > > accepting bitcoin payments at scale.
          >
          > So let's make it better? Building bitcoin businesses on the lie that
          > unconfirmed txs are safe and won't be replaced is going to bite us
          > eventually; focussing on trying to push that back indefinitely is just
          > going to make everyone less prepared when it eventually happens.
          >
          > > > > For me
          > > > > personally it would be an easier discussion to have when Lightning
          > is at
          > > > > 80%+ of all bitcoin transactions.
          > > > Can you extrapolate from the numbers you've seen to estimate when that
          > > > might be, given current trends?
          > > Not sure, it might be exponential growth, and the next 60% of Lightning
          > > growth happen faster than the first 15%. Hard to tell. But we're likely
          > > talking years here..
          >
          > Okay? Two years is very different from 50 years, and at the moment there's
          > not really any data, so people are just going to go with their gut...
          >
          > If it were growing in line with lightning capacity in BTC, per
          > bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
          > perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
          > getting from 15% to 80% would then be about 8 years.
          >
          > Presumably that's a laughably terrible model, of course. But if we had
          > some actual numbers where we can watch the progress, it might be a lot
          > easier to be patient about waiting for lightning adoption to hit 80%
          > or whatever, and focus on productive things in the meantime?
          >
          > Cheers,
          > aj
          > _______________________________________________
          > bitcoin-dev mailing list
          > bitcoin-dev@lists•linuxfoundation.org
          > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >
          
          [-- Attachment #2: Type: text/html, Size: 9259 bytes --]
          
          ^ permalink raw reply	[flat|nested] 33+ messages in thread

        • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
              2022-10-20 21:07         ` Greg Sanders
            @ 2022-10-20 22:02           ` Eloy
              2022-10-21 12:02           ` Sergej Kotliar
              1 sibling, 0 replies; 33+ messages in thread
            From: Eloy @ 2022-10-20 22:02 UTC (permalink / raw)
              To: Bitcoin Protocol Discussion
            
            [-- Attachment #1: Type: text/plain, Size: 8691 bytes --]
            
            There is obviously an alternative approach to the issue.
            
            If we like opt-in RBF and would like to keep opt out RBF 0CONF working, we could add another option to punish those nodes that replace transactions. That is, a miner that publishes a block with a NO RBF, that is replaced (that is easy to check for a full node) could stop propagation of that block (so it have less chances to win). That would make the network decide when it is the time to deploy RBF.
            
            It seems obvious for me that most devs prefer full RBF to force users to use centralized stuff (that is why the full RBF option is there already on core), but just wanted to make that clear that there is always a way to enforce a policy (read to keep zero conf working).
            
            Regards.
            
            El 20 de octubre de 2022 18:07:07 ART, Greg Sanders via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> escribió:
            >> If it were growing in line with lightning capacity in BTC, per
            >bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
            >perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
            >getting from 15% to 80% would then be about 8 years.
            >
            >I'd caution against any metrics-based approach like this, unless it's
            >simply used for ballparking potential adoption curves to set a a timeframe
            >people can live with.
            >
            >A large number of coins/users sit on custodial rails and this would
            >essentially encumber protocol developers to those KYC/AML institutions. If
            >Binance decides to never support Lightning in favor of BNC-wrapped BTC,
            >should this be an issue at all for reasoning about a path forward?
            >
            >Hoping to be wrong,
            >Greg
            >
            >
            >
            >On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
            >bitcoin-dev@lists•linuxfoundation.org> wrote:
            >
            >> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
            >> wrote:
            >> > > If someone's going to systematically exploit your store via this
            >> > > mechanism, it seems like they'd just find a single wallet with a good
            >> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
            >> > > where opt-in rbf vs fullrbf policies make any difference at all?
            >> > Sort of. But yes once this starts being abused systemically we will have
            >> to
            >> > do something else w RBF payments, such as crediting the amount in BTC to
            >> a
            >> > custodial account. But this option isn't available to your normal payment
            >> > processor type business.
            >>
            >> So, what I'm hearing is:
            >>
            >>  * lightning works great, but is still pretty small
            >>  * zeroconf works great for txs that opt-out of RBF
            >>  * opt-in RBF is a pain for two reasons:
            >>     - people don't like that it's not treated as zeroconf
            >>     - the risk of fiat/BTC exchange rate changes between
            >>       now and when the tx actually confirms is worrying
            >>       even if it hasn't caused real problems yet
            >>
            >> (Please correct me if that's too far wrong)
            >>
            >> Maybe it would be productive to explore this opt-in RBF part a bit
            >> more? ie, see if "we" can come up with better answers to some question
            >> along the lines of:
            >>
            >>  "how can we make on-chain payments for goods priced in fiat work well
            >>   for payees that opt-in to RBF?"
            >>
            >> That seems like the sort of thing that's better solved by a collaboration
            >> between wallet devs and merchant devs (and protocol devs?), rather than
            >> just one or the other?
            >>
            >> Is that something that we could talk about here? Or maybe it's better
            >> done via an optech workgroup or something?
            >>
            >> If "we'll credit your account in BTC, then work out the USD coversion
            >> and deduct that for your purchase, then you can do whatever you like
            >> with any remaining BTC from your on-chain payment" is the idea, maybe we
            >> should just roll with that design, but make it more decentralised: have
            >> the initial payment setup a lightning channel between the customer and
            >> the merchant with the BTC (so it's not custodial), but do some magic to
            >> allow USD amounts to be transferred over it (Taro? something oracle based
            >> so that both parties are confident a fair exchange rate will be used?).
            >>
            >> Maybe that particular idea is naive, but having an actual problem to
            >> solve seems more constructive than just saying "we want rbf" "but we
            >> want zeroconf" all the time?
            >>
            >> (Ideally the lightning channels above would be dual funded so they could
            >> be used for routing more generally; but then dual funded channels are
            >> one of the things that get broken by lack of full rbf)
            >>
            >> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
            >> create
            >> > > two conflicting txs in advance, one paying the merchant, one paying
            >> > > yourself, connect to many peers, relay the one paying the merchant to
            >> > > the merchant, and the other to everyone else.
            >> > > I'm just basing this off Peter Todd's stuff from years ago:
            >> > >
            >> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
            >> > >
            >> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
            >> > Yeah, I know the list still rehashes a single incident from 10 years ago
            >> to
            >> > declare the entire practice as unsafe, and ignores real-world data that
            >> of
            >> > the last million transactions we had zero cases of this successfully
            >> > abusing us.
            >>
            >> I mean, the avenue above isn't easy to exploit -- you have to identify
            >> the merchant's node so that they get the bad tx, and you have to connect
            >> to many peers so that your preferred tx propogates to miners first --
            >> and probably more importantly, it's relatively easy to detect -- if the
            >> merchant has a few passive nodes that the attacker doesn't know about
            >> it, and uses those to watch for attempted doublespends while it tries
            >> to ensure the real tx has propogated widely. So it doesn't surprise me
            >> at all that it's not often attempted, and even less often successful.
            >>
            >> > > > Currently Lightning is somewhere around 15% of our total bitcoin
            >> > > > payments.
            >> > > So, based on last year's numbers, presumably that makes your bitcoin
            >> > > payments break down as something like:
            >> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
            >> > >   15% txs are lightning
            >> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
            >> > >   60% txs are on-chain and seem fine for zeroconf
            >> > Numbers are right. Shady is too strong a word,
            >>
            >> Heh, fair enough.
            >>
            >> So the above suggests 25% of payments already get a sub-par experience,
            >> compared to what you'd like them to have (which sucks, but if you're
            >> trying to reinvent both money and payments, maybe isn't surprising). And
            >> going full rbf would bump that from 25% to 85%, which would be pretty
            >> terrible.
            >>
            >> > RBF is a strictly worse UX as proven by anyone
            >> > accepting bitcoin payments at scale.
            >>
            >> So let's make it better? Building bitcoin businesses on the lie that
            >> unconfirmed txs are safe and won't be replaced is going to bite us
            >> eventually; focussing on trying to push that back indefinitely is just
            >> going to make everyone less prepared when it eventually happens.
            >>
            >> > > > For me
            >> > > > personally it would be an easier discussion to have when Lightning
            >> is at
            >> > > > 80%+ of all bitcoin transactions.
            >> > > Can you extrapolate from the numbers you've seen to estimate when that
            >> > > might be, given current trends?
            >> > Not sure, it might be exponential growth, and the next 60% of Lightning
            >> > growth happen faster than the first 15%. Hard to tell. But we're likely
            >> > talking years here..
            >>
            >> Okay? Two years is very different from 50 years, and at the moment there's
            >> not really any data, so people are just going to go with their gut...
            >>
            >> If it were growing in line with lightning capacity in BTC, per
            >> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
            >> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
            >> getting from 15% to 80% would then be about 8 years.
            >>
            >> Presumably that's a laughably terrible model, of course. But if we had
            >> some actual numbers where we can watch the progress, it might be a lot
            >> easier to be patient about waiting for lightning adoption to hit 80%
            >> or whatever, and focus on productive things in the meantime?
            >>
            >> Cheers,
            >> aj
            >> _______________________________________________
            >> bitcoin-dev mailing list
            >> bitcoin-dev@lists•linuxfoundation.org
            >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
            >>
            
            -- 
            Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
            
            [-- Attachment #2: Type: text/html, Size: 10439 bytes --]
            
            ^ permalink raw reply	[flat|nested] 33+ messages in thread

          • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
              2022-10-20 21:07         ` Greg Sanders
              2022-10-20 22:02           ` Eloy
            @ 2022-10-21 12:02           ` Sergej Kotliar
              2022-10-21 14:01             ` Greg Sanders
              2022-10-21 19:43             ` Peter Todd
              1 sibling, 2 replies; 33+ messages in thread
            From: Sergej Kotliar @ 2022-10-21 12:02 UTC (permalink / raw)
              To: Greg Sanders; +Cc: Bitcoin Protocol Discussion, Anthony Towns
            
            [-- Attachment #1: Type: text/plain, Size: 8602 bytes --]
            
            On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail•com> wrote:
            
            > A large number of coins/users sit on custodial rails and this would
            > essentially encumber protocol developers to those KYC/AML institutions. If
            > Binance decides to never support Lightning in favor of BNC-wrapped BTC,
            > should this be an issue at all for reasoning about a path forward?
            >
            
            This is a big question here, with the caveat that it's not just binance but
            in fact the majority of wallets and services that people use with bitcoin
            today.
            But the question remains as you phrased: At which point do we break
            backwards compatibility? Another analogy would be to have sunset the old
            P2PKH addresses during rollout of Segwit - it would certainly have led to
            Segwit getting rolled out faster. The rbf change actually breaks more
            things than that, takes more effort to address than just implementing a new
            address format. Previously in the Bitcoin Core process we've chosen to keep
            backwards compatibility and only roll out opt-in changes with broad
            consensus over them, with the default behavior being to not roll out
            changes that are controversial. At which point it's time to back away from
            that - I honestly don't know. There is probably such a point, and we should
            maybe have some kind of discussion around that topic on a higher level,
            just as you phrased it, and I'll paraphrase:
            If a majority of bitcoin wallets and services continue using legacy
            patterns and features, preventing progress, at which point do we want to
            break compatibility with them?
            
            Best,
            Sergej
            
            
            On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
            > bitcoin-dev@lists•linuxfoundation.org> wrote:
            >
            >> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
            >> wrote:
            >> > > If someone's going to systematically exploit your store via this
            >> > > mechanism, it seems like they'd just find a single wallet with a good
            >> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
            >> > > where opt-in rbf vs fullrbf policies make any difference at all?
            >> > Sort of. But yes once this starts being abused systemically we will
            >> have to
            >> > do something else w RBF payments, such as crediting the amount in BTC
            >> to a
            >> > custodial account. But this option isn't available to your normal
            >> payment
            >> > processor type business.
            >>
            >> So, what I'm hearing is:
            >>
            >>  * lightning works great, but is still pretty small
            >>  * zeroconf works great for txs that opt-out of RBF
            >>  * opt-in RBF is a pain for two reasons:
            >>     - people don't like that it's not treated as zeroconf
            >>     - the risk of fiat/BTC exchange rate changes between
            >>       now and when the tx actually confirms is worrying
            >>       even if it hasn't caused real problems yet
            >>
            >> (Please correct me if that's too far wrong)
            >>
            >> Maybe it would be productive to explore this opt-in RBF part a bit
            >> more? ie, see if "we" can come up with better answers to some question
            >> along the lines of:
            >>
            >>  "how can we make on-chain payments for goods priced in fiat work well
            >>   for payees that opt-in to RBF?"
            >>
            >> That seems like the sort of thing that's better solved by a collaboration
            >> between wallet devs and merchant devs (and protocol devs?), rather than
            >> just one or the other?
            >>
            >> Is that something that we could talk about here? Or maybe it's better
            >> done via an optech workgroup or something?
            >>
            >> If "we'll credit your account in BTC, then work out the USD coversion
            >> and deduct that for your purchase, then you can do whatever you like
            >> with any remaining BTC from your on-chain payment" is the idea, maybe we
            >> should just roll with that design, but make it more decentralised: have
            >> the initial payment setup a lightning channel between the customer and
            >> the merchant with the BTC (so it's not custodial), but do some magic to
            >> allow USD amounts to be transferred over it (Taro? something oracle based
            >> so that both parties are confident a fair exchange rate will be used?).
            >>
            >> Maybe that particular idea is naive, but having an actual problem to
            >> solve seems more constructive than just saying "we want rbf" "but we
            >> want zeroconf" all the time?
            >>
            >> (Ideally the lightning channels above would be dual funded so they could
            >> be used for routing more generally; but then dual funded channels are
            >> one of the things that get broken by lack of full rbf)
            >>
            >> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
            >> create
            >> > > two conflicting txs in advance, one paying the merchant, one paying
            >> > > yourself, connect to many peers, relay the one paying the merchant to
            >> > > the merchant, and the other to everyone else.
            >> > > I'm just basing this off Peter Todd's stuff from years ago:
            >> > >
            >> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
            >> > >
            >> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
            >> > Yeah, I know the list still rehashes a single incident from 10 years
            >> ago to
            >> > declare the entire practice as unsafe, and ignores real-world data that
            >> of
            >> > the last million transactions we had zero cases of this successfully
            >> > abusing us.
            >>
            >> I mean, the avenue above isn't easy to exploit -- you have to identify
            >> the merchant's node so that they get the bad tx, and you have to connect
            >> to many peers so that your preferred tx propogates to miners first --
            >> and probably more importantly, it's relatively easy to detect -- if the
            >> merchant has a few passive nodes that the attacker doesn't know about
            >> it, and uses those to watch for attempted doublespends while it tries
            >> to ensure the real tx has propogated widely. So it doesn't surprise me
            >> at all that it's not often attempted, and even less often successful.
            >>
            >> > > > Currently Lightning is somewhere around 15% of our total bitcoin
            >> > > > payments.
            >> > > So, based on last year's numbers, presumably that makes your bitcoin
            >> > > payments break down as something like:
            >> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
            >> > >   15% txs are lightning
            >> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
            >> > >   60% txs are on-chain and seem fine for zeroconf
            >> > Numbers are right. Shady is too strong a word,
            >>
            >> Heh, fair enough.
            >>
            >> So the above suggests 25% of payments already get a sub-par experience,
            >> compared to what you'd like them to have (which sucks, but if you're
            >> trying to reinvent both money and payments, maybe isn't surprising). And
            >> going full rbf would bump that from 25% to 85%, which would be pretty
            >> terrible.
            >>
            >> > RBF is a strictly worse UX as proven by anyone
            >> > accepting bitcoin payments at scale.
            >>
            >> So let's make it better? Building bitcoin businesses on the lie that
            >> unconfirmed txs are safe and won't be replaced is going to bite us
            >> eventually; focussing on trying to push that back indefinitely is just
            >> going to make everyone less prepared when it eventually happens.
            >>
            >> > > > For me
            >> > > > personally it would be an easier discussion to have when Lightning
            >> is at
            >> > > > 80%+ of all bitcoin transactions.
            >> > > Can you extrapolate from the numbers you've seen to estimate when that
            >> > > might be, given current trends?
            >> > Not sure, it might be exponential growth, and the next 60% of Lightning
            >> > growth happen faster than the first 15%. Hard to tell. But we're likely
            >> > talking years here..
            >>
            >> Okay? Two years is very different from 50 years, and at the moment there's
            >> not really any data, so people are just going to go with their gut...
            >>
            >> If it were growing in line with lightning capacity in BTC, per
            >> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
            >> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
            >> getting from 15% to 80% would then be about 8 years.
            >>
            >> Presumably that's a laughably terrible model, of course. But if we had
            >> some actual numbers where we can watch the progress, it might be a lot
            >> easier to be patient about waiting for lightning adoption to hit 80%
            >> or whatever, and focus on productive things in the meantime?
            >>
            >> Cheers,
            >> aj
            >> _______________________________________________
            >> bitcoin-dev mailing list
            >> bitcoin-dev@lists•linuxfoundation.org
            >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
            >>
            >
            
            -- 
            
            Sergej Kotliar
            
            CEO
            
            
            Twitter: @ziggamon <https://twitter.com/ziggamon>
            
            
            www.bitrefill.com
            
            Twitter <https://www.twitter.com/bitrefill> | Blog
            <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
            
            [-- Attachment #2: Type: text/html, Size: 14493 bytes --]
            
            ^ permalink raw reply	[flat|nested] 33+ messages in thread

          • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
                2022-10-21 12:02           ` Sergej Kotliar
              @ 2022-10-21 14:01             ` Greg Sanders
                2022-10-21 14:19               ` Sergej Kotliar
                2022-10-21 19:43             ` Peter Todd
                1 sibling, 1 reply; 33+ messages in thread
              From: Greg Sanders @ 2022-10-21 14:01 UTC (permalink / raw)
                To: Sergej Kotliar; +Cc: Bitcoin Protocol Discussion, Anthony Towns
              
              [-- Attachment #1: Type: text/plain, Size: 10040 bytes --]
              
              Full-rbf is an odd duck, because while it is not a consensus issue, it does
              affect a large % of transactions made by wallets already, contrary to most
              policy changes. We have a status quo that is understandable, but
              unfortunately long-term incentive incompatible.
              
              It's also a UX issue, not a safety issue for retail wallet users(except
              Muun, who have given a clear timeline). Clearly considerations would be
              very different otherwise, but retail wallets by and large do not consider
              0-conf as a valid deposit, or at least put up some warning symbols to that
              effect.
              
              Can only speak for myself, but I am looking for a concrete timeframe from
              0-conf stakeholders. I have no preference for any particular time frame, as
              long as it can be agreed upon in the near-ish future. This keeps the
              transition technically speaking very simple, and removes uncertainty from
              decision making going forward.
              
              To make a follow-on consensus analogy, I am in the BIP8
              lock-on-timeout=true camp for full rbf. If metrics arise that shows we're
              ready early, great. If not, I still want to avoid having this discussion
              again in N+ years.
              
              Cheers,
              Greg
              
              On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar <sergej@bitrefill•com> wrote:
              
              > On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail•com> wrote:
              >
              >> A large number of coins/users sit on custodial rails and this would
              >> essentially encumber protocol developers to those KYC/AML institutions. If
              >> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
              >> should this be an issue at all for reasoning about a path forward?
              >>
              >
              > This is a big question here, with the caveat that it's not just binance
              > but in fact the majority of wallets and services that people use with
              > bitcoin today.
              > But the question remains as you phrased: At which point do we break
              > backwards compatibility? Another analogy would be to have sunset the old
              > P2PKH addresses during rollout of Segwit - it would certainly have led to
              > Segwit getting rolled out faster. The rbf change actually breaks more
              > things than that, takes more effort to address than just implementing a new
              > address format. Previously in the Bitcoin Core process we've chosen to keep
              > backwards compatibility and only roll out opt-in changes with broad
              > consensus over them, with the default behavior being to not roll out
              > changes that are controversial. At which point it's time to back away from
              > that - I honestly don't know. There is probably such a point, and we should
              > maybe have some kind of discussion around that topic on a higher level,
              > just as you phrased it, and I'll paraphrase:
              > If a majority of bitcoin wallets and services continue using legacy
              > patterns and features, preventing progress, at which point do we want to
              > break compatibility with them?
              >
              > Best,
              > Sergej
              >
              >
              > On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
              >> bitcoin-dev@lists•linuxfoundation.org> wrote:
              >>
              >>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
              >>> wrote:
              >>> > > If someone's going to systematically exploit your store via this
              >>> > > mechanism, it seems like they'd just find a single wallet with a good
              >>> > > UX for opt-in RBF and lowballing fees, and go to town -- not
              >>> something
              >>> > > where opt-in rbf vs fullrbf policies make any difference at all?
              >>> > Sort of. But yes once this starts being abused systemically we will
              >>> have to
              >>> > do something else w RBF payments, such as crediting the amount in BTC
              >>> to a
              >>> > custodial account. But this option isn't available to your normal
              >>> payment
              >>> > processor type business.
              >>>
              >>> So, what I'm hearing is:
              >>>
              >>>  * lightning works great, but is still pretty small
              >>>  * zeroconf works great for txs that opt-out of RBF
              >>>  * opt-in RBF is a pain for two reasons:
              >>>     - people don't like that it's not treated as zeroconf
              >>>     - the risk of fiat/BTC exchange rate changes between
              >>>       now and when the tx actually confirms is worrying
              >>>       even if it hasn't caused real problems yet
              >>>
              >>> (Please correct me if that's too far wrong)
              >>>
              >>> Maybe it would be productive to explore this opt-in RBF part a bit
              >>> more? ie, see if "we" can come up with better answers to some question
              >>> along the lines of:
              >>>
              >>>  "how can we make on-chain payments for goods priced in fiat work well
              >>>   for payees that opt-in to RBF?"
              >>>
              >>> That seems like the sort of thing that's better solved by a collaboration
              >>> between wallet devs and merchant devs (and protocol devs?), rather than
              >>> just one or the other?
              >>>
              >>> Is that something that we could talk about here? Or maybe it's better
              >>> done via an optech workgroup or something?
              >>>
              >>> If "we'll credit your account in BTC, then work out the USD coversion
              >>> and deduct that for your purchase, then you can do whatever you like
              >>> with any remaining BTC from your on-chain payment" is the idea, maybe we
              >>> should just roll with that design, but make it more decentralised: have
              >>> the initial payment setup a lightning channel between the customer and
              >>> the merchant with the BTC (so it's not custodial), but do some magic to
              >>> allow USD amounts to be transferred over it (Taro? something oracle based
              >>> so that both parties are confident a fair exchange rate will be used?).
              >>>
              >>> Maybe that particular idea is naive, but having an actual problem to
              >>> solve seems more constructive than just saying "we want rbf" "but we
              >>> want zeroconf" all the time?
              >>>
              >>> (Ideally the lightning channels above would be dual funded so they could
              >>> be used for routing more generally; but then dual funded channels are
              >>> one of the things that get broken by lack of full rbf)
              >>>
              >>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
              >>> create
              >>> > > two conflicting txs in advance, one paying the merchant, one paying
              >>> > > yourself, connect to many peers, relay the one paying the merchant to
              >>> > > the merchant, and the other to everyone else.
              >>> > > I'm just basing this off Peter Todd's stuff from years ago:
              >>> > >
              >>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
              >>> > >
              >>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
              >>> > Yeah, I know the list still rehashes a single incident from 10 years
              >>> ago to
              >>> > declare the entire practice as unsafe, and ignores real-world data
              >>> that of
              >>> > the last million transactions we had zero cases of this successfully
              >>> > abusing us.
              >>>
              >>> I mean, the avenue above isn't easy to exploit -- you have to identify
              >>> the merchant's node so that they get the bad tx, and you have to connect
              >>> to many peers so that your preferred tx propogates to miners first --
              >>> and probably more importantly, it's relatively easy to detect -- if the
              >>> merchant has a few passive nodes that the attacker doesn't know about
              >>> it, and uses those to watch for attempted doublespends while it tries
              >>> to ensure the real tx has propogated widely. So it doesn't surprise me
              >>> at all that it's not often attempted, and even less often successful.
              >>>
              >>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
              >>> > > > payments.
              >>> > > So, based on last year's numbers, presumably that makes your bitcoin
              >>> > > payments break down as something like:
              >>> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
              >>> > >   15% txs are lightning
              >>> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
              >>> > >   60% txs are on-chain and seem fine for zeroconf
              >>> > Numbers are right. Shady is too strong a word,
              >>>
              >>> Heh, fair enough.
              >>>
              >>> So the above suggests 25% of payments already get a sub-par experience,
              >>> compared to what you'd like them to have (which sucks, but if you're
              >>> trying to reinvent both money and payments, maybe isn't surprising). And
              >>> going full rbf would bump that from 25% to 85%, which would be pretty
              >>> terrible.
              >>>
              >>> > RBF is a strictly worse UX as proven by anyone
              >>> > accepting bitcoin payments at scale.
              >>>
              >>> So let's make it better? Building bitcoin businesses on the lie that
              >>> unconfirmed txs are safe and won't be replaced is going to bite us
              >>> eventually; focussing on trying to push that back indefinitely is just
              >>> going to make everyone less prepared when it eventually happens.
              >>>
              >>> > > > For me
              >>> > > > personally it would be an easier discussion to have when Lightning
              >>> is at
              >>> > > > 80%+ of all bitcoin transactions.
              >>> > > Can you extrapolate from the numbers you've seen to estimate when
              >>> that
              >>> > > might be, given current trends?
              >>> > Not sure, it might be exponential growth, and the next 60% of Lightning
              >>> > growth happen faster than the first 15%. Hard to tell. But we're likely
              >>> > talking years here..
              >>>
              >>> Okay? Two years is very different from 50 years, and at the moment
              >>> there's
              >>> not really any data, so people are just going to go with their gut...
              >>>
              >>> If it were growing in line with lightning capacity in BTC, per
              >>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
              >>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
              >>> getting from 15% to 80% would then be about 8 years.
              >>>
              >>> Presumably that's a laughably terrible model, of course. But if we had
              >>> some actual numbers where we can watch the progress, it might be a lot
              >>> easier to be patient about waiting for lightning adoption to hit 80%
              >>> or whatever, and focus on productive things in the meantime?
              >>>
              >>> Cheers,
              >>> aj
              >>> _______________________________________________
              >>> bitcoin-dev mailing list
              >>> bitcoin-dev@lists•linuxfoundation.org
              >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
              >>>
              >>
              >
              > --
              >
              > Sergej Kotliar
              >
              > CEO
              >
              >
              > Twitter: @ziggamon <https://twitter.com/ziggamon>
              >
              >
              > www.bitrefill.com
              >
              > Twitter <https://www.twitter.com/bitrefill> | Blog
              > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
              >
              
              [-- Attachment #2: Type: text/html, Size: 16094 bytes --]
              
              ^ permalink raw reply	[flat|nested] 33+ messages in thread

            • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
                  2022-10-21 14:01             ` Greg Sanders
                @ 2022-10-21 14:19               ` Sergej Kotliar
                  2022-10-21 14:47                 ` Greg Sanders
                  0 siblings, 1 reply; 33+ messages in thread
                From: Sergej Kotliar @ 2022-10-21 14:19 UTC (permalink / raw)
                  To: Greg Sanders; +Cc: Bitcoin Protocol Discussion, Anthony Towns
                
                [-- Attachment #1: Type: text/plain, Size: 11444 bytes --]
                
                On Fri, 21 Oct 2022 at 16:01, Greg Sanders <gsanders87@gmail•com> wrote:
                
                > Full-rbf is an odd duck, because while it is not a consensus issue, it
                > does affect a large % of transactions made by wallets already, contrary to
                > most policy changes.
                >
                
                Yeah, there are several policy features that are not consensus related but
                end up de facto setting rules for how bitcoin behaves. Minrelayfee being
                another, and probably other examples out there that I don't know of.
                
                
                > It's also a UX issue, not a safety issue for retail wallet users(except
                > Muun, who have given a clear timeline). Clearly considerations would be
                > very different otherwise, but retail wallets by and large do not consider
                > 0-conf as a valid deposit, or at least put up some warning symbols to that
                > effect.
                >
                > Can only speak for myself, but I am looking for a concrete timeframe from
                > 0-conf stakeholders. I have no preference for any particular time frame, as
                > long as it can be agreed upon in the near-ish future. This keeps the
                > transition technically speaking very simple, and removes uncertainty from
                > decision making going forward.
                >
                
                It's hard to give a timeframe because it's not clear what the path forward
                for these stakeholders is. Most of what I've heard in this channel is
                things like "just use Lightning" but that's contradicted by user data. So
                the action becomes "stop accepting payments onchain" which isn't really a
                timeframe type issue, it will hurt whenever it happens. Maybe a thorough
                discussion for a way forward would be useful here. Jeremy Rubin suggested
                an interesting idea for using CPFP to force a transaction to complete.
                We'll evaluate it and see if it works in the wild for zero-conf of RBF
                today and report findings, need to evaluate from several angles first
                incentives-wise. There might also be other solutions.
                
                I'd also ask if there might also be other solutions for solving the pinning
                issue as well if we dig deep into it? Perhaps there are those with
                tradeoffs, but those tradeoffs being less significant than the tradeoffs of
                rbf policy?
                
                
                Best,
                Sergej
                
                >
                > On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar <sergej@bitrefill•com>
                > wrote:
                >
                >> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail•com> wrote:
                >>
                >>> A large number of coins/users sit on custodial rails and this would
                >>> essentially encumber protocol developers to those KYC/AML institutions. If
                >>> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
                >>> should this be an issue at all for reasoning about a path forward?
                >>>
                >>
                >> This is a big question here, with the caveat that it's not just binance
                >> but in fact the majority of wallets and services that people use with
                >> bitcoin today.
                >> But the question remains as you phrased: At which point do we break
                >> backwards compatibility? Another analogy would be to have sunset the old
                >> P2PKH addresses during rollout of Segwit - it would certainly have led to
                >> Segwit getting rolled out faster. The rbf change actually breaks more
                >> things than that, takes more effort to address than just implementing a new
                >> address format. Previously in the Bitcoin Core process we've chosen to keep
                >> backwards compatibility and only roll out opt-in changes with broad
                >> consensus over them, with the default behavior being to not roll out
                >> changes that are controversial. At which point it's time to back away from
                >> that - I honestly don't know. There is probably such a point, and we should
                >> maybe have some kind of discussion around that topic on a higher level,
                >> just as you phrased it, and I'll paraphrase:
                >> If a majority of bitcoin wallets and services continue using legacy
                >> patterns and features, preventing progress, at which point do we want to
                >> break compatibility with them?
                >>
                >> Best,
                >> Sergej
                >>
                >>
                >> On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
                >>> bitcoin-dev@lists•linuxfoundation.org> wrote:
                >>>
                >>>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
                >>>> bitcoin-dev wrote:
                >>>> > > If someone's going to systematically exploit your store via this
                >>>> > > mechanism, it seems like they'd just find a single wallet with a
                >>>> good
                >>>> > > UX for opt-in RBF and lowballing fees, and go to town -- not
                >>>> something
                >>>> > > where opt-in rbf vs fullrbf policies make any difference at all?
                >>>> > Sort of. But yes once this starts being abused systemically we will
                >>>> have to
                >>>> > do something else w RBF payments, such as crediting the amount in BTC
                >>>> to a
                >>>> > custodial account. But this option isn't available to your normal
                >>>> payment
                >>>> > processor type business.
                >>>>
                >>>> So, what I'm hearing is:
                >>>>
                >>>>  * lightning works great, but is still pretty small
                >>>>  * zeroconf works great for txs that opt-out of RBF
                >>>>  * opt-in RBF is a pain for two reasons:
                >>>>     - people don't like that it's not treated as zeroconf
                >>>>     - the risk of fiat/BTC exchange rate changes between
                >>>>       now and when the tx actually confirms is worrying
                >>>>       even if it hasn't caused real problems yet
                >>>>
                >>>> (Please correct me if that's too far wrong)
                >>>>
                >>>> Maybe it would be productive to explore this opt-in RBF part a bit
                >>>> more? ie, see if "we" can come up with better answers to some question
                >>>> along the lines of:
                >>>>
                >>>>  "how can we make on-chain payments for goods priced in fiat work well
                >>>>   for payees that opt-in to RBF?"
                >>>>
                >>>> That seems like the sort of thing that's better solved by a
                >>>> collaboration
                >>>> between wallet devs and merchant devs (and protocol devs?), rather than
                >>>> just one or the other?
                >>>>
                >>>> Is that something that we could talk about here? Or maybe it's better
                >>>> done via an optech workgroup or something?
                >>>>
                >>>> If "we'll credit your account in BTC, then work out the USD coversion
                >>>> and deduct that for your purchase, then you can do whatever you like
                >>>> with any remaining BTC from your on-chain payment" is the idea, maybe we
                >>>> should just roll with that design, but make it more decentralised: have
                >>>> the initial payment setup a lightning channel between the customer and
                >>>> the merchant with the BTC (so it's not custodial), but do some magic to
                >>>> allow USD amounts to be transferred over it (Taro? something oracle
                >>>> based
                >>>> so that both parties are confident a fair exchange rate will be used?).
                >>>>
                >>>> Maybe that particular idea is naive, but having an actual problem to
                >>>> solve seems more constructive than just saying "we want rbf" "but we
                >>>> want zeroconf" all the time?
                >>>>
                >>>> (Ideally the lightning channels above would be dual funded so they could
                >>>> be used for routing more generally; but then dual funded channels are
                >>>> one of the things that get broken by lack of full rbf)
                >>>>
                >>>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
                >>>> create
                >>>> > > two conflicting txs in advance, one paying the merchant, one paying
                >>>> > > yourself, connect to many peers, relay the one paying the merchant
                >>>> to
                >>>> > > the merchant, and the other to everyone else.
                >>>> > > I'm just basing this off Peter Todd's stuff from years ago:
                >>>> > >
                >>>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
                >>>> > >
                >>>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
                >>>> > Yeah, I know the list still rehashes a single incident from 10 years
                >>>> ago to
                >>>> > declare the entire practice as unsafe, and ignores real-world data
                >>>> that of
                >>>> > the last million transactions we had zero cases of this successfully
                >>>> > abusing us.
                >>>>
                >>>> I mean, the avenue above isn't easy to exploit -- you have to identify
                >>>> the merchant's node so that they get the bad tx, and you have to connect
                >>>> to many peers so that your preferred tx propogates to miners first --
                >>>> and probably more importantly, it's relatively easy to detect -- if the
                >>>> merchant has a few passive nodes that the attacker doesn't know about
                >>>> it, and uses those to watch for attempted doublespends while it tries
                >>>> to ensure the real tx has propogated widely. So it doesn't surprise me
                >>>> at all that it's not often attempted, and even less often successful.
                >>>>
                >>>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
                >>>> > > > payments.
                >>>> > > So, based on last year's numbers, presumably that makes your bitcoin
                >>>> > > payments break down as something like:
                >>>> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
                >>>> > >   15% txs are lightning
                >>>> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
                >>>> > >   60% txs are on-chain and seem fine for zeroconf
                >>>> > Numbers are right. Shady is too strong a word,
                >>>>
                >>>> Heh, fair enough.
                >>>>
                >>>> So the above suggests 25% of payments already get a sub-par experience,
                >>>> compared to what you'd like them to have (which sucks, but if you're
                >>>> trying to reinvent both money and payments, maybe isn't surprising). And
                >>>> going full rbf would bump that from 25% to 85%, which would be pretty
                >>>> terrible.
                >>>>
                >>>> > RBF is a strictly worse UX as proven by anyone
                >>>> > accepting bitcoin payments at scale.
                >>>>
                >>>> So let's make it better? Building bitcoin businesses on the lie that
                >>>> unconfirmed txs are safe and won't be replaced is going to bite us
                >>>> eventually; focussing on trying to push that back indefinitely is just
                >>>> going to make everyone less prepared when it eventually happens.
                >>>>
                >>>> > > > For me
                >>>> > > > personally it would be an easier discussion to have when
                >>>> Lightning is at
                >>>> > > > 80%+ of all bitcoin transactions.
                >>>> > > Can you extrapolate from the numbers you've seen to estimate when
                >>>> that
                >>>> > > might be, given current trends?
                >>>> > Not sure, it might be exponential growth, and the next 60% of
                >>>> Lightning
                >>>> > growth happen faster than the first 15%. Hard to tell. But we're
                >>>> likely
                >>>> > talking years here..
                >>>>
                >>>> Okay? Two years is very different from 50 years, and at the moment
                >>>> there's
                >>>> not really any data, so people are just going to go with their gut...
                >>>>
                >>>> If it were growing in line with lightning capacity in BTC, per
                >>>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
                >>>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
                >>>> getting from 15% to 80% would then be about 8 years.
                >>>>
                >>>> Presumably that's a laughably terrible model, of course. But if we had
                >>>> some actual numbers where we can watch the progress, it might be a lot
                >>>> easier to be patient about waiting for lightning adoption to hit 80%
                >>>> or whatever, and focus on productive things in the meantime?
                >>>>
                >>>> Cheers,
                >>>> aj
                >>>> _______________________________________________
                >>>> bitcoin-dev mailing list
                >>>> bitcoin-dev@lists•linuxfoundation.org
                >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                >>>>
                >>>
                >>
                >> --
                >>
                >> Sergej Kotliar
                >>
                >> CEO
                >>
                >>
                >> Twitter: @ziggamon <https://twitter.com/ziggamon>
                >>
                >>
                >> www.bitrefill.com
                >>
                >> Twitter <https://www.twitter.com/bitrefill> | Blog
                >> <https://www.bitrefill.com/blog/> | Angellist
                >> <https://angel.co/bitrefill>
                >>
                >
                
                -- 
                
                Sergej Kotliar
                
                CEO
                
                
                Twitter: @ziggamon <https://twitter.com/ziggamon>
                
                
                www.bitrefill.com
                
                Twitter <https://www.twitter.com/bitrefill> | Blog
                <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
                
                [-- Attachment #2: Type: text/html, Size: 21860 bytes --]
                
                ^ permalink raw reply	[flat|nested] 33+ messages in thread

              • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
                    2022-10-21 14:19               ` Sergej Kotliar
                  @ 2022-10-21 14:47                 ` Greg Sanders
                    0 siblings, 0 replies; 33+ messages in thread
                  From: Greg Sanders @ 2022-10-21 14:47 UTC (permalink / raw)
                    To: Sergej Kotliar; +Cc: Bitcoin Protocol Discussion, Anthony Towns
                  
                  [-- Attachment #1: Type: text/plain, Size: 14324 bytes --]
                  
                  > Yeah, there are several policy features that are not consensus related
                  but end up de facto setting rules for how bitcoin behaves.
                  
                  Yes, it's status quo so wallets "just know" not to do them. The fact that
                  the status quo would be changing is important, in that it may degrade UX
                  for 0-conf deposits. If bip125 was full rbf, the status quo would be the
                  other way around, but here we are.
                  
                  > need to evaluate from several angles first incentives-wise
                  
                  Right, if people have put their heads together and found a few
                  possibilities, we should explore the possibilities. CPFP would be an
                  interesting one used to lock in FX risk, or at least make the
                  double-spender over-pay to exploit the delta, especially for larger
                  amounts/new users with no track record.
                  
                  > I'd also ask if there might also be other solutions for solving the
                  pinning issue as well if we dig deep into it? Perhaps there are those with
                  tradeoffs, but those tradeoffs being less significant than the tradeoffs of
                  rbf policy?
                  
                  There's been a lot of work on crafting an opt-in policy that blunts the
                  edges of pinning attacks, and I think we've gotten to the point where it
                  can be said if you opt into this scheme: "If I have a required key in every
                  transaction input script, I can safely and efficiently fee bump the
                  transaction" through a mixture of RBF/CPFP, depending on structure.
                  
                  Please see
                  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021036.html
                  and issues linked in that e-mail, if you're interested in the set of policy
                  changes required to get there. Note that these would still all be opt-in.
                  
                  This unfortunately rules out any "coinjoin" like scenario, including
                  dual-funding lightning channels(which is close to landing finally). The
                  good news is that those cases seem to not have theft risk, just normal DoS
                  risk of funds being stuck for potentially weeks. It would also rule out
                  anything like coinpools, or other advanced constructs that don't actually
                  exist yet.
                  
                  Maybe the above proposals make RBF'ing super reliable compared to today,
                  and that changes the calculus for wallet authors, but this is still a ways
                  out as these are still early proposals.
                  
                  > it will hurt whenever it happens
                  
                  Yes it's a risk that this never gets satisfactorily resolved, which is why
                  I was mentioning a potentially long "timeout" being decided in the near-ish
                  future. Let's gather what we can, start building aspirationally towards
                  that, and try to not beat this horse again.
                  
                  Greg
                  
                  On Fri, Oct 21, 2022 at 10:19 AM Sergej Kotliar <sergej@bitrefill•com>
                  wrote:
                  
                  >
                  >
                  > On Fri, 21 Oct 2022 at 16:01, Greg Sanders <gsanders87@gmail•com> wrote:
                  >
                  >> Full-rbf is an odd duck, because while it is not a consensus issue, it
                  >> does affect a large % of transactions made by wallets already, contrary to
                  >> most policy changes.
                  >>
                  >
                  > Yeah, there are several policy features that are not consensus related but
                  > end up de facto setting rules for how bitcoin behaves. Minrelayfee being
                  > another, and probably other examples out there that I don't know of.
                  >
                  >
                  >> It's also a UX issue, not a safety issue for retail wallet users(except
                  >> Muun, who have given a clear timeline). Clearly considerations would be
                  >> very different otherwise, but retail wallets by and large do not consider
                  >> 0-conf as a valid deposit, or at least put up some warning symbols to that
                  >> effect.
                  >>
                  >> Can only speak for myself, but I am looking for a concrete timeframe from
                  >> 0-conf stakeholders. I have no preference for any particular time frame, as
                  >> long as it can be agreed upon in the near-ish future. This keeps the
                  >> transition technically speaking very simple, and removes uncertainty from
                  >> decision making going forward.
                  >>
                  >
                  > It's hard to give a timeframe because it's not clear what the path forward
                  > for these stakeholders is. Most of what I've heard in this channel is
                  > things like "just use Lightning" but that's contradicted by user data. So
                  > the action becomes "stop accepting payments onchain" which isn't really a
                  > timeframe type issue, it will hurt whenever it happens. Maybe a thorough
                  > discussion for a way forward would be useful here. Jeremy Rubin suggested
                  > an interesting idea for using CPFP to force a transaction to complete.
                  > We'll evaluate it and see if it works in the wild for zero-conf of RBF
                  > today and report findings, need to evaluate from several angles first
                  > incentives-wise. There might also be other solutions.
                  >
                  > I'd also ask if there might also be other solutions for solving the
                  > pinning issue as well if we dig deep into it? Perhaps there are those with
                  > tradeoffs, but those tradeoffs being less significant than the tradeoffs of
                  > rbf policy?
                  >
                  >
                  > Best,
                  > Sergej
                  >
                  >>
                  >> On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar <sergej@bitrefill•com>
                  >> wrote:
                  >>
                  >>> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail•com> wrote:
                  >>>
                  >>>> A large number of coins/users sit on custodial rails and this would
                  >>>> essentially encumber protocol developers to those KYC/AML institutions. If
                  >>>> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
                  >>>> should this be an issue at all for reasoning about a path forward?
                  >>>>
                  >>>
                  >>> This is a big question here, with the caveat that it's not just binance
                  >>> but in fact the majority of wallets and services that people use with
                  >>> bitcoin today.
                  >>> But the question remains as you phrased: At which point do we break
                  >>> backwards compatibility? Another analogy would be to have sunset the old
                  >>> P2PKH addresses during rollout of Segwit - it would certainly have led to
                  >>> Segwit getting rolled out faster. The rbf change actually breaks more
                  >>> things than that, takes more effort to address than just implementing a new
                  >>> address format. Previously in the Bitcoin Core process we've chosen to keep
                  >>> backwards compatibility and only roll out opt-in changes with broad
                  >>> consensus over them, with the default behavior being to not roll out
                  >>> changes that are controversial. At which point it's time to back away from
                  >>> that - I honestly don't know. There is probably such a point, and we should
                  >>> maybe have some kind of discussion around that topic on a higher level,
                  >>> just as you phrased it, and I'll paraphrase:
                  >>> If a majority of bitcoin wallets and services continue using legacy
                  >>> patterns and features, preventing progress, at which point do we want to
                  >>> break compatibility with them?
                  >>>
                  >>> Best,
                  >>> Sergej
                  >>>
                  >>>
                  >>> On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
                  >>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
                  >>>>
                  >>>>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
                  >>>>> bitcoin-dev wrote:
                  >>>>> > > If someone's going to systematically exploit your store via this
                  >>>>> > > mechanism, it seems like they'd just find a single wallet with a
                  >>>>> good
                  >>>>> > > UX for opt-in RBF and lowballing fees, and go to town -- not
                  >>>>> something
                  >>>>> > > where opt-in rbf vs fullrbf policies make any difference at all?
                  >>>>> > Sort of. But yes once this starts being abused systemically we will
                  >>>>> have to
                  >>>>> > do something else w RBF payments, such as crediting the amount in
                  >>>>> BTC to a
                  >>>>> > custodial account. But this option isn't available to your normal
                  >>>>> payment
                  >>>>> > processor type business.
                  >>>>>
                  >>>>> So, what I'm hearing is:
                  >>>>>
                  >>>>>  * lightning works great, but is still pretty small
                  >>>>>  * zeroconf works great for txs that opt-out of RBF
                  >>>>>  * opt-in RBF is a pain for two reasons:
                  >>>>>     - people don't like that it's not treated as zeroconf
                  >>>>>     - the risk of fiat/BTC exchange rate changes between
                  >>>>>       now and when the tx actually confirms is worrying
                  >>>>>       even if it hasn't caused real problems yet
                  >>>>>
                  >>>>> (Please correct me if that's too far wrong)
                  >>>>>
                  >>>>> Maybe it would be productive to explore this opt-in RBF part a bit
                  >>>>> more? ie, see if "we" can come up with better answers to some question
                  >>>>> along the lines of:
                  >>>>>
                  >>>>>  "how can we make on-chain payments for goods priced in fiat work well
                  >>>>>   for payees that opt-in to RBF?"
                  >>>>>
                  >>>>> That seems like the sort of thing that's better solved by a
                  >>>>> collaboration
                  >>>>> between wallet devs and merchant devs (and protocol devs?), rather than
                  >>>>> just one or the other?
                  >>>>>
                  >>>>> Is that something that we could talk about here? Or maybe it's better
                  >>>>> done via an optech workgroup or something?
                  >>>>>
                  >>>>> If "we'll credit your account in BTC, then work out the USD coversion
                  >>>>> and deduct that for your purchase, then you can do whatever you like
                  >>>>> with any remaining BTC from your on-chain payment" is the idea, maybe
                  >>>>> we
                  >>>>> should just roll with that design, but make it more decentralised: have
                  >>>>> the initial payment setup a lightning channel between the customer and
                  >>>>> the merchant with the BTC (so it's not custodial), but do some magic to
                  >>>>> allow USD amounts to be transferred over it (Taro? something oracle
                  >>>>> based
                  >>>>> so that both parties are confident a fair exchange rate will be used?).
                  >>>>>
                  >>>>> Maybe that particular idea is naive, but having an actual problem to
                  >>>>> solve seems more constructive than just saying "we want rbf" "but we
                  >>>>> want zeroconf" all the time?
                  >>>>>
                  >>>>> (Ideally the lightning channels above would be dual funded so they
                  >>>>> could
                  >>>>> be used for routing more generally; but then dual funded channels are
                  >>>>> one of the things that get broken by lack of full rbf)
                  >>>>>
                  >>>>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
                  >>>>> create
                  >>>>> > > two conflicting txs in advance, one paying the merchant, one paying
                  >>>>> > > yourself, connect to many peers, relay the one paying the merchant
                  >>>>> to
                  >>>>> > > the merchant, and the other to everyone else.
                  >>>>> > > I'm just basing this off Peter Todd's stuff from years ago:
                  >>>>> > >
                  >>>>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
                  >>>>> > >
                  >>>>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
                  >>>>> > Yeah, I know the list still rehashes a single incident from 10 years
                  >>>>> ago to
                  >>>>> > declare the entire practice as unsafe, and ignores real-world data
                  >>>>> that of
                  >>>>> > the last million transactions we had zero cases of this successfully
                  >>>>> > abusing us.
                  >>>>>
                  >>>>> I mean, the avenue above isn't easy to exploit -- you have to identify
                  >>>>> the merchant's node so that they get the bad tx, and you have to
                  >>>>> connect
                  >>>>> to many peers so that your preferred tx propogates to miners first --
                  >>>>> and probably more importantly, it's relatively easy to detect -- if the
                  >>>>> merchant has a few passive nodes that the attacker doesn't know about
                  >>>>> it, and uses those to watch for attempted doublespends while it tries
                  >>>>> to ensure the real tx has propogated widely. So it doesn't surprise me
                  >>>>> at all that it's not often attempted, and even less often successful.
                  >>>>>
                  >>>>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
                  >>>>> > > > payments.
                  >>>>> > > So, based on last year's numbers, presumably that makes your
                  >>>>> bitcoin
                  >>>>> > > payments break down as something like:
                  >>>>> > >    5% txs are on-chain and seem shady and are excluded from
                  >>>>> zeroconf
                  >>>>> > >   15% txs are lightning
                  >>>>> > >   20% txs are on-chain but signal rbf and are excluded from
                  >>>>> zeroconf
                  >>>>> > >   60% txs are on-chain and seem fine for zeroconf
                  >>>>> > Numbers are right. Shady is too strong a word,
                  >>>>>
                  >>>>> Heh, fair enough.
                  >>>>>
                  >>>>> So the above suggests 25% of payments already get a sub-par experience,
                  >>>>> compared to what you'd like them to have (which sucks, but if you're
                  >>>>> trying to reinvent both money and payments, maybe isn't surprising).
                  >>>>> And
                  >>>>> going full rbf would bump that from 25% to 85%, which would be pretty
                  >>>>> terrible.
                  >>>>>
                  >>>>> > RBF is a strictly worse UX as proven by anyone
                  >>>>> > accepting bitcoin payments at scale.
                  >>>>>
                  >>>>> So let's make it better? Building bitcoin businesses on the lie that
                  >>>>> unconfirmed txs are safe and won't be replaced is going to bite us
                  >>>>> eventually; focussing on trying to push that back indefinitely is just
                  >>>>> going to make everyone less prepared when it eventually happens.
                  >>>>>
                  >>>>> > > > For me
                  >>>>> > > > personally it would be an easier discussion to have when
                  >>>>> Lightning is at
                  >>>>> > > > 80%+ of all bitcoin transactions.
                  >>>>> > > Can you extrapolate from the numbers you've seen to estimate when
                  >>>>> that
                  >>>>> > > might be, given current trends?
                  >>>>> > Not sure, it might be exponential growth, and the next 60% of
                  >>>>> Lightning
                  >>>>> > growth happen faster than the first 15%. Hard to tell. But we're
                  >>>>> likely
                  >>>>> > talking years here..
                  >>>>>
                  >>>>> Okay? Two years is very different from 50 years, and at the moment
                  >>>>> there's
                  >>>>> not really any data, so people are just going to go with their gut...
                  >>>>>
                  >>>>> If it were growing in line with lightning capacity in BTC, per
                  >>>>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
                  >>>>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
                  >>>>> getting from 15% to 80% would then be about 8 years.
                  >>>>>
                  >>>>> Presumably that's a laughably terrible model, of course. But if we had
                  >>>>> some actual numbers where we can watch the progress, it might be a lot
                  >>>>> easier to be patient about waiting for lightning adoption to hit 80%
                  >>>>> or whatever, and focus on productive things in the meantime?
                  >>>>>
                  >>>>> Cheers,
                  >>>>> aj
                  >>>>> _______________________________________________
                  >>>>> bitcoin-dev mailing list
                  >>>>> bitcoin-dev@lists•linuxfoundation.org
                  >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  >>>>>
                  >>>>
                  >>>
                  >>> --
                  >>>
                  >>> Sergej Kotliar
                  >>>
                  >>> CEO
                  >>>
                  >>>
                  >>> Twitter: @ziggamon <https://twitter.com/ziggamon>
                  >>>
                  >>>
                  >>> www.bitrefill.com
                  >>>
                  >>> Twitter <https://www.twitter.com/bitrefill> | Blog
                  >>> <https://www.bitrefill.com/blog/> | Angellist
                  >>> <https://angel.co/bitrefill>
                  >>>
                  >>
                  >
                  > --
                  >
                  > Sergej Kotliar
                  >
                  > CEO
                  >
                  >
                  > Twitter: @ziggamon <https://twitter.com/ziggamon>
                  >
                  >
                  > www.bitrefill.com
                  >
                  > Twitter <https://www.twitter.com/bitrefill> | Blog
                  > <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
                  >
                  
                  [-- Attachment #2: Type: text/html, Size: 25122 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 33+ messages in thread

            • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
                2022-10-21 12:02           ` Sergej Kotliar
                2022-10-21 14:01             ` Greg Sanders
              @ 2022-10-21 19:43             ` Peter Todd
                2022-10-24  7:55               ` Sergej Kotliar
                1 sibling, 1 reply; 33+ messages in thread
              From: Peter Todd @ 2022-10-21 19:43 UTC (permalink / raw)
                To: Sergej Kotliar, Bitcoin Protocol Discussion; +Cc: Anthony Towns, Greg Sanders
              
              [-- Attachment #1: Type: text/plain, Size: 2356 bytes --]
              
              On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev wrote:
              > On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail•com> wrote:
              > 
              > > A large number of coins/users sit on custodial rails and this would
              > > essentially encumber protocol developers to those KYC/AML institutions. If
              > > Binance decides to never support Lightning in favor of BNC-wrapped BTC,
              > > should this be an issue at all for reasoning about a path forward?
              > >
              > 
              > This is a big question here, with the caveat that it's not just binance but
              > in fact the majority of wallets and services that people use with bitcoin
              > today.
              > But the question remains as you phrased: At which point do we break
              > backwards compatibility? Another analogy would be to have sunset the old
              > P2PKH addresses during rollout of Segwit - it would certainly have led to
              > Segwit getting rolled out faster. The rbf change actually breaks more
              > things than that, takes more effort to address than just implementing a new
              > address format. Previously in the Bitcoin Core process we've chosen to keep
              
              RBF certainly does not break more things than depreciating an entire address
              standard. P2PKH addresses are still used by old wallets, and it's often not
              worth the risk to upgrade to new software for old coins kept offline by
              ordinary users. I personally have used P2PKH addresses in the past few months.
              
              Zeroconf on the other hand has never worked reliably, so you can't even claim
              it's a "supported feature". And the fact is, it breaks all the time because
              every time miners change their acceptance rules - eg with new releases - we
              break it every single time we do a new release with different you can easily
              exploit zeroconf.
              
              Frankly, the fact that we didn't widely implement full-rbf sooner is quite
              unfortunate, as Bitrefill, Muun, etc. should have never been using it in the
              first place.
              
              > If a majority of bitcoin wallets and services continue using legacy
              > patterns and features, preventing progress, at which point do we want to
              > break compatibility with them?
              
              It's clearly false to claim that the "majority of bitcoin wallets and services"
              are using zeroconf. A tiny minority are attempting to use it, with the vast
              majority of previous users having given up on it.
              
              -- 
              https://petertodd.org 'peter'[:-1]@petertodd.org
              
              [-- Attachment #2: signature.asc --]
              [-- Type: application/pgp-signature, Size: 488 bytes --]
              
              ^ permalink raw reply	[flat|nested] 33+ messages in thread

            • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
                  2022-10-21 19:43             ` Peter Todd
                @ 2022-10-24  7:55               ` Sergej Kotliar
                  0 siblings, 0 replies; 33+ messages in thread
                From: Sergej Kotliar @ 2022-10-24  7:55 UTC (permalink / raw)
                  To: Peter Todd; +Cc: Bitcoin Protocol Discussion, Anthony Towns, Greg Sanders
                
                [-- Attachment #1: Type: text/plain, Size: 3751 bytes --]
                
                On Fri, 21 Oct 2022 at 21:43, Peter Todd <pete@petertodd•org> wrote:
                
                > On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev
                > wrote:
                > > On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail•com> wrote:
                > >
                > > > A large number of coins/users sit on custodial rails and this would
                > > > essentially encumber protocol developers to those KYC/AML
                > institutions. If
                > > > Binance decides to never support Lightning in favor of BNC-wrapped BTC,
                > > > should this be an issue at all for reasoning about a path forward?
                > > >
                > >
                > > This is a big question here, with the caveat that it's not just binance
                > but
                > > in fact the majority of wallets and services that people use with bitcoin
                > > today.
                > > But the question remains as you phrased: At which point do we break
                > > backwards compatibility? Another analogy would be to have sunset the old
                > > P2PKH addresses during rollout of Segwit - it would certainly have led to
                > > Segwit getting rolled out faster. The rbf change actually breaks more
                > > things than that, takes more effort to address than just implementing a
                > new
                > > address format. Previously in the Bitcoin Core process we've chosen to
                > keep
                >
                > RBF certainly does not break more things than depreciating an entire
                > address
                > standard. P2PKH addresses are still used by old wallets, and it's often not
                > worth the risk to upgrade to new software for old coins kept offline by
                > ordinary users. I personally have used P2PKH addresses in the past few
                > months.
                >
                > Zeroconf on the other hand has never worked reliably, so you can't even
                > claim
                > it's a "supported feature". And the fact is, it breaks all the time because
                > every time miners change their acceptance rules - eg with new releases - we
                > break it every single time we do a new release with different you can
                > easily
                > exploit zeroconf.
                >
                
                Haven't heard of any release breaking zeroconf. I would absolutely say it's
                working reliably.
                
                
                > Frankly, the fact that we didn't widely implement full-rbf sooner is quite
                > unfortunate, as Bitrefill, Muun, etc. should have never been using it in
                > the
                > first place.
                >
                
                You make it sound like we're the odd ones out when it's in fact ~every
                service that lets you buy stuff with bitcoin. It's just that we're the only
                ones raising voices on the mailing list so far. On the contrary side, can
                you name one service that lets you buy stuff with bitcoin that doesn't rely
                on zeroconf? Maybe with the caveat that it should have some level of scale
                and an audience not consisting of only power users.
                
                
                > > If a majority of bitcoin wallets and services continue using legacy
                > > patterns and features, preventing progress, at which point do we want to
                > > break compatibility with them?
                >
                > It's clearly false to claim that the "majority of bitcoin wallets and
                > services"
                > are using zeroconf. A tiny minority are attempting to use it, with the vast
                > majority of previous users having given up on it.
                >
                
                I didn't claim that. But it's definitely true that the vast majority of
                wallets and services do not allow users to do RBF. This is easy to validate
                as the list of wallets with RBF support is short), the list of exchanges
                with RBF support is zero.
                https://transactionfee.info/charts/transactions-signaling-explicit-rbf/
                29% of txs signal RBF, meaning 71% do not. And let's be honest, it's not
                like the majority of those were given a choice and chose not to, for the
                majority their wallet just doesn't support RBF.
                
                
                > --
                > https://petertodd.org 'peter'[:-1]@petertodd.org
                >
                
                
                -- 
                
                Sergej Kotliar
                
                CEO
                
                
                Twitter: @ziggamon <https://twitter.com/ziggamon>
                
                
                www.bitrefill.com
                
                Twitter <https://www.twitter.com/bitrefill> | Blog
                <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
                
                [-- Attachment #2: Type: text/html, Size: 9027 bytes --]
                
                ^ permalink raw reply	[flat|nested] 33+ messages in thread

        • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
            2022-10-20 19:58       ` Anthony Towns
            2022-10-20 21:05         ` David A. Harding
            2022-10-20 21:07         ` Greg Sanders
          @ 2022-10-20 22:13         ` Peter Todd
            2022-10-21  9:34           ` Sergej Kotliar
            2022-10-21 11:56         ` Sergej Kotliar
            3 siblings, 1 reply; 33+ messages in thread
          From: Peter Todd @ 2022-10-20 22:13 UTC (permalink / raw)
            To: Anthony Towns, Bitcoin Protocol Discussion; +Cc: Sergej Kotliar
          
          [-- Attachment #1: Type: text/plain, Size: 1468 bytes --]
          
          On Fri, Oct 21, 2022 at 05:58:41AM +1000, Anthony Towns via bitcoin-dev wrote:
          > On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
          > > > If someone's going to systematically exploit your store via this
          > > > mechanism, it seems like they'd just find a single wallet with a good
          > > > UX for opt-in RBF and lowballing fees, and go to town -- not something
          > > > where opt-in rbf vs fullrbf policies make any difference at all?
          > > Sort of. But yes once this starts being abused systemically we will have to
          > > do something else w RBF payments, such as crediting the amount in BTC to a
          > > custodial account. But this option isn't available to your normal payment
          > > processor type business.
          > 
          > So, what I'm hearing is:
          > 
          >  * lightning works great, but is still pretty small
          >  * zeroconf works great for txs that opt-out of RBF
          
          It's important to note that the businesses that say "zeroconf works great" for
          them, appear to be achieving that by sybil attacking the network to measure
          propagation. That's not sustainable nor decentralized, as only a small number
          of companies can do that without causing a lot of harm to Bitcoin by using up
          inbound slots. We've gone through this before with "zeroconf guarantee"
          services, and the end result is not good.
          
          It's in our interests to make sure those companies stop doing that, and no new
          companies start.
          
          -- 
          https://petertodd.org 'peter'[:-1]@petertodd.org
          
          [-- Attachment #2: signature.asc --]
          [-- Type: application/pgp-signature, Size: 488 bytes --]
          
          ^ permalink raw reply	[flat|nested] 33+ messages in thread

        • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
              2022-10-20 22:13         ` Peter Todd
            @ 2022-10-21  9:34           ` Sergej Kotliar
              2022-10-21 19:33             ` Peter Todd
              0 siblings, 1 reply; 33+ messages in thread
            From: Sergej Kotliar @ 2022-10-21  9:34 UTC (permalink / raw)
              To: Peter Todd; +Cc: Bitcoin Protocol Discussion, Anthony Towns
            
            [-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
            
            This is factually incorrect and not required for us to do what we do.
            
            On Fri, 21 Oct 2022 at 00:13, Peter Todd <pete@petertodd•org> wrote:
            
            > On Fri, Oct 21, 2022 at 05:58:41AM +1000, Anthony Towns via bitcoin-dev
            > wrote:
            > > On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
            > wrote:
            > > > > If someone's going to systematically exploit your store via this
            > > > > mechanism, it seems like they'd just find a single wallet with a good
            > > > > UX for opt-in RBF and lowballing fees, and go to town -- not
            > something
            > > > > where opt-in rbf vs fullrbf policies make any difference at all?
            > > > Sort of. But yes once this starts being abused systemically we will
            > have to
            > > > do something else w RBF payments, such as crediting the amount in BTC
            > to a
            > > > custodial account. But this option isn't available to your normal
            > payment
            > > > processor type business.
            > >
            > > So, what I'm hearing is:
            > >
            > >  * lightning works great, but is still pretty small
            > >  * zeroconf works great for txs that opt-out of RBF
            >
            > It's important to note that the businesses that say "zeroconf works great"
            > for
            > them, appear to be achieving that by sybil attacking the network to measure
            > propagation. That's not sustainable nor decentralized, as only a small
            > number
            > of companies can do that without causing a lot of harm to Bitcoin by using
            > up
            > inbound slots. We've gone through this before with "zeroconf guarantee"
            > services, and the end result is not good.
            >
            > It's in our interests to make sure those companies stop doing that, and no
            > new
            > companies start.
            >
            > --
            > https://petertodd.org 'peter'[:-1]@petertodd.org
            >
            
            
            -- 
            
            Sergej Kotliar
            
            CEO
            
            
            Twitter: @ziggamon <https://twitter.com/ziggamon>
            
            
            www.bitrefill.com
            
            Twitter <https://www.twitter.com/bitrefill> | Blog
            <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
            
            [-- Attachment #2: Type: text/html, Size: 6377 bytes --]
            
            ^ permalink raw reply	[flat|nested] 33+ messages in thread

          • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
                2022-10-21  9:34           ` Sergej Kotliar
              @ 2022-10-21 19:33             ` Peter Todd
                2022-10-24  7:45               ` Sergej Kotliar
                0 siblings, 1 reply; 33+ messages in thread
              From: Peter Todd @ 2022-10-21 19:33 UTC (permalink / raw)
                To: Sergej Kotliar; +Cc: Bitcoin Protocol Discussion, Anthony Towns
              
              [-- Attachment #1: Type: text/plain, Size: 260 bytes --]
              
              On Fri, Oct 21, 2022 at 11:34:17AM +0200, Sergej Kotliar wrote:
              > This is factually incorrect and not required for us to do what we do.
              
              So how do you detect people sending conflicting transactions?
              
              -- 
              https://petertodd.org 'peter'[:-1]@petertodd.org
              
              [-- Attachment #2: signature.asc --]
              [-- Type: application/pgp-signature, Size: 488 bytes --]
              
              ^ permalink raw reply	[flat|nested] 33+ messages in thread

            • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
                  2022-10-21 19:33             ` Peter Todd
                @ 2022-10-24  7:45               ` Sergej Kotliar
                  0 siblings, 0 replies; 33+ messages in thread
                From: Sergej Kotliar @ 2022-10-24  7:45 UTC (permalink / raw)
                  To: Peter Todd; +Cc: Bitcoin Protocol Discussion, Anthony Towns
                
                [-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
                
                There are many countermeasures that can be done, we've only implemented a
                subset of them as more haven't been needed.
                
                Mainly we wait some time to make sure any conflicting transaction has time
                to propagate on the network. We have well connected nodes with basic
                redundancy.
                When they are available we sometimes use external block explorers for
                certain nice-to-have enhancements, but it's absolutely not required for
                zeroconf as they are frequently down.
                
                I can of course only speak to our custom-built setup, presumably everyone
                who accepts payments with bitcoin uses something similar. Regardless, let's
                maybe not go as far as to say that anyone who accepts payments with bitcoin
                is attacking bitcoin ;)
                
                On Fri, 21 Oct 2022 at 21:33, Peter Todd <pete@petertodd•org> wrote:
                
                > On Fri, Oct 21, 2022 at 11:34:17AM +0200, Sergej Kotliar wrote:
                > > This is factually incorrect and not required for us to do what we do.
                >
                > So how do you detect people sending conflicting transactions?
                >
                > --
                > https://petertodd.org 'peter'[:-1]@petertodd.org
                >
                
                
                -- 
                
                Sergej Kotliar
                
                CEO
                
                
                Twitter: @ziggamon <https://twitter.com/ziggamon>
                
                
                www.bitrefill.com
                
                Twitter <https://www.twitter.com/bitrefill> | Blog
                <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
                
                [-- Attachment #2: Type: text/html, Size: 5666 bytes --]
                
                ^ permalink raw reply	[flat|nested] 33+ messages in thread

        • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
            2022-10-20 19:58       ` Anthony Towns
                                     ` (2 preceding siblings ...)
            2022-10-20 22:13         ` Peter Todd
          @ 2022-10-21 11:56         ` Sergej Kotliar
            3 siblings, 0 replies; 33+ messages in thread
          From: Sergej Kotliar @ 2022-10-21 11:56 UTC (permalink / raw)
            To: Anthony Towns; +Cc: Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 5873 bytes --]
          
          On Thu, 20 Oct 2022 at 21:58, Anthony Towns <aj@erisian•com.au> wrote:
          
          > So, what I'm hearing is:
          >
          >  * lightning works great, but is still pretty small
          >  * zeroconf works great for txs that opt-out of RBF
          >  * opt-in RBF is a pain for two reasons:
          >     - people don't like that it's not treated as zeroconf
          >     - the risk of fiat/BTC exchange rate changes between
          >       now and when the tx actually confirms is worrying
          >       even if it hasn't caused real problems yet
          >
          > This is about right yes
          
          
          > Maybe it would be productive to explore this opt-in RBF part a bit
          > more? ie, see if "we" can come up with better answers to some question
          > along the lines of:
          >
          >  "how can we make on-chain payments for goods priced in fiat work well
          >   for payees that opt-in to RBF?"
          >
          > That seems like the sort of thing that's better solved by a collaboration
          > between wallet devs and merchant devs (and protocol devs?), rather than
          > just one or the other?
          >
          > Is that something that we could talk about here? Or maybe it's better
          > done via an optech workgroup or something?
          >
          
          Agreed, more work is needed in the regard and we're happy to participate in
          any efforts to make things better. It's not like we _want_ to be against
          the core dev roadmap :)
          
          
          > If "we'll credit your account in BTC, then work out the USD coversion
          > and deduct that for your purchase, then you can do whatever you like
          > with any remaining BTC from your on-chain payment" is the idea, maybe we
          > should just roll with that design, but make it more decentralised: have
          > the initial payment setup a lightning channel between the customer and
          > the merchant with the BTC (so it's not custodial), but do some magic to
          > allow USD amounts to be transferred over it (Taro? something oracle based
          > so that both parties are confident a fair exchange rate will be used?).
          >
          > Maybe that particular idea is naive, but having an actual problem to
          > solve seems more constructive than just saying "we want rbf" "but we
          > want zeroconf" all the time?
          >
          
          Don't think it would solve any of the issues even if the above could
          technically work, which it can't, simply because wallets that can only do
          dump onchain payments are unlikely to be able to implement a scheme like
          this.
          
          
          > > > > Currently Lightning is somewhere around 15% of our total bitcoin
          > > > > payments.
          > > > So, based on last year's numbers, presumably that makes your bitcoin
          > > > payments break down as something like:
          > > >    5% txs are on-chain and seem shady and are excluded from zeroconf
          > > >   15% txs are lightning
          > > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
          > > >   60% txs are on-chain and seem fine for zeroconf
          > > Numbers are right. Shady is too strong a word,
          >
          > Heh, fair enough.
          >
          > So the above suggests 25% of payments already get a sub-par experience,
          > compared to what you'd like them to have (which sucks, but if you're
          > trying to reinvent both money and payments, maybe isn't surprising). And
          > going full rbf would bump that from 25% to 85%, which would be pretty
          > terrible.
          >
          > > RBF is a strictly worse UX as proven by anyone
          > > accepting bitcoin payments at scale.
          >
          > So let's make it better? Building bitcoin businesses on the lie that
          > unconfirmed txs are safe and won't be replaced is going to bite us
          > eventually; focussing on trying to push that back indefinitely is just
          > going to make everyone less prepared when it eventually happens.
          >
          
          Sure. The question is if we "make it better" first or if we standardize on
          that which works worse first.
          
          
          > > > > For me
          > > > > personally it would be an easier discussion to have when Lightning
          > is at
          > > > > 80%+ of all bitcoin transactions.
          > > > Can you extrapolate from the numbers you've seen to estimate when that
          > > > might be, given current trends?
          > > Not sure, it might be exponential growth, and the next 60% of Lightning
          > > growth happen faster than the first 15%. Hard to tell. But we're likely
          > > talking years here..
          >
          > Okay? Two years is very different from 50 years, and at the moment there's
          > not really any data, so people are just going to go with their gut...
          >
          > If it were growing in line with lightning capacity in BTC, per
          > bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
          > perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
          > getting from 15% to 80% would then be about 8 years.
          >
          
          This math doesn't work. Capacity is a bad metric for activity, something we
          unfortunately imported from the ETH world's TVL. Liquid has the same number
          of btc on it as Lightning, but we probably all know there are several
          orders of magnitude of difference in terms of usage.
          
          There is another type of linear math that can but done but it's
          significantly more gloomy: Over the past 3 years the share of bitcoin
          payments among services has dropped from ~90%+ to below 50%. These figures
          are similar across Bitrefill, Living Room of Satoshi, CoinCards, Bitpay
          which is all the sources I know that have published stats on this. If we
          assume this trend continues at that pace we might be at a point where
          payments on Bitcoin are irrelevant, especially onchain, and there isn't
          much left to argue over. I don't think that's going to happen tho, this
          math probably also doesn't work for the same reasons, and we will work hard
          for it to not happen. Fundamentally the issue of legacy support for bitcoin
          things remains, and the ossification that happened on bitcoin things around
          the 2015 level of UX. Solving that issue has proven to be a very tricky
          subject, that we spend lots of energy on, but yet without overwhelming
          success.
          
          Best,
          Sergej
          
          
          -- 
          
          Sergej Kotliar
          
          CEO
          
          
          Twitter: @ziggamon <https://twitter.com/ziggamon>
          
          
          www.bitrefill.com
          
          Twitter <https://www.twitter.com/bitrefill> | Blog
          <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
          
          [-- Attachment #2: Type: text/html, Size: 11413 bytes --]
          
          ^ permalink raw reply	[flat|nested] 33+ messages in thread

      • * [bitcoindev] Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
          2022-10-20 12:37     ` Sergej Kotliar
          2022-10-20 14:14       ` Ruben Somsen
          2022-10-20 19:58       ` Anthony Towns
        @ 2025-05-02 10:06       ` Anthony Towns
          2 siblings, 0 replies; 33+ messages in thread
        From: Anthony Towns @ 2025-05-02 10:06 UTC (permalink / raw)
          To: Sergej Kotliar, Bitcoin Development Mailing List
        
        On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
        > On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian•com.au> wrote:
        > > On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
        > > wrote:
        > > > Currently Lightning is somewhere around 15% of our total bitcoin
        > > > payments.
        > > So, based on last year's numbers, presumably that makes your bitcoin
        > > payments break down as something like:
        > >
        > >    5% txs are on-chain and seem shady and are excluded from zeroconf
        > >   15% txs are lightning
        > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
        > >   60% txs are on-chain and seem fine for zeroconf
        > Numbers are right. Shady is too strong a word, it's mostly transactions
        > with very low fee, or high purchase amount, or many dependent unconfirmed
        > transactions, stuff like that. In some cases we do a human assessment of
        > the support ticket and often just pass them through.
        
        > > > This is very much not nothing, and all of us here want Lightning to grow,
        > > > but I think it warrants a serious discussion on whether we want Lightning
        > > > adoption to go to 100% by means of disabling on-chain commerce.
        > > If the numbers above were accurate, this would just mean you'd go from 60%
        > > zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
        > Point is that RBF transactions are unsafe even when waiting for a
        > confirmation, which Peter Todd trivially proved in the reply next to this.
        > The reliable solution is to reject all RBF payments and direct those users
        > to custodial accounts. There are other variants to solve this with varying
        > degree of convolutedness. RBF is a strictly worse UX as proven by anyone
        > accepting bitcoin payments at scale.
        
        So the mempoolfullrbf default changed from false to true in 28.0 released
        in October last year, which is advertised as being run by maybe 30%-40%
        of the network now, and fullrbf transactions have been reportedly been mined
        reliably since well before that.
        
        Any chance of an update on how that change has affected bitcoin/lightning
        payment volume for you guys, or customer satisfaction (if payment
        acceptance is delayed more often), or how much engineering/support time
        was needed to adapt, or any other impact?
        
        Cheers,
        aj
        
        -- 
        You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
        To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aBSZGqZ50K-WVnAf%40erisian.com.au.
        
        
        ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
      2022-10-19 14:29 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Sergej Kotliar
                         ` (4 preceding siblings ...)
      2022-10-20  7:22   ` Anthony Towns
    @ 2022-10-23 19:20   ` David A. Harding
      2022-10-23 20:51     ` alicexbt
      5 siblings, 1 reply; 33+ messages in thread
    From: David A. Harding @ 2022-10-23 19:20 UTC (permalink / raw)
      To: Sergej Kotliar, Bitcoin Protocol Discussion
    
    On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:
    > The biggest risk
    > in accepting bitcoin payments is in fact not zeroconf risk (it's
    > actually quite easily managed), it's FX risk as the merchant must
    > commit to a certain BTCUSD rate ahead of time for a purchase. Over
    > time some transactions lose money to FX and others earn money - that
    > evens out in the end. But if there is an _easily accessible in the
    > wallet_ feature to "cancel transaction" that means it will eventually
    > get systematically abused.
    
    One way to address this risk is by turning it into a certainty.  If the 
    price of BTC increases between when the invoice is generated and when a 
    transaction is included in a block, give the customer a future purchase 
    credit equal in value to the difference between the price they paid and 
    the value of the purchase at confirmation time.  Now there's no benefit 
    to the customer from canceling their transaction.
    
    Of course, this means that the merchant will always either break even or 
    lose money on the exchange rate part of the transaction and will need to 
    raise their prices accordingly.  I can see how that would be unappealing 
    to implement, but it seems better to me to address the incentive 
    incompatibility you've raised rather than hope no large miners ever 
    start performing full RBF.  Plus, maybe the future credit feature is 
    something customers would like: I know I've been sad several times when 
    the exchange rate changed significantly while I was waiting for one of 
    my transactions to confirm.
    
    The above mitigation is also compatible with LN payments.  For example, 
    a merchant today might issue an LN invoice that expires in 10 minutes.  
    The customer can wait for most of that time to elapse to see how the 
    exchange rate changes before deciding to pay, obtaining the same 
    American call option.  If they are instead offered a future purchase 
    credit for any gains, the customer doesn't suffer any opportunity cost 
    by paying immediately.  (With LN, it might be possible to have a better 
    UX for this by either refunding any excess or (if using something like 
    Original AMP or PTLCs) not claiming any parts of the payment which are 
    in excess.)
    
    -Dave
    
    
    ^ permalink raw reply	[flat|nested] 33+ messages in thread

  • • * Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
        2022-10-23 19:20   ` David A. Harding
      @ 2022-10-23 20:51     ` alicexbt
        0 siblings, 0 replies; 33+ messages in thread
      From: alicexbt @ 2022-10-23 20:51 UTC (permalink / raw)
        To: David A. Harding; +Cc: Sergej Kotliar, Bitcoin Protocol Discussion
      
      Hi Dave,
      
      > One way to address this risk is by turning it into a certainty.  If the 
      price of BTC increases between when the invoice is generated and when a 
      transaction is included in a block, give the customer a future purchase 
      credit equal in value to the difference between the price they paid and 
      the value of the purchase at confirmation time.  Now there's no benefit 
      to the customer from canceling their transaction.
      
      There are several methods to approach this issue, one of which is by using multiple exchanges from different countries as there are always possibilities for arbitrage. Example:
      
      The user purchases a gift card on Bitrefill for 0.01 BTC, and then Bitrefill cash it out at one of the three exchanges where the price of bitcoin is 19000, 19100, or 19500. However, price used for gift card payment was average of all 3. This should never be solved at protocol level as speculation of price is irrelevant when making RBF policy default in bitcoin core.
      
      There are different types of businesses that accept bitcoin payments and its good for bitcoin. However, everyone has their own way to deal with the issues. Example:
      
      In a website for booking flights, you may cancel a user's ticket if they couldn't make a payment within a certain amount of time and confirmations. I'm not sure how gift cards operate, but they are used for carding, fraud etc. frequently.
      
      Its important to give priority to bitcoin projects that could improve demand for block space even if opening and closing channels. I would [quote][0] something from a pull request by Michael Folkson although I do not agree with everything he writes:
      
      "I don't believe in added code (complexity) for issues that can be resolved in alternative repos and through communication with the ecosystem."
      
      Things that could help improve business for companies that accept bitcoin payments could be done in other ways. Zero conf is old school but we can try new ways and do partnerships with more organizations (outside North America and Europe). I work for an exchange as developer although CTO won't write an email and CEO don't want to spam the mailing list with non technical things. I request on their behalf that we consider all businesses and some are not even aware of fullRBF. Example: Lolli or Gosats
      
      TL;DR
      
      Full RBF should be tried and if default is an issue, devs should convince some nodes and miners or agree on one of the pull requests. I prefer [AJ's pull request][1] because it gives time for review and testing. It is important to test as many websites, apps, projects etc. as possible before making something default and also consider the percent of usage.
      
      [0]: https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280742475
      [1]: https://github.com/bitcoin/bitcoin/pull/26323
      
      
      /dev/fd0
      
      
      Sent with Proton Mail secure email.
      
      ------- Original Message -------
      On Monday, October 24th, 2022 at 12:50 AM, David A. Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
      
      
      > On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:
      > 
      > > The biggest risk
      > > in accepting bitcoin payments is in fact not zeroconf risk (it's
      > > actually quite easily managed), it's FX risk as the merchant must
      > > commit to a certain BTCUSD rate ahead of time for a purchase. Over
      > > time some transactions lose money to FX and others earn money - that
      > > evens out in the end. But if there is an easily accessible in the
      > > wallet feature to "cancel transaction" that means it will eventually
      > > get systematically abused.
      > 
      > 
      > One way to address this risk is by turning it into a certainty. If the
      > price of BTC increases between when the invoice is generated and when a
      > transaction is included in a block, give the customer a future purchase
      > credit equal in value to the difference between the price they paid and
      > the value of the purchase at confirmation time. Now there's no benefit
      > to the customer from canceling their transaction.
      > 
      > Of course, this means that the merchant will always either break even or
      > lose money on the exchange rate part of the transaction and will need to
      > raise their prices accordingly. I can see how that would be unappealing
      > to implement, but it seems better to me to address the incentive
      > incompatibility you've raised rather than hope no large miners ever
      > start performing full RBF. Plus, maybe the future credit feature is
      > something customers would like: I know I've been sad several times when
      > the exchange rate changed significantly while I was waiting for one of
      > my transactions to confirm.
      > 
      > The above mitigation is also compatible with LN payments. For example,
      > a merchant today might issue an LN invoice that expires in 10 minutes.
      > The customer can wait for most of that time to elapse to see how the
      > exchange rate changes before deciding to pay, obtaining the same
      > American call option. If they are instead offered a future purchase
      > credit for any gains, the customer doesn't suffer any opportunity cost
      > by paying immediately. (With LN, it might be possible to have a better
      > UX for this by either refunding any excess or (if using something like
      > Original AMP or PTLCs) not claiming any parts of the payment which are
      > in excess.)
      > 
      > -Dave
      > _______________________________________________
      > bitcoin-dev mailing list
      > bitcoin-dev@lists•linuxfoundation.org
      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      
      
      ^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2025-05-02 10:33 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
2022-10-19 14:29 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Sergej Kotliar
2022-10-19 14:45   ` Erik Aronesty
2022-10-19 15:43   ` Jeremy Rubin
2022-10-19 15:51     ` Greg Sanders
2022-10-19 16:04     ` Sergej Kotliar
2022-10-19 16:08       ` Greg Sanders
2022-10-20  1:37   ` Antoine Riard
2022-10-20 14:11     ` Sergej Kotliar
2022-10-21  1:04       ` Antoine Riard
2022-10-20  4:05   ` Peter Todd
2022-10-21 19:35     ` Peter Todd
2022-10-20  7:22   ` Anthony Towns
2022-10-20 12:37     ` Sergej Kotliar
2022-10-20 14:14       ` Ruben Somsen
2022-10-20 14:17         ` Sergej Kotliar
2022-10-20 19:58       ` Anthony Towns
2022-10-20 21:05         ` David A. Harding
2022-10-20 21:07         ` Greg Sanders
2022-10-20 22:02           ` Eloy
2022-10-21 12:02           ` Sergej Kotliar
2022-10-21 14:01             ` Greg Sanders
2022-10-21 14:19               ` Sergej Kotliar
2022-10-21 14:47                 ` Greg Sanders
2022-10-21 19:43             ` Peter Todd
2022-10-24  7:55               ` Sergej Kotliar
2022-10-20 22:13         ` Peter Todd
2022-10-21  9:34           ` Sergej Kotliar
2022-10-21 19:33             ` Peter Todd
2022-10-24  7:45               ` Sergej Kotliar
2022-10-21 11:56         ` Sergej Kotliar
2025-05-02 10:06       ` [bitcoindev] " Anthony Towns
2022-10-23 19:20   ` David A. Harding
2022-10-23 20:51     ` alicexbt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox