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 <ser...@bitrefill.com> wrote: > On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsander...@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> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
