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