summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJames MacWhyte <macwhyte@gmail.com>2018-10-08 16:42:57 -0700
committerbitcoindev <bitcoindev@gnusha.org>2018-10-08 23:43:11 +0000
commitcccbc993514bb89d1503f3c99d781be340ba1a13 (patch)
tree24544ea73f42bb014f3510526f103898926e4389
parent4bae514fa5db1b8050f324aff34ecebc3eff37a3 (diff)
downloadpi-bitcoindev-cccbc993514bb89d1503f3c99d781be340ba1a13.tar.gz
pi-bitcoindev-cccbc993514bb89d1503f3c99d781be340ba1a13.zip
Re: [bitcoin-dev] MultiSig request URI proposal
-rw-r--r--bd/b0dcd5650b25f9b1bcdcf4efe16831e894d5b7163
1 files changed, 163 insertions, 0 deletions
diff --git a/bd/b0dcd5650b25f9b1bcdcf4efe16831e894d5b7 b/bd/b0dcd5650b25f9b1bcdcf4efe16831e894d5b7
new file mode 100644
index 000000000..829dc2c0f
--- /dev/null
+++ b/bd/b0dcd5650b25f9b1bcdcf4efe16831e894d5b7
@@ -0,0 +1,163 @@
+Return-Path: <keatonatron@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 643266FCE
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 8 Oct 2018 23:43:11 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com
+ [209.85.221.51])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 944BF7F0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 8 Oct 2018 23:43:10 +0000 (UTC)
+Received: by mail-wr1-f51.google.com with SMTP id x12-v6so22543506wru.8
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 08 Oct 2018 16:43:10 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
+ h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
+ bh=iB2mnCkuqXUB+te6tCdgsA1+1xwRU36Fan1TTpiHVcM=;
+ b=V9f9Mlxr4aw2uepr4YlbEDK7WaD99p0qsHqEr4I8p5SWJKxvIf6UrW6DyNjrCuvb0f
+ neLR6WZleyAmfPxrGs/Di2XuwKtlrvTMXLs366SjkG4GfqdQTpih9fi0iK/oFJM3imSo
+ SrfztgjEgWk2adGUrIPbo1Jt2qkQ5XCnEgITSB5SOF0okjuWbH8eSEg7+Wg+g65J2tXh
+ 5EvtNdGTGMOmmelsRJdmIueRQviG7/iqpG1ZwWVGJcFwnGGK916uoDx30vyjv3b++Nw4
+ mOU3bmP0MzxMaHsKCV0BuqOqrtADPmIn8dtRJsKBOozfllFcRuI6/VR8kRkfd9v0QAp8
+ juZQ==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:references:in-reply-to:from:date
+ :message-id:subject:to;
+ bh=iB2mnCkuqXUB+te6tCdgsA1+1xwRU36Fan1TTpiHVcM=;
+ b=iIOacVrUUeBIUTxJPKICfar+ve+54JMXoyJ+HsTn1JoesvBY9mrGTalt6PWtHtbkxh
+ 85AQg0iUmq5eBlDmFGMQaSB2A4z/3TM0JUY5tFnnAObhJv3PyC/1LlGKX9XyCtkFdT29
+ 8Vekngh1RTZdIluXo9pdi7yhbmDd8Ih6ATjGtBbXSa1f49HAoIY2zHz29ac1gbuRjKea
+ rELjD2M8SJ/KnyGVxAnZ3FsLV1uPbieLZ4GS7YcVrj4w2q2NB3Pm+dFSx/vVQf+lfTb9
+ PF1WR6JRO++PY6xc7jzaUzF+4Yc1tgbBpzrleSWbyB6LPg1NZfK2Rp8DKNRAawxg9esR
+ /pHw==
+X-Gm-Message-State: ABuFfoiW3dl1pt4ko4eEgcSQQ5eYyUKxF/7/rqwnTxAyhOkLl3KOFjMd
+ ZdVTGzCHpD+h5x91/bnG1JuqSjM4ZRhG6rVS3R4=
+X-Google-Smtp-Source: ACcGV62dAEe9JhYonweHZB8KviFF23BNx5JggaOd9MD3WEkD6VErxVOSbE5MtIrJcyhRcGH3LE/23YC1sUiM8UQlpY0=
+X-Received: by 2002:a5d:4706:: with SMTP id
+ y6-v6mr17283516wrq.256.1539042188974;
+ Mon, 08 Oct 2018 16:43:08 -0700 (PDT)
+MIME-Version: 1.0
+References: <CAHm82F78NpV0UmyVMuka64Y1b0rwBO6FNj=KwAOm885d9q4xJg@mail.gmail.com>
+In-Reply-To: <CAHm82F78NpV0UmyVMuka64Y1b0rwBO6FNj=KwAOm885d9q4xJg@mail.gmail.com>
+From: James MacWhyte <macwhyte@gmail.com>
+Date: Mon, 8 Oct 2018 16:42:57 -0700
+Message-ID: <CAH+Axy6Ldsx+AABMTSAN=_-Y4CWRyy+_E1eLNKhymOiosZ_81w@mail.gmail.com>
+To: =?UTF-8?B?44GK44Gu44GL44Gh44GK?= <onokatio@gmail.com>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: multipart/alternative; boundary="000000000000f7de330577c02ef5"
+X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
+ RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+X-Mailman-Approved-At: Mon, 08 Oct 2018 23:57:58 +0000
+Subject: Re: [bitcoin-dev] MultiSig request URI proposal
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+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: Mon, 08 Oct 2018 23:43:11 -0000
+
+--000000000000f7de330577c02ef5
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+Hello!
+
+A URI is useful as a standard for one-way communication, but on-chain
+multisig requires many steps. multiple parties need to provide signatures,
+and one party needs to aggregate all the signatures and publish the
+transaction. This URI scheme would allow one to pass along a raw
+transaction in one direction, but once the signer has signed the
+transaction, what are they supposed to do with it? You might be thinking
+you could include a callback URL, like BIP72 does, so the signer can pass
+the signed transaction back to the organizer. However, BIP72 was created as
+a backwards-compatible extension to BIP70, which was designed for one-way
+communication. Since there is no way to be backwards compatible here, there
+is no need to limit yourself to the URI system. Instead of creating a new
+URI and using it for something it is not suited for, it would be better (in
+my opinion) to find a different method that is better suited for two-way
+communication.
+
+On Thu, Oct 4, 2018 at 3:52 PM =E3=81=8A=E3=81=AE=E3=81=8B=E3=81=A1=E3=81=
+=8A via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> Hi.
+>
+> I have an idea that subject.
+>
+> There are already BIP 21.
+> But Multisig request URI is non exist.
+>
+> My idea is below:
+>
+> bitcoin-sigreq://{{rawtx}}?{{param}}
+>
+> rawtx: raw transaction (encoded by base64)
+> param:
+> - pubkey=3D{{public key for sign key pair}}
+> - hd_wallet_position=3D{{path for HD wallet position}}
+>
+> This URI scheme is used for multisig request from website to user's local
+> wallet.
+>
+> How do you think ?
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+--000000000000f7de330577c02ef5
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">Hello!<div><br></div><div>A URI is useful as a standard fo=
+r one-way communication, but on-chain multisig requires many steps. multipl=
+e parties need to provide signatures, and one party needs to aggregate all =
+the signatures and publish the transaction. This URI scheme would allow one=
+ to pass along a raw transaction in one direction, but once the signer has =
+signed the transaction, what are they supposed to do with it? You might be =
+thinking you could include a callback URL, like BIP72 does, so the signer c=
+an pass the signed transaction back to the organizer. However, BIP72 was cr=
+eated as a backwards-compatible extension to BIP70, which was designed for =
+one-way communication. Since there is no way to be backwards compatible her=
+e, there is no need to limit yourself to the URI system. Instead of creatin=
+g a new URI and using it for something it is not suited for, it would be be=
+tter (in my opinion) to find a different method that is better suited for t=
+wo-way communication.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
+On Thu, Oct 4, 2018 at 3:52 PM =E3=81=8A=E3=81=AE=E3=81=8B=E3=81=A1=E3=81=
+=8A via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
+.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
+uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
+solid;padding-left:1ex"><div dir=3D"ltr">Hi.<div><br></div><div>I have an i=
+dea that subject.</div><div><br></div><div>There are already BIP 21.</div><=
+div>But Multisig request URI is non exist.</div><div><br></div><div>My idea=
+ is below:</div><div><br></div><div>bitcoin-sigreq://{{rawtx}}?{{param}}</d=
+iv><div><br></div><div>rawtx: raw transaction (encoded by base64)</div><div=
+>param:</div><div>- pubkey=3D{{public key for sign key pair}}</div><div>- h=
+d_wallet_position=3D{{path for HD wallet position}}</div><div><br></div><di=
+v>This URI scheme is used for multisig request from website to user&#39;s l=
+ocal wallet.</div><div><br></div><div>How do you think ?</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></div>
+
+--000000000000f7de330577c02ef5--
+