<oembed><type>rich</type><version>1.0</version><author_name>npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_name><author_url>https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-09-28&#xA;📝 Original message:On Mon, Sep 28, 2015 at 09:43:42AM -0400, Gavin Andresen wrote:&#xA;&gt; On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd &lt;pete at petertodd.org&gt; wrote:&#xA;&gt; &#xA;&gt; &gt; &gt; 2) Mr. Todd (or somebody) needs to write up a risk/benefit security&#xA;&gt; &gt; &gt; tradeoff analysis doo-hickey document and publish it. I&#39;m reasonably&#xA;&gt; &gt; &gt; confident that the risks to SPV nodes can be mitigated (e.g. by deploying&#xA;&gt; &gt; &gt; mempool-only first, before the soft fork rolls out), but as somebody who&#xA;&gt; &gt; &gt; has only been moderately paying attention, BETTER COMMUNICATION is&#xA;&gt; &gt; needed.&#xA;&gt; &gt; &gt; What should SPV wallet authors be doing right now, if anything? Once the&#xA;&gt; &gt; &gt; soft fork starts to roll out or activates, what do miners need to be&#xA;&gt; &gt; aware&#xA;&gt; &gt; &gt; of? SPV wallet authors?&#xA;&gt; &gt;&#xA;&gt; &gt; Do you have such a document for your BIP101? That would save me a lot of&#xA;&gt; &gt; time, and the need for that kind of document is significantly higher&#xA;&gt; &gt; with BIP101 anyway.&#xA;&gt; &gt;&#xA;&gt; &#xA;&gt; Hmmm?  When I asked YOU for that kind of security analysis document, you&#xA;&gt; said you&#39;d see if any of your clients would be willing to let you publish&#xA;&gt; one you&#39;d done in the past. Then I never heard back from you.&#xA;&#xA;I don&#39;t remember what you are referring to at all. Was this a private&#xA;email? IRC chat? In person discussion?&#xA;&#xA;&gt; So, no, I don&#39;t have one for BIP 101, but unless you were lying and just&#xA;&gt; trying to add Yet Another Hoop for BIP 101 to jump through, you should&#xA;&gt; already have something to start from.&#xA;&#xA;&#34;unless you were lying&#34;&#xA;&#xA;Please keep the discussion on the development mailing list civil and&#xA;respectful.&#xA;&#xA;&gt; RE: mempool only: yes, pull-req 5000 satisfies (and that&#39;s what I was&#xA;&gt; thinking of). There should be a nice, readable blog post explaining to&#xA;&gt; other full node implementors and wallet implementors why that was done for&#xA;&gt; Core and what they should do to follow &#39;best practices to be soft-fork&#xA;&gt; ready.&#39;&#xA;&#xA;Actually, that sounds like the kind of thing that should be in the&#xA;bitcoin.org developer documentation; IMO for the audience of competent&#xA;full node developers the comments in the pull-req code itself and&#xA;associated discussion covers everything they need to know. Without that&#xA;background though, this is something that&#39;d fit well in the category of&#xA;general education to get new developers to a good state of competence.&#xA;&#xA;As for wallets specifically, that&#39;s pretty much all covered by SPV&#xA;wallets based on bitcoinj, and Mike Hearn has different views on the&#xA;subject which need to be resolved first.&#xA;&#xA;-- &#xA;&#39;peter&#39;[:-1]@petertodd.org&#xA;0000000000000000102f6eb0772c453a0ad0e10a6f720f41a7f008a7d329ef66&#xA;-------------- next part --------------&#xA;A non-text attachment was scrubbed...&#xA;Name: signature.asc&#xA;Type: application/pgp-signature&#xA;Size: 650 bytes&#xA;Desc: Digital signature&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/17258ef8/attachment.sig&gt;</html></oembed>