< tErik_mc>
wumpus, viewed your response on that ms script can be used for sending email alerts, THANKS.
< tErik_mc>
i think that should be easier solution, so i will try that 1st, and if time permit in future then use gpg encrypted emails.
< phantomcircuit>
gmaxwell, incase anybody asks the sybil attack coming from aws appears to just be holding connection slots open
< gmaxwell>
phantomcircuit: could be listening to invs.
< phantomcircuit>
gmaxwell, probably
< phantomcircuit>
maybe a response to the improved trickle logic
< sipa>
how do you mean?
< phantomcircuit>
sipa, the more connections to each node the more likely an attacker is to observe a first relay
< gmaxwell>
making multiple connections effectively divides the possion delay by N, since they're independant.
< Squidicuz>
is banning the offending ip's effective?
< gmaxwell>
Squidicuz: effective at what?
< Squidicuz>
whatever they are trying to do..? *shrug* I had some many connections :s
< gmaxwell>
sipa: when we first added the delay I contemplated suggesting that there be a single short shared delay for all peers. plus the non-shared independant part... but figured such a thing could be added later.
< gmaxwell>
Squidicuz: we don't know what they're trying to do; if you're trying to just DOS attack, it's already ineffective assuming you're running >0.11.
< Squidicuz>
ah. okay
< sipa>
gmaxwell: for incoming connections we could multiply by (a function of) the incoming connection count
< gmaxwell>
just doing that keeps the average the same but doesn't change the best case benefit.
< sipa>
gmaxwell: it can be a sublinear functiom
< sipa>
but yes, i see what you mean
< gmaxwell>
having a shared time t=possion(9), and then all inbound nextimes are set to t+possion(1), would have good properties I think.
< GitHub118>
[bitcoin] gmaxwell opened pull request #8080: Do not use mempool for GETDATA for tx accepted after the last mempool req. (master...nonmempool_getdata) https://github.com/bitcoin/bitcoin/pull/8080
< phantomcircuit>
gmaxwell, how about "remove mempool"
< phantomcircuit>
:/
< phantomcircuit>
(command)
< phantomcircuit>
opinions on replacing the "reindex?" with something just just forces a reindex?
< sipa>
?
< phantomcircuit>
there's a bunch of places where we detect corruption and then present the user with the option of reindexing
< phantomcircuit>
this seems kind of silly since there's unlikely to be any other option
< sipa>
the gui does that
< wumpus>
in the GUI tha tmakes sense
< wumpus>
in the command line I'd prefer to leave decisions like that to the operator (which is supposed to be more clueful)
< wumpus>
removing the '?' in the case of the daemon makes sense though - it makes no sense to word it like a question
< wumpus>
(but it's a bit annoying to do so without introducing an explicit gui/non-gui dependency, which is why no one bothered to do so)
< gmaxwell>
For example, I've multiple times just changed my txindex flag instead of reindexing.
< wumpus>
sam here 'oh, another value of txindex was expected'
< gmaxwell>
also, "oh this one is broken, I'll use another datadir" rather than "now lets spend hours reindexing". ... I also usually will increase my dbcache before reindexing. All that said I agree with the principle that we shouldn't just be telling random endusers to reindex.
< gmaxwell>
(for one, it builds bad habbits like randomly reindexing whenever something isn't working)
< GitHub68>
[bitcoin] gmaxwell opened pull request #8082: Defer inserting into maprelay until just before relaying. (master...just_in_time_maprelay) https://github.com/bitcoin/bitcoin/pull/8082
< GitHub98>
[bitcoin] jonasschnelli opened pull request #8083: Add support for dnsseeds with option to filter by servicebits (master...2016/05/dnsfilter) https://github.com/bitcoin/bitcoin/pull/8083