--- Day changed Thu Mar 31 2016 00:21 -!- abritoid [~abritoid@46.16.193.99] has joined #bitcoin-core-dev 00:22 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 00:38 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 248 seconds] 00:39 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev 00:43 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 00:52 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection] 01:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 01:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 01:07 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 01:16 < wumpus> We're destroying the future utility by producing false positives now. <- exactly 01:16 < wumpus> that's why I said "in any case let's say that if we can unequivocably decide that 7568 is an improvement that makes it worth keeping the system in the next 24 hours then we'll merge and backport that, otherwise we'll disable it in 0.12 for now" ... we should consider the utility now, even if that temporarily means disabling it 01:19 < wumpus> anyhow let's discuss at the meeting 01:20 -!- Bootvis [bob@baltar.lan.endoria.net] has quit [Remote host closed the connection] 01:24 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 01:27 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds] 01:39 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 01:51 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 01:52 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:53 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 248 seconds] 01:55 < GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8a8f3d4b22b...16555b658f5b 01:55 < GitHub33> bitcoin/master fb8a8cf Wladimir J. van der Laan: rpc: Register calls where they are defined... 01:55 < GitHub33> bitcoin/master 16555b6 Wladimir J. van der Laan: Merge #7766: rpc: Register calls where they are defined... 01:55 < GitHub45> [bitcoin] laanwj closed pull request #7766: rpc: Register calls where they are defined (master...2016_03_separate_rpc_registration) https://github.com/bitcoin/bitcoin/pull/7766 01:56 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 02:08 < GitHub195> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/16555b658f5b...7c80e720402d 02:08 < GitHub195> bitcoin/master 40234ba BtcDrak: Fix comments in tests 02:08 < GitHub195> bitcoin/master 7c80e72 Wladimir J. van der Laan: Merge #7773: Fix comments in tests... 02:08 < GitHub51> [bitcoin] laanwj closed pull request #7773: Fix comments in tests (master...csv-comments) https://github.com/bitcoin/bitcoin/pull/7773 02:16 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 02:19 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Ping timeout: 244 seconds] 02:40 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 02:47 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 268 seconds] 02:55 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 03:09 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 03:12 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 244 seconds] 03:23 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has left #bitcoin-core-dev [] 03:43 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 03:49 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 268 seconds] 04:22 -!- gijensen [~gijensen@gijensen.xyz] has quit [Ping timeout: 244 seconds] 04:22 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 244 seconds] 04:22 -!- p15 [~p15@33.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 244 seconds] 04:22 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds] 04:22 -!- Squidicc [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Ping timeout: 244 seconds] 04:22 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev 04:23 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 04:23 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev 04:25 < GitHub59> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c80e720402d...3081fb9a3105 04:25 < GitHub59> bitcoin/master eff736e Pieter Wuille: Reformat version in UpdateTip and other messages... 04:25 < GitHub59> bitcoin/master 3081fb9 Wladimir J. van der Laan: Merge #7763: Put hex-encoded version in UpdateTip... 04:25 < GitHub95> [bitcoin] laanwj closed pull request #7763: Put hex-encoded version in UpdateTip (master...hexver) https://github.com/bitcoin/bitcoin/pull/7763 04:25 < GitHub99> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3081fb9a3105...209dbeb05f88 04:25 < GitHub99> bitcoin/master 3e55b3a accraze: [doc] added depends cross compile info 04:25 < GitHub99> bitcoin/master 209dbeb Wladimir J. van der Laan: Merge #7747: [docs] added depends cross compile info... 04:26 < GitHub89> [bitcoin] laanwj closed pull request #7747: [docs] added depends cross compile info (master...depends-build-docs) https://github.com/bitcoin/bitcoin/pull/7747 04:27 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds] 04:33 -!- cryptapus [~cyptapus@87.254.202.184] has joined #bitcoin-core-dev 04:33 -!- cryptapus [~cyptapus@87.254.202.184] has quit [Changing host] 04:33 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:45 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 04:49 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 248 seconds] 04:50 < GitHub59> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/4d035bcc9aa3388dc7f37cf81451e55f0b6270ee 04:50 < GitHub59> bitcoin/0.12 4d035bc accraze: [doc] added depends cross compile info... 04:57 -!- chris2000 [~chris2000@customer-static-225-38.wobline-ip.de] has joined #bitcoin-core-dev 05:14 < GitHub125> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/209dbeb05f88...63832688939f 05:14 < GitHub125> bitcoin/master ae2156f Pavel Janík: Clear the input line after activating autocomplete 05:14 < GitHub125> bitcoin/master 6383268 Jonas Schnelli: Merge #7772: Clear the input line after activating autocomplete... 05:14 < GitHub14> [bitcoin] jonasschnelli closed pull request #7772: Clear the input line after activating autocomplete (master...20160330_completer_clean_input_line) https://github.com/bitcoin/bitcoin/pull/7772 05:29 < GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/63832688939f...28ad4d9fc2be 05:29 < GitHub124> bitcoin/master 72fd008 Daniel Kraft: Fix quoting of copyright holders in configure.ac.... 05:29 < GitHub124> bitcoin/master 28ad4d9 Wladimir J. van der Laan: Merge #7477: Fix quoting of copyright holders in configure.ac.... 05:29 < GitHub97> [bitcoin] laanwj closed pull request #7477: Fix quoting of copyright holders in configure.ac. (master...configure-quoting) https://github.com/bitcoin/bitcoin/pull/7477 05:45 < GitHub199> [bitcoin] laanwj closed pull request #7511: [WIP] New ax_pthread.m4 from upstream - draft 3 (not final), for testing on all platforms (master...20160211_WIP_test_new_ax_pthread) https://github.com/bitcoin/bitcoin/pull/7511 05:46 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 05:50 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 248 seconds] 05:56 < GitHub104> [bitcoin] laanwj opened pull request #7776: build: Remove unnecessary executables from gitian release (master...2016_03_gitian_release_cleanup) https://github.com/bitcoin/bitcoin/pull/7776 06:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 06:29 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev 06:36 < GitHub57> [bitcoin] jtimon closed pull request #7731: Discussion: By "more precision", I don't mean using rational numbers in CFeeRate (master...0.12.99-feerate) https://github.com/bitcoin/bitcoin/pull/7731 06:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:43 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev 06:46 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 06:51 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 244 seconds] 06:57 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev 07:01 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds] 07:20 < GitHub142> [bitcoin] laanwj pushed 5 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/c251f46bea8f...ecaa178a235a 07:20 < GitHub25> [bitcoin] laanwj closed pull request #7743: [0.11] Important backports for 0.11.3 (updated to v0.12.0) (0.11...backports-for-0.11.3) https://github.com/bitcoin/bitcoin/pull/7743 07:20 < GitHub142> bitcoin/0.11 90de0e1 Cory Fields: build: Split hardening/fPIE options out... 07:20 < GitHub142> bitcoin/0.11 5c0b357 Cory Fields: build: Use fPIC rather than fPIE for qt objects.... 07:20 < GitHub142> bitcoin/0.11 d626faa Luke Dashjr: Merge commit '5c0b357' into backports-for-0.11.3 07:31 -!- trippysalmon [~trippy@cyberdynesys.org] has joined #bitcoin-core-dev 07:46 -!- zooko [~user@2601:281:8301:eb00:d486:faaf:68eb:6e0e] has joined #bitcoin-core-dev 07:46 < MarcoFalke> Anything holding back 7691? 08:17 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 08:22 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 252 seconds] 08:27 -!- zooko` [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev 08:29 -!- zooko [~user@2601:281:8301:eb00:d486:faaf:68eb:6e0e] has quit [Ping timeout: 268 seconds] 08:35 -!- abritoid [~abritoid@46.16.193.99] has quit [Quit: Zzz…] 09:00 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev 09:04 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds] 09:06 -!- chris2000 [~chris2000@customer-static-225-38.wobline-ip.de] has quit [] 09:09 -!- zooko` [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds] 09:10 -!- Bootvis [bob@baltar.lan.endoria.net] has joined #bitcoin-core-dev 09:13 -!- Don_John [~Don@248-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev 09:21 < sdaftuar> wumpus: can you explain the infinite loop in EncodeDecimal that #7751 addressed? 09:22 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has joined #bitcoin-core-dev 09:27 < morcos> wumpus: in particular, encoding amounts as strings for json now make it so that current rpc tests can't be run against pre 0.12 binaries 09:28 < morcos> we discovered this when sdaftuar couldn't reproduce the same testing of the CSV soft fork backport I and btcdrak did without removing all the calls to Decimal 09:28 < morcos> Also it would make it hard to use our rpc tests to test against other implementations which might not handle JSON numbers as strings since thats not really proper json 09:29 < morcos> it seems better if our rpc tests dont' encode them that way? 09:35 -!- abritoid [~abritoid@62.44.101.70] has joined #bitcoin-core-dev 09:35 -!- abritoid [~abritoid@62.44.101.70] has quit [Client Quit] 09:37 < GitHub136> [bitcoin] MarcoFalke opened pull request #7778: [qa] Bug fixes and refactor (master...Mf1604-qaFixesRefactor) https://github.com/bitcoin/bitcoin/pull/7778 09:47 -!- zooko [~user@50.141.119.31] has joined #bitcoin-core-dev 09:51 < GitHub176> [bitcoin] MarcoFalke closed pull request #7722: [qa] Refactor python2 syntax (master...Mf1603-qaPy2/3) https://github.com/bitcoin/bitcoin/pull/7722 09:52 -!- zooko` [~user@2601:281:8001:26aa:d486:faaf:68eb:6e0e] has joined #bitcoin-core-dev 09:53 -!- zooko [~user@50.141.119.31] has quit [Ping timeout: 244 seconds] 09:54 < GitHub32> [bitcoin] jtimon opened pull request #7779: Discussion: Consensus: There's only one type of consensus flags (master...0.12.99-consensus-unify-flags) https://github.com/bitcoin/bitcoin/pull/7779 10:02 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 10:10 < MarcoFalke> NicolasDorier, I can still see it 10:10 < MarcoFalke> + if (!CheckFinalTx(tx, flags) 10:11 < NicolasDorier> ?? one second 10:11 < NicolasDorier> https://usercontent.irccloud-cdn.com/file/R9q9fyfu/ 10:11 < NicolasDorier> I removed the flags 10:11 < NicolasDorier> and it compiles on travis 10:12 < NicolasDorier> MarcoFalke: you see the like with flags as "add" ? 10:13 < NicolasDorier> the line 10:13 < MarcoFalke> travis is all red 10:13 < MarcoFalke> check char 25 in this line 10:13 < NicolasDorier> nop, only two build which are red because I pushed too fast, if can again should work fine 10:14 < NicolasDorier> hu are we on same commit ? 10:14 < NicolasDorier> ad930cdab3b23801f8a415cc4e900a182a6f8bc6 ? 10:15 < wumpus> sdaftuar: in python 3.4, round(Decimal) no longer converts the decimal to a float 10:15 < MarcoFalke> git grep 'if (!CheckFinalTx(tx, flags)' 10:15 < wumpus> sdaftuar: so EncodeDecimal returns a (rounded) Decimal, which is again passed to EncodeDecimal 10:15 < MarcoFalke> on the commit you posted 10:15 < MarcoFalke> what is the result? 10:16 < NicolasDorier> ooooooh 10:16 < wumpus> sdaftuar: (e.g. if the 'default' function returns an object that is not json encodable, it will call the function on it, just as long as necessary) 10:16 < NicolasDorier> omg sorry, wtf did it compiled on several conf in travis and on my machine 10:16 < sdaftuar> wumpus: ah okay 10:16 < wumpus> sdaftuar: that shouldn't be backported to pre-0.12, no 10:17 < MarcoFalke> I think there is an issue with travis if you push faster than it can start the build. 10:17 < MarcoFalke> It will just compile the current ref instad of the commit you pushed 10:17 < wumpus> MarcoFalke: yes, it will try to fetch the pull then fails 10:17 < wumpus> oh okay 10:18 < wumpus> sdaftuar: you can still use the old authproxy.py if yo udon't care about python 3 compat 10:18 < sdaftuar> wumpus: right, yeah i figured out how to workaround the issue for now 10:18 < sdaftuar> wumpus: but i do wonder if the fix in master makes sense, we're outside the JSON spec when we deliver numeric values as strings, right? 10:18 < sdaftuar> i know bitcoind supports it 10:19 < NicolasDorier> MarcoFalke: Just repushed, sorry for the myopa :D 10:20 < MarcoFalke> np 10:20 -!- Tasoshi_ [~Tasoshi@unaffiliated/tasoshi] has joined #bitcoin-core-dev 10:22 -!- cguida [~chris@162.216.46.195] has quit [Quit: cguida] 10:23 -!- cguida [~chris@162.216.46.195] has joined #bitcoin-core-dev 10:24 < wumpus> sdaftuar: how is passing strings 'outside the json spec'? 10:24 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has quit [Ping timeout: 276 seconds] 10:24 < sdaftuar> for numeric values i mean 10:24 < wumpus> what it sends it 100% valid json 10:25 < wumpus> well the underlying problem is that python has no way to send-this-string-unquoted 10:25 < sdaftuar> hm, so i guess the rpc calls themselves now support numeric or string? i suppose that makes sense. 10:25 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 10:25 < wumpus> casting to float defeats the purpose of using decimal in the first place 10:25 < wumpus> so I think this is better 10:26 < wumpus> besides reimplementing the json module to support arbitrary number formats, like univalue 10:28 < wumpus> but yes the reason we implement strings for monetary values is that this is easier to use for software that uses decimals, no need to insert another type into the json stream just wrap it as string 10:29 < wumpus> indeed, this is implemented in AmountFromValue 10:30 < instagibbs> has anyone charted out the various major function calls for accepting/creating new blocks? I don't find the function call names very helpful :) 10:31 < instagibbs> and comments tend to have lingo I don't really grok 10:31 < wumpus> the doxygen docs have a call tree 10:31 < instagibbs> hmm ill check that 10:32 < morcos> sipa: gmaxwell: i was just trying to do a quick review of #7568 and i'm very confused 10:32 < wumpus> https://dev.visucore.com/bitcoin/doxygen/ 10:33 < instagibbs> yeah found it, thanks. Just need to find the "tip" of the flow I'm looking for now :) 10:33 < morcos> isn't it doomed to have way too many false positives due to its use of GetBlockTime(). I mean that could kind of be anything. 10:33 < morcos> We have to measure when the block was actually found, not the time on the block right? 10:33 < instagibbs> wumpus, oh this is actually really useful, it has callee & caller graph 10:34 < morcos> It's not clear to me that 7568 would meaningfully reduce the number of false positives, so i might now be leaning towards removal for 0.12.1, but i'd like to make sure i'm not missing something 10:42 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 10:49 < NicolasDorier> morcos: for #7574 you say it is premature to remove, why ? this code is not used at all anymore, why keeping it around ? 10:50 < morcos> NicolasDorier: We don't even know if these soft forks are going to activate. We should not lock ourselves into only using MTP for mempool acceptance until they do. 10:50 < NicolasDorier> so you mean in case we need to revert it would be easier ? 10:50 < morcos> I'd even argue that after they activate, its still better to preserve the ability to pass in different flags to the mempool. If for instance trying to analyze something that happend on the chain before the soft fork triggered, or starting a new chain where the fork hasn't triggered yet 10:51 < wumpus> I tend to agree it may be too early to remove it 10:51 < NicolasDorier> ok I close the pr for now or keep around ? 10:51 < wumpus> and for future softforks there may be other, new, flags to pass around 10:51 < morcos> I like #7779 as the right approach 10:51 < morcos> OR a step in the right direction 10:52 < NicolasDorier> ok let's do that then, I close the PR ? 10:52 < morcos> If you see in the segwit code I actually introduce some ways to accept non-standard stuff to the mempool (At least for testnet/regtest) 10:52 < morcos> I think that its better to abstract ways to do that for better testing 10:52 < morcos> That would be my recommendation (close the PR) 10:53 < NicolasDorier> ok did it 10:53 < wumpus> NicolasDorier: yes I think so, we can always bring it back when it's time 10:53 < morcos> NicolasDorier: I actually thought until today that we shouldn't even have the LOCKTIME_VERIFY_SEQUENCE flag at all 10:53 < GitHub28> [bitcoin] NicolasDorier closed pull request #7574: Remove STANDARD_LOCKTIME_VERIFY_FLAGS and mempool policy's flags (master...removeFlag) https://github.com/bitcoin/bitcoin/pull/7574 10:53 < NicolasDorier> morcos, I think there is case where we need it 10:53 < morcos> but now I think by my own argument we should have that, so that we have a way to specify for the mempool whether it should enforce that or not 10:53 < NicolasDorier> if the fork is not activated, the flag is off 10:54 < morcos> For consensus its not needed, because you can just check for the CSV soft fork activation and then not even call SequenceLocks if it isn't activated 10:54 < morcos> No reason to call it with no flag and have it just short circuit 10:55 < NicolasDorier> ah yes I see what you mean 10:55 < morcos> I think we properly abstract a set of rules and a way to determine whether they are active (and this can be consensus or standardness) its possible that just the flags bitfield is the right way to do this, i'm not sure 10:56 < morcos> It seems like what you really want is a way to do that for the mempool. What is active now 10:57 < morcos> For blocks you recreate that set of flags each block 10:57 < morcos> but for the mempool, you want to know what was active as of the last block 10:57 < morcos> maybe thats somethign we should just save as a global from connectBlock or maybe there is a better way 10:57 < wumpus> well not exactly that, I think 10:57 < wumpus> usually we start enforcing things for the mempool first 10:58 < morcos> wumpus: well you want AT LEAST that 10:58 < wumpus> I think for the mempool you want to do *everything* 10:58 < wumpus> there's generally no point in merging a softfork and not enforcing it for the mempool 10:58 < morcos> wumpus: I don't like it that in the mempool you are separately constructing that list of rules for the mempool via the STANDARD_FLAGS 10:59 < morcos> I think somehow you should have the STANDARD_FLAGS and the currently active consensus flags 10:59 < morcos> instead we have STANDARD_FLAGS and sort of original consensus flags 10:59 < wumpus> well sure, the standard flags need to be stricter than anything that is currently active 11:00 < wumpus> I'm sure that could be implemented with more clarity, but effectively I think it's doing the right thing. Standard has alwasy been "be as strict as possible, above and beyond what consensus requires" 11:00 < wumpus> there's nothing wrong with having a mechanism that checks and makes sure that that is the case, of course 11:01 < wumpus> another thing is that the rules for the mempool should be invariant over a run, otherwise there may be old transactions in the mempool from earlier (before catching up) before some new rules were added 11:02 < morcos> yeah i keep getting concerned around mempool issues during a soft fork activation 11:02 < morcos> but i don't think there are any current problems 11:03 < morcos> wumpus: did you see my prior comment on alert chain triggering. i'm not pro removal 11:03 < morcos> i'm NOW pro removal i mean 11:03 < morcos> bad-chain alert triggering, ugh, i can't type today 11:04 < wumpus> well as long as the mempool already enforces a rule *before* the softfork triggers, something we always make sure, there should be no problem 11:04 < wumpus> morcos: yes I saw, I think we should discuss it at the meeting but the prevailing sentiment seems to be to remove it for 0.12.1 11:06 < morcos> ok, i'll be back for that 11:12 < gmaxwell> morcos: Just comining into the discussion but we prefer a behavior change be throughly non-standard on the whole network before a soft-fork activates so that unupgraded software does not get itself orphaned. Generally a soft-fork should not be invalidating any transactions honest users are actually making. (MTP is special in my view because the 'invalidation' is merely a short delay, and there w 11:13 < gmaxwell> ere very few timelocked transactions being made) 11:13 < gmaxwell> and so since we'd want to make that transistion a version or two ahead, there really isn't a reason to make sure we re-filter the mempool. 11:19 < NicolasDorier> not enforcing a sf in mempool before activation may also be an attack. For example MTP, if it was not pushed in mempool for 0.11, when it would have been enforced by miners, someone can flood the network of old nodes by making replacement transaction whci never can confirm but can still be propagated. 11:20 < zooko`> The Zcash project has an issue ticket to track "hard-fork detection", which I currently think is the same thing or 11:20 < zooko`> at least closely related to the bad-chain-alert-triggering that you're talking about 11:20 < zooko`> disabling: https://github.com/zcash/zcash/issues/131#issuecomment-204063197 11:20 -!- zooko` is now known as zooko 11:21 < sipa> zooko: no, this is about partition detection; hard forks are much easier to detect: you see a longer but invalid chain 11:21 < zooko> sipa: oh, thanks. 11:21 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 11:22 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev 11:24 < sipa> morcos: see my comments on the PR 11:25 < sipa> morcos: i don't know what the reason is for the actual false firing we frequently see now 11:33 < sipa> morcos: i actually have no idea how much block timestamps are off 11:35 < gmaxwell> I doubt it's block timestamps. 11:36 < gmaxwell> one cause of false firing is correct but uninteresting firing. E.g. not enough blocks shows up on my laptop when I leave the office and go to dinner and such on the way home, then for the next week until I restart I'm left with this stupid not enough blocks warning. 11:37 < gmaxwell> It's unfortunate that this was constructed without a clear model of the kinds of true positives it was trying to detect. 11:37 < helo> should it be bother-until-dismissed? 11:39 < helo> in -qt, that is 11:39 < gmaxwell> thats obnoxious too, what is the threat you hope to solve by telling people their network connection _used_ to be down? 11:40 < gmaxwell> without an argument, that just sounds like another kind of false positive: we commanded the users attention where no action was actually required on their part. Creating more reason to ignore any further warnings. 11:47 < morcos> gmaxwell: i'm surprised you don't think its the block time stamps 11:47 < morcos> as soon as the current tip is over 130 mins old by its own time stamp, that'll cause an alert 11:48 < helo> potentially bad (but probably not) might warrant getting someone's attention... -paranoialevel=N 11:48 < morcos> that seems likely to happen, if say it was mined with a time an hour in the past and it was another 70 mins before the next block was found 11:48 < dgenr8> sipa: you can get a quick idea from tac debug.log | grep UpdateTip | awk '{printf("%s %s\n", $2, $10);} 11:50 < dgenr8> ' 11:56 < morcos> and even if that isn't the cause, it allows any miner to make a false alert more likely by just using an old timestamp 11:56 -!- kangx [42d7ee99@gateway/web/freenode/ip.66.215.238.153] has joined #bitcoin-core-dev 11:56 < sipa> in the short term i am mostly concernes with fixing the spurious alerts 11:56 < sipa> longer term, we should think hard about what the cases are to detect 11:57 < sipa> for example, if miners would intentionally keep timestamps low, isn't that something to alert about as well? 11:58 < jonasschnelli> Right? The meeting is now +1 on GMT? 11:58 < dgenr8> time warp 11:58 < wumpus> yes I think so 11:59 < wumpus> no, I mean meeting is +0 UTC, but that's now isn't it? 11:59 < Luke-Jr> ? 11:59 < Luke-Jr> my calendar says it should start right now 11:59 < paveljanik> yup 11:59 < petertodd> Luke-Jr: ack 11:59 < wumpus> meeting is in Reykjavik time, they don't have DST 11:59 < wumpus> #startmeeting 11:59 < lightningbot> Meeting started Thu Mar 31 18:59:45 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:59 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:00 < wumpus> action points from last meeting: ACTION: review more at https://github.com/bitcoin/bitcoin/pull/7648 (wumpus, 19:05:42) done and merged 12:00 < jonasschnelli> topic proposal (short): p2p layer encryption 12:00 < wumpus> ACTION: hunt down miners that mine MTP violations <- don't know about this one 12:00 < wumpus> main topic is the softfork backports I think 12:01 < sipa> topic: short update on segwit and segnet4 12:01 < wumpus> cool 12:01 < wumpus> #topic short update on segwit and segnet4 12:02 < cfields> topic suggestion: net-refactor update 12:02 < sipa> segwit code progressed a lot the past few days; it now passes all preexisting rpc tests and unit tests, and many bugs were fixed in the process 12:02 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 12:02 < jonasschnelli> Nice! 12:02 < wumpus> good to hear! 12:02 < petertodd> sipa: +1 12:03 < jonasschnelli> also had no crash on my segnet4 node.. :) 12:03 < sipa> it's also rebased on top of the bip68/112/113 backport, and a new segnet (segnet4) is up and running with bip9 activation logic 12:03 < gmaxwell> morcos: my uncertanty comes from looking at some incidents and it not being obvious what the cause was in them. 12:04 < gmaxwell> it's not well founded uncertanty. 12:04 < gmaxwell> oops. [sorry for OT] 12:04 < sipa> lastly, i have significantly reorganized the commits in the branch to 1) define segnet 2) add consensus/node logic 3) add wallet logic 4) add tests 12:04 < sipa> so that upgrade tests from pre-segwit code post fork can be tested 12:05 < sipa> and so that the consensus critical part can be reviewed separately 12:05 < morcos> sipa: i think it would be hugely beneficial if you could come up with a list of things you'd like other people to work on to move this forward 12:05 < sipa> ack, will do 12:05 < cfields> yes, that would be great 12:06 < petertodd> I should add segwit to python-bitcoinlib... 12:06 < sipa> the next thing i will do myself is write script unit tests, as we are not testing all possible witness validation failures 12:06 < gmaxwell> As far as the MTP huntdown, sdaftuar checked to see if there were violations already, and there weren't. I need to start generating mtp violating transactions, but haven't done this yet. 12:07 < petertodd> sipa: ah cool - are you going to do that with the existing script_(in)valid.json framework? 12:07 < sipa> there are some unusual things to test that are not typivally needed for softforks, such as the preferential peering (oh, that's implemented too; on top of the service bits enforcement logic), rewind testing, ... 12:07 < sipa> petertodd: yes 12:08 < btcdrak> #link https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwit 12:08 < wumpus> #action start generating mtp violating transactions (gmaxwell) 12:08 < petertodd> sipa: how are you going to add segwit support to it? (I was just updating python-bitcoinlib's script unit tests yesterday along those lines) 12:08 < sipa> petertodd: tbd, i'm sure i'll find a way 12:09 < sipa> but i haven't looked into it deeply 12:09 < sipa> EOT? (end of topic) 12:10 < sipa> btcdrak: no, use segwit-base...segwit 12:10 < sipa> (so you don't see the backports before segwit) 12:10 < wumpus> ok 12:11 < wumpus> #topic net-refactor update 12:11 < wumpus> @cfields 12:11 < cfields> ok. I've pushed an up-to-date version to my net-refactor10 branch... 12:12 < cfields> at this point, it's ready for testing and review, but i'm not entirely sure how to proceed 12:12 < wumpus> ohh I'm two branches behind 12:13 < wumpus> what is unclear? 12:13 < cfields> atm it's just 2 huge commits. I'm not sure how much it's worth going in and splitting into logical chunks, because it's really one big change... 12:13 < btcdrak> sipa: this then? https://github.com/sipa/bitcoin/compare/segwit-base...sipa:segwit 12:13 < sipa> btcdrak: ack 12:13 < wumpus> well if it is one big change it should be one commit 12:13 < wumpus> splitting makes sense if there are atomic changes 12:14 < wumpus> especially if they're somewhat independent 12:14 < cfields> also, it needs a bunch of unit tests, which I'm still working on a framework for. For catching stupid things like max connections, etc 12:15 < cfields> wumpus: sure. what I'm not clear on is if I should try to refactor current master to make it easier to slide in the other changes, or just plan to do it all in one go 12:15 < cfields> s/refactor/PR small refactoring chunks/ 12:15 < wumpus> I don't know. I'd try it first in one go, if people complain about it being to much you can always decide to do it in multiple phases. 12:16 < cfields> ok. Well, next steps are adding tons of docs and tests. But at this point, I'm happy to have people test and point out any brokenness 12:17 < wumpus> congrats :) 12:17 < cfields> I suppose that's it for now 12:18 < wumpus> unfortunately this comes at a time that people are really busy, so I hope they can spare enough review cycles, to get this in for 0.13 12:18 < cfields> wumpus: understood. I'm starting to doubt whether it makes sense for .13. 12:19 < sipa> when is the feature freeze for 0.13? 12:19 < wumpus> #topic softfork backports 12:19 < jonasschnelli> I have already started reviewing it but need to read myself more into libevent first. 12:19 < petertodd> cfields: well, keep in mind that what's keeping everyone busy is stuff that'll be backported 12:19 < jtimon> NicolasDorier: 12:19 < btcdrak> backports are #7543 and #7716 12:19 < cfields> jonasschnelli: for the sake of review, I'd say you can do it in 2 main chunks 12:19 < cfields> first, libbtcnet can be considered to be a black box that works as intended 12:19 < jtimon> what? it was a suggestion for extension, I think you got simplifications I missed' 12:19 < cfields> then, reviewing libbtcnet itself 12:20 < wumpus> sipa: 2016-05-15 https://github.com/bitcoin/bitcoin/issues/7679 12:20 < btcdrak> so #7543 is a straight up cherry-pick from master, easy peasy. 12:20 < btcdrak> #7716 needs a bit more review, but the tests, as per the comments make it quite easy to verify. 12:20 < sipa> i gave a command line for easy mechanical review of 7543 :) 12:20 < morcos> "easy" 12:21 < btcdrak> #7543 has 5 tested ACKs so far. It should be ready for merge. 12:21 < jtimon> NicolasDorier: seriously if someone else could do it I think we could be much more objective combined (I'm probably too biased with my consensus branch) 12:22 < phantomcircuit> cfields: link to current net refactor work? 12:22 < wumpus> agree on the 0.12 backport btcdrak 12:22 < cfields> phantomcircuit: https://github.com/theuni/bitcoin/tree/net-refactor10 12:22 < wumpus> #action #7543 has 5 tested ACKs so far. It should be ready for merge 12:23 < btcdrak> wumpus: I'll go round bugging more people for review of #7716 this week. 12:24 < morcos> I know this may be controversial, but I'd argue that it is worse to provide backports for 0.11 than not 12:24 < wumpus> #link https://github.com/theuni/bitcoin/tree/net-refactor10 12:24 < cfields> btcdrak: you bugged me last week but i didn't get to them. Will review both right after the meeting. 12:25 < wumpus> what would be the effect of not backporting to 0.11? 12:25 < morcos> It's very difficult to provide sufficient enough review. You could have backported those soft forks to 0.11 in a way that passed both the existing unit tests and was broken if you didn't know you needed to change both 12:25 < morcos> I think we are doing our "customers" a better service by not putting our stamp of approval on something we can't give as high a degree of safety to 12:25 < morcos> Just a though, given that segwit will also likely be difficult to get properly tested in 0.11 12:26 < gmaxwell> I've had this thought too. Unfortunately none of the users of these things will give us any feedback. 12:26 < petertodd> morcos: ack - and also, esp. from miners, do we have a clear request to do a backport? 12:26 < wumpus> do miners use 0.11? 12:26 < wumpus> if not, backporting softfork to 0.11 is not *that* important 12:27 < phantomcircuit> wumpus: miners use git master... 12:27 < morcos> This is an opensource project anyway, nothing stopping other people from backporting to 0.11 themselves 12:27 < wumpus> sure, but we have a PR open for 0.11 12:27 < morcos> We should concentrate our efforts where they will be most effective 12:27 < sdaftuar> hah - low probability of getting that right 12:27 < wumpus> people that want it can review it 12:27 < sdaftuar> but agree that it's difficult to review 12:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 12:27 < wumpus> if no one wants it, no one should review it 12:28 < wumpus> so the decision would be more 'backport to 0.11 should block 0.12 deployment' 12:28 < btcdrak> wumpus: I know of some miners who are still on 0.11.2 but plan to upgrade, but instead are waiting for 0.12.1 now. 12:28 < petertodd> how about we mention that we haven't done a backport in the release notes for 0.12.x, and make it clear that if people do what that they should let us know? 12:28 < morcos> wumpus: But what I'm saying is we seem to have set a requirement for ourselves that we will backport 2 major versions, and so we waste a lot of development resources doing that for a questionable quality product 12:28 < Luke-Jr> wumpus: yes, miners still use 0.11 12:28 < wumpus> morcos: well the plan was to release 0.11.3 and 0.12.1 at the same time 12:28 < Luke-Jr> wumpus: and that is likely to remain the case for some time 12:28 < wumpus> that means that 0.11.3 will block 0.12.1 12:29 < morcos> Yes thats what i'm objecting to! 12:29 < btcdrak> I disagree with morcos that 0.11 is so difficult. We do have a pretty decent set of functional tests, and the 0.11 backport passes those. 12:29 < jonasschnelli> cat dnsseed.dump | grep " 100.00% 100.00%" | grep "/Satoshi:0.11." | wc -l ---> 1581 12:29 < jonasschnelli> cat dnsseed.dump | grep " 100.00% 100.00%" | grep "/Satoshi:0.12." | wc -l --> 1276 12:29 < jonasschnelli> I think a BP for 0.11 would be good. 12:30 < wumpus> mind that 0.12 isn't very old yet, and it's still at .0, lots of people wait for .1 releases to deploy it 12:30 < morcos> btcdrak: i think the 0.11 backport is correct. but it would have been easy to get wrong and still could be 12:30 < btcdrak> morcos: so far 3 people have tested #7716. 12:30 < Luke-Jr> wumpus: it also has no well-tested CPFP yet ;) 12:30 < morcos> yes and 2 of them think it was a waste of time 12:31 < wumpus> so can we get people that use 0.11.x involved in testing it? 12:31 < btcdrak> For the record, I am fine not to backport to 0.11 12:31 < morcos> anyway, this is potentially off topic, but i think its more important that this project spend its resources getting segwit deployed 12:31 < wumpus> this is an open source project, so at some point it's scratch your own itch 12:31 < morcos> than deploying CSV to 0.11 12:31 < jonasschnelli> morcos : +1 12:31 < morcos> wumpus: sure, so lets not delay 0.12.1 12:31 < paveljanik> +1 12:31 < jl2012> Anyway, I think it's unlikely to backport segwit to 0.11, so I don't think we really need to backport CSV to 0.11 12:31 < btcdrak> +1 12:31 < morcos> jl2012: thanks 12:31 < wumpus> but what if bbackporting to 0.11.x helps segwit deployment, by making sure miners use it? 12:31 < gmaxwell> 0.11 is also so low in performance relative to 0.12 that there are many reasons not to run it. 12:31 < wumpus> ok 12:31 < btcdrak> please can we merge 7543 and start the RC phase. 12:31 < jonasschnelli> Agree with wumpus: 0.12 is relatively new. The time will also works towers 0.12 adaptation. 12:32 < jonasschnelli> towards 12:32 < morcos> btcdrak: well that brings us to next topic, bad-chain alerts 12:32 < Luke-Jr> it may be easier to get morcos's new CPFP stuff tested well 12:32 < gmaxwell> it is premature to RC on 0.12 at this second. (maybe in a couple days) 12:32 < wumpus> it'd be better if we would have first done a bugfix release for 0.12 12:32 < morcos> Luke-Jr: heh, thanks but sdaftuar's 12:32 < Luke-Jr> oh, oops 12:32 < btcdrak> morcos: this is my answer to back chain alerts for 0.12.1 https://github.com/bitcoin/bitcoin/compare/0.12...btcdrak:spurious 12:32 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 12:32 < wumpus> then again I know of no *serious* bugs in 0.12 12:32 < btcdrak> disable them for 0.12.1 and if we get them fixed, we can add back to 0.12.2 12:33 < wumpus> new topic bad chain alerts? 12:33 < morcos> btcdrak: i think i mostly agree with that 12:33 < wumpus> #topic bad chain alerts 12:34 < gmaxwell> is that bad "chain alerts" or "bad chain" alerts? :) 12:34 < jonasschnelli> second. 12:34 < wumpus> hehe both 12:34 < sipa> (bad ((bad chain) alerts)) 12:34 < gmaxwell> I think it's actually more the first. 12:34 < btcdrak> sipa: groan 12:34 < morcos> wumpus: i think the proper thing to do here is properly research what was causing the false positives. 12:34 < wumpus> so, disable for now, then try to fix in master, if that succeeds backport to 0.12.2? 12:35 < morcos> that would be my vote 12:35 < btcdrak> wumpus: +1 12:35 < gmaxwell> +1 12:35 < sdaftuar> ack 12:35 < gmaxwell> We urgently must stop the false positives or the facility becomes completely useless. 12:35 < wumpus> morcos: I agree, hurriedly backporting an improvement that isn't even merged in master yet is probably a bad idea 12:35 < morcos> wasn't MeniRosenfelds calculation that the existing code should be generating an alert once every 3 years, well i think something is off 12:35 < wumpus> gmaxwell: right 12:35 < gmaxwell> I think the work that Tom has done improving it is valuable and welcome, but clearly not enough yet. 12:36 < morcos> gmaxwell: or it might be enough, but we're not sure yet 12:36 < wumpus> gmaxwell: it makes sense to merge that for master 12:36 < sipa> morcos: under assumptions of constant hash rate,nodes that are up 100% of the time, and correct block timestamps 12:36 < petertodd> I recently spoke to a very confused user who thought the alerts meant bitcoin was fending off attack :/ 12:36 < sipa> morcos: if any of those assumptions are wrong, it will fail more 12:36 < wumpus> ah a bad-weather check that only works under good-weather conditions :) 12:36 < morcos> sipa: yes so we don't have a sense of what false positive rate we'll have with 7568 b/c those assumptions are still equally poorly met 12:37 < dgenr8> sipa: why do you think it will fail more? 12:37 < wumpus> petertodd: yes, it confuses users 12:37 < gmaxwell> dgenr8: fail more than meni's calculation. 12:37 < wumpus> petertodd: especially because the alert just won't go away 12:37 < morcos> dgenr8: i think its very likely that 7568 will fail less often than master, but maybe not rarely enough compared to just disabling 12:37 < morcos> and it obscures other alerts 12:37 < dgenr8> morcos: hard to argue with that ;) 12:38 < morcos> "maybe" :) 12:38 < gmaxwell> it will still falsely alert after a temporary disconnection, that alone shows its insufficent to avoid many of the reported FPs. 12:38 < dgenr8> bad weather check that never detects bad weather 12:38 < petertodd> wumpus: when we fix them, probably worthwhile to hide the alerts in the gui for the first release 12:38 < wumpus> #action disable bad-chain alert for 0.12.1 12:38 < sipa> dgenr8: anyway, i want to be clear here: i really think you changes should go in, but perhaps only once we're sure no further imorovements are needed to make them reliable 12:39 < wumpus> who's going to make a PR? 12:39 < morcos> yes i agree with sipa 12:39 < dgenr8> sipa: re your comment. coordinated check times would not actually solve anything. they would just ensure everyone agreed on the sample error. 12:39 < petertodd> wumpus: I'll do it 12:39 < gmaxwell> dgenr8: I think the mental model you should use is that any important looking warning that turns out to be false and not require use action seen by a user has a 90% chance of making that use forever ignore any similar looking warning. So it's critical that FPs be basically 0. 12:39 < morcos> this is just about backporting to 0.12 12:39 < wumpus> dgenr8: your changes should go into master. If it turns out to be enough, they'll make 0.13, it's too late for 0.12.1 12:40 < wumpus> right. 12:40 < dgenr8> wumpus: that's great 12:40 < petertodd> wumpus: what branch would be best to do it against? 12:40 < wumpus> petertodd: 0.12 12:40 < wumpus> only 0.12 12:40 < petertodd> wumpus: ack 12:40 < btcdrak> oh 12:40 < GitHub123> [bitcoin] btcdrak opened pull request #7780: [0.12] Disable bad-chain alert (0.12...spurious) https://github.com/bitcoin/bitcoin/pull/7780 12:40 < gmaxwell> dgenr8: I don't agree with your view on coordinated check times. When we want there to be no FP _anywhere_ except very rarely, the lack of sync means that this will happen much more often. It's the multiple comparisons problem. 12:40 < btcdrak> I just submitted 12:41 < jonasschnelli> ^^ :-) 12:41 < sipa> i think disabling should go in master 12:41 < gmaxwell> dgenr8: FPs are also less harmful when everyone gets one, since at least then "I got a warning and no one else did" is a good warning sign. 12:41 < dgenr8> gmaxwell: ah I forgot the "exclude false positives" code 12:41 < sipa> so that if no appropriate imorovement is found for 0.13, we don't need a separate "fix" there 12:41 < btcdrak> sipa: we're likely to fix it before then surely? 12:41 < wumpus> sipa: I don't agree, we should aim for improvement in master 12:41 < morcos> wumpus: I agree with sipa, otherwise we forget and have the broken one back for 0.13 12:41 < morcos> wumpus: yes AIM 12:41 < wumpus> sipa: if it itsn't fixed by 0.13 then we can easily disable it 12:42 < sipa> wumpus: disabling is considered an improvement, it should in master and be backported 12:42 < btcdrak> morcos: we wont forget. If it's not ready by 0.13 we can just disbale it 12:42 < wumpus> sigh 12:42 < sipa> but i don't care strongly 12:42 < sipa> :) 12:42 < morcos> we always forget! 12:42 < wumpus> I don't care 12:42 < wumpus> I just thought we had a plan and it's completely different now, but just do whatever you think makes sense 12:42 < btcdrak> well how about we merge 7780 the cherry-pick it into master. same diff 12:42 < morcos> if it makes it on a task list somewhere, thats good enough 12:42 < morcos> but just saying it here is a mistake 12:43 < gmaxwell> we've already wasted too much time on this really minor feature. If this loops too much more my view is going to change to abandon it completely. 12:43 < wumpus> if you disable it that means there is effectgively no testing for the improved code 12:43 < sipa> ok, let's fix in master 12:43 < sipa> i retract my comment 12:43 < gmaxwell> wumpus: already people have stopped reporting false postives. :( 12:44 < wumpus> gmaxwell: sure, if no one is going to improve the code further, that's fine too, wel'll disable it, just be honest about it :) 12:44 < morcos> i withdraw comment due to fear of the wrath of maxwell (kidding trolls, kidding) 12:44 < sipa> morcos: you should fear maxwell's demon indeed 12:44 < wumpus> hah 12:45 * petertodd shakes head 12:45 < petertodd> (thereby increasing entropy slightly) 12:45 < morcos> wumpus: you should do what you think is best, just don't let us forget if you leave it in... make an issue and milestone it or milestone dgenr8's PR 12:45 < morcos> next topic 12:45 < wumpus> morcos: right 12:46 < wumpus> I don't think 'we always forget', if we really want to remember something for the release there are ways to do so, but if no one feels it's worth the trouble well then it's not :) 12:46 < morcos> i am prone to hyperbole on the rare occasion 12:46 < wumpus> any other topics? 12:46 < sdaftuar> topic suggestion: CPFP mining 12:46 < wumpus> #topic CPFP mining 12:46 < sipa> sdaftuar: answer is yes 12:46 < sdaftuar> mostly i just want to bug people for review 12:47 < sipa> sorry, i wanted to review again now that the base tracking is merged, but haven't gotten around to it 12:47 < morcos> first step is for people to give concept feedback for 7598, refactor of CreateNewBlock 12:47 < sdaftuar> ^ yes that's what i was going to say 12:47 < morcos> its a kind of large change, and lets get it to a design we all like better 12:47 < morcos> sdaftuar and i can rebuild the CPFP on whatever the design is people like best 12:48 < morcos> the original goal of the design was to separate priority filling from feerate filling, but i think the overall goal should be to make it more modular to figure out how to assemble a block 12:48 < wumpus> #action disable bad-alert detection in master if it doesn't improve enough by 0.13 (and don't forget!) 12:49 < sipa> morcos: ok 12:50 < morcos> hmm 12:51 < jonasschnelli> 5mins for p2p enc/auth? 12:51 < morcos> i'm just trying to think about itming of all these things 12:51 < morcos> 5/15 isn't that far away 12:51 < morcos> and some changes on top of segwit will be necessary 12:51 < morcos> do we punt on these other things for now and try to get segwit merged 12:51 < morcos> or continue in parallel or what 12:52 < morcos> i'm not sure i know the answer... 12:52 < wumpus> jonasschnelli: sure 12:52 < jonasschnelli> I just wanted to get a feeling if it's worth to continue work on the p2p encryption and authentication BIP. 12:52 < jonasschnelli> IMO there are clear benefits. Question is more if we need our own solution (including all the risks) of if we should adapt stuff like stunnel, DJB's curveCP, etc. are already available. 12:52 < jonasschnelli> Continuing makes probably only sense if most of us prefere a own/custom solution. 12:52 < wumpus> #topic p2p encryption/authentication 12:53 < petertodd> jonasschnelli: fwiw, note that .onion addresses do work pretty well for p2p encryption and authentication 12:53 < sipa> jonasschnelli: you can literally copy the crypto code from openssh; it's 300 lines for chacha20-poly1305 12:53 < wumpus> I'm all for adapting something that already exists as long as it's not openssl 12:53 -!- MarcoFa [d9fe8fbe@gateway/web/cgi-irc/kiwiirc.com/ip.217.254.143.190] has joined #bitcoin-core-dev 12:53 < sipa> and ecdh and signing we already have 12:54 < jonasschnelli> I think it would allow extremely simple setups for wallet nodes (spv) to increase privacy. 12:54 < petertodd> sipa: copying ssh sounds pretty reasonable to me 12:54 < Luke-Jr> jonasschnelli: ready for BIP #s yet? 12:54 < btcdrak> jonasschnelli: continuing to work on those BIPs is a clear win 12:54 < jonasschnelli> tor is an alternative, but not preferred by everyone and probably consequences on performance. 12:55 < sipa> jonasschnelli: i don't think we should rush this (implementation should not start until cfields's refaactor is in, i think) 12:55 < jonasschnelli> Luke-Jr: BIP is _not_ ready yet. 12:55 < sipa> but thinking about it can continur 12:55 * wumpus also likes chacha20-poly1305 12:55 < jonasschnelli> Right. No rush. Can take 1-2 years. I just want to keep it moving. 12:55 < sipa> chacha20-poly1305 is faster than sha256 ;) 12:56 < warren> Are folks thinking this would be optional, not default? 12:56 < cfields> sipa / jonasschnelli: note that you can easily test with libbtcnet, so it'll be familiar after the net refactor 12:56 < petertodd> jonasschnelli: fwiw, this will improve privacy for non-spv as well if widely deployed; one of the interesting things that the network monitoring services like chainalysis are doing is MITMing nodes by simply faking the address info for both sides of the connection 12:56 < jonasschnelli> Okay. Will continue finish the BIP and seek out for funding for cryptanalysis, etc. 12:56 < petertodd> jonasschnelli: obviously encryption isn't a total solution, but the authentication is a good first step to anti-sybil techniques 12:56 < cfields> sipa / jonasschnelli: i added support for chunked reads as suggested, in case i forgot to mention 12:56 < wumpus> and indeed, .onion does fairly well as a p2p encryption and authentication for now, but that doesn't mean it's not worth looking for something that can be integrated 12:57 < gmaxwell> jonasschnelli: please don't ask for external cryptanalysis until it passes pieter's review. Otherwise it just risks embarassing our team and wasting money. :) 12:57 < sipa> related topic: shameless plug for https://github.com/sipa/ctaes (since it was a topic last week) 12:57 < petertodd> sipa: thanks! 12:57 < jonasschnelli> gmaxwell: Agree! 12:57 < cfields> jonasschnelli: i suspect there would be some MIT folks interested in analyzing/researching. I could ask around if you'd like. 12:57 < wumpus> #link https://github.com/sipa/ctaes 12:57 < jonasschnelli> cfields: good idea. 12:57 < gmaxwell> please not yet. 12:57 < cfields> heh, offer retracted after gmaxwell's plea :) 12:58 < jonasschnelli> Yes. Not now. First we need an implementation and clear review from maxwell and sipa. 12:58 < gmaxwell> I'm happy to help refining it, though. 12:58 < jonasschnelli> (after the BIP is "stable"). 12:58 < jonasschnelli> gmaxwell: yes. Will bother you soon with tons of q. 12:58 < gmaxwell> jonasschnelli: Thank you! 12:59 < jonasschnelli> 12:59 * sipa afk 12:59 < wumpus> #endmeeting 12:59 < lightningbot> Meeting ended Thu Mar 31 19:59:56 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:59 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-31-18.59.html 12:59 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-31-18.59.txt 12:59 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-31-18.59.log.html 13:00 < morcos> wait sorry if i zoned out 13:00 < morcos> did we agree not to hold up 0.12.1 for 0.11.3 ? 13:00 < jonasschnelli> I think so. 13:00 < wumpus> I don't think we agreed in anything in that regard, then again meetings are not for making decisions :) 13:00 < jonasschnelli> But it was not a clear obvious decision I guess. 13:01 < jonasschnelli> ok. 13:01 < instagibbs> in Core unit tests how do I pass in a chainparam string argument? Can't find examples and looking up Boost docs is failing me. 13:01 < jtimon> wait, how can this be endmeeting? wasn't the meeting starting at 8 pm? I was supposed to have missed the meeting 2 hours ago. Bad job communicating the hour changes ;) 13:02 < wumpus> jtimon: meeting is +0 UTC, or Reykjavik time 13:02 < morcos> wumpus: well, given that we are so close with 0.11.3, i think we should continue for CSV, but no reason to hold up 0.12.1, thats what i think 13:02 < morcos> the timeframe is set by the startdate in BIP9 anyway, so no reason not to let 0.12.1 penetrate for a little bit longer if we can 13:02 < wumpus> according to my calendar it just ended 13:03 < morcos> jtimon: you are funny, you were chatting offtopic during hte meeting, yet you didn't notice it was happening? :) 13:03 < wumpus> morcos: I personally tend to agree though, dependencies between releaases just inhibit flexibilty 13:04 < wumpus> then again even if we merged the softfork backport right now 0.12.1 wouldn't be ready yet, I think there's still an timeout issue to deal with 13:04 < morcos> wumpus: yes, but lets let worry about its own blockers only. 13:04 < morcos> wait 13:04 < jtimon> wumpus: oh, right, no more hour changes anymore that's better. If we were open to bike-shedding I would propose GMT forever everywhere without "time savings" and that would be it 13:05 < wumpus> jtimon: that's what it is already 13:05 < paveljanik> jtimon, then am and pm can change its meaning ;-) 13:05 < wumpus> jtimon: it's planned in UTC+0 which has no time savings 13:05 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev 13:06 < jtimon> morcos: yeah, sorry about that, I was answering on IRC not to disrupt gihub :( 13:06 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds] 13:06 < wumpus> meeting is always: 19:00 to 20:00 (GMT+00:00) Reykjavik 13:06 < jtimon> wumpus: yeah, it's perfect, sorry, I was just kidding about more radical "clock regimes" and I would ACK 13:06 < wumpus> jtimon: ohh okay 13:07 < wumpus> jtimon: sorry :) 13:07 < jtimon> no worries, my fault 13:07 < btcdrak> morcos: yes we agreed not to hold up 0.12.1 13:07 < wumpus> yes I'd prefer to get rid of DST in my country as well, it's an artifact of the past 13:07 < petertodd> jtimon: heh, I keep meaning to switch my computers to display time in UTC because a) I travel constantly anyway, so they're wrong half the time, and b) privacy! 13:07 < petertodd> jtimon: (also c) my brother is a pilot and does that already - sibling rivalry!) 13:08 < jtimon> petertodd: mhmm, never thought about privacy... 13:08 < petertodd> jtimon: _lots_ of stuff leaks where you are by leaking your local TZ 13:08 < wumpus> yes, it does, e.g. git 13:09 < petertodd> jtimon: e.g you can pretty easily figure out the last time I was in Newfoundland based on a well timed git commit (er, well, I was in Newfoundland's airspace...) 13:09 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 13:10 < wumpus> I don't really understand that, why protocols don't just use UTC timestamps or dates 13:10 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds] 13:10 < jtimon> trust me: as non-native english speaker tryting to full my OS installer that I am, I always have problems 13:10 < petertodd> wumpus: nsa conspiracy obvs :) 13:10 < wumpus> hehe 13:10 < instagibbs> for boost unit tests how does one pass an argument to the fixture, in order to test other chainparams? anyone? 13:11 < petertodd> wumpus: along those lines, I'm surprised even privacy oriented stuff doesn't let you fuzz timestamps - day-level resolution is pretty revealing, let alone down to the second 13:11 < jtimon> well, notalways, debian seems to listen, ubuntu doesn't 13:11 < jtimon> wumpus: UTC is still flawed 13:12 < sipa> instagibbs: you don't; individual tests specify what chain they run it 13:13 < instagibbs> sipa, the default string parameter is MAIN 13:13 < wumpus> petertodd: sure, a different issue, but timestamps in itself are always a fingerprinting angle, I was kind of shocked to read there are even some in TCP 13:13 < instagibbs> maybe I'm not looking at the right examples, but I don't see it being changed? 13:14 < wumpus> instagibbs: it's a matter of passing the right chainparams to the appropriate functions, let me see 13:14 < jtimon> let me expain, if you throw 2 UTC clocks in perpendicular directions, you may be deceived into thinking that either the earth is not moving or you have to grow a withe mustache to undesrstand the universe: it's neither of them, you just have to use median time, see BIP113 13:14 < sipa> instagibbs: i guess almost all unit tests run in main (maybe actually all) 13:14 < instagibbs> i need to learn the right incantation 13:15 < sipa> instagibbs: there is no incantation, it's not supposed to be configurable 13:15 < instagibbs> well... it's odd it has a parameter then 13:15 < wumpus> we're trying to erfactor away from having a global chainparams, so as many functions as possible just need it passed in 13:15 < instagibbs> I see 13:15 < sipa> instagibbs: wait, you mean in the code or on the command line? 13:16 < wumpus> but the right incantation is: SelectParams(CBaseChainParams::TESTNET); 13:16 < wumpus> see eg base58_tests.cpp 13:17 < instagibbs> ok that makes sense, the constructor calls it for chainName, which is always MAIN, so calling it myself may work 13:17 < wumpus> but in general that's not necessary, and you can just do const CChainParams& chainparams = Params(CBaseChainParams::TESTNET); then use that and pass it to the appropriate functions 13:18 < wumpus> unless you are testing something that uses the globally configured params 13:18 < instagibbs> wumpus, it's yelling at me about coinbase stuff 13:18 < instagibbs> anyhoo, one sec 13:21 < jtimon> so, given that there's people congregated I feel tempted to ask about my latest too crazy ideas 13:21 < petertodd> jtimon: heh 13:22 < jtimon> 1) do we need more feerate precision? ok, but not now, right? if so, we have much to disrupt and I'm looking for voluntaries, promise reivew 13:22 < jtimon> 2) are we coing to unify consensus flags or what? 13:23 < Luke-Jr> I don't know that it makes sense to release 0.12.1 without 0.11 being ready 13:23 < Luke-Jr> since 0.12 is not ready for mining 13:24 < jtimon> 1) #7731 2) #7779 please feel free to comment on the PRs and/or take/modify/resethead any commits as it may fit 13:24 < instagibbs> wumpus, SelectParams did the trick +1 13:25 < jtimon> do we still have selectparams? facepalm 13:25 < instagibbs> unit tests use it <_< 13:25 < sipa> Luke-Jr: increasing precision: i don't think we need it (it's less needed the larger fees are) 13:25 < sipa> eh, jtimon 13:26 < sipa> Luke-Jr: why is 0.12 not ready for mining? 13:26 < Luke-Jr> sipa: no CPFP 13:26 < sipa> Luke-Jr: neither did 0.11 13:26 < Luke-Jr> yes it does 13:26 < Luke-Jr> just not in Core 13:26 < jtimon> yeah, we don't have a factory for tests yet, #6907 sigh 13:26 < gmaxwell> Luke-Jr: analysis run by sdaftuar showed that it appeared no one was CFPF mining a couple months ago. 13:27 < Luke-Jr> gmaxwell: that can't be right, considering people are *using* CPFP on a regular basis 13:27 < Luke-Jr> and I know for certain a number of miners are 13:27 < gmaxwell> but do they solve more than a block per week? 13:28 < Luke-Jr> yes 13:28 < jtimon> btw, Luke-Jr morcos and I want more policy encapsulation and we're not doing it for lack of communication 13:29 < petertodd> the most convincing move towards policy encapsulation would be to get an alternate way of getting txs to miners - txs over bitmessage comes to mind 13:29 < Luke-Jr> … 13:29 < jtimon> oh CFPF... 13:30 < jtimon> CPFP 13:30 < morcos> jtimon: i think it makes more sense for you to take over policy encapsulation PR's and i can help review 13:33 -!- MarcoFa [d9fe8fbe@gateway/web/cgi-irc/kiwiirc.com/ip.217.254.143.190] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 13:36 < jtimon> morcos: I have things I could easily rebase to set up an easy base to continue (based on a base from look, but I hipe luke can agree we have more since my first policy PR which started just as nit to his) but in my best policy encapsulation dreams, at some point const CPolicy& was just a parameter to AcceptToMemorypoolWorker. And now it has many more parameters I don't know about 13:37 < jtimon> so I'm kind of worried of committing to a work I won't finish 13:37 < morcos> jtimon: ok. no problem. i think i will close my two open PR's though for now.. 13:38 < morcos> i feel a lot of other stuff happening, unless you tihnk either of them is worth pursuing 13:38 < jtimon> I mean, I believe little steps cannot be bad, but if you're reviwieing maybe with the thought of having to continue the work, that would be very helpful indeed 13:39 < jtimon> I mean, probably not just you, once it's started many people can help, but having someone committed to "finish it" (if we find a common definition of "finish") it's great 13:39 < jtimon> nah, I don't think this is urgent 13:40 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has joined #bitcoin-core-dev 13:42 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev 13:43 < jtimon> I will resurrect 6068 and friends just to take feerate out of primitives/transaction (which is the only thing that really makes me sigh) and hopefully create an abstract CPolicy policy parameter and a CDefaultPolicy to put new options in 13:43 < jtimon> morcos: did I got this right? you mostly care about encapsulating the minRealyFee global first 13:44 < morcos> jtimon: i think at the time i wrote that what i cared about was yes, being able to access that global from other codes rather than passing it in on construction which is broken b/c it hasn't been set by command line argument yet 13:45 < morcos> s/other codes/other classes/files/ 13:48 < jtimon> ok, I now wonder how many of them we need though 13:48 < jtimon> once I wrote a version in which you had a dynamic one based on your feeestimator and a static one for dust 13:49 < jtimon> policy/policy depends on the dust one 13:50 < jtimon> which is the one I'm most interested in touching now for moving it out of primitives/transaction and amount.o, but maybe we need to 13:50 < jtimon> 2 13:51 < jtimon> morcos: does that make sense to you? You know that code better than me 13:54 < jtimon> anyway, I should show you some code before asking 13:56 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 13:59 -!- BCBot_ [~BCBot@pc-5305.ethz.ch] has quit [Remote host closed the connection] 13:59 -!- BCBot [~BCBot@pc-5305.ethz.ch] has quit [Remote host closed the connection] 14:00 < morcos> jtimon: we need the existing one and we need the minIncrementalRate, they can be the same thing for now. i 14:01 -!- BCBot [~BCBot@nb-10350.ethz.ch] has joined #bitcoin-core-dev 14:01 -!- cryptapus_afk is now known as cryptapus 14:08 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Quit: laurentmt] 14:12 < jtimon> morcos: ok that's the kind of thing I don't have criterion to decide and someone else has to do (but whoever does it should be interested in my stuff to suppoosedly make that easy [and I'm very interested on comments of the sort "I don't think this will make my life easier", which is why I thought of you for review on my "preparations" {MarcoFalke is never here and NicolasDorier I would like to look too, I mean the more people 14:12 < jtimon> look the better, but you guys first please if you are available whenever}]); 14:13 < morcos> so is there a specific PR you want me to review now 14:18 < jtimon> I'll open a PR and ping you for review, knowing that feerate is your prioriy is great, the functions in policy/policy were just examples for the interface containing globals that would become encapsulated in globalPolicy (in main, althout I would prefer globals/server, never got to the poinst to explain that without great disruption), but GetDefaultFee() is as good as an example as any other. If you're goint to use it directly, 14:18 < jtimon> all the better. 14:21 < jtimon> too many words and too little code, when I open the PR, you're gonna ask why I need to mention satoshi so many times for such a simple no-change commit but as said I should talk to the compiler first, thanks for bringing this up again 14:35 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 248 seconds] 14:36 -!- xabbix [~xabbix@bzq-79-176-85-172.red.bezeqint.net] has joined #bitcoin-core-dev 14:36 -!- xabbix [~xabbix@bzq-79-176-85-172.red.bezeqint.net] has quit [Changing host] 14:36 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-core-dev 14:39 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev 14:47 -!- JeromeLegoupil [~textual@46-127-102-197.dynamic.hispeed.ch] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 14:52 -!- brg444 [4631c99d@gateway/web/freenode/ip.70.49.201.157] has joined #bitcoin-core-dev 14:54 -!- brg444 [4631c99d@gateway/web/freenode/ip.70.49.201.157] has left #bitcoin-core-dev [] 15:06 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:08 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev 15:12 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection] 15:12 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 15:13 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds] 15:28 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:32 -!- cryptapus is now known as cryptapus_afk 15:35 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Read error: Connection reset by peer] 15:38 -!- zooko [~user@2601:281:8001:26aa:d486:faaf:68eb:6e0e] has quit [Remote host closed the connection] 15:45 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 240 seconds] 15:50 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 15:55 -!- lolwut [47c528a4@gateway/web/freenode/ip.71.197.40.164] has joined #bitcoin-core-dev 15:58 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev 16:00 -!- lolwut [47c528a4@gateway/web/freenode/ip.71.197.40.164] has quit [Quit: Page closed] 16:39 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160315153207]] 16:59 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 17:11 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev 17:16 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds] 17:21 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rfdlxuidtiqycfts] has quit [Quit: Connection closed for inactivity] 17:33 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev 17:37 < ebfull> the bitcoin core contributing guidelines are vague on one point; is the author of a pull request free to rebase as their changes become unmergeable? 17:38 < ebfull> it does claim that rebasing and squashing may be asked of the author by "maintainers" 17:40 < gmaxwell> ebfull: just try to not confuse other reviewers, if its gone quiet (like your HTLC) is, I think it's fine to slice and dice the whole thing up. 17:41 < ebfull> thanks. moreover, would you find a policy asking contributors to submit a new pull request to avoid force pushes to their branches to be a silly rule/guideline? (presumably out of a fear of destroying history for reviewers) 17:42 < gmaxwell> it wouldn't be silly but it might be a bit over strong. Esp for trivial patches. 17:42 < ebfull> or trivial rebases 17:42 < ebfull> cool, thanks! 17:42 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Read error: Connection reset by peer] 17:42 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 18:01 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] 18:02 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:15 -!- dirtynewshoes [~dirtynews@sydnns0115w-047055195008.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 240 seconds] 18:15 -!- dirtynewshoes [~dirtynews@sydnns0115w-047055195008.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev 18:18 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 18:35 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.] 18:41 -!- p15 [~p15@22.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 18:47 < cfields> what's the purpose of mapRelay? Just a cache to avoid hitting the mempool for fresh transactions? 18:48 < gmaxwell> no so you will answer transactions you advertised recently even if they're not in mempool anymore. (e.g. just got mined.) 18:50 < cfields> aha, thanks 19:01 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev 19:13 < Luke-Jr> hm, is there a reason to do that? 19:13 < Luke-Jr> if it got mined, you're presumably going to resend it as part of the block anyway, right? 19:17 < gmaxwell> who says the peer even fetches the block? 19:25 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 19:33 < GitHub137> [bitcoin] morcos closed pull request #7557: Encapsulate options for mempool policy (master...policyOptions) https://github.com/bitcoin/bitcoin/pull/7557 19:34 < GitHub66> [bitcoin] morcos closed pull request #7556: Some cleanup work for mempool and policy estimator (master...cleanupMempool) https://github.com/bitcoin/bitcoin/pull/7556 19:48 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev 20:13 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer] 20:14 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:15 -!- ajweutr [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has quit [Ping timeout: 250 seconds] 20:24 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Remote host closed the connection] 20:44 -!- Don_John [~Don@248-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer] 20:51 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 21:15 -!- cguida [~chris@162.216.46.195] has quit [Quit: cguida] 21:19 -!- cguida [~chris@162.216.46.176] has joined #bitcoin-core-dev 21:21 -!- kangx [42d7ee99@gateway/web/freenode/ip.66.215.238.153] has quit [Quit: Page closed] 21:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:55 -!- d_t [~textual@212.144.253.35] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:01 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 260 seconds] 22:03 -!- Tasoshi_ [~Tasoshi@unaffiliated/tasoshi] has quit [Read error: Connection reset by peer] 22:07 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 22:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:11 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:36 -!- p15 [~p15@22.91.145.64.client.static.strong-tk2.bringover.net] has quit [Max SendQ exceeded] 22:39 -!- p15 [~p15@22.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 22:43 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 23:06 < btcdrak> ebfull: we don't have a policy against rebasing in pull requests. most of rerbase and even ask for PR authors to squash where it makes sense. 23:06 < sipa> i tend to rebase continuously, updating individual commits in a way to make the history most logical 23:06 < sipa> until there is significant review 23:07 < ebfull> i agree with your policy (and it's what i'm used to on github); i had other reasons for asking :) 23:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dvjfycqodefkqjft] has joined #bitcoin-core-dev 23:29 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-vykhvamohdmnmgnp] has quit [Quit: Connection closed for inactivity] 23:50 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 244 seconds] 23:55 -!- trippysalmon [~trippy@cyberdynesys.org] has quit [Ping timeout: 260 seconds]