Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-21 📝 Original message:Full-rbf is an odd duck, ...
📅 Original date posted:2022-10-21
📝 Original message: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 at bitrefill.com> wrote:
> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87 at 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 at 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 at 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>;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221021/ee43dfba/attachment-0001.html>;
📝 Original message: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 at bitrefill.com> wrote:
> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87 at 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 at 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 at 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>;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221021/ee43dfba/attachment-0001.html>;