Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-09-28 š Original message:On Mon, Sep 28, 2015 at ...
š
Original date posted:2015-09-28
š Original message:On Mon, Sep 28, 2015 at 09:43:42AM -0400, Gavin Andresen wrote:
> On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd <pete at petertodd.org> wrote:
>
> > > 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.
> >
>
> 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.
--
'peter'[:-1]@petertodd.org
0000000000000000102f6eb0772c453a0ad0e10a6f720f41a7f008a7d329ef66
-------------- 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/17258ef8/attachment.sig>;
š Original message:On Mon, Sep 28, 2015 at 09:43:42AM -0400, Gavin Andresen wrote:
> On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd <pete at petertodd.org> wrote:
>
> > > 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.
> >
>
> 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.
--
'peter'[:-1]@petertodd.org
0000000000000000102f6eb0772c453a0ad0e10a6f720f41a7f008a7d329ef66
-------------- 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/17258ef8/attachment.sig>;