Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1We0uK-0002cl-ND for bitcoin-development@lists.sourceforge.net; Sat, 26 Apr 2014 11:36:36 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.46 as permitted sender) client-ip=209.85.216.46; envelope-from=manuelaraoz@gmail.com; helo=mail-qa0-f46.google.com; Received: from mail-qa0-f46.google.com ([209.85.216.46]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1We0uJ-0005lB-SP for bitcoin-development@lists.sourceforge.net; Sat, 26 Apr 2014 11:36:36 +0000 Received: by mail-qa0-f46.google.com with SMTP id i13so4642708qae.33 for ; Sat, 26 Apr 2014 04:36:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.44.34 with SMTP id f31mr17670185qga.73.1398512190322; Sat, 26 Apr 2014 04:36:30 -0700 (PDT) Sender: manuelaraoz@gmail.com Received: by 10.224.20.9 with HTTP; Sat, 26 Apr 2014 04:36:30 -0700 (PDT) Received: by 10.224.20.9 with HTTP; Sat, 26 Apr 2014 04:36:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Apr 2014 08:36:30 -0300 X-Google-Sender-Auth: etjpyh65IltMRgMPxl2poK7wGPw Message-ID: From: Manuel Araoz To: Mike Hearn Content-Type: multipart/alternative; boundary=001a1139fdda51c2a804f7f07e57 X-Spam-Score: -0.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 (manuelaraoz[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1We0uJ-0005lB-SP Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] New BIP32 structure for P2SH multisig 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: Sat, 26 Apr 2014 11:36:36 -0000 --001a1139fdda51c2a804f7f07e57 Content-Type: text/plain; charset=ISO-8859-1 On Apr 26, 2014 6:43 AM, "Mike Hearn" wrote: > > I'm not sure I understand why you need any special structure for this at all. The way I'd do it is just use regular HD wallets for everyone, of the regular form, and then swap the watching keys. Why do people need to be given a cosigner index at all, given that they all have unique root keys anyway? I tried to explain that here: The reason for using separate branches for each cosigner is we don't want two of them generating the same address and receiving simultaneous payments to it. The ideal case is that each address receives at most one payment, requested by the corresponding cosigner. To clarify, the problem the cosigner_index is trying to solve is race conditions when receiving payments. Remember that we can't assume all cosigners to be online at all times. Let's assume we use one shared branch for everyone. Then two cosigners could need a new receiving address at the same time, and get the next unused address on that branch. They then each pass the same address to their payers, and we can get two payments to the same address. Monitoring balances is not enough in this case because a cosigner can never know when the others are generating a new address. Separating branches and having each cosigner only use one branch makes this problem go away. --001a1139fdda51c2a804f7f07e57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 26, 2014 6:43 AM, "Mike Hearn" <mike@plan99.net> wrote:
>
> I'm not sure I understand why you need any special structure for t= his at all. The way I'd do it is just use regular HD wallets for everyo= ne, of the regular form, and then swap the watching keys. Why do people nee= d to be given a cosigner index at all, given that they all have unique root= keys anyway?

I tried to explain that here:

The reason for using separate branches for each cosigner is = we don't want two of them generating the same address and receiving sim= ultaneous payments to it. The ideal case is that each address receives at m= ost one payment, requested by the corresponding cosigner.=A0

To clarify, the problem the cosigner_index is trying to solv= e is race conditions when receiving payments. Remember that we can't as= sume all cosigners to be online at all times. Let's assume we use one s= hared branch for everyone. Then two cosigners could need a new receiving ad= dress at the same time, and get the next unused address on that branch. The= y then each pass the same address to their payers, and we can get two payme= nts to the same address. Monitoring balances is not enough in this case bec= ause a cosigner can never know when the others are generating a new address= . Separating branches and having each cosigner only use one branch makes th= is problem go away.

--001a1139fdda51c2a804f7f07e57--