path: root/be/a2cb3529b855ed64bf9d8b8e1243b03302b01b

Return-Path: <eloyesp@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DED17C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 22:02:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9873660C15
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 22:02:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9873660C15
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=ca20qsOc
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hviB-bkbkIqE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 22:02:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 65EE360BC1
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com
 [IPv6:2607:f8b0:4864:20::22f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 65EE360BC1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 22:02:21 +0000 (UTC)
Received: by mail-oi1-x22f.google.com with SMTP id g10so1167103oif.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 15:02:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=autocrypt:content-transfer-encoding:mime-version:message-id
 :references:in-reply-to:user-agent:subject:to:from:date:from:to:cc
 :subject:date:message-id:reply-to;
 bh=33wMeJ4OvwR+j5Ewv51UpngjvB9VS3YWg8Lqwgvz6V8=;
 b=ca20qsOcW4vmRy3uNGEjVr6QACmVNRgwiu/AQls2yXhQuC8mMwIpQBGSpa0HC4KNHj
 QO+7+eTm1FyDwMUbs74JhCFIQpzaZLk91usBGMhXzo+3vILexXjbVpR2wYFTixxJ6/61
 SAPCntGa6dmBRjPDc1CyvhV91Sh2ZQp94izFggLuNuPVMnT7LEOzQqTO5Lka93GJqwqn
 ttRaluKaNVzEmZA1J34EvzfcoQWlYZGakWd3f8AgNgSq29FfkzEk/87RAQAf1BsuigFK
 pqBq9jMvzxZ7N63KAbp1DVvfOYAIXPM5sdvzXJ4xAPmoTPN1TYSPw5dRjAEgz15xkBEz
 iEaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=autocrypt:content-transfer-encoding:mime-version:message-id
 :references:in-reply-to:user-agent:subject:to:from:date
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=33wMeJ4OvwR+j5Ewv51UpngjvB9VS3YWg8Lqwgvz6V8=;
 b=SjHBCUeJtJ7JG/uriBtVmM1vsrXhloSsHMb/f3/eVtoyLv4DLFk4Sae9dHt9t0j0I1
 6lcArIPdpdtDsfJ9skHw2/Af3X9g10FpdiBDsQSCkwqUPfSzihYna3XSZr2zZNCNxybN
 Ji5LilYhMKUwnRdiDylz2batrDHUGyyB8Py0OOH50RLW/gNGEUXYucAfXOGQyBW/eMlT
 /qy8JWqWRWILKK/Cno1DQbrgt3hcW9RkWgUTFRZ4KAgd0nTb2ZsctACGzE+Q5ghb0hyR
 TSAwIoL8GiMeEuFNJ8+JW8GXkShgsXMovxueQNtrgjN1mTT/gZqL+Ckk1F3LIsU/mkl8
 50FQ==
X-Gm-Message-State: ACrzQf3vzOl6SFYwRF5urFVojBO5oZG3HJfm35jjUiTFMgXW3NA2b9OF
 A5pllqGtN8x07fCwRmnJw2LZq/uKTdE=
X-Google-Smtp-Source: AMsMyM6jqg0VD+hUskMpzC/UABxodP+CIeMfy8zmmuVY8B9BipUe71E9cv+OzBMQmNjqqKHDACUjPw==
X-Received: by 2002:aca:3608:0:b0:34f:bb9b:cdc9 with SMTP id
 d8-20020aca3608000000b0034fbb9bcdc9mr8537037oia.261.1666303340098; 
 Thu, 20 Oct 2022 15:02:20 -0700 (PDT)
Received: from [127.0.0.1] ([186.12.97.33]) by smtp.gmail.com with ESMTPSA id
 e25-20020aca1319000000b00342eade43d4sm444612oii.13.2022.10.20.15.02.18
 for <bitcoin-dev@lists.linuxfoundation.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Oct 2022 15:02:19 -0700 (PDT)
Date: Thu, 20 Oct 2022 19:02:13 -0300
From: Eloy <eloyesp@gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAB3F3DtbxXiHW0GxtaVMMtAo5X7ZcsCPR7odVnwz50qw_3oCLg@mail.gmail.com>
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
 <Y1D3OkdsCq2pLduG@erisian.com.au>
 <CABZBVTBupMcBbOUtLbMaEmAiWGsMwisNW+k+bTUJGsUad2=ZZg@mail.gmail.com>
 <Y1Gocf216O+yKqqS@erisian.com.au>
 <CAB3F3DtbxXiHW0GxtaVMMtAo5X7ZcsCPR7odVnwz50qw_3oCLg@mail.gmail.com>
Message-ID: <874FE3CC-5F27-40A2-9BD3-FD9937C1A40D@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary=----K0KL030ENUOIRF3FI4W8MZAZG7IBWN
Content-Transfer-Encoding: 7bit
Autocrypt: addr=eloyesp@gmail.com; keydata=
 mQGNBFp4kysBDAD0oZA5ojIBuhdncQwZKGPMJIl6m4UoiUzv7duv5i1mDTgV6ItkFpsjRl+4A+5s
 3vTwLAqYhE+J27GsLwA0h5Gm7d32USX7SScQ+I+zvLPTyKCRBSWoVE+f6nwaPLGbBGa8t7Aobla2
 CZrFGptoBjgOOBwu5mDqa88c/bxrkgWa+mF/+libTx3+AdnI71YtBkEA0VfIOs4E67WSuEyfxto3
 k+vhOYe4DXQ6PDD97+mnAxrhG90wQ/WUmgDA+Q6lbdWmO41V4j3KO31EVHGL6BiwnFIXfrMVM+pb
 RJ1o0AsqEx7+yEROTBsKy6j0V31M35j6ByGKZitAJs39FtTMTExbW9JCgtscQW0AkwnmbCDJxYEm
 RAbuqEZFsDFXmZD4C4dyXiO+gxKXSc6fy2Leusxh1cxpxdgRC4zlzBUHxDUgEzq3afNjxUkvQAk7
 p9IpblpiLeiHlqKwA8XNGcB3BRUvv2WERAyyd+Qg9In+vu0vaODFp7rUeqtQ8KMdOBTqBXEAEQEA
 AbQhRWxveSBFc3BpbmFjbyA8ZWxveWVzcEBnbWFpbC5jb20+iQHUBBMBCgA+AhsDBQsJCAcCBhUK
 CQgLAgQWAgMBAh4BAheAFiEED+YFPqF1uItVRsYBTjocMAZOZ0IFAmIotDcFCQoBY/8ACgkQTjoc
 MAZOZ0Kn2Qv+OgpURwEp/HKHP4GDgPVZDUS1Jq2Vpb8dIV7xzUZ9bcSK0WL4rF1+aLxRf1kj2Gy4
 6+X43S7AZg78Lic/AL7FGicPHTJ8SaQGbG244SStJsHhbC4RcMJ9gP2KO+Xc6Rj24988bopGkCpR
 +K3brkL+O3iRsBYpwEGrPjir6fssspVgQEKpjrGSbVm2A/xcBSOxIrCQA65nAhCXctDg1rdr5oba
 Uf3rMhb7MRyfTlaTFVelN9wJ05jktl38SAxifLUPVYA+JK1VhhvlHgImH5vqPbPdtiqpMRQEI7ti
 JwPubeCton0MZC+UqXDDcIqHX11cdK7roJfYOBy1ccouEMPzNvIperCZaq896qm3wM+FXgRiIfT6
 FQgReNyXobfJN2MJ6hw3ixox3i7k86BJGdugVLa3JCEA2iKPlCYybGtM2TTazLcGAiBXCGkd6QFK
 m/u7sckVx5NaSyY6NXZXv1Pg6wEElyGgz7zOS6YhADLZtYP0aLgKPica0nzkaf/8L6quuQGNBF5Z
 HGQBDAD0HsEdHmDk/Da3YdBA23POyUDcM8kMCWVCWV+u4A5GGogbrvcEkjhMp1VL5QrWc0XVuEp3
 VXH/TfHGPE5pNiqvyQbk+bEoHcpm9OXGLBGPy084YvkAjAP5Y1J/TwCPpyZFEdXo9E9gj+BUd870
 rwmyFJI1Qnz9Ol2UcoF8KhZ9GeLoHL21IoDPGCVsv91c9mUBjbwp7bbZqr8PaIeTbryIaPuyHKXL
 aWNc8c9U0c26Fg14bokiv2Pg0ZVrPAEJXNlwLYRxZwAuYKGNzUA4w3GZMPnSZlhFgzOzd2OD4VAp
 1xkVvYb97HlSqRIqdxBVqOt2EFL2yiu7zTwyD/26L+D78czuzsJvFaNozhUnb3GaB5d2QDCEZzZh
 wIvF2jPdrs9q71SGDOsex+tUQG7DgWw0SGhfkLoOnLETLi58FdTrjYP0KVD9QPOWmAk9tUy6t6nU
 ZpXOKmP285DaS8VaaeUq7q8woV2l04ALU0YUMMfgd2A7Q6N/eKE1AwcoYb670JsAEQEAAYkBvAQY
 AQoAJgIbDBYhBA/mBT6hdbiLVUbGAU46HDAGTmdCBQJgwMYwBQkGKhDMAAoJEE46HDAGTmdC3FQL
 /2qJkYqvw+c1K6l1Uiivb49eb88C0UVr98W3sMNBDH9zV4caf8ySmLu0cxM/TFcN5mhHSaQZhu0y
 F9lFWiv4g60eW4jFRllNQGr8qeG1fvDWmYzDaQ+pM50WQM3dy65+JJMBwQsL3SJlnO7p3ltly53D
 zmSWL8XwQnn0Tc/exc2w5xiaHFQgQsoBgJxTc98QhJExFfKSI9AV50zElGdBrWZ4Kq57j+NoN/OV
 q1BPvSNmkd66UTpUxgD0OLKpRLu5kmtxjnV3/dHtKbS1YWylhwHJGF+Q4B9+QAtbhTK2L3v+A14A
 UHrcb/O/0PFvYMI8yJGo+QZ87oAFlklm8U1NEODPx3VJzoFL0/6Dj4bZX/Jwo5UnxDGpRuAObEnq
 WMV7VoDBVIZWAnU+BW8woNMoBL8llShWeiRk78AlB3DSgzoIyPVOTPQNH9+BokCirODfD5Pts1lT
 AgUKWCKRmF9Fa7IZcA+SJ5doA13it0ldvUTiJgNK4FwrX8ILMEh+TJiCag==
X-Mailman-Approved-At: Thu, 20 Oct 2022 22:03:49 +0000
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in
	immediate	danger
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2022 22:02:25 -0000

------K0KL030ENUOIRF3FI4W8MZAZG7IBWN
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

There is obviously an alternative approach to the issue=2E

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=
=2E 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 blo=
ck (so it have less chances to win)=2E That would make the network decide w=
hen it is the time to deploy RBF=2E

It seems obvious for me that most devs prefer full RBF to force users to u=
se centralized stuff (that is why the full RBF option is there already on c=
ore), but just wanted to make that clear that there is always a way to enfo=
rce a policy (read to keep zero conf working)=2E

Regards=2E

El 20 de octubre de 2022 18:07:07 ART, Greg Sanders via bitcoin-dev <bitco=
in-dev@lists=2Elinuxfoundation=2Eorg> escribi=C3=B3:
>> If it were growing in line with lightning capacity in BTC, per
>bitcoinvisuals=2Ecom/ln-capacity; then 15% now would have grown from
>perhaps 4% in May 2021, so perhaps 8% per year=2E With linear growth,
>getting from 15% to 80% would then be about 8 years=2E
>
>I'd caution against any metrics-based approach like this, unless it's
>simply used for ballparking potential adoption curves to set a a timefram=
e
>people can live with=2E
>
>A large number of coins/users sit on custodial rails and this would
>essentially encumber protocol developers to those KYC/AML institutions=2E=
 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=2Elinuxfoundation=2Eorg> wrote:
>
>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-de=
v
>> 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 go=
od
>> > > UX for opt-in RBF and lowballing fees, and go to town -- not someth=
ing
>> > > where opt-in rbf vs fullrbf policies make any difference at all?
>> > Sort of=2E 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=2E But this option isn't available to your normal p=
ayment
>> > processor type business=2E
>>
>> 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 collaborati=
on
>> 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 w=
e
>> 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 bas=
ed
>> so that both parties are confident a fair exchange rate will be used?)=
=2E
>>
>> 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 coul=
d
>> 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=2E
>> > > I'm just basing this off Peter Todd's stuff from years ago:
>> > >
>> https://np=2Ereddit=2Ecom/r/Bitcoin/comments/40ejy8/peter_todd_with_my_=
doublespendpy_tool_with/cytlhh0/
>> > >
>> https://github=2Ecom/petertodd/replace-by-fee-tools/blob/master/doubles=
pend=2Epy
>> > 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 th=
at
>> of
>> > the last million transactions we had zero cases of this successfully
>> > abusing us=2E
>>
>> 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 connec=
t
>> 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=2E So it doesn't surprise m=
e
>> at all that it's not often attempted, and even less often successful=2E
>>
>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
>> > > > payments=2E
>> > > So, based on last year's numbers, presumably that makes your bitcoi=
n
>> > > payments break down as something like:
>> > >    5% txs are on-chain and seem shady and are excluded from zerocon=
f
>> > >   15% txs are lightning
>> > >   20% txs are on-chain but signal rbf and are excluded from zerocon=
f
>> > >   60% txs are on-chain and seem fine for zeroconf
>> > Numbers are right=2E Shady is too strong a word,
>>
>> Heh, fair enough=2E
>>
>> 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)=2E =
And
>> going full rbf would bump that from 25% to 85%, which would be pretty
>> terrible=2E
>>
>> > RBF is a strictly worse UX as proven by anyone
>> > accepting bitcoin payments at scale=2E
>>
>> 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=2E
>>
>> > > > For me
>> > > > personally it would be an easier discussion to have when Lightnin=
g
>> is at
>> > > > 80%+ of all bitcoin transactions=2E
>> > > Can you extrapolate from the numbers you've seen to estimate when t=
hat
>> > > might be, given current trends?
>> > Not sure, it might be exponential growth, and the next 60% of Lightni=
ng
>> > growth happen faster than the first 15%=2E Hard to tell=2E But we're =
likely
>> > talking years here=2E=2E
>>
>> Okay? Two years is very different from 50 years, and at the moment ther=
e's
>> not really any data, so people are just going to go with their gut=2E=
=2E=2E
>>
>> If it were growing in line with lightning capacity in BTC, per
>> bitcoinvisuals=2Ecom/ln-capacity; then 15% now would have grown from
>> perhaps 4% in May 2021, so perhaps 8% per year=2E With linear growth,
>> getting from 15% to 80% would then be about 8 years=2E
>>
>> Presumably that's a laughably terrible model, of course=2E But if we ha=
d
>> 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=2Elinuxfoundation=2Eorg
>> https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
>>

--=20
Enviado desde mi dispositivo Android con K-9 Mail=2E Por favor, disculpa m=
i brevedad=2E
------K0KL030ENUOIRF3FI4W8MZAZG7IBWN
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body>There is obviously an alternative approach to the =
issue=2E<br><br>If we like opt-in RBF and would like to keep opt out RBF 0C=
ONF working, we could add another option to punish those nodes that replace=
 transactions=2E That is, a miner that publishes a block with a NO RBF, tha=
t is replaced (that is easy to check for a full node) could stop propagatio=
n of that block (so it have less chances to win)=2E That would make the net=
work decide when it is the time to deploy RBF=2E<br><br>It seems obvious fo=
r 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 wante=
d to make that clear that there is always a way to enforce a policy (read t=
o keep zero conf working)=2E<br><br>Regards=2E<br><br><div class=3D"gmail_q=
uote">El 20 de octubre de 2022 18:07:07 ART, Greg Sanders via bitcoin-dev &=
lt;bitcoin-dev@lists=2Elinuxfoundation=2Eorg&gt; escribi=C3=B3:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir=3D"ltr">&gt; If it were growing in line with lightning capacity i=
n BTC, per<br><a href=3D"http://bitcoinvisuals=2Ecom/ln-capacity" rel=3D"no=
referrer" target=3D"_blank">bitcoinvisuals=2Ecom/ln-capacity</a>; then 15% =
now would have grown from<br>perhaps 4% in May 2021, so perhaps 8% per year=
=2E With linear growth,<br>getting from 15% to 80% would then be about 8 ye=
ars=2E<div><br></div><div>I'd caution against any metrics-based approach li=
ke this, unless it's simply used for ballparking potential adoption curves =
to set a a timeframe people&nbsp;can live with=2E</div><div><br></div><div>=
A large number of coins/users sit on custodial rails and this would essenti=
ally encumber protocol developers to those KYC/AML institutions=2E If Binan=
ce decides to never support Lightning in favor of BNC-wrapped BTC, should t=
his be an issue at all for reasoning about a path forward? <br></div><div><=
br></div><div>Hoping to be wrong,</div><div>Greg</div><div><br></div><div><=
br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev &lt;=
<a href=3D"mailto:bitcoin-dev@lists=2Elinuxfoundation=2Eorg">bitcoin-dev@li=
sts=2Elinuxfoundation=2Eorg</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0=2E8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">On Thu, Oct 20, 2022 at 02:37:53PM +0200, Serg=
ej Kotliar via bitcoin-dev wrote:<br>
&gt; &gt; If someone's going to systematically exploit your store via this=
<br>
&gt; &gt; mechanism, it seems like they'd just find a single wallet with a=
 good<br>
&gt; &gt; UX for opt-in RBF and lowballing fees, and go to town -- not som=
ething<br>
&gt; &gt; where opt-in rbf vs fullrbf policies make any difference at all?=
<br>
&gt; Sort of=2E But yes once this starts being abused systemically we will=
 have to<br>
&gt; do something else w RBF payments, such as crediting the amount in BTC=
 to a<br>
&gt; custodial account=2E But this option isn't available to your normal p=
ayment<br>
&gt; processor type business=2E<br>
<br>
So, what I'm hearing is:<br>
<br>
&nbsp;* lightning works great, but is still pretty small<br>
&nbsp;* zeroconf works great for txs that opt-out of RBF<br>
&nbsp;* opt-in RBF is a pain for two reasons:<br>
&nbsp; &nbsp; - people don't like that it's not treated as zeroconf<br>
&nbsp; &nbsp; - the risk of fiat/BTC exchange rate changes between<br>
&nbsp; &nbsp; &nbsp; now and when the tx actually confirms is worrying<br>
&nbsp; &nbsp; &nbsp; even if it hasn't caused real problems yet<br>
<br>
(Please correct me if that's too far wrong)<br>
<br>
Maybe it would be productive to explore this opt-in RBF part a bit<br>
more? ie, see if "we" can come up with better answers to some question<br>
along the lines of:<br>
<br>
&nbsp;"how can we make on-chain payments for goods priced in fiat work wel=
l<br>
&nbsp; for payees that opt-in to RBF?"<br>
<br>
That seems like the sort of thing that's better solved by a collaboration<=
br>
between wallet devs and merchant devs (and protocol devs?), rather than<br=
>
just one or the other?<br>
<br>
Is that something that we could talk about here? Or maybe it's better<br>
done via an optech workgroup or something?<br>
<br>
If "we'll credit your account in BTC, then work out the USD coversion<br>
and deduct that for your purchase, then you can do whatever you like<br>
with any remaining BTC from your on-chain payment" is the idea, maybe we<b=
r>
should just roll with that design, but make it more decentralised: have<br=
>
the initial payment setup a lightning channel between the customer and<br>
the merchant with the BTC (so it's not custodial), but do some magic to<br=
>
allow USD amounts to be transferred over it (Taro? something oracle based<=
br>
so that both parties are confident a fair exchange rate will be used?)=2E<=
br>
<br>
Maybe that particular idea is naive, but having an actual problem to<br>
solve seems more constructive than just saying "we want rbf" "but we<br>
want zeroconf" all the time?<br>
<br>
(Ideally the lightning channels above would be dual funded so they could<b=
r>
be used for routing more generally; but then dual funded channels are<br>
one of the things that get broken by lack of full rbf)<br>
<br>
&gt; &gt; I thought the "normal" avenue for fooling non-RBF zeroconf was t=
o create<br>
&gt; &gt; two conflicting txs in advance, one paying the merchant, one pay=
ing<br>
&gt; &gt; yourself, connect to many peers, relay the one paying the mercha=
nt to<br>
&gt; &gt; the merchant, and the other to everyone else=2E<br>
&gt; &gt; I'm just basing this off Peter Todd's stuff from years ago:<br>
&gt; &gt; <a href=3D"https://np=2Ereddit=2Ecom/r/Bitcoin/comments/40ejy8/p=
eter_todd_with_my_doublespendpy_tool_with/cytlhh0/" rel=3D"noreferrer" targ=
et=3D"_blank">https://np=2Ereddit=2Ecom/r/Bitcoin/comments/40ejy8/peter_tod=
d_with_my_doublespendpy_tool_with/cytlhh0/</a><br>
&gt; &gt; <a href=3D"https://github=2Ecom/petertodd/replace-by-fee-tools/b=
lob/master/doublespend=2Epy" rel=3D"noreferrer" target=3D"_blank">https://g=
ithub=2Ecom/petertodd/replace-by-fee-tools/blob/master/doublespend=2Epy</a>=
<br>
&gt; Yeah, I know the list still rehashes a single incident from 10 years =
ago to<br>
&gt; declare the entire practice as unsafe, and ignores real-world data th=
at of<br>
&gt; the last million transactions we had zero cases of this successfully<=
br>
&gt; abusing us=2E<br>
<br>
I mean, the avenue above isn't easy to exploit -- you have to identify<br>
the merchant's node so that they get the bad tx, and you have to connect<b=
r>
to many peers so that your preferred tx propogates to miners first --<br>
and probably more importantly, it's relatively easy to detect -- if the<br=
>
merchant has a few passive nodes that the attacker doesn't know about<br>
it, and uses those to watch for attempted doublespends while it tries<br>
to ensure the real tx has propogated widely=2E So it doesn't surprise me<b=
r>
at all that it's not often attempted, and even less often successful=2E<br=
>
<br>
&gt; &gt; &gt; Currently Lightning is somewhere around 15% of our total bi=
tcoin<br>
&gt; &gt; &gt; payments=2E<br>
&gt; &gt; So, based on last year's numbers, presumably that makes your bit=
coin<br>
&gt; &gt; payments break down as something like:<br>
&gt; &gt;&nbsp; &nbsp; 5% txs are on-chain and seem shady and are excluded=
 from zeroconf<br>
&gt; &gt;&nbsp; &nbsp;15% txs are lightning<br>
&gt; &gt;&nbsp; &nbsp;20% txs are on-chain but signal rbf and are excluded=
 from zeroconf<br>
&gt; &gt;&nbsp; &nbsp;60% txs are on-chain and seem fine for zeroconf<br>
&gt; Numbers are right=2E Shady is too strong a word,<br>
<br>
Heh, fair enough=2E<br>
<br>
So the above suggests 25% of payments already get a sub-par experience,<br=
>
compared to what you'd like them to have (which sucks, but if you're<br>
trying to reinvent both money and payments, maybe isn't surprising)=2E And=
<br>
going full rbf would bump that from 25% to 85%, which would be pretty<br>
terrible=2E<br>
<br>
&gt; RBF is a strictly worse UX as proven by anyone<br>
&gt; accepting bitcoin payments at scale=2E<br>
<br>
So let's make it better? Building bitcoin businesses on the lie that<br>
unconfirmed txs are safe and won't be replaced is going to bite us<br>
eventually; focussing on trying to push that back indefinitely is just<br>
going to make everyone less prepared when it eventually happens=2E<br>
<br>
&gt; &gt; &gt; For me<br>
&gt; &gt; &gt; personally it would be an easier discussion to have when Li=
ghtning is at<br>
&gt; &gt; &gt; 80%+ of all bitcoin transactions=2E<br>
&gt; &gt; Can you extrapolate from the numbers you've seen to estimate whe=
n that<br>
&gt; &gt; might be, given current trends?<br>
&gt; Not sure, it might be exponential growth, and the next 60% of Lightni=
ng<br>
&gt; growth happen faster than the first 15%=2E Hard to tell=2E But we're =
likely<br>
&gt; talking years here=2E=2E<br>
<br>
Okay? Two years is very different from 50 years, and at the moment there's=
<br>
not really any data, so people are just going to go with their gut=2E=2E=
=2E<br>
<br>
If it were growing in line with lightning capacity in BTC, per<br>
<a href=3D"http://bitcoinvisuals=2Ecom/ln-capacity" rel=3D"noreferrer" tar=
get=3D"_blank">bitcoinvisuals=2Ecom/ln-capacity</a>; then 15% now would hav=
e grown from<br>
perhaps 4% in May 2021, so perhaps 8% per year=2E With linear growth,<br>
getting from 15% to 80% would then be about 8 years=2E <br>
<br>
Presumably that's a laughably terrible model, of course=2E But if we had<b=
r>
some actual numbers where we can watch the progress, it might be a lot<br>
easier to be patient about waiting for lightning adoption to hit 80%<br>
or whatever, and focus on productive things in the meantime?<br>
<br>
Cheers,<br>
aj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists=2Elinuxfoundation=2Eorg" target=3D"_bl=
ank">bitcoin-dev@lists=2Elinuxfoundation=2Eorg</a><br>
<a href=3D"https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists=2Elinuxfoundation=
=2Eorg/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div><div style=3D'white-space: pre-wrap'><div class=3D'k9ma=
il-signature'>-- <br>Enviado desde mi dispositivo Android con K-9 Mail=2E P=
or favor, disculpa mi brevedad=2E</div></div></body></html>
------K0KL030ENUOIRF3FI4W8MZAZG7IBWN--