--- Day changed Wed Apr 12 2017
00:00 -!- jnewshoes [~jodie@blk-215-123-241.eastlink.ca] has joined #bitcoin-core-dev     
00:02 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
00:03 -!- kexkey_ [~kexkey@68.168.119.228] has quit [Ping timeout: 252 seconds]     
00:06 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
00:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]     
00:18 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 245 seconds]     
00:24 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
00:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
00:26 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
00:36 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
00:44 -!- vicenteH [~user@96.235.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
01:23 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
01:26 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
01:40 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
01:43 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nnvcltmufxlsedrv] has joined #bitcoin-core-dev     
01:49 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
02:11 -!- frabrunelle [frabrunell@safenetwork/frabrunelle] has quit [Remote host closed the connection]     
02:11 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-witcbaviluyuhhnd] has quit [Remote host closed the connection]     
02:11 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-xgjnkrkumlnwemff] has quit [Remote host closed the connection]     
02:13 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-nzgjcibbylviohdu] has joined #bitcoin-core-dev     
02:15 -!- so [~so@unaffiliated/so] has quit [Ping timeout: 260 seconds]     
02:26 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
02:30 < wumpus> taking another look at #9694, really want to move forward multiwallet support
02:30 < wumpus> #8694 sorry
02:31 < gribble> https://github.com/bitcoin/bitcoin/issues/9694 | Importmulti cannot import bare private keys · Issue #9694 · bitcoin/bitcoin · GitHub
02:31 < gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
02:34 -!- frabrunelle [frabrunell@safenetwork/frabrunelle] has joined #bitcoin-core-dev     
02:34 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-okxcmwrnjcjbyaxs] has joined #bitcoin-core-dev     
02:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:58 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
03:12 -!- so [~so@unaffiliated/so] has joined #bitcoin-core-dev     
03:28 < bitcoin-git> [bitcoin] bulldozer00 opened pull request #10194: Remove unecessary friend keyword from the class definition (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10194
03:38 -!- kayamm [~km@pastasuta.pro] has joined #bitcoin-core-dev     
03:38 -!- kayamm [~km@pastasuta.pro] has quit [Changing host]     
03:38 -!- kayamm [~km@unaffiliated/kayamm] has joined #bitcoin-core-dev     
03:46 < wumpus> what's the problem with travis today?
03:52 < wumpus> nm, no travis issue today :)
03:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 240 seconds]     
04:00 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
04:15 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
04:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
04:58 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
05:37 < bitcoin-git> [bitcoin] sipa opened pull request #10195: Switch chainstate db and cache to per-txout model (master...pertxoutcache) https://github.com/bitcoin/bitcoin/pull/10195
05:37 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!]     
05:42 -!- Jared [~Jared@188.226.139.184] has joined #bitcoin-core-dev     
05:42 -!- Jared is now known as Guest19942     
05:49 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
05:49 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
05:49 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
05:49 -!- cryptapus is now known as cryptapus_afk     
06:01 -!- To7 [~theo@cpe-158-222-192-214.nyc.res.rr.com] has joined #bitcoin-core-dev     
06:04 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]     
06:08 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:b828:df98:5578:2a31] has quit [Quit: .]     
06:11 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:4158:6da8:2ea3:932a] has joined #bitcoin-core-dev     
06:16 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: jnewbery]     
06:24 -!- Samdney [~Samdney@178.162.209.135] has joined #bitcoin-core-dev     
06:26 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
06:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:37 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
06:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
06:43 < bitcoin-git> [bitcoin] jnewbery reopened pull request #10191: [trivial] Remove unused submit block parameters argument (master...remove_submit_block_params) https://github.com/bitcoin/bitcoin/pull/10191
06:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:50 -!- kexkey [~kexkey@68.168.119.228] has joined #bitcoin-core-dev     
06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
06:54 -!- ChillazZ [~ChillazZ@195.30.94.129] has joined #bitcoin-core-dev     
06:54 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
06:55 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 268 seconds]     
07:30 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
07:36 < bitcoin-git> [bitcoin] sdaftuar opened pull request #10196: Bugfix: PrioritiseTransaction updates the mempool tx counter (master...2017-04-prioritise-transaction) https://github.com/bitcoin/bitcoin/pull/10196
07:47 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
07:49 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
07:56 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
07:56 -!- molz_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
07:56 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
07:57 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
07:57 -!- Guest19942 [~Jared@188.226.139.184] has quit [Remote host closed the connection]     
08:12 < bitcoin-git> [bitcoin] jnewbery opened pull request #10197: Functional test warnings (master...functional_test_warnings) https://github.com/bitcoin/bitcoin/pull/10197
08:17 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Ping timeout: 260 seconds]     
08:46 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:57 -!- Char0n [~Charon@46.232.225.129] has quit [Read error: Connection reset by peer]     
08:59 -!- shesek [~shesek@bzq-84-110-54-107.red.bezeqint.net] has quit [Read error: Connection reset by peer]     
09:08 < bitcoin-git> [bitcoin] jnewbery opened pull request #10198: [tests] Remove is_network_split from functional test framework (master...remove_is_network_split) https://github.com/bitcoin/bitcoin/pull/10198
09:09 < bitcoin-git> [bitcoin] jnewbery closed pull request #10198: [tests] Remove is_network_split from functional test framework (master...remove_is_network_split) https://github.com/bitcoin/bitcoin/pull/10198
09:15 -!- Char0n [~Charon@46.232.225.129] has joined #bitcoin-core-dev     
09:19 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
09:21 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 268 seconds]     
09:41 -!- root-servers [~root-serv@112.208.17.114] has joined #bitcoin-core-dev     
09:57 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Ping timeout: 240 seconds]     
10:01 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Read error: Connection reset by peer]     
10:01 < arubi> is there a way to get bitcoind to not complain about any non-standardness?  I'd still like for it to error on operations with invalid transactions, but for example I'd like it to not care about DER strictness, or to ignore the P2SH requirement for a valid redeemscript (provided some preimage to p2sh, it should pass, no matter if the preimage parses as a script at all).  "SCRIPT_VERIFY_NONE = 0;" in script/interpreter.h (I'm on some 
10:01 < arubi> 0.13.99) looks promising, but I'm not sure what to set it to.  would love a hint on what I should look for
10:03 < arubi> this is for testnet \ regtest use by the way
10:06 < arubi> maybe I should just set all verify flags to 0 :)
10:10 < Chris_Stewart_5> arubi: Like you mentioned you can tinker with the verify flags: https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h#L52
10:10 < Chris_Stewart_5> but I'm not sure if you can do this from the command line :/ 
10:10 < arubi> oh no command line, these flags are not enough though
10:11 < arubi> it's letting it advance, I can send non standard transactions with some of these flags disabled, but getblocktemplate fails
10:11 < arubi> I don't wanna say that it's related, I already mauled this specific code to death
10:11 < Chris_Stewart_5> hmmm, perhaps you need to tinker with relay policy? Not sure where that is set in the codebase though
10:11 < arubi> other nodes drop the transaction
10:12 < arubi> actually I think they're banning me
10:12 < arubi> I'll be able to mine it myself eventually on testnet, when the diff drops, I just need getblocktemplate to work :)  setting all verify flags to 0 now
10:17 < arubi> muhaha it's working
10:18 < bitcoin-git> [bitcoin] morcos opened pull request #10199: Better fee estimates (master...smarterfee) https://github.com/bitcoin/bitcoin/pull/10199
10:20 < Chris_Stewart_5> setting all the flags to zero worked?
10:21 < arubi> yep     
10:21 < Chris_Stewart_5> you couldn't just unset STRICTDER?
10:21 < arubi> well I noticed script_verify_p2sh is used even with this tx's bare p2pk
10:22 < arubi> I did unset strictder to even be able to relay it... I think checking block validity is even more strict than that
10:22 < arubi> if you saw the tx in #-dev, it's also a hybrid pubkey, so maybe more relaxed flags are needed
10:26 < Chris_Stewart_5> arubi: Is p2pk scripts considered non standard?
10:26 < arubi> if it's a hybrid pubkey, probably
10:27 < arubi> also the signature itself is weird.  uses 0x01000000 as the sighash when the sig is passed as input
10:28 < arubi> so it's actually passed with a 4 byte value instead of just 0x01.. I think it should still be valid?
10:31 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: jnewbery]     
10:32 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
10:34 < instagibbs> morcos, for #10199 did you look at how it handles chain limits? There was some speculation during last spam attack that the chain limits were causing high-fee transactions to "fail" to get into blocks, spiking fees randomly
10:34 < gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
10:35 < morcos> instagibbs: the estimates don't consider txs that are dependent on other txs
10:35 < morcos> i don't think i saw that speculation, but it makes no sense
10:36 < Chris_Stewart_5> arubi: Look at this function if you haven't seen it yet: https://github.com/bitcoin/bitcoin/blob/b83264d9c7a8ddb79f64bd9540caddc8632ef31f/src/script/interpreter.cpp#L186
10:36 < Chris_Stewart_5> to see if the hash type is valid
10:36 < arubi> being defined != being valid :)
10:37 < arubi> the famous amount overflow transaction used 0xA8 as sighash iirc, weird, but it resolves to ALL
10:38 < arubi> interpreter.cpp has the rules for setting up the sighash, it does a bunch of bitwise and's with 1F and flags it knows.  really I think 32 bits can be used.  sighashv2 uses 32 bits
10:39 < instagibbs> morcos, ok good to know. One less idea why someone was doing that then.
10:40 < arubi> er, it uses 16 bits.
10:42 < arubi> was just informed that I may be wrong re. 4 bytes sighash value :)
10:45 < arubi> bip66 might be causing testnet failures where it works on regtest.  will stop spamming :)
10:45 < Chris_Stewart_5> Yeah when checking the signature you have to prepend? the extra bytes? 
10:45 < arubi> (-dev)
10:47 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
10:58 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/b44adf92342a...350b22497c7c
10:58 < bitcoin-git> bitcoin/master 4d9950d John Newbery: Set BCLog::LIBEVENT correctly for old libevent versions.
10:58 < bitcoin-git> bitcoin/master 5255aca John Newbery: [rpc] Add logging RPC...
10:58 < bitcoin-git> bitcoin/master 7fd50c3 John Newbery: allow libevent logging to be updated during runtime
10:58 < bitcoin-git> [bitcoin] laanwj closed pull request #10150: [rpc] Add logging rpc (master...logging_rpc) https://github.com/bitcoin/bitcoin/pull/10150
10:58 < gmaxwell> neat
11:00 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 255 seconds]     
11:00 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
11:02 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
11:13 -!- bsm1175321 [~mcelrath@157.130.6.242] has joined #bitcoin-core-dev     
11:14 -!- bsm117532 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has quit [Killed (wolfe.freenode.net (Nickname regained by services))]     
11:14 -!- bsm1175321 is now known as bsm117532     
11:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
11:14 -!- bsm1175321 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
11:15 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/350b22497c7c...de01da7cad32
11:15 < bitcoin-git> bitcoin/master 8c3e6c6 KibbledJiveElkZoo: Changed "Send" button default status from true to false...
11:15 < bitcoin-git> bitcoin/master de01da7 Wladimir J. van der Laan: Merge #10177: Changed "Send" button default status from true to false...
11:16 < bitcoin-git> [bitcoin] laanwj closed pull request #10177: Changed "Send" button default status from true to false (master...ui_fixes) https://github.com/bitcoin/bitcoin/pull/10177
11:25 < BlueMatt> wumpus: can we give that guy an award for "most humorous bug report"?
11:40 < bitcoin-git> [bitcoin] bulldozer00 closed pull request #10194: Remove unecessary friend keyword from the class definition (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10194
11:51 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
12:11 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
12:17 < BlueMatt> #9942 looks mergeable
12:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
12:18 < BlueMatt> same with #9480, maybe jeremyrubin should change the commit message, but has like 5 acks
12:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9480 | De-duplicate SignatureCacheHasher by JeremyRubin · Pull Request #9480 · bitcoin/bitcoin · GitHub
12:26 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection]     
12:26 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev     
12:26 -!- juscamarena is now known as Guest76166     
12:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
12:59 < bitcoin-git> [bitcoin] sdaftuar opened pull request #10200: Mining: Skip recent transactions if fee difference is small (master...2017-04-dont-mine-recent-tx) https://github.com/bitcoin/bitcoin/pull/10200
13:12 < gmaxwell> sdaftuar: wow, that is much more complicated than I expected.  What I had just expected it to do is to simply skip very new transactions unless they paid a high feerate, just like we skip transactions that there aren't room in the block for.
13:12 < gmaxwell> sdaftuar: is there a big fee income difference from doing a simple thing like that?
13:14 < BlueMatt> cfields: wait, we really want random bash snippets in git history run by a script in #10189? I'm unsure about the wisdom of that?
13:14 < gribble> https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni · Pull Request #10189 · bitcoin/bitcoin · GitHub
13:14 < BlueMatt> i mean its super nice to have, but also...running bash scripts out of git messages :/
13:16 < cfields> BlueMatt: arguably if a script is used to transform a large chunk of code, it should be saved with the commit for future reference. Why not use it too?
13:16 < BlueMatt> yea......
13:16 < BlueMatt> cfields: do merge tools show commit messages very clearly for sign-off?
13:17 < BlueMatt> would need to if they dont for this, i suppose
13:17 < cfields> BlueMatt: "git notes" is what you're asking about, i think :)
13:17 < BlueMatt> hmm?
13:18 < cfields> BlueMatt: i suppose I don't understand your question
13:19 < BlueMatt> cfields: contrib/devtools/github-merge.py
13:19 < BlueMatt> i would expect them to clearly query the merger to read each commit's commitmsg
13:21 < cfields> unsure. Wouldn't change anything there, though. the merge script could just run the verifier first.
13:22 < BlueMatt> cfields: oh dear god lets not default to running random peoples' commitmsg scripts on wumpus' computer
13:22 < BlueMatt> cfields: my point is that many people dont read commitmsgs in enough detail and might miss such scripts esp if they're replaced last-minute in a "title-only rebase"
13:24 < cfields> BlueMatt: travis runs the script and fails if it doesn't transform 1:1. It can be done locally as well....
13:25 < cfields> BlueMatt: I don't see what's so terrible about automating this checking: https://github.com/bitcoin/bitcoin/pull/9902/commits/bac5c9cf643e9333479ac667426d0b70f8f3aa7f
13:25 < BlueMatt> cfields: insmod cool_thing.ko && sed s/BOOST_FOREACH/for/
13:25 < BlueMatt> it'll transform 1:1 still?
13:25 < BlueMatt> this is not a sufficient check
13:26 < BlueMatt> automating on travis whatever
13:26 < BlueMatt> putting yet more scripts in a place that people might not see it is bad...I'm only suggesting we make it more apparent at least to people pressing the merge button
13:26 < BlueMatt> as many of us primarily just look at the diff itself
13:28 -!- shesek [~shesek@bzq-84-110-56-60.red.bezeqint.net] has joined #bitcoin-core-dev     
13:28 -!- root-servers [~root-serv@112.208.17.114] has quit [Read error: Connection reset by peer]     
13:28  * BlueMatt ponders if you can get a ^H somewhere....insmod kool_things.ko &&^H^H^H^H^H^H^H^Hsed s/BOOST_FOREACH/for/
13:28 < BlueMatt> probably not
13:29 < cfields> BlueMatt: the person pressing the merge button on bac5c9cf643e9333479ac667426d0b70f8f3aa7f should be running that sed script to be sure all occurances have been caught. Again, this should only be automatiting cases where mass transforms need to be checked anyway.
13:29 < BlueMatt> cfields: yes, but the person pressing the merge button should also be reading the script before it gets automatically run on their system
13:29 < BlueMatt> I think we're talking past each other somehow
13:30 < cfields> so yea, maybe not make it part of the merge script, but i don't see how having c-i do it could be a bad thing
13:30 < BlueMatt> I didnt say having c-i do it is bad?
13:30 < BlueMatt> i agree, travis should do it?
13:30 < BlueMatt> my only point was that the person pressing the merge button MUST be forced to read commit messages now
13:30 < BlueMatt> <BlueMatt> I think we're talking past each other somehow
13:32 < cfields> ok, fair enough. I thought you point was that the person hitting the button should be verifying as well if it's going to live in the commit message..
13:32 < BlueMatt> oh i mean maybe, i dont care much either way there, travis should run it so thats good
13:33 < BlueMatt> my only point is something should be done because many of us dont read commit messages as part of review (much)
13:33 < cfields> BlueMatt: jtimon suggested a prefix: "scripted-diff: commit msg here". I suppose for those, the merge-tool could interrupt and present the full message, if it doesn't already
13:34 < BlueMatt> that may help, i suppose
13:34 < BlueMatt> long prefix sucks though
13:34 < BlueMatt> scripted:
13:34 < cfields> well it could also just detect the script begin/end
13:34 < BlueMatt> but, yea, putting it in the commit title itself is probably good
13:34 < BlueMatt> no, i like jtimon's suggestion
13:35 < jtimon> yep, look at https://github.com/bitcoin/bitcoin/pull/10193 for an example (needs some squashing after completing it)
13:36 < cfields> jtimon: btw, I think you're looking for: sed -i '/#include <boost\/foreach.hpp>/d' file
13:36 < cfields> :)     
13:37 < jtimon> btw, how can I do sed -i ':a;N;$!ba;s/#include <boost\/foreach.hpp>\n//' ./src/*.cpp but excluding some specific files ?
13:38 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 260 seconds]     
13:43 < jtimon> yeah, for qt and wallet  I have it done, but some places use BOOST_REVERSE_FOREACH so they need to maintain the include for now
13:43 < jtimon> that's why I need to exclude specific files
13:44 < sdaftuar> gmaxwell: yeah it is certainly possible i overlooked something simple
13:44 < sdaftuar> gmaxwell: but with what you describe, i don't see how you could bound the income difference?
13:44 < sdaftuar> without making assumptions about the fee distribution
13:44 < cfields> jtimon: how about just changing those to rbegin/rend iterators in a prior commit?
13:46 < jtimon> yeah, that would be another option, at first I was thinking of only removing it from qt and wallet for now, but if I can completely remove them using this, it doesn't look as disruptive as I expected
13:46 < sdaftuar> gmaxwell: one way to implement what you describe might be, fill up the first X% of the block, and if no recent transactions were chosen, then exclude recent transactions from the remainder of the block
13:47 < sdaftuar> but if fee distributions were close to flat, then you might give up a lot of income unless X is large
13:47 < jtimon> I mean, if people are ok with doing it all at once, I would prefer it
13:51 < BlueMatt> jtimon: please. kill boost
13:51 -!- waxwing [~waxwing@96.47.224.155] has joined #bitcoin-core-dev     
13:52 < jtimon> BlueMatt: alright, that feeback is useful
13:52 < BlueMatt> :)     
13:53 < sdaftuar> gmaxwell: and conversely, i think you could also have the problem of including recent transactions too frequently -- a small high feerate transactions that was recently received should almost certainly not be included
13:53 < sdaftuar> because block reward is still high enough that it dominates
13:57 -!- waxwing [~waxwing@96.47.224.155] has quit [Ping timeout: 260 seconds]     
14:07 -!- bsm117532 [~mcelrath@157.130.6.242] has quit [Ping timeout: 255 seconds]     
14:13 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-core-dev     
14:26 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
14:28 < bincap> is it possible to write a script that executes or not depending on version bits of current block? (e.g. a payment locked by activation of segwit)?
14:28 < bincap> (or of other block)
14:29 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
14:37 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
14:38 < sipa> no, transactions cannot observe what block they are in
14:38 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
14:38 < sipa> otherwise you couldn't validate them before being confirmed
14:39 < bincap> sipa: in previous block(s) then
14:53 < sipa> no, transactions cannot observe what block they are in
14:57 < gmaxwell> sdaftuar: income difference is bound by amount_you_will_skip times transactions.
15:00 < bincap> sipa: could they instead observe e.g. version bits of block defined in script by it's height?
15:01 < bincap> that could allow to set up some incentives for users promising to support given BIP to actually do that
15:04 < gmaxwell> sdaftuar: I agree that what you propose is more 'correct', but it is non-trivially more complex. I'm doubtful that it increases income a meaningful amount, we've also not seen miners working especially hard in increasing their work update speed.. which causes similar losses.
15:05 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
15:06 < jtimon> would adding something like https://gist.github.com/arvidsson/7231973 be acceptable for getting rid of BOOST_REVERSE_FOREACH ?
15:12 < sipa> bincap: transactions don't observe blocms
15:12 < sipa> transactions exist before they're in a block
15:13 < sipa> their validity is independent of what chain they are included in
15:13 < sipa> so no
15:15 < bincap> I see. I thought of something like NLockTime
15:24 < bincap> can you otherwise create now a transaction, that will be very expensive to spend without segwit, but easy with segwit? (for example some setup of creating dust transactions and collecting them in segwit)
15:28 -!- Guest76166 [~justin@47.148.176.74] has quit [Remote host closed the connection]     
15:29 -!- Guest76166 [~justin@47.148.176.74] has joined #bitcoin-core-dev     
15:34 < gmaxwell> bincap: such things would create terrible incentives to lie about your rule support. These kinds of proposals have been rehashed many times before...
15:42 < berndj> gmaxwell, i think i started this line of thinking in #bitcoin, my version was only slightly different, where the coins become redeemable by anyone (i.e. probably a miner) if SW should fail to be active
15:42 < berndj> so blame me for that :)
15:58 -!- vicenteH [~user@96.235.15.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
15:59 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]     
16:14 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-xknxtgxhamzwlooz] has quit [Quit: Connection closed for inactivity]     
16:18 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ykijcskulbnohhqx] has joined #bitcoin-core-dev     
16:24 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
16:31 < sdaftuar> gmaxwell: i don't think the PR is all that complex, it may appear to be because i broke things out into lots of small commits (hopefully, to help review).  but admittedly i introduced some complexity in order to shave a few milliseconds off the runtime
16:32 < gmaxwell> sdaftuar: to confess, I didn't review it yet but you made it _sound_ complex.
16:32 < sdaftuar> gmaxwell: conceptually, i could have kept things very simple if i just ran CNB twice, once allowing recent transacitons in, and once without them
16:32 < gmaxwell> yes, but that would have pretty poor performance.
16:32 < sdaftuar> not terribly poor, if you avoided the TBV call
16:32 < sdaftuar> er, redundant TBV call
16:33 < sdaftuar> basically you would just call addPackageTxs twice... average runtime of 7-8ms
16:33 < sdaftuar> so that times two, versus the optimization i did, which gets down to about 10ms instead
16:34 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]     
16:34 < sdaftuar> i do want to save further optimization for a future PR.  but i could back out the optimization in this one, if it would aid review
16:35 < gmaxwell> Do you have a benchmark for this, that lets you measure how often it picks each option and how much fees it loses on consistent traffic?
16:35 < gmaxwell> e.g. that you could also try a braindead simple patch that just skips txn you've had less than X seconds, unless they have astronomic fees?
16:36 < sdaftuar> yeah i have simulated this a bunch.  i think with 10seconds of recency and 1% threshold, it almost never will include recent transactions.
16:36 < sdaftuar> my most recent run was with 30 seconds/0.5% threshold, and it still very rarely included recent transactions... maybe a handful of times out of more than 1000 samples
16:37 < gmaxwell> I made measurements of cross node mempool consistency a while back, but cdecker tells me that propagation has become much slower (which was intentional) so those numbers probably should be redone.
16:39 < sdaftuar> so the toggles in that model would be X (number of seconds) and fee (feerate?) threshold?
16:39 < cdecker> Yeah, TX propagation has slowed down considerably (http://bitcoinstats.com/network/propagation/), but blocks have sped up a lot
16:39 < sdaftuar> cdecker: thats great data, thanks!
16:40 < gmaxwell> (It slowed down because we unbroke trickling)
16:43 < midnightmagic> +1 unbreaking trickling
16:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
16:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
16:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
16:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
16:57 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
17:00 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
17:11 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
17:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nnvcltmufxlsedrv] has quit [Quit: Connection closed for inactivity]     
17:17 < jtimon> sipa: I'm getting some errors related to prevector templating, perhaps you can help with https://github.com/bitcoin/bitcoin/pull/10193#issuecomment-293742166
17:22 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
17:32 < sdaftuar> gmaxwell: is this what you have in mind? https://github.com/sdaftuar/bitcoin/tree/2017-04-braindead-simple-mining
17:32 < sdaftuar> i'm happy to simulate it for you on the same data set i've been using, just tell me what parameters you'd like to see
17:33 < sdaftuar> i'm not a fan of the model though
17:35 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Quit: quit]     
17:41 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
18:10 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
18:11 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Read error: Connection reset by peer]     
18:11 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
18:19 < gmaxwell> sdaftuar: 10 seconds and .0005 BTC should be fine for a test run. 
18:22 < gmaxwell> sdaftuar: I would gladly agree that it's a hack. But -- it's surely a simple one, if there is nothing else that could be said about it..  CreateNewBlock performance and simplicity counts for a lot. 
18:24 < gmaxwell> sdaftuar: also because of how BIP152 works it is still preferable to have less new data. E.g. having a binary "contains new stuff" vs "not" isn't ideal--- because once prefilling is in use up to 10kb will be prefilled and if there is more than that, we're likely to prefill noting (under the assumption that the block is too inconsistent to be salvagable)
18:25 -!- isle2983 [~isle2983@gateway/vpn/privateinternetaccess/isle2983] has quit [Ping timeout: 240 seconds]     
18:25 < sdaftuar> gmaxwell: that seems gameable though?  if i just rbf a transaction every 10 seconds with fee 50000, 50000+incremental_relay_fee, ... you'll always produce a block with a recent transaction, and i'll give up a negligible amount of money?
18:26 < gmaxwell> sdaftuar: 10 seconds is a non-trivial amount of time to allow propagation however.
18:27 < sdaftuar> gmaxwell: i agree about the prefilling concern... that was part of the reason i was skeptical of this approach at all, but i figured that for now, "needs a roundtrip" is pretty different from not needing a roundtrip, so might as well capture that.
18:28 < sdaftuar> even if i rbf every 5 seconds, its a trivial amount of money
18:28 -!- Guest76166 [~justin@47.148.176.74] has quit [Remote host closed the connection]     
18:29 < gmaxwell> I did calculations before that were hand-wave-handwave about the cost of orphaning relative to the subsidy based on block propagation observations and concluded a pretty low fee pays for the risk.
18:30 < gmaxwell> (mentioned somewhere in the logs here)
18:31 < sdaftuar> yeah i have no idea what the actual stale rates people see are
18:32 < sdaftuar> (and really, my model requires converting two numbers into 1 -- stale rate without recent txs/stale rate with recent txs -> my parameter.  not a difficult calculation, but requires understanding
18:32 < sdaftuar> for clarity:  that "/" above is not meant to be division
18:34 < gmaxwell> well my figuring didn't use stale rates but measurements of delays between stratum updates at pools as a function of blocksize, so I was able to come up with a constant + factor*size model for orphaning risk.  This was before BIP152-- and I think we can't really measure it anymore, but I figure the before bip152 figures give a baseline for the marginal impact. my model basically assumed the comp
18:34 < gmaxwell> etition was sending an empty block.
18:34 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ykijcskulbnohhqx] has quit [Quit: Connection closed for inactivity]     
18:51 < sdaftuar> gmaxwell: for the 0.14.1 release notes, did you want to specifically mention that the 0.14.0 defaults could result in the utxo cache using 1.2GB of memory due to mempool sharing?
18:52 < sdaftuar> i just pushed an update to #10185 but didn't call out that fact specifically, let me know if you'd like me to add it
18:52 < gribble> https://github.com/bitcoin/bitcoin/issues/10185 | [0.14] Mention dbcache memory changes in release notes by sdaftuar · Pull Request #10185 · bitcoin/bitcoin · GitHub
18:52 < gmaxwell> sdaftuar: I don't remember now, I don't think I wanted to do that. did I?  uh. I don't think we should bother mentioning the 0.14.0 usage. Did you mention it before but only say it could use 600 or something?
18:53 < sdaftuar> gmaxwell: i just explained that the 300MiB default could result in 600MiB of usage, so that people would know to double their values if they wanted to, say, keep the whole thing cached still
18:53 < sdaftuar> ah, i guess my language is potentially confusing
18:55 < gmaxwell> sdaftuar: but with the mempool the defaults could be 1200 which is what I was trying to express.. the dbcache just get doubled, the mempool did too.
18:55 < sdaftuar> right
18:55 < sdaftuar> all i wanted to explain was "multiply by 2!"
18:55 < sdaftuar> maybe just delete my parenthetical?
18:58 < sdaftuar> ok, got rid of it -- hopefully the sentence about only accounting for half the peak utilization will be enough for people to figure out what they want to do.
19:00 -!- dermoth [~thomas@dsl-66-36-132-82.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
19:00 -!- dermoth [~thomas@dsl-66-36-132-82.mtl.aei.ca] has joined #bitcoin-core-dev     
19:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
19:05 -!- Samdney [~Samdney@178.162.209.135] has quit [Quit: Verlassend]     
19:07 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
19:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
19:15 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]     
19:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
19:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
19:26 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
19:29 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
20:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
20:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
20:12 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]     
20:13 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
20:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
20:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
20:46 -!- dodomojo [~goksinen@2604:2000:c591:8400:842c:943:f446:8955] has joined #bitcoin-core-dev     
20:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
20:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
20:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
21:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Read error: Connection timed out]     
21:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
21:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
21:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
21:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
21:47 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
21:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
21:51 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]     
22:05 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Read error: Connection reset by peer]     
22:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
22:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
22:19 -!- dodomojo [~goksinen@2604:2000:c591:8400:842c:943:f446:8955] has quit [Remote host closed the connection]     
22:42 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-vmxiimbpijzitomx] has joined #bitcoin-core-dev     
22:57 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
23:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
23:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
23:10 -!- goksinen [~goksinen@2604:2000:c591:8400:842c:943:f446:8955] has joined #bitcoin-core-dev     
23:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zvdtqiaqmvrucvqd] has joined #bitcoin-core-dev     
23:15 -!- goksinen [~goksinen@2604:2000:c591:8400:842c:943:f446:8955] has quit [Ping timeout: 245 seconds]     
23:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
23:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
23:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
23:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
23:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
23:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
23:49 -!- vFSgrcFGBJHg [~rYUtdcvYT@2a02:2f0a:b0a0:567:4dc7:f812:601c:bac9] has joined #bitcoin-core-dev