diff options
author | James MacWhyte <macwhyte@gmail.com> | 2018-10-08 16:42:57 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-10-08 23:43:11 +0000 |
commit | cccbc993514bb89d1503f3c99d781be340ba1a13 (patch) | |
tree | 24544ea73f42bb014f3510526f103898926e4389 | |
parent | 4bae514fa5db1b8050f324aff34ecebc3eff37a3 (diff) | |
download | pi-bitcoindev-cccbc993514bb89d1503f3c99d781be340ba1a13.tar.gz pi-bitcoindev-cccbc993514bb89d1503f3c99d781be340ba1a13.zip |
Re: [bitcoin-dev] MultiSig request URI proposal
-rw-r--r-- | bd/b0dcd5650b25f9b1bcdcf4efe16831e894d5b7 | 163 |
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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation= +.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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'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-- + |