Version 0.6 release candidate 1 plan
5 messages, 6 to 7 Feb 2012. Started by Gavin Andresen.
Luke Dashjr (3), Gavin Andresen (2)
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.
On Monday, February 06, 2012 10:44:09 AM Gavin Andresen wrote:
Quoted text (4 lines)
> 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
Quoted text (1 line)
> 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.
Quoted text (2 lines)
> Pull a modified version of: > 755 : Don't vote for /P2SH/ unless -p2sh specified
What else do I need to change for this?
Quoted text (2 lines)
> 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
On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote:
Quoted text (6 lines)
> > 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).
On Tuesday, February 07, 2012 10:04:36 AM Luke-Jr wrote:
Quoted text (7 lines)
> 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.
Quoted text (2 lines)
> 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.