path: root/d5/bcfddcbc88e4a2008355cc20a2e725510e1113

Return-Path: <sergej@bitrefill.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 54F06C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:17:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 1FF188432B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:17:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1FF188432B
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=bitrefill.com header.i=@bitrefill.com
 header.a=rsa-sha256 header.s=b header.b=IbZQ3kgR
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Tf24G-_nlDw8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:17:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 525378432A
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
 [IPv6:2a00:1450:4864:20::130])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 525378432A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:17:37 +0000 (UTC)
Received: by mail-lf1-x130.google.com with SMTP id be13so18192706lfb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 07:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitrefill.com; s=b;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=1kHb9/hOnaEoXobz/M/EFLti8wBqJNH1IcQHyK/eIFA=;
 b=IbZQ3kgRSmPrNByGTQgpzS5PhqWG7oSvGD17cV5g0K5hz7YSL6zmIpgTsNcqo7Zyhm
 0nnHnjwE573hNs4CiCD+K+nlJ+FVyhTyec5Xx31ustsnr+1KHtmzvA4EE3M8wsW52+i1
 xDyEABbQfpSj9v6z4jumTTT3p6MTS4cdDy9WWOvaUHQ48xpTCHp07LojlQMvEMFs2Pp9
 UOgNpcrcHZ7a56OnNw3MGTQemfO43NsrTKniyJihDSsb4Q3P58k/nFzGRV4L5xttFlzQ
 tiHczbO2keaq3ve5SC09feQnFrXiv1YBqa89gQHwpI5RQQajPqTG6Z82JEajeLYdBIcn
 w+Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=1kHb9/hOnaEoXobz/M/EFLti8wBqJNH1IcQHyK/eIFA=;
 b=pPWi+c1EoK2Ev6VFHYjYkJN0ylgGFfu3dlJToebUeAn3wdR4TMybqer4+fCxMTXDhW
 FiTqrjfpH7wHk7+boUz0hu8yStzUG1C523/cG9ziYIzNvtb52YhUQrTojSjw2rXCc8r0
 B3841EiRp3q0xfaqAlSh+NgiaYC4PN6qPITY6iddfowl3V034rMm2Gs9OLAwxqPazHwq
 IHg9V7t9O72bcm9W+mycdkTFeSSU5p4z9R+Iuar5jtC3BbJurdg14O+WhbAgHVSQU+vs
 CY+rE8uOxKXete4HKhr54JJdLBmOJLLjaMnDR2NszFFKxIHHF1+yTE03PXUbnXFeRiI4
 90iw==
X-Gm-Message-State: ACrzQf1zhDxAHWMiApuAG/o6q5Cs10D06/lwLo+ETHqJLRObqMq4YMAx
 jXPCwjlBwpu44JfJOaHiBkmegBFmzSuYz8Un1CvOAw==
X-Google-Smtp-Source: AMsMyM6cvdYPoxwnpfplaUNsG+BqyWdD4zhvyU1u4Rd3OUfz6TwNAIMnDA1ZYYLyPiHXvezjVBaqV+2Ffxq3r4HtZkM=
X-Received: by 2002:a05:6512:b9e:b0:4a2:9853:b87f with SMTP id
 b30-20020a0565120b9e00b004a29853b87fmr4547260lfv.257.1666275455166; Thu, 20
 Oct 2022 07:17:35 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
 <Y1D3OkdsCq2pLduG@erisian.com.au>
 <CABZBVTBupMcBbOUtLbMaEmAiWGsMwisNW+k+bTUJGsUad2=ZZg@mail.gmail.com>
 <CAPv7TjZDzQaF=Yf6R6_D8AAmKkFHmSn0_0=LhOW386L2awj2Hw@mail.gmail.com>
In-Reply-To: <CAPv7TjZDzQaF=Yf6R6_D8AAmKkFHmSn0_0=LhOW386L2awj2Hw@mail.gmail.com>
From: Sergej Kotliar <sergej@bitrefill.com>
Date: Thu, 20 Oct 2022 16:17:23 +0200
Message-ID: <CABZBVTDf3hCdiZSQdMeRj7U4c_HDBLvTruyyBSB_YmPAkAGuZw@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009a863205eb77fcac"
X-Mailman-Approved-At: Thu, 20 Oct 2022 14:21:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
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 14:17:40 -0000

--0000000000009a863205eb77fcac
Content-Type: text/plain; charset="UTF-8"

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>

--0000000000009a863205eb77fcac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It&#39;s a good idea in theory, the issue is that most wal=
lets and services bitcoin users use today to send bitcoin don&#39;t use sol=
utions to that. So we end up with &quot;you need to use X wallet to buy stu=
ff&quot;, which is equivalent to &quot;you need to use a Lightning wallet t=
o buy stuff&quot;</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Thu, 20 Oct 2022 at 16:14, Ruben Somsen &lt;<a href=3D"=
mailto:rsomsen@gmail.com">rsomsen@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi,</div><=
div><br></div>There is a reasonable tradeoff one can make to get eventual s=
ettlement assurance prior to confirmation: lock up the funds with a counter=
party in a 2-of-2 multisig with a timelock back to the owner. As long as th=
e 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 t=
he same person, this solution=C2=A0is trustless. Since merchant purchases t=
end to be low-value, the counterparty risk (facilitating double spends) see=
ms acceptable. GreenAddress provided such a service in 2015 or so, but the =
idea got abandoned.<div><br></div><div>Personally, I find this solution muc=
h more tenable than relying on spurious network assumptions about what will=
 be propagated and mined.<br><br><div>Best regards,</div><div>Ruben<br><div=
><br></div><div><br></div></div></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 20, 2022 at 2:44 PM Serge=
j Kotliar via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div></div><div class=3D"gmail_quote"><span style=3D"color:rgb(80,=
0,80)"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 20 Oct 2022 at 09:22, =
Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj=
@erisian.com.au</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via=
 bitcoin-dev wrote:<br>&gt; The<br>&gt; biggest risk in accepting bitcoin p=
ayments is in fact not zeroconf risk<br>&gt; (it&#39;s actually quite easil=
y managed),<br><br>You mean &quot;it&#39;s quite easily managed, provided t=
he transaction doesn&#39;t<br>opt-in to rbf&quot;, right? At least, that&#3=
9;s what I understood you saying last<br>time; ie that if the tx signals rb=
f, then you just don&#39;t do zeroconf no<br>matter what other trustworthy =
signals you might see:<br><br>=C2=A0=C2=A0<a href=3D"https://twitter.com/zi=
ggamon/status/1435863691816275970" rel=3D"noreferrer" target=3D"_blank">htt=
ps://twitter.com/ziggamon/status/1435863691816275970</a><br><br>(rbf txs se=
em to have increased from 22% then to 29% now)<br></blockquote><div><br></d=
iv></span><div>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&#39;t do RBF</div><span style=3D"color:rgb(80,0,80)"><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; it&#39;s=
 FX risk as the merchant must<br>&gt; commit to a certain BTCUSD rate ahead=
 of time for a purchase. Over time<br>&gt; some transactions lose money to =
FX and others earn money - that evens out<br>&gt; in the end.<br><br>&gt; B=
ut if there is an _easily accessible in the wallet_ feature to<br>&gt; &quo=
t;cancel transaction&quot; that means it will eventually get systematically=
<br>&gt; abused. A risk of X% loss on many payments that&#39;s easy to syst=
ematically<br>&gt; abuse is more scary than a rare risk of losing 100% of o=
ne occasional<br>&gt; payment. It&#39;s already possible to execute this fo=
rm of abuse with opt-in<br>&gt; RBF,<br><br>If someone&#39;s going to syste=
matically exploit your store via this<br>mechanism, it seems like they&#39;=
d just find a single wallet with a good<br>UX for opt-in RBF and lowballing=
 fees, and go to town -- not something<br>where opt-in rbf vs fullrbf polic=
ies make any difference at all?<br></blockquote><div><br></div></span><div>=
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&#39;t available to your normal paym=
ent processor type business.=C2=A0</div><div><br></div><div>Also worth keep=
ing in mind that sometimes &quot;opportunity makes the thief&quot;. Current=
ly only power-user wallet have that feature and their market share is relat=
ively small, mainly electrum stands out. But if this is available to all us=
ers everywhere then it will start being abused and we&#39;ll have to then d=
irect all payments to custodial account, or some other convoluted solution.=
</div><span style=3D"color:rgb(80,0,80)"><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">It&#39;s not like existing wallets that do=
n&#39;t let you set RBF will suddenly<br>get a good UX for replacing transa=
ctions just because they&#39;d be relayed<br>if they did, is it?<br><br>&gt=
; To successfully fool (non-RBF)<br>&gt; zeroconf one needs to have access =
to mining infrastructure and probability<br>&gt; of success is the % of has=
h rate controlled.<br><br>I thought the &quot;normal&quot; avenue for fooli=
ng non-RBF zeroconf was to create<br>two conflicting txs in advance, one pa=
ying the merchant, one paying<br>yourself, connect to many peers, relay the=
 one paying the merchant to<br>the merchant, and the other to everyone else=
.<br><br>I&#39;m just basing this off Peter Todd&#39;s stuff from years ago=
:<br><br><a href=3D"https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_t=
odd_with_my_doublespendpy_tool_with/cytlhh0/" rel=3D"noreferrer" target=3D"=
_blank">https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_=
doublespendpy_tool_with/cytlhh0/</a><br><br><a href=3D"https://github.com/p=
etertodd/replace-by-fee-tools/blob/master/doublespend.py" rel=3D"noreferrer=
" target=3D"_blank">https://github.com/petertodd/replace-by-fee-tools/blob/=
master/doublespend.py</a>=C2=A0<br></blockquote><div><br></div></span><div>=
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 abusi=
ng us.</div><span style=3D"color:rgb(80,0,80)"><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">&gt; Currently Lightning is somewher=
e around 15% of our total bitcoin payments.<br><br>So, based on last year&#=
39;s numbers, presumably that makes your bitcoin<br>payments break down as =
something like:<br><br>=C2=A0 =C2=A05% txs are on-chain and seem shady and =
are excluded from zeroconf<br>=C2=A0 15% txs are lightning<br>=C2=A0 20% tx=
s are on-chain but signal rbf and are excluded from zeroconf<br>=C2=A0 60% =
txs are on-chain and seem fine for zeroconf<br></blockquote><div><br></div>=
</span><div>Numbers are right. Shady is too strong a word, it&#39;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 asse=
ssment of the support ticket and often just pass them through.=C2=A0</div><=
span style=3D"color:rgb(80,0,80)"><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">&gt; This is very much not nothing, and all of us=
 here want Lightning to grow,<br>&gt; but I think it warrants a serious dis=
cussion on whether we want Lightning<br>&gt; adoption to go to 100% by mean=
s of disabling on-chain commerce.<br><br>If the numbers above were accurate=
, this would just mean you&#39;d go from 60%<br>zeroconf/25% not-zeroconf t=
o 85% not-zeroconf; wouldn&#39;t be 0% on-chain.<br></blockquote><div><br><=
/div></span><div>Point is that RBF transactions are unsafe even when waitin=
g for a confirmation, which Peter Todd trivially proved in the reply next t=
o this. The reliable solution is to reject all RBF payments and direct thos=
e 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 a=
nyone accepting bitcoin payments at scale.</div><span style=3D"color:rgb(80=
,0,80)"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
&gt; For me<br>&gt; personally it would be an easier discussion to have whe=
n Lightning is at<br>&gt; 80%+ of all bitcoin transactions.<br><br>Can you =
extrapolate from the numbers you&#39;ve seen to estimate when that<br>might=
 be, given current trends?=C2=A0<br></blockquote><div><br></div></span><div=
>Not sure, it might be exponential growth, and the next 60% of Lightning gr=
owth happen faster than the first 15%. Hard to tell. But we&#39;re likely t=
alking years here..=C2=A0</div><span style=3D"color:rgb(80,0,80)"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>&gt; The ben=
efits of Lightning are many and obvious,<br>&gt; we don&#39;t need to limit=
 onchain to make Lightning more appealing.<br><br>To be fair, I think makin=
g lightning (and coinjoins) work better is<br>exactly what inspired this --=
 not as a &quot;make on-chain worse so we look<br>better in comparison&quot=
;, but as a &quot;making lightning work well is a bunch<br>of hard problems=
, here&#39;s the next thing we need in order to beat the<br>next problem&qu=
ot;.<br></blockquote><div><br></div></span><div>In deed. The fact that the =
largest non-custodial Lightning wallet started this thread should be an ind=
icator that despite these intentions the solution harms more than it fixes.=
</div><div><div style=3D"margin:5px 0px"><div id=3D"m_-179668769666992398m_=
3388081098041139380gmail-q_1683" style=3D"background-color:rgb(232,234,237)=
;border:none;clear:both;line-height:6px;outline:none;width:24px;color:rgb(8=
0,0,80);font-size:11px;border-radius:5.5px"><div style=3D"background:url(&q=
uot;https://www.gstatic.com/images/icons/material/system_gm/1x/more_horiz_b=
lack_20dp.png&quot;) 50% 50%/20px no-repeat;height:11px;opacity:0.71;width:=
24px"></div></div></div></div><div>Transactions being evicted from mempool =
is solved by requiring a minimum fee rate, which we do and now seems to hav=
e become a=C2=A0standard practice. Theoretically we can imagine them being =
evicted anyway but now we&#39;re several theoreticals deep again when discu=
ssing something that will cause massive problems right away. In emergency s=
ituations CPFP and similar can of course be done manually in special=C2=A0c=
ircumstances.</div><div>=C2=A0</div><div>Cheers</div><font color=3D"#888888=
"><div>Sergej</div></font></div><div style=3D"outline:none;padding:10px 0px=
;width:22px;margin:2px 0px 0px"><br></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 20 Oct 2022 at 09:22, Ant=
hony Towns &lt;<a href=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj@er=
isian.com.au</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bi=
tcoin-dev wrote:<br>
&gt; The<br>
&gt; biggest risk in accepting bitcoin payments is in fact not zeroconf ris=
k<br>
&gt; (it&#39;s actually quite easily managed),<br>
<br>
You mean &quot;it&#39;s quite easily managed, provided the transaction does=
n&#39;t<br>
opt-in to rbf&quot;, right? At least, that&#39;s what I understood you sayi=
ng last<br>
time; ie that if the tx signals rbf, then you just don&#39;t do zeroconf no=
<br>
matter what other trustworthy signals you might see:<br>
<br>
=C2=A0 <a href=3D"https://twitter.com/ziggamon/status/1435863691816275970" =
rel=3D"noreferrer" target=3D"_blank">https://twitter.com/ziggamon/status/14=
35863691816275970</a><br>
<br>
(rbf txs seem to have increased from 22% then to 29% now)<br>
<br>
&gt; it&#39;s FX risk as the merchant must<br>
&gt; commit to a certain BTCUSD rate ahead of time for a purchase. Over tim=
e<br>
&gt; some transactions lose money to FX and others earn money - that evens =
out<br>
&gt; in the end.<br>
<br>
&gt; But if there is an _easily accessible in the wallet_ feature to<br>
&gt; &quot;cancel transaction&quot; that means it will eventually get syste=
matically<br>
&gt; abused. A risk of X% loss on many payments that&#39;s easy to systemat=
ically<br>
&gt; abuse is more scary than a rare risk of losing 100% of one occasional<=
br>
&gt; payment. It&#39;s already possible to execute this form of abuse with =
opt-in<br>
&gt; RBF,<br>
<br>
If someone&#39;s going to systematically exploit your store via this<br>
mechanism, it seems like they&#39;d just find a single wallet with a good<b=
r>
UX for opt-in RBF and lowballing fees, and go to town -- not something<br>
where opt-in rbf vs fullrbf policies make any difference at all? <br>
<br>
It&#39;s not like existing wallets that don&#39;t let you set RBF will sudd=
enly<br>
get a good UX for replacing transactions just because they&#39;d be relayed=
<br>
if they did, is it?<br>
<br>
&gt; To successfully fool (non-RBF)<br>
&gt; zeroconf one needs to have access to mining infrastructure and probabi=
lity<br>
&gt; of success is the % of hash rate controlled.<br>
<br>
I thought the &quot;normal&quot; avenue for fooling non-RBF zeroconf was to=
 create<br>
two conflicting txs in advance, one paying the merchant, one paying<br>
yourself, connect to many peers, relay the one paying the merchant to<br>
the merchant, and the other to everyone else.<br>
<br>
I&#39;m just basing this off Peter Todd&#39;s stuff from years ago:<br>
<br>
<a href=3D"https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_=
my_doublespendpy_tool_with/cytlhh0/" rel=3D"noreferrer" target=3D"_blank">h=
ttps://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespe=
ndpy_tool_with/cytlhh0/</a><br>
<br>
<a href=3D"https://github.com/petertodd/replace-by-fee-tools/blob/master/do=
ublespend.py" rel=3D"noreferrer" target=3D"_blank">https://github.com/peter=
todd/replace-by-fee-tools/blob/master/doublespend.py</a><br>
<br>
&gt; Currently Lightning is somewhere around 15% of our total bitcoin payme=
nts.<br>
<br>
So, based on last year&#39;s numbers, presumably that makes your bitcoin<br=
>
payments break down as something like:<br>
<br>
=C2=A0 =C2=A05% txs are on-chain and seem shady and are excluded from zeroc=
onf<br>
=C2=A0 15% txs are lightning<br>
=C2=A0 20% txs are on-chain but signal rbf and are excluded from zeroconf<b=
r>
=C2=A0 60% txs are on-chain and seem fine for zeroconf<br>
<br>
&gt; This is very much not nothing, and all of us here want Lightning to gr=
ow,<br>
&gt; but I think it warrants a serious discussion on whether we want Lightn=
ing<br>
&gt; adoption to go to 100% by means of disabling on-chain commerce.<br>
<br>
If the numbers above were accurate, this would just mean you&#39;d go from =
60%<br>
zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn&#39;t be 0% on-chain.=
<br>
<br>
&gt; For me<br>
&gt; personally it would be an easier discussion to have when Lightning is =
at<br>
&gt; 80%+ of all bitcoin transactions.<br>
<br>
Can you extrapolate from the numbers you&#39;ve seen to estimate when that<=
br>
might be, given current trends? Or perhaps when fine-for-zeroconf txs<br>
drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still<br>
work the same in a fullrbf world.<br>
<br>
&gt; The benefits of Lightning are many and obvious,<br>
&gt; we don&#39;t need to limit onchain to make Lightning more appealing. <=
br>
<br>
To be fair, I think making lightning (and coinjoins) work better is<br>
exactly what inspired this -- not as a &quot;make on-chain worse so we look=
<br>
better in comparison&quot;, but as a &quot;making lightning work well is a =
bunch<br>
of hard problems, here&#39;s the next thing we need in order to beat the<br=
>
next problem&quot;.<br>
<br>
&gt; Sidenote: On the efficacy of RBF to &quot;unstuck&quot; stuck transact=
ions<br>
&gt; After interacting with users during high-fee periods I&#39;ve come to =
not<br>
&gt; appreciate RBF as a solution to that issue. Most users (80% or so) sim=
ply<br>
&gt; don&#39;t have access to that functionality, because their wallet does=
n&#39;t<br>
&gt; support it, or they use a custodial (exchange) wallet etc. Of those th=
at<br>
&gt; have the feature - only the power users understand how RBF works, and<=
br>
&gt; explaining how to do RBF to a non-power-user is just too complex, for =
the<br>
&gt; same reason why it&#39;s complex for wallets to make sensible non-powe=
r-user UI<br>
&gt; around it. Current equilibrium is that mostly only power users have ac=
cess<br>
&gt; to RBF and they know how to handle it, so things are somewhat working.=
 But<br>
&gt; rolling this out to the broad market is something else and would likel=
y<br>
&gt; cause more confusion.<br>
&gt; CPFP is somewhat more viable but also not perfect as it would require =
lots<br>
&gt; of edge case code to handle abuse vectors: What if users abuse a gener=
ous<br>
&gt; CPFP policy to unstuck past transactions or consolidate large wallets.=
 Best<br>
&gt; is for CPFP to be done on the wallet side, not the merchant side, but =
there<br>
&gt; too are the same UX issues as with RBF.<br>
<br>
I think if you&#39;re ruling out both merchants and users being able to add=
<br>
fees to a tx to get it to confirm, then you&#39;re going to lose either way=
.<br>
Txs will either expire because they&#39;ve been stuck for more than a week,=
<br>
and be vulnerable to replacement at that point anyway, or they&#39;ll be<br=
>
dropped from mempools because they&#39;ve filled up and they were the lowes=
t<br>
fee tx, and be vulnerable to replacement for that reason. In the expiry<br>
case, the merchant can rebroadcast the original transaction to keep it<br>
alive, perhaps with a good chance of beating an attacker to the punch,<br>
but in the full mempool case, you could only do that if you were also<br>
CPFPing it, which you already ruled out.<br>
<br>
Cheers,<br>
aj<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l=
tr"><div dir=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0p=
t;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color=
:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:normal;=
font-variant:normal;text-decoration:none;vertical-align:baseline;white-spac=
e:pre-wrap">Sergej Kotliar</span></p><p dir=3D"ltr" style=3D"line-height:1.=
38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-fa=
mily:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:700;fo=
nt-style:normal;font-variant:normal;text-decoration:none;vertical-align:bas=
eline;white-space:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-heig=
ht:1.38;margin-top:0pt;margin-bottom:0pt"><b style=3D"font-weight:normal"><=
br></b></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-b=
ottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(102,10=
2,102);background-color:transparent;font-weight:700;font-style:normal;font-=
variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre=
-wrap"><span style=3D"border:none;display:inline-block;overflow:hidden;widt=
h:220px;height:80px"><img src=3D"https://lh4.googleusercontent.com/wU5i7e8b=
oCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txX=
MKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" width=3D"220" height=
=3D"80" style=3D"margin-left: 0px; margin-top: 0px;"></span></span></p><p d=
ir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><spa=
n style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgro=
und-color:transparent;font-weight:400;font-style:normal;font-variant:normal=
;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Twitter=
: @</span><a href=3D"https://twitter.com/ziggamon" style=3D"text-decoration=
:none" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;c=
olor:rgb(102,102,102);background-color:transparent;font-weight:400;font-sty=
le:normal;font-variant:normal;text-decoration:underline;vertical-align:base=
line;white-space:pre-wrap">ziggamon</span></a><span style=3D"font-size:9.5p=
t;font-family:Arial;color:rgb(102,102,102);background-color:transparent;fon=
t-weight:400;font-style:normal;font-variant:normal;text-decoration:none;ver=
tical-align:baseline;white-space:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" =
style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><b style=3D"fon=
t-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1.38;margi=
n-top:0pt;margin-bottom:0pt"><a href=3D"http://www.bitrefill.com/" style=3D=
"text-decoration:none" target=3D"_blank"><span style=3D"font-size:9.5pt;fon=
t-family:Arial;color:rgb(102,102,102);background-color:transparent;font-wei=
ght:400;font-style:normal;font-variant:normal;text-decoration:underline;ver=
tical-align:baseline;white-space:pre-wrap">www.bitrefill.com</span></a></p>=
<p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">=
<a href=3D"https://www.twitter.com/bitrefill" target=3D"_blank"><span style=
=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-col=
or:transparent;vertical-align:baseline;white-space:pre-wrap">Twitter</span>=
</a><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102)=
;background-color:transparent;vertical-align:baseline;white-space:pre-wrap"=
> | </span><a href=3D"https://www.bitrefill.com/blog/" target=3D"_blank"><s=
pan style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backg=
round-color:transparent;vertical-align:baseline;white-space:pre-wrap">Blog<=
/span></a><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,10=
2,102);background-color:transparent;vertical-align:baseline;white-space:pre=
-wrap"> | </span><a href=3D"https://angel.co/bitrefill" target=3D"_blank"><=
span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);back=
ground-color:transparent;vertical-align:baseline;white-space:pre-wrap">Ange=
llist </span></a><br></p></div></div></div></div></div></div></div></div></=
div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div=
 dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><p dir=3D"ltr" style=3D"line=
-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5=
pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-wei=
ght:700;font-style:normal;font-variant:normal;text-decoration:none;vertical=
-align:baseline;white-space:pre-wrap">Sergej Kotliar</span></p><p dir=3D"lt=
r" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=
=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:tra=
nsparent;font-weight:700;font-style:normal;font-variant:normal;text-decorat=
ion:none;vertical-align:baseline;white-space:pre-wrap">CEO</span></p><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><b sty=
le=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1=
.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-fa=
mily:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:=
700;font-style:normal;font-variant:normal;text-decoration:none;vertical-ali=
gn:baseline;white-space:pre-wrap"><span style=3D"border:none;display:inline=
-block;overflow:hidden;width:220px;height:80px"><img src=3D"https://lh4.goo=
gleusercontent.com/wU5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_z=
OQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1Qcjtef=
CDkNG" width=3D"220" height=3D"80" style=3D"margin-left: 0px; margin-top: 0=
px;"></span></span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;col=
or:rgb(102,102,102);background-color:transparent;font-weight:400;font-style=
:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;wh=
ite-space:pre-wrap">Twitter: @</span><a href=3D"https://twitter.com/ziggamo=
n" style=3D"text-decoration:none" target=3D"_blank"><span style=3D"font-siz=
e:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transpare=
nt;font-weight:400;font-style:normal;font-variant:normal;text-decoration:un=
derline;vertical-align:baseline;white-space:pre-wrap">ziggamon</span></a><s=
pan style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backg=
round-color:transparent;font-weight:400;font-style:normal;font-variant:norm=
al;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">=C2=
=A0</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt"><b style=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" st=
yle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href=3D"http:/=
/www.bitrefill.com/" style=3D"text-decoration:none" target=3D"_blank"><span=
 style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgrou=
nd-color:transparent;font-weight:400;font-style:normal;font-variant:normal;=
text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">www=
.bitrefill.com</span></a></p><p dir=3D"ltr" style=3D"line-height:1.38;margi=
n-top:0pt;margin-bottom:0pt"><a href=3D"https://www.twitter.com/bitrefill" =
target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:rg=
b(102,102,102);background-color:transparent;vertical-align:baseline;white-s=
pace:pre-wrap">Twitter</span></a><span style=3D"font-size:9.5pt;font-family=
:Arial;color:rgb(102,102,102);background-color:transparent;vertical-align:b=
aseline;white-space:pre-wrap"> | </span><a href=3D"https://www.bitrefill.co=
m/blog/" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial=
;color:rgb(102,102,102);background-color:transparent;vertical-align:baselin=
e;white-space:pre-wrap">Blog</span></a><span style=3D"font-size:9.5pt;font-=
family:Arial;color:rgb(102,102,102);background-color:transparent;vertical-a=
lign:baseline;white-space:pre-wrap"> | </span><a href=3D"https://angel.co/b=
itrefill" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Aria=
l;color:rgb(102,102,102);background-color:transparent;vertical-align:baseli=
ne;white-space:pre-wrap">Angellist </span></a><br></p></div></div></div></d=
iv></div></div></div></div></div></div></div>

--0000000000009a863205eb77fcac--