diff options
| author | Eloy <eloyesp@gmail.com> | 2022-10-20 19:02:13 -0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-20 22:02:24 +0000 |
| commit | f502c380830d455c57ad8829a36539babf7668b4 (patch) | |
| tree | d11e5aa0cbd42acf8d6128dd00db34bbd4f1a835 | |
| parent | 8bb47e90c95dff55b543fad1fbb58f150bc049cf (diff) | |
| download | pi-bitcoindev-f502c380830d455c57ad8829a36539babf7668b4.tar.gz pi-bitcoindev-f502c380830d455c57ad8829a36539babf7668b4.zip | |
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
| -rw-r--r-- | be/a2cb3529b855ed64bf9d8b8e1243b03302b01b | 576 |
1 files changed, 576 insertions, 0 deletions
diff --git a/be/a2cb3529b855ed64bf9d8b8e1243b03302b01b b/be/a2cb3529b855ed64bf9d8b8e1243b03302b01b new file mode 100644 index 000000000..5657d4151 --- /dev/null +++ b/be/a2cb3529b855ed64bf9d8b8e1243b03302b01b @@ -0,0 +1,576 @@ +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> 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">> 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 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 <= +<a href=3D"mailto:bitcoin-dev@lists=2Elinuxfoundation=2Eorg">bitcoin-dev@li= +sts=2Elinuxfoundation=2Eorg</a>> 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> +> > If someone's going to systematically exploit your store via this= +<br> +> > mechanism, it seems like they'd just find a single wallet with a= + good<br> +> > UX for opt-in RBF and lowballing fees, and go to town -- not som= +ething<br> +> > where opt-in rbf vs fullrbf policies make any difference at all?= +<br> +> Sort of=2E But yes once this starts being abused systemically we will= + have to<br> +> do something else w RBF payments, such as crediting the amount in BTC= + to a<br> +> custodial account=2E But this option isn't available to your normal p= +ayment<br> +> processor type business=2E<br> +<br> +So, what I'm hearing is:<br> +<br> + * lightning works great, but is still pretty small<br> + * zeroconf works great for txs that opt-out of RBF<br> + * opt-in RBF is a pain for two reasons:<br> + - people don't like that it's not treated as zeroconf<br> + - the risk of fiat/BTC exchange rate changes between<br> + now and when the tx actually confirms is worrying<br> + 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> + "how can we make on-chain payments for goods priced in fiat work wel= +l<br> + 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> +> > I thought the "normal" avenue for fooling non-RBF zeroconf was t= +o create<br> +> > two conflicting txs in advance, one paying the merchant, one pay= +ing<br> +> > yourself, connect to many peers, relay the one paying the mercha= +nt to<br> +> > the merchant, and the other to everyone else=2E<br> +> > I'm just basing this off Peter Todd's stuff from years ago:<br> +> > <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> +> > <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> +> Yeah, I know the list still rehashes a single incident from 10 years = +ago to<br> +> declare the entire practice as unsafe, and ignores real-world data th= +at of<br> +> the last million transactions we had zero cases of this successfully<= +br> +> 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> +> > > Currently Lightning is somewhere around 15% of our total bi= +tcoin<br> +> > > payments=2E<br> +> > So, based on last year's numbers, presumably that makes your bit= +coin<br> +> > payments break down as something like:<br> +> > 5% txs are on-chain and seem shady and are excluded= + from zeroconf<br> +> > 15% txs are lightning<br> +> > 20% txs are on-chain but signal rbf and are excluded= + from zeroconf<br> +> > 60% txs are on-chain and seem fine for zeroconf<br> +> 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> +> RBF is a strictly worse UX as proven by anyone<br> +> 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> +> > > For me<br> +> > > personally it would be an easier discussion to have when Li= +ghtning is at<br> +> > > 80%+ of all bitcoin transactions=2E<br> +> > Can you extrapolate from the numbers you've seen to estimate whe= +n that<br> +> > might be, given current trends?<br> +> Not sure, it might be exponential growth, and the next 60% of Lightni= +ng<br> +> growth happen faster than the first 15%=2E Hard to tell=2E But we're = +likely<br> +> 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-- + |