Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F16F1985 for ; Mon, 28 Sep 2015 14:14:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148154.authsmtp.co.uk (outmail148154.authsmtp.co.uk [62.13.148.154]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C1B2C222 for ; Mon, 28 Sep 2015 14:14:48 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SEElUg026941; Mon, 28 Sep 2015 15:14:47 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SEEgqo025254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Sep 2015 15:14:44 +0100 (BST) Date: Mon, 28 Sep 2015 10:14:41 -0400 From: Peter Todd To: Gavin Andresen Message-ID: <20150928141441.GA21815@savin.petertodd.org> References: <20150927185031.GA20599@savin.petertodd.org> <20150928132814.GB4829@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 44f55940-65eb-11e5-b399-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAoUC1AEAgsB AmMbWlFeUVl7XWY7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRRi c2tJE0ZydQBEfXo+ ZEVgXHcVWEAscEN0 Rk5JE2hTN3phaTUa TRJbfgpJcANIexZF O1F6ACIKLwdSbGoL FQ4vNDcwO3BTJTpg CiUAMR0JCUoGBjo7 VlgoPA1xQAUuZwgY DDgBAX0gPWM8DGgI EHUQEDp/ X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 14:14:49 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2015 at 09:43:42AM -0400, Gavin Andresen wrote: > On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd wrote: >=20 > > > 2) Mr. Todd (or somebody) needs to write up a risk/benefit security > > > tradeoff analysis doo-hickey document and publish it. I'm reasonably > > > confident that the risks to SPV nodes can be mitigated (e.g. by deplo= ying > > > mempool-only first, before the soft fork rolls out), but as somebody = who > > > has only been moderately paying attention, BETTER COMMUNICATION is > > needed. > > > What should SPV wallet authors be doing right now, if anything? Once = the > > > soft fork starts to roll out or activates, what do miners need to be > > aware > > > of? SPV wallet authors? > > > > Do you have such a document for your BIP101? That would save me a lot of > > time, and the need for that kind of document is significantly higher > > with BIP101 anyway. > > >=20 > Hmmm? When I asked YOU for that kind of security analysis document, you > said you'd see if any of your clients would be willing to let you publish > one you'd done in the past. Then I never heard back from you. I don't remember what you are referring to at all. Was this a private email? IRC chat? In person discussion? > So, no, I don't have one for BIP 101, but unless you were lying and just > trying to add Yet Another Hoop for BIP 101 to jump through, you should > already have something to start from. "unless you were lying" Please keep the discussion on the development mailing list civil and respectful. > RE: mempool only: yes, pull-req 5000 satisfies (and that's what I was > thinking of). There should be a nice, readable blog post explaining to > other full node implementors and wallet implementors why that was done for > Core and what they should do to follow 'best practices to be soft-fork > ready.' Actually, that sounds like the kind of thing that should be in the bitcoin.org developer documentation; IMO for the audience of competent full node developers the comments in the pull-req code itself and associated discussion covers everything they need to know. Without that background though, this is something that'd fit well in the category of general education to get new developers to a good state of competence. As for wallets specifically, that's pretty much all covered by SPV wallets based on bitcoinj, and Mike Hearn has different views on the subject which need to be resolved first. --=20 'peter'[:-1]@petertodd.org 0000000000000000102f6eb0772c453a0ad0e10a6f720f41a7f008a7d329ef66 --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWCUtNXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwY2E2MjYzNzRmMjVkYWRiYmI5MjQ1ZTYwNTYzYTRkODc2 ZjNjNzMwNzBhZDM4NDkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft3MAf+LD5ELAZfnu3d9QeBs6RbIBT5 IkSbA3VvFZqDmsCUJhPVCHKLtp+MJWzQ3S4woNkjt6qD/Ym2c9Cp9uTByBQ2OwXI zud5uBoJNryS1oe90lVC+RVdZV+eRzVyl7ml5lDrYf8Rvh/VdtI+HmPLiryEC/4w DXL3demXVhMBlk4bDI1Vr5foxkgjWI187kn+6JmLx+UrSwMoyGf+ilfnh/suU+1k q45hIAjZ7T8cx0s50bteYzQGxeU301hL3SkuCfqiEasfE+r8C5JQ/gsKORinS+UR VBdqLWgrZfJpFnem5PLg94Xq/mc0gxnH2RzFXZAxqR4+WOLjpvZ8rr+8/nlrwQ== =zXTS -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--