< phantomcircuit> morcos, im a bit confused by your feefilter patch, it seems to be vastly more complex than necessary
< phantomcircuit> why not simply call CTxMemPool::GetMinFee ?
< gmaxwell> phantomcircuit: read the mailing list post. He's trying to prevent connection correlation. But I'm not sure that it's effective in any case-- consider, one can actively prove for the minfee by sending transactions and seeing if they end up mempooled.
< phantomcircuit> gmaxwell, yeah i dont see the point there, it's trivial to probe a remote peers mempool
< gmaxwell> at the moment.
< gmaxwell> though we should fix that.
< phantomcircuit> gmaxwell, uh, how?
< gmaxwell> Sufficiently advanced magic.
< phantomcircuit> it seems a fundamentally difficult thing to do
< phantomcircuit> gmaxwell, http://pastebin.com/raw/X9Q1LM2C
< phantomcircuit> that's an amusingly sophisticated understanding of fees actually
< gmaxwell> phantomcircuit: the obvious way to do is is to run seperate logical mempools.
< phantomcircuit> gmaxwell, what like one for each peer and then do de-duplication of the actual data?
< gmaxwell> phantomcircuit: or the same but pivoting the table structure. e.g. for each mempool transaction keep track of which peers it's in mempool for.
< gmaxwell> (this could be much more efficient than the current maps used for known txn)
< midnightmagic> application-aware blinding proxies go away then i think..?
< phantomcircuit> gmaxwell, i guess it would be enough to just keep track of which transactions a peer has sent you and then request any transaction a peer sends that isn't duplicate
< gmaxwell> phantomcircuit: yes but not efficient.
< phantomcircuit> gmaxwell, rolling bloom filter would work for that where entries are only added to the filter when accepted to the mempool
< phantomcircuit> not perfect but certainly better than what we have today
< phantomcircuit> either way i dont actually see why we would care that our peers know our exact minimum mempool feerate requirement
< gmaxwell> phantomcircuit: the reason, afaik, is to just reduce correlation. Where you can tell that a given v4 and hs node is the same node. Given that there are so many other ways to correlate right now it may be pointless.
< phantomcircuit> gmaxwell, i certainly would not run a node accessible from anything other than tor as a hidden service and think that correlation wasn't possible if not likely
< phantomcircuit> and i actually think it would be extremely dangerous to tell anybody otherwise no matter how much effort is put into removing possible correlations
< phantomcircuit> s/dangerous/irresponsible/
< morcos> phantomcircuit: are you just talking about the FilterRounder code that is "vastly more complex"?
< morcos> I agree that the obfuscation has limited value, but when I actually implemented it, I was surprised by how neatly packaged away it was. I don't see what other parts of the implmentation are unnecessary.
< morcos> Without the FilterRounder code, it is completely trivial to correlate nodes, so it seemed worthwhile to avoid that if it could be done easily, and in the end I kind of like the quantization, it saves broadcasting unnecessary feefilter messages quite often.
< phantomcircuit> morcos, well for example, why did you have to change AcceptToMemoryPool at all?
< morcos> phantomcircuit: thats for responding for a feefilter message. how are you supposed to know whether the tx you are about to send an inv for falls below the fee filter your peer sent you?
< morcos> you have to know the feerate of the inv's you are about to relay
< phantomcircuit> morcos, hmm for dependency tracking i see
< morcos> dependency?
< morcos> no these are all just individual fee rates
< phantomcircuit> hmm ok i can see why you did it this way
< phantomcircuit> it's structurally ugly but not because of anything you did
< morcos> yeah calculating a fee for a tx requires work, and that work is already being done in ATMP which is almost always called right before RelayTransaction
< phantomcircuit> there should probably be something like CTransaction that knows about the outputs it's inputs are trying to spend
< phantomcircuit> but well.. effort
< phantomcircuit> gmaxwell, there doesn't seem to be any sane way to set the vfReachable flags
< gmaxwell> set it if you're bound on it (and in the case of tor, have a onion/proxy set); it shouldn't be harmful to be reachable when not.
< phantomcircuit> gmaxwell, for the most common setup that doesn't work at all though, ipv4 w/o ipv6 behind nat
< phantomcircuit> it seems like we'd do better to only use the IsLimited flags
< GitHub102> [bitcoin] pstratem opened pull request #7553: Remove vfReachable and modify IsReachable to only use vfLimited. (master...2016-02-17-reachable) https://github.com/bitcoin/bitcoin/pull/7553
< sipa> Reachable used to take into account whether you were bound to a publicly routable address
< phantomcircuit> sipa, it still does, but that's essentially meaningless for peers behind NAT
< sipa> it's also harmless for thrm
< sipa> (they don't get a publicly routable address)
< phantomcircuit> sipa, it's not harmless IsReachable is used to decide whether addresses received are added to addrman
< phantomcircuit> if you're running with dnsseed=0 you'll end up only connected to the hard coded dns seeds... ever
< phantomcircuit> er hard coded seeds
< wumpus> going to tag -final today - anyone that still has plans to update the release notes, please let me know asap
< * btcdrak> orders champaign
< wumpus> * [new tag] v0.12.0 -> v0.12.0
< * btcdrak> highfives wumpus
< wumpus> party!
< brg444> cheers, good work guys
< JackH> this is it? 0.12 today?
< btcdrak> fire up your gitian builders...
< JackH> \o/
< GitHub107> [bitcoin] laanwj closed pull request #7429: 0.12 release notes: Sort by importance to usability (0.12...0.12-sort-release-notes) https://github.com/bitcoin/bitcoin/pull/7429
< randy-waterhouse> wd
< * jonasschnelli> is back from holidays and is gitian building v0.12.0 now..
< btcdrak> jonasschnelli: wb
< wumpus> welcome back jonasschnelli! hope you had a good holiday
< wumpus> re: gitian building, make sure you wipe your cache if you built 0.12.x before, there has been at least one toolchain change in ubuntu trusty which isn't detected automatically
< jonasschnelli> wumpus: Thanks! Will clear the 0.12 caches and rebuild.
< instagibbs> wumpus, is there still time to fix release notes :X
< wumpus> well it doesn't make sense to change them on the branch anymore
< instagibbs> ok, well the description of pruned wallet mode disabling importaddress, privkey are wrong, which might confuse some
< wumpus> e.g. after this, the release notes on the 0.12 branch will be cleared for 0.12.1
< wumpus> it's a bit annoying, what we can do is copy the release notes to the master branch under doc/release-notes/0.12.0.md and do post-humous fixes there
< wumpus> (that should be done in any case)
< sipa> it would be a bit silly to do a 0.12.1 with as release notes "Improve release notes for 0.12.0"
< JackH> make it :D
< instagibbs> errata for release notes in master maybe
< wumpus> or just copy the release notes to a gist and fix them there. I don't know which set of release notes people will actually read, if it's the ones I copy in the release announcement then it could come from anywhere :p
< instagibbs> usually it's me googling "0.11 release notes" whatever shows up first :D
< GitHub159> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/0e3ccbfb26b11ea3d9ed7dfd39886d69097286e1
< GitHub159> bitcoin/master 0e3ccbf Wladimir J. van der Laan: doc: Add historical release notes for 0.10.4 0.11.2 and 0.12.0
< wumpus> now you can edit them in master
< GitHub21> [bitcoin] vlamer opened pull request #7555: Merge pull request (master...master) https://github.com/bitcoin/bitcoin/pull/7555
< GitHub125> [bitcoin] laanwj closed pull request #7555: Merge pull request (master...master) https://github.com/bitcoin/bitcoin/pull/7555
< GitHub54> [bitcoin] morcos opened pull request #7556: Some cleanup work for mempool and policy estimator (master...cleanupMempool) https://github.com/bitcoin/bitcoin/pull/7556
< GitHub51> [bitcoin] morcos opened pull request #7557: Encapsulate options for mempool policy (master...policyOptions) https://github.com/bitcoin/bitcoin/pull/7557
< michagogo> Gitian's churning right now, building the second set of Linux tests atm
< wumpus> #meetingstart
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Feb 18 19:04:07 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< wumpus> topics?
< btcdrak> suggested topic #7187 since it relates to the recent merge og 7184
< paveljanik> release status? :-)
< wumpus> from previous meeting: ACTION: review/test/merge #7148 and #6564 (wumpus, 19:19:10)
< morcos> i'm happy to discuss fee filter if anyone wants
< btcdrak> wumpus typo it was #7184. which has been merged. #6564 became #7524 which has been merged too
< btcdrak> paveljanik: just waiting on gitian signers
< wumpus> yes, mempool only BIP-112 and BIP-68 were merged
< wumpus> paveljanik: it has been tagged
< btcdrak> wumpus: so 7187 is an optimisation patch that builds on 7184
< wumpus> I haven't really looked at the fee filter, maybe better to make that an action point and discuss it next week
< btcdrak> "Keep reorgs fast for SequenceLocks checks #7187"
< michagogo> My linux build's done, Windows being prepped now
< wumpus> #action reviw 'Implement "feefilter" P2P message' #7542
< morcos> wumpus: sure.
< michagogo> Oh, sorry! Didn't realize meeting was going on
< morcos> is the topic 7187 now?
< wumpus> we dont' have a topic yet :)
< * btcdrak> makes wumpus a coffee
< wumpus> #topic Keep reorgs fast for SequenceLocks checks 7187
< morcos> The idea behind 7187 is that checking sequence locks to determine whether the tx is valid requires looking up the heights of all its inputs. In a reorg, as it stands now, this will require reevaluating the inputs of every single tx in the mempool
< morcos> That is obviously painful
< wumpus> yes, that sounds expensive
< morcos> 7187 attempts to cache for each tx the block hash of the latest block containing an input which had a sequence lock
< morcos> In the event of a reorg, if that hash is still on the chain, you know the previously calculated height and time (also cached) are still valid.
< morcos> thus ideally you won't have to look up most txs
< wumpus> sounds sensible
< morcos> so i think we should backport that to at least 0.12
< btcdrak> morcos: without a doubt.
< wumpus> yes
< morcos> it's not clear to me whether its worth the effort for 0.11, which already is way slower
< morcos> it'll still be functionally correct without it
< morcos> just reorgs will be slow
< wumpus> probably not - better to keep the patch for 0.11 as small and simple as possible
< wumpus> it will get less testing after all
< morcos> so now we need to review/test 7187 and get it merged?
< wumpus> and with all the changes to the mempool in 0.12 it will probably be non-trivial to backport that optimization
< morcos> wumpus: thats what i'd be afraid of
< wumpus> which increses the risk further
< wumpus> #action review/test #7187 Keep reorgs fast for SequenceLocks checks
< btcdrak> morcos was telling me the bip68-sequence.py RPC tests should test regression
< wumpus> I've already added the needs backport tag
< morcos> ha ha, thats more assertiveness than i intended
< btcdrak> morcos: maybe add a specific test for regression?
< morcos> there are some reorgs in the bip68 test, but i haven't looked at exactly what they do recently
< sdaftuar> i think there's a test that at least is theoretically checking that sequence locked transactions are correctly removed during a reorg
< morcos> great, well quick meeting today?
< wumpus> I think so
< btcdrak> no more topics?
< btcdrak> I have one
< morcos> congrats on getting 0.12 tagged wumpus. you should take a long weekend!
< wumpus> don't think there's much to discuss, no snags yet with the mempool BIP68/112 merges
< btcdrak> yeah went well. I'm working on a patch for the softforks btw.
< shea256> yes great work!
< wumpus> morcos: thanks :)
< wumpus> congrats to everyone on 0.12
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Feb 18 19:20:36 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< btcdrak> wumpus: Would it be possible for us to arrange open source licenses of the Jetbrains IDEs for C++ and Python? They offer free licenses to projects like this
< btcdrak> wumpus: just needs a maintainer to apply basically https://www.jetbrains.com/buy/opensource/?product=clion
< btcdrak> their IDEs are CLion and PyCharm, they are incredibly good.
< wumpus> btcdrak: yes I think so, if anyone is interested in that I can do that
< btcdrak> wumpus: please do!
< btcdrak> wumpus: link to the form https://www.jetbrains.com/shop/eform/opensource (add CLion & PyCharm)
< btcdrak> If anyone wants to review the 0.12 blog post, most welcome https://github.com/bitcoin-core/bitcoincore.org/pull/116
< sipa> oh, i forgot about the meeting!
< btcdrak> oh sipa, shea256 has some questions about libsecp256k1
< shea256> yes, can I grab you for a minute
< sipa> sure!
< shea256> cool, I'll message you
< sipa> wumpus: congrats indeed!
< morcos> btcdrak: What is Improved Rules for Transaction Relaying referring to in the blog post?
< btcdrak> morcos: speak to shea256 (he's @ryan on Slack)
< sipa> master does not compile?
< sipa> util.cpp: In function ‘std::string CopyrightHolders(const string&)’:
< sipa> util.cpp:841:53: error: ‘COPYRIGHT_HOLDERS’ was not declared in this scope
< helo> sipa: did you clean? some toolchain changes may require it
< morcos> make clean and autogen
< sipa> ok
< btcdrak> I had to git clean -dfx
< instagibbs> sipa, you have to clean yeah
< instagibbs> had same issue
< michagogo> Okay, my sigs are up
< michagogo> Is achow101 in here by a different name?
< michagogo> midnightmagic: I don't suppose you ever figured out what was different about your system, did you?
< midnightmagic> michagogo: part of it was that windows cache problem: I build gitian a lot, locally, and I guess I managed to get into that state where cache was messing me up. Right now, I suspect the < rc5 is no longer gitian'able by anyone. All I did, personally, was alter my build script to delete the cache if the version string was >= 0.12.0
< michagogo> Well, I would think it can still be built
< michagogo> But any sigs from a certain point on will not match the ones from before that point
< midnightmagic> michagogo: in terms of OS/X, I switched back on LXC for the build process and it's working for me now. At this point, honestly, the fact that I build completely out of lock-step with what the rest of you build is to blame and changing state of the system is the main cause.
< michagogo> (i.e. if a bunch of people went back and built, they should all match afaik)
< midnightmagic> michagogo: it should be historically buildable or else people just have to take out word for it. if that's what you meant.
< midnightmagic> oh
< michagogo> But yeah, that Ubuntu change messed things up
< michagogo> midnightmagic: afaik we're not all doing the same thing
< midnightmagic> tor unfortunately has switched from ubuntu to debian for their build host, so now I have to teach my system how to run debian guests :(
< michagogo> I know I'm using LXC, I think wumpus might be using KVM
< midnightmagic> michagogo: I sure hope not. :( I hate being odd man out.
< midnightmagic> so to speak
< michagogo> Not really sure what everyone uses
< michagogo> Hm? It's more complicated than just running make-base-vm with the arguments for the right debian?
< michagogo> Interesting, looks like Tor automates things more than we do
< midnightmagic> michagogo: the vm-builder for Ubuntu can't do a debian guest. this guy has made progress doing it: https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/235562 https://code.launchpad.net/~josephbisch/vmbuilder/debian
< midnightmagic> yeah, the tor stuff also verifies tag signatures, so as part of my modifications to get it co-existing with bitcoin gitian I have to maintain a minor fork. gitian doesn't play nice with itself.
< midnightmagic> (just for tor though, the bitcoin stuff is unchanged)
< michagogo> Ah, yeah. Looking at the gitian readme, I see "The official vmbuilder only includes support for Ubuntu guests, so you need to install [Joseph Bisch's fork of vmbuilder](https://github.com/josephbisch/vmbuilder), which adds a Debian plugin."
< PRab> Minor complaint about gitian. If I wait to long to enter the sudo password after running ./bin/gbuild, it fails with "failed to run make-clean-vm..."
< michagogo> PRab: KVM or LXC?
< PRab> Um.. IDK.