--- Day changed Thu Aug 24 2017
00:02 -!- eck [~tGysJVzRq@151.56.197.35.bc.googleusercontent.com] has quit [Changing host]     
00:02 -!- eck [~tGysJVzRq@fsf/member/eck] has joined #bitcoin-core-dev     
00:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
00:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
00:08 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has quit []     
00:18 < bitcoin-git> [bitcoin] practicalswift closed pull request #10961: Improve readability of DecodeBase58Check(...) (master...DecodeBase58Check-cleanup) https://github.com/bitcoin/bitcoin/pull/10961
00:19 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:19 < bitcoin-git> [bitcoin] practicalswift reopened pull request #10961: Improve readability of DecodeBase58Check(...) (master...DecodeBase58Check-cleanup) https://github.com/bitcoin/bitcoin/pull/10961
00:22 -!- jtimon [~quassel@173.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds]     
00:52 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 240 seconds]     
00:52 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev     
00:55 -!- Alina-malina [~Alina-mal@37.157.223.81] has joined #bitcoin-core-dev     
01:13 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
01:13 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
01:15 -!- jonasa [~jonas@50-39-186-230.bvtn.or.frontiernet.net] has quit [Ping timeout: 240 seconds]     
01:35 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
01:35 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
01:36 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
01:49 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
01:51 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 276 seconds]     
01:54 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 240 seconds]     
01:54 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
01:57 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 252 seconds]     
01:58 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
02:10 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]     
02:20 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Ping timeout: 248 seconds]     
02:23 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
03:02 -!- fanquake1 [~fanquake@203-59-110-1.dyn.iinet.net.au] has joined #bitcoin-core-dev     
03:03 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Ping timeout: 248 seconds]     
03:06 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
03:14 -!- JackH [~laptop@46.189.28.211] has quit [Quit: Leaving]     
03:22 -!- laurentmt [~Thunderbi@115.31.156.105] has joined #bitcoin-core-dev     
03:22 -!- laurentmt [~Thunderbi@115.31.156.105] has quit [Client Quit]     
03:49 < meshcollider> hmm https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md uses br0 but https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-build.sh uses lxcbr0, are they supposed to be different?
03:51 < meshcollider> (unrelated to the issue fanquake was having btw)
04:14 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
04:15 -!- tonikt [~tonikt@unaffiliated/tonikt] has joined #bitcoin-core-dev     
04:15 -!- tonikt [~tonikt@unaffiliated/tonikt] has left #bitcoin-core-dev []     
04:41 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds]     
04:42 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
04:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:50 -!- jtimon [~quassel@173.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
04:56 -!- laurentmt [~Thunderbi@115.31.156.105] has joined #bitcoin-core-dev     
05:01 -!- laurentmt [~Thunderbi@115.31.156.105] has quit [Client Quit]     
05:09 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has joined #bitcoin-core-dev     
05:16 -!- Alina-malina [~Alina-mal@37.157.223.81] has quit [Changing host]     
05:16 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
05:26 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 240 seconds]     
05:28 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev     
05:40 < michagogo> meshcollider: looks like the former script exports an env variable to use that device
05:40 < michagogo> The latter*
05:40 < michagogo> br0 is the default that gitian uses (and if I'm not mistaken, that's what's set up on my system)
05:44 < GAit> I'm a bit confused by a failure, https://travis-ci.org/bitcoin/bitcoin/jobs/267945919 - two out of seven failed, seems a race but not sure what is causing it. Is stop_nodes() synchronous?
05:46 < instagibbs> GAit, looks like a "normal" failure: assert wait_until(lambda: len(self.nodes[1].getrawmempool()) == 5)
05:48 < GAit> What do you mean normal? it shouldn't fail and indeed it doesn't fail on the other runners nor locally. 
05:49 < GAit> the test does this: have a node with 5 tx in mempool, dump that to file, copy file to second node, start second node, make sure it has those 5 tx - without synchronizing manually. 
05:56 < fanquake1> GAit I restarted the tests
06:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:00 < jnewbery> fanquake1 - I was just looking at the Travis output and it disappeared under my feet :(
06:01 < jnewbery> in any case, if it's a new test and it failed first time on Travis it's probably reproducible
06:02 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
06:04 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]     
06:06 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 264 seconds]     
06:06 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
06:07 < instagibbs> GAit, it means that it appears to be related to your changes, or maybe you got unlucky
06:09 < fanquake1> jnewbery sorry. Looks like the same two have failed anyways.
06:10 < GAit> jnewbery: I merged mempool_dump into mempool_persist. instagibbs: def related to my changes, what i don't get is which is causing it to be racy. Maybe os.rename but i'd be very surprised. 
06:10 -!- Giszmo [~leo@ip-61-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
06:11 < GAit> jnewbery: seems we get the same failure, but only on some builders
06:13 < jnewbery> ok, I'll try to reproduce locally
06:17 < jnewbery> oh, it might be a merge conflict with master. You no longer need to assert on the return value of `wait_until()` (after #11068)
06:17 < jnewbery> Try rebasing on master and changing the `assert wait_until()`s to `wait_until()`s
06:19 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
06:19 < GAit> thanks, but i didn't rebase so i don't see how master can hurt it? - but very happy to rebase. Do you think I can also squash things while at it?
06:22 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
06:25 < jnewbery> GAit: Github automatically creates a merge into master, which is what Travis takes for its build: https://github.com/bitcoin/bitcoin/commit/30dfb2ceda2e8aae954a25b6a3cef63d24cf6512
06:25 < jnewbery> There's no merge conflict, but the semantics of that function have changed in a different file, which I believe is what caused your build failure
06:25 < jnewbery> if you merge or rebase locally and then test I expect it'll fail in the same way
06:25 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:25 -!- Bluewolf33 [~miker@2601:18d:4701:1f53::7c16] has quit [Remote host closed the connection]     
06:26 -!- Bluewolf33 [~miker@2601:18d:4701:1f53:1eb6:508a:883e:319d] has joined #bitcoin-core-dev     
06:26 < jnewbery> And yes, probably a good idea to squash at this point
06:28 < GAit> thanks! i thought i was crazy :) indeed fails locally now, will fix and squash
06:31 < jnewbery> GAit: no problem. I'll re-review once you've pushed
06:34 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
06:35 < GAit> jnewbery: done but i'd wait for travis before reviewing
06:35 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit []     
06:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
06:39 -!- promag [~Adium@2001:8a0:fe30:de01:140:11df:b4da:d06] has joined #bitcoin-core-dev     
06:40 < promag> jnewbery: do you think travis should merge with master and then run the tests?
06:43 < GAit> promag: that is what it does now and what made it fail, wait_until changed in master after i branched so I had to rebase
06:44 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds]     
06:45 < GAit> i guess is better to fail earlier rather merge day but it was confusing for me
06:46 < promag> right, the problem is when master forwards but you don't push to your branch, and at that moment your branch can have problems.
06:47 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
06:47 < GAit> yes and if the code is still mergable it may suffer only too late. But rebasing often (which I like) breaks reviews doesn't it?
06:49 < promag> usually unless you point the diff between the old and new commit.
06:59 -!- Giszmo [~leo@ip-61-233.219.201.nextelmovil.cl] has quit [Ping timeout: 240 seconds]     
07:01 < instagibbs> wish github had gitlab feature of "diff since last push"
07:07 -!- promag [~Adium@2001:8a0:fe30:de01:140:11df:b4da:d06] has quit [Quit: Leaving.]     
07:07 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit []     
07:09 -!- Evel-Knievel [~Evel-Knie@178-119-237-211.access.telenet.be] has joined #bitcoin-core-dev     
07:10 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
07:10 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Client Quit]     
07:15 -!- promag [~Adium@2001:8a0:fe30:de01:3c19:9c96:518c:e1c] has joined #bitcoin-core-dev     
07:20 -!- promag [~Adium@2001:8a0:fe30:de01:3c19:9c96:518c:e1c] has quit [Quit: Leaving.]     
07:20 -!- jonasa [~jonas@50-39-186-230.bvtn.or.frontiernet.net] has joined #bitcoin-core-dev     
07:28 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
07:30 -!- fanquake1 [~fanquake@203-59-110-1.dyn.iinet.net.au] has quit [Quit: Leaving.]     
07:32 < GAit> jnewbery: i like what you are doing in #11121
07:33 < jnewbery> GAit thanks. Just working on some nits from kallewoof and MarcoFalke. I'll push an updated branch soon. Reviews always appreciated :)
07:36 < GAit> jnewbery: :) - do you know why there are sleeps in the tests all over the place? if they are flacky without perhaps we need a better way to wait for the node to be ready?
07:37 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds]     
07:44 < GAit> mempool_persist seems to work fine locally without the sleeps (and 3 whole seconds faster!)
07:45 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Quit: Leaving.]     
07:50 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
08:09 < jnewbery> GAit - yes there are probably sleeps that can be removed
08:13 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
08:13 -!- tiagotrs [~tiago@p5DC465F3.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
08:14 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Client Quit]     
08:15 -!- tiagotrs [~tiago@p5DC465F3.dip0.t-ipconnect.de] has quit [Changing host]     
08:15 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
08:34 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 248 seconds]     
08:38 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:39 < MarcoFalke> Indeed, we should remove all sleeps other than for explicit polling
08:40 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
08:41 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Client Quit]     
08:50 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
08:51 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
08:51 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
08:52 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Client Quit]     
08:53 -!- btcdrak [uid239175@gateway/web/irccloud.com/x-hxkybodygiwsroat] has joined #bitcoin-core-dev     
08:55 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
09:03 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
09:07 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
09:07 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
09:13 -!- Dizzle [~dizzle@108.171.182.16] has quit [Ping timeout: 255 seconds]     
09:16 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds]     
09:18 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has joined #bitcoin-core-dev     
09:20 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
09:21 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
09:23 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:36 -!- adrh [52f60080@gateway/web/freenode/ip.82.246.0.128] has joined #bitcoin-core-dev     
09:39 < adrh> hey guys. i need some help if you can help me. I've been busting my head off...i want to build a script that uses sendtoaddress and i really can't get it to work
09:39 < adrh> here is my script: https://pastebin.com/fESuZDvz 
09:41 < adrh> it works to list my address, but i can't make sendtoaddress work
09:45 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:48 -!- tiagotrs [~tiago@p5DC465F3.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
09:48 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #bitcoin-core-dev     
09:50 < adrh> anyone ?
09:54 < instagibbs> adrh, try #bitcoin
09:54 < adrh> i tried . nobody can help me there at the moment
10:02 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
10:03 < instagibbs> sorry, off topic here
10:03 -!- alreadylate [~textual@37.247.1.221] has joined #bitcoin-core-dev     
10:04 < adrh> i dont know where to ask to be honest. i'm trying for 8 hours to make it work...
10:04 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
10:05 -!- alreadylate [~textual@37.247.1.221] has quit [Client Quit]     
10:21 -!- adrh [52f60080@gateway/web/freenode/ip.82.246.0.128] has quit [Quit: Page closed]     
10:22 < luke-jr> I seem to have a reproducable crash at startup with rc2 on testnet
10:23 < gmaxwell> luke-jr: whats the backtrace
10:23 < luke-jr> getting it
10:25 < luke-jr> http://codepad.org/aiVTgE08
10:25 < luke-jr> lock order issue, so probably wouldn't affect prod bins
10:28 < gmaxwell> what did the lockorder debugging print
10:29 < luke-jr> it's in the pastebin
10:30 < luke-jr> I don't understand how the walletdb.cpp lock is still in the lock order here
10:44 < ryanofsky> probably the easiest way to fix this is to just change LoadWallet LOCK(wallet) to a LOCK2(main, wallet)
10:44 < BlueMatt> ryanofsky: that feels strange...maybe cs_main in CreateWalletFromFile in wallet.cpp instead?
10:44 < luke-jr> ryanofsky: do you understand the problem? why is walletdb's lock relevant here?
10:44 < BlueMatt> taking cs_main inside of walletdb is...yuck
10:44 < BlueMatt> luke-jr: cause its a lock inversion
10:44 < BlueMatt> walletdb takes the wallet lock, so...lock inversion?
10:44 < luke-jr> BlueMatt: but walletdb's lock is released before we get to the wallet lock?
10:44 < BlueMatt> no it isnt
10:44 < BlueMatt> ReadKeyValue calls back into wallet
10:45 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
10:46 < luke-jr> BlueMatt: to ReacceptWalletTransactions?
10:46 < luke-jr> how?
10:46 < MarcoFalke> wumpus: Mind to create a gitian.docs under bitcoin-core?
10:46 < BlueMatt> luke-jr: yes
10:46 < BlueMatt> LoadToWallet
10:46 < MarcoFalke> You wanted me to write a fedora guide for it
10:47 < luke-jr> BlueMatt: that doesn't call Reaccept
10:48 < bitcoin-git> [bitcoin] promag opened pull request #11125: Add bitcoin-cli -stdinrpcpass functional test (master...2017-08-stdinrpcpass-functional-test) https://github.com/bitcoin/bitcoin/pull/11125
10:48 < promag> jnewbery: ^ as soon as you can? ty!
10:49 < wumpus> MarcoFalke: you want a repo specifically for gitian docs?
10:49 < BlueMatt> luke-jr: the conflict is MarkConflicted, not Reaccept
10:49  * luke-jr peers at his editor
10:50 < luke-jr> oh, the backtrace was in Reaccept
10:50 < MarcoFalke> jup, they don't really belong in the main repo
10:50 < MarcoFalke> Also, a GitHub wiki is not suitable
10:51 < MarcoFalke> It is either open to be edited by anyone (with a GitHub account) or effectively none
10:52 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-core-dev     
10:54 -!- Aaronvan_ is now known as AaronvanW     
10:57 < wumpus> but I can't see a gitian.docs repo ever containing more than one or two files - what about a more general 'docs' repo, which could potentially include other things as well?
10:58 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 246 seconds]     
10:58 < luke-jr> wumpus: +1
10:58 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
10:58  * luke-jr wonders how to make a test that would pick up on this wallet lock issue
10:58 < luke-jr> if (prevtx.nIndex == -1 && !prevtx.hashUnset()) { <-- this line needs a comment :/
10:58 < MarcoFalke> wumpus: Fine with me
10:59 < wumpus> MarcoFalke: ok
10:59 < luke-jr> otoh, gitian docs may be unversioned, whereas other docs might be versioned?
11:00 < wumpus> nah, all documentation tends to be about the newest versions
11:01 < wumpus> could add sections for building older versions
11:01 -!- oooo [5ec040c7@gateway/web/freenode/ip.94.192.64.199] has joined #bitcoin-core-dev     
11:01 < luke-jr> wumpus: I just mean, it makes sense to tag docs per release, but not gitian docs necessarily
11:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]     
11:01 < wumpus> I'd prefer not to do any tagging/brancing in the docs repo
11:01 < wumpus> document change control tends to be very diffrent from source code
11:01 < luke-jr> wumpus: so we keep release-specific docs with the main repo?
11:02 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
11:02 < wumpus> yes, there are no plans to move anythingbesides the gitian building doc at this point
11:02 < luke-jr> i c     
11:06 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
11:08 -!- oooo [5ec040c7@gateway/web/freenode/ip.94.192.64.199] has quit [Ping timeout: 260 seconds]     
11:09 < wumpus> MarcoFalke: https://github.com/bitcoin-core/docs.git
11:09 < MarcoFalke> ty     
11:09 < wumpus> you should have push access, we can add other maintainers later
11:14 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 246 seconds]     
11:15 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
11:19 < cfields> sipa: do you have local work on top of #11117? Anything I can help with there?
11:22 -!- Veseli_Zagorec [~Veseli_Za@dh207-66-49.xnet.hr] has joined #bitcoin-core-dev     
11:22 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
11:23 < sipa> cfields: nope
11:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
11:23 < sipa> but i don't expect it to be much
11:24 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
11:27 < cfields> ok. let me know if there's anything i can help with without stepping on your toes
11:29 < bitcoin-git> [bitcoin] ryanofsky opened pull request #11126: Acquire cs_main lock before cs_wallet during wallet initialization (master...pr/loadlock2) https://github.com/bitcoin/bitcoin/pull/11126
11:45 -!- tiagotrs [~tiago@p5DC465F3.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]     
11:48 -!- Veseli_Zagorec [~Veseli_Za@dh207-66-49.xnet.hr] has quit [Quit: Leaving]     
11:58 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has quit [Read error: Connection reset by peer]     
11:59 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
12:00 < sipa> WOOSH
12:00 -!- praxeology1 [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has joined #bitcoin-core-dev     
12:00 < sipa> meetingh?
12:00 < jonasschnelli> \o/     
12:01 -!- Guest79199 [~smuxi@2600:8805:3a01:ac00:88ff:9870:5bbb:2362] has joined #bitcoin-core-dev     
12:01 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]     
12:01 < wumpus> #startmeeting
12:01 < lightningbot> Meeting started Thu Aug 24 19:01:45 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01 < gmaxwell> wumpus: you have the best nameping.
12:02 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
12:02 < kanzure> hi.     
12:02 < achow101> hi     
12:02 < BlueMatt> happy segwit everyone
12:02 < sipa> short topic: thanks and congrats everyone with SegWit... it seems it activated on the network without a glitch
12:02 < wumpus> yes, congratulations everyone!
12:03 < jonasschnelli> wohoo!
12:03 < achow101> yay!
12:03 < cfields> hi     
12:03 < wumpus> it took lots of time, and lots of sweat, but we did it
12:03 < kanzure> whole bitcoin community did it
12:03 < gmaxwell> sipa: well except the glitch of miners universally having maxblocksize=1000000 in their configs, resulting in overly small blocks even though there have been several oppturnityies to make bigger ones.
12:03 < sipa> gmaxwell: everything on its time
12:03 < luke-jr> s/glitch/good thing/
12:04 < sipa> misconceptions are hard to fix
12:04 < gmaxwell> You may well have jinxed us, since things blowing up might only happen with a >1MB block. :)
12:04 < BlueMatt> yes, some miner appear to be confused by maxblocksize/maxblockweight options, we need #11100
12:04 < wumpus> we should probably publicize some segwit miner's faq thing
12:04 < wumpus> on bitcoincore.org
12:04 < achow101> wumpus: isn't there already one?
12:04 < luke-jr> wumpus: not if they don't encourage big blocks. :/
12:04 < luke-jr> err, not if they do*
12:04 < kanzure> luke-jr: it would have been better if the expectations around that would have been communicated, then i would agree with you about good thing. expectation mismatch is not ideal.
12:04 < wumpus> achow101: there is a segwit faq but it doesn't include this
12:04 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
12:04 < achow101> https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/#miners
12:05 < achow101> not really an faq I guess
12:05 < gmaxwell> achow101: says nothing about needing to remove the maxblocksize setting and setting maxblockweight=4000000
12:05 < luke-jr> there is no such need, nor is it good for them to do so
12:06 < kanzure> luke-jr: it's about being honest about expectations. if miners expected the software to do something different, then we need to better document the configuration.
12:06 < wumpus> kanzure: +1
12:06 < harding> Is there anything else that should go into a current segwit faq for miners?
12:06 < wumpus> there is apparently a lack of documentation for these optons and what they do, that's clear, no matter what your opinion on what their value should be is
12:07 < kanzure> sounds like there's some requests for a post-activation faq
12:07 < wumpus> #topic segwit faq for miners
12:07 < luke-jr> hm, I thought we had documented it before, but I can't find it
12:07 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
12:07 < BlueMatt> blockmaxsize really just needs to be removed, it has caused significant confusion with several mining pool operators...if you want to limit the block's size-in-bytes you can do that yourself as a gbt client (isnt that what gbt is for?)
12:08 < gmaxwell> wumpus: it's super confusing for people.  esp the fact that the maxblocksize setting (which doesn't make any sense anymore) says it defaults to 750k so then I tell people to remove it and set maxblockweight=4000000 and they don't believe it'll make a >750k block.
12:08 -!- Dizzle [~dizzle@108.171.182.16] has quit [Ping timeout: 255 seconds]     
12:08 < wumpus> not sure if there's any other ones, have there been any other frequent questions about segwit by miners?
12:08 < luke-jr> BlueMatt: size is often the bottleneck today, so it makes sense to limit by size
12:08 < gmaxwell> so then I say, "it will but fine, just set blockmaxsize=4000000" and then they think if they set if over 1M they'll make invalid blocks. :(
12:08 < BlueMatt> luke-jr: ok, then gbt clients can do so
12:08 < gmaxwell> luke-jr: size is a bottleneck in _what_?
12:09 < BlueMatt> wumpus: I've literally heard confusion to the tone of what gmaxwell described from every mining pool operator I spoke to
12:09 < luke-jr> gmaxwell: IBD mainly at this point I guess
12:09 < BlueMatt> that option needs to die
12:09 < sipa> luke-jr: with BIP152, the size hardly matters, except if you're ridiculously bandwidth constraint to the point you'd be unable to keep a node synced in the first place
12:09 < sipa> *constrained
12:09 < achow101> luke-jr: IBD is too late to save already
12:09 < luke-jr> sipa: blocksonly?
12:09 < gmaxwell> luke-jr: not for anyone with an internet connection beyond a few megabits in speed.
12:10 < gmaxwell> luke-jr: IBD time is limited by chainstate database operations for parties that aren't totally network starved.
12:10 < luke-jr> achow101: it's nothing like as bad as it could be
12:10 < cfields> i've seen a ton of questions about segwit and "the addresses that start with a 3"...
12:10 < kanzure> ya i have seen mostly non-miner questions
12:10 < BlueMatt> anyway, so aside from luke is there anyone who objects generally to removing -maxblocksize? (ala #11100)
12:10 < wumpus> BlueMatt: IMO the solution to lack of documentation  should be documentation, changing around things more so there's differences between versions to explain too
12:11 < cfields> a quick update and faq about segwit addresses, how they look, and how they'll look soon would be helpful imo. even if it's just re-hashed info
12:11 < luke-jr> not long ago, the blockchain was 100 GB. now it's 150 GB. and every month 10 GB more with 2 MB blocks :/
12:11 < kanzure> we can also copy-paste old segwit faq details anyway
12:11 < kanzure> (or link to them)
12:11 < sipa> luke-jr: prune
12:11 < luke-jr> sipa: that doesn't eliminate IBD
12:11 < wumpus> 'take the option away and the problem goes away' is a bit too simplistic at this point
12:11 < BlueMatt> wumpus: 11100 now removes it but keeps it somewhat compaible in spirit with what most miners appear to still have in their config files...
12:11 < BlueMatt> ehh, deprecates it
12:11 < BlueMatt> and clearly states blockmaxsize is deprecated
12:12 < BlueMatt> which roughly aligns with the expectation of everyone i spoke to
12:12 < luke-jr> 11100 is stupid.
12:12 < BlueMatt> there was confusion as to why blockmaxsize still existed in the context of segwit
12:12 < meshcollider> deprecating makes sense to me
12:12 < morcos> even i have trouble keeping up with what the interaction of these different options is
12:12 < kanzure> needs an interaction matrix visualization
12:12 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
12:12 < kanzure> where the cells indicate interaction :-)
12:12 < morcos> we need to move towards getting rid of blockmaxsize, its confusion for no benefit....
12:12 < achow101> is blockmaxsize taken into consideration with segwit or just ignored?
12:13 < sipa> achow101: it is!
12:13 < wumpus> deprecation is likely a good idea on the longer run, but not a fix to the misunderstanding created
12:13 < instagibbs> taken into account
12:13 < gmaxwell> achow101: it does something stupid, it truncates block construction when you reach that size.
12:13 < achow101> bleh :/
12:13 < luke-jr> it does what it's supposed to do
12:13 < gmaxwell> it originally went away and luke threw a fit.  With segwit not active it made sense as a legacy support thing but it's active now.
12:13 < morcos> wait a second
12:13 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]     
12:13 < BlueMatt> wumpus: I disagree here, I was explicitly asked why it was not deprecated, because the consensus limit is around weight, so thats what people expect to be setting
12:14 < luke-jr> gmaxwell: you're rewriting history now
12:14 < BlueMatt> deprecation is, itself, documentation
12:14 < wumpus> BlueMatt: but we're already in the screwed state that those options exist
12:14 < morcos> i might be wrong (b/c the interaction is complicated) but isn't it just flat out wrong to say the default is 750K
12:14 < morcos> isn't the default infinity?
12:14 < sdaftuar> morcos: no, i don't think so.
12:14 < sipa> morcos: i honestly don't know anymore
12:14 < achow101> morcos: how so?
12:14 < morcos> if you don't set blockmaxsize it doesn't even calculate it
12:15 < gmaxwell> morcos: the default is 1/4 the configured weight which defaults to 3m.
12:15 < sdaftuar> if you set nothing, you get a 750k default, i believe.  and a 3M weight max.
12:15 < wumpus> I'm fine with marking it as deprecated anyhow
12:15 < morcos> ok well we'll get to the bottom of it in a second, but look how ridiculous it is that we don't know
12:15 < sdaftuar> if you set just blockmaxweight, then blockmaxsize is effectively infinity, i think.
12:15 < bitcoin-git> [bitcoin] romanornr opened pull request #11127: Make Bitcoin Core compatible with NYA segwit2x (master...s2x) https://github.com/bitcoin/bitcoin/pull/11127
12:15 < gmaxwell> sdaftuar: right.
12:15 < sipa> if you set only one of them, the other is taken as infinity
12:15 < gmaxwell> oh jesus.
12:15 < sipa> if you set both, both are enforced independently
12:15 < sdaftuar> but blockmaxsize is absurd, it should be removed.
12:15 < morcos> sdaftuar: you think if you set no options you can not produce a segwit-tx containing block bigger than 750k?
12:15 < morcos> that doesn't seem right to me
12:16 < sipa> morcos: i believe that is correct
12:16 < instagibbs> morcos, pretty sure that's correct
12:16 < sdaftuar> correct, you are capped at 750kb
12:16 < gmaxwell> That is correct.
12:16 < meshcollider> if you set blockmaxsize then blockmaxweight becomes blockmaxsize * WITNESS_SCALE_FACTOR doesn't it?
12:16 < bitcoin-git> [bitcoin] romanornr closed pull request #11127: Make Bitcoin Core compatible with NYA segwit2x (master...s2x) https://github.com/bitcoin/bitcoin/pull/11127
12:16 < instagibbs> all miners have cranked up to 1MB
12:16 < morcos> ugh, we should never have released it in this state
12:16 < sdaftuar> +1     
12:16 < sipa> yes     
12:17 < wumpus> but we're there anyhow, what now?
12:17 < gmaxwell> instagibbs: which now means a cranking down to 1MB. :(
12:17 < sdaftuar> wumpus: we should remove it and deprecate the command line option
12:17 < bitcoin-git> [bitcoin] hovah opened pull request #11128: Make Bitcoin Core compatible with NYA segwit2x (master...s2x) https://github.com/bitcoin/bitcoin/pull/11128
12:17 < sdaftuar> as we indicated we may do in the future in the 0.13 release notes, iirc
12:17 < morcos> Announcement that you should set only blockmaxweight and you should set it to 4,000,000.  Plus change code to ignore blockmaxsize unless specifically set, and deprecate it.
12:17 < gmaxwell> Well we should remove the silly option. The maximum size is not really correlated with anything that is interesting to be set anymore.
12:17 < luke-jr> miners producing blocks larger than 750k (or 1 MB at most) is malicious toward the network, and advising they do so or deprecating the blockmaxsize option needed to control this, it what is absurd.
12:17 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
12:17 < luke-jr> morcos: absolutely not
12:18 < jtimon> BlueMatt: ack on removing blockmaxsize and leaving only maxblockweight
12:18 < gmaxwell> Luke is faulty.
12:18 < wumpus> luke-jr: so they can still choose to do that with that option removed, right?
12:18 < wumpus> luke-jr: e.g. by setting the blockmaxweight lower?
12:18 < sdaftuar> or by using the gbt results and truncating themselves
12:18 < BlueMatt> anyway, so it sounds like #11100
12:18 < wumpus> that doesn't need two options
12:18 < luke-jr> wumpus: not effectively
12:18 < sdaftuar> luke-jr: why not?
12:18 < morcos> In general it is good that we have a culture of arguing things to death here, sometimes useful things result.  But in this case, we've been over this, we've heard Luke's arguments, and last time we gave in to end the argument
12:18 < sipa> luke-jr: the assumption behind segwit is that size doesn't matter nearly as much as a new metric, weight
12:18 < wumpus> the complication here is having two options that interact in a complicated way
12:19 < BlueMatt> luke-jr: you're the one who always advocates for policy at the other end of gbt, or isnt that the design of gbt?
12:19 < wumpus> please don't confuse it with what the value should be
12:19 < praxeology1> I don't think you should depricate the maxblocksize option.  If anything, if you want the software to enforce a legacy block size of 1MB, then hard code the limit...  and remove the maxblocksize setting from the configuration.
12:19 < sipa> luke-jr: i'm sorry to hear you disagree about that point, but that ship has sailed
12:19 < luke-jr> the only way to limit size to 750k with blockmaxweight is =750000, which will make 250k blocks unless 100% of tx are segwit
12:19 < morcos> Unless someone else agrees with Luke, I htink its just time to say unfortunately we're proceeding against his objections on this issue
12:19 < jnewbery> Concept ACK 11100
12:19 < gmaxwell> praxeology1: oh jesus christ you're also confused
12:19 < wumpus> yes, that sounds confused
12:19 < luke-jr> sipa: that ship has not sailed. that's not an argument.
12:20 < gmaxwell> praxeology1: THERE IS NO "LEGACY BLOCK SIZE" LIMIT ANYMORE!  Compatibility with old nodes achieved implicitly through how weight is constructed.
12:20 < BlueMatt> praxeology1: these options only effect the type of blocks miners mine, and are currently a maze of confusing
12:20 < sipa> luke-jr: segwit is active, regardless of your preferences, you should assume that rational actors will produce what the rules allow them to
12:20 < achow101> the parameter interaction is defined here: https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L81 for reference
12:20 < luke-jr> sipa: then Bitcoin is dead.
12:20 < BlueMatt> praxeology1: whats worse, the current options default to pissing away a significant amount of profit (so are always being overridden in practice, which has resulted in much confusion)
12:21 < jnewbery> what, dead again?!
12:21 < sipa> luke-jr: then Bitcoin is evolving to actually be tested
12:21 < gmaxwell> luke-jr: you've failed to address any of the points which I raised against your last rant on this on github.
12:21 < praxeology1> OK... so if there is no legacy limit anymore... then why would there be a configuration option for it? :o  Are you saying post segwit activation, it has no effect now?
12:21 < kanzure> does 11100 completely encompass the proposed changes
12:21 < BlueMatt> kanzure: I believe so
12:21 < sipa> luke-jr: i'm only interested in a Bitcoin that survives under the assumption that miners act rationally
12:21 < achow101> praxeology1: it has an effect, kind of. it really shouldn't though
12:21 < sipa> luke-jr: and you should too
12:22 < luke-jr> gmaxwell: your "points" depend on assertions that have no evidence at this time, which you are trying to CAUSE to be true
12:22 < gmaxwell> luke-jr: in particular expecting people to throw money on the floor to protect interests like keeping IBD times slightly lower is a failed expectation. (which we knew would fail, which is also why many of us don't support those reckless blocksize uncapping proposals)
12:22 < wumpus> if you think a defaults change kills bitcoin, you're severly underestimating it
12:22 < luke-jr> sipa: incentives are too broken for that to be possible right now
12:22 < sipa> luke-jr: how so?
12:22 < luke-jr> sipa: unless "rationally" includes altruism
12:22 < instagibbs> I motion to move onto a new discussion unless there's some new information to be shared
12:22 < sdaftuar> seconded
12:22 < wumpus> people are already overriding it on large scale, no one is using that stupid default
12:22 < sipa> seconded
12:22 < BlueMatt> ok, other topics?
12:22 < wumpus> #topic 0.15.0 release
12:22 < luke-jr> wumpus: overriding it to 1 MB, not 4 MB
12:23 < BlueMatt> second round of congrats on segwit?
12:23 < morcos> i'm against moving on unless we have agreed to get rid of the option and make an announcement
12:23 < kanzure> i could see luke-jr maybe working on the calculation there and showing numbers at some point. but probably not this moment. in the mean time i think 11100 review status should be checked?
12:23 < BlueMatt> morcos: I think we did
12:23 < morcos> we can't constantly do the wrong thing because luke is willing to argue longer than the rest of us
12:23 < morcos> at some point we must overrrule
12:23 < morcos> with 3 r's
12:23 < luke-jr> morcos: you're the one who wants to do the wrong thing
12:23 < praxeology1> BlueMatt: Congratulations! wahoo!!!! :) :) :) :) 
12:23 < BlueMatt> morcos: go ack 11100, I dont think there was any concept objection
12:23 < sdaftuar> luke-jr: he is not "the one" who wants to do what he is suggesting
12:23 < sdaftuar> he is one of many
12:23 < gmaxwell> morcos: a point of order, I prefer we don't force 'final' decisions to be made in the meetings due to attendance complications. I think what you suggest it clearly the general thrust of where things are going, however.
12:24 < BlueMatt> okkkkkk, so 0.15.0
12:24 < instagibbs> reviewing the PR is the action item
12:24 < gmaxwell> s/it/is/
12:24 < wumpus> this is getting really unruly
12:24 < BlueMatt> dooglus finally got some backtraces on #9683, which I think needs to be investigated for 0.15
12:24 < wumpus> I'm going to end this meeting if this continues
12:24 < BlueMatt> also #11126
12:25 < wumpus> any reports of new regressions with rc2?
12:26 < achow101> probably not
12:26 < wumpus> to be honest dooglus has been having issues no one else is having, for a long time, we should assist him but I'm not sure we should hold up a release for it
12:26 < BlueMatt> wumpus: well are we gonna release today? I'll take a look at his issues this afternoon :)
12:26 < BlueMatt> i mean I'm not saying hold it up
12:26 < meshcollider> only issue I've heard with rc2 has been fanquakes gitian issue :)
12:26 < BlueMatt> just make sure its not an obvious "oh, thats broken" kind of thing
12:26 < wumpus> 11126 is an issue that only affects DEBUG_LOCKORDER in ithe initialization; nothing else is running at that moment
12:26 < wumpus> so it doesn't cause any real issue
12:26 < BlueMatt> ah, ok, i hadnt investigated it significantly
12:27 < cfields> i've had a few crashes lately that i mentioned here i think. I've finally been able to track them down to local changes. So, no concern for 0.15.
12:27 < BlueMatt> hmmmm, looks like dooglus' qt crash is the same one I couldnt debug
12:27 < BlueMatt> i wonder if he's also running qt over X forwarding
12:27 < BlueMatt> that appears to make it more likely
12:27 < jonasschnelli> Seems like a free/alloc race in the table weak loading
12:28 < BlueMatt> it doesnt appear to be harmful, at least, some race in setting the table sort order or something like that
12:28 < jonasschnelli> Could also be a Qt bug
12:28 < BlueMatt> indeed, could be
12:28 < BlueMatt> mine was 9883
12:29 < jonasschnelli> They are related
12:29 < jonasschnelli> setSortingEnabled()
12:29 < jonasschnelli> I'll investigate
12:29 < BlueMatt> thanks
12:29 < jtimon> the deault of one is a function of what you set in another? that interaction should definitely go away asap, ideally to me by removing the size one, I don't care the weight default is 2000000 or whatever
12:30 < jonasschnelli> If its racy,.. could be due to a large wallet
12:30 < jonasschnelli> (many txns)
12:30 < wumpus> #9883 crashed in the leveldb iter?!
12:30 < BlueMatt> the wallet I saw that on is not so large...maybe 1k txn?
12:30 < wumpus> oh wait, wrong thread, that was just going on at the time
12:30 < jonasschnelli> wumpus: not that I know...  I think it crashes via setSortingEnabled
12:31 < jonasschnelli> QTableView::setSortingEnabled(bool) -> QCollator::QCollator(QLocale const&
12:31 < BlueMatt> dooglus also has some crashes where quick-exit races openssl mutex unlocking....I assume that is an openssl bug or so
12:31 -!- bitstein [~bitstein@unaffiliated/bitstein] has joined #bitcoin-core-dev     
12:31 < BlueMatt> its the old mutex-locked-during-destruction crash, though, so not harmful
12:31 < wumpus> jonasschnelli: yes, I see now, that's a more recognizable trace
12:31 < BlueMatt> just a scary warning
12:32 < wumpus> is something outside the GUI thread calling Qt functions perhaps?
12:32 < jonasschnelli> BlueMatt: your 9883, self compiled Qt? What version?
12:32 < BlueMatt> yes...uhhh, sec
12:32 < BlueMatt> wumpus: that was my assumption
12:32 < wumpus> if so, that can explain the crashes with remote X, as well as this
12:32 < BlueMatt> jonasa: qt5 something
12:32 < wumpus> *only* the GUI thread may call Qt GUI functions, the rest should queue signals on the GUI thread
12:33 < wumpus> I haven't seen any violation of that, though
12:33 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Quit: Leaving.]     
12:33 -!- jimmysong__ is now known as jimmysong     
12:33 < jonasschnelli> wumpus: Yeah. But that would very likely show another thread calling a relevant Qt function during the crash
12:33 < jonasschnelli> (which it doesn't)
12:35 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
12:35 < wumpus> PSA regarding 0.15.0 final - I will not be able to tag releases while in the US, and I'm leaving wednesday night 30th, and return to NL the 12th
12:35 < BlueMatt> anyway, it appears to be an only-at-startup thing and afaict, at least for me is a very reliable either-crashes-or-works-fine thing, so I'm still not too worried
12:35 < wumpus> jonasschnelli: you'd say so, but not necessarily, it could just mess up some internal table state, or even internal X state
12:35 < BlueMatt> (hence the closure of the original bug, may be a qt bug)
12:35 < achow101> wumpus: so, final this week?
12:36 < jonasschnelli> wumpus: Yes. Possible.
12:36 < wumpus> achow101: yes, or second half of september
12:37 < gmaxwell> I would rather have 0.15 out sooner rather than later. so far I haven't seen any clear blockers.
12:37 < wumpus> and I guess we should work on 0.15.1 during coredev
12:37 < BlueMatt> gmaxwell: agreed
12:37 < jonasschnelli> wumpus: Yes. Ideally.
12:37 < wumpus> segwit wallet support etc
12:37 < jonasschnelli> Yes     
12:38 < luke-jr> wumpus: maybe tag locally, and delay pushing?
12:38 < wumpus> luke-jr: well it's more complicated, I could possibly push the tag, but I can't upload executables
12:38 < luke-jr> wumpus: there are others who can, right?
12:38 -!- promag [~Adium@2001:8a0:fe30:de01:4068:3ca3:c1e9:d741] has joined #bitcoin-core-dev     
12:39 < jonasschnelli> I think wumpus should do it.
12:39 < wumpus> yes, but they'll have to us their own release signing key
12:39 < jonasschnelli> It's just 12 days (max +/-)
12:39 < BlueMatt> luke-jr: no (I mean theoretically we can *give* others access, but I see no reason to do so at this time)
12:39 < achow101> I think we should sign with a differnt release key and see if anyone notices :)
12:39 < meshcollider> yeah wumpus should do it, its not that time critical
12:39 < jonasschnelli> achow101: they will...
12:39  * luke-jr shrugs
12:39 < wumpus> oh people notice, my mail was full after stupping using my personal key for that
12:40 < wumpus> even though it was announced on the mailing lists etc
12:40 < wumpus> anyhow... let's release 0.15.0 soon if possible
12:40 < wumpus> if there's still something you'd like to debug over the weekend I can wait until after that
12:40 < BlueMatt> anyway, so I have no objections to tagging 0.15 this weekend/tomorrow if no other issues come up in that time
12:41 -!- promag [~Adium@2001:8a0:fe30:de01:4068:3ca3:c1e9:d741] has quit [Client Quit]     
12:41 < wumpus> but hearing that cfields's concerns were with local code puts me at ease a bit about 0.15.0 at least :)
12:41 < luke-jr> the lock issue can probably be ignored, I guess?
12:41 < wumpus> luke-jr: not ignored, just fixed on master and next 0.15 branch release
12:41 < luke-jr> sure, that's what I mean. ignored for 0.15.0
12:42 < luke-jr> would be nice to get a test that reproduces it, but I'm not sure how
12:42 < wumpus> well as I understand it there are no threads in flight yet at that point
12:42 < gmaxwell> we understand it, it shouldn't block the release. (it's in init)
12:42 < cfields> wumpus: if that puts you at ease, i should invent some local problems and solve them more often :)
12:42 < meshcollider> 😂
12:42 < BlueMatt> lol     
12:42 < wumpus> cfields: haha!
12:43 < wumpus> can cfields create an issue even cfields cannot debug
12:43 < cfields> haha
12:43 < wumpus> ok, any other topics?
12:43 < BlueMatt> Segwit is active!
12:43 < sipa> what? how?!
12:44 < wumpus> yeah! we can remove the point 'activate segwit' from the weekly agenda
12:44 < BlueMatt> heh     
12:44 < kanzure> i have a topic. it can wait.
12:44 < luke-jr> what is it waiting for?
12:44 < wumpus> ther's only 15 minutes left so don't wait too long
12:44 < kanzure> i am collecting topic ideas for coredev.tech meetup. either pm me with things you want to see or in here.
12:44 < kanzure> and i will publish small document somewhere
12:44 < wumpus> segwit wallet support
12:44 < kanzure> it's not a schedule. just a braindump sorta.
12:44 < kanzure> oh.     
12:44 < kanzure> okay added
12:45 < wumpus> (which is very general, probably should be divided up...)
12:46 < jonasschnelli> kanzure: thanks for collecting stuff for the CoreDev.tech in SF!
12:46 < kanzure> sure
12:46 < jnewbery> wumpus: I'd like #11053 to be reopened / reconsidered
12:47 < wumpus> GUI support, bech32 yes/no for this release, etc
12:47 < jnewbery> refactor: Make all #includes relative to project root
12:48 < cfields> jnewbery: +1. I think my concerns there were mistaken for a NACK. I pretty much regret bringing them up.
12:48 < luke-jr> wumpus: eh, at least sending bech32 seems a necessity
12:48 < wumpus> cfields: no, not really, it just made me reconsider whether it's really a good idea
12:48 < wumpus> cfields: ideally we'd clear out src and move everything to subdirs
12:49 < cfields> wumpus: agree with that.
12:49 < wumpus> cfields: on the other hand this doesn't make things worse at least
12:49 < wumpus> cfields: #include "" is severly misused in our source code
12:49 < bitcoin-git> [bitcoin] sipa closed pull request #11128: Make Bitcoin Core compatible with NYA segwit2x (master...s2x) https://github.com/bitcoin/bitcoin/pull/11128
12:50 < wumpus> if used it should be used to include relative to the directory of the source file, but it's used as a kind of wildcard include
12:50 < wumpus> *find it somewhere!*
12:51 < bitcoin-git> [bitcoin] laanwj reopened pull request #11053: refactor: Make all #includes relative to project root (master...2017_08_includes_absolute) https://github.com/bitcoin/bitcoin/pull/11053
12:51 < gmaxwell> 12:44:01 < wumpus> yeah! we can remove the point 'activate segwit' from the weekly agenda
12:52 < wumpus> anyhow reopening the pull, it wasn't my intent to stop discussion on it, just to make it clear there's no urgency in mergin a certain solution
12:52 < gmaxwell> we should also go dig up the wallet improvements we couldn't make without segwit... and start working on them. :)
12:52 < instagibbs> wumpus, oh thought you just implemented those changes just now, haha
12:52 < jnewbery> thanks wumpus
12:52 < gmaxwell> (perhaps see the log of the meeting where we added that item)
12:52 < cfields> wumpus: agreed, i just don't see a ton of benefit in changing something that works
12:52 -!- Bluewolf33 [~miker@2601:18d:4701:1f53:1eb6:508a:883e:319d] has quit [Ping timeout: 255 seconds]     
12:52 < cfields> however, if benches show that it's noticibly faster, i'm all for it :)
12:53 < wumpus> cfields: well the current state prevents having files with the same name in multiple places in the tree sanely
12:53 < sipa> cfields: eh, what are you talking about?
12:53 < gmaxwell> how are include paths going to change the speed of anything?
12:53 < wumpus> cfields: that's what kind of triggered this, we can't have wallet/init.h and init.h right now because #include "" as we use it now gets confused
12:53 < wumpus> gmaxwell: it can reduce the amount of probing the compiler has to do
12:54 < meshcollider> (compile speed not runtime speed)
12:54 < cfields> wumpus made that point ^^ in the PR, i believe
12:54 < gmaxwell> okay, I'll look at the PR then.
12:54 < wumpus> gmaxwell: e.g. including "primitives/primitives.h" in "primitvies/transaction.h" makes it look in primitives/primitives/transaction.h
12:54 < wumpus> gmaxwell: which can affect compile speed in some setups
12:54 < wumpus> gmaxwell: it's not the primary reason for making the change, though
12:55 < BlueMatt> ok, other topics?
12:56 < cfields> anyway, i'm happy to see it reopened
12:56 < luke-jr> how about meeting plans?
12:56 < luke-jr> or should we just discuss that in the dedicated channel later?
12:56 < sipa> yes     
12:56 < wumpus> I thin kthe best reason for it is that it makes it immediately clear where to look for a file to developers
12:56 < luke-jr> (specifically, are people sticking around Friday, or leaving as soon as it's over?)
12:56 < BlueMatt> luke-jr: dedicated channel, i think
12:56 -!- telberrak [51611256@gateway/web/freenode/ip.81.97.18.86] has joined #bitcoin-core-dev     
12:57 < wumpus> instead of eh, it's included with "", is it in the current dir? no? oh maybe it's under src/ directly
12:57 < meshcollider> which channel is that?
12:57 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
12:58 < kanzure> #bitcoin-core-dev
12:58 < jonasschnelli> ##     
12:58 -!- telberrak [51611256@gateway/web/freenode/ip.81.97.18.86] has quit [Client Quit]     
12:58 < kanzure> i didn't say what you thought i said
12:59 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
12:59 < kanzure> luke-jr: anyway there's enough people local to the area that you'll find friendlies even if the visitors leave.
12:59 < meshcollider> I guess there's some sort of filtering happening yae
13:00 < wumpus> and that concludes the meeting, thanks everyone
13:00 < wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Aug 24 20:00:11 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.log.html
13:00 < wumpus> we can back to shouting at each other about default values now :)
13:01 < morcos> well re: the shouting, i think there is time to argue on github about the changes for next release
13:01 < morcos> what i'm more interested in is letting miners know what they need to do
13:01  * BlueMatt thinks we should just merge all currently open prs for 0.15 and see what happens
13:02 < kanzure> chaos branch?
13:02 < gmaxwell> luke-jr: I'm concerned that you seem to be fixated on size rather than on the greater goal of keeping bitcoin decenteralized, secure, usable. Size is increasingly not an interesting magic metric for that, moreover, single miners reducing their size does nothing to help here-- if it did there would be much less reason for a blocksize limit.
13:02 < cfields> morcos: let's forego some of the arguments and s/what they need to do/what their options are/ :)
13:03 < morcos> well i think the only option that has a legitimate chance of getting approved is something that says
13:03 < kanzure> gmaxwell: luke was arguing that his reasoning is directly related to IBD. perhaps IBD growth should be capped some other way in a more explicit way.
13:03 < morcos> If you want to just produce the blocks with the most fee that you can without limiting anyting about them more than required by consenus then you should do X
13:03 < cfields> morcos: yes, exactly.
13:04 < wumpus> BlueMatt: luckily that's never going to work, most PRs conflict with a few other PRs :)
13:04 < luke-jr> gmaxwell: there's only so much improvement that is possible. supposedly that's 17% per year, which gives us only room for 300-450k blocks. I don't think we have a magic leap to fix that..
13:04 < BlueMatt> wumpus: merge at random until the only remaining ones conflict, then resolve conflicts at random until it compiles :p
13:05 < kanzure> (would an IBD limiting value  get to safely ignore signatures for the same reason that a signature validation skip mechanism was implemented for firstpass?)
13:05 < gmaxwell> kanzure: the only thing that can save IBD is something like a utxo sync; any plausable blocksize results in a growth rate well in excess of computers/links getting faster, so its only a question of when things fail not if, absent. it.
13:05 < wumpus> BlueMatt: it would be kind of nice if github had a way of showing what PRs don't conflict, or *shudders* what the biggest subset of PRs would be that could be merged without conflicting 
13:05 < kanzure> well that's an interesting argument.
13:05 < gmaxwell> luke-jr: we do, stop syncing the whole history, and only sync the last year worth or whatever.
13:05 < morcos> luke-jr: do you have an opinion on Core making such a statement via tweet or blog post or both?  where X is set maxblockweight=4000000 and don't set maxblocksize
13:06 < luke-jr> gmaxwell: UTXO sync is a change to the security model, and you were just going after praxeology1 for wanting to work on it earlier unless I totally misunderstood that?
13:06 < kanzure> gmaxwell: ok then what about argument about limiting IBD until utxo commitment sync stuff
13:06 < gmaxwell> luke-jr: and as I mentioned in the meeting for many (perhaps most) IO costs in maintaining the chainstate dominate sync time, so witness size increases don't matterh much.
13:06 < luke-jr> morcos: yes, I think we shouldn't recommend things that harm Bitcoin.
13:06 -!- blznblzn2 [~blzn@2605:6001:f28d:e600:cf36:4af4:2baf:900a] has quit [Ping timeout: 246 seconds]     
13:06 < kanzure> well i think IBD concerns weren't about validation cost, mostly bandwidth over the interwebs
13:06 < morcos> i don't think my statement recommended anything
13:07 < kanzure> sorry, i mean, those specific IBD concerns
13:07 < gmaxwell> luke-jr: what is the security model of a bitcoin with no nodes?  But with the assumevalid approach I don't know that it's really a meaningful change in the security model.
13:07 < luke-jr> gmaxwell: we aren't only getting witness size increases with Segwit..
13:07 < morcos> i think it was just informing miners of how to do something that most of us (probably including you) guess that a lot of them want to do, without commenting on its "goodness"
13:07 < sipa> luke-jr: the worst case I/O effect of a block has not changed at all with SegWit
13:07 < cfields> luke-jr: if bitcoin is as fickle as a default setting, the value of that setting isn't the issue...
13:07 < luke-jr> morcos: that statement sounded like a recommendation. maybe a neutral blog post that explains how to get different policies configured would be fine
13:07 < sipa> luke-jr: the average just got closer to the worst case, which is a good thing
13:08 < gmaxwell> luke-jr: moreover the thing you're insisting on (maxsize) doesn't correlate with those IO costs well.
13:08 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/affe9271aa49...4ae6d0fbef60
13:08 < bitcoin-git> bitcoin/master b23549f John Newbery: [tests] add TestNodeCLI class for calling bitcoin-cli for a node
13:08 < bitcoin-git> bitcoin/master c6ec435 John Newbery: [tests] Add bitcoin_cli.py test script
13:08 < bitcoin-git> bitcoin/master 4ae6d0f MarcoFalke: Merge #10798: [tests] [utils] test bitcoin-cli...
13:08 < luke-jr> cfields: all the more reason we should make the default something advisable (or nothing at all)
13:08 < kanzure> surely it was bandwidth not IO concern?
13:08 < jtimon> luke-jr: if we delete the maxsize and set de default weight to 2MB, do you think many miners won't change it to 4MB ?
13:08 < gmaxwell> luke-jr: if you want to argue that maxsize=4m maxweight=3m .. at least that makes more sense (though I would disagree there too)
13:08 < morcos> luke-jr: at some point we have to consider what our customers (miners in this case) want.   i suppose we could just get jeff to tweet it, since they claim to be running his software anyway.
13:08 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10798: [tests] [utils] test bitcoin-cli (master...cli_tests) https://github.com/bitcoin/bitcoin/pull/10798
13:08 < morcos> maybe i'll just do that
13:08 < gmaxwell> kanzure: read faster. For a lot of systems they are _not_ bandwidth limited in IBD.
13:09 < kanzure> but is that luke's concern?
13:09 < gmaxwell> kanzure: they're chainstate IO limited, etc.
13:09 -!- Bluewolf33 [~miker@2601:18d:4701:1f53:1eb6:508a:883e:319d] has joined #bitcoin-core-dev     
13:09 < luke-jr> morcos: they can configure the settings for what they want; it doesn't mean we need to suggest what those should be, if it's against what others might want
13:11 < gmaxwell> It's a fact that setting in any way other than 4m vs 4m will be leaving money on the floor, potentially quite a lot.
13:12 < luke-jr> morcos: I think documenting how to use the settings is good. I don't think suggesting settings harmful to the network, over more benevolent settings, is good.
13:12 < luke-jr> gmaxwell: only if other miners set that
13:12 < luke-jr> no miners right now AFAIK set 4/4
13:13 < gmaxwell> luke-jr: no, you'll still miss out on what you could have earned even if no one else sets it.
13:13 < morcos> ok in the meantime i'm just going to tweet it myself in the event that some miners don't know, i think many would like to know what to do
13:13 < gmaxwell> which is why expecting people to set it some other way is unrealistic and has simply failed in the past.
13:13 < luke-jr> gmaxwell: you have a probability to get it next block of yours
13:13 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
13:14 < luke-jr> gmaxwell: do you disagree with #3229 ?
13:14 < luke-jr> (it was originally shot down by Hearn and Garzik)
13:15 < gmaxwell> I think it's phenominally dumb but better than the current behavior. (not really much of an endorsement)
13:15 -!- Bluewolf33 [~miker@2601:18d:4701:1f53:1eb6:508a:883e:319d] has quit [Ping timeout: 276 seconds]     
13:15 < luke-jr> sigh
13:17 < luke-jr> either miners are setting the config or not. if they are, then defaults don't matter, and we should either set what would be ideal, or require configuration. if they aren't, then the same conclusions make sense
13:17 < gmaxwell> I don't think these things should be configurable at all.
13:17 < gmaxwell> it's harmful to the network to have discrepencies.
13:18 < gmaxwell> Do we have a setting to set a maximum number of 1-bits in a seralized block. No.
13:18 < gmaxwell> Would we support such a setting if someone asked for one, ... almost certantly not.
13:18 < gmaxwell> discrepancies*
13:19 < sipa> if you want to less insane example; we also don't have a setting to control how many sigops in a block (which correlates much more strongly with actual cost to the network)
13:19 < gmaxwell> (I mean that for both weight and size, but especially size because it doesn't very map well to anything that matters and causes a lot of confusion)
13:19 < wumpus> we wouldn't add it, but if we had such an option since the beginning, then removing it would still be difficult
13:19 < luke-jr> size does matter though
13:20 < sipa> luke-jr: yes, a bit
13:20 < luke-jr> at the very least, there is the clear case of the blocksonly node
13:20 < sipa> so do many other things
13:20 < gmaxwell> it's easy to demonstrate that the size option is seriously confusing people; they think it's controls the "legacy block size" and that if they set it over 1mb their blocks will be invalid. :( so much disinformation spread by people like garzik means that people are primed to have a screwed up understanding, and it's not like it's especially clear even without being setup to fail.
13:20 < gmaxwell> luke-jr: what about the blocksonly node?
13:21 < luke-jr> gmaxwell: its bandwidth requirement is primarily affected by the block sizes
13:21 < gmaxwell> luke-jr: it matters a small bit yes, but other things matter a lot more.
13:21 < sipa> luke-jr: let's work on compressed blocks then
13:22 < gmaxwell> luke-jr: you can reduce its bandwidth requirement by almost 30%, in a way that isn't economically unstable and won't fail in a couple months,  by helping finish the compacted seralization.  But do you work on that? No.  You throw rocks here and emotionally exhaust people who are working on things like that.
13:22 < luke-jr> compressed blocks are going to make 100% year-over-year improvements? :/
13:23 < praxeology1> True or false... 0.14.2 nodes by default currently limit the weight to 4M?
13:23 < sipa> praxeology1: to 3M
13:23 < sipa> praxeology1: for mining, that is
13:23 < sipa> the consensus rules are obviously not configurable
13:23 < gmaxwell> luke-jr: expecting to trick miners with a default that works against their interests isn't going to meaningfully keep the size down, all it's going to do is amplify segwit 2x drama. 
13:23 < luke-jr> gmaxwell: it's not a trick
13:24 < wumpus> tip: you can see the default for every option with bitcoind --help
13:24 < praxeology1> sipa: yea I am talking about consensus rules, not what miners create by default
13:24 < sipa> praxeology1: that's entirely offtopic
13:24 < sipa> and irrelevant here
13:25 < wumpus> praxeology1: huh, then you shouldn't ask 'by default'
13:25 < luke-jr> praxeology1: the consensus rule is max weight of 4M.
13:25 < gmaxwell> wumpus: elsewhere he's suffering the "but if miners set things higher they'll produce invalid blocks" confusion.
13:25 < wumpus> (unless you mean this in the extremely twisted sense of 'without source code changes'? )
13:25 < sipa> praxeology1: the weight, which is defined as 3*witsize + basesize must be less than 4M
13:26 < sipa> praxeology1: that implies that basesize must be less than 1M
13:26 < praxeology1> I'm trying to find out what you guys are talking about... it wasn't clear to me that "maxweight" configuration doesn't effect the consensus rule
13:26 < sipa> praxeology1: we're only talking about the mining code
13:26 < gmaxwell> sipa: don't use witsize as your variable. sounds like the size of the witnesses.
13:26 < sipa> -blockmaxsize and -blockmaxweight control the size of blocks the mining code produce
13:27 < sipa> but the mining code will never ever produce a consensus-invalid block, regardless of settings
13:27 < gmaxwell> praxeology1: consensus rules are not configurable because that would be extremely negligant, incompetent, and pointless.
13:27 < gmaxwell> negligent*
13:27  * luke-jr notes miners could set blockmaxsize=8000000 safely
13:27 < BlueMatt> eg https://eprint.iacr.org/2017/686.pdf (as to why making consensus limits configurable is an astoundingly stupid idea)
13:27 < morcos> sipa: i think you got your formula wrong there
13:27 < gmaxwell> or 16123123
13:27 < gmaxwell> morcos: by witsize he means the total size of the block.
13:28 < morcos> oh     
13:28 < gmaxwell> he should have said 3*size + stripped size.
13:28 < sipa> sorry, by witsize i meant "size including witnesses"
13:28 < morcos> isn't that still wrong
13:28 < sipa> yes.
13:28 < luke-jr> (3 * stripped size) + size
13:28 < morcos> thanks luke
13:28 < gmaxwell> derp.
13:28 < gmaxwell> yea.
13:29 < morcos> i can't wait to read r/btc tonight
13:29 < luke-jr> I'm thinking of unsub'ing r/btc
13:29 < BlueMatt> lol, you're just *now* thinking of that?
13:30 < luke-jr> tbf, not just now. ;)
13:32 < clarkmoody> gmaxwell sipa Can you guys look at https://github.com/bitcoin/bips/pull/553 ?
13:32 < praxeology1> sipa: gmaxwell: ok, its clear to me know what you guys are talking about...  thanks.  Sorry for injecting myself into the conversation, now I see I don't even care about it (has nothing to do with consensus rules)
13:43 -!- bitstein [~bitstein@unaffiliated/bitstein] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
13:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
13:49 < praxeology1> gmaxwell: given one was using rolling utxo hashes to verify the state of a utxo snapshot...  what kind of data structure would be used to store old snapshots for new nodes to synch from?
13:51 < praxeology1> maintaining such a data structure w/ no block height delay on the hash... sounds hard
13:54 < praxeology1> Make the heights one can synch from periodic instead of each block.  Store the spends in a new DB for that specific snapshot height.  remember the block height for new utxos in the current chainstate
13:57 < praxeology1> So then to reproduce the utxos at a given height... its the set of spent txs in that snapshot's DB, plus any utxo in the current chainstate from a block <= given height.
13:59 < sipa> praxeology1: our database already supports snapshotting
14:00 < sipa> so make a snapshot, then process that snaoshot in the background into a compact utxo representation, and continue with normal procoessing
14:00 < sipa> and yes, periodically
14:01 < praxeology1> sounds good to me
14:02 < praxeology1> then we just need some kind of standardization on how the "compact utxo representation" is hashed so that people can download from multiple sources piecewise
14:03 < sipa> yes     
14:03 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
14:05 -!- bitstein [~bitstein@unaffiliated/bitstein] has joined #bitcoin-core-dev     
14:06 < praxeology1> Hopefully also some automated process for people to generate these utxo hashes, and communicate them over insecure networks
14:06 < praxeology1> Or is there talk bout making it a commitment?
14:09 < praxeology1> *trying to get a feel for the core dev's current position on this... thinking it might be a touchy subject
14:09 < sipa> i think it's gettingna bit offtopic here
14:10 < praxeology1> Well, whether the rolling utxo hash was committed on, or was communicated outside of blocks... would have a big impact on... how it was communicated
14:11 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
14:13 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
14:13 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #11129: [qa] util: Poll cookie file size before reading (master...Mf1708-qaPollCookie) https://github.com/bitcoin/bitcoin/pull/11129
14:13 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
14:13 < praxeology1> Where would it be on topic?
14:17 < sipa> mailing list
14:17 < sipa> or bitcoin-wizards
14:25 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has quit [Quit: See ya...]     
14:25 -!- bitstein [~bitstein@unaffiliated/bitstein] has quit [Quit: Textual IRC Client: www.textualapp.com]     
14:34 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4ae6d0fbef60...77fc469fc78c
14:34 < bitcoin-git> bitcoin/master cd0ea48 Matt Corallo: Changing -txindex requires -reindex, not -reindex-chainstate
14:34 < bitcoin-git> bitcoin/master 77fc469 MarcoFalke: Merge #11108: Changing -txindex requires -reindex, not -reindex-chainstate...
14:35 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #11108: Changing -txindex requires -reindex, not -reindex-chainstate (master...2017-08-fix-reindex-txindex-err) https://github.com/bitcoin/bitcoin/pull/11108
14:48 < bitcoin-git> [bitcoin] jtimon closed pull request #9271: There's two types of flags: consensus and script (master...0.13-consensus-flags-error) https://github.com/bitcoin/bitcoin/pull/9271
14:53 -!- Bluewolf33 [~blue@2601:18d:4701:1f53::331a] has joined #bitcoin-core-dev     
14:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
14:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
14:55 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
14:58 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
14:59 -!- Cryptocide [~Cryptocid@109.200.4.114] has quit [Ping timeout: 246 seconds]     
14:59 -!- Cryptocide [~Cryptocid@96.44.147.34] has joined #bitcoin-core-dev     
15:01 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
15:03 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
15:03 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
15:09 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]     
15:27 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]     
15:27 < meshcollider> 8:21 am <sipa> luke-jr: let's work on compressed blocks then
15:27 < meshcollider> What's the current to-do for them?
15:28 < sipa> morcos: designing, experimenting, implementating :)
15:28 < sipa> s/morcos/meshcollider/
15:29 < luke-jr> it's too bad the UTXO set doesn't store the absolute output index in the blockchain
15:29 < sipa> luke-jr: it's easy enough to add if that's needed
15:29 < luke-jr> sipa: wouldn't it require a re-sync for all pruned nodes?
15:30 < luke-jr> otoh, maybe there's some way to do a gradual upgrade..?
15:33 < meshcollider> sipa: doesn't BIP 152 cover at least the design step? Or is it still being thought out
15:33 < sipa> meshcollider: bip152 is completely unrelated
15:33 < sipa> meshcollider: we're just talking about an efficient encoding for transactions
15:33 < sipa> luke-jr: if you really mean absolute index, yes
15:34 < sipa> hmm, even for relative index in the block
15:34 < luke-jr> relative index isn't quite as useful
15:34 < luke-jr> I was thinking have all the inputs just address by index
15:35 < meshcollider> Oh am I confusing compressed blocks with compact blocks
15:35 < luke-jr> I suppose relative index in the sense of "<this tx abs index> - <relative index> = <input's TXO abs index>" might be good
15:35 < luke-jr> might make varint more optimal
15:35 < gmaxwell> luke-jr: I can't figure out what you're talking about.
15:35 < luke-jr> I suppose a per-block index might also be combinable with UTXO height, but I don't see a clear advantage to that
15:36 < luke-jr> gmaxwell: replace the input txid+index with an absolute tx index in the blockchain
15:36 < gmaxwell> how does that have anything to do with the utxo set?
15:37 < luke-jr> you'd need to store/index by the absolute tx index to do the lookup
15:37 < luke-jr> saying blockchain tx #1934 isn't useful unless the node can easily figure out what tx that is
15:37 < luke-jr> utxo*
15:37 < gmaxwell> I think what you're trying to suggest is this: make a transfered block smaller by rekeying its inputs with indexes.
15:37 < sipa> luke-jr: i think needing a UTXO set in order to just decompress a block is already a no-go
15:37 -!- Cryptocide [~Cryptocid@96.44.147.34] has quit [Ping timeout: 248 seconds]     
15:37 < gmaxwell> I think all you need is an index to txid table, seperate from the utxo set. Which you can build on the fly as you sync.
15:38 < sipa> luke-jr: as that means an attacker can make you do arbitrarily much I/O before you can figure out PoW
15:38 -!- Cryptocide [~Cryptocid@96.44.145.26] has joined #bitcoin-core-dev     
15:38 < gmaxwell> but as sipa is pointing out it would be a layering mess.
15:38 < sipa> s/figure out/validate/
15:38 < luke-jr> hm     
15:39 < gmaxwell> luke-jr: the compacted seralization I proposed (which sipa later refined) reduces tx sizes by around 28% without doing anything like that, working just one tx at a time... so it's useful for loose transction relay as well as blocks.
15:39 < gmaxwell> yes, there is a lot more savings if you could replace txin hashes with indexes, but ... layering mess.
15:40 < luke-jr> what if we add a commitment to the index-based format?
15:40 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
15:40 < gmaxwell> yes, we could do something like have a compressed block, format where there was a tree-root in the software, assume valid style, no commitment needed.
15:41 < gmaxwell> but: I think we'd better off spending effort on from utxo sync (needed to escape eventual doom); or on compact seralization (works also for loose transaction relay)
15:42 < meshcollider> gmaxwell: is your serialisation format posted anywhere? Sorry I'm just catching up 
15:43 < gmaxwell> meshcollider: yes, but sipa's revised version is better and I don't think thats posted anywhere.
15:44 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
15:44 < sipa> https://gist.github.com/sipa/1d29c1019e00874a61e533b2b050046f
15:44 < sipa> very much WIP
15:49 -!- Guest79199 [~smuxi@2600:8805:3a01:ac00:88ff:9870:5bbb:2362] has quit [Remote host closed the connection]     
15:49 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
15:50 < morcos> damn, i skipped down to Analysis
15:53 < sipa> haha
15:54 -!- hasten [~Mutter@2607:fb90:4c48:c7ab:3195:124d:813f:62e8] has joined #bitcoin-core-dev     
15:55 < jimpo> I'm looking into writing a P2P test for this: https://github.com/bitcoin/bitcoin/pull/11113
15:55 < jimpo> What's the best way from the test framework to fast-forward time or create blocks in the future
15:56 < jimpo> or start the chain with blocks far in the past would work too
15:57 -!- hasten [~Mutter@2607:fb90:4c48:c7ab:3195:124d:813f:62e8] has quit [Client Quit]     
16:04 -!- Aaronvan_ is now known as AaronvanW     
16:06 < jimpo> nvm, I found the setmocktime method
16:09 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 252 seconds]     
16:15 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
16:16 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
16:18 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
16:20 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
16:27 < gmaxwell> morcos: IIRC sipa's version is ~28% size reduction for the history.
16:28 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
16:35 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
16:36 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 248 seconds]     
16:39 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
16:47 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
16:49 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 252 seconds]     
16:55 -!- sniip3r [90d94a18@gateway/web/freenode/ip.144.217.74.24] has joined #bitcoin-core-dev     
16:56 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
16:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
17:14 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit []     
17:19 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev     
17:23 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
17:29 -!- promag [~Adium@2001:8a0:fe30:de01:4068:3ca3:c1e9:d741] has joined #bitcoin-core-dev     
17:32 -!- pandabull [~pandabull@2601:184:407f:de69:c970:353b:bd94:b6c] has joined #bitcoin-core-dev     
17:32 -!- pandabull [~pandabull@2601:184:407f:de69:c970:353b:bd94:b6c] has quit [Client Quit]     
17:33 -!- promag [~Adium@2001:8a0:fe30:de01:4068:3ca3:c1e9:d741] has quit [Client Quit]     
17:34 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
17:34 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]     
17:35 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Client Quit]     
17:37 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:41 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has quit [Quit: Page closed]     
17:42 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 248 seconds]     
17:42 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
17:46 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
17:49 -!- jtimon [~quassel@173.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]     
17:53 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Quit: Leaving.]     
17:54 -!- owowo [ovovo@gateway/vpn/mullvad/x-yllnaodbjkxnytpd] has joined #bitcoin-core-dev     
17:56 -!- LeandroBellini [b39f39ab@gateway/web/freenode/ip.179.159.57.171] has joined #bitcoin-core-dev     
17:57 -!- praxeology1 [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has quit [Ping timeout: 252 seconds]     
17:57 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
17:58 -!- LeandroBellini [b39f39ab@gateway/web/freenode/ip.179.159.57.171] has quit [Client Quit]     
17:59 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
18:00 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Client Quit]     
18:01 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
18:02 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/77fc469fc78c...3f726c99f819
18:02 < bitcoin-git> bitcoin/master f1708ef practicalswift: Add recommendation: By default, declare single-argument constructors `explicit`
18:02 < bitcoin-git> bitcoin/master 3f726c9 MarcoFalke: Merge #11112: [developer-notes] By default, declare single-argument constructors "explicit"...
18:03 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #11112: [developer-notes] By default, declare single-argument constructors "explicit" (master...declare-single-argument-constructors-explicit) https://github.com/bitcoin/bitcoin/pull/11112
18:13 -!- sniip3r [90d94a18@gateway/web/freenode/ip.144.217.74.24] has quit [Quit: Page closed]     
18:13 -!- andreacab [6cb4e61c@gateway/web/freenode/ip.108.180.230.28] has joined #bitcoin-core-dev     
18:30 -!- andreacab [6cb4e61c@gateway/web/freenode/ip.108.180.230.28] has quit [Ping timeout: 260 seconds]     
18:33 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
18:58 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds]     
19:19 -!- instagibbs [~instagibb@pool-72-83-36-237.washdc.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
19:20 -!- instagibbs [~instagibb@pool-72-83-36-237.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
19:23 -!- Deadhand [~deadhand@2607:fea8:e380:10f::3] has quit [Ping timeout: 246 seconds]     
19:24 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 255 seconds]     
19:25 -!- sipa [~pw@2001:19f0:ac01:2fb:5400:ff:fe5b:c3ff] has joined #bitcoin-core-dev     
19:27 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
19:29 -!- Deadhand [~deadhand@CPEf0f249a14e43-CMf0f249a14e40.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev     
19:32 -!- praxeology [~praxeolog@cpe-76-187-87-73.tx.res.rr.com] has joined #bitcoin-core-dev     
19:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
19:39 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Quit: bye]     
19:39 -!- praxeology1 [~praxeolog@cpe-76-187-87-73.tx.res.rr.com] has joined #bitcoin-core-dev     
19:40 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
19:41 -!- praxeology1 [~praxeolog@cpe-76-187-87-73.tx.res.rr.com] has left #bitcoin-core-dev []     
19:42 -!- praxeology [~praxeolog@cpe-76-187-87-73.tx.res.rr.com] has quit [Ping timeout: 248 seconds]     
19:47 -!- praxeology1 [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
20:01 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
20:09 < luke-jr> hm, do we still warn about BIP91?
20:28 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
20:28 -!- Deadhand [~deadhand@CPEf0f249a14e43-CMf0f249a14e40.cpe.net.cable.rogers.com] has quit [Ping timeout: 248 seconds]     
20:28 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
20:31 < meshcollider> sipa: gmaxwell is the idea that the full serialised transaction has to be obtainable just from the compressed transaction, for hashing, etc? i.e. no throwing away of data even if it's unused but hashed?
20:31 -!- Deadhand [~deadhand@2607:fea8:e380:10f::3] has joined #bitcoin-core-dev     
20:39 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 268 seconds]     
20:45 < Lightsword> luke-jr, warn about what in regards to BIP91?
20:46 < sipa> meshcollider: indeed
20:46 < luke-jr> Lightsword: unknown versionbit deployment
20:47 < Lightsword> luke-jr, why would it be showing anything anymore? it didn’t use.a 2016 block activation period so it shouldn’t show as activated
20:49 < Lightsword> hmm, well I do see “Warning: Unknown block versions being mined! It's possible unknown rules are in effect” but that’s not a version bit specific warning right?
20:49 -!- Deacyded [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
20:49 < Lightsword> warning='59 of last 100 blocks have unexpected version'
20:50 < sipa> Lightsword: those are from miners who are still signalling segwit
20:50 < sipa> not bip91
20:50 < Lightsword> yep…guess I’ll tell them to turn that off
20:52 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 240 seconds]     
21:03 < luke-jr> ah     
21:10 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
21:10 < gmaxwell> meshcollider: because the hashes are normative there is no unused data.
21:17 -!- promag [~Adium@bl22-247-244.dsl.telepac.pt] has quit [Quit: Leaving.]     
21:18 < meshcollider> i mean unused in the sense of having no actual function, not just unused in general. E.g. the transaction locktime, if all the sequence numbers are set to 0xffffffff
21:19 < gmaxwell> meshcollider: almost always the locktime is zero in that case, however.
21:23 < meshcollider> yeah I'd imagine so, so most of the time it would be encoded in the TxHeader in that case right 👍
21:25 < meshcollider> what is the reason for choosing 0-14 for the nLockTime = TxVersionCode? Why 14?
21:30 < gmaxwell> that is a misprint, that is nVersion = TxVersionCode.
21:30 < gmaxwell> (because why would nLocktime be _versionCode_ :) )
21:31 < gmaxwell> so tx versions 0-14 are explicitly coded, and any version greater than that ends up as a uint32.
21:32 < meshcollider> mhm I did wonder haha, seemed odd. sipa, you might want to update that 
21:32 < gmaxwell> the document isn't really intended for public consumption.
21:33 < gmaxwell> (not to say that he won't fix it, but this is just working notes)
21:36 < meshcollider> regardless, was there any specific reason for choosing 14 for the version code?
21:37 -!- gmac83 [b23ef210@gateway/web/freenode/ip.178.62.242.16] has joined #bitcoin-core-dev     
21:38 < gmaxwell> because it room for plenty of transaction versions, and leaves space to signal future encoding versions.
21:40 -!- gmac83 [b23ef210@gateway/web/freenode/ip.178.62.242.16] has left #bitcoin-core-dev []     
21:42 -!- treebeardd [~treebeard@73.109.62.252] has joined #bitcoin-core-dev     
21:45 < meshcollider> makes sense :) are the blank sections not thought out or just not written up
21:46 < meshcollider> guessing the latter because back references sounds like something which wouldn't just be added in without a plan
21:53 < gmaxwell> it's just not written up. pieter implemented an encoder, which is how we know what the space savings is.
21:54 < gmaxwell> (actually it looks like all the parts are actually describe in the bulleted lists, but not explained)
22:03 -!- treebeardd [~treebeard@73.109.62.252] has quit [Quit: Leaving...]     
22:14 < meshcollider> it looks really well thought out and comprehensive to me, that's awesome :) so would compressed blocks just have a new compressed block header and contain compressed transactions like this?
22:16 < luke-jr> meshcollider: blocks aren't typically transmitted as a big data blob anymore anyway
22:16 < gmaxwell> except in ibd.
22:16 < gmaxwell> it's just an alternative encoding of transactions, and blocks are transmited as a header and a bunch of transactions.
22:18 < meshcollider> Ah I guess block headers are only 80 bytes anyway, probably not worth even trying to compress them more?
22:18 < luke-jr> they're already compressed somewhat IIRC
22:18 < gmaxwell> well for headers messages it's useful to compact them, but thats pretty orthorgonal to blocks.
22:18 < luke-jr> (when sent as a chain, the prevblock part is skipped)
22:19 < gmaxwell> in a message that sends a lot of headers you can roughly halve their size.
22:25 -!- laurentmt [~Thunderbi@115.31.156.105] has joined #bitcoin-core-dev     
22:25 -!- laurentmt [~Thunderbi@115.31.156.105] has quit [Client Quit]     
22:41 -!- Bluewolf33 [~blue@2601:18d:4701:1f53::331a] has quit [Ping timeout: 246 seconds]     
22:58 -!- Bluewolf33 [~blue@2601:18d:4701:1f53::331a] has joined #bitcoin-core-dev     
23:02 -!- Bluewolf33 [~blue@2601:18d:4701:1f53::331a] has quit [Ping timeout: 246 seconds]     
23:42 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has quit [Read error: Connection reset by peer]     
23:45 -!- laurentmt [~Thunderbi@115.31.156.105] has joined #bitcoin-core-dev     
23:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
23:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
23:51 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:59 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has joined #bitcoin-core-dev