path: root/d8/65902484418bf85710deb1c66315dbf723093d

Return-Path: <pilotniq@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 56438959
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Nov 2016 20:56:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DA11170
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Nov 2016 20:56:48 +0000 (UTC)
Received: by mail-wm0-f52.google.com with SMTP id t79so200015832wmt.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Nov 2016 12:56:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:from:date:message-id:subject:to;
	bh=blgEF/CIRyNL3gjOizXu7h2SMTVYpN/136gm6lPc5AE=;
	b=hZ/pJQmioU831BP9TSsq7VYsdZLBlRIXrYZuws4r2UHgjMPQBd8+Os6Otzug6i0KGA
	w77ugwEwo+aXFVCEE949eqd0kID/mF7VdjBsXnZuX4j6im0nRXqkEAySBboJ2Q7NKFpe
	yP33J6MT+gEDBl46RbPoJgEt+MJxPGTM6WkFYYvMRoMnZRJ99PFJc621zOws2DS7Ozor
	RcGkJS8AQBHhBKl3Ej+7/sb0q8Ck6h6IkeGeNHNQYZBlxYH5voUNYAZlWmolQi76lUpm
	Q+6UtuOgAA6sZHuxCa5ryMHt3dUMoyf4tKOxJiknUN0FxSoA8VpauJW64gDrhPmAwOKW
	U5Lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
	:to; bh=blgEF/CIRyNL3gjOizXu7h2SMTVYpN/136gm6lPc5AE=;
	b=R3cCGC8gszR4ZkCTByWTttFUJsvTW/JRZAWEPIKwijXl77te1hEh2EwcUzYQ0ODRcT
	xsD4osiqRi1JBWCyChe/eakqWYSZ2HpKo4xDmS65lrrUJyHLqgiHC39pjEy6P3N2Ho4q
	dsKqCg+zTx31jrOdNvej0vBItkFP5IOrPAUbI2idyjmcWyYjDJz6sAJ6ZmtEahqIrwTS
	rsGKvY23LEBFDEGmviUXbVyhoDNk0qrOvHDxdEhe2hA5RkLXWmvHJUqaCmGimReTi3h9
	R0d8PhehsbnR0QjMel7GI64NMLddUEjjWimLxKHF8bhT26+A6OPRinKHz0C6NqxoZlHG
	a5Zg==
X-Gm-Message-State: AKaTC02bTEWO4eM6vtKFrckjlOdM9wQXWhkC+JSEoZaxCwbVaOP4RYX1e1Giw9u2TzOCH8sF7Zodhq6Sg2Ep0Q==
X-Received: by 10.28.13.144 with SMTP id 138mr24543714wmn.120.1480453006524;
	Tue, 29 Nov 2016 12:56:46 -0800 (PST)
MIME-Version: 1.0
Sender: pilotniq@gmail.com
Received: by 10.194.153.162 with HTTP; Tue, 29 Nov 2016 12:56:45 -0800 (PST)
From: Erland Lewin <erland@lewin.nu>
Date: Tue, 29 Nov 2016 21:56:45 +0100
X-Google-Sender-Auth: 1qRTzrVNbd-RNCV8UUwSg9V3LN0
Message-ID: <CADn+-hkarmEEJyzE67DSajTK3koTkKuna2kwVHuZkzHDxp6SZw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a114436168f881b054276d312
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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: Tue, 29 Nov 2016 21:12:35 +0000
Subject: [bitcoin-dev] BIP idea: Standardised p2sh bitcoin addresses
 requiring an arbitrary and/or combination of keys
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: Tue, 29 Nov 2016 20:56:50 -0000

--001a114436168f881b054276d312
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would like to get community feedback on whether the following idea would
be reasonable to write as an informational BIP proposal:


Boolean Addresses: Standardized p2sh addresses combining public keys,
multisigs and time locks with arbitrary and/or-operations


Abstract
=3D=3D=3D=3D=3D=3D=3D=3D
It is currently straightforward to create Bitcoin addresses which can be
redeemed by a single key or an m-of-n multi signature. It is not as
straight forward to create addresses that can be redeemed by, for example,
key A or (key B and key C).

This proposal describes a consistent way to create s type of p2sh addresses
(=E2=80=9CBoolean addresses=E2=80=9D) which can be redeemed by an arbitrary=
 set of keys and
multi signatures combined with logical and/or operations.


Examples

=3D=3D=3D=3D=3D=3D=3D=3D
In the examples below, Alice has key A, Bob key B, Charles key C, etc).

Example 1:

A corporation has an account that can be spent by the CEO Alice or two
board members (of Bob, Charles, David or Eric) in union. The account should
allow signatures by "A or (2 of 4 of B, C, D, E)"


Example 2:


Alice wants a bitcoin address that she normally signs herself. However, if
she has a fatal accident, she sets up a key "B" to be automatically mailed
from a cloud service after a given time of inactivity to close relatives
Charles, David and Eric. These relatives are also given keys written on
paper.


Alice's address can be redeemed by "A or (B and 1-of-3 of C, D, E)". This
way, if the cloud wallet key B is compromised or paper wallets C, D or E
are stolen, it is not sufficient to redeem the address. If Alice=E2=80=99s =
key is
lost, she can ask C, D, or E for their key and use key B to spend the
address to a new one with a new key for Alice.


Motivation

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Standardisation of these addresses would allow interoperability for wallet
software to create, sign and share signature requests for such addresses.


Implementation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A Boolean address is described as a tree starting at a root node, where a
node can be:

* An =E2=80=9Cand=E2=80=9D operation, with a list of sub-nodes
* An =E2=80=9Cor=E2=80=9D operation, with a list of sub-nodes
* A public key
* A Multisig operation n-of-m with a list of public keys
* A CHECKLOCKTIMEVERIFY operation

The implementation will describe a single well-defined way to generate a
P2SH script from a given boolean address tree.

It will also define the ordering of sub-nodes for and and or operations.

The implementation will further detail how spending transactions are to be
signed. A signature will consist of keys required for a given path through
the tree. Signing an =E2=80=9Cor=E2=80=9D- branch of the tree, will consist=
 of a value
specifying which or-subnode is signed, followed by the signatures for that
node. That way, only one or-case has to be evaluated in the script.

For example, in the case of an account that can be redeemed by the example
"A or (B and 1-of-3 of C, D, E)" from above, could be signed by something
like:

0 (meaning evaluate the first sub-node of the or condition)
A

or

1 (evaluate the second sub-node of the top level or condition)
B
1 (One key for the multisig)
D (one of the 1-of-3 signatures)
0 (padding required for multisig opcode)

--001a114436168f881b054276d312
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span id=3D"gmail-docs-internal-guid-404222e8-b1c5-d3f8-b5=
23-02e75c34183d"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma=
rgin-bottom:3pt"><span style=3D"font-family:monospace,monospace;white-space=
:pre-wrap;background-color:transparent">I </span><span style=3D"font-family=
:monospace,monospace">would like to get community feedback on whether the f=
ollowing idea would be reasonable to write as an informational BIP proposal=
:</span><br></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;mar=
gin-bottom:3pt"><font face=3D"monospace, monospace"><br>Boolean Addresses: =
Standardized p2sh addresses combining public keys, multisigs and time locks=
 with arbitrary and/or-operations<br><br><br>Abstract<br>=3D=3D=3D=3D=3D=3D=
=3D=3D<br>It is currently straightforward to create Bitcoin addresses which=
 can be redeemed by a single key or an m-of-n multi signature. It is not as=
 straight forward to create addresses that can be redeemed by, for example,=
 key A or (key B and key C).<br><br>This proposal describes a consistent wa=
y to create s type of p2sh addresses (=E2=80=9CBoolean addresses=E2=80=9D) =
which can be redeemed by an arbitrary set of keys and multi signatures comb=
ined with logical and/or operations.<br><br><br>Examples</font></p><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:3pt"><font =
face=3D"monospace, monospace">=3D=3D=3D=3D=3D=3D=3D=3D<br>In the examples b=
elow, Alice has key A, Bob key B, Charles key C, etc).<br><br>Example 1:<br=
><br>A corporation has an account that can be spent by the CEO Alice or two=
 board members (of Bob, Charles, David or Eric) in union. The account shoul=
d allow signatures by &quot;A or (2 of 4 of B, C, D, E)&quot;<br><br><br>Ex=
ample 2:</font></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;=
margin-bottom:3pt"><font face=3D"monospace, monospace"><br>Alice wants a bi=
tcoin address that she normally signs herself. However, if she has a fatal =
accident, she sets up a key &quot;B&quot; to be automatically mailed from a=
 cloud service after a given time of inactivity to close relatives Charles,=
 David and Eric. These relatives are also given keys written on paper.<br><=
br><br>Alice&#39;s address can be redeemed by &quot;A or (B and 1-of-3 of C=
, D, E)&quot;. This way, if the cloud wallet key B is compromised or paper =
wallets C, D or E are stolen, it is not sufficient to redeem the address. I=
f Alice=E2=80=99s key is lost, she can ask C, D, or E for their key and use=
 key B to spend the address to a new one with a new key for Alice.<br><br><=
br>Motivation</font></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top=
:0pt;margin-bottom:3pt"><font face=3D"monospace, monospace">=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<br>Standardisation of these addresses would allow interoper=
ability for wallet software to create, sign and share signature requests fo=
r such addresses.<br><br><br>Implementation<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<br>A Boolean address is described as a tree starting at a r=
oot node, where a node can be:<br><br>* An =E2=80=9Cand=E2=80=9D operation,=
 with a list of sub-nodes<br>* An =E2=80=9Cor=E2=80=9D operation, with a li=
st of sub-nodes<br>* A public key<br>* A Multisig operation n-of-m with a l=
ist of public keys<br>* A CHECKLOCKTIMEVERIFY operation<br><br>The implemen=
tation will describe a single well-defined way to generate a P2SH script fr=
om a given boolean address tree.<br><br>It will also define the ordering of=
 sub-nodes for and and or operations.<br><br>The implementation will furthe=
r detail how spending transactions are to be signed. A signature will consi=
st of keys required for a given path through the tree. Signing an =E2=80=9C=
or=E2=80=9D- branch of the tree, will consist of a value specifying which o=
r-subnode is signed, followed by the signatures for that node. That way, on=
ly one or-case has to be evaluated in the script.<br><br>For example, in th=
e case of an account that can be redeemed by the example &quot;A or (B and =
1-of-3 of C, D, E)&quot; from above, could be signed by something like:<br>=
<br>0 (meaning evaluate the first sub-node of the or condition)<br>A<br><br=
>or<br><br>1 (evaluate the second sub-node of the top level or condition)<b=
r>B<br>1 (One key for the multisig)<br>D (one of the 1-of-3 signatures)<br>=
0 (padding required for multisig opcode)</font></p></span><div><span style=
=3D"white-space:pre-wrap"><font face=3D"monospace, monospace"><br></font></=
span></div><div><font face=3D"arial"><span style=3D"white-space:pre-wrap"><=
br></span></font></div></div>

--001a114436168f881b054276d312--