path: root/28/855df50c8ff1af32dbfb64538d3bbc879dfce4

Return-Path: <karel.kyovsky@generalbytes.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 51B70C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jul 2021 14:35:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 40A1A84482
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jul 2021 14:35:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level: 
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=generalbytes-com.20150623.gappssmtp.com
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 90E0uBo0rQtx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jul 2021 14:35:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [IPv6:2a00:1450:4864:20::629])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 855F984478
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jul 2021 14:35:35 +0000 (UTC)
Received: by mail-ej1-x629.google.com with SMTP id hd33so15443521ejc.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jul 2021 07:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=generalbytes-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:from:date:message-id:subject:to;
 bh=B2ivOR7AaoC0j0+dtChXUfgEtjcyVupf9TULCqkvWu0=;
 b=qaxdI+KRYJ2lDANZARMGypoLev3DRzjfTXa+FdgfEA+mH2O5mYOhl5y/kyzzUlBhBo
 LHiFkm3K6vVHfJ/zwAUTtw/FfwpUrlzA3G2gaI7+BV8TE3ivcz3dA5VbJXrVtNV7q/LB
 IKJW02eCpO4zIFNlAVmonxZJxKTuRBCKE0jRxiE/dlt5aYqExqy97iVbNWPdS32BkMWt
 /3CS0zssXm+QysqiBsjtRjChdkeu4wZFwfg5KxOr1MWQ6YJVy6ePQRxTrgdK0VdX4Uhf
 3SPcLMKy3fdTzNs4++O7BYAI+u2ytmNieJC/bIwJyeiXtV+F01jEOnogpNiYIBI3J4P1
 fFbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=B2ivOR7AaoC0j0+dtChXUfgEtjcyVupf9TULCqkvWu0=;
 b=NQwV93SOQDLkdAJivJO4mxq90AWCCbVcAcUOa2GZ4R2Y9jPDeS+I5RGfqQWJIDuSRj
 uaUtQRouPxX6nlqdC6QkH39kvitJdFehq7T901bj6SSq/6xGB3vZ36iLA0ZHku2yp4jo
 8zCi/OF0+8EJNmj+T3eiyMoO1adkNkXnmW45R5PFFg08g2wOcHRNkSeb2Pqv1FT0yJB3
 nvb3tnMowrrj4Gc7H74d10gmEUQ+eMxo9jp8hE/T/Ul+PCdCr6tV0moFkCoNEbbxjn2E
 B2giEgtqqi7s2UYCM1ML76J0Srs042xWqz4oXHSoQD2P0HZj3aTa7TkQF4L1gKXjvIel
 sD9g==
X-Gm-Message-State: AOAM532gQ0vvHSpgROPNM2Wp3pMQTPvRxJiYn+n1t1FYKcEk/krujNi7
 CFbK3oeaq1t45ARAWorZdaxYixp9gq9RWQ5XR2aomGcP5eo=
X-Google-Smtp-Source: ABdhPJzBLTxUj+5+RplYdhCFxI/WigNkRfkDMBY1fEVMmUpwmkKAsXhXzG3AkXycZWpzAq+XflW2gVkIQGlr1mG2nME=
X-Received: by 2002:a17:906:d8da:: with SMTP id
 re26mr12122462ejb.205.1626446133455; 
 Fri, 16 Jul 2021 07:35:33 -0700 (PDT)
MIME-Version: 1.0
From: Karel Kyovsky <karel.kyovsky@generalbytes.com>
Date: Fri, 16 Jul 2021 16:35:21 +0200
Message-ID: <CALSqm3bG0pYhPvGQd-uxN5fTQXS_rbzQFq3L5+d2xbaLUuCE3Q@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000008055205c73e8048"
X-Mailman-Approved-At: Fri, 16 Jul 2021 17:53:35 +0000
Subject: [bitcoin-dev] Travel rule, VASP UID and bitcoin URI - A new BIP
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: Fri, 16 Jul 2021 14:35:39 -0000

--00000000000008055205c73e8048
Content-Type: text/plain; charset="UTF-8"

Hi There,
I would like to propose a standardization of the bitcoin URI parameter name
that could be optionally used to contain the unique id of VASP (Virtual
asset service provider as defined by FATF) hosting the user's wallet
address.
My question is: Should I prepare a completely new BIP or should I prepare a
modification of BIP21?
BIP21 status is FINAL so I guess it should be a completely new BIP that
would just extend the BIP21. I'm looking for confirmation of this approach.
Thank you for answering that.

Please let's NOT start a discussion whether the FATF travel rule is a good
thing or not. This could derail my initial question.

Background:
We are going to be soon working on travel rule integration for our Bitcoin
ATM product.
The current user scenario is that the user shows on his phone QR code to
the ATM with bitcoin URI containing an address, inserts cash and walks away
with BTC arriving to his wallet.

In a Travel Rule compliant scenario the ATM operator must perform the "best
effort" to find out who(VASP) is hosting the user's wallet, contact such
VASP and send VASP customer identity data. This can be achieved by:

a) ATM contacting every possible known VASP that is travel rule compliant
via some platform and ask him whether the address read from the QR code
belongs to him. Such search could be done also with bloom filter to protect
the privacy of a user. But of course this is very far from ideal.

or

b) ATM could use blockchain analytics tools to find who might be serving
this wallet (major exchange etc). If the wallet address is empty prior to
the purchase on the ATM this address would have to be monitored for some
time to find out if it doesn't fall into some exchange's(VASP) cluster and
that would have to be later contacted.

or

c) User will choose from the list of VASPs on the ATM screen to match his
wallet provider(imagine phonebook with search field - terrible). Most
people will select irrelevant VASP because they will not be willing to
spend time to search VASP's name on the screen.

or

d) The user could enable in settings of their mobile wallet that VASP UID
would be provided in URI as one of the parameters so that Bitcoin ATM
operator will not have to search for VASP and could communicate with VASP
immediately after scanning URI from QR code. In such a case options a) or
b) or c) would not have to be performed and user experience for ATM users
would stay the same as before travel rule compliance. In order to achieve
this all wallet providers need to use the same parameter name in URI so
that ATM will read this parameter - standardization of this parameter name
is the purpose of proposed new BIP.

VASP UID could be also a public key that could be used to encrypt the
customer's identity information before sending it to wallet provider VASP
from the bitcoin ATM. Directory of VASP UIDs, how VASP could be contacted,
method of transfer when one knows VASP UID should be all outside of scope
of this BIP. I expect this to be covered by 3rd party
tools/platforms/regulators.

Bitcoin ATM operators want to stay in business and for that they need to
stay compliant with US regulation. Therefore they ask us to improve our
products to comply with the FATF-Travel Rule.
The same probably applies to US custodian wallet service providers so I
envision that the majority of custodian wallets offered on Appstore/Google
play in the US would provide their VASP UID in bitcoin URI as a new default
with an option for users to turn it off.

Please note that Travel Rule doesn't apply for unhosted(non-custodian)
wallets.

Thank you,
Karel Kyovsky

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

<div dir=3D"auto"><div dir=3D"auto">Hi There,</div><div dir=3D"auto">I woul=
d like to propose a standardization of the bitcoin URI parameter name that =
could be optionally used to contain the unique id of VASP (Virtual asset se=
rvice provider as defined by FATF) hosting the user&#39;s wallet address.</=
div><div dir=3D"auto">My question is: Should I prepare a completely new BIP=
 or should I prepare a modification of BIP21?</div><div dir=3D"auto">BIP21 =
status is FINAL so I guess it should be a completely new BIP that would jus=
t extend the BIP21. I&#39;m looking for confirmation of this approach. Than=
k you for answering that.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Please let&#39;s NOT start a discussion whether the FATF travel rule is a=
 good thing or not. This could derail my initial question.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Background:</div><div dir=3D"auto">We ar=
e going to be soon working on travel rule integration for our Bitcoin ATM p=
roduct.</div><div dir=3D"auto">The current user scenario is that the user s=
hows on his phone QR code to the ATM with bitcoin URI containing an address=
, inserts cash and walks away with BTC arriving to his wallet.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">In a Travel Rule compliant scenario =
the ATM operator must perform the &quot;best effort&quot; to find out who(V=
ASP) is hosting the user&#39;s wallet, contact such VASP and send VASP cust=
omer identity data. This can be achieved by:</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">a) ATM contacting every possible known VASP that is tr=
avel rule compliant via some platform and ask him whether the address read =
from the QR code belongs to him. Such search could be done also with bloom =
filter to protect the privacy of a user. But of course this is very far fro=
m ideal.</div><div dir=3D"auto"><br></div><div dir=3D"auto">or</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">b) ATM could use blockchain analytic=
s tools to find who might be serving this wallet (major exchange etc). If t=
he wallet address is empty prior to the purchase on the ATM this address wo=
uld have to be monitored for some time to find out if it doesn&#39;t fall i=
nto some exchange&#39;s(VASP) cluster and that would have to be later conta=
cted.</div><div dir=3D"auto"><br></div><div dir=3D"auto">or</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">c) User will choose from the list of =
VASPs on the ATM screen to match his wallet provider(imagine phonebook with=
 search field - terrible). Most people will select irrelevant VASP because =
they will not be willing to spend time to search VASP&#39;s name on the scr=
een.</div><div dir=3D"auto"><br></div><div dir=3D"auto">or</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">d) The user could enable in settings of =
their mobile wallet that VASP UID would be provided in URI as one of the pa=
rameters so that Bitcoin ATM operator will not have to search for VASP and =
could communicate with VASP immediately after scanning URI from QR code. In=
 such a case options a) or b) or c) would not have to be performed and user=
 experience for ATM users would stay the same as before travel rule complia=
nce. In order to achieve this all wallet providers need to use the same par=
ameter name in URI so that ATM will read this parameter - standardization o=
f this parameter name is the purpose of proposed new BIP.=C2=A0</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">VASP UID could be also a public key=
 that could be used to encrypt the customer&#39;s identity information befo=
re sending it to wallet provider VASP from the bitcoin ATM. Directory of VA=
SP UIDs, how VASP could be contacted, method of transfer when one knows VAS=
P UID should be all outside of scope of this BIP. I expect this to be cover=
ed by 3rd party tools/platforms/regulators.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Bitcoin ATM operators want to stay in business and for =
that they need to stay compliant with US regulation. Therefore they ask us =
to improve our products to comply with the FATF-Travel Rule.=C2=A0</div><di=
v dir=3D"auto">The same probably applies to US custodian wallet service pro=
viders so I envision that the majority of custodian wallets offered on Apps=
tore/Google play in the US would provide their VASP UID in bitcoin URI as a=
 new default with an option for users to turn it off.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Please note that Travel Rule doesn&#39;t appl=
y for unhosted(non-custodian) wallets.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Thank you,</div><div dir=3D"auto">Karel Kyovsky</div></div>

--00000000000008055205c73e8048--