From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7D08013CF for ; Tue, 15 Sep 2015 15:03:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7078F182 for ; Tue, 15 Sep 2015 15:02:59 +0000 (UTC) Received: by qgez77 with SMTP id z77so145708123qge.1 for ; Tue, 15 Sep 2015 08:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sci.ventures; s=google; h=date:sender:mime-version:message-id:in-reply-to:references:from:to :cc:subject:content-type; bh=CRK9g+4WKUfBIBotlLl3AO5/JhUsAOwE8Lr42cHl+UI=; b=gXjiC+wEyf8UiZlaclv2ht3XjYMJdgABzjxqopEtCq1uKjyXgSIXVCJ5V97b9VwtZz wu/0ZkyAqqW4mXt2sQpd6J3uMdPzOsK/PX2BeK+lhXNozsg9LLE7Yx9h2v6eoUNWAgxb Tejx8I7mo4AXEGQGSgUwl8loE3d0g1426K0do= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sci.ph; s=google; h=date:sender:mime-version:message-id:in-reply-to:references:from:to :cc:subject:content-type; bh=CRK9g+4WKUfBIBotlLl3AO5/JhUsAOwE8Lr42cHl+UI=; b=Se3nh+KrVbv3miUmj7cMBOVzKcO2rluk9WnTlHp/bOzLqEqK32TfR0rvKwd5c51YB+ wk6NgIexJxX2037qVjQRuWQb9g9vB+GjRZ7cq7wSKXE/YFXzIcjjZqnRO5znFSx2dLGY TEyhbRYJgCteUMALtb2epxhJS6yZt97zqo5IA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:sender:mime-version:message-id:in-reply-to :references:from:to:cc:subject:content-type; bh=CRK9g+4WKUfBIBotlLl3AO5/JhUsAOwE8Lr42cHl+UI=; b=m7TjQPxT1I2E9EVGeWTuISMhCPjYKjponXsclvqJGaFFk9hHD1GHClVLBffLULZ0e9 fYj/9YVmDhwAFHqEtxS5HZiRfh21eATaLS/ATNmmeydntua171PxvMILEhr+8hKsZGrb /uT4FCaqDiO0jb8qOpnWsBMe5VGb8FdAwnzezOvyhLtNTHuGU2zXfhaelW+HT1zoOc8y jePxxBGwESczo6itf89YmGMrN67aRt4uvXixe+Xs+xl5QpmbOg9G0nWYcxBsNK863/1J MH55UpipUzT/VyyiXepG+aHNH3gNDhjeeqcB5hnQANbsYI+CHdLffAIjRi/XKSHT0zi4 XmTw== X-Gm-Message-State: ALoCoQkCgsxnDUGwsqOApSHX/otnofaZ5HPblX9Y6G8aBifKPi5n7RkLReRXujH+d6uuvYKRZvXE X-Received: by 10.140.194.8 with SMTP id p8mr21310150qha.63.1442329378501; Tue, 15 Sep 2015 08:02:58 -0700 (PDT) Received: from hedwig-51.prd.orcali.com (ec2-54-85-253-165.compute-1.amazonaws.com. [54.85.253.165]) by smtp.gmail.com with ESMTPSA id 82sm8065856qhs.8.2015.09.15.08.02.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Sep 2015 08:02:57 -0700 (PDT) Date: Tue, 15 Sep 2015 08:02:57 -0700 (PDT) X-Google-Original-Date: Tue, 15 Sep 2015 15:02:57 GMT Sender: John Bailon MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1442329377422.86a9d355@Nodemailer> In-Reply-To: References: X-Orchestra-Oid: 156CE148-D581-4F3E-B1AC-538E8154B0B6 X-Orchestra-Sig: 591c7d17e30f255f852163d41528cd902ae91705 X-Orchestra-Thrid: TECD6BC8B-F1DF-4416-9B83-7350B377AFD5_1512377369530741589 X-Orchestra-Thrid-Sig: 418fb5fe2f5e56a69bdf9ef61c0b87202e3659d4 X-Orchestra-Account: 3e5f7091929babb8fae6ab112a21ac556a06c07e From: "John Bailon" To: "Thomas Kerin" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1442329377656" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Instant exchange rates URI scheme X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 15:03:00 -0000 ------Nodemailer-0.5.0-?=_1-1442329377656 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This scheme would mostly be beneficial to end users of instant exchange = wallets and would be implemented by the operators. None of the parameters = would be filled up by the user by hand. It's more of enabling different = wallet operators to communicate with each other and to be able to present = to their end users the rates they are getting when sending from their = pegged wallet to another pegged wallet. Abstracting bitcoin rates from both= end users.=C2=A0 To illustrate, imagine Alice who has a USD wallet wants to send JPY 10,000 = to Bob who has a JPY pegged wallet.=C2=A0 Alice's wallet scans Bob's wallet which tells Alice's wallet the following = info: 1. Bob's BTC address 2. Bob's wallet currency is JPY 3. Bob's wallet operator is pricing BTC 1 at JPY=C2=A027,779 for the next 5= minutes.=C2=A0 With these info, Alice's wallet can already derive the following: Alice needs to send=C2=A00.35998416 BTC to send JPY 10,000. Alice's wallet = can also show how much=C2=A00.35998416 BTC is in USD, which is USD 83.27. = Alice's wallet can present it as follows; =22You are sending JPY 10,000 for USD 83.27 to Bob's wallet.=22 On Tue, Sep 15, 2015 at 10:40 PM, Thomas Kerin wrote: > Something very similar was posted not too long ago. > Long and sort of it is, there is no point in saying you priced in GBP, = etc, > because it can vary from exchange to exchange. > To be honest, adding more things to consider at checkout time confuses > things; why not just specify the amount of Bitcoin you wish to be = paid=3F > On 15 Sep 2015 11:11 am, =22John Bailon via bitcoin-dev=22 < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> Hello, >> >> I'd like to propose a BIP for a standard URI scheme to allow wallet >> operators that implement instant exchange or pegging to other currencies= , >> cryptocurrencies or asset classes to allow for interoperable = communications >> of rates and other pertinent information. >> >> The idea is to include in the wallet address as parameters information >> that supplements the presentation of a proposed transaction. >> >> For example, a wallet operator that instantly exchanges bitcoin to gold >> would present a wallet address as follows: >> >> bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV=3Fcurrency=3Dxau&rate=3D0.= 2084&expires=3D1458432000 >> >> Wherein: >> : the currency, cryptocurrency or asset that the = transaction >> will end up as encoded in ISO 4217 if applicable. >> : the bitcoin to rate as dictated by receiving wallet >> : unix timestamp of when the rate loses validity >> >> This would allow the sending wallet the ability to present up-to-date >> exchange rates. When, for example, a wallet operator that pegs to the = USD >> scans the address above, it would be able to present to the user the >> following information: >> >> 1. USD to XAU rate >> 2. How much XAU will be received by the address >> 3. How long before the rates expires >> >> >> Thoughts=3F >> >> >> Regards, >> John >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> ------Nodemailer-0.5.0-?=_1-1442329377656 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This scheme would mostly be beneficial to end users of instant = exchange wallets and would be implemented by the operators. None of the = parameters would be filled up by the user by hand. It's more of enabling = different wallet operators to communicate with each other and to be able to= present to their end users the rates they are getting when sending from = their pegged wallet to another pegged wallet. Abstracting bitcoin rates = from both end users.=C2=A0

To illustrate, imagine Alice who has a USD wallet wants to send JPY 10= ,000 to Bob who has a JPY pegged wallet.=C2=A0

Alice's wallet scans Bob's wallet which tells Alice's wallet the = following info:
1. Bob's BTC address
2. Bob's wallet currency is JPY
3. Bob's wallet operator is pricing BTC 1 at JPY=C2=A027,779 for the next 5 minutes.=C2=A0

With these info, = Alice's wallet can already derive the following:

Alice needs to = send=C2=A00.35998416 BTC to send JPY 10,000. Alice's wallet can also = show how much=C2=A00.35998416 BTC is in USD, = which is USD 83.27. Alice's wallet can present it as follows;

=22You are sending JPY 10,000 for USD 83.27 to = Bob's wallet.=22





On Tue, Sep 15, 2015 at 10:40 = PM, Thomas Kerin <thomas.kerin@gmail.= com> wrote:

Something very similar was posted not too long ago. =

Long and sort of it is, there is no point in saying you = priced in GBP, etc, because it can vary from exchange to exchange.

To be honest, adding more things to consider at checkout= time confuses things; why not just specify the amount of Bitcoin you wish = to be paid=3F

On 15 Sep 2015 11:11 am, =22John Bailon = via bitcoin-dev=22 <bitcoin-dev@lists.linuxfoundation.org> = wrote:
Hello,

I'd like to propose a BIP for a standard URI scheme to allow wallet = operators that implement instant exchange or pegging to other currencies, = cryptocurrencies or asset classes to allow for interoperable communications= of rates and other pertinent information.

The idea is to include in= the wallet address as parameters information that supplements the = presentation of a proposed transaction.

For example, a wallet = operator that instantly exchanges bitcoin to gold would present a wallet = address as follows:
bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV=3Fcurren= cy=3Dxau&rate=3D0.2084&expires=3D1458432000

Wherein:
<= currency> : =C2=A0the currency, cryptocurrency or asset that the = transaction will end up as encoded in ISO 4217 if applicable.=
<rate> : the bitcoin to <currency> rate as dictated by = receiving wallet
<expires> : unix timestamp of when the rate loses= validity

This would allow the sending wallet the ability to present= up-to-date exchange rates. When, for example, a wallet operator that pegs = to the USD scans the address above, it would be able to present to the user= the following information:

1. USD to XAU rate
2. How much XAU = will be received by the address
3. How long before the rates = expires


Thoughts=3F


Regards,
John

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.= org/mailman/listinfo/bitcoin-dev


------Nodemailer-0.5.0-?=_1-1442329377656--