From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Date: Fri, 16 Aug 2013 10:01:16 -0400 [thread overview]
Message-ID: <20130816140116.GB16201@petertodd.org> (raw)
In-Reply-To: <CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4454 bytes --]
On Fri, Aug 16, 2013 at 02:24:04PM +0200, Mike Hearn wrote:
> The only other thing I'd like to see there is the start of a new anti-DoS
> framework. I think once the outline is in place other people will be able
> to fill it in appropriately. But the current framework has to be left
> behind.
Part of anti-DoS should include making it easier for people to
contribute back to the network. Lowest hanging fruit:
1) SPV nodes with spare bandwidth should relay whole blocks to reduce
the load on full-nodes. The SPV security model is based on hashing power
anyway, so there is no major harm in doing so - if you have the
resources to fake blocks, you probably have the resources to sybil the
network anyway.
2) It's probably reasonable for SPV peers with bandwidth to be willing
to do bloom filtering on the behalf of peers that don't have spare
bandwidth. Hence they would set NODE_BLOOM, but not NODE_NETWORK. (or
more likely some more nuanced flags) Again this has to apply to full
blocks only unless we come up with some PoW scheme or similar to
discourage DoS attacks via invalid transactions. (maintaining partial
UTXO sets is another possibility, although a complex one)
Both examples work best with payment protocols where the recipient is
responsible for getting the transaction broadcast. Similarly you can by
default not connect to full-node peers, and then connect to them on
demand when you have a transaction to send.
Doing this also makes it more difficult to sybil the network - for
instance right now you can create "SPV honeypots" that allow incoming
connections only from SPV nodes, thus attracting a disproportionate % of
the total SPV population given a relatively small number of nodes. You
can then use that to harm SPV nodes by, for instance, making a % of
transactions be dropped deterministicly, either by the bloom matching
code, or when sent. Users unlucky enough to be surrounded by sybil nodes
will have their transactions mysteriously fail to arrive in their
wallets, or have their transactions mysteriously never confirm. Given
how few full nodes there are, it probably won't take very many honeypots
to pull off this attack, especially if you combine it with a
simultaneous max connections or bloom io attack to degrade the capacity
of honest nodes.
Deanonymization is another attack that can be done at the same time of
course.
In any case, the more peers on the network that can relay data the
better.
3) Make it easier to run a full node. IMO partial mode is the way to go
here. Note that from a legal perspective we really want to make sure
that running full nodes (and mining p2pool or solo) continue to be
something ordinary users do. We do not want to give the impression to
regulators that running a full node is in any way unusual or rare, and
thus something that might be practical or desirable to regulate. Users
should be given clear options about how much disk space and bandwidth to
donate to the health of the network, and within those limits nodes
should always try to make progress towards being full nodes, and in the
meantime being increasingly productive partial nodes.
Even with pure SPV nodes if they are relaying block data and ideally
transactions they make it much more difficult for regulations to be made
that, say, require full node operators to apply blacklists to
transactions in the mempool or in blocks.
4) This is really a side effect, and not directly DoS-related, but
unfortunately we're going to have to create some kind of
proof-of-UTXO-possession that miners include in the blocks they mine.
With partial mode it's just too easy and tempting for people to mine
blocks with fee paying transactions in them without actually having the
full UTXO set; such nodes can't tell if a block is invalid due to a fake
txin, and thus will happily extend a invalid chain. This possession
proof can probably be make part of a UTXO commitment.
> If I had to choose one thing to evict to make time for that, it'd be the
> whitepapers. At the moment we still have plenty of headroom in block sizes,
> even post April. It can probably be safely delayed for a while.
Lots of off-chain tx solutions are popping up which will help push back
the issue's relevance as well. Also your micropayment channels possibly.
--
'peter'[:-1]@petertodd.org
000000000000000b9656276a0fdab028ca759c3fd7f951fb20196c264b5cd1ce
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-08-16 14:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 1:00 Gavin Andresen
2013-08-16 4:06 ` Melvin Carvalho
2013-08-16 12:11 ` Mike Hearn
2013-08-16 12:24 ` Mike Hearn
2013-08-16 13:41 ` Warren Togami Jr.
2013-08-16 13:46 ` Mike Hearn
2013-08-16 13:53 ` Warren Togami Jr.
2013-08-16 14:06 ` Peter Todd
2013-08-16 14:56 ` Gregory Maxwell
2013-08-16 14:01 ` Peter Todd [this message]
2013-08-16 14:15 ` Peter Todd
2013-08-16 14:27 ` Warren Togami Jr.
2013-08-16 14:36 ` Mike Hearn
2013-08-16 14:59 ` Peter Todd
2013-08-16 15:06 ` Warren Togami Jr.
2013-08-16 15:11 ` Mike Hearn
2013-08-16 15:13 ` Mike Hearn
2013-08-16 15:59 ` Peter Todd
2013-08-17 0:08 ` Warren Togami Jr.
2013-08-17 12:35 ` Mike Hearn
2013-08-17 13:41 ` Jeff Garzik
2013-08-19 3:09 ` John Dillon
2013-08-19 3:17 ` Peter Todd
2013-08-19 5:00 ` John Dillon
2013-08-19 5:34 ` John Dillon
2013-08-19 5:11 ` Mark Friedenbach
2013-08-19 9:16 ` Mike Hearn
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=20130816140116.GB16201@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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