[Bitcoin-development] Version 0.6 release candidate 1 plan

[Bitcoin-development] Version 0.6 release candidate 1 plan

[Gavin Andresen]

There are several major changes in git HEAD that are ready for wider
testing. The best way of getting lots of testing is to release
binaries, so I'm going to be pulling together a release candidate in
the next day or two.

The goal will be to get at least a full month of release candidate
review/testing before releasing a 0.6 final, with zero High Priority
bugs ( https://github.com/bitcoin/bitcoin/issues?labels=Priority+High&state=open
)

Here's the proposed TODO list for a rc1:

Pull:
800 : bug fix, multiple output display fix in GUI
799 : Have bitcoind recomend a secure RPC password
769 : Make transactions with extra data in scriptSig non-standard

Rebase/pull:
795 : Fix minimize to tray

Pull a modified version of:
755 : Don't vote for /P2SH/ unless -p2sh specified

I'd like to pull 787 (CAddrMan: stochastic address manager) but it
didn't pass my sanity tests.

I'm going to start a separate discussion thread with some thoughts on
rolling out higher-level multisignature support.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Version 0.6 release candidate 1 plan

[Luke-Jr]

On Monday, February 06, 2012 10:44:09 AM Gavin Andresen wrote:
> There are several major changes in git HEAD that are ready for wider
> testing. The best way of getting lots of testing is to release
> binaries, so I'm going to be pulling together a release candidate in
> the next day or two.

There are still many other pull requests that seem to be ready, but perhaps 
those can just as well wait for 0.7 if the 0.6 changes are deemed too much to 
add onto. Here are some that seem to be well-tested, and have been part of 
next-test for a while:
	719 coinbaser (already verbally accepted by Gavin for 0.6 a while ago!)
	568 rpc_keepalive
	565 optimize_FastGetWork
	715 bugfix_client_name
	562 optimize_ToHex

> 769 : Make transactions with extra data in scriptSig non-standard

If this affects relaying, it will significantly harm the ability to replace 
the current spammy "green address" scheme with a sensible extra signature 
system. On the miner end, it could significantly harm adoption of such a 
system.

> Pull a modified version of:
> 755 : Don't vote for /P2SH/ unless -p2sh specified

What else do I need to change for this?

> I'd like to pull 787 (CAddrMan: stochastic address manager) but it
> didn't pass my sanity tests.

I can also confirm I have seen at least one addr.db corruption with this.

Luke

Re: [Bitcoin-development] Version 0.6 release candidate 1 plan

[Luke-Jr]

On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote:
> > 769 : Make transactions with extra data in scriptSig non-standard
> 
> If this affects relaying, it will significantly harm the ability to replace
> the current spammy "green address" scheme with a sensible extra signature
> system. On the miner end, it could significantly harm adoption of such a
> system.

FWIW, at least MtGox was OK with the plan to move to non-blockchain-spam
0-confirmation via an extra signature. Why do you ignore this possibility, and 
merge stuff that will break it? Do you have an alternative solution to the 
problem of green addresses spamming the blockchain? As I noted in the pull 
request, stripping extra data has no negative impact on normal transactions, 
and clients creating these can be written to expect the txnid to change (or 
simply not care what the txnid is).

Re: [Bitcoin-development] Version 0.6 release candidate 1 plan

[Luke-Jr]

On Tuesday, February 07, 2012 10:04:36 AM Luke-Jr wrote:
> On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote:
> > > 769 : Make transactions with extra data in scriptSig non-standard
> > 
> > If this affects relaying, it will significantly harm the ability to
> > replace the current spammy "green address" scheme with a sensible extra
> > signature system. On the miner end, it could significantly harm adoption
> > of such a system.

gmaxwell explained to me why this is no longer needed on IRC.
I withdraw my objection.

Re: [Bitcoin-development] Version 0.6 release candidate 1 plan

[Gavin Andresen]

> Do you have an alternative solution to the
> problem of green addresses spamming the blockchain?

Sure, here's one:

Green address provider give a REST-ful API, that provides the
following functionality:

+ Give transaction ID and credentials, request that the transaction be
declared "green"
  (sender's wallet site/software would do this)

+ Give transaction ID, return boolean "has this transaction been
deeclared green?"



As I said, I think any design that relies on clients recognizing two
variations of a transaction is a very bad idea.

-- 
--
Gavin Andresen