From: Gregory Maxwell <greg@xiph•org>
To: Rusty Russell <rusty@rustcorp•com.au>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Blockchain verification flag (BIP draft)
Date: Sun, 6 Dec 2015 05:13:15 +0000 [thread overview]
Message-ID: <CAAS2fgRMi3KKKUW_7eunG9cprOLtz8yrEtA+8ChiCgninjMMZw@mail.gmail.com> (raw)
In-Reply-To: <871tb16diz.fsf@rustcorp.com.au>
On Fri, Dec 4, 2015 at 10:43 PM, Rusty Russell <rusty@rustcorp•com.au> wrote:
>> I agree with Jannes Faber, behavior with respect to SPV clients should be
>> to only tell them about fully validated headers.
>
> A delicate balance. If we penalize these blocks too much, it's
> disincentive to set the bit. Fortunately it's easy for SPV clients to
> decide for themselves, I think?
I think this is orthogonal: You should only tell SPV clients* about
blocks you've fully validated yourself. The bit in the header doesn't
matter with respect to that. (Effectively, the wallet risk model gets
as input the fact that they got given the block in the first place as
well as the flag where the miner said they were validating things or
not.)
Whatever the ideal behavior is for network nodes towards lite clients;
it's insanely cheap to just spin up a lot of 'nodes' that have
arbitrary behavior; so it shouldn't be relied on too much; but
absolutely they should be filtering to things they've verified
themselves... unlike the mining case, there is no reason not to.
[Specific attacks to consider: You get a broken miner to include both
your payment, and some invalid transaction. Other miners extend it
without verifying. To avoid the fact that nodes sensibly filter
invalid blocks from their lite clients, you simply just run a lot of
'nodes' so that virtually every lite client has a connection to you]
(More specifically, peers should be able to specify that they want to
know about pre-validated blocks and you should be able to fetch blocks
from them which haven't been validated... but no one should get fed
unverified blocks by surprise.)
prev parent reply other threads:[~2015-12-06 5:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 8:26 Gregory Maxwell
2015-12-04 12:44 ` Jannes Faber
2015-12-04 16:46 ` Thomas Kerin
2015-12-04 17:34 ` Gavin Andresen
2015-12-04 22:43 ` Rusty Russell
2015-12-06 2:47 ` James Hilliard
2015-12-06 6:26 ` Gregory Maxwell
2015-12-06 5:13 ` Gregory Maxwell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgRMi3KKKUW_7eunG9cprOLtz8yrEtA+8ChiCgninjMMZw@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rusty@rustcorp$(echo .)com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox