From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 51B70C000E for ; 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 ; 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 ; 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 ; Fri, 16 Jul 2021 14:35:35 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id hd33so15443521ejc.9 for ; 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 Date: Fri, 16 Jul 2021 16:35:21 +0200 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi There,
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'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 jus= t extend the BIP21. I'm looking for confirmation of this approach. Than= k 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 ar= e going to be soon working on travel rule integration for our Bitcoin ATM p= roduct.
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.

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

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.

or

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't fall i= nto some exchange's(VASP) cluster and that would have to be later conta= cted.

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 scr= een.

or

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

VASP UID could be also a public key= that could be used to encrypt the customer'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.

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
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.

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

Thank you,
Karel Kyovsky
--00000000000008055205c73e8048--