12015-10-02T00:06:00 <jcorgan> ok, #6743 passes travis finally
22015-10-02T00:21:00 <phantomcircuit> I dont think we need the "Address refresh broadcast" in main.cpp now that addrKnown is a CRollingBloomFilter
32015-10-02T00:30:00 <phantomcircuit> gavinandresen, sanity check on above statement?
42015-10-02T00:38:00 <phantomcircuit> ie the filter will "forget" an addr after 5000 inserts anyways so there's no reason to clear it
52015-10-02T00:43:00 <GitHub53> [bitcoin] pstratem opened pull request #6745: Net: Remove "Address refresh broadcast" logic. (master...addr_known_reset) https://github.com/bitcoin/bitcoin/pull/6745
62015-10-02T00:52:00 <phantomcircuit> is there a reason that ARM is the fastest travis build?
72015-10-02T00:52:00 <phantomcircuit> that seems odd
82015-10-02T01:01:00 <jgarzik> builds fewer components IIRC
92015-10-02T01:08:00 <phantomcircuit> jgarzik, sanity check on #6745 ?
102015-10-02T01:13:00 <jgarzik> phantomcircuit, add a unit test to prove it :)
112015-10-02T01:16:00 <phantomcircuit> jgarzik, there's already CRollingBloomFilter tests that validate it's properties
122015-10-02T01:16:00 <phantomcircuit> so im not sure what you mean
132015-10-02T01:27:00 <gmaxwell> phantomcircuit: not clearing would significantly reduce address propagation, I think? like... if the ratio of addresses to filter size is small enough it's the same as never clearing.
142015-10-02T01:31:00 <phantomcircuit> gmaxwell, which addresses though?
152015-10-02T01:31:00 <phantomcircuit> real node count, addresses in addrman, or addresses that random peers push out to the network?
162015-10-02T01:32:00 <gmaxwell> well if real node count is low then basically learning about them depends on their being enough bogus addresses to flush out the table... seems like a dumb thing to count on!
172015-10-02T01:33:00 <jgarzik> heh, same comment on the PR
182015-10-02T01:35:00 <phantomcircuit> oh right
192015-10-02T01:35:00 <phantomcircuit> i forgot that PushAddress is what checks addrKnown
202015-10-02T01:35:00 <gmaxwell> :)
212015-10-02T01:36:00 <phantomcircuit> i believe that even with a very low real node/filter size ratio the node would still effectively broadcast it's own address
222015-10-02T01:37:00 <phantomcircuit> for all outbound connections we broadcast our own address
232015-10-02T01:37:00 <phantomcircuit> gmaxwell, hehe also AdvertizeLocal -> AdvertiseLocal
242015-10-02T01:39:00 <phantomcircuit> gmaxwell, the logic in AdvertizeLocal is slightly different from the logic in the "version" message handler, is there a reason for that?
252015-10-02T01:40:00 <phantomcircuit> oh and the logic in the "version" handler ignores fDiscover
262015-10-02T01:44:00 <PRab> https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-downloader/prab-key.pgp has expired, but I have created and rolled over to a new key. What is the "proper" way to update this?
272015-10-02T01:54:00 <phantomcircuit> hmm except IsInitialBlockDownload() is going to be true fairly often
282015-10-02T02:00:00 <phantomcircuit> gmaxwell, im thinking that the IsInitialBlockDownload check shouldnt gate AdvertiseLocal in the "version" handler
292015-10-02T02:01:00 <phantomcircuit> (i bet that's mostly the reason why people who up in #bitcoin and ask why they have no inbound connections)
302015-10-02T02:47:00 <CodeShark> I would perhaps like to merge code that just moves the IsSuperMajority checks into a separate unit before going full force on version bits. This change would not affect any behavior and only touches main.cpp in very few places. Any objections to this approach?
312015-10-02T02:50:00 <CodeShark> should be easy to review...and easy to rebase against
322015-10-02T02:51:00 <CodeShark> The reason being that if we're going to still use ISM for deployments I'd like to start organizing them better
332015-10-02T02:52:00 <CodeShark> So that when we do the first version bits deployments they are easier to review
342015-10-02T02:55:00 <gmaxwell> So it seems someone might have taken my comment about canoniczing transactions to heart, as someone is complaining to me about mutants, and they say that they think the smaller of the mutants is the mutated one.
352015-10-02T02:56:00 <gmaxwell> and that it started for them around midnight utc.
362015-10-02T02:56:00 <gmaxwell> if someone here is doing that, you probably should cut it out. If nothing else, it'll complicate scanning the blockchain and figuring out which wallet software needs to be nagged to produce low-S signatures.
372015-10-02T03:02:00 <CodeShark> if we rebase the current ISM soft forks against my soft forks unit, we can more easily decide how to deploy them later on without having to rebase them again
382015-10-02T03:03:00 <CodeShark> we can either continue to use ISM, we can deploy them one at a time, or several together, or eventually use versionbits
392015-10-02T03:06:00 <rusty> CodeShark I can only really judge after I've seen the result, so use your judgement I guess.
402015-10-02T03:08:00 <CodeShark> rusty, basically https://github.com/bitcoin/bitcoin/compare/master...CodeShark:versionbits but without softforks.h/softforks.cpp
412015-10-02T03:08:00 <CodeShark> and with better structured commits
422015-10-02T03:11:00 <CodeShark> I can rebase 68, 112, and 113 against it
432015-10-02T03:11:00 <CodeShark> as well as 65
442015-10-02T03:14:00 <CodeShark> I just want to see if there are any potential serious objections so I don't waste my time doing it
452015-10-02T03:14:00 <rusty> CodeShark that patch does too much. There's unnecesary code motion, collapse of variables, and a new return state.Invalid() which I don't see a source for.
462015-10-02T03:15:00 <CodeShark> which code motion are you referring to in particular?
472015-10-02T03:15:00 <rusty> CodeShark ah, this is more than one commit I'm looking at. One sec/
482015-10-02T03:15:00 <CodeShark> yeah, ignore the commit structure - just look at the final compare
492015-10-02T03:15:00 <CodeShark> I'll be sure to structure the commits to make them easier to review
502015-10-02T03:17:00 <rusty> CodeShark Hmm, IsValidVersion seems like a new concept; I can't see where the equiv code is removed. Maybe because you commented out rather than removing?
512015-10-02T03:17:00 <CodeShark> it replaces the explicit calls to IsSuperMajority in ContextualCheckBlockHeader
522015-10-02T03:18:00 <CodeShark> I'll be sure to make those movements in a single commit
532015-10-02T03:18:00 <CodeShark> yes, I did comment out what it replaces in main.cpp
542015-10-02T03:20:00 <rusty> Right, so overall it's not too bad, but I would be super paranoid and keep eg. "fEnforceBIP30" var, so diff is minimized. Then cleanup unnecessary vars at the end.
552015-10-02T03:20:00 <rusty> Make it super bite-size digestible. People may want a backport...
562015-10-02T03:21:00 <CodeShark> yeah, I want to try to change as little as possible in main.cpp.
572015-10-02T03:21:00 <CodeShark> Eventually I'd like the forks to be clearly visible within the consensus code and structured nicely...but that can wait
582015-10-02T03:24:00 <phantomcircuit> gmaxwell, ha
592015-10-02T03:25:00 <CodeShark> one of the goals, rusty, is to separate the review of BIPs for their features from the review of the deployment strategy
602015-10-02T03:26:00 <CodeShark> would be nice to disentangle the two
612015-10-02T03:28:00 <CodeShark> it would also be beautiful if we could avoid as much rebasing as possible from BIP proposal to BIP deployment
622015-10-02T03:29:00 <CodeShark> we keep getting stuck on stupid crap that continues to delay deployment unnecessarily
632015-10-02T03:29:00 <gmaxwell> versionbits must be backported unless we want to delay it's deployment until 0.12 is the oldest thing we'd backport to. :(
642015-10-02T03:29:00 <gmaxwell> we 'backported' it could be reimplemented, of course.
652015-10-02T03:30:00 <rusty> CodeShark: Agreed, a laudable goal.
662015-10-02T03:30:00 <gmaxwell> I think sipa's initial plan might have been to do that... e.g. using efficient implementation in new code and a 'walks the last 1000 blocks very block' implementation in backports.
672015-10-02T03:31:00 <CodeShark> walking back 1000 blocks every block isn't enough - we need to map state every activation interval in the block index
682015-10-02T03:31:00 <phantomcircuit> gmaxwell, what do you think about setting random bits to 0 in the bloom filter instead of clearing it at a fixed interval?
692015-10-02T03:32:00 <CodeShark> in any case, I'm fine with backporting versionbits itself after 0.12
702015-10-02T03:32:00 <CodeShark> the implementation is the easy part - it's getting it reviewed and acked that's a bitch :p
712015-10-02T03:32:00 <gmaxwell> we're pretty screwed on backport review bandwidth.
722015-10-02T03:33:00 <CodeShark> point is the current proposal won't require backporting
732015-10-02T03:33:00 <CodeShark> or will minimize it considerably
742015-10-02T03:33:00 <gmaxwell> there is always backporting even if the code is unchanged. :)
752015-10-02T03:34:00 <CodeShark> backporting will probably amount to changing a handful of lines in main.cpp
762015-10-02T03:34:00 <CodeShark> or are you also taking into account the proposed code movements for consensus and other stuff?
772015-10-02T03:35:00 <gmaxwell> More that I just mean that most of the 'backporting' work is actually the review to figure out if the changes are really safe in the new context.
782015-10-02T03:37:00 <CodeShark> yes, which is why I'm primarily interested in first merging stuff that will minimize such risks later on
792015-10-02T03:37:00 <CodeShark> it's a horrendous bottleneck
802015-10-02T03:37:00 <CodeShark> lots of people are frustrated
812015-10-02T03:39:00 <CodeShark> a good number of people doing real quantum leap type work on Bitcoin are waiting on changes that are taking forever
822015-10-02T03:40:00 <CodeShark> and it seems that we're wasting a lot of precious expert dev time having them basically repeat the same type of grunt work for each PR
832015-10-02T03:40:00 <CodeShark> (I'm looking at you, sipa)
842015-10-02T04:01:00 <CodeShark> to be clear, I don't want to sound like I'm complaining - this is not a complaint...I want to help Bitcoin Core be more efficient
852015-10-02T04:03:00 <CodeShark> the dev process, that is
862015-10-02T05:36:00 <GitHub54> [bitcoin] CodeShark opened pull request #6747: Softforks unit (master...softforks_unit) https://github.com/bitcoin/bitcoin/pull/6747
872015-10-02T05:49:00 <phantomcircuit> that's interesting someone reported "non-canonical ReadCompactSize()" in their error field thing
882015-10-02T05:50:00 <phantomcircuit> see the same thing... on all nodes
892015-10-02T05:50:00 <GitHub176> [bitcoin] paveljanik opened pull request #6748: Rewrite help texts for features enabled by default (master...configure_disable) https://github.com/bitcoin/bitcoin/pull/6748
902015-10-02T06:05:00 <gmaxwell> http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high "BIP62 is not currently deployed and we encourage all miners to enforce it as soon as possible." 0_o
912015-10-02T06:12:00 <phantomcircuit> gmaxwell, at this point it seems like it would be best if BIP62 rules were made IsStandard
922015-10-02T06:13:00 <gmaxwell> phantomcircuit: IIRC they aren't even all implemented, and as far as bip62 goes many were only to be applied to higher versioned transactions which don't exist.
932015-10-02T06:13:00 <gmaxwell> we also have relatively low confidence that they're complete.
942015-10-02T06:13:00 <gmaxwell> (like... I don't think anyone has even ever tried implementing them and AFLing to try to get a passing mutant)
952015-10-02T06:14:00 <phantomcircuit> gmaxwell, sure... but it raises the bar a bit
962015-10-02T06:15:00 <gmaxwell> but .. it doesn't. it would have no effect on the current mutations if they're ecdsa based, until people started producing elevated version transactions.
972015-10-02T06:18:00 <phantomcircuit> gmaxwell, mutate to low-s and reject even without higher version numbers as non standard
982015-10-02T06:18:00 <phantomcircuit> it's not a security consideration
992015-10-02T06:18:00 <phantomcircuit> just a nuisance reduction
1002015-10-02T06:18:00 <gmaxwell> phantomcircuit: okay, thats the instutionalize the attack thing I mentioned a day ago.
1012015-10-02T06:19:00 <phantomcircuit> broken wallets producing high-s are already just as broken as they are now
1022015-10-02T06:19:00 <gmaxwell> I'd really like to figure out who is producing high S and nag them to change.
1032015-10-02T06:19:00 <gmaxwell> I went to go measure it today but of course the attacks obscure the results. :)
1042015-10-02T06:20:00 <phantomcircuit> follow the crumbs of users complaining about weirdness with their wallet :P
1052015-10-02T06:21:00 <phantomcircuit> or maybe they'll stop
1062015-10-02T06:22:00 <gmaxwell> phantomcircuit: we should probably go write the nuclear canonicize transaction patch at least.
1072015-10-02T06:22:00 <phantomcircuit> yup
1082015-10-02T06:22:00 <phantomcircuit> gmaxwell, btw im trying to go back and get that trickle logic fixing patch commit ready
1092015-10-02T06:23:00 <phantomcircuit> thus my questions from before about AdvertiseLocal
1102015-10-02T06:37:00 <phantomcircuit> gmaxwell, well lets see, of the things on the BIP62 list the first is BIP66, right?
1112015-10-02T07:08:00 <wumpus> <phantomcircuit> is there a reason that ARM is the fastest travis build? <- yes a) no GUI b) doesn't run tests
1122015-10-02T07:08:00 <Luke-Jr> eh, why no GUI?
1132015-10-02T07:09:00 <Luke-Jr> I just figured it was because it ran first :P
1142015-10-02T07:09:00 <CodeShark> how can I run the same tests travis runs locally?
1152015-10-02T07:09:00 <Luke-Jr> wumpus: is there a reason for unbanning lightningbot?
1162015-10-02T07:10:00 <wumpus> Luke-Jr: something with depends, building Qt was somewhat tricky on ARM
1172015-10-02T07:10:00 <wumpus> CodeShark: qa/pulltester/rpc-tests.py
1182015-10-02T07:10:00 <wumpus> Luke-Jr: it's the logging bot
1192015-10-02T07:11:00 <Luke-Jr> oh
1202015-10-02T07:12:00 <CodeShark> thanks, wumpus
1212015-10-02T07:12:00 <Luke-Jr> wumpus: btw, I believe 5574 and 6349 are good to go
1222015-10-02T07:15:10 *** lightningbot has joined #bitcoin-core-dev
1232015-10-02T07:16:38 <aj> wumpus: this time for sure :-/
1242015-10-02T07:18:14 *** d_t has quit IRC
1252015-10-02T07:18:22 <aj> wumpus: logs are backfilled from my scrollback too fwiw
1262015-10-02T07:24:52 *** gmaxwell is now known as gmaxwell_
1272015-10-02T07:24:59 *** gmaxwell_ is now known as gregorymaxwell
1282015-10-02T07:25:04 *** gregorymaxwell is now known as gmaxweii
1292015-10-02T07:25:09 *** gmaxweii is now known as gmaxwelI
1302015-10-02T07:25:15 *** gmaxwelI is now known as gmaxwelIl
1312015-10-02T07:26:01 *** BlueMatt is now known as gmaxweII
1322015-10-02T07:26:14 *** gmaxweII is now known as BlueMatt
1332015-10-02T07:26:20 <BlueMatt> lol, you reg'd gmaxweII???
1342015-10-02T07:26:59 <midnightmagic> lotta scammers.
1352015-10-02T07:29:38 <wumpus> where bitcoin developers do their ritual tribal name-swapping dance
1362015-10-02T07:30:59 <CodeShark> hmm, when I run the tests locally it succeeds - but travis is choking
1372015-10-02T07:32:05 <BlueMatt> oh, I love those ones :(
1382015-10-02T07:32:12 <gmaxwelIl> BlueMatt: there was a scammer using it in the past, also freenode is about to expire a bunch of not used for a while nicks.
1392015-10-02T07:32:16 * BlueMatt misses when he ran the tester, then I could ssh in and figure it all out :)
1402015-10-02T07:32:25 <Luke-Jr> can someone throw a notice on BIP 62 that it is currently not deployable? http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high
1412015-10-02T07:32:53 <jonasschnelli> Hmm... I think we could speed up Travis by moving to the new platform. Would require to get rid of "sudo", "apt-*" calls and migrate to package installing over the YAML structure.
1422015-10-02T07:33:46 <gmaxwelIl> Luke-Jr: write the patch, I'll gladly ack/merge, just a "This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment."
1432015-10-02T07:34:06 <jonasschnelli> BlueMatt: an additional CI is still possible. Maybe no github auto-comment feature. I think some people run it.
1442015-10-02T07:34:24 *** dcousens has joined #bitcoin-core-dev
1452015-10-02T07:34:51 <BlueMatt> jonasschnelli: you miss the point, my point is when the tester failed, I could manually fix it for my pulls, adding new testers just means more failures, not ability for me to have privileged status through fixing my own pulls :p
1462015-10-02T07:35:14 <jonasschnelli> Ah.. I see. :-)
1472015-10-02T07:37:27 <Luke-Jr> https://github.com/bitcoin/bips/pull/210
1482015-10-02T07:41:24 <CodeShark> is there anything else I can do to diagnose the travis test failure issue?
1492015-10-02T07:41:26 <wumpus> CodeShark: travis servers tend to be very busy, this has, for me at least, triggered race conditions that wouldn't appear locally
1502015-10-02T07:41:49 <CodeShark> so what's the workaround?
1512015-10-02T07:42:39 <BlueMatt> load your workstation a ton before running locally?
1522015-10-02T07:42:46 <CodeShark> lol
1532015-10-02T07:42:57 <BlueMatt> also run tests on a workstation with like 20 cores?
1542015-10-02T07:42:59 <wumpus> run your tests while running a parallel a build of bitcoin core with gccin the background?
1552015-10-02T07:43:13 <wumpus> that will help to fill up memory as well as cores :-)
1562015-10-02T07:43:20 *** gmaxwelIl is now known as gmawell
1572015-10-02T07:43:25 <BlueMatt> wumpus: yea, if only my workstation would actually fill up its cores running "make -j"
1582015-10-02T07:43:29 <BlueMatt> but, it doesnt :(
1592015-10-02T07:43:39 <BlueMatt> damn 40 threads
1602015-10-02T07:43:41 <wumpus> BlueMatt: if X is high enough (though it will probabl yfill up memory first)
1612015-10-02T07:43:55 <BlueMatt> wumpus: no, not "make -jX", "make -j"
1622015-10-02T07:43:59 <BlueMatt> as in, run it ALL at once
1632015-10-02T07:44:20 <wumpus> but it creates a lot of nice I/O delays. Another option is the latter part of the chain verification with -par=high-number
1642015-10-02T07:44:25 <CodeShark> are you saying the race conditions are in Bitcoin Core? or in the travis environment?
1652015-10-02T07:44:27 <wumpus> BlueMatt: ooh I didn't know that one
1662015-10-02T07:44:35 <wumpus> CodeShark: in your code change, usually
1672015-10-02T07:44:45 <CodeShark> I didn't touch any threading stuff whatsoever
1682015-10-02T07:44:54 <BlueMatt> CodeShark: time to dust off the cpu miner!
1692015-10-02T07:45:25 <wumpus> CodeShark: where is it failing btw?
1702015-10-02T07:45:26 <BlueMatt> wumpus: yes, its only useful when you have 64GB memory lying around that has half your hdd in cache anyway, plus lots of threads to eat the work quick
1712015-10-02T07:45:39 <CodeShark> https://travis-ci.org/bitcoin/bitcoin/jobs/83252957
1722015-10-02T07:46:31 <CodeShark> oh, hmm Coinbase script size out of range
1732015-10-02T07:47:07 <wumpus> ah it fails in the block tester
1742015-10-02T07:47:17 <CodeShark> yeah - how can I reproduce that locally?
1752015-10-02T07:48:17 * wumpus did it in the past but doesn't know by heart
1762015-10-02T07:49:15 <wumpus> also don't see it in travis.yml at all, it just does 'make check' then the rpc-tests.sh script
1772015-10-02T07:49:28 <wumpus> but it's there somewhere!
1782015-10-02T07:49:36 <BlueMatt> its in ./configure
1792015-10-02T07:49:40 <BlueMatt> --with-comparison-tool=....
1802015-10-02T07:49:41 <BlueMatt> or so
1812015-10-02T07:49:44 <BlueMatt> then make check runs it
1822015-10-02T07:49:55 <BlueMatt> the ... being the path to the jar
1832015-10-02T07:50:11 <CodeShark> oh, I need to install java? :)
1842015-10-02T07:50:13 <CodeShark> lol
1852015-10-02T07:50:25 <BlueMatt> yes
1862015-10-02T07:50:29 <wumpus> ahh, yes I think in the case of travis it's being installed as part of depends, then configure picks it up automatically
1872015-10-02T07:52:21 <wumpus> but you can also download the jar and pas it with --with-comparison-tool, or even build the jar yourself if you're adventurous
1882015-10-02T07:53:37 <wumpus> we should add some documentation for this at some point
1892015-10-02T07:54:05 <wumpus> how to run the python tests is pretty well documented, but this isn't
1902015-10-02T07:54:08 <CodeShark> for the block tester, is it using real blocks on mainnet? or is it mining something?
1912015-10-02T07:54:22 <wumpus> regtest IIRC
1922015-10-02T07:54:50 <CodeShark> hmm...seems related to BIP34
1932015-10-02T07:55:04 <CodeShark> just a guess :)
1942015-10-02T07:55:06 <wumpus> I think it was the original motivation for regtest even
1952015-10-02T07:57:19 <CodeShark> ok, fine...installing jre...
1962015-10-02T07:57:21 <CodeShark> lol
1972015-10-02T08:01:54 <CodeShark> where can I grab the jar file?
1982015-10-02T08:02:13 *** n0n0_ has joined #bitcoin-core-dev
1992015-10-02T08:02:53 <CodeShark> meh...I'll install the jdk as well
2002015-10-02T08:03:30 <CodeShark> where's the java source located?
2012015-10-02T08:07:11 <wumpus> it's part of bitcoinj *however* that may not be the newest version, the person to ask would be cfields
2022015-10-02T08:07:42 <BlueMatt> the bitcoinj one is +/- the latest
2032015-10-02T08:09:11 <wumpus> https://github.com/theuni/bitcoind-comparisontool does he have any information there?
2042015-10-02T08:09:27 <CodeShark> I found the source - but I suppose I need to install the library as well and all that
2052015-10-02T08:09:33 <CodeShark> it's been ages since I touched java
2062015-10-02T08:10:22 <BlueMatt> you can grab the binary from the above repo
2072015-10-02T08:10:59 <wumpus> building it yourself is probably not worth it, unless you want to work on it, and fathom learning java build systems and such
2082015-10-02T08:11:22 <CodeShark> the 8c666 jar?
2092015-10-02T08:11:42 <wumpus> that's the one referred to in depends/packages/native_comparisontool.mk
2102015-10-02T08:13:13 <CodeShark> ok, test is running (crossing fingers)
2112015-10-02T08:14:22 <CodeShark> alright, successfully reproduced the error :)
2122015-10-02T08:14:42 <wumpus> phew, good
2132015-10-02T08:25:38 *** d_t has joined #bitcoin-core-dev
2142015-10-02T08:26:18 *** d_t has joined #bitcoin-core-dev
2152015-10-02T08:27:06 *** d_t has joined #bitcoin-core-dev
2162015-10-02T08:28:14 *** d_t has quit IRC
2172015-10-02T08:28:59 *** d_t has joined #bitcoin-core-dev
2182015-10-02T08:29:36 *** Cocodude has left #bitcoin-core-dev
2192015-10-02T08:30:08 *** d_t has quit IRC
2202015-10-02T08:31:05 *** d_t has joined #bitcoin-core-dev
2212015-10-02T08:32:00 *** d_t has quit IRC
2222015-10-02T08:32:47 *** d_t has joined #bitcoin-core-dev
2232015-10-02T08:33:52 *** d_t has quit IRC
2242015-10-02T08:36:03 *** TZander is now known as zander
2252015-10-02T08:36:32 *** zander is now known as thomasz
2262015-10-02T08:37:21 *** thomasz is now known as TZander
2272015-10-02T08:52:15 *** BashCo has joined #bitcoin-core-dev
2282015-10-02T08:53:16 <BlueMatt> sdaftuar/morcos: great call on switching to calling RemoveStaged after each loop iteration instead of at the end
2292015-10-02T08:53:21 <BlueMatt> resulted in removing more than a third of the lines of code in TrimToSize!
2302015-10-02T08:53:26 <BlueMatt> and the mempool is no longer sorted based on max(tx-feerate-with-descendants, tx-feerate), but instead only tx-feerate-with-descendants :)
2312015-10-02T08:54:29 <BlueMatt> the heart of mempool limiting in 6722 is now 55 LOC :)
2322015-10-02T08:56:29 <gmawell> BlueMatt: that sounds fantastic.
2332015-10-02T09:00:49 <gmawell> FWIW: re current malleability event, https://bitcointalk.org/index.php?topic=1198032.msg12579271#msg12579271
2342015-10-02T09:02:09 <BlueMatt> hah
2352015-10-02T09:10:25 <BlueMatt> ok, that shit was bugging me, now its 50 :)
2362015-10-02T09:14:58 *** warren_2 has joined #bitcoin-core-dev
2372015-10-02T09:15:11 *** Apocalyptic_ has joined #bitcoin-core-dev
2382015-10-02T09:17:21 *** TZander has quit IRC
2392015-10-02T09:17:47 *** Apocalyptic has quit IRC
2402015-10-02T09:17:47 *** warren has quit IRC
2412015-10-02T09:17:50 *** nanotube has quit IRC
2422015-10-02T09:17:51 *** Apocalyptic_ is now known as Apocalyptic
2432015-10-02T09:17:51 *** warren_2 is now known as warren
2442015-10-02T09:23:48 *** nanotube has joined #bitcoin-core-dev
2452015-10-02T09:38:29 *** tripleslash_e has joined #bitcoin-core-dev
2462015-10-02T09:38:41 *** tripleslash has quit IRC
2472015-10-02T10:04:30 *** rusty has joined #bitcoin-core-dev
2482015-10-02T10:33:33 <GitHub108> [bitcoin] petertodd opened pull request #6750: Recent rejects backport to v0.11 (0.11...recent-rejects-v0.11-backport) https://github.com/bitcoin/bitcoin/pull/6750
2492015-10-02T11:10:01 *** midnightmagic has quit IRC
2502015-10-02T11:14:40 *** midnightmagic has joined #bitcoin-core-dev
2512015-10-02T11:16:11 *** midnightmagic has quit IRC
2522015-10-02T11:20:16 *** midnightmagic has joined #bitcoin-core-dev
2532015-10-02T11:20:39 *** midnightmagic is now known as Guest73782
2542015-10-02T11:22:19 *** rusty has quit IRC
2552015-10-02T11:28:20 *** rusty has joined #bitcoin-core-dev
2562015-10-02T11:44:50 *** Guest73782 has quit IRC
2572015-10-02T11:46:56 *** ParadoxSpiral has joined #bitcoin-core-dev
2582015-10-02T12:11:28 *** midnightmagic_ has joined #bitcoin-core-dev
2592015-10-02T12:21:28 *** rusty has quit IRC
2602015-10-02T12:41:20 *** midnightmagic_ is now known as midnightmagic
2612015-10-02T12:58:02 *** midnightmagic has quit IRC
2622015-10-02T12:59:29 *** midnightmagic has joined #bitcoin-core-dev
2632015-10-02T13:05:12 *** BashCo has quit IRC
2642015-10-02T13:05:12 *** BashCo has joined #bitcoin-core-dev
2652015-10-02T13:05:12 *** BashCo has quit IRC
2662015-10-02T13:05:12 *** BashCo has joined #bitcoin-core-dev
2672015-10-02T13:06:51 *** BashCo_ has joined #bitcoin-core-dev
2682015-10-02T13:09:10 *** dcousens has quit IRC
2692015-10-02T13:10:49 *** BashCo has quit IRC
2702015-10-02T13:29:41 <btcdrak> Luke-Jr: gmaxwell: I asked coinkite to change their blog post
2712015-10-02T13:40:03 *** goregrind has quit IRC
2722015-10-02T13:43:26 <sdaftuar> ;
2732015-10-02T13:46:24 <DocHex> btcdrak: (it's been updated) if you have a link to something about what's missing in BIP62, or what remains to be done, I'm happy to link to that on the blog too.
2742015-10-02T13:55:33 <sdaftuar> BlueMatt: one other thought about the mempool limiting algorithm -- i was thinking about how, in TrimToSize, we're skipping over any packages that have the new tx as a descendant
2752015-10-02T13:56:11 <sdaftuar> it seems a little counterintuitive to me that we might let in a new transaction that ends up joining some package near the bottom of the mempool, while it may have been able to evict some higher up package (and set the min relay fee higher than the bottom package in the mempool)
2762015-10-02T13:57:59 <sdaftuar> i'm not sure there's any big problem here that needs solving, i haven't yet thought of any new fundamental attacks, but it made me wonder if this modified algorithm might be easier to reason about:
2772015-10-02T13:59:19 <sdaftuar> when a new transaction comes in, let it in if it exceeds the current prevailing relay fee (and all the usual other checks). after accepting it, call TrimToSize() and remove packages from the bottom until we're under the size limit, and update the relay fee based on whether anything was evicted
2782015-10-02T13:59:56 <sdaftuar> (at that point, we could set our notion of whether this tx was accepted or rejected based on whether it's still in the mempool at the end)
2792015-10-02T14:11:25 *** CoinMuncher has joined #bitcoin-core-dev
2802015-10-02T14:13:12 *** BashCo has joined #bitcoin-core-dev
2812015-10-02T14:16:03 *** BashCo_ has quit IRC
2822015-10-02T14:38:59 <morcos> BlueMatt: your change to use only package fee rate and not max: any reasoning behind that?
2832015-10-02T14:39:36 <morcos> I can't think of a problem off of the top of my head, i know there were problems with earlier versions if you didn't use the max, but maybe they've all gone away now that we evict (and resort) on every pass.
2842015-10-02T14:39:48 <morcos> but it certainly changes behavior.
2852015-10-02T14:44:06 *** paveljanik has joined #bitcoin-core-dev
2862015-10-02T14:57:02 *** rubensayshi has joined #bitcoin-core-dev
2872015-10-02T15:05:25 *** zooko has joined #bitcoin-core-dev
2882015-10-02T15:16:46 *** goregrind has joined #bitcoin-core-dev
2892015-10-02T15:35:18 *** zveda has joined #bitcoin-core-dev
2902015-10-02T15:35:39 *** zveda has left #bitcoin-core-dev
2912015-10-02T15:38:16 *** fkhan has quit IRC
2922015-10-02T15:51:29 *** rubensayshi has quit IRC
2932015-10-02T15:52:06 *** treehug88 has joined #bitcoin-core-dev
2942015-10-02T16:04:50 *** BashCo has quit IRC
2952015-10-02T16:07:04 *** d_t has joined #bitcoin-core-dev
2962015-10-02T16:10:15 *** n0n0__ has joined #bitcoin-core-dev
2972015-10-02T16:13:54 *** n0n0_ has quit IRC
2982015-10-02T16:15:24 *** rubensayshi has joined #bitcoin-core-dev
2992015-10-02T16:18:35 *** rubensayshi has quit IRC
3002015-10-02T16:46:10 *** fkhan has joined #bitcoin-core-dev
3012015-10-02T16:49:36 *** randy-waterhouse has joined #bitcoin-core-dev
3022015-10-02T16:50:15 <cfields> jonasschnelli: sorry i missed your question yesterday, i didn't realize my irc client had shut down. It did seem unusually quiet, though :)
3032015-10-02T16:50:29 <cfields> Missed the meeting too :\
3042015-10-02T16:52:07 <cfields> wumpus / sipa: I'm working to have something to show wrt network code asap. It's taking much longer than expected, I've hit snags and had to refactor several times now
3052015-10-02T16:53:14 <cfields> ultimately I've decided not to mess with much at the individual message level yet, so the general flow there is pretty much the same as now
3062015-10-02T16:53:36 <wumpus> "i didn't realize my irc client had shut down" hehe that has happened to me too
3072015-10-02T16:53:42 <wumpus> nice cfields!
3082015-10-02T16:54:18 <wumpus> any problems with libevent? or just with our code structure?
3092015-10-02T16:55:17 <cfields> wumpus: nah, no problems. Just lots of sudden "oh, so that's how that works. well shit." moments
3102015-10-02T17:08:02 *** d_t has quit IRC
3112015-10-02T17:14:50 *** adam3us has joined #bitcoin-core-dev
3122015-10-02T17:29:31 *** zooko has quit IRC
3132015-10-02T17:31:24 <CodeShark> cfields: as you probably know, I've also dabbled a bit in this messaging stuff...if you would like me to review anything I'd like to have a look
3142015-10-02T17:40:47 <cfields> CodeShark: great, thanks
3152015-10-02T17:40:52 *** CoinMuncher1 has joined #bitcoin-core-dev
3162015-10-02T17:43:07 *** CoinMuncher has quit IRC
3172015-10-02T17:44:01 *** CoinMuncher has joined #bitcoin-core-dev
3182015-10-02T17:45:19 *** CoinMuncher1 has quit IRC
3192015-10-02T17:51:37 <jgarzik> cfields, feel free to ask questions
3202015-10-02T17:52:25 <jgarzik> cfields, there is a lot of subtlety. for example, we stop reading in if writing output pauses. fixes some TCP windowing attacks (along with some related logic).
3212015-10-02T17:55:54 <btcdrak> ping maaku
3222015-10-02T17:59:00 <maaku> yes?
3232015-10-02T18:00:51 <btcdrak> maaku: sdaftuar was asking if there was a resolution to this http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009344.html
3242015-10-02T18:01:03 <jgarzik> cfields, management of the active set should be the same across current code and new libevent code
3252015-10-02T18:01:26 <sdaftuar> maaku: yeah i was just wondering if there was an open pull to implement your solution in that thread?
3262015-10-02T18:06:49 <maaku> sdaftuar: #6312 does not suffer that issue
3272015-10-02T18:07:10 <maaku> most significant bit determines whether relative lock-time semantics are used
3282015-10-02T18:10:27 <CodeShark> maaku: you still don't have a PR for the actual soft forks, just the mempool stuff, right?
3292015-10-02T18:11:56 <sdaftuar> maaku: thanks, i think i'm reading the wrong bip 68 text, perhaps -- i believe the link from #6312 is to an older draft?
3302015-10-02T18:13:21 <CodeShark> I wanted to ask you about the trigger mechanisms when you have a moment
3312015-10-02T18:13:31 *** DocHex has left #bitcoin-core-dev
3322015-10-02T18:15:41 <btcdrak> CodeShark: there wont be softforking PRs until this gets merged
3332015-10-02T18:19:37 <btcdrak> sdaftuar: should be this https://github.com/maaku/bips/blob/bip68/bip-0068.mediawiki
3342015-10-02T18:20:50 <sdaftuar> btcdrak: that differs from https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
3352015-10-02T18:21:07 <btcdrak> oh i see, typo.
3362015-10-02T18:21:22 <btcdrak> well /master/ is the right one
3372015-10-02T18:23:21 *** zooko has joined #bitcoin-core-dev
3382015-10-02T18:28:58 <morcos> btcdrak: typo? its just different text, oh you mean typo on the link?
3392015-10-02T18:29:28 <btcdrak> yeah the link is to brancn bip68 rather than master branch, ping @maaku
3402015-10-02T18:31:26 <morcos> what's the right way to leave feedback on the bip text
3412015-10-02T18:31:46 <morcos> the terminology "reduced by 2^14" was confusing to me, also there are small typos
3422015-10-02T18:32:02 <morcos> open an issue?
3432015-10-02T18:32:37 *** ParadoxSpiral_ has joined #bitcoin-core-dev
3442015-10-02T18:33:25 *** d_t has joined #bitcoin-core-dev
3452015-10-02T18:35:22 *** ParadoxSpiral has quit IRC
3462015-10-02T18:39:22 *** CoinMuncher has quit IRC
3472015-10-02T18:41:38 <btcdrak> Open a PR directly
3482015-10-02T18:42:02 <btcdrak> or if you dont have time PM me the issues and I'll make a PR quickly
3492015-10-02T18:44:39 <morcos> Yeah I didn't want to PR because I'm not sure what the history of arriving at the phrase "reduced by" is, but I found it confusing. that same sentence has a typo "heigh" instead of "height". If I find more, I'll PR them, but I'm going to review pulls now
3502015-10-02T18:51:07 <btcdrak> ty
3512015-10-02T19:08:41 *** BashCo has joined #bitcoin-core-dev
3522015-10-02T19:41:26 <btcdrak> does anyone know which block BIP66 enforced on specifically?
3532015-10-02T19:41:54 <CodeShark> I think 358806
3542015-10-02T19:43:51 <CodeShark> it's probably something really stupid - according to the cli, it's still activating the best chain when it runs
3552015-10-02T19:54:01 *** CodeShark_ has quit IRC
3562015-10-02T19:54:53 *** treehug88 has quit IRC
3572015-10-02T19:55:23 <maaku> sdaftuar: it's a one-line fix to make the CLTV soft-fork do 68, 112, and 113 as well
3582015-10-02T19:57:31 <btcdrak> maaku, we need to bump transaction version to 2 also right?
3592015-10-02T20:02:32 *** d_t has quit IRC
3602015-10-02T20:02:50 *** d_t has joined #bitcoin-core-dev
3612015-10-02T20:12:12 <BlueMatt> morcos: the reasoning was its not no longer useful to do so
3622015-10-02T20:12:54 <BlueMatt> (and simplicity is better)
3632015-10-02T20:15:15 <BlueMatt> sdaftuar: hmmmmmm, yeaaaaa
3642015-10-02T20:15:38 *** bitdevsnyc has joined #bitcoin-core-dev
3652015-10-02T20:16:31 *** zooko has quit IRC
3662015-10-02T20:19:14 <BlueMatt> sdaftuar: yay more loc removal :)
3672015-10-02T20:20:16 <jgarzik> maaku, oh? (RE one-line)
3682015-10-02T20:20:46 <morcos> BlueMatt: For example: if A->B,C and B,C -> D. D = 90 B = 10, C = 10 A = 70. Then the package sorts before B or C, but the max sorts after
3692015-10-02T20:21:20 <morcos> so would you really want to boot A from your mempool? it might be the most expensive immediately minable tx in there?
3702015-10-02T20:22:00 <maaku> ok maybe 2-3 lines. basically the CLTV soft-fork does a supermajority check and sets a script validation flag. 112 would set a different script validation flag, and 68 and 113 would set a lock-time flag
3712015-10-02T20:22:38 <morcos> its not clear to me that max is better, but its a difference worth considering.
3722015-10-02T20:22:41 <maaku> the pull requests for 68, 112, and 113 are specifically coded to support the same soft-fork rollout as cltv
3732015-10-02T20:23:18 <morcos> maaku: i've just started my review of these things, is there an analysis anywhere of why we don't need the mempool-only versions to be released for a while before we do the soft fork
3742015-10-02T20:23:21 <BlueMatt> ok, TrimToSize is now 10 LOC
3752015-10-02T20:23:35 <morcos> for instance do we know there are no txs which would fail?
3762015-10-02T20:23:55 <morcos> well not none, but you know what i mean, they aren't being regularly generateed
3772015-10-02T20:24:50 <morcos> quite honestly this seems like kind of a lot of new code to me and that it might make more sense to have it as mempool only first before softforking it in
3782015-10-02T20:24:59 <maaku> morcos: why would we?
3792015-10-02T20:25:09 <morcos> or at least have it in master for a while before releasing a soft fork with it
3802015-10-02T20:25:17 <morcos> why would we what?
3812015-10-02T20:25:46 <maaku> what would be the reason to have them in master as mempool only?
3822015-10-02T20:26:00 <maaku> for some period of time that is, it obviously makes sense to break up the PRs that way
3832015-10-02T20:26:20 <morcos> so they get a lot more real world testing
3842015-10-02T20:27:09 <BlueMatt> morcos: hmmm...how did I convince myself that it was never used? :/
3852015-10-02T20:27:16 <BlueMatt> (anymore)
3862015-10-02T20:27:31 <maaku> (1) they can (and have) been tested on elements alpha, (2) i'm not sure what real world testing can be done until it is a consensus rule, that can't already be done against the PR before merging it
3872015-10-02T20:27:51 <morcos> i mean i can see why waiting for 0.12 to release mempool only and months later for a soft fork roll out is too long to wait. but i find it hard to imagine that i personally will be comfortable with acking it for a soft fork in the next couple weeks
3882015-10-02T20:27:59 <morcos> 1) is a good point, i hadn't though tabout that
3892015-10-02T20:28:20 <morcos> thats not to say i would NACK it, not at all, just i'd depend on other people being really comfortable with it
3902015-10-02T20:28:54 <morcos> anyway, i'll keep reviewing, maybe comfort will come quicker, and at the very least we should get the mempool pulls merged as quickly as we can
3912015-10-02T20:29:09 <maaku> morcos: maybe there's a reason to have it tested as mempool-only. but i'd like to actually see a test plan.
3922015-10-02T20:29:55 <btcdrak> morcos we should get these ACKd, the ISM softfork would be a separate PR anyway, so there's no reason you couldnt ACK these as they are mempool only anyhow.
3932015-10-02T20:30:50 <morcos> BlueMatt: certainly before you evicted on every pass, it was a requirement to avoid certain types of degenerate situations.. i remember being glad it was there on several occasions. i _think_ its not required any more, but i'm not sure whether its better or worse with it.
3942015-10-02T20:31:02 <morcos> btcdrak: yes agreed, see my prior mesg
3952015-10-02T20:32:33 <BlueMatt> morcos: well its obviously non-optimal in the case you just proposed
3962015-10-02T20:33:00 <BlueMatt> welll, maybe not
3972015-10-02T20:33:23 <BlueMatt> so I'm gonna leave it in
3982015-10-02T20:33:48 <morcos> BlueMatt: leave what in?
3992015-10-02T20:34:14 <BlueMatt> hmm, I dunno, so the metric I was targeting (which it seems we can hit) is to optimize average feerate in mempool
4002015-10-02T20:34:24 <morcos> I'd vote for reverting it to max, but I can't make a concrete argument thats better.
4012015-10-02T20:34:27 <maaku> morcos: my frustration re: this is that I've seen stuff get shelved on multiple occasions for reasons such as "to get more real world testing", but really all that seems to happen is delay because nothing gets done in the interim
4022015-10-02T20:34:53 <maaku> if we need to delay for mempool testing, then that's fine, but we need to be explicit about what needs to be tested before advancing to the next stage
4032015-10-02T20:34:56 <morcos> BlueMatt: I don't think you should be worrying about optimizing for that metric. Worry about attacks and not doing anything stupid.
4042015-10-02T20:35:04 <BlueMatt> suresure
4052015-10-02T20:35:40 <BlueMatt> i wasnt suggesting deciding based on that metric, but that that metric is what we can make an algorithm that isnt trivially attack-able and is optimal
4062015-10-02T20:36:21 <BlueMatt> in the above case, using a max() will result in a larger mempool with lower feerate
4072015-10-02T20:36:42 <BlueMatt> which I kinda like
4082015-10-02T20:36:46 <BlueMatt> so, yea, I'd prefer leaving it in
4092015-10-02T20:36:50 <BlueMatt> (I already pushed that, anyway)
4102015-10-02T20:36:53 <sdaftuar> maaku: i've been reviewing #6312, and one thing jumps out at me
4112015-10-02T20:37:10 <jgarzik> What are good pre-reqs for time based limiting? bluematt's stuff
4122015-10-02T20:37:11 <sdaftuar> i don't understand how we're using the new LockTime() function in ContextualCheckBlock
4132015-10-02T20:37:12 <jgarzik> ?
4142015-10-02T20:37:27 <sdaftuar> pcoinsTip isn't being updated between transactions in the caller
4152015-10-02T20:37:48 <sdaftuar> so i don't get how the LockTime code can be doing the right thing, in the case of a chain of transactions within a block?
4162015-10-02T20:38:14 <sdaftuar> i know it's not relevant for the mempool-only case, but it seems like a problem when we want to make it part of consensus
4172015-10-02T20:38:23 <maaku> sdaftuar: in that case it isn't being called with pcoinsTip, it is using the block validation view
4182015-10-02T20:38:29 <maaku> the consensus code doesn't use pcoinsTip
4192015-10-02T20:39:00 <sdaftuar> ContextualCheckBlock() does, right?
4202015-10-02T20:39:43 <morcos> jgarzik: i didn't understand your question. i think BlueMatt is adding time based expiration similar to sipa's commit from 6557 right?
4212015-10-02T20:41:21 <maaku> sdaftuar: you are correct. hrm. working around sipa's nits broke that
4222015-10-02T20:41:28 <morcos> BlueMatt: was the time based commit going to be added to 6722? what else is left to do? i'm kind of waiting til you say "done" to start diving into it again.
4232015-10-02T20:41:39 <maaku> (prior versions would skip inputs that weren't found)
4242015-10-02T20:42:12 <jgarzik> ditto
4252015-10-02T20:42:30 <jgarzik> morcos, BlueMatt: I thought time-based was "later" but may have misunderstood.
4262015-10-02T20:44:01 <sdaftuar> i don't think skipping would be safe either, would it?
4272015-10-02T20:44:19 <sdaftuar> you might have a transaction that can't be spent until a block after its parent...
4282015-10-02T20:44:52 <sdaftuar> i'm not sure but i don't believe that ConnectBlock redoes the LockTime() tests (?)
4292015-10-02T20:45:55 <morcos> maaku: btw, i think the answer to my question a few mins ago is that its already non-standard to create txs which violate the new rules, because they have to be nVersion=2. i hadn't caught that that makes it safer to go straight to soft fork.
4302015-10-02T20:46:24 <BlueMatt> morcos: I was figuring I'd just leave the timeout-ing to right afterwards, and adding multiple txn in one step, too
4312015-10-02T20:46:34 <BlueMatt> so....go review?
4322015-10-02T20:46:41 <BlueMatt> all thats left that I know of is writing tests
4332015-10-02T20:46:49 <BlueMatt> it may be very broken right now and I wouldnt know it
4342015-10-02T20:47:32 <morcos> BlueMatt: you didn't adddress the DynamicMemoryUsage calculation then. its already set up to include a time index, which wouldn't be part of your pull
4352015-10-02T20:47:41 <morcos> i commented on the pull about that earlier
4362015-10-02T20:48:14 <morcos> i say just add the Expire() commit, its short and simple and basically stands alone
4372015-10-02T20:48:29 <jgarzik> BlueMatt, +1 :)
4382015-10-02T20:48:35 <morcos> and i think it really helps to reason about how the whole mempool is kept limited
4392015-10-02T20:49:29 <morcos> (but definitely hold off on the multiple txs piece! i'm not sure i even agree thats something we want to do, RBF is so much superior)
4402015-10-02T20:49:45 <sdaftuar> wow that is way shorter code
4412015-10-02T20:49:49 <maaku> sdaftuar: I'm investigating -- that was my memory that ConnectBlock redoes the LockTime() tests with context
4422015-10-02T20:50:04 <maaku> but I'm having trouble finding it
4432015-10-02T20:51:08 <jgarzik> Does CLTV/CSV enable a situation where you can create tiered time locks: funds frozen on chain. At time X, pubkey A can redeem. At time X+N, pubkeys (A,B) can redeem.
4442015-10-02T20:52:00 <maaku> jgarzik: yes that's the driving purpose
4452015-10-02T20:52:04 <jgarzik> The idea is a custodian could hold a backup key for the later time period, if funds are not claimed by active and aware participants.
4462015-10-02T20:52:14 <btcdrak> jgarzik: yup.
4472015-10-02T20:52:17 <gmawell> jgarzik: of course, as its just a script opcode. :)
4482015-10-02T20:52:41 <morcos> maaku: interpreter.cpp calls CheckLockTime
4492015-10-02T20:52:43 <gmawell> if () {lock1 condition} elsif () {lock2 condition2} ....
4502015-10-02T20:53:06 <jgarzik> CLTV can do this alone, yes?
4512015-10-02T20:53:13 <morcos> EvalScript I should say
4522015-10-02T20:53:24 <jgarzik> It appears so.
4532015-10-02T20:53:30 <maaku> morcos: different CheckLockTime (ugh, sorry about that)
4542015-10-02T20:53:50 <maaku> the interpreter.cpp one is a method of SignatureChecker
4552015-10-02T20:53:57 <morcos> oh yeah of course, thats horrible
4562015-10-02T20:54:12 <maaku> yeah didn't even notice until now
4572015-10-02T20:55:30 *** gmawell is now known as gmaxwell
4582015-10-02T20:55:51 * btcdrak just had a cup of coffee
4592015-10-02T20:56:04 <btcdrak> *gmaxwell
4602015-10-02T20:59:22 <BlueMatt> morcos: it stands well alone is exactly why it should be its own pr :p
4612015-10-02T20:59:48 <morcos> BlueMatt: i regreted that choice of words before I hit Enter
4622015-10-02T20:59:55 <BlueMatt> :)
4632015-10-02T20:59:59 <BlueMatt> morcos: yes, but the earlier comment was "the 9 is wrong"
4642015-10-02T21:00:01 <BlueMatt> not what it should be
4652015-10-02T21:00:20 <morcos> i think its supposed to be 3 * the number of indices
4662015-10-02T21:00:22 <BlueMatt> so the 9 should be 3
4672015-10-02T21:00:22 <morcos> so 6
4682015-10-02T21:00:24 <BlueMatt> and then its fine?
4692015-10-02T21:00:26 <BlueMatt> oh, wait, what
4702015-10-02T21:00:27 <morcos> no
4712015-10-02T21:00:42 <morcos> unfortunately sdaftuar and i broke it in master already
4722015-10-02T21:00:43 <BlueMatt> the 9 should be 6 and then its fine?
4732015-10-02T21:00:53 <morcos> DynamicMemoryUsage is 9 (and hsould be 6) in master
4742015-10-02T21:01:00 <BlueMatt> who's code is it anyway? (tm)
4752015-10-02T21:01:07 <sdaftuar> was my fault :)
4762015-10-02T21:01:12 <morcos> GuessDynamicMemoryUSage is new and should be the same as master
4772015-10-02T21:01:17 <morcos> sorry
4782015-10-02T21:01:22 <morcos> same as DynamicMemoryUsage
4792015-10-02T21:01:24 <BlueMatt> ahh, ok
4802015-10-02T21:01:27 <BlueMatt> I'll go fix both, then
4812015-10-02T21:01:30 <morcos> so both should be 6 unless you add expiration
4822015-10-02T21:01:33 <morcos> which is what you should do
4832015-10-02T21:01:37 <morcos> so then they should both be 9
4842015-10-02T21:01:46 <BlueMatt> I'll just do 6 and let you add expiration :)
4852015-10-02T21:02:52 <morcos> (if i remain silent does it cause you to reconsider?)
4862015-10-02T21:03:00 <BlueMatt> heh
4872015-10-02T21:03:06 <BlueMatt> I'm gonna go rebase the whole pr
4882015-10-02T21:03:10 <morcos> +!
4892015-10-02T21:03:12 <morcos> 1
4902015-10-02T21:14:08 <phantomcircuit> sipa, what ever happened to the normalized transaction id stuff?
4912015-10-02T21:17:39 <morcos> maaku: btcdrak: its really confusing for someone who hasn't been following all along when the BIP's and the PR's are just completely different
4922015-10-02T21:17:56 <morcos> for CSV, the BIP seems to be describing an earlier version?
4932015-10-02T21:18:02 *** belcher_ has joined #bitcoin-core-dev
4942015-10-02T21:19:31 <morcos> where is the most up to date version of BIP-112?
4952015-10-02T21:21:47 <btcdrak> morcos, the BIP text needs updating, let me push that
4962015-10-02T21:21:51 <btcdrak> (for 112)
4972015-10-02T21:23:51 <morcos> btcdrak: i know BIPs are supposed to be descriptive, not proscriptive, but it sure would be helpful for proposed soft forks like this if there is a clear consensus on the semantics separately and first, and then the code can be reviewed for compliance with that
4982015-10-02T21:24:41 *** n0n0__ has quit IRC
4992015-10-02T21:25:15 <btcdrak> BIP68 was ironed out exactly that way. BIP112 just needs tweaking because of the references to BIP68.
5002015-10-02T21:26:05 <morcos> ok fair enough
5012015-10-02T21:28:52 <maaku> sorry btcdrak had authored new text for BIP 112. I didn't realize it hadn't been pushed
5022015-10-02T21:36:16 <morcos> maaku: oh i didn't realize the name conflict on CheckLockTime goes away with CSV, that's good
5032015-10-02T21:37:31 <morcos> oh spoke too soon, sorry
5042015-10-02T21:49:37 <BlueMatt> morcos/jgarzik/sdafutar: ok, pushed a new version of #6722
5052015-10-02T21:49:46 <BlueMatt> because expiry is so simple I went ahead and merged that
5062015-10-02T21:49:54 <BlueMatt> I also squashed everything into reasonably reviewable bites
5072015-10-02T21:50:25 <jgarzik> BlueMatt, does expiry occur even if mempool is not full?
5082015-10-02T21:50:31 <BlueMatt> yes
5092015-10-02T21:50:37 <jgarzik> good
5102015-10-02T21:51:04 <morcos> BlueMatt: great! just in time for me to call it a week however. will review asap
5112015-10-02T21:51:11 <morcos> why'd you make it 72 hours though
5122015-10-02T21:51:14 <morcos> way too small
5132015-10-02T21:52:10 <BlueMatt> because we dont have large-scale cpfp deployed by miners :(
5142015-10-02T21:52:16 <morcos> if blocks are on average 90% full, then a 300MB mempool could last most of a week
5152015-10-02T21:52:17 <BlueMatt> and the mempool limiting stuff assumes that
5162015-10-02T21:52:19 <morcos> ah
5172015-10-02T21:52:36 <morcos> ok will review with that in mind
5182015-10-02T21:55:18 <jgarzik> BlueMatt, with 10,000 txs in mempool, what is the expense of Expire() + TrimToSize() for each new tx? (wall clock time /cpu cycles)
5192015-10-02T22:00:16 <morcos> jgarzik: i did some measurements on old versions, and it was pretty fast, and its been made much much faster with matt's algo
5202015-10-02T22:00:31 <morcos> the slow stuff is already merged which is calculating the descendant packages
5212015-10-02T22:00:32 <BlueMatt> in terms of real cost, untested, in terms of complexity - its something like n*m^2*lgm where n is the number of packages to remove and m is the number of txn in that package
5222015-10-02T22:00:52 <morcos> it wouldn't be a bad idea to measure it again now
5232015-10-02T22:00:53 <jgarzik> as long as it's operating off a sorted index it's fine. just want to avoid a bunch of whole-mempool walks in edge/worst cases. reading now...
5242015-10-02T22:01:05 <morcos> but the real question is yep, exactly, edge cases
5252015-10-02T22:01:15 <morcos> so its more about thinking of whats the worst case we can encounter
5262015-10-02T22:01:22 <BlueMatt> if you have a bunch of tiny packages, then its just n, which isnt so bad
5272015-10-02T22:01:27 <BlueMatt> if you have very large packages, then n is 1
5282015-10-02T22:01:57 <BlueMatt> the worst-case, really, is a large single txn comes in to replace a single package which has a TON of tiny txn
5292015-10-02T22:02:42 <morcos> no i meant like the attack scenarios we were describing
5302015-10-02T22:03:01 <morcos> shoot, i forgot i was supposed to draft an email to dev about reduced package sizes
5312015-10-02T22:03:05 <jgarzik> expiry can also create orphans
5322015-10-02T22:03:37 <morcos> CalculateDescendants makes sure all the descendants are found and also removed
5332015-10-02T22:05:45 <dgenr8> expiring at 2 hours, and happily relying on replacement to bump fees is an interesting strategy
5342015-10-02T22:07:34 <jgarzik> I think 2 hours is way too short for expiry
5352015-10-02T22:09:18 <BlueMatt> honestly I think it should be closer to 12/24 with the current mempool limiting stuff
5362015-10-02T22:09:53 * dgenr8 good to look at the latest fee estimates
5372015-10-02T22:10:01 <jgarzik> 48 hours is my pref
5382015-10-02T22:10:22 <BlueMatt> jgarzik: you forget the mempool limiting stuff assumes cpfp
5392015-10-02T22:10:24 <BlueMatt> and miners dont have it
5402015-10-02T22:10:35 <BlueMatt> so anything that is in mempool because of cpfp is essentially there until it times out
5412015-10-02T22:10:38 <jgarzik> miners run big mempools anyway
5422015-10-02T22:10:55 <BlueMatt> that is irrelevant
5432015-10-02T22:11:27 <jgarzik> few use CPFP or descendents at all
5442015-10-02T22:11:40 <BlueMatt> yes, thats my point
5452015-10-02T22:11:45 <jgarzik> zero conf security actively incentives against it
5462015-10-02T22:11:55 <jgarzik> & malleation
5472015-10-02T22:12:18 <BlueMatt> what???
5482015-10-02T22:12:50 <BlueMatt> as a miner, its clearly in your best interest to use cpfp
5492015-10-02T22:13:23 <BlueMatt> there just isnt code to do so, so most dont
5502015-10-02T22:13:29 <BlueMatt> well, not merged code, at least
5512015-10-02T22:13:31 <BlueMatt> ie well-reviewed code
5522015-10-02T22:13:48 <dgenr8> estimatefee 12 = 0.00008634; estimatefee 24 = 0.00006981
5532015-10-02T22:13:59 <jgarzik> BlueMatt, think from the user PoV
5542015-10-02T22:14:08 <BlueMatt> in any case, the point is, because miners dont do it, random nodes' mempools accept things that they hold because cpfp makes them have lots of fees
5552015-10-02T22:14:20 <BlueMatt> so they hold these txn only because of cpfp and will hold them until they expire
5562015-10-02T22:14:26 <BlueMatt> hence why a low expiry time makes sense
5572015-10-02T22:14:31 <jgarzik> BlueMatt, in practice there are few descendents and malleation attacks make them even less likely
5582015-10-02T22:14:41 <BlueMatt> what does this have to do with miners?
5592015-10-02T22:14:45 <BlueMatt> yes, users dont use cpfp
5602015-10-02T22:14:52 <BlueMatt> they should be using rbf
5612015-10-02T22:14:53 <jgarzik> thus miners don't use cpfp
5622015-10-02T22:15:07 <jgarzik> let's consider what -is- before -should be- :)
5632015-10-02T22:15:15 <BlueMatt> miners dont because its not much extra income and the patches arent well-reviewed, not because they actively choose not to
5642015-10-02T22:15:24 <BlueMatt> yes, thats what I'm saying.......
5652015-10-02T22:15:42 <BlueMatt> of course all the mempool stuff being written today is written assuming we do cpfp in mining soon
5662015-10-02T22:15:43 <jgarzik> if there is no user cpfp traffic, miners do not use cpfp (nor have an incentive to deploy it or bother with it much at all)
5672015-10-02T22:15:44 <BlueMatt> which we should
5682015-10-02T22:15:54 <BlueMatt> there is some, however
5692015-10-02T22:16:01 <BlueMatt> and thus they should be using it
5702015-10-02T22:16:34 <BlueMatt> in *any* case, writing a cpfp-included mining thing based on mempool tracking will make mining a TON more efficient in any case
5712015-10-02T22:16:44 <BlueMatt> so we should do that
5722015-10-02T22:17:50 <jgarzik> In theory sure. But's it's optimizing for the "last 0.0001%" Bitcoin isn't great for long chains of unconfirmed transactions. Sure miners should capture those, but users and services will not generate them.
5732015-10-02T22:18:06 <BlueMatt> we need to rewrite the mining stuff anyway
5742015-10-02T22:18:07 <jgarzik> Just noting the context. If it comes for free, great. But don't put a lot of effort into supporting something users won't much use.
5752015-10-02T22:18:08 <BlueMatt> because it sucks
5762015-10-02T22:18:14 <BlueMatt> including cpfp in that is the logical decision
5772015-10-02T22:19:15 <jgarzik> Including rarely used features isn't necessarily logical.
5782015-10-02T22:19:18 <BlueMatt> in any case, this is way off topic from the original discussion - the mempool expiry time
5792015-10-02T22:19:34 <BlueMatt> rarely used because you also cant use it, because miners dont care about it
5802015-10-02T22:19:41 <BlueMatt> so its also a chicken-and-egg problem
5812015-10-02T22:20:03 <BlueMatt> of course the real solution is rbf, but...well, people are against that for political reasons
5822015-10-02T22:20:25 <dgenr8> if fee(12) and fee(24) were equal, should txes expire at 12?
5832015-10-02T22:20:34 <BlueMatt> ?
5842015-10-02T22:20:41 <dgenr8> see #'s above
5852015-10-02T22:21:08 <jgarzik> no it's not quite chichen-and-egg. users are incentivized against it because long chains of unconfirmed transactions do not work well in the bitcoin system. that's not specific to CPFP but relevant to evaluating CPFP.
5862015-10-02T22:21:17 <dgenr8> if they were equal, that amount gets you confirmed in 12 and nothing happens for the next 12 blocks
5872015-10-02T22:21:24 *** PaulCapestany has quit IRC
5882015-10-02T22:21:33 <BlueMatt> jgarzik: indeed, hence why we need RBF :p
5892015-10-02T22:21:49 <jgarzik> BlueMatt, so you agree CPFP is mostly useless? :)
5902015-10-02T22:21:56 <BlueMatt> no, i dont agree its mostly useless
5912015-10-02T22:22:07 <jgarzik> it's a miner "nice to have, in the rare occasions the code is triggered"
5922015-10-02T22:22:09 <BlueMatt> its the next-best thing when people are against rbf for bullshit reasons
5932015-10-02T22:22:19 <BlueMatt> its useful for the system as a whole
5942015-10-02T22:22:22 <BlueMatt> very useful
5952015-10-02T22:22:25 <BlueMatt> its just not as nice as rbf
5962015-10-02T22:22:41 *** PaulCapestany has joined #bitcoin-core-dev
5972015-10-02T22:22:45 <dgenr8> RBF solves an important need. but that need is not more important than not destroying all confidence in 0conf
5982015-10-02T22:22:57 <BlueMatt> dgenr8: I think you're comparing different numbers? estimatefee 12 is in 12 blocks, no? not 12 hours?
5992015-10-02T22:23:03 <jgarzik> The businesses like Coinbase and Bitpay are fine with RBF -- if and only if there is a secure instant transaction tech in place
6002015-10-02T22:23:11 <dgenr8> yes, im talking about 12 blocks = 2 hours
6012015-10-02T22:23:19 <jgarzik> need a replacement first, hard requirement
6022015-10-02T22:23:26 <jgarzik> *zero conf replacement
6032015-10-02T22:23:41 <BlueMatt> the funny thing is rbf has almost zero effect on 0conf security
6042015-10-02T22:23:54 <BlueMatt> its so hilariously insecure already that adding rbf to the mix doesnt make it materially worse
6052015-10-02T22:23:58 *** wumpus has quit IRC
6062015-10-02T22:24:04 <jgarzik> It matters from a practical standpoint
6072015-10-02T22:24:09 <BlueMatt> people using 0confs today are doing so by betting most customers are not trying to rip them off
6082015-10-02T22:24:17 <BlueMatt> which works fine for many people who have lots of customers
6092015-10-02T22:24:30 <BlueMatt> and who do other kyc stuff
6102015-10-02T22:24:37 <BlueMatt> so, they can keep doing that
6112015-10-02T22:24:47 <BlueMatt> with or without rbf
6122015-10-02T22:25:15 <jgarzik> Outside the theoretical world, deploying full bore RBF is anti social to several existing payment flows at major businesses
6132015-10-02T22:25:18 <dgenr8> today, if you pay with a highly standard tx and miner respects first-seen, it's not that easy to get double-spent
6142015-10-02T22:25:23 <BlueMatt> in any case, this is my point - people object to rbf because, whatever, which means we need cpfp
6152015-10-02T22:25:35 <BlueMatt> jgarzik: how?!
6162015-10-02T22:25:49 <BlueMatt> dgenr8: not true
6172015-10-02T22:26:01 <jgarzik> Attacks become quite a bit easier
6182015-10-02T22:26:03 <dgenr8> ah you'll want to enter my "double-spend me" contest
6192015-10-02T22:26:05 <BlueMatt> dgenr8: also, the way "the big guys" are mostly doing it doesnt even check that miners have seen a tx
6202015-10-02T22:26:10 <BlueMatt> or that its not double spent anywhere
6212015-10-02T22:26:17 <jgarzik> There was an RBF attack spree the instant that Chinese pool turned it on
6222015-10-02T22:26:19 <BlueMatt> jgarzik: not really, actually
6232015-10-02T22:26:30 <BlueMatt> jgarzik: yea, because it was publicized
6242015-10-02T22:26:37 <jgarzik> ...thus reality != theory
6252015-10-02T22:26:47 <BlueMatt> so dont publicize it on reddit
6262015-10-02T22:26:54 <jgarzik> There is real end user negative impact
6272015-10-02T22:26:54 <BlueMatt> still, you're just proving my point - people reject to rbf, so we need cpfp
6282015-10-02T22:26:59 <jcorgan> guys, can you take it to #bitcoin-dev or #bitcoin?
6292015-10-02T22:27:08 <BlueMatt> because we need *something* for this usecase
6302015-10-02T22:27:29 <jgarzik> CPFP is harmless, so no NAK. Just will be rarely used feature.
6312015-10-02T22:27:44 <jgarzik> Similar to code miners should have that sweeps anyone-can-pay into their wallet.
6322015-10-02T22:27:54 <BlueMatt> then how do wallets who paid too little fee fix their stuck txn?
6332015-10-02T22:28:11 <dgenr8> i actually think mempool expiration at 2 hours is the solution to replacement
6342015-10-02T22:28:26 <jgarzik> Miners -should- be doing that, just like they -should- be deploying CPFP, a just-in-case capture. It won't be used much at all though.
6352015-10-02T22:29:04 <jgarzik> dgenr8, the lower the limit, the greater the traffic on the network
6362015-10-02T22:30:27 <dgenr8> depends on the numbers then
6372015-10-02T22:30:58 <jgarzik> yep, as with anything in life there is a zen balance to be achieved :)
6382015-10-02T22:32:31 *** d_t has quit IRC
6392015-10-02T22:32:58 <morcos> ahh i go away for 30 mins
6402015-10-02T22:33:10 <morcos> you guys are touching on this, but its a very important point
6412015-10-02T22:33:17 <morcos> we're conflating two completely different things
6422015-10-02T22:33:35 <morcos> CPFP as a user action for helping a stuck tx is completely separate from CPFP as a mining algo
6432015-10-02T22:33:40 <morcos> i couldn't care less about the first
6442015-10-02T22:33:51 <morcos> but the second is just properly maximizing miner income
6452015-10-02T22:34:00 <morcos> its very important that core includes a good algorithm for that
6462015-10-02T22:34:23 <morcos> otherwise big miners that have the money and talent to do their own custom mining algos will have a significant advantag over small miners
6472015-10-02T22:34:32 <BlueMatt> jeff's point is that it really doesnt matter today (go ask big miners - they dont care about fees, really)
6482015-10-02T22:34:35 <morcos> its another example of where the default has to be really close enough to optimal
6492015-10-02T22:34:42 <BlueMatt> however, if you have users using it for stuck txn, then it does matter
6502015-10-02T22:34:52 <btcdrak> this really is a discussion for #bitcoin-dev or #bitcoin
6512015-10-02T22:35:25 <morcos> this is exactly a discussion for core-dev we're trying to figure out how important it is to include CPFP in core's mining algo
6522015-10-02T22:36:15 <BlueMatt> the big miners I've heard from dont care about fees, and are perfectly willing to forgo them to make bitcoin work properly for users - if users' wallets are using cpfp to unstick transactions, then it becomes required for bitcoin to work properly for users
6532015-10-02T22:36:43 <btcdrak> CPFP is incredibly inefficient compared to RBF
6542015-10-02T22:36:52 <Luke-Jr> is someone going to rewrite CPFP?
6552015-10-02T22:36:56 <BlueMatt> indeed, but there are many rejections to rbf
6562015-10-02T22:36:58 <morcos> btcdrak: exactly we're not talking about CPFP for users
6572015-10-02T22:37:04 <Luke-Jr> btcdrak: they're not competitive, they solve different problems
6582015-10-02T22:37:09 <BlueMatt> Luke-Jr: i dont think anyone has signed up to do so, yet
6592015-10-02T22:37:18 <BlueMatt> Luke-Jr: it requires adding more mempool tracking
6602015-10-02T22:37:23 * Luke-Jr not entirely sure why his CPFP was closed then.
6612015-10-02T22:37:29 <BlueMatt> but it should all be inverse duplication of whats already there
6622015-10-02T22:37:30 <morcos> sdaftuar and i are rewriting mining to be more optimal (which includes tracking ancestor package fee rates)
6632015-10-02T22:37:38 <BlueMatt> Luke-Jr: the way to do it is to do ancestor package tracking
6642015-10-02T22:37:41 <BlueMatt> ahh, ok, good
6652015-10-02T22:37:42 <morcos> i'm going to stop calling it CPFP so poeple don't think i'm talking about adding a user feature
6662015-10-02T22:38:02 <Luke-Jr> CPFP is what it's always been called, and doesn't imply anything like user features..
6672015-10-02T22:38:02 <BlueMatt> morcos: please make sure to fix https://github.com/bitcoin/bitcoin/issues/6531 when you do
6682015-10-02T22:38:28 <btcdrak> how is CPFP not a user feature?
6692015-10-02T22:38:43 <BlueMatt> btcdrak: its both a user feature and a miner feature, is the point
6702015-10-02T22:38:54 <Luke-Jr> morcos: if you're going to work on this stuff, it'd be nice to avoid the centralised policy problem we have now before it gets too deep ;)
6712015-10-02T22:39:10 <Luke-Jr> btcdrak: users don't care *how* their transactions get confirmed
6722015-10-02T22:39:16 <morcos> BlueMatt: i think that should be doable
6732015-10-02T22:39:36 <BlueMatt> morcos: its easy, just not done yet
6742015-10-02T22:39:47 <morcos> Luke-Jr: i'm thinking that the policy is adjusted by using your priorizeTransaction functionality
6752015-10-02T22:39:57 <Luke-Jr> morcos: that is not sufficient/reasonable.
6762015-10-02T22:40:08 <morcos> ha, well thats hard enough on its own
6772015-10-02T22:40:13 <morcos> why is that not sufficient
6782015-10-02T22:40:34 <btcdrak> OT: curious, who here, other than jgarzik and dgen8 are opposed to RBF?
6792015-10-02T22:40:52 <morcos> btcdrak: heh, and i get yelled at. :)
6802015-10-02T22:40:55 <Luke-Jr> because then people need to figure out how to translate their policy into relationship with the default policy
6812015-10-02T22:41:37 <Luke-Jr> it's already hard enough to implement policies; forcing people to implement *and* translate is even more work
6822015-10-02T22:42:04 <btcdrak> morcos: if you cant beat them, join them? :-P
6832015-10-02T22:42:06 <Luke-Jr> the goal is to make policy changes *easier*, not harder
6842015-10-02T22:42:10 <morcos> ok, i think its worth me learning more about that, so maybe i'll ping you next week to try to learn a bit more about what policies look like
6852015-10-02T22:43:23 <morcos> BlueMatt: to your point about miners not caring, i agree maybe the urgency isn't there at this exact second
6862015-10-02T22:43:57 <morcos> but it could be important soon, and we shouldn't fall behind the curve
6872015-10-02T22:44:14 <morcos> anyway, i really have to run now... good night!
6882015-10-02T22:44:26 <btcdrak> I mean, especially now that f2pool has RBF there's no reason we shouldnt add it to core
6892015-10-02T22:44:39 <btcdrak> FSS-RBF at the very least..
6902015-10-02T22:45:38 <Luke-Jr> frankly there was never a reason not to
6912015-10-02T22:46:16 <BlueMatt> morcos: sure
6922015-10-02T22:46:57 <Luke-Jr> other than perhaps encouraging miners not to use Core's policy code.. but that's a failure so far
6932015-10-02T22:47:56 <btcdrak> The funny thing is the clutching onto insecure 0conf will go away when we have real instant paynebt via payment channels/LN
6942015-10-02T22:48:06 <BlueMatt> btcdrak: yupp
6952015-10-02T22:48:11 <BlueMatt> we're all looking forward to that :)
6962015-10-02T22:48:22 <btcdrak> :)
6972015-10-02T22:48:25 <Luke-Jr> btcdrak: well, that's not really relevant to merge-or-not, since miners can run RBF whether it's in Core or not
6982015-10-02T22:49:03 <BlueMatt> does eligius still do rbf?
6992015-10-02T22:49:25 <btcdrak> Luke-Jr: right, but I mean the people who are objecting on the grounds of 0conf lose their basis
7002015-10-02T22:50:45 <phantomcircuit> jgarzik, it's the businesses responsibility to ensure that users are credit worthy if they are accepting unconfirmed transactions
7012015-10-02T22:50:59 <dgenr8> btcdrak: do you need to replace your tx like, pronto? can you wait 2 hours?
7022015-10-02T22:51:25 <phantomcircuit> jgarzik, realistically they cannot rely on unconfirmed transactions to confirm when it is in the financial best interest of miners to run full replace by fee
7032015-10-02T22:51:54 <phantomcircuit> jgarzik, long term it's going to do much more harm to them if we even try to make it less dangerous
7042015-10-02T22:56:41 <btcdrak> dgenr8: think about fee bumps
7052015-10-02T22:57:39 <dgenr8> btcdrak: yes, i'm asking how high-frequency fee-bumps need to be
7062015-10-02T22:58:49 <phantomcircuit> jgarzik, also there is CPFP traffic on mainnet today
7072015-10-02T23:01:56 <phantomcircuit> it's in the Schildbach wallet
7082015-10-02T23:03:35 <BlueMatt> oh really?
7092015-10-02T23:03:37 <BlueMatt> heh, thats cool
7102015-10-02T23:05:20 <phantomcircuit> BlueMatt, it basically is useless though because miners aren't running cpfp
7112015-10-02T23:05:36 <phantomcircuit> Luke-Jr, is eligius running cpfp?
7122015-10-02T23:07:20 <BlueMatt> phantomcircuit: indeed
7132015-10-02T23:07:29 <BlueMatt> cool that its deployed though, thats pretty awesome
7142015-10-02T23:11:03 <Luke-Jr> yes, Eligius has been CPFP since like 2011 or 2012
7152015-10-02T23:11:23 <Luke-Jr> which also means unless it gets updated for 0.12, we're going to have to stick to 0.11 ..
7162015-10-02T23:13:55 <BlueMatt> I'm sure there will be a patch to do it on 0.12, even if not merged
7172015-10-02T23:18:01 *** d_t has joined #bitcoin-core-dev
7182015-10-02T23:22:16 *** randy-waterhouse has quit IRC
7192015-10-02T23:43:27 *** BananaLotus has joined #bitcoin-core-dev