rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-09-28 📝 Original message:On Mon, Sep 28, 2015 at 09:01:02AM -0400, Gavin Andresen wrote: > I think three things need to happen: > > 1) Stop pretending that "everyone must agree to make consensus rule > changes." "Rough consensus" is what we've always gone with, and is good > enough. > > 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 deploying > 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. Re: mempool, CLTV-using transactions are non-standard and are not relayed in all Bitcoin Core releases. (see my pull-req #5000 - Discourage NOPs reserved for soft-fork upgrades - for why) I believe that meets your suggestion of deploying mempool-only first. -- 'peter'[:-1]@petertodd.org 0000000000000000032420ad2987adc954df855f9ae10cf608e911b431f640e0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/24bdf9f3/attachment.sig>