Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XWSm4-0006Fy-Gx for bitcoin-development@lists.sourceforge.net; Tue, 23 Sep 2014 16:17:08 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.182 as permitted sender) client-ip=209.85.216.182; envelope-from=etotheipi@gmail.com; helo=mail-qc0-f182.google.com; Received: from mail-qc0-f182.google.com ([209.85.216.182]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XWSm3-0003QZ-G7 for bitcoin-development@lists.sourceforge.net; Tue, 23 Sep 2014 16:17:08 +0000 Received: by mail-qc0-f182.google.com with SMTP id m20so1974773qcx.41 for ; Tue, 23 Sep 2014 09:17:01 -0700 (PDT) X-Received: by 10.224.73.132 with SMTP id q4mr984731qaj.78.1411489021868; Tue, 23 Sep 2014 09:17:01 -0700 (PDT) Received: from [192.168.1.85] (c-69-143-221-64.hsd1.md.comcast.net. [69.143.221.64]) by mx.google.com with ESMTPSA id z32sm10588354qgd.40.2014.09.23.09.17.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 09:17:01 -0700 (PDT) Message-ID: <54219CF9.7080500@gmail.com> Date: Tue, 23 Sep 2014 12:16:57 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XWSm3-0003QZ-G7 Subject: [Bitcoin-development] Proposal: "No-Collision" mode for Multisig BIP32 Wallets X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 16:17:08 -0000 This topic has been touched on briefly here before, but I wanted to solidify it and propose it as a BIP if there is wider support for it.=20 Also, the topic is difficult to discuss without lots of pictures -- so that's what I've done (mainly to describe it to my team, but also as general documentation). It's in presentation form: https://s3.amazonaws.com/bitcoinarmory-media/MultisigWalletNoCollide.pdf The proposal is that for an M-of-N multisig wallet based on BIP32, there should be N internal chains and N external chains. Each party is assigned a chain based on the lexicographic ordering of their wallet's root public key in the multisig. This guarantees that no parties are generating and distributing the same addresses, and also provides a certain level of built-in book-keeping. Coins being received on chain 2*x were created by participant x (receiving), and coins received on 2*x+1 are change outputs created by participant x (outgoing). Thus, it's easy from simply looking at the wallet structure who was responsible for which transactions. Alternatively, we could change it to suggest that each "device" is assigned a pair of chains. For a 2-of-3 there may 3 participants plus a CFO with a "watch-only" version of the multisig wallet. Then you might use four pairs of chains. I'm just not sure how they would be assigned. If this has been proposed before, then consider this my contribution to documentation.=20 -Alan P.S. -- "No-Collision Mode" is not a great name. Happy to take suggestions for changing it.