< vasild>
sipa: wumpus: wrt sending sendaddrv2 and the difference between the code and the BIP, I opened https://github.com/bitcoin/bips/pull/1043 to change the BIP.
2020-12-05
< pinheadmz>
re: coordination though - BIPs are good places to pick service bits, etc at the community level - thats not really "bitcoin core deciding:
< pinheadmz>
i see yeah reading up the chatter on bip155 PR as well...
< wumpus>
... even less interest and we might as well puglish BIPs directly into the arctic code vault
< jonasschnelli>
It might lead to more reluctant testing and lesser interest to read BIPs more carefully
< jonasschnelli>
<wumpus> my first public draft was apparently june 1, 2018, I posted it to the mailing list feb 18, 2019 (there we no replies at all), I created the PR for the BIPs repository on feb 27, 2019, it was merged jul 23, 2019. Vasild picked up the implementation april this year, and quite quickly had a working implementation (though some other detailed were still ironed out). [...]
< wumpus>
but it's too frustrating for me personally and I don't think I'll be working on BIPs again
< wumpus>
my first public draft was apparently june 1, 2018, I posted it to the mailing list feb 18, 2019 (there we no replies at all), I created the PR for the BIPs repository on feb 27, 2019, it was merged jul 23, 2019. Vasild picked up the implementation april this year, and quite quickly had a working implementation (though some other detailed were still ironed out). It was discussed in
2020-12-03
< luke-jr>
until we switch to BIP324
< luke-jr>
(we can just add new features only within the context of BIP324)
< luke-jr>
as long as we ensure they can't continue their silliness into BIP324, at least it has an end date?
< jonasschnelli>
BIP324 is probably different since we want to get disconnected when the handshake is not supported
< jonasschnelli>
Its not even messages in BIP324,.. its the handshake that is headerless
< * sipa>
points at BIP324
< luke-jr>
IANA and BIPs aren't that different
< luke-jr>
sdaftuar: we also have no authority to impose BIP155 on them anyway
< sdaftuar>
i am not sure an updated version of bip155 was ever sent to the mailing list describing that the version bump was being dropped. so it's hard to blame them, imo, other than for a long-running misunderstanding of how we think unknown messaegs should be treated
< sdaftuar>
what's the status of sendaddrv2/bip155, there was a report that it caused other peers to disconnect us i think?
2020-12-01
< jnewbery>
vasild: your suggested change to BIP155 isn't what Bitcoin Core is doing. It sends the message after receiving a version message
< vasild>
maybe bip155 should be corrected: "sendaddrv2 SHOULD be sent after receiving the verack message" s/receiving/sending/
< sipa>
i'm happy we got bip154 in 0.21, but this isn't the time to change it anymore...
< jonatack>
michaelfolkson: when reviewing, sometimes running them for less than a minute finds things, e.g. was the case for the BIP324 implementation
< S3RK>
question about fuzzing. we use regtest chain params, but in corups for src/test/fuzz/descriptor_parse.cpp I see xprv keys. As a result fuzzing don't cover code paths with valid keys for bip32 decriptors. I tried to add initial seeds with tprv, but fuzzer doesn't detect any new edges covered. What do I miss?
2020-11-03
< jonasschnelli>
I haven't seen BIP324 discussion about the missing backward secrecy of the current rekeying approach.
< sipa>
as long as we don't worry about secrecy in the other direction (which the current bip324 writeup doesn't, afaik), i think this is very much preferable
< jonasschnelli>
I wanted to ask about BIP324's rekeying
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< S3RK>
question about fuzzing. we use regtest chain params, but in corups for src/test/fuzz/descriptor_parse.cpp I see xprv keys. As a result fuzzing don't cover code paths with valid keys for bip32 decriptors. I tried to add initial seeds with tprv, but fuzzer doesn't detect any new edges covered. What do I miss?
< sipa>
bip322 proves the ability to spend coins sent to a particular bitcoin address; a lightning equivalent sounds like it would need a lightning-specific solution
2020-10-19
< bitcoin-git>
[bitcoin] sipa opened pull request #20189: Switch to BIP341's suggested scheme for outputs without script (master...202010_taproot_std_noscript) https://github.com/bitcoin/bitcoin/pull/20189
< sipa>
there is one context where we actually treat someone with a private key as an attacker in BIP340, and it's a rather unusual requirement: nobody (even those with private keys) should be able to construct a signature for which the single-sig validation and batch-validation algorithm produce a different result (with more than negligible probability)
< phantomcircuit>
sipa, yeah i understand now, i was confused by the bip340 language about malleability
< sipa>
phantomcircuit: to be clear, the bip340 signing algorithm is deterministic if no auxiliary randomness is used
< bitcoin-git>
bitcoin/master 79f3d9b Pieter Wuille: Mention BIP155 in doc/bips.md
2020-10-11
< ja>
luke-jr: when would an ack be necessary for marking 'obsolete'? i thought it would be analogous to 'final' which you seem to wait for an explicit ack for here: https://github.com/bitcoin/bips/pull/926
< bitcoin-git>
[bitcoin] fanquake merged pull request #19954: Complete the BIP155 implementation and upgrade to TORv3 (master...torv3) https://github.com/bitcoin/bitcoin/pull/19954
2020-10-10
< ariard>
vasild: I'm still not understanding how a BIP155 node is supposed to discover the list of network IDs supported by its BIP155-peers ?
2020-10-09
< sipa>
(and the usage in bip152 is restricted to 16-bit numbers, which obviously won't have any problems)
2020-10-08
< sipa>
i guess we overlooked that in bip152, where it's also not used as a size, but restricted to pretty small numbers
< sipa>
it is as BIP42 predicted
< jonatack>
to summarize, if I may: before feature freeze in one week, please review 19953 (BIPs 340-342), 19954 (tor v3), 19988 (tx relay logic), and 19077 (sqlite wallet)
2020-10-03
< bitcoin-git>
[bitcoin] robot-dreams opened pull request #20074: test: p2p_blockfilters tests for BIP157 config args (master...bip157-blockfilters-tests) https://github.com/bitcoin/bitcoin/pull/20074
< wumpus>
the higher level question would be 'should AddrMan be entirely disabled in some cases', we had some related discussion wrt. that for BIP155 for making it possible for nodes to signal that they don't take part in address gossip
< sipa>
wumpus: also, ack bip155 changes, as those need to be stable before 0.21 if we want it :)
< vasild>
I agree it is out of scope, but I also think "I participate in gossip" is out of scope for bip155, if we consider that its purpose is to support larger than 16 byte addresses
< wumpus>
things like that were proposed before, though never in the for of a BIP afaik, but I think that's out of scope of BIP155
< vasild>
Wrt the next bip155/torv3 PR, assuming #19845 gets merged - #19031 has two more commits "net: CAddress & CAddrMan: (un)serialize as ADDRv2" (+193/-15) and "net: advertise support for ADDRv2 via new message" (+129/-8). Then we will have done BIP155 - will gossip torv3/i2p/cjdns addresses if we receive them (even though we may not be able to make use of them yet). After that we need one more change
< sipa>
i wonder how much of a bandwidth savings BIP155 will be
< wumpus>
phantomcircuit: that's not relevant here, we don't do DNS lookups for bitcoin nodes, and in any case, how a DNS returns is separate from how they're gossiped (which is all that BIP155 is about)
< sipa>
BIP155 makes it sound like (a), at least for TORv2
< sipa>
vasild: the way i see it, the P2P is just lagging behind a bit due to no BIP155, but we can easily circumvent that now ;)
< sipa>
BIP155 supports up to 512 bytes addresses, but clients will ignore unknown networks/lengths
2020-09-09
< ariard>
jonasschnelli: just replied on bip324, AFAICT real-or-random and I favor MACing the length a la noise, even if as Lloyd is pointing we don't a concrete exploitation of it
2020-09-08
< yanmaani>
I know, but is there any research being done? Like on BIPs or stuff? I know about utreexo
< sipa>
though they were an essential part of BIP37
< sipa>
aj: i have a branch where it's half done, but i got preempted by bip340/taproot stuff
< jonatack>
quick reminder to review the bip155 and bip324 implementation PRs
< gmaxwell>
https://github.com/bitcoin-core/secp256k1/pull/558 looks ready-ish to merge, so if anyone wanted to review ack this updated version that reflects the latest BIP340 changes (even R), it's time!
< sipa>
kallewoof: fwiw, the powLimit in the signet PR doesn't exactly match the difficulty as specified in BIP325 (the digits after 00002adc28 should be zeroes)
2020-08-27
< sipa>
right, this is not about computing our onion address, but to convert between the bip155 encoding and onion addresses
< jonatack>
I think BIP155 addrv2 is a priority, according to vasild the next steps should be smaller and easier
< ariard>
sipa: what was llfourn main proposal of change for bip324? He didn't propose to MAC the length field, so no BIP change
< jonatack>
BIP324 v2 p2p encrypted message transport protocol: right after the last p2p meeting, jonasschnelli rebased and updated #18242 (changes only used in tests for now) and I've begun re-reviewing it along with the BIP, which has some open questions.
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< jonatack>
BIP325 signet: #18267 has been through a few more rounds of review and seems to be getting close, with recent review by fjahr, pinheadz, MarcoFalke, instagibbs, and myself
< jonatack>
BIP155 addrv2: #19628 has been receiving review from sipa, elichai, ryanofsky, kallewoof, sipsorceryand myself, and now has 4 ACKs; vasild is deferring further (minor) changes to the PR in order to preserve existing review, but there's no reason to not review it
< jonatack>
My prios were BIP155, BIP324, and BIP325 implementation PRs, and they seem to be moving forward.
< vasild>
jonatack: troygiorshev: yes, the BIP155 sendaddrv2 can come any time, but we try to do it early so that when the peer is about to advertise his own address to us, he has the option to send us addrv2 - would be important if his address is torv3 because he wouldn't be able to advertise it to us with addr(v1)
< ariard>
sdaftuar: I think that's good it was unclear between matt and I on bip339 implemn in rust-bitcoin about why 339 bumps both protocol version and wtxid-relay
< jonatack>
vasild: i think it's fine to define one's own list of important PRs to review. e.g. longer term for me would be: BIP155/addrv2, BIP324, BIPs340-342, BIP325
< dongcarl>
jonatack: do you have link to bip324 discussion?
< jonatack>
i was then asked by a few devs to consider picking up bip324 implementation
2020-08-06
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
2020-08-03
< sipa>
warren: BIP324 will replace BIP151
< warren>
jonasschnelli: hey. Curious whatever happened to BIP150 and 151. Did that end up getting rolled into a replacement BIP?
2020-07-31
< bitcoin-git>
bitcoin/master d362f19 Pieter Wuille: doc: list support for BIP 339 in doc/bips.md
2020-07-29
< sipa>
the only exceptions are (1) segwit, which introduced a p2p change along with a consensus change and (2) bip133 feefilter
2020-07-27
< vasild>
but I gather "varint" in BIPs may be used to denote what the source code calls compactsize
< vasild>
both varint and compactsize are mentioned in some BIPs
< vasild>
jonasschnelli: luke-jr: sipa: wumpus: what do you think, (s/VARINT/CompactSize/ in BIP155)?
< vasild>
Anyway, given that compact size is used in p2p and not varint, I suggest that we change the spec to say "compactsize" instead of "varint" with some clarification like "For the purposes of this section, CompactSize refers to the variable-length integer encoding used acros..." (from bip152) and also change the code to use compactsize instead of varint (the code is in
< vasild>
and "compactsize" is mentioned in 6 BIPs
< vasild>
s/8 occurrences/mentioned in 8 BIPs/
< sipa>
for BIP152 there was initially an intention to use varint, but it was changed to compactsize to simplify specification
< vasild>
Or, well, if in other specs the word "VARINT" is used to mean "compactsize", then should the BIP155 C++ source code use compactsize?
< vasild>
BIP155 says:
< vasild>
Ok, so neither one of varint or compactsize is defined in BIPs, but compact size is already used in other places in the p2p protocol whereas varint is not.
< sipa>
vasild: not in any BIPs afaik; things that existed in the protocol before the BIPs process existed as generally just taken as gospel
< achow101>
2020-06-19.log:16:10 < bsm117532> #proposedwalletmeetingtopic descriptor specification for watch-only wallets, and repeated payments without address use via BIP32 paths
< sipa>
descriptor checksums have a range of 2^40, so somewhat better than bip32 fingerprints (which are only 2^32)
< shesek>
would it make sense to invent one? this could also use a `/` separator like bip32 key origins, though a different character might be better because this doesn't have multiple levels of nesting like key origins
< sipa>
(i kind of think that using fingerprints for bip32 was a bad idea too... they're too small to guarantee no collisions)
< shesek>
is there a customary notation for referring to the nth script of a descriptor identified by its checksum, akin to <bip32-fingerprint>/<index>?
2020-06-19
< bsm117532>
#proposedwalletmeetingtopic descriptor specification for watch-only wallets, and repeated payments without address use via BIP32 paths
2020-06-16
< wumpus>
but all new repositories are created under bitcoin-core, at some point, if enough things split off from the main codebase, at some point maybe only the consensus code (and bips) will be left under bitcoin
2020-06-12
< jamesob>
This issue of the message handling thread being potentially blocked by indexing (BIP157/158) that jnewbery raised is disconcerting, and separating out the indexing stuff seems more or less in line with the spirit of the process separation work.
< shesek>
is there a customary notation for referring to the nth script of a descriptor identified by its checksum? something like <checksum>/<index>, akin to <bip32-fingerprint>/<index>?
< real_or_random>
we (the BIPauthors) feel it's in a good state, I think otherwise sipa wouldn't bring this up
< elichai2>
I think the big "political" question in terms of merging is if anyone believes that BIP340 doesn't have a good chance of landing in bitcoin core
< nickler>
Afaik we've addressed all comments on the BIPS on the mailing list in some form of another
< elichai2>
I'd like to review the new keypair direction but I do hope that BIP340 will actually end up in bitcoin in the end so I think it's ok to move toward merging schnorr to libsecp
< sipa>
so with the prospect of having BIP340-342 one day merged, there will need to be a time to merge BIP340 support in libsecp256k1
< MarcoFalke>
For logging, one could disable bip324
< sipa>
shower thought: are pcap files easy? if so, maybe it's useful post-BIP324 to permit dumping the decrypted stream in pcap format
< jonasschnelli>
would ne no longer fun for post BIP324 connections
< troygiorshev>
i'm personally a huge fan of BIP324 and AltNet and related, so I'
2020-06-02
< sipa>
with a million keys the bip158 filter won't help
< sipa>
phantomcircuit: i think bip158 was designed for much smaller sets of keys, yes
< achow101>
i'm gonna need to brush up on bip158 first
< phantomcircuit>
"Empirical analysis also shows that was chosen as these parameters minimize the bandwidth utilized, considering both the expected number of blocks downloaded due to false positives and the size of the filters themselves." - BIP158
< sipa>
you have to explicitly enable bip37, or whitelist the peer
< aj>
yeah, i was thinking of making it so bip35 wouldn't let you see stuff that hadn't made it into the bloom filter, but seems too complicated, esp if we think bip35 is only for trusted-ish peers
< aj>
sipa: why not do bip35 via bloom as well?
< sipa>
aj: so WDYT about relay pool 2 minutes, bloom filter per peer for last (whatever can be relayed in 2 minutes) transactions, things can be requested if they're in the bloom filter OR in mempool and older than 2 minutes OR older than the last BIP35 response; BIP35 responses don't go into the bloom filter
2020-05-29
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< sipa>
it's why we think we need an upgrade mechanism in BIP342
< jonasschnelli>
sipa: do you think it could have implications for v2/BIP342?
< jonasschnelli>
despite the – eventually – altering BIP324, I think we can finalise the implementation and hide it behind an experimental runtime parameter.
< jonasschnelli>
BIP342 is still in discussion.
< dongcarl>
jonasschnelli: I see, so after #18242, we need #14049, and then BIP324 handshake + BIP324 ECDH calc + BIP324 HKDF key deriv (last few commits from 2019/08/net_v2)?
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< jonasschnelli>
So as for BIP342, just focus on #18242
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< jonasschnelli>
15206/15197 are now BIP324 irrelevant
< dongcarl>
Hey jonasschnelli, I wanted to confirm my overall understanding of the topology of the open PRs related to BIP324. Here?s my understanding:
< dongcarl>
- #15197 + #15206 seem to be additional improvements that 1. Can be merged independently of the main line of progression, 2. Can help/simplify the implementation of BIP324. Question here: Could you give concrete examples as to how they help/simplify the implementation?
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
2020-05-28
< jnewbery>
both for BIP324 and altnet
< jonasschnelli>
its nice. but not necessary anymore for future transport protocols (like BIP324)
< willcl_ark>
sipa: thanks for your earlier reply re BIP30/34
< PaulTroon>
thanks sipa, the commentary from bip30 makes more sense now
< PaulTroon>
I was also trying to understand that BIP30 attack scenario, snot sure if I understand it.. a coinbase_1 with an unspent txout to A, and then create a duplicate coinbase_2 that has a txout to B ?
< sipa>
BIP30 thankfully has an exception that in that case doesn't prevent creation, because otherwise we'd need to keep track of every spent utxo forever
< sipa>
the problem that BIP30 was trying to solve is txout _overwriting_
< PaulTroon>
sipa: because BIP30 allows duplicate tx's if all outputs are spent?
< sipa>
BIP141 solved that
< PaulTroon>
A pre-BIP34 coinbase with matching signature for block height 1,983,702 (approx year 2048)
< sipa>
willcl_ark: BIP30 doesn't prevent duplicate txids; it only prevents one transaction that would overwrite an earlier one
< willcl_ark>
BIP30 appears to leave some room for re-orgs, but I can't tell if "spent" transactions (in different blocks) could still be allowed to have had identical txids
< willcl_ark>
Does BIP30 / BIP34 completely prevent there from existing two transactions with same txid, or are there still edge-cases where this can happen?
2020-05-15
< jonasschnelli>
would it make sense to support BIP39 mnemonics in descriptors?
2020-05-13
< jonasschnelli>
Dont get me wrong. I’m totally pro BIP157.
< jonatack>
jonasschnelli: the conceptual discussion is ongoing (at least for me) on bip157, but the changes in that PR didn't seem dangerous on their own after reviewing them, and reversible before the next release
< jonasschnelli>
Yes. I agree. Just it looks like there is no clear conceptual ACK on serving filters after BIP157 (don't get me wrong, I'm all for serving BIP157).
2020-05-12
< phantomcircuit>
sipa, for non-legacy wallets using the existing bip158 "basic" filter (which is the entire script) is definitely preferable
< sipa>
phantomcircuit: unless you really need support for raw multisig (which i think the wallet doesn't even support anymore), you could use the bip158 filter
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #15845: wallet: Fast rescan with BIP157 block filters (master...1904-walletFastRescan) https://github.com/bitcoin/bitcoin/pull/15845
< ariard>
luke-jr: right I'm not arguing bip157-vs-bip37 here, but more broadly on light-client model in case of forks
< jonatack>
question: if bip157 is opt-in, and a full node can soon export a descriptor wallet xpub, why would a full node turn on serving cfilters?
< * luke-jr>
still hasn't heard a use case for merging BIP157 at all, aside from harming Bitcoin
< sipa>
(not BIP157 specifically, just in general - if you ask too much of us and we get overloaded, deprioritize)
< ariard>
sipa: yes but we don't do this AFAIK? and if everyone start to deprioritizie servicing bip157 clients you do have an issue
< jonasschnelli>
Yes. The only difference to blocks serving (which seems to cause much more traffic) is that blocks served to bip157 are pure consumption while blocks served to full nodes should - ideally - be served to other peers.
< ariard>
kanzure: no my concern is assuming you have the bip157 light client paradigm, how do you make it scale ecosystem-wise
< jonasschnelli>
ariard: also, one can crosscheck the CDN filters against some p2p loaded bip157 filters
< jonatack>
fwiw, i'm running a bip157 node on mainnet with -peercfilters=1 -blockfilterindex=1 to test for the first time, and /blockfilter/basic is 4 GB
< ariard>
overall, bip157 is good for experimentation, while keeping awareness there is still unsolved issues on security and scalability
< sipa>
luke-jr: bip157 has other advantages over bloom filters, such as being able to connect to two nodes and comparing the filters, permitting a "1 of 2 nodes is trusted" security model
< luke-jr>
stratum > bloom > bip157
< ariard>
jonasschenlli: yes my concern isn't bip157 specific, I do think that's the best option available today
< ariard>
jonasschenelli: okay my point was really about LN clients, for which bip157 was designed, not an application which needs to download block over and over
< jonasschnelli>
if there is the concern that there are too many BIP157 clients,... one might want to limit the bandwidth
< sipa>
with BIP157 you do it once
< sipa>
BIP157 is certainly harder on clients
< ariard>
and almost all bip157 clietns, dont't have strong addr management countermeasures
< ariard>
on the security aspect, supporting bip157 in core encourage people to connect directly to random peers
< sipa>
(but that's still better than BIP37...)
< sipa>
BIP157 support is very cheap for the server
< ariard>
and having a better idea for which bip157 support was aimed, people using their mobile wallets with their full-nodes
< jonasschnelli>
I think BIP157 support in core is a conceptual no brainer. The question is maybe more, if it should be open to non-whitelisted peers (random peers).
< luke-jr>
BIP157 isn't just "not perfect", it's harmful/backward
< ariard>
what I was worry about, is by supporting bip157 in core, all people building such nice LN wallets
< wumpus>
#topic bip157 and light clients (ariard)
< ariard>
do people have a bit of time to talk about bip157 or more broadly light clients ?
< vasild>
wumpus: While looking at the addrv2/BIP155 wip PR #16748 I realized that in CSubNet we support netmasks that have 0-bits followed by 1-bits, e.g. /255.255.0.255.
< jonasschnelli>
I could understand why the signraw commands could refuse to work for BIP44-ish descriptor wallets (due to the hardening violation),... though for manual privkey-ckd it should work
2020-04-08
< Talkless>
jonasschnelli: alternative is just to wait until Bitcoin Qt has BIP39 support and easy HW wallet support, so I could just switch to Bitcoin Qt :)
2020-04-06
< bitcoin-git>
[bitcoin] theStack opened pull request #18544: net: limit BIP37 filter lifespan (active between 'filterload'..'filterclear') (master...20200406-net-limit_bip37_filter_lifetime) https://github.com/bitcoin/bitcoin/pull/18544
2020-04-05
< bitcoin-git>
bitcoin/master cf21293 MarcoFalke: Merge #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py (master...20200403-test-check-for-CVE20135700-vuln-in-bip37-tests) https://github.com/bitcoin/bitcoin/pull/18515
< bitcoin-git>
bitcoin/master 0ed2d8e Sebastian Falbesoner: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py