Bitcoin core 0.11 planning
6 messages, 28 Apr to 11 May 2015. Started by Wladimir J. van der Laan.
Wladimir J. van der Laan (3), Peter Todd (2), Pieter Wuille
Hello all,
The release window for 0.11 is nearing, I'd propose the following schedule:
2015-05-01 Soft translation string freeze
Open Transifex translations for 0.11
Finalize and close translation for 0.9
2015-05-15 Feature freeze, string freeze
2015-06-01 Split off 0.11 branch
Tag and release 0.11.0rc1
Start merging for 0.12 on master branch
2015-07-01 Release 0.11.0 final (aim)
In contrast to former releases, which were protracted for months, let's try to be more strict about the dates. Of course it is always possible for last-minute critical issues to interfere with the planning. The release will not be held up for features, though, and anything that will not make it to 0.11 will be postponed to next release scheduled for end of the year.
Wladimir
I'll point out that at this rate the soonest we'll see CHECKLOCKTIMEVERIFY implemented on Bitcoin will be something like summer 2016, a year and a half after it got adopted on Viacoin. (and a few other alts whose names I forget)
Right now the shortest path to adoption would be to release a v0.12 with just a CLTV soft-fork as soon as the BIP66 softfork triggers. While there's been proposal to change the way the upgrade mechanism triggers to a multiple parallel fork scheme, that is quite complex, stateful, and will need lots of review, probably a few months worth; faster would be to continue with the existing mechanism.
IMO the main reason to accelerate CLTV is scalability. The only viable scalability improvements possible in the short/medium term that don't entirely rely on trusting third parties are payment channel based. While we have a working payment channel scheme - Jeremy Spilman's refund tx based system - it is fairly complex, needs good and immediate backups, and is susceptible to tx malleability. CLTV fixes those issues robustly. Of course, payment channel schemes can start off with Spilman's scheme first and go to CLTV later, but that is a lot of extra code to be written and later depreciated - I'm sure many authors are dubious about going down that path.
Thoughts?
On 28 April 2015 03:44:16 GMT-04:00, "Wladimir J. van der Laan" <laanwj@gmail•com> wrote:
Quoted text (25 lines)
>Hello all, > >The release window for 0.11 is nearing, I'd propose the following >schedule: > >2015-05-01 Soft translation string freeze > Open Transifex translations for 0.11 > Finalize and close translation for 0.9 > >2015-05-15 Feature freeze, string freeze > >2015-06-01 Split off 0.11 branch > Tag and release 0.11.0rc1 > Start merging for 0.12 on master branch > >2015-07-01 Release 0.11.0 final (aim) > >In contrast to former releases, which were protracted for months, let's >try to be more strict about the dates. Of course it is always possible >for last-minute critical issues to interfere with the planning. The >release will not be held up for features, though, and anything that >will not make it to 0.11 will be postponed to next release scheduled >for end of the year. > >Wladimir
As softforks almost certainly require backports to older releases and other software anyway, I don't think they should necessarily be bound to Bitcoin Core major releases. If they don't require large code changes, we can easily do them in minor releases too. On Apr 28, 2015 12:51 PM, "Peter Todd" <pete@petertodd•org> wrote:
Quoted text (81 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'll point out that at this rate the soonest we'll see CHECKLOCKTIMEVERIFY > implemented on Bitcoin will be something like summer 2016, a year and a > half after it got adopted on Viacoin. (and a few other alts whose names I > forget) > > Right now the shortest path to adoption would be to release a v0.12 with > just a CLTV soft-fork as soon as the BIP66 softfork triggers. While there's > been proposal to change the way the upgrade mechanism triggers to a > multiple parallel fork scheme, that is quite complex, stateful, and will > need lots of review, probably a few months worth; faster would be to > continue with the existing mechanism. > > IMO the main reason to accelerate CLTV is scalability. The only viable > scalability improvements possible in the short/medium term that don't > entirely rely on trusting third parties are payment channel based. While we > have a working payment channel scheme - Jeremy Spilman's refund tx based > system - it is fairly complex, needs good and immediate backups, and is > susceptible to tx malleability. CLTV fixes those issues robustly. Of > course, payment channel schemes can start off with Spilman's scheme first > and go to CLTV later, but that is a lot of extra code to be written and > later depreciated - I'm sure many authors are dubious about going down that > path. > > Thoughts? > > > On 28 April 2015 03:44:16 GMT-04:00, "Wladimir J. van der Laan" < > laanwj@gmail•com> wrote: > >Hello all, > > > >The release window for 0.11 is nearing, I'd propose the following > >schedule: > > > >2015-05-01 Soft translation string freeze > > Open Transifex translations for 0.11 > > Finalize and close translation for 0.9 > > > >2015-05-15 Feature freeze, string freeze > > > >2015-06-01 Split off 0.11 branch > > Tag and release 0.11.0rc1 > > Start merging for 0.12 on master branch > > > >2015-07-01 Release 0.11.0 final (aim) > > > >In contrast to former releases, which were protracted for months, let's > >try to be more strict about the dates. Of course it is always possible > >for last-minute critical issues to interfere with the planning. The > >release will not be held up for features, though, and anything that > >will not make it to 0.11 will be postponed to next release scheduled > >for end of the year. > > > >Wladimir > -----BEGIN PGP SIGNATURE----- > > iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVP2Wy > AAoJEMCF8hzn9LncqOcH/3rDFbgWprqTfk8dKWAItRcY6ZyiQ+dNrqNgymaNP5Ig > MNKaTmWYyZRH6PW13JOv72ArXia+D82Mp5reTaLIb3TV5uef2biruOCaH9eI8Uv5 > i2PCBLw3uqZIZZ5Qr/7nlp2CaBQIGDK3fg3jx10UyWpg4BxkKP2mLJibMG8l3JcK > Moi/kh6lvwySpT8NYtZfXax+5AQ2oLXiSzbFF8P0ioI9fJYaoVCAyS5VEE4KsZnV > thOaoPAWoK+spEYKFrjvyXnQXFe6m+KPfRPU3WKYSFhI7m8MW6bKxEnD0Lffo6qU > YS6jsE3A0LoKs4kD73ivHcMeXDhO6LXyPAu8zQtgGr8= > =Z/GT > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Tue, Apr 28, 2015 at 04:01:00AM -0700, Pieter Wuille wrote:
Quoted text (4 lines)
> As softforks almost certainly require backports to older releases and other > software anyway, I don't think they should necessarily be bound to Bitcoin > Core major releases. If they don't require large code changes, we can > easily do them in minor releases too.
The code changes for absolute CLTV are quite small, and easily ported to any Bitcoin Core version.
What's the oldest version you think we need backports for?
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
Quoted text (4 lines)
> As softforks almost certainly require backports to older releases and other > software anyway, I don't think they should necessarily be bound to Bitcoin > Core major releases. If they don't require large code changes, we can easily > do them in minor releases too.
Agree here - there is no need to time consensus changes with a major release, as they need to be ported back to older releases anyhow. (I don't really classify them as software features, but properties of the underlying system that we need to adopt to)
Wladimir
A reminder - feature freeze and string freeze is coming up this Friday the 15th.
Let me know if your pull request is ready to be merged before then,
Wladimir
On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan <laanwj@gmail•com> wrote:
Quoted text (19 lines)
> Hello all, > > The release window for 0.11 is nearing, I'd propose the following schedule: > > 2015-05-01 Soft translation string freeze > Open Transifex translations for 0.11 > Finalize and close translation for 0.9 > > 2015-05-15 Feature freeze, string freeze > > 2015-06-01 Split off 0.11 branch > Tag and release 0.11.0rc1 > Start merging for 0.12 on master branch > > 2015-07-01 Release 0.11.0 final (aim) > > In contrast to former releases, which were protracted for months, let's try to be more strict about the dates. Of course it is always possible for last-minute critical issues to interfere with the planning. The release will not be held up for features, though, and anything that will not make it to 0.11 will be postponed to next release scheduled for end of the year. > > Wladimir