--- Log opened Thu Jan 10 00:00:16 2019 00:18 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev 00:48 -!- jarthur [~jarthur@2605:6000:1019:41ab:51e7:47b4:376f:2e97] has quit [] 00:52 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 00:54 -!- rhavar_ [uid237883@gateway/web/irccloud.com/x-botsrafsdwpgqwzk] has quit [Quit: Connection closed for inactivity] 01:09 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 01:12 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:20 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 01:28 -!- aqquadro [~name@net-37-159-134-26.cust.vodafonedsl.it] has joined #bitcoin-core-dev 01:28 -!- aqquadro [~name@net-37-159-134-26.cust.vodafonedsl.it] has quit [Changing host] 01:28 -!- aqquadro [~name@unaffiliated/aqquadro] has joined #bitcoin-core-dev 01:46 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has joined #bitcoin-core-dev 01:46 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 01:51 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has quit [Ping timeout: 264 seconds] 01:52 -!- newbie111 [4e3ee998@gateway/web/freenode/ip.78.62.233.152] has joined #bitcoin-core-dev 01:52 < newbie111> hi ALL 01:54 -!- gekisai [~gekisai@203.109.150.153] has joined #bitcoin-core-dev 01:54 -!- newbie111 [4e3ee998@gateway/web/freenode/ip.78.62.233.152] has quit [Client Quit] 02:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:06 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:07 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 02:07 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Client Quit] 02:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 02:12 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-ouwsaysynjrgsdxg] has joined #bitcoin-core-dev 02:21 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 02:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:29 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 02:34 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 02:34 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 02:35 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 02:36 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 02:36 < meshcollider> gkrizek: we dont need branches 0.11, 0.12 or 0.13 anymore btw, only 14+ 02:55 < wumpus> good point, I cleaned up those branches to keep the number of branches from getting out of hand, as there's no active development expected on them anymore 02:59 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 03:05 -!- gekisai [~gekisai@203.109.150.153] has quit [Remote host closed the connection] 03:07 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has quit [Ping timeout: 250 seconds] 03:08 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev 03:21 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 03:39 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection] 03:40 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 03:43 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has joined #bitcoin-core-dev 03:43 -!- gelmutshmidt [~gelmutshm@188.113.8.92] has joined #bitcoin-core-dev 03:48 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has quit [Ping timeout: 268 seconds] 03:56 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 04:17 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 256 seconds] 04:20 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 246 seconds] 04:21 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 04:25 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 245 seconds] 04:27 -!- miknotauro [~miknotaur@187.214.238.139] has quit [Ping timeout: 252 seconds] 04:33 -!- mg0314b [~mg0314b@li1767-237.members.linode.com] has joined #bitcoin-core-dev 04:38 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 04:38 -!- mg0314b [~mg0314b@li1767-237.members.linode.com] has quit [Quit: Igloo IRC: https://iglooirc.com] 04:46 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 05:01 -!- mistergold [~mistergol@77.243.31.171] has joined #bitcoin-core-dev 05:30 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 05:40 -!- anome [~anome@unaffiliated/anome] has quit [Ping timeout: 240 seconds] 05:50 -!- Aaronvan_ is now known as AaronvanW 05:54 -!- VK86GER [95acfeda@gateway/web/freenode/ip.149.172.254.218] has joined #bitcoin-core-dev 05:59 -!- Cchadwicka [~ident@c-71-238-229-151.hsd1.ar.comcast.net] has joined #bitcoin-core-dev 06:05 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 06:05 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 06:06 -!- VK86GER [95acfeda@gateway/web/freenode/ip.149.172.254.218] has quit [Quit: Page closed] 06:08 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 06:11 -!- benthecarman [~benthecar@89.39.107.195] has joined #bitcoin-core-dev 06:12 < benthecarman> Is there an easy to way get a CTransaction from a CWalletTx 06:15 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:19 -!- lnostdal [~lnostdal@151.251.241.67] has joined #bitcoin-core-dev 06:24 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.] 06:34 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev 06:34 < wumpus> benthecarman: the 'tx' field contains a pointer to the underlying CTransaction 06:34 -!- lnostdal [~lnostdal@151.251.241.67] has quit [Ping timeout: 258 seconds] 06:36 < benthecarman> Oh okay thnx 06:42 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 06:45 -!- mike_ [~mike@47.23.101.106] has joined #bitcoin-core-dev 06:45 -!- mike_ is now known as Guest51719 06:46 -!- lnostdal [~lnostdal@151.251.246.180] has joined #bitcoin-core-dev 07:11 -!- lnostdal [~lnostdal@151.251.246.180] has quit [Ping timeout: 246 seconds] 07:13 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 07:19 -!- Tralfaz [~none@185.156.175.59] has joined #bitcoin-core-dev 07:23 -!- lnostdal [~lnostdal@151.251.255.109] has joined #bitcoin-core-dev 07:27 -!- promag [~promag@83.223.251.46] has joined #bitcoin-core-dev 07:30 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev 07:38 -!- zenogais [~zenogais1@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-dev 07:45 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has joined #bitcoin-core-dev 07:49 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has quit [Ping timeout: 250 seconds] 07:53 -!- aqquadro [~name@unaffiliated/aqquadro] has quit [Quit: Leaving] 07:55 -!- lnostdal [~lnostdal@151.251.255.109] has quit [Ping timeout: 250 seconds] 07:57 -!- Cchadwicka [~ident@c-71-238-229-151.hsd1.ar.comcast.net] has quit [Quit: —I-n-v-i-s-i-o-n— 3.3 (November '11)] 08:07 -!- lnostdal [~lnostdal@151.251.242.110] has joined #bitcoin-core-dev 08:13 -!- promag [~promag@83.223.251.46] has quit [Remote host closed the connection] 08:13 -!- lnostdal [~lnostdal@151.251.242.110] has quit [Ping timeout: 258 seconds] 08:18 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 08:19 -!- mistergold [~mistergol@77.243.31.171] has quit [Ping timeout: 245 seconds] 08:22 < hebasto> promag: hi, should I close #14798 in favor of #15136? 08:22 < gribble> https://github.com/bitcoin/bitcoin/issues/14798 | qt: Fix deselecting peer when switching from peers to console tab by hebasto · Pull Request #14798 · bitcoin/bitcoin · GitHub 08:22 < gribble> https://github.com/bitcoin/bitcoin/issues/15136 | qt: "Peers" tab overhaul by hebasto · Pull Request #15136 · bitcoin/bitcoin · GitHub 08:23 < promag> you know my preference :D 08:23 < hebasto> yeap :) 08:23 < promag> hebasto: which behavior you prefer? 08:25 < hebasto> promag: I would not work on it if it seems useless for me. 08:26 -!- lnostdal [~lnostdal@151.251.251.52] has joined #bitcoin-core-dev 08:27 < promag> hebasto: then I think you should close the other one with some reasoning 08:31 < promag> see you in the meeting 08:31 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 08:31 < hebasto> promag: sure 08:32 -!- miknotauro [~miknotaur@187.214.238.139] has joined #bitcoin-core-dev 08:38 < gkrizek> meshcollider: wumpus: Ok, great. Thank you. I'm going to send messages when Tags are created as well. They are part of the same event type from GitHub and seem important info to message about 08:40 < achow101> gkrizek: that's a good idea. currently wumpus has to send that message himself 08:40 -!- lnostdal [~lnostdal@151.251.251.52] has quit [Ping timeout: 244 seconds] 08:40 < sipa> gkrizek: thank you for working on this 08:42 < wumpus> gkrizek: thanks, seems useful! 08:42 < gkrizek> Great, I think it would be too and since they are already part of the event it's almost no extra work. 08:44 < gkrizek> sipa: no problem! Happy to help. This will probably be a pretty minimal implementation at first because Services are officially EOL on the 31st. Just trying to get something to replace it for now, then can make it better later on. 08:48 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 08:54 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 09:03 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 09:05 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 09:13 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 09:21 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 09:31 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 09:32 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 09:34 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 09:43 -!- promag [~promag@83.223.249.210] has joined #bitcoin-core-dev 09:46 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has joined #bitcoin-core-dev 09:51 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has quit [Ping timeout: 264 seconds] 09:57 -!- sfhi [~sfhi@178.255.154.107] has joined #bitcoin-core-dev 10:00 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection] 10:00 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:04 -!- Giszmo [~leo@ip-95-228-107-190.nextelmovil.cl] has quit [Ping timeout: 246 seconds] 10:10 -!- miknotauro [~miknotaur@187.214.238.139] has quit [Ping timeout: 250 seconds] 10:19 -!- Giszmo [~leo@ip-240-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 10:19 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 10:25 -!- mistergold [~mistergol@185.37.25.172] has joined #bitcoin-core-dev 10:27 -!- Krellan [~Krellan@2601:640:4000:a876:6d65:bdf5:deb2:9a69] has quit [Remote host closed the connection] 10:28 -!- Krellan [~Krellan@2601:640:4000:a876:8f9:e371:1081:7908] has joined #bitcoin-core-dev 10:30 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:32 -!- Krellan [~Krellan@2601:640:4000:a876:8f9:e371:1081:7908] has quit [Ping timeout: 252 seconds] 10:46 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 11:00 < achow101> meeting? 11:00 < instagibbs> meeting. 11:00 < wumpus> #startmeeting 11:00 < lightningbot> Meeting started Thu Jan 10 19:00:32 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:00 < moneyball> hi 11:00 < sdaftuar> hi 11:00 < sipa> hi 11:00 < achow101> hi 11:00 < moneyball> fyi there weren't any proposed topics in IRC the past week 11:01 < jonasschnelli> hi 11:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb 11:01 < promag> hi 11:01 < jamesob> hi 11:01 < wumpus> any proposed topics now? 11:01 < wumpus> thanks for keeping track moneyball 11:01 < achow101> topic: moving hwi under bitcoin-core org 11:02 < wumpus> hwi? 11:02 < achow101> hardware wallet interface thingy 11:02 < instagibbs> https://github.com/achow101/HWI 11:02 < jnewbery> hi 11:02 < wumpus> ohh ofc 11:02 < wumpus> #topic high priority for review 11:02 < wumpus> https://github.com/bitcoin/bitcoin/projects/8 11:03 < sipa> can i has #14955 ? 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub 11:03 < wumpus> current ones: #11082 #14491 #14711 #14941 #14938 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub 11:03 < wumpus> sipa: sure 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14711 | Remove uses of chainActive and mapBlockIndex in wallet code by ryanofsky · Pull Request #14711 · bitcoin/bitcoin · GitHub 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14941 | rpc: Make unloadwallet wait for complete wallet unload by promag · Pull Request #14941 · bitcoin/bitcoin · GitHub 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14938 | Support creating an empty wallet by Sjors · Pull Request #14938 · bitcoin/bitcoin · GitHub 11:04 < sdaftuar> i'd like to request #15141 11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub 11:04 < jnewbery> I think everyone's scared of reviewing that! 11:04 < sdaftuar> it's already been reviewed a bunch, just never was merged :( 11:05 < wumpus> added 11:05 < sdaftuar> thanks 11:06 < wumpus> #topic moving hwi under bitcoin-core org (achow101) 11:06 < phantomcircuit> hi 11:06 < wumpus> #link https://github.com/achow101/HWI 11:06 < jonasschnelli> Maybe we can discuss #11082 since there was the discussion of JSON vs INI? 11:06 < gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub 11:06 < meshcollider> Hi 11:07 < achow101> so hwi is currently under my account. but if we are going to use it for hardware wallet support in core, then perhaps it would be better to have it under a proper github org. the obvious one that comes to mind is bitcoin-core 11:08 < wumpus> yes, that makes sense 11:08 < achow101> instagibbs: might have some thoughts on this? 11:08 < instagibbs> nothing against achow101 but also I'm actively using it and would be nice to be put under an established org 11:08 < instagibbs> ;) 11:08 < instagibbs> ACK in other words 11:09 < wumpus> no one seems to be opposed :) 11:09 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 11:09 < instagibbs> https://github.com/achow101/HWI/issues/91 for further background 11:09 < meshcollider> We should give achow merge permission on it imo 11:09 < wumpus> of course 11:10 < sipa> achow101: iirc there is a way to 'transfer' a repo to another org, that way github will automatically set up redirects etc 11:10 < sipa> as opposed to copying it over 11:10 < instagibbs> yep, just an organizational thing, with established review/merge norms/contributor docs 11:10 < wumpus> he might still want the local clone for his own PRs 11:10 < achow101> sipa: yes, there's a transfer ownership button 11:10 < jnewbery> #link https://help.github.com/articles/transferring-a-repository/ 11:10 < wumpus> but could create a new one as well 11:11 < wumpus> (clone it again after transfering) 11:11 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 11:11 < wumpus> any other topics? 11:11 < jimpo> BIP 157 index leveldb vs flatfiles? 11:12 < wumpus> ah yes jonasschnelli had one 11:12 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Client Quit] 11:12 < jonasschnelli> not an important one 11:12 < jonasschnelli> (and my internet connection goes up and down) 11:12 < wumpus> ok jimpo first then 11:12 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11082#issuecomment-451406061 11:12 < jonasschnelli> ack 11:12 < wumpus> #topic BIP 157 index leveldb vs flatfiles (jimpo) 11:13 < jimpo> So there's some discussion on #14121 11:13 < gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub 11:13 < jimpo> basically there's three options 1) store entire filters along with metadata in separate LevelDB 11:13 < jimpo> 2) store filter metadata (hash, disk pos) in levelDB and filters in flat files 11:14 < jimpo> 3) add filter metadata to CBlockIndex and store filters in flat files, just like undo data 11:14 < jimpo> In terms of perf, #3 is probably the fastest and certainly the fastest with enough IO optimizations 11:14 < gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub 11:14 < sipa> so the first question is between 1/2 and 3, i think; whether the filters are their own index semantically, or part of the main data structures 11:15 < jonasschnelli> What speaks against being part of the main data structure? 11:15 < jimpo> I prefer 1/2 since I can imagine alternate filter types 11:15 < jonasschnelli> (like option 3) 11:15 < sipa> and i guess that depends on how they'll be used; if they're mostly optional things that some people want to enable, a separate index is the obvious way to go 11:15 < jamesob> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/14121#issuecomment-451838178 11:15 < sipa> but if we envision it may become a consensus rule, having it separate is quite annoying 11:15 < jimpo> metadata is like 76 bytes (2 hashes + disk loc) 11:16 < jonasschnelli> From what I see is that there are plans to commit the filters at one point so it'll be part of the consensus, right? 11:17 < jimpo> it's more convenient to have it in CBlockIndex if part of consensus rules, yes, but I'm not sure how much worse the separate index is there 11:17 < sipa> i guess it isn't really 11:17 < jimpo> would have to do some synchronization or build the filters twice (but that's really fast) 11:17 < jimpo> like you can validate the consensus rule w/o storing the filter 11:17 < sipa> it can go from an asynchronously maintained one to a synchronous one perhap at that time, but still remain a separate db/directory 11:17 < jimpo> if you don't want to 11:17 < sipa> right 11:18 < jimpo> which is another strong (IMO) argument in favor of 1/2: not everyone needs to or should be forced to store filters 11:19 < jimpo> and no need to bloat CBlockIndex if people might disable it 11:19 < sipa> agree; i forgot about the possibility that even in case of it being consensus, there is no requirement to actually store the filters 11:20 < sipa> about the difference between 1 and 2... i prefer the flat files approach slightly (the filters aren't that big that using leveldb is insurmountable, but they're still append-only data like blocks/undo) 11:20 < sipa> and i saw you also have a PR to abstract out the flat files stuff, which seems useful in any case 11:20 < jimpo> I do agree that 2 is somewhat conceptually cleaner 11:21 < jimpo> but it does make the code more complex and is slower right now unless we add a caching layer to the flatfile stuff 11:21 < jamesob> we don't know how much slower though, right? might be negligible 11:22 < gmaxwell> I feel sketchy about adding a requirement to store blobs in leveldb, I think in the long run we won't end up using leveldb -- we now no longer need basically any interesting properties of it, it's just a MAP on disk for us now. 11:22 < gmaxwell> I'm confused that its slower or at least why it would be under actual use though. 11:22 < jamesob> gmaxwell: we might use snapshotting to alleviate lock contention at some point... 11:22 < gmaxwell> jamesob: you wouldn't say that if you'd actually tested snapshotting. 11:22 < jimpo> just two separate reads instead of 1 for each filter I think 11:23 < sipa> gmaxwell: but do you think that choosing to use leveldb right now will complicate a hypothetical move to using something else? 11:23 < jimpo> but there are certainly ways to reduce that overhead which I haven't experimented with 11:23 < gmaxwell> jimpo: why two seperate reads? 11:23 < jamesob> 1 for leveldb, then 1 for flatfile 11:23 -!- chenpo [~chenpo@118-160-51-129.dynamic-ip.hinet.net] has joined #bitcoin-core-dev 11:23 < jimpo> first read from the leveldb index to get the disk pos, then read the filter from flatfile 11:23 < sipa> well the leveldb part can be in memory, no? 11:23 < sipa> like CBlockIndex is now 11:23 < gmaxwell> Ah so it's directly reading the leveldb instead of having the index in memory like the block index is. 11:24 < jimpo> true, we could keep the whole index in memory 11:24 < jimpo> but shouldn't that be pretty much equivalent to setting the cache on the leveldb high enough? 11:24 < gmaxwell> I would be saying these pointers should just be in the blockindex. But there was some talk about switching this on and off above. 11:25 < gmaxwell> jimpo: not really, there are a bunch of overheads in the leveldb caching and it's not particularly intelligent. 11:25 < sipa> also a leveldb _read_ is not a single disk access 11:25 < sipa> (as opposed to something that hits a cache) 11:26 < jimpo> ok 11:26 < gmaxwell> it's quasi log(n) plus a bunch of rather expensive bloom filter checks, which is why I was surprised the flatfile was slower.. 11:26 < sipa> so with index in memory + flatfile you're guaranteed one disk seek always 11:26 < gmaxwell> but if your flatfile is a leveldb access plus the file now I see why it couldn't be faster. 11:26 < gmaxwell> since you take the ldb overheads in both cases. 11:26 < jimpo> gmaxwell yes it was leveldb + flatfile 11:27 -!- profmac [~ProfMac@2001:470:1f0f:226:b46a:e174:3d38:3b2e] has quit [Ping timeout: 250 seconds] 11:27 < jimpo> OK, so what if we have a leveldb index + flatfiles 11:28 < jimpo> then if that's slow we can add logic to pull the whole leveldb index into mem like the CChain structure 11:28 < jimpo> but as a separate structure 11:28 < sipa> is that easier than doing it immediately? (i'm thinking about dealing with the possibility of leveldb read failure outside of startup etc) 11:29 < jimpo> yes, it definitely breaks up the size of the code change 11:29 < gmaxwell> sipa: I think right now our leveldb usage can be replaced with something that very simply serializes the things like blockindexes, and an open-hash table for the utxo set. e.g. like the one the ripple people did... and it would likely be a pretty massive speedup. I suppose you could just convert this to a flatfile /then/, so it's not the end of the world. We also take on some increased 11:29 < gmaxwell> Q/A,dev overhead if we start storing blobs in ldb because thats just a whole other set of access patterns that we need to worry about that might result in misbehaviors (like, what is ldb's peak memory usage look like when storing 40kb blobs in it?) 11:29 < jamesob> sipa: if we have leveldb read failures we've got bigger problems than serving block filters, no? 11:29 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 11:29 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 11:30 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-ouwsaysynjrgsdxg] has quit [Quit: Connection closed for inactivity] 11:30 < jimpo> is a leveldb read failure significantly more likely than a flatfile read failure? 11:30 < sipa> gmaxwell: ok i see 11:30 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 11:30 < sipa> jimpo: it needs exception handling etc, which i remember was a pain to deal with in the UTXO code 11:31 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has joined #bitcoin-core-dev 11:31 < wumpus> doesn't all i/o need error handling? 11:32 < jimpo> I guess flatfile accesses just return error codes or null vs throwing exceptions? is that what you're saying sipa? 11:32 < sipa> sure, but an "if (!read) return false" in the startup code is easier than a wrapper database object that catches exceptions etc 11:32 < wumpus> oh sure the way in which errors are reported will differ 11:32 < sipa> anyway, i'm fine with leveldb index + flatfiles, and moving the load into RAM to a later chance 11:33 < wumpus> one thing at least, for the first iteration it's useful to keep the amount of new code minimal 11:33 < sipa> performance at this point doesn't matter that much for this application, but it's nice that in the future it wouldn't be a compatibility break 11:33 < gmaxwell> is the only reason to not store it in the blockindex is to just avoid the size of the blockindex objects increasing when the filter isn't used? 11:34 < jimpo> potentially if core supports multiple filter types (dunno how likely that is?) 11:34 < sipa> jimpo: also to simplify building it in the background, i guess? 11:34 < wumpus> so if using leveldb results in much less code than implementing some manual file handling, that might be handier for review, as said it can be optimized later 11:35 < gmaxwell> it won't be. 11:36 < jimpo> it's a few hundred more lines 11:36 < jimpo> *after* the flatfile refactor 11:36 < wumpus> as long as you don't end up rolling your own k/v store 11:36 < jimpo> but I think the refactor is good to do anyway 11:36 < jamesob> agree with that 11:37 < sipa> agree, yes 11:37 < sipa> gmaxwell: what makes you say so? 11:37 < gmaxwell> The whole process of making these things super optional seems to add a lot of complexity. If instead we didn't think of it that way the filters could just be handled right along side, say, undo data. 11:38 < jimpo> eh, depends how you think about complexity 11:38 < jimpo> I consider adding more stuff to CBlockIndex to be more complex than a separate, asynchronous system 11:38 < sipa> gmaxwell: agree, it adds complexity to make it optional and separate, but that's a different question than whether or not everything should be in leveldb or partially in flat files 11:39 < jimpo> otherwise it involves messing around with validation code before there's even a consensus change 11:39 < gmaxwell> If I drop out support for upgrades and what not, I believe I could add support for including indexes with two dozen lines of code. Obviously not a fair comparison. 11:39 < wumpus> right, with decoupling at least changes can be localized and contained, instead of tying everything together 11:39 < gmaxwell> But building a pile of logical abstractions that add layers and layers is not actually a reduction in complexity. 11:39 < wumpus> exactly jimpo 11:39 < gmaxwell> It's decomplexity theater. 11:39 < sipa> please 11:39 < wumpus> is that what he's doing? 11:40 < jimpo> rich hickey would disagree, I think 11:40 -!- profmac [~ProfMac@2001:470:1f0f:226:4d0a:b31a:4cb4:a042] has joined #bitcoin-core-dev 11:40 < gmaxwell> and then we just spend our entire lives on pointless refactors shifting around the deckchairs on this fractal of layers, while seldom actually advancing visible functionality, which is exactly what the project has been doing for the last year. 11:41 < wumpus> I don't think this is construcive anymore 11:41 < wumpus> any other topics? 11:41 < jonasschnelli> rw_config INI vs UniValue 11:41 < jamesob> operation of cblockindex is consensus critical; atm serving filter blocks is not => decoupling failure of the optional feature from the critical one is safer 11:41 < wumpus> #topic rw_config INI vs UniValue (jonasschnelli) 11:41 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11082#issuecomment-451406061 11:42 -!- mistergold [~mistergol@185.37.25.172] has quit [Ping timeout: 258 seconds] 11:42 < jonasschnelli> The current rw_config PR from luke-jr uses .INI file structure (own parser)... 11:42 < jonasschnelli> The question is, if a simple JSON file wouldn't be simpler and more stable 11:42 < wumpus> jamesob: FWIW I agree, as long as it is not consensus critical, it's better to have it separate from the consensus critical code, this was the same idea with separating out the other indexes 11:43 < wumpus> but apparently all of that was pointless — 11:43 < jimpo> JSON is somewhat less human-readable IMO 11:43 < jonasschnelli> Yes. But should its main focus be human editable / readable? 11:43 < jamesob> also more annoying to write (e.g. trailing commas on last key causes errors) 11:45 < jonasschnelli> I think using a JSON file is more straight forward since we have the parser/writer logic in place (rather then adding another file format) 11:46 -!- promag [~promag@83.223.249.210] has quit [Ping timeout: 250 seconds] 11:46 < jonasschnelli> Also, the rw_configs focus AFAIK is "edit through the application layer" rather then manually with a text editor 11:46 < ryanofsky> the question isn't really "do you like ini or json better?" the question is how do you want to replace QSettings? with a new ini parser, or existing ini parser, or with existing univalue parser? 11:46 < jamesob> I'm in favor of whatever is less code 11:46 < jonasschnelli> UniValue is very likely less code 11:47 < jimpo> Yeah, I'm on board with JSON 11:47 < jonasschnelli> But maybe we pick up the discussion when luke-jr is back or – if you care – comment on the PR 11:49 < jonasschnelli> other topics? 11:49 < jamesob> so can we proceed on jimpo's option (2), i.e. indexing in ldb and storing filters in flatfiles? 11:50 < wumpus> jamesob | I'm in favor of whatever is less code <- same 11:50 -!- gekisai [~gekisai@2407:7000:9f61:e400:5ddb:f2d6:113e:151c] has quit [Ping timeout: 250 seconds] 11:51 < wumpus> no other topics? 11:51 < jnewbery> reminder: wallet IRC meeting tomorrow 11:52 < wumpus> #endmeeting 11:52 < lightningbot> Meeting ended Thu Jan 10 19:52:52 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 11:52 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.html 11:52 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.txt 11:52 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-10-19.00.log.html 11:53 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 11:54 -!- benthecarman_ [~benthecar@ics133-250.icsincorporated.com] has joined #bitcoin-core-dev 11:55 < dongcarl> I would like people to take a look at #12255 when they can, I'm not sure if there is precedent for how this is usually done but I think we should contact distro package maintainers if we decide it should be merged 11:55 < gribble> https://github.com/bitcoin/bitcoin/issues/12255 | Update bitcoin.service to conform to init.md by dongcarl · Pull Request #12255 · bitcoin/bitcoin · GitHub 11:56 < dongcarl> I do not want careless distro maintainers clogging up people's hard drives and bringing down nodes just because the default datadir has changed 11:57 -!- benthecarman [~benthecar@89.39.107.195] has quit [Ping timeout: 245 seconds] 11:57 -!- bentheacarman__ [~benthecar@89.39.107.204] has joined #bitcoin-core-dev 11:57 -!- bentheacarman__ [~benthecar@89.39.107.204] has quit [Client Quit] 11:58 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 11:59 -!- benthecarman [~benthecar@89.39.107.204] has joined #bitcoin-core-dev 11:59 -!- benthecarman_ [~benthecar@ics133-250.icsincorporated.com] has quit [Ping timeout: 250 seconds] 12:06 < wumpus> to be honest I have no idea who is actually using those files, whether they're used in any distro packaging 12:06 < wumpus> I do know it tends to be hard to find reviewers for init scripts and such 12:07 < wumpus> I think they're meant as examples in the first place, to copy over and tweak, not for anything to be automtically installing them 12:08 < wumpus> but it's a good point... 12:12 -!- Guest29947 [~Andrea@2-233-24-247.ip215.fastwebnet.it] has joined #bitcoin-core-dev 12:12 -!- Guest29947 [~Andrea@2-233-24-247.ip215.fastwebnet.it] has quit [Max SendQ exceeded] 12:12 < dongcarl> wumpus: I know that at least Arch Linux uses the systemd file 12:13 < gwillen> I would appreciate if people would glance at #14978, it has a couple of utACKs but I don't really know what it needs before someone is comfortable merging it 12:13 < gribble> https://github.com/bitcoin/bitcoin/issues/14978 | Factor out PSBT utilities from RPCs for use in GUI code; related refactoring. by gwillen · Pull Request #14978 · bitcoin/bitcoin · GitHub 12:16 -!- chenpo [~chenpo@118-160-51-129.dynamic-ip.hinet.net] has quit [Remote host closed the connection] 12:20 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 12:23 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 12:24 -!- gekisai [~gekisai@125-239-46-196-fibre.sparkbb.co.nz] has joined #bitcoin-core-dev 12:28 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 12:29 -!- gekisai [~gekisai@125-239-46-196-fibre.sparkbb.co.nz] has quit [Remote host closed the connection] 12:29 -!- gekisai [~gekisai@125-239-46-196-fibre.sparkbb.co.nz] has joined #bitcoin-core-dev 12:32 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 12:45 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 12:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 12:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 12:54 -!- chenpo [~chenpo@118-160-51-129.dynamic-ip.hinet.net] has joined #bitcoin-core-dev 12:54 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 12:58 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 13:01 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 13:07 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 13:10 < phantomcircuit> sipa, what does openssl's rng do to gather entropy? anything that you're not already doing? 13:11 < gmaxwell> phantomcircuit: I believe the code in sipa's PR does more or less strictly more than openssl does by default on linux at least. 13:11 < gmaxwell> phantomcircuit: it reads dev/urandom and also combines in e.g. the stack pointer and a time. 13:11 < phantomcircuit> also why remove the perfmon data from GetStrongRand* functions 13:12 < phantomcircuit> oh i see you moved it to the scheduler, makes sense 13:12 < gmaxwell> phantomcircuit: the permon is already only once in a while (its slow), in the PR it gets moved to the idle thread. 13:13 < gmaxwell> right. 13:19 -!- Giszmo [~leo@ip-240-233.219.201.nextelmovil.cl] has quit [Ping timeout: 272 seconds] 13:25 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 13:36 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has joined #bitcoin-core-dev 13:40 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 13:46 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 13:52 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 13:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 14:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 14:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 14:05 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 14:07 -!- Guest51719 [~mike@47.23.101.106] has quit [Quit: Guest51719] 14:08 -!- Liliaceae [sid282374@gateway/web/irccloud.com/x-iufhlznhrilblhpm] has quit [Ping timeout: 252 seconds] 14:10 -!- Liliaceae [sid282374@gateway/web/irccloud.com/x-acnpxzesqedxqdea] has joined #bitcoin-core-dev 14:33 -!- hidden [5ad14461@gateway/web/freenode/ip.90.209.68.97] has joined #bitcoin-core-dev 14:33 -!- hidden [5ad14461@gateway/web/freenode/ip.90.209.68.97] has left #bitcoin-core-dev [] 14:33 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 14:37 -!- hidden [~hidden@unaffiliated/hidden] has joined #bitcoin-core-dev 14:45 < hidden> https://github.com/bitcoin/bitcoin/issues/7463#issuecomment-306336149 does anybody know how i could recover keys from keypool that has been damaged in relation to this issue? 14:46 < hidden> i have been trying for years now any help will be hugely appreciated 15:04 -!- sfhi [~sfhi@178.255.154.107] has quit [Quit: Leaving] 15:05 < gwillen> hidden: is there a writeup somewhat of what happened, what the failure looks like, and what you've tried 15:05 < gwillen> the easiest way to get help will start with writing those things down 15:06 < gwillen> (also, I'm not sure this channel is the right place to seek help, but in any case it's not the right place to have a long discussion about it) 15:07 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 15:11 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 15:11 < hidden> gwillen basically i salvagewallet and it said failed and wallet is corrupt. if i try to open the client again it i could try generate a new address to load up the reserved ones in the keypool, i could do so until i the "unknown key in key pool" error. i can dump the wallet (which was renamed ending .bak december 2013) using pywallet. in the dump i see the address and the corresponding "public_key_hex" under list of keypool but not the 15:11 < hidden> private key. 15:12 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 15:13 < hidden> I also downloaded berkeley DB, did a db_dump, didn't go anywhere much yet, i hear doing recovery without aggressive might help but still clueless and learning about berkely db. 15:13 < hidden> it's not a HD wallet as you might have guessd. the link i posted (https://github.com/bitcoin/bitcoin/issues/7463#issuecomment-306336149) details the exact issue. 15:13 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 15:14 < hidden> maybe even a solution was provided there to retrieve keys but i couldn't follow. if anyone has idea on what to do, patiently just idling and searching solutions thanks. 15:15 < gwillen> hm, if pywallet --dumwallet show private keys for other public keys, but not the one in question, presumably that is one of the corrupted records :-\ 15:16 < gwillen> that doesn't necessarily mean there are zero useful bytes to recover, but it does mean some bytes you want have probably been destroyed, and implies that fixing the salvagewallet issue probably wouldn't recover that key 15:17 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has quit [Ping timeout: 246 seconds] 15:17 < gwillen> but again I don't want to do too much discussion in this channel -- it would be really helpful if you would write down somewhere, e.g. even just a google doc or something, everything you've tried so far and exactly what you see (e.g. what output do you get from pywallet? obviously don't paste any actual private keys.) 15:17 < hidden> yes it is one of the the pages are out of order https://pastebin.com/g0gDC990 15:19 < hidden> the output of pywallet is 600mb its hard to post it. but i can post headers of db_dump https://pastebin.com/TbUM2STN 15:19 < hidden> i'll write a google doc if no one can provide a solution tonight. maybe it's an easy fix 15:20 < gwillen> I'll caution that unfortunately it doesn't _sound_ like an easy fix, but I'd love to offer you one if it is -- a google doc would be ideal 15:20 < gwillen> make sure you don't include any private keys, even ones you think aren't the right ones, just in case -- censor them from anything you post 15:21 < hidden> ok, i'll get the google doc somewhere, hopefully someone see's the scrollback too who can help. will do some recovery with berkeley db tools 15:33 -!- Giszmo [~leo@ip-9-234-219-201.nextelmovil.cl] has joined #bitcoin-core-dev 15:35 -!- miknotauro [~miknotaur@187.214.238.139] has joined #bitcoin-core-dev 15:37 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 244 seconds] 15:38 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 15:43 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 15:43 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 15:54 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 15:54 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 15:54 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 16:05 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 250 seconds] 16:08 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 16:11 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 16:23 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 16:24 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev 16:37 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:39 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Client Quit] 16:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 16:56 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 17:03 -!- mistergold [~mistergol@185.37.25.172] has joined #bitcoin-core-dev 17:03 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 17:06 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has quit [Read error: Connection reset by peer] 17:08 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 17:09 -!- miknotauro [~miknotaur@187.214.238.139] has quit [Ping timeout: 240 seconds] 17:09 -!- mistergold [~mistergol@185.37.25.172] has quit [Ping timeout: 258 seconds] 17:13 < benthecarman> Can someone point me to a good source to learn about p2sh 17:13 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Quit: Leaving] 17:25 < sipa> bip16 17:31 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 17:35 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 258 seconds] 17:50 -!- mistergold [~mistergol@185.37.25.172] has joined #bitcoin-core-dev 17:56 -!- mistergold [~mistergol@185.37.25.172] has quit [Ping timeout: 240 seconds] 18:00 < hidden> ReserveKeyFromKeyPool: unknown key in key pool (code -1) :( 18:09 < phantomcircuit> sipa, why have a bunch of functions that modify a struct instead of a class? 18:12 < sipa> phantomcircuit: wut? 18:12 < phantomcircuit> the rng stuff 18:12 < sipa> i don't understand 18:13 < sipa> you mean why is RNGState a struct and not a class? 18:13 < phantomcircuit> yes 18:13 < sipa> you know what the difference is between the two? 18:13 < phantomcircuit> like AddDataToRng could be a method instead of calling GetRNGState 18:14 < sipa> sure 18:14 < phantomcircuit> sipa, public/private default, but i meant more the style change that typically happens with a class 18:14 < sipa> maybe i should make the internal state orivate 18:14 < sipa> *private 18:14 < sipa> that seems like a nice guarantee anyway 18:14 < sipa> to avoid bugs that accidentally wipe the state 18:15 < gmaxwell> can the state get stored in the mlocked pool, or is there some initalization order issue there. 18:16 < sipa> that's actually pretty doable 18:30 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 18:30 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 18:34 < sipa> done 18:34 < sipa> that was surprisingly easy 18:37 -!- bitstein [~bitstein@unaffiliated/bitstein] has joined #bitcoin-core-dev 18:38 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 18:41 -!- bitstein [~bitstein@unaffiliated/bitstein] has quit [Client Quit] 18:43 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 18:45 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev 18:48 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 240 seconds] 18:56 -!- rex4539 [~rex4539@ppp-2-84-172-204.home.otenet.gr] has quit [Quit: rex4539] 19:00 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 19:01 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 19:01 -!- benthecarman [~benthecar@89.39.107.204] has quit [Ping timeout: 268 seconds] 19:13 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3] 19:34 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 246 seconds] 19:34 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 19:39 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 19:50 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 19:51 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 19:55 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 258 seconds] 20:00 -!- gelmutshmidt [~gelmutshm@188.113.8.92] has quit [Remote host closed the connection] 20:01 -!- chenpo [~chenpo@118-160-51-129.dynamic-ip.hinet.net] has quit [Remote host closed the connection] 20:05 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 20:06 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev 20:12 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 20:14 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds] 20:15 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 20:16 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 20:16 -!- gkrizek34 [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has joined #bitcoin-core-dev 20:17 -!- gkrizek34 [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has quit [Client Quit] 20:25 -!- qrestlove [~qrestlove@2605:6000:eb4a:ef00:347a:7bd3:7ad2:b0a8] has quit [Ping timeout: 268 seconds] 20:28 -!- miknotauro [~miknotaur@187.214.238.139] has joined #bitcoin-core-dev 20:34 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 20:42 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has joined #bitcoin-core-dev 20:46 -!- gekisai [~gekisai@125-239-46-196-fibre.sparkbb.co.nz] has quit [Remote host closed the connection] 20:47 -!- gekisai [~gekisai@125-239-46-196-fibre.sparkbb.co.nz] has joined #bitcoin-core-dev 20:51 -!- gekisai [~gekisai@125-239-46-196-fibre.sparkbb.co.nz] has quit [Ping timeout: 258 seconds] 21:00 -!- promag [~promag@2.83.246.44] has joined #bitcoin-core-dev 21:05 -!- promag [~promag@2.83.246.44] has quit [Ping timeout: 268 seconds] 21:14 -!- qrestlove [~qrestlove@2605:6000:eb4a:ef00:c977:813f:a17:2b0] has joined #bitcoin-core-dev 21:29 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 21:34 -!- gkrizek [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has quit [Quit: gkrizek] 21:38 -!- TX1683 [~TX1683@unaffiliated/tx1683] has quit [Ping timeout: 252 seconds] 21:43 -!- gkrizek [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has joined #bitcoin-core-dev 21:45 -!- gekisai [~gekisai@2407:7000:9f61:e400:1564:2ae:a020:56ed] has joined #bitcoin-core-dev 21:45 -!- TX1683 [~TX1683@unaffiliated/tx1683] has joined #bitcoin-core-dev 21:48 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 21:49 -!- gekisai [~gekisai@2407:7000:9f61:e400:1564:2ae:a020:56ed] has quit [Ping timeout: 268 seconds] 21:58 -!- chenpo [~chenpo@2001-b400-e23b-8e48-1c53-5b96-a55f-29b0.emome-ip6.hinet.net] has joined #bitcoin-core-dev 22:07 -!- zenogais [~zenogais1@cpe-76-175-74-114.socal.res.rr.com] has quit [Ping timeout: 250 seconds] 22:15 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 22:41 -!- chenpo [~chenpo@2001-b400-e23b-8e48-1c53-5b96-a55f-29b0.emome-ip6.hinet.net] has quit [] 22:43 -!- gkrizek [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has quit [Quit: gkrizek] 22:44 -!- gkrizek [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has joined #bitcoin-core-dev 22:45 -!- Giszmo [~leo@ip-9-234-219-201.nextelmovil.cl] has quit [Quit: Leaving.] 23:07 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-dev 23:08 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 23:16 -!- Krellan [~Krellan@2601:640:4000:a876:441a:6ff6:539c:6663] has joined #bitcoin-core-dev 23:21 -!- Krellan [~Krellan@2601:640:4000:a876:441a:6ff6:539c:6663] has quit [Ping timeout: 268 seconds] 23:24 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 246 seconds] 23:26 -!- Krellan [~Krellan@2601:640:4000:a876:8832:9440:b62b:9c76] has joined #bitcoin-core-dev 23:39 -!- TX1683 [~TX1683@unaffiliated/tx1683] has quit [Ping timeout: 244 seconds] 23:40 -!- mistergold [~mistergol@77.243.22.97] has joined #bitcoin-core-dev 23:44 -!- TX1683 [~TX1683@unaffiliated/tx1683] has joined #bitcoin-core-dev --- Log closed Fri Jan 11 00:00:18 2019