Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 56438959 for ; 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 ; Tue, 29 Nov 2016 20:56:48 +0000 (UTC) Received: by mail-wm0-f52.google.com with SMTP id t79so200015832wmt.0 for ; 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 Date: Tue, 29 Nov 2016 21:56:45 +0100 X-Google-Sender-Auth: 1qRTzrVNbd-RNCV8UUwSg9V3LN0 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

I would like to get community feedback on whether the f= ollowing 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 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.


Examples

=3D=3D=3D=3D=3D=3D=3D=3D
In the examples b= elow, 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 shoul= d allow signatures by "A or (2 of 4 of B, C, D, E)"


Ex= ample 2:


Alice wants a bi= tcoin 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.
<= br>
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. 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>Motivation

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Standardisation of these addresses would allow interoper= ability for wallet software to create, sign and share signature requests fo= r 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 r= oot 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 li= st of sub-nodes
* A public key
* A Multisig operation n-of-m with a l= ist of public keys
* A CHECKLOCKTIMEVERIFY operation

The implemen= tation will describe a single well-defined way to generate a P2SH script fr= om a given boolean address tree.

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

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.

For example, in th= e 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)


<= br>
--001a114436168f881b054276d312--