--- Day changed Fri Oct 02 2015
00:04 -!- mode/#bitcoin-core-dev [-b *!supybot@2400:8900::f03c:91ff:fedf:3a06] by wumpus
00:04 -!- mode/#bitcoin-core-dev [-b *!lightningb@cerulean.erisian.com.au] by wumpus
00:04 -!- mode/#bitcoin-core-dev [-b *!~supybot@cerulean.erisian.com.au] by wumpus
00:05 -!- mode/#bitcoin-core-dev [-b *!~supybot@cerulean.erisian.com.au] by wumpus
00:05 -!- mode/#bitcoin-core-dev [-b *!~supybot@cerulean.erisian.com.au] by wumpus
00:05 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ
00:08 < wumpus> <phantomcircuit> is there a reason that ARM is the fastest travis build? <- yes a) no GUI b) doesn't run tests
00:08 < Luke-Jr> eh, why no GUI?
00:09 < Luke-Jr> I just figured it was because it ran first :P
00:09 < CodeShark> how can I run the same tests travis runs locally?
00:09 < Luke-Jr> wumpus: is there a reason for unbanning lightningbot?
00:10 < wumpus> Luke-Jr: something with depends, building Qt was somewhat tricky on ARM
00:10 < wumpus> CodeShark: qa/pulltester/rpc-tests.py
00:10 < wumpus> Luke-Jr: it's the logging bot
00:11 < Luke-Jr> oh
00:12 < CodeShark> thanks, wumpus
00:12 < Luke-Jr> wumpus: btw, I believe 5574 and 6349 are good to go
00:15 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
00:16 < aj> wumpus: this time for sure :-/
00:18 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:18 < aj> wumpus: logs are backfilled from my scrollback too fwiw
00:24 -!- gmaxwell is now known as gmaxwell_
00:24 -!- gmaxwell_ is now known as gregorymaxwell
00:25 -!- gregorymaxwell is now known as gmaxweii
00:25 -!- gmaxweii is now known as gmaxwelI
00:25 -!- gmaxwelI is now known as gmaxwelIl
00:26 -!- BlueMatt is now known as gmaxweII
00:26 -!- gmaxweII is now known as BlueMatt
00:26 < BlueMatt> lol, you reg'd gmaxweII???
00:26 < midnightmagic> lotta scammers.
00:29 < wumpus> where bitcoin developers do their ritual tribal name-swapping dance
00:30 < CodeShark> hmm, when I run the tests locally it succeeds - but travis is choking
00:32 < BlueMatt> oh, I love those ones :(
00:32 < 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.
00:32  * BlueMatt misses when he ran the tester, then I could ssh in and figure it all out :)
00:32 < 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
00:32 < 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.
00:33 < 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." 
00:34 < jonasschnelli> BlueMatt: an additional CI is still possible. Maybe no github auto-comment feature. I think some people run it.
00:34 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
00:34 < 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
00:35 < jonasschnelli> Ah.. I see. :-)
00:37 < Luke-Jr> https://github.com/bitcoin/bips/pull/210
00:41 < CodeShark> is there anything else I can do to diagnose the travis test failure issue?
00:41 < wumpus> CodeShark: travis servers tend to be very busy, this has, for me at least, triggered race conditions that wouldn't appear locally
00:41 < CodeShark> so what's the workaround?
00:42 < BlueMatt> load your workstation a ton before running locally?
00:42 < CodeShark> lol
00:42 < BlueMatt> also run tests on a workstation with like 20 cores?
00:42 < wumpus> run your tests while running a parallel a build of bitcoin core with gccin the background?
00:43 < wumpus> that will help to fill up memory as well as cores :-)
00:43 -!- gmaxwelIl is now known as gmawell
00:43 < BlueMatt> wumpus: yea, if only my workstation would actually fill up its cores running "make -j"
00:43 < BlueMatt> but, it doesnt :(
00:43 < BlueMatt> damn 40 threads
00:43 < wumpus> BlueMatt: if X is high enough (though it will probabl yfill up memory first)
00:43 < BlueMatt> wumpus: no, not "make -jX", "make -j"
00:43 < BlueMatt> as in, run it ALL at once
00:44 < 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
00:44 < CodeShark> are you saying the race conditions are in Bitcoin Core? or in the travis environment?
00:44 < wumpus> BlueMatt: ooh I didn't know that one
00:44 < wumpus> CodeShark: in your code change, usually
00:44 < CodeShark> I didn't touch any threading stuff whatsoever
00:44 < BlueMatt> CodeShark: time to dust off the cpu miner!
00:45 < wumpus> CodeShark: where is it failing btw?
00:45 < 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
00:45 < CodeShark> https://travis-ci.org/bitcoin/bitcoin/jobs/83252957
00:46 < CodeShark> oh, hmm Coinbase script size out of range
00:47 < wumpus> ah it fails in the block tester
00:47 < CodeShark> yeah - how can I reproduce that locally?
00:48  * wumpus did it in the past but doesn't know by heart
00:49 < wumpus> also don't see it in travis.yml at all, it just does 'make check' then the rpc-tests.sh script
00:49 < wumpus> but it's there somewhere!
00:49 < BlueMatt> its in ./configure
00:49 < BlueMatt> --with-comparison-tool=....
00:49 < BlueMatt> or so
00:49 < BlueMatt> then make check runs it
00:49 < BlueMatt> the ... being the path to the jar
00:50 < CodeShark> oh, I need to install java? :)
00:50 < CodeShark> lol
00:50 < BlueMatt> yes
00:50 < wumpus> ahh, yes I think in the case of travis it's being installed as part of depends, then configure picks it up automatically 
00:52 < 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
00:53 < wumpus> we should add some documentation for this at some point
00:54 < wumpus> how to run the python tests is pretty well documented, but this isn't
00:54 < CodeShark> for the block tester, is it using real blocks on mainnet? or is it mining something?
00:54 < wumpus> regtest IIRC
00:54 < CodeShark> hmm...seems related to BIP34
00:55 < CodeShark> just a guess :)
00:55 < wumpus> I think it was the original motivation for regtest even
00:57 < CodeShark> ok, fine...installing jre...
00:57 < CodeShark> lol
01:01 < CodeShark> where can I grab the jar file?
01:02 -!- n0n0_ [~n0n0@x5f768399.dyn.telefonica.de] has joined #bitcoin-core-dev
01:02 < CodeShark> meh...I'll install the jdk as well
01:03 < CodeShark> where's the java source located?
01:07 < wumpus> it's part of bitcoinj *however* that may not be the newest version, the person to ask would be cfields
01:07 < BlueMatt> the bitcoinj one is +/- the latest
01:09 < wumpus> https://github.com/theuni/bitcoind-comparisontool  does he have any information there?
01:09 < CodeShark> I found the source - but I suppose I need to install the library as well and all that
01:09 < CodeShark> it's been ages since I touched java
01:10 < BlueMatt> you can grab the binary from the above repo
01:10 < wumpus> building it yourself is probably not worth it, unless you want to work on it, and fathom learning java build systems and such 
01:11 < CodeShark> the 8c666 jar?
01:11 < wumpus> that's the one referred to in depends/packages/native_comparisontool.mk
01:13 < CodeShark> ok, test is running (crossing fingers)
01:14 < CodeShark> alright, successfully reproduced the error :)
01:14 < wumpus> phew, good
01:25 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
01:25 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
01:26 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
01:26 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Client Quit]
01:27 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
01:28 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Client Quit]
01:28 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
01:29 -!- Cocodude [~marc@109.169.23.186] has left #bitcoin-core-dev []
01:30 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Client Quit]
01:31 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
01:32 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Client Quit]
01:32 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
01:33 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Client Quit]
01:36 -!- TZander is now known as zander
01:36 -!- zander is now known as thomasz
01:37 -!- thomasz is now known as TZander
01:52 -!- BashCo [BashCo@gateway/vpn/mullvad/x-ccghkttnialgfzps] has joined #bitcoin-core-dev
01:53 < BlueMatt> sdaftuar/morcos: great call on switching to calling RemoveStaged after each loop iteration instead of at the end
01:53 < BlueMatt> resulted in removing more than a third of the lines of code in TrimToSize!
01:53 < BlueMatt> and the mempool is no longer sorted based on max(tx-feerate-with-descendants, tx-feerate), but instead only tx-feerate-with-descendants :)
01:54 < BlueMatt> the heart of mempool limiting in 6722 is now 55 LOC :)
01:56 < gmawell> BlueMatt: that sounds fantastic.
02:00 < gmawell> FWIW: re current malleability event, https://bitcointalk.org/index.php?topic=1198032.msg12579271#msg12579271
02:02 < BlueMatt> hah
02:10 < BlueMatt> ok, that shit was bugging me, now its 50 :)
02:14 -!- warren_2 [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev
02:15 -!- Apocalyptic_ [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev
02:17 -!- TZander [~quassel@kde/zander] has quit [Disconnected by services]
02:17 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 250 seconds]
02:17 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 250 seconds]
02:17 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Ping timeout: 250 seconds]
02:17 -!- Apocalyptic_ is now known as Apocalyptic
02:17 -!- warren_2 is now known as warren
02:23 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev
02:38 -!- tripleslash_e [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
02:38 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 268 seconds]
03:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev
03: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
04:10 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Quit: quit]
04:14 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
04:16 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Remote host closed the connection]
04:20 -!- midnightmagic [~midnightm@S0106001d7d131fa4.gv.shawcable.net] has joined #bitcoin-core-dev
04:20 -!- midnightmagic is now known as Guest73782
04:22 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
04:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev
04:44 -!- Guest73782 [~midnightm@S0106001d7d131fa4.gv.shawcable.net] has quit [Quit: leaving]
04:46 -!- ParadoxSpiral [~ParadoxSp@p508B968D.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
05:11 -!- midnightmagic_ [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
05:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds]
05:41 -!- midnightmagic_ is now known as midnightmagic
05:58 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Remote host closed the connection]
05:59 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
06:05 -!- BashCo [BashCo@gateway/vpn/mullvad/x-ccghkttnialgfzps] has quit [Changing host]
06:05 -!- BashCo [BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:05 -!- BashCo [BashCo@unaffiliated/bashco] has quit [Changing host]
06:05 -!- BashCo [BashCo@gateway/vpn/mullvad/x-ccghkttnialgfzps] has joined #bitcoin-core-dev
06:06 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:09 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 246 seconds]
06:10 -!- BashCo [BashCo@gateway/vpn/mullvad/x-ccghkttnialgfzps] has quit [Ping timeout: 268 seconds]
06:29 < btcdrak> Luke-Jr: gmaxwell: I asked coinkite to change their blog post
06:40 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Remote host closed the connection]
06:43 < sdaftuar> ;
06:46 < 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.
06:55 < 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
06:56 < 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)
06:58 < 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:
06:59 < 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
06:59 < 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)
07:11 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-core-dev
07:13 -!- BashCo [BashCo@gateway/vpn/mullvad/x-mowsxzakybqyrozm] has joined #bitcoin-core-dev
07:16 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]
07:38 < morcos> BlueMatt: your change to use only package fee rate and not max: any reasoning behind that?
07:39 < 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.
07:39 < morcos> but it certainly changes behavior.
07:44 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
07:57 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev
08:05 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:16 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev
08:35 -!- zveda [~zveda@unaffiliated/zveda] has joined #bitcoin-core-dev
08:35 -!- zveda [~zveda@unaffiliated/zveda] has left #bitcoin-core-dev ["Ex-Chat"]
08:38 -!- fkhan [weechat@gateway/vpn/mullvad/x-jfozayxakgwlhkes] has quit [K-Lined]
08:51 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Ping timeout: 256 seconds]
08:52 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
09:04 -!- BashCo [BashCo@gateway/vpn/mullvad/x-mowsxzakybqyrozm] has quit [Ping timeout: 265 seconds]
09:07 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:10 -!- n0n0__ [~n0n0@x4d0665f2.dyn.telefonica.de] has joined #bitcoin-core-dev
09:13 -!- n0n0_ [~n0n0@x5f768399.dyn.telefonica.de] has quit [Ping timeout: 255 seconds]
09:15 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev
09:18 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Remote host closed the connection]
09:46 -!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-core-dev
09:49 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
09:50 < cfields> jonasschnelli: sorry i missed your question yesterday, i didn't realize my irc client had shut down. It did seem unusually quiet, though :)
09:50 < cfields> Missed the meeting too :\
09:52 < 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
09:53 < 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
09:53 < wumpus> "i didn't realize my irc client had shut down" hehe that has happened to me too
09:53 < wumpus> nice cfields!
09:54 < wumpus> any problems with libevent? or just with our code structure?
09:55 < cfields> wumpus: nah, no problems. Just lots of sudden "oh, so that's how that works. well shit." moments
10:08 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:14 -!- adam3us [~Adium@195.138.228.14] has joined #bitcoin-core-dev
10:29 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 256 seconds]
10:31 < 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
10:40 < cfields> CodeShark: great, thanks
10:40 -!- CoinMuncher1 [~jannes@ip54544d54.adsl-surfen.hetnet.nl] has joined #bitcoin-core-dev
10:43 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Ping timeout: 250 seconds]
10:44 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-core-dev
10:45 -!- CoinMuncher1 [~jannes@ip54544d54.adsl-surfen.hetnet.nl] has quit [Ping timeout: 246 seconds]
10:51 < jgarzik> cfields, feel free to ask questions
10:52 < 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).
10:55 < btcdrak> ping maaku
10:59 < maaku> yes?
11:00 < btcdrak> maaku: sdaftuar was asking if there was a resolution to this http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009344.html
11:01 < jgarzik> cfields, management of the active set should be the same across current code and new libevent code
11:01 < sdaftuar> maaku: yeah i was just wondering if there was an open pull to implement your solution in that thread?
11:06 < maaku> sdaftuar: #6312 does not suffer that issue
11:07 < maaku> most significant bit determines whether relative lock-time semantics are used
11:10 < CodeShark> maaku: you still don't have a PR for the actual soft forks, just the mempool stuff, right?
11:11 < 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?
11:13 < CodeShark> I wanted to ask you about the trigger mechanisms when you have a moment
11:13 -!- DocHex [~DocHex@193.28.228.45] has left #bitcoin-core-dev []
11:15 < btcdrak> CodeShark: there wont be softforking PRs until this gets merged
11:19 < btcdrak> sdaftuar: should be this https://github.com/maaku/bips/blob/bip68/bip-0068.mediawiki
11:20 < sdaftuar> btcdrak: that differs from https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
11:21 < btcdrak> oh i see, typo.
11:21 < btcdrak> well /master/ is the right one
11:23 -!- zooko [~user@172.56.8.138] has joined #bitcoin-core-dev
11:28 < morcos> btcdrak: typo?  its just different text, oh you mean typo on the link?
11:29 < btcdrak> yeah the link is to brancn bip68 rather than master branch, ping @maaku
11:31 < morcos> what's the right way to leave feedback on the bip text
11:31 < morcos> the terminology "reduced by 2^14" was confusing to me, also there are small typos
11:32 < morcos> open an issue?
11:32 -!- ParadoxSpiral_ [~ParadoxSp@p508B990D.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:33 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
11:35 -!- ParadoxSpiral [~ParadoxSp@p508B968D.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
11:39 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
11:41 < btcdrak> Open a PR directly
11:42 < btcdrak> or if you dont have time PM me the issues and I'll make a PR quickly
11:44 < 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
11:51 < btcdrak> ty
12:08 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
12:41 < btcdrak> does anyone know which block BIP66 enforced on specifically?
12:41 < CodeShark> I think 358806 
12:43 < CodeShark> it's probably something really stupid - according to the cli, it's still activating the best chain when it runs
12:54 -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 244 seconds]
12:54 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
12:55 < maaku> sdaftuar: it's a one-line fix to make the CLTV soft-fork do 68, 112, and 113 as well
12:57 < btcdrak> maaku, we need to bump transaction version to 2 also right?
13:02 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
13:02 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
13:12 < BlueMatt> morcos: the reasoning was its not no longer useful to do so
13:12 < BlueMatt> (and simplicity is better)
13:15 < BlueMatt> sdaftuar: hmmmmmm, yeaaaaa
13:15 -!- bitdevsnyc [bitdevsnyc@gateway/vpn/mullvad/x-ulegvlrolsrjkfmw] has joined #bitcoin-core-dev
13:16 -!- zooko [~user@172.56.8.138] has quit [Ping timeout: 246 seconds]
13:19 < BlueMatt> sdaftuar: yay more loc removal :)
13:20 < jgarzik> maaku, oh?  (RE one-line)
13:20 < 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
13:21 < morcos> so would you really want to boot A from your mempool?  it might be the most expensive immediately minable tx in there?
13:22 < 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
13:22 < morcos> its not clear to me that max is better, but its a difference worth considering.
13:22 < maaku> the pull requests for 68, 112, and 113 are specifically coded to support the same soft-fork rollout as cltv
13:23 < 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
13:23 < BlueMatt> ok, TrimToSize is now 10 LOC
13:23 < morcos> for instance do we know there are no txs which would fail?
13:23 < morcos> well not none, but you know what i mean, they aren't being regularly generateed
13:24 < 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
13:24 < maaku> morcos: why would we?
13:25 < morcos> or at least have it in master for a while before releasing a soft fork with it
13:25 < morcos> why would we what?
13:25 < maaku> what would be the reason to have them in master as mempool only?
13:26 < maaku> for some period of time that is, it obviously makes sense to break up the PRs that way
13:26 < morcos> so they get a lot more real world testing
13:27 < BlueMatt> morcos: hmmm...how did I convince myself that it was never used? :/
13:27 < BlueMatt> (anymore)
13:27 < 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
13:27 < 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
13:27 < morcos> 1) is a good point, i hadn't though tabout that
13:28 < morcos> thats not to say i would NACK it, not at all, just i'd depend on other people being really comfortable with it
13:28 < 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
13:29 < maaku> morcos: maybe there's a reason to have it tested as mempool-only. but i'd like to actually see a test plan.
13:29 < 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.
13:30 < 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.
13:31 < morcos> btcdrak: yes agreed, see my prior mesg
13:32 < BlueMatt> morcos: well its obviously non-optimal in the case you just proposed
13:33 < BlueMatt> welll, maybe not
13:33 < BlueMatt> so I'm gonna leave it in
13:33 < morcos> BlueMatt: leave what in?
13:34 < BlueMatt> hmm, I dunno, so the metric I was targeting (which it seems we can hit) is to optimize average feerate in mempool
13:34 < morcos> I'd vote for reverting it to max, but I can't make a concrete argument thats better.
13:34 < 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
13:34 < 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
13:34 < morcos> BlueMatt: I don't think you should be worrying about optimizing for that metric.  Worry about attacks and not doing anything stupid.
13:35 < BlueMatt> suresure
13:35 < 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
13:36 < BlueMatt> in the above case, using a max() will result in a larger mempool with lower feerate
13:36 < BlueMatt> which I kinda like
13:36 < BlueMatt> so, yea, I'd prefer leaving it in
13:36 < BlueMatt> (I already pushed that, anyway)
13:36 < sdaftuar> maaku: i've been reviewing #6312, and one thing jumps out at me
13:37 < jgarzik> What are good pre-reqs for time based limiting?  bluematt's stuff 
13:37 < sdaftuar> i don't understand how we're using the new LockTime() function in ContextualCheckBlock
13:37 < jgarzik> ?
13:37 < sdaftuar> pcoinsTip isn't being updated between transactions in the caller
13:37 < 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?
13:38 < 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
13:38 < maaku> sdaftuar: in that case it isn't being called with pcoinsTip, it is using the block validation view
13:38 < maaku> the consensus code doesn't use pcoinsTip
13:39 < sdaftuar> ContextualCheckBlock() does, right?
13:39 < morcos> jgarzik: i didn't understand your question.  i think BlueMatt is adding time based expiration similar to sipa's commit from 6557 right?
13:41 < maaku> sdaftuar: you are correct. hrm. working around sipa's nits broke that
13:41 < 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.
13:41 < maaku> (prior versions would skip inputs that weren't found)
13:42 < jgarzik> ditto
13:42 < jgarzik> morcos, BlueMatt: I thought time-based was "later" but may have misunderstood.
13:44 < sdaftuar> i don't think skipping would be safe either, would it?
13:44 < sdaftuar> you might have a transaction that can't be spent until a block after its parent...
13:44 < sdaftuar> i'm not sure but i don't believe that ConnectBlock redoes the LockTime() tests (?)
13:45 < 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.
13:46 < BlueMatt> morcos: I was figuring I'd just leave the timeout-ing to right afterwards, and adding multiple txn in one step, too
13:46 < BlueMatt> so....go review?
13:46 < BlueMatt> all thats left that I know of is writing tests
13:46 < BlueMatt> it may be very broken right now and I wouldnt know it
13:47 < 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
13:47 < morcos> i commented on the pull about that earlier
13:48 < morcos> i say just add the Expire() commit, its short and simple and basically stands alone
13:48 < jgarzik> BlueMatt, +1   :)
13:48 < morcos> and i think it really helps to reason about how the whole mempool is kept limited
13:49 < 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)
13:49 < sdaftuar> wow that is way shorter code 
13:49 < maaku> sdaftuar: I'm investigating -- that was my memory that ConnectBlock redoes the LockTime() tests with context
13:50 < maaku> but I'm having trouble finding it
13:51 < 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.
13:51 < maaku> jgarzik: yes that's the driving purpose
13:52 < 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.
13:52 < btcdrak> jgarzik: yup.
13:52 < gmawell> jgarzik: of course, as its just a script opcode. :)
13:52 < morcos> maaku: interpreter.cpp calls CheckLockTime
13:52 < gmawell> if () {lock1 condition} elsif () {lock2 condition2} ....
13:53 < jgarzik> CLTV can do this alone, yes?
13:53 < morcos> EvalScript I should say
13:53 < jgarzik> It appears so.
13:53 < maaku> morcos: different CheckLockTime (ugh, sorry about that)
13:53 < maaku> the interpreter.cpp one is a method of SignatureChecker
13:53 < morcos> oh yeah of course, thats horrible
13:54 < maaku> yeah didn't even notice until now
13:55 -!- gmawell is now known as gmaxwell
13:55  * btcdrak just had a cup of coffee
13:56 < btcdrak> *gmaxwell
13:59 < BlueMatt> morcos: it stands well alone is exactly why it should be its own pr :p
13:59 < morcos> BlueMatt: i regreted that choice of words before I hit Enter
13:59 < BlueMatt> :)
13:59 < BlueMatt> morcos: yes, but the earlier comment was "the 9 is wrong"
14:00 < BlueMatt> not what it should be
14:00 < morcos> i think its supposed to be 3 * the number of indices
14:00 < BlueMatt> so the 9 should be 3
14:00 < morcos> so 6
14:00 < BlueMatt> and then its fine?
14:00 < BlueMatt> oh, wait, what
14:00 < morcos> no
14:00 < morcos> unfortunately sdaftuar and i broke it in master already
14:00 < BlueMatt> the 9 should be 6 and then its fine?
14:00 < morcos> DynamicMemoryUsage is 9 (and hsould be 6) in master
14:01 < BlueMatt> who's code is it anyway? (tm)
14:01 < sdaftuar> was my fault :)
14:01 < morcos> GuessDynamicMemoryUSage is new and should be the same as master
14:01 < morcos> sorry
14:01 < morcos> same as DynamicMemoryUsage
14:01 < BlueMatt> ahh, ok
14:01 < BlueMatt> I'll go fix both, then
14:01 < morcos> so both should be 6 unless you add expiration
14:01 < morcos> which is what you should do
14:01 < morcos> so then they should both be 9
14:01 < BlueMatt> I'll just do 6 and let you add expiration :)
14:02 < morcos> (if i remain silent does it cause you to reconsider?)
14:03 < BlueMatt> heh
14:03 < BlueMatt> I'm gonna go rebase the whole pr
14:03 < morcos> +!
14:03 < morcos> 1
14:14 < phantomcircuit> sipa, what ever happened to the normalized transaction id stuff?
14:17 < 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
14:17 < morcos> for CSV, the BIP seems to be describing an earlier version?
14:18 -!- belcher_ [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:19 < morcos> where is the most up to date version of BIP-112?
14:21 < btcdrak> morcos, the BIP text needs updating, let me push that
14:21 < btcdrak> (for 112)
14:23 < 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
14:24 -!- n0n0__ [~n0n0@x4d0665f2.dyn.telefonica.de] has quit [Ping timeout: 256 seconds]
14:25 < btcdrak> BIP68 was ironed out exactly that way. BIP112 just needs tweaking because of the references to BIP68.
14:26 < morcos> ok fair enough
14:28 < maaku> sorry btcdrak had authored new text for BIP 112. I didn't realize it hadn't been pushed
14:36 < morcos> maaku: oh i didn't realize the name conflict on CheckLockTime goes away with CSV, that's good
14:37 < morcos> oh spoke too soon, sorry
14:49 < BlueMatt> morcos/jgarzik/sdafutar: ok, pushed a new version of #6722
14:49 < BlueMatt> because expiry is so simple I went ahead and merged that
14:49 < BlueMatt> I also squashed everything into reasonably reviewable bites
14:50 < jgarzik> BlueMatt, does expiry occur even if mempool is not full?
14:50 < BlueMatt> yes
14:50 < jgarzik> good
14:51 < morcos> BlueMatt: great!  just in time for me to call it a week however.  will review asap
14:51 < morcos> why'd you make it 72 hours though
14:51 < morcos> way too small
14:52 < BlueMatt> because we dont have large-scale cpfp deployed by miners :(
14:52 < morcos> if blocks are on average 90% full, then a 300MB mempool could last most of a week
14:52 < BlueMatt> and the mempool limiting stuff assumes that
14:52 < morcos> ah
14:52 < morcos> ok will review with that in mind
14:55 < jgarzik> BlueMatt, with 10,000 txs in mempool, what is the expense of Expire() + TrimToSize() for each new tx?  (wall clock time /cpu cycles)
15:00 < 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
15:00 < morcos> the slow stuff is already merged which is calculating the descendant packages
15:00 < 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
15:00 < morcos> it wouldn't be a bad idea to measure it again now 
15:00 < 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...
15:01 < morcos> but the real question is yep, exactly, edge cases
15:01 < morcos> so its more about thinking of whats the worst case we can encounter
15:01 < BlueMatt> if you have a bunch of tiny packages, then its just n, which isnt so bad
15:01 < BlueMatt> if you have very large packages, then n is 1
15:01 < BlueMatt> the worst-case, really, is a large single txn comes in to replace a single package which has a TON of tiny txn
15:02 < morcos> no i meant like the attack scenarios we were describing
15:03 < morcos> shoot, i forgot i was supposed to draft an email to dev about reduced package sizes
15:03 < jgarzik> expiry can also create orphans
15:03 < morcos> CalculateDescendants makes sure all the descendants are found and also removed
15:05 < dgenr8> expiring at 2 hours, and happily relying on replacement to bump fees is an interesting strategy
15:07 < jgarzik> I think 2 hours is way too short for expiry
15:09 < BlueMatt> honestly I think it should be closer to 12/24 with the current mempool limiting stuff
15:09  * dgenr8 good to look at the latest fee estimates
15:10 < jgarzik> 48 hours is my pref
15:10 < BlueMatt> jgarzik: you forget the mempool limiting stuff assumes cpfp
15:10 < BlueMatt> and miners dont have it
15:10 < BlueMatt> so anything that is in mempool because of cpfp is essentially there until it times out
15:10 < jgarzik> miners run big mempools anyway
15:10 < BlueMatt> that is irrelevant
15:11 < jgarzik> few use CPFP or descendents at all
15:11 < BlueMatt> yes, thats my point
15:11 < jgarzik> zero conf security actively incentives against it
15:11 < jgarzik> & malleation
15:12 < BlueMatt> what???
15:12 < BlueMatt> as a miner, its clearly in your best interest to use cpfp
15:13 < BlueMatt> there just isnt code to do so, so most dont
15:13 < BlueMatt> well, not merged code, at least
15:13 < BlueMatt> ie well-reviewed code
15:13 < dgenr8> estimatefee 12 = 0.00008634; estimatefee 24 = 0.00006981
15:13 < jgarzik> BlueMatt, think from the user PoV
15:14 < 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
15:14 < BlueMatt> so they hold these txn only because of cpfp and will hold them until they expire
15:14 < BlueMatt> hence why a low expiry time makes sense
15:14 < jgarzik> BlueMatt, in practice there are few descendents and malleation attacks make them even less likely
15:14 < BlueMatt> what does this have to do with miners?
15:14 < BlueMatt> yes, users dont use cpfp
15:14 < BlueMatt> they should be using rbf
15:14 < jgarzik> thus miners don't use cpfp
15:15 < jgarzik> let's consider what -is- before -should be- :)
15:15 < BlueMatt> miners dont because its not much extra income and the patches arent well-reviewed, not because they actively choose not to
15:15 < BlueMatt> yes, thats what I'm saying.......
15:15 < BlueMatt> of course all the mempool stuff being written today is written assuming we do cpfp in mining soon
15:15 < 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)
15:15 < BlueMatt> which we should
15:15 < BlueMatt> there is some, however
15:16 < BlueMatt> and thus they should be using it
15:16 < BlueMatt> in *any* case, writing a cpfp-included mining thing based on mempool tracking will make mining a TON more efficient in any case
15:16 < BlueMatt> so we should do that
15:17 < 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.
15:18 < BlueMatt> we need to rewrite the mining stuff anyway
15:18 < 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.
15:18 < BlueMatt> because it sucks
15:18 < BlueMatt> including cpfp in that is the logical decision
15:19 < jgarzik> Including rarely used features isn't necessarily logical.
15:19 < BlueMatt> in any case, this is way off topic from the original discussion - the mempool expiry time
15:19 < BlueMatt> rarely used because you also cant use it, because miners dont care about it
15:19 < BlueMatt> so its also a chicken-and-egg problem
15:20 < BlueMatt> of course the real solution is rbf, but...well, people are against that for political reasons
15:20 < dgenr8> if fee(12) and fee(24) were equal, should txes expire at 12?
15:20 < BlueMatt> ?
15:20 < dgenr8> see #'s above
15:21 < 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.
15:21 < dgenr8> if they were equal, that amount gets you confirmed in 12 and nothing happens for the next 12 blocks
15:21 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
15:21 < BlueMatt> jgarzik: indeed, hence why we need RBF :p
15:21 < jgarzik> BlueMatt, so you agree CPFP is mostly useless?  :)
15:21 < BlueMatt> no, i dont agree its mostly useless
15:22 < jgarzik> it's a miner "nice to have, in the rare occasions the code is triggered"
15:22 < BlueMatt> its the next-best thing when people are against rbf for bullshit reasons
15:22 < BlueMatt> its useful for the system as a whole
15:22 < BlueMatt> very useful
15:22 < BlueMatt> its just not as nice as rbf
15:22 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
15:22 < dgenr8> RBF solves an important need.  but that need is not more important than not destroying all confidence in 0conf
15:22 < BlueMatt> dgenr8: I think you're comparing different numbers? estimatefee 12 is in 12 blocks, no? not 12 hours?
15:23 < jgarzik> The businesses like Coinbase and Bitpay are fine with RBF -- if and only if there is a secure instant transaction tech in place
15:23 < dgenr8> yes, im talking about 12 blocks = 2 hours
15:23 < jgarzik> need a replacement first, hard requirement
15:23 < jgarzik> *zero conf replacement
15:23 < BlueMatt> the funny thing is rbf has almost zero effect on 0conf security
15:23 < BlueMatt> its so hilariously insecure already that adding rbf to the mix doesnt make it materially worse
15:23 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 268 seconds]
15:24 < jgarzik> It matters from a practical standpoint
15:24 < BlueMatt> people using 0confs today are doing so by betting most customers are not trying to rip them off
15:24 < BlueMatt> which works fine for many people who have lots of customers
15:24 < BlueMatt> and who do other kyc stuff
15:24 < BlueMatt> so, they can keep doing that
15:24 < BlueMatt> with or without rbf
15:25 < jgarzik> Outside the theoretical world, deploying full bore RBF is anti social to several existing payment flows at major businesses
15:25 < dgenr8> today, if you pay with a highly standard tx and miner respects first-seen, it's not that easy to get double-spent
15:25 < BlueMatt> in any case, this is my point - people object to rbf because, whatever, which means we need cpfp
15:25 < BlueMatt> jgarzik: how?!
15:25 < BlueMatt> dgenr8: not true
15:26 < jgarzik> Attacks become quite a bit easier
15:26 < dgenr8> ah you'll want to enter my "double-spend me" contest
15:26 < BlueMatt> dgenr8: also, the way "the big guys" are mostly doing it doesnt even check that miners have seen a tx
15:26 < BlueMatt> or that its not double spent anywhere
15:26 < jgarzik> There was an RBF attack spree the instant that Chinese pool turned it on
15:26 < BlueMatt> jgarzik: not really, actually
15:26 < BlueMatt> jgarzik: yea, because it was publicized
15:26 < jgarzik> ...thus reality != theory
15:26 < BlueMatt> so dont publicize it on reddit
15:26 < jgarzik> There is real end user negative impact
15:26 < BlueMatt> still, you're just proving my point - people reject to rbf, so we need cpfp
15:26 < jcorgan> guys, can you take it to #bitcoin-dev or #bitcoin?
15:27 < BlueMatt> because we need *something* for this usecase
15:27 < jgarzik> CPFP is harmless, so no NAK.  Just will be rarely used feature.
15:27 < jgarzik> Similar to code miners should have that sweeps anyone-can-pay into their wallet.
15:27 < BlueMatt> then how do wallets who paid too little fee fix their stuck txn?
15:28 < dgenr8> i actually think mempool expiration at 2 hours is the solution to replacement
15:28 < 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.
15:29 < jgarzik> dgenr8, the lower the limit, the greater the traffic on the network
15:30 < dgenr8> depends on the numbers then
15:30 < jgarzik> yep, as with anything in life there is a zen balance to be achieved :)
15:32 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:32 < morcos> ahh i go away for 30 mins
15:33 < morcos> you guys are touching on this, but its a very important point
15:33 < morcos> we're conflating two completely different things
15:33 < morcos> CPFP as a user action for helping a stuck tx is completely separate from CPFP as a mining algo
15:33 < morcos> i couldn't care less about the first
15:33 < morcos> but the second is just properly maximizing miner income
15:34 < morcos> its very important that core includes a good algorithm for that
15:34 < 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
15:34 < BlueMatt> jeff's point is that it really doesnt matter today (go ask big miners - they dont care about fees, really)
15:34 < morcos> its another example of where the default has to be really close enough to optimal
15:34 < BlueMatt> however, if you have users using it for stuck txn, then it does matter
15:34 < btcdrak> this really is a discussion for #bitcoin-dev or #bitcoin
15:35 < 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
15:36 < 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
15:36 < btcdrak> CPFP is incredibly inefficient compared to RBF
15:36 < Luke-Jr> is someone going to rewrite CPFP?
15:36 < BlueMatt> indeed, but there are many rejections to rbf
15:36 < morcos> btcdrak: exactly we're not talking about CPFP for users
15:37 < Luke-Jr> btcdrak: they're not competitive, they solve different problems
15:37 < BlueMatt> Luke-Jr: i dont think anyone has signed up to do so, yet
15:37 < BlueMatt> Luke-Jr: it requires adding more mempool tracking
15:37  * Luke-Jr not entirely sure why his CPFP was closed then.
15:37 < BlueMatt> but it should all be inverse duplication of whats already there
15:37 < morcos> sdaftuar and i are rewriting mining to be more optimal (which includes tracking ancestor package fee rates)
15:37 < BlueMatt> Luke-Jr: the way to do it is to do ancestor package tracking
15:37 < BlueMatt> ahh, ok, good
15:37 < morcos> i'm going to stop calling it CPFP so poeple don't think i'm talking about adding a user feature
15:38 < BlueMatt> morcos: please make sure to fix https://github.com/bitcoin/bitcoin/issues/6531 when you do
15:38 < Luke-Jr> CPFP is what it's always been called, and doesn't imply anything like user features..
15:38 < btcdrak> how is CPFP not a user feature?
15:38 < BlueMatt> btcdrak: its both a user feature and a miner feature, is the point
15:38 < 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 ;)
15:39 < Luke-Jr> btcdrak: users don't care *how* their transactions get confirmed
15:39 < morcos> BlueMatt: i think that should be doable
15:39 < BlueMatt> morcos: its easy, just not done yet
15:39 < morcos> Luke-Jr: i'm thinking that the policy is adjusted by using your priorizeTransaction functionality
15:39 < Luke-Jr> morcos: that is not sufficient/reasonable.
15:40 < morcos> ha, well thats hard enough on its own
15:40 < morcos> why is that not sufficient
15:40 < btcdrak> OT: curious, who here, other than jgarzik and dgen8 are opposed to RBF?
15:40 < morcos> btcdrak: heh, and i get yelled at.  :)
15:40 < Luke-Jr> because then people need to figure out how to translate their policy into relationship with the default policy
15:41 < Luke-Jr> it's already hard enough to implement policies; forcing people to implement *and* translate is even more work
15:42 < btcdrak> morcos: if you cant beat them, join them? :-P
15:42 < Luke-Jr> the goal is to make policy changes *easier*, not harder
15:42 < 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
15:43 < morcos> BlueMatt: to your point about miners not caring, i agree maybe the urgency isn't there at this exact second 
15:43 < morcos> but it could be important soon, and we shouldn't fall behind the curve
15:44 < morcos> anyway, i really have to run now...  good night!
15:44 < btcdrak> I mean, especially now that f2pool has RBF there's no reason we shouldnt add it to core
15:44 < btcdrak> FSS-RBF at the very least..
15:45 < Luke-Jr> frankly there was never a reason not to
15:46 < BlueMatt> morcos: sure
15:46 < Luke-Jr> other than perhaps encouraging miners not to use Core's policy code.. but that's a failure so far
15:47 < btcdrak> The funny thing is the clutching onto insecure 0conf will go away when we have real instant paynebt via payment channels/LN
15:48 < BlueMatt> btcdrak: yupp
15:48 < BlueMatt> we're all looking forward to that :)
15:48 < btcdrak> :)
15:48 < 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
15:49 < BlueMatt> does eligius still do rbf?
15:49 < btcdrak> Luke-Jr: right, but I mean the people who are objecting on the grounds of 0conf lose their basis
15:50 < phantomcircuit> jgarzik, it's the businesses responsibility to ensure that users are credit worthy if they are accepting unconfirmed transactions
15:50 < dgenr8> btcdrak: do you need to replace your tx like, pronto?  can you wait 2 hours?
15:51 < 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
15:51 < phantomcircuit> jgarzik, long term it's going to do much more harm to them if we even try to make it less dangerous
15:56 < btcdrak> dgenr8: think about fee bumps
15:57 < dgenr8> btcdrak: yes, i'm asking how high-frequency fee-bumps need to be
15:58 < phantomcircuit> jgarzik, also there is CPFP traffic on mainnet today
16:01 < phantomcircuit> it's in the Schildbach wallet
16:03 < BlueMatt> oh really?
16:03 < BlueMatt> heh, thats cool
16:05 < phantomcircuit> BlueMatt, it basically is useless though because miners aren't running cpfp
16:05 < phantomcircuit> Luke-Jr, is eligius running cpfp?
16:07 < BlueMatt> phantomcircuit: indeed
16:07 < BlueMatt> cool that its deployed though, thats pretty awesome
16:11 < Luke-Jr> yes, Eligius has been CPFP since like 2011 or 2012
16:11 < Luke-Jr> which also means unless it gets updated for 0.12, we're going to have to stick to 0.11 ..
16:13 < BlueMatt> I'm sure there will be a patch to do it on 0.12, even if not merged
16:18 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:22 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
16:43 -!- BananaLotus [~BananaLot@club.maza.club] has joined #bitcoin-core-dev
17:20 < phantomcircuit> maaku, there's a typo in BIP 68 "block-heigh" -> "block-height"
17:21 < maaku> phantomcircuit: thank you will correct
17:22 < phantomcircuit> maaku, also "the remaining bits reduced by 2^14" does that mean the remaining 30 bits - 2^14 ?
17:22 < maaku> it means ">> 14"
17:22 < maaku> have a better way of phrasing that?
17:22 < maaku> you're the 2nd person to comment on it
17:23 < jgarzik> Writing it as pseudo-C code may be more clear.
17:24 < phantomcircuit> maaku, wouldn't that be the same as simply saying "the next 16 bits are interpreted as"
17:25 < maaku> phantomcircuit: yeah that's pretty clear. I'll do that
17:25 < maaku> the normative C code is included below it
17:25 < phantomcircuit> i assume you're not using the full range of 30 bits such as to preserve the most bits possible as undefined meaning?
17:25 < maaku> *C++
17:25 < maaku> phantomcircuit: correct
17:26 < phantomcircuit> probably want to note that explicitly, otherwise the format is super confusing
17:26 < phantomcircuit> (as in appears to make no sense :)
17:27 < maaku> right ok
17:33 < phantomcircuit> maaku, OP_CHECKLOCKTIMEVERIFY is in master currently for mempool checking right?
17:34 < maaku> phantomcircuit: mempool-only CLTV is in master, yes
17:58 -!- challisto [~dell@76.16.149.33] has quit [Remote host closed the connection]
18:23 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:45 -!- zooko [~user@2600:100e:b02c:327:4491:4416:b461:1e4e] has joined #bitcoin-core-dev
18:51 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:12 < phantomcircuit> BlueMatt, still working on the mempool limiter?
19:12 < BlueMatt> no, please review
19:12 < BlueMatt> I mean yes, needs unit tests
19:12 < BlueMatt> but please review
19:17 < phantomcircuit> lol
19:26 -!- zooko` [~user@172.56.9.217] has joined #bitcoin-core-dev
19:28 -!- zooko [~user@2600:100e:b02c:327:4491:4416:b461:1e4e] has quit [Ping timeout: 240 seconds]
19:36 -!- challisto [~dell@c-76-16-149-33.hsd1.il.comcast.net] has joined #bitcoin-core-dev
19:53 -!- challisto [~dell@c-76-16-149-33.hsd1.il.comcast.net] has quit [Changing host]
19:53 -!- challisto [~dell@unaffiliated/challisto] has joined #bitcoin-core-dev
19:53 -!- challisto [~dell@unaffiliated/challisto] has quit [Quit: Leaving]
19:55 -!- challisto [~dell@unaffiliated/challisto] has joined #bitcoin-core-dev
20:03 -!- challisto [~dell@unaffiliated/challisto] has quit [Quit: Leaving]
20:12 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev
20:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev
20:25 -!- belcher_ [~user@unaffiliated/belcher] has quit [Quit: Leaving]
20:40 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:33 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:42 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:43 -!- zooko` [~user@172.56.9.217] has quit [Ping timeout: 256 seconds]
21:49 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
21:51 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds]
21:55 -!- ehenri [~ehenri@c-68-49-47-249.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
22:00 -!- ehenri [~ehenri@c-68-49-47-249.hsd1.mi.comcast.net] has quit [Quit: Leaving]
23:41 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 255 seconds]