Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.47 as permitted sender)
	client-ip=209.85.210.47; envelope-from=laanwj@gmail.com;
	helo=mail-pz0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <CABsx9T09h4EQ=3BFyu-7k9D_t1ryWoC5go4yu4xwsaob9ciK6Q@mail.gmail.com>
References: <CABsx9T09h4EQ=3BFyu-7k9D_t1ryWoC5go4yu4xwsaob9ciK6Q@mail.gmail.com>
Date: Mon, 6 Feb 2012 18:27:20 +0100
Message-ID: <CA+s+GJC7N3k8n335mHa7hU-Lq4uO6mu1QBLX30G+68cBtDSg3w@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b10d1cd8f2f1d04b84ef971
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Multisignature transaction support in the
	GUI
Precedence: list

--047d7b10d1cd8f2f1d04b84ef971
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 6, 2012 at 5:07 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:

>
> Advantage of (2) is it should mean more testing of multisig, and fewer
> bug reports of "I added a multisig address via RPC but I can't send to
> it using the GUI"
>
> My opinion: I think it is worth allowing send-to-multisig-address via
> the GUI (should be a very simple change to the address validation
> logic).  But creating multisig addresses via the GUI should wait until
> the next release.
>

I think we should go with (2), changing the maximum address length and
validation is very easy. We'd need to

   - Change BitcoinAddressValidator::MaxAddressLength to 35
   - The addresses are validated with walletmodel->validateAddress which in
   turn calls CBitcoinAddress addressParsed(addr) and then isValid(). Does
   this work for the new addresses?

The set of allowed characters is still the same, so BitcoinAddressValidator
doesn't have to be changed.

Advanced dialogs for constructing the addresses / adding them to the
address book could wait for 0.7.0.

Wladimir

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

<div class=3D"gmail_quote">On Mon, Feb 6, 2012 at 5:07 PM, Gavin Andresen <=
span dir=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com">gavinandres=
en@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Advantage of (2) is it should mean more testing of multisig, and fewer<br>
bug reports of &quot;I added a multisig address via RPC but I can&#39;t sen=
d to<br>
it using the GUI&quot;<br>
<br>
My opinion: I think it is worth allowing send-to-multisig-address via<br>
the GUI (should be a very simple change to the address validation<br>
logic). =C2=A0But creating multisig addresses via the GUI should wait until=
<br>
the next release.<br></blockquote><div><br></div>I think we should go with =
(2),=C2=A0changing the maximum address length and validation is very easy. =
We&#39;d need to</div><div class=3D"gmail_quote"><ul><li>Change BitcoinAddr=
essValidator::MaxAddressLength to 35</li>
<li>The addresses are validated with walletmodel-&gt;validateAddress which =
in turn calls=C2=A0CBitcoinAddress addressParsed(addr) and then isValid(). =
Does this work for the new addresses?</li></ul></div><div class=3D"gmail_qu=
ote">
The set of allowed characters is still the same, so BitcoinAddressValidator=
 doesn&#39;t have to be changed.</div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">Advanced dialogs for constructing the addresses =
/ adding them to the address book could wait for 0.7.0.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Wladimir</d=
iv><div class=3D"gmail_quote"><br></div>

--047d7b10d1cd8f2f1d04b84ef971--