From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yn3GI-00051K-KS for bitcoin-development@lists.sourceforge.net; Tue, 28 Apr 2015 11:01:10 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.169 as permitted sender) client-ip=209.85.217.169; envelope-from=pieter.wuille@gmail.com; helo=mail-lb0-f169.google.com; Received: from mail-lb0-f169.google.com ([209.85.217.169]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yn3GE-0008Bl-QO for bitcoin-development@lists.sourceforge.net; Tue, 28 Apr 2015 11:01:10 +0000 Received: by lbbqq2 with SMTP id qq2so104023742lbb.3 for ; Tue, 28 Apr 2015 04:01:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.203.162 with SMTP id kr2mr14078941lac.68.1430218860436; Tue, 28 Apr 2015 04:01:00 -0700 (PDT) Received: by 10.112.19.7 with HTTP; Tue, 28 Apr 2015 04:01:00 -0700 (PDT) Received: by 10.112.19.7 with HTTP; Tue, 28 Apr 2015 04:01:00 -0700 (PDT) In-Reply-To: <4E63339A-69B1-4885-9D7F-6D14E75CE174@petertodd.org> References: <20150428074414.GA19918@amethyst.visucore.com> <4E63339A-69B1-4885-9D7F-6D14E75CE174@petertodd.org> Date: Tue, 28 Apr 2015 04:01:00 -0700 Message-ID: From: Pieter Wuille To: Peter Todd Content-Type: multipart/alternative; boundary=001a1134632620e3f20514c6c7f1 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Yn3GE-0008Bl-QO Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bitcoin core 0.11 planning X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 11:01:10 -0000 --001a1134632620e3f20514c6c7f1 Content-Type: text/plain; charset=ISO-8859-1 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" wrote: > -----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 > --001a1134632620e3f20514c6c7f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

As softforks almost certainly require backports to older rel= eases and other software anyway, I don't think they should necessarily = be bound to Bitcoin Core major releases. If they don't require large co= de changes, we can easily do them in minor releases too.

On Apr 28, 2015 12:51 PM, "Peter Todd"= <pete@petertodd.org> wrote= :
-----BEGIN PGP SIG= NED MESSAGE-----
Hash: SHA256

I'll point out that at this rate the soonest we'll see CHECKLOCKTIM= EVERIFY implemented on Bitcoin will be something like summer 2016, a year a= nd a half after it got adopted on Viacoin. (and a few other alts whose name= s I forget)

Right now the shortest path to adoption would be to release a v0.12 with ju= st 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 mult= iple parallel fork scheme, that is quite complex, stateful, and will need l= ots of review, probably a few months worth; faster would be to continue wit= h the existing mechanism.

IMO the main reason to accelerate CLTV is scalability. The only viable scal= ability improvements possible in the short/medium term that don't entir= ely rely on trusting third parties are payment channel based. While we have= a working payment channel scheme - Jeremy Spilman's refund tx based sy= stem - it is fairly complex, needs good and immediate backups, and is susce= ptible to tx malleability. CLTV fixes those issues robustly. Of course, pay= ment channel schemes can start off with Spilman's scheme first and go t= o CLTV later, but that is a lot of extra code to be written and later depre= ciated - I'm sure many authors are dubious about going down that path.<= br>
Thoughts?


On 28 April 2015 03:44:16 GMT-04:00, "Wladimir J. van der Laan" &= lt;laanwj@gmail.com> wrote:
>Hello all,
>
>The release window for 0.11 is nearing, I'd propose the following >schedule:
>
>2015-05-01=A0 Soft translation string freeze
>=A0 =A0 =A0 =A0 =A0 =A0 Open Transifex translations for 0.11
>=A0 =A0 =A0 =A0 =A0 =A0 Finalize and close translation for 0.9
>
>2015-05-15=A0 Feature freeze, string freeze
>
>2015-06-01=A0 Split off 0.11 branch
>=A0 =A0 =A0 =A0 =A0 =A0 Tag and release 0.11.0rc1
>=A0 =A0 =A0 =A0 =A0 =A0 Start merging for 0.12 on master branch
>
>2015-07-01=A0 Release 0.11.0 final (aim)
>
>In contrast to former releases, which were protracted for months, let&#= 39;s
>try to be more strict about the dates. Of course it is always possible<= br> >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=3D
=3DZ/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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--001a1134632620e3f20514c6c7f1--