< morcos>
has anybody really looked into the recent attack closely?
< morcos>
one thing i find curious is when i start up a new node, it fills up pretty quickly
< morcos>
at a much faster rate than an old node's mempool is growing, so that implies old txs are still showing up
< morcos>
the question is, is that because somebody is rebroadcasting them over and over and if so, how come they are propogating? people keep starting up fresh nodes with empty mempools?
< morcos>
or is this behavior just a "natural" feedback cycle of the network
< morcos>
would it go away when the recentRejects code is widespread?
< morcos>
do we need to reconsider how wallet rebroadcast works?
< morcos>
hmm.. maybe the recentRejcts code isn't going to help that much since it resets
< morcos>
BlueMatt: sipa: sdaftuar: this seems like it could be a problem with limited mempools if there is some way to induce this kind of behavior
< morcos>
where you are relayed many many times.
< morcos>
some of these txs seem to have been requested by my nodes half a dozen times or more
< morcos>
maybe its particularly bad b/c of peer churn now too?
< petertodd>
morcos: the random drop strategy of XT may be helping these txs get rebroadcast
< morcos>
i think that'd be mostly true for any eviction strategy though right?
< petertodd>
morcos: no, the random drop stategy means they can be rebroadcast
< petertodd>
morcos: deterministic strategies don't let that happen in the same way
< morcos>
sort of, you could evict it but then later accept it (and relay it again)
< petertodd>
morcos: exactly
< morcos>
even with 6722 i'm saying
< morcos>
you wouldn't immediately accept it again
< petertodd>
morcos: less of an issue there though, as minfee will rise accordingly
< petertodd>
morcos: random drop allows that to happen wholesale
< Luke-Jr>
oh.
< Luke-Jr>
are we rebroadcasting received wtx still? could spammers target real users to get the amplification?
< morcos>
yeah i guess you might be right that its a lot better
< morcos>
Luke-Jr: ooo, hadn't thought about that.. htats terrible
< morcos>
dont' think thats happening here, since the txs tend to be 100 inputs -> 1 output
< morcos>
and so no room to target somebody else
< petertodd>
Luke-Jr: wouldn't be an issue w/ deterministic dropping mind you
< Luke-Jr>
a possible risk tho
< Luke-Jr>
petertodd: it's an issue as long as you rebroadcast your own crap
< petertodd>
Luke-Jr: it's a privacy issue, but much less of a network-wide DoS one
< Luke-Jr>
petertodd: get enough nodes doing it..
< petertodd>
Luke-Jr: not very likely; too few btc core wallets out there (sadly!)
< Luke-Jr>
:|
< morcos>
i agree with Luke-Jr, seems like its worth thinking about more. increase min fee helps a lot, but once there is enough diversity in the network
< morcos>
it may be able to keep bouncing around
< morcos>
ha! too few core wallets saves the day
< petertodd>
morcos: well, clever attackers would have some anyone-can-spend outputs and do it that way...
< petertodd>
morcos: which incidentally, I have seen before
< petertodd>
bbl
< Luke-Jr>
petertodd: anyone-can-spend outputs are not recognised by the wallet..
< phantomcircuit>
for good reason
< Luke-Jr>
multiple good reasons :p
< midnightmagic>
w 19
< attar66>
hi
< attar66>
no body talk?
< petertodd>
Luke-Jr: there's a bunch of people automatically grabbing anyone-can-spend outputs, of all types (e.g. known privkey too)
< gmaxwell>
morcos: normally there is no rebroadcast, but over the years there have been no shortage of idiots who amplify.
< gmaxwell>
it would be useful to check to see which peers are giving you these transactions (turn up debugging)
< wumpus>
morcos: sure, mintxfee could be reduced again in e.g. a later 0.10.x/0.11.x version, if 0.12 is released and mempool limiting works - if those versions still matter by that time
< paveljanik>
wumpus, 0.10 doesn't contain 649f5d9c1100bb3cbace724900f035939df5ea11. It was backported to 0.11 only. OK?
< wumpus>
paveljanik: it's not on 0.10
< bitcoin-wiki>
Hi all
< bitcoin-wiki>
I have a question
< bitcoin-wiki>
can anyone help me?
< CodeShark_>
if it pertains to the channel's topic, don't ask whether you can ask - just ask. if it doesn't pertain to the channel's topic, don't ask anything at all
< Luke-Jr>
am I correct that quantum computers shouldn't break HD wallets particularly? ie, knowledge of old pubkeys/privkeys won't expose the other pubkeys for the HD wallet (unless the watch seed is shared)?
< paveljanik>
wumpus, but 0.10 has the same issue...
< CodeShark>
Luke-Jr: quantum computers will break ECDSA
< Luke-Jr>
where is the code that re-requests blocks from another peer, if the one we already requested it from has disconnected?
< CodeShark>
how do you add a new unit_test.cpp to the build?
< CodeShark>
ah, you need to add it to src/Makefile.test.include and reconfigure
< CodeShark>
should add that to the README...
< GitHub12>
[bitcoin] CodeShark opened pull request #6798: Clarification of unit test build instructions. (master...unit_test_readme_fix) https://github.com/bitcoin/bitcoin/pull/6798
< michagogo>
18:58:21 <wumpus> my gitian build spends a lot of time in "Upgrading system...". Does making new images avoid that?
< michagogo>
wumpus: well, bringing the base image up to date does
< michagogo>
IIRC since the way the VMs are created was changed, it actually creates an image that *only* pulls from precise and not from -updates/-security, so it's ~mandatory for a usable build
< michagogo>
But I'm not sure if that was KVM too or only LXC
< michagogo>
One sec
< michagogo>
Actually, yeah, looks like it's only LXC that uses debootstrap now. KVM still uses vmbuilder, so yeah, simply recreating the base image should (I think) give you an up to date one
< michagogo>
wumpus: Oh, BTW, you mis-signed 0.10.3rc1. You signed as 0.10.3rc1-win-unsigned, should have been 0.10.3rc1-win. The Windows detached signature process wasn't backported to 0.10.
< michagogo>
(also, I hope you made sure to keep the OS X unsigned bundle for 0.10.3rc1 and 0.11.1rc1 separate... I almost blew away the 0.11.1rc1 version, but fortunately I realized in time)