* [Bitcoin-development] Version 0.6 release candidate 1 plan
@ 2012-02-06 15:44 Gavin Andresen
2012-02-06 15:54 ` Luke-Jr
0 siblings, 1 reply; 5+ messages in thread
From: Gavin Andresen @ 2012-02-06 15:44 UTC (permalink / raw)
To: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Version 0.6 release candidate 1 plan
2012-02-06 15:44 [Bitcoin-development] Version 0.6 release candidate 1 plan Gavin Andresen
@ 2012-02-06 15:54 ` Luke-Jr
2012-02-07 15:04 ` Luke-Jr
0 siblings, 1 reply; 5+ messages in thread
From: Luke-Jr @ 2012-02-06 15:54 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Version 0.6 release candidate 1 plan
2012-02-06 15:54 ` Luke-Jr
@ 2012-02-07 15:04 ` Luke-Jr
2012-02-07 16:14 ` Luke-Jr
2012-02-07 16:14 ` Gavin Andresen
0 siblings, 2 replies; 5+ messages in thread
From: Luke-Jr @ 2012-02-07 15:04 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
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).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Version 0.6 release candidate 1 plan
2012-02-07 15:04 ` Luke-Jr
@ 2012-02-07 16:14 ` Luke-Jr
2012-02-07 16:14 ` Gavin Andresen
1 sibling, 0 replies; 5+ messages in thread
From: Luke-Jr @ 2012-02-07 16:14 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Version 0.6 release candidate 1 plan
2012-02-07 15:04 ` Luke-Jr
2012-02-07 16:14 ` Luke-Jr
@ 2012-02-07 16:14 ` Gavin Andresen
1 sibling, 0 replies; 5+ messages in thread
From: Gavin Andresen @ 2012-02-07 16:14 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-02-07 16:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-06 15:44 [Bitcoin-development] Version 0.6 release candidate 1 plan Gavin Andresen
2012-02-06 15:54 ` Luke-Jr
2012-02-07 15:04 ` Luke-Jr
2012-02-07 16:14 ` Luke-Jr
2012-02-07 16:14 ` Gavin Andresen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox