Date: Fri, 8 Jul 2011 11:25:07 +0200
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20110708092506.GA6641@ulyssis.org>
References: <20110707111557.GA5231@ulyssis.org> <4E16A567.6020309@justmoon.de>
	<CAJNQ0st3ygLHPtq8fa9ceivSC1DQ38Hv+AQRiaXw=aL2Jze33Q@mail.gmail.com>
	<CAJNQ0su6MVJ7cz2uQ4ftGPykvYxWH7J7rk5Q0Us6JWM6zoW02Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJNQ0su6MVJ7cz2uQ4ftGPykvYxWH7J7rk5Q0Us6JWM6zoW02Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [Bitcoin-development] Version bytes
Precedence: list

On Fri, Jul 08, 2011 at 08:18:19AM +0000, John Smith wrote:
> 
> On Fri, Jul 8, 2011 at 6:36 AM, Stefan Thomas <moon@justmoon.de> wrote:
> >
> >> Hey Pieter,
> >>
> >> > Otherwise, we could reset testnet (not actually reset, just
> >> > change its addresses a bit), and simply state odd=testnet, even=realnet.
> >>
> >> We could use the XOR hack for now and remove it the next time we reset
> >> testnet. But I do think the 111 is baggage we want to get rid of. Using
> >> the lsb as a simple flag is much cleaner.
> 
> I agree it is cleaner, but I think breaking compatiblity with older address
> (even testnet) is not a good idea right now. It is important to build an
> image of stability and backward compatibility.
> 
> So I vote for the XOR 111 hack :)

It does have another advantage: it makes testnet codes visually (after base58
encoding) different from realnet ones, which is probably the reason why the
relatively large number 111 was chosen.

The only small change that can cause the first base58 character to remain equal,
is a modification to nVersion of less than 5 in absolute value.

PS: +/- 111 is also possible, instead of XOR 111.

-- 
Pieter