< 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>
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 0.12.0.1 :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
< GitHub54>
[bitcoin] morcos opened pull request #7556: Some cleanup work for mempool and policy estimator (master...cleanupMempool) https://github.com/bitcoin/bitcoin/pull/7556
< 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>
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>
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..."