1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
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--
|
