--- Log opened Sun Sep 09 00:00:03 2018
00:09 -!- pkx1 [~pkx@unaffiliated/pkx] has quit [Ping timeout: 246 seconds]
00:19 -!- phwalkr [~phwalkr@203-166-226-250.dyn.iinet.net.au] has joined #bitcoin-core-dev
00:28 -!- phwalkr [~phwalkr@203-166-226-250.dyn.iinet.net.au] has quit [Remote host closed the connection]
00:35 -!- Krellan [~Krellan@2601:640:4000:9258:dd54:1588:bada:6119] has quit [Ping timeout: 252 seconds]
00:36 -!- Krellan [~Krellan@2601:640:4000:9258:59ab:5fe3:56a7:f407] has joined #bitcoin-core-dev
00:43 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
00:52 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev
00:53 -!- echonaut10 [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer]
01:16 < wumpus> there is a feature for manual pruning, isn't  there?
01:16 < wumpus> I remember something like that was merged at some point, a command line flag to prevent automatic pruning as well as a RPC to prune
01:17 < wumpus> client software could use this to prune only what they no longer require
01:21 < wumpus> (I don't think any lightning daemons do this, at the moment, but would be useful)
01:37 < CubicEarth> wumpus: yeah, sipa was also saying there is manual prune option
01:39 < CubicEarth> so that should be able to be used by lightning nodes to ensure the only blocks pruned are ones they don't need anymore
01:42 -!- hebasto [~hebasto@195.60.70.234] has joined #bitcoin-core-dev
01:42 < gmaxwell> the design of manual prune is kinda not ideal if you have multiple potential things that need data. :(
01:44 < CubicEarth> if there was a DoNotPruneAbove, it could be set by different things, with the lowest one controlling
01:45 < gmaxwell> indeed but then you'd need interface elements to remove zombie DNPAs.
01:45 < CubicEarth> Yeah :)
01:46 < CubicEarth> If too many things want the data, not pruning at all might be favorable
01:50 < gmaxwell> it might be more useful if there were just a way of setting it up so you won't process blocks unless your lightning is running, or you've removed the binding.
01:51 < CubicEarth> In either case though, if blocks are to be retained until the pruning command is given by another service, it seems useful to have bitcoin have an option to not download more than some MBs or GBs worth of blocks
01:51 < CubicEarth> ahead 
01:53 < CubicEarth> gmaxwell: are we saying the same thing?
01:59 < wumpus> it's not ideal, but nothing is even using the current functionality as far as I know, so I'm kind of reluctant to discuss adding even more
02:00 < wumpus> once it works for the 1 bitcoind - 1 lightningd case, it'd be more fruitful to discuss extending it to other cases
02:01 < wumpus> instead of adding a lot of logic for something that no one will be using in practice
02:02 < wumpus> FWIW "DNPA" could be implemented by an external process using the current RPC interface
02:02 < wumpus> have it manage the list of requirements and manage manual pruning
02:03 < wumpus> accordingly
02:05 < CubicEarth> Yeah. DNPA is mostly the same as manual pruning it seems.
02:05 < CubicEarth> And that makes sense about not adding complexity.
02:05 < CubicEarth> Maybe it would be simple to add a DoNotValidateBeyond ?
02:06 < wumpus> what I mean is that manual pruning provides the required low-level interface, DNPA would be one strategy to manage it at a higher level with multiple data consumers, but likely not the only way (at some point you might want to kill off consumers if they're too slow, for example, depending on disk space etc)
02:08 < CubicEarth> I understood as such ^^ even if my reply suggested otherwise :)
02:08 < wumpus> something like that, though validation is not the problem in this case, block download is - you'd want to tell it to pause downloading new blocks
02:08 < wumpus> I think there's a command that more or less does that, pause networking, but might be GUI-only I don't remember exactly
02:10 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
02:10 < wumpus> "setnetworkactive"
02:11 -!- Krellan [~Krellan@2601:640:4000:9258:59ab:5fe3:56a7:f407] has quit [Remote host closed the connection]
02:12 < wumpus> it can continue validating the blocks it already has, that won't fill up disk space
02:13 < wumpus> with manual pruning, it's not the validation that triggers pruning anyhow
02:15 < CubicEarth> hmmm, but block are not downloaded sequentially anymore, right?
02:16 < CubicEarth> or non-sequentially within a sliding window?
02:16 < wumpus> I don't see how that is relevant to this, stopping block download is stopping block download, whether they're downloaded sequentially or not, if you want it to stop filling up disk you want to pause block download
02:17 < wumpus> the blocks it downloads can be non-sequential in a consensus sense, but on disk, they're all simply to the block files in a first come first serve basis
02:17 < wumpus> +appended
02:19 < CubicEarth> I was thinking it wouldn't be as helpful to have downloaded and storing a bunch of blocks, and yet be missing an earlier one, at the point networking was shut off
02:19 < wumpus> why not?
02:20 < CubicEarth> validation couldn't proceed 
02:20 < wumpus> that stops filling the disk; once it's turned on again, it will download the rest and connect them
02:20 < wumpus> of course validation cannot proceed
02:20 < wumpus> you're essentially shutting down your node without really shutting it down
02:20 < wumpus> so it will respond to RPC queries to get the blocks and other data already there 
02:21 < wumpus> and to pruning commands
02:21 < wumpus> once the clients have caught up, and a pruning command has been issues, the networking can be waken up again, but maybe I'm missing something I don't know...
02:22 < wumpus> and validation will continue as far as it can with the blocks that it had at the time of network shutdown, not further
02:24 < CubicEarth> I need to think about it more (not from the lightning perspective ... I am no lighting expert). What you are describing might be totally workable. I was just thinking if blocks are not downloaded sequentially, and networking was turned off, there will be storage being taken up with blocks that can't be validated due to gaps. I wasn't thinking practically so much. Just in theory, it would be nice to only be storing 
02:24 < CubicEarth> what could be validated
02:25 < CubicEarth> Yes, those gaps would be filled as soon as networking was turned back on, and it would proceed.
02:25 < wumpus> yes I think it makes sense to get a clear idea of what you practically need, otherwise you'll by definition drag unrelated concerns into it
02:25 < wumpus> exactly
02:29 < wumpus> from the perspective of the lightning clients they will see the block number stop increasing when validation is blocked, which will negatively affect their usefulness as lightning nodes, channel status updates will no longer be detected
02:31 < CubicEarth> the block download window is 1024, btw
02:32 < gmaxwell> CubicEarth: no, above I meant a something much simpler. A setting in bitcoind where it just won't run unless your lightning daemon is connected.
02:33 < gmaxwell> but as wumpus was saying, they aren't even bothering to use the existing functionality.
02:37 < CubicEarth> those lazy lighting devs!
02:39 < gmaxwell> more like they only recently graduated to not requiring -txindex...
02:41 < jl2012> I have a question about this: https://github.com/bitcoin/bitcoin/blob/master/src/secp256k1/src/scalar_8x32_impl.h#L78
02:42 < jl2012> if no becomes true in line 78 to 81, yes must be false
02:42 < jl2012> why don't it return the result earlier?
02:44 < gmaxwell> Because there is no need to, it might well even be slower to do so.
02:47 < gmaxwell> it would also make the function non-constant-time if it terminates early.
02:47 < jl2012> oh, I think this is the real reason?
02:48 < gmaxwell> if that were the only reason we'd have two versions.
02:49 < gmaxwell> But as I said, I wouldn't be surprised if branching out earlier was slower.
02:52 < jl2012> thanks!
02:59 < wumpus> CubicEarth: please, don't call anyone lazy just because they don't focus on your specific issue, everyone is more like overworked
03:00 < wumpus> btw, wow, lightiningd's API to get the last log messages for a specific node is very nice
03:01 < wumpus> even works to get log messages at a lower logging level (say, debug) than are written to disk
03:02 < gmaxwell> I had aspirations of doing all our logging into a ringbuffer... with disk just taking a feed off it.
03:02 < gmaxwell> which would allow us to do things like no logs normally, but dump the ring on crash.
03:02 < wumpus> that's what they do, I think, well I don't know if it's implemented as a ringbuffer but it acts that way on the outside
03:03 < wumpus> but yes that would be neat to have
03:04 -!- rex4539 [~rex4539@2a02:587:3500:8e00:e5d7:7fa7:74d2:72b3] has quit [Ping timeout: 252 seconds]
03:04 < wumpus> at least for log messages that don't cost a lot of overhead to format unnecessarily
03:04 < CubicEarth> wumpus: you are right. I meant it not seriously, but things don't always come across as intended on irc. Nothing but respect for lightning devs from me! 
03:04 < wumpus> CubicEarth: okay, sorry for misreading you then
03:05 < gmaxwell> wumpus: yea, I wondered about that but IIRC other than the format strings themselves there are only ~two places in the code where we totally skip some processing according the the log flags.
03:05 < gmaxwell> and I seem to recall thinking that those could probably just go away.
03:06 < wumpus> gmaxwell: agree, my concern i not relevant to many places and there we already skip the processin explicitly, so the ring-buffer thing would just work
03:06 < wumpus> (except for those messages, obviously)
03:07 < gmaxwell> I think in general, for most users, the logging provides no real value, just wastes disk space even becomes an attack vector (e.g. via spam up the disk attacks). So as a result we've made default logging pretty conservative, but then useful stuff isn't there when something goes wrong.  perhaps more interesting is how any of this would interact with concurrency.
03:12 < wumpus> it'd have to synchronize around writes to the ringbuffer, instead of around disk writes like now
03:13 < wumpus> there is a PR that moves part of logging to a thread I suddenly remember, #13200, should look into it in more detail
03:13 < gribble> https://github.com/bitcoin/bitcoin/issues/13200 | Process logs in a separate thread by jamesob · Pull Request #13200 · bitcoin/bitcoin · GitHub
03:14 < gmaxwell> right but if the ringbuffer is getting more logs into it because it logs more things than disk, that might be annoying. Of course we could have a seperate buffer per thread(group) and only take locks for all of them to merge output for display.
03:14 -!- Krellan [~Krellan@2601:640:4000:9258:4c97:fc2:4b53:b82b] has joined #bitcoin-core-dev
03:15 < wumpus> yes, fair enough
03:42 -!- rex4539 [~rex4539@2a02:587:3500:8e00:bcae:1d8a:5954:4acd] has joined #bitcoin-core-dev
04:09 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
04:24 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
04:32 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev
05:17 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
05:19 -!- Krellan [~Krellan@2601:640:4000:9258:4c97:fc2:4b53:b82b] has quit [Read error: Connection reset by peer]
05:20 -!- Krellan [~Krellan@2601:640:4000:9258:4c97:fc2:4b53:b82b] has joined #bitcoin-core-dev
05:54 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 252 seconds]
06:15 -!- polydin [~delphi@2602:306:b8b6:b970:f984:bae2:2f45:1509] has quit [Remote host closed the connection]
06:21 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl]
06:53 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
06:57 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
07:04 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:23 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
07:56 -!- emilengler [~Emil@77.20.82.41] has joined #bitcoin-core-dev
08:25 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has quit [Ping timeout: 240 seconds]
08:31 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has joined #bitcoin-core-dev
08:32 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://www.Quanto.ga/]
08:34 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
08:40 -!- jarthur [~jarthur@2605:6000:1019:41ab:80bd:950b:c2cb:925a] has joined #bitcoin-core-dev
08:43 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Ping timeout: 256 seconds]
08:47 -!- miknotauro [~miknotaur@187.207.79.62] has quit [Ping timeout: 244 seconds]
08:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:59 -!- Cheeseo [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev
09:03 -!- emilengler [~Emil@77.20.82.41] has quit [Ping timeout: 252 seconds]
09:07 -!- jhfrontz [~Adium@S010664777dad4333.cc.shawcable.net] has joined #bitcoin-core-dev
09:07 -!- hebasto [~hebasto@195.60.70.234] has quit [Remote host closed the connection]
09:15 -!- jhfrontz [~Adium@S010664777dad4333.cc.shawcable.net] has quit [Quit: Leaving.]
09:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
09:49 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
09:50 -!- jhfrontz [~Adium@S010664777dad4333.cc.shawcable.net] has joined #bitcoin-core-dev
09:50 -!- Cheeseo [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer]
09:52 -!- jhfrontz [~Adium@S010664777dad4333.cc.shawcable.net] has quit [Client Quit]
09:56 -!- jhfrontz [~Adium@S010664777dad4333.cc.shawcable.net] has joined #bitcoin-core-dev
09:58 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
10:07 -!- itaseski [~itaseski@213.135.176.135] has joined #bitcoin-core-dev
10:11 -!- jhfrontz [~Adium@S010664777dad4333.cc.shawcable.net] has quit [Quit: Leaving.]
10:31 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev
10:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
10:48 -!- jarthur [~jarthur@2605:6000:1019:41ab:80bd:950b:c2cb:925a] has quit []
10:51 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev
10:51 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 246 seconds]
10:56 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
10:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
10:59 -!- ExtraCrispy [~ExtraCris@67.215.11.12] has quit [Remote host closed the connection]
11:01 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
11:10 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 246 seconds]
11:11 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 252 seconds]
11:16 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev
11:29 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
11:49 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
13:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
13:29 -!- Linrono [~Linrono@pool-108-31-147-152.washdc.fios.verizon.net] has joined #bitcoin-core-dev
13:30 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
14:28 < phantomcircuit> it seems kind of awkward to me to use the new naming convention in the same (small) function as the old one
14:30 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
14:31 -!- Linrono [~Linrono@pool-108-31-147-152.washdc.fios.verizon.net] has quit [Ping timeout: 245 seconds]
14:36 < sipa> phantomcircuit: if it's a small function, just change it all
14:38 < phantomcircuit> sipa, im looking at https://github.com/bitcoin/bitcoin/blob/718843aed5e60e42ebbe822457511b4fbbf318eb/src/net.cpp#L1225
14:39 < phantomcircuit> which is mostly moveonly, changing it would change that
14:39 < phantomcircuit> but the nMicroTime variable is new
14:46 -!- DigiByteDev [~JT2@45-20-196-19.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev
15:04 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev
15:17 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 250 seconds]
15:26 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
15:35 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 246 seconds]
15:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
15:48 -!- miknotauro [~miknotaur@187.207.79.62] has joined #bitcoin-core-dev
16:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:15 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
16:19 -!- profmac [~ProfMac@2001:470:1f0f:226:3902:bc29:5297:baf9] has quit [Ping timeout: 252 seconds]
16:33 -!- profmac [~ProfMac@2001:470:1f0f:226:d052:67a8:91c9:ffcc] has joined #bitcoin-core-dev
16:34 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
16:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
16:38 -!- profmac [~ProfMac@2001:470:1f0f:226:d052:67a8:91c9:ffcc] has quit [Ping timeout: 252 seconds]
16:41 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
16:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
16:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
16:48 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
16:49 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
16:53 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
17:02 < dongcarl> Hi all, would like to learn about how the p2p code in bitcoind is structured... I'm guessing src/net* are the files to look at, but I can't find an "entry point" that handles and initiates TCP connections, could someone point me to the right place?
17:02 < echeveria> ProcessMessage is where the magic happens. 
17:03 < dongcarl> echeveria: I'm also seeing that CConnman is also important?
17:05 < sipa> echeveria: ProcessMessage is message processing, not network code
17:05 < dongcarl> Is... ProcessMessage a 1300-line function?
17:06 < sipa> sure
17:06 < echeveria> dongcarl: look at CConnman::ThreadSocketHandler, etc. 
17:07 < dongcarl> Ahhhh... anything other than CConnman?
17:07 < sipa> echeveria: almost
17:08 < sipa> socket handling deals with connections that are already open
17:08 < echeveria> sipa: can we go back to 0.1 where things make sense? 
17:08 < sipa> echeveria: they didn't
17:08 < sipa> or did you really prefer having the wallet code mixed with the network code and gui calls in main.cpp?
17:09 < sipa> dongcarl: most basic is probably ConnectSocketDirectly in netbase.cpp
17:10 < sipa> dongcarl: then CConnman::ConnectNode is higher level
17:10 -!- jarthur [~jarthur@2605:6000:1019:41ab:2540:7333:ee:534f] has joined #bitcoin-core-dev
17:10 < sipa> then OpenNetworkConnection on top of that
17:11 < echeveria> sipa: still fascinating that it worked at all. 
17:14 < midnightmagic> I didn't like the interleaved logic, but I found the old code to be extremely legible.
17:14 < echeveria> hey at least bitcoin doesn't make HTTP requests using raw sockets now. 
17:14 < dongcarl> ThreadOpenConnections -> OpenNetworkConnection -> ConnectNode -> ConnectSocketDirectly ?
17:15 < dongcarl> and Start -> ThreadOpenConnections ofc
17:26 < sipa> midnightmagic: i agree, it was readable... or at least so it seemed until i tried to figure out how the wallet ever learned a particular output was being spent
17:26 < sipa> midnightmagic: turns out there was a callback from the script execution code into the wallet...
17:27 < sipa> but sure, things have gotten a lot more complicated since
17:27 < sipa> the code also does a lot more
17:30 < midnightmagic> sipa: I don't think it's more complicated in the comprehension sense, just..  harder to navigate with my preferred terminal tools is all. cscope is required (for me) now due to the logic spreading across multiple files. I don't think it's a problem, just I think peeps take some other types of tools for granted these days I guess. :)
17:32 < dongcarl> Looking into libconsensus as well... I'm wondering if the API detailed in https://github.com/bitcoin/bitcoin/issues/6714 still holds... Seems like jtimon and NicolasDorier did a bunch of work that's been closed due to inactivity?
17:32 < midnightmagic> sipa: tangentially, you ever detail your dev tools anywhere?
17:34 < dongcarl> midnightmagic: SuperCoder 2000 ofc
17:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
17:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
17:45 -!- Dizzle [~Dizzle@2605:6000:1019:41ab:2540:7333:ee:534f] has joined #bitcoin-core-dev
17:47 < sipa> midnightmagic: i only use git grep and mcedit :)
17:48 < sipa> dongcarl: i don't think the libconsensus api ever changed
17:48 < sipa> apart from the addition of tx amounts for segwit
17:51 < dongcarl> sipa: Is there a particular reason why there was lack of interest in the PRs?
17:55 < sipa> dongcarl: lack of agreement on approach, i think
17:57 < sipa> and refactorings that keep going on for a long time are annoying to other contributors
17:58 < dongcarl> sipa: are the conversations/discussions recorded somehwere?
17:59 < midnightmagic> sipa: lol dangit. I forgot you do the same sort of thing I do.
18:01 < sipa> dongcarl: irc and github...
18:02 -!- DigiByteDev [~JT2@45-20-196-19.lightspeed.austtx.sbcglobal.net] has quit [Quit: DigiByteDev]
18:05 < sipa> dongcarl: but really, there just wasn't enough momenentum i think - those kinds of changes need many people to agree on a plan first
18:13 < dongcarl> sipa: Makes sense... Would Tokyo be a good place to talk about this?
18:23 < sipa> maybe
18:27 < jarthur> Hey, I'm able to reproduce this on both Debian jessie and Debian stretch - https://github.com/bitcoin/bitcoin/issues/8749 - any of you run into it yet?
18:28 < jarthur> libboost 1.62.0.1 packages
18:35 < sipa> jarthur: have you tried reinstalling the boost packages?
18:36 < sipa> make sure they're all the same version
18:36 < sipa> if you have a locally installed version, point the configure script to it
18:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
18:43 < jarthur> sipa: using the apt packages. Will double check all the versions now. One thing I did was install the libs first, then the -dev packages.
18:45 < sipa> also try clearing your config cache
18:45 < sipa> "git clear -dfx" wipes everything not committed in the source tree
18:48 < jarthur> Using the source tgz
18:49 < sipa> in that case, delete the build dir and extract again
18:49 < sipa> (but you should really consider building from git, if you do it repeatedly)
18:49 -!- RubenSomsen [uid301948@gateway/web/irccloud.com/x-nbfoanvetcttebsk] has joined #bitcoin-core-dev
18:58 < jarthur> sipa: confirmed all libboost pkgs show same version. Re-extracted, autogenned and such. Maybe it's an issue with using --no-install-recommends when installing the libbost-*-dev pkgs. Doing this for a large-scale docker deployment, so keeping things minimal.
19:02 < jarthur> s/libbost/libboost/
19:07 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
19:38 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Ping timeout: 256 seconds]
19:47 -!- rex4539 [~rex4539@2a02:587:3500:8e00:bcae:1d8a:5954:4acd] has quit [Ping timeout: 252 seconds]
19:55 -!- mdrollette [~mdrollett@feynman.drollette.com] has quit [Quit: ZNC 1.7.1 - https://znc.in]
20:01 < jarthur> sipa: yea, seeing it on Ubuntu as well. If we didn't need libboost-program-options-dev before, maybe this is a new autogen macro issue. Looked back at old debs and never saw libboost-program-options-dev being pulled in as a dep or recommends.
20:03 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has joined #bitcoin-core-dev
20:19 -!- itaseski [~itaseski@213.135.176.135] has quit [Ping timeout: 246 seconds]
20:24 -!- ken2812221_ is now known as ken2812221
20:25 < ken2812221> jarthur: libboost-program-options-dev is no longer required since #13482
20:25 < gribble> https://github.com/bitcoin/bitcoin/issues/13482 | Remove boost::program_options dependency by ken2812221 · Pull Request #13482 · bitcoin/bitcoin · GitHub
20:26 < Dizzle> ken2812221: yep, you're so right
20:26 < Dizzle> thanks!
20:26 < jarthur> ty
20:53 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has quit [Remote host closed the connection]
20:56 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has joined #bitcoin-core-dev
21:09 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has quit [Ping timeout: 264 seconds]
21:48 -!- miknotauro [~miknotaur@187.207.79.62] has quit [Ping timeout: 272 seconds]
22:03 -!- Dizzle [~Dizzle@2605:6000:1019:41ab:2540:7333:ee:534f] has quit [Quit: Leaving...]
22:12 -!- Krellan [~Krellan@2601:640:4000:9258:4c97:fc2:4b53:b82b] has quit [Read error: Connection reset by peer]
22:13 -!- Krellan [~Krellan@2601:640:4000:9258:4c97:fc2:4b53:b82b] has joined #bitcoin-core-dev
22:26 -!- rex4539 [~rex4539@2a02:587:3500:8e00:bc80:defc:f63c:19de] has joined #bitcoin-core-dev
22:32 < kallewoof> How do the recoverable ecsda signatures differ from the regular ones aside from the recid + compressed prefix byte?
22:37 < sipa> not
22:37 < sipa> they're literally a normal signature + recid
22:37 < kallewoof> Great! Thanks
22:38 < sipa> also, don't use them :)
22:38 < kallewoof> I'm writing a BIP for the sign|verifymessage proposal from ML from awhile back. How would the verifier extract pubkey?
22:38 < kallewoof> +if not using recoverable sig
22:39 < kallewoof> Just brute force it?
22:39 < sipa> the script based stuff?
22:39 < sipa> script doesn't have any recoverable sigs
22:39 < kallewoof> Was gonna just say "include a 1 byte 'flags' whose lower 2 bits are the recid and upper 6 bits reserved for future flags". Yeah.
22:39 < sipa> that makes no sense
22:40 < kallewoof> Because you can just brute force it?
22:40 < sipa> they whole point is that you can just reuse script
22:40 < sipa> no
22:40 < sipa> the signature can literally just be a witness
22:40 < sipa> which for a p2wpkh output contains a pubkey+sig
22:40 < kallewoof> Doh. Yeah.
22:40 < sipa> it's a bit longer, but meh
22:41 < kallewoof> I got things mixed up. I somehow assumed I needed the pubkey
22:41 < sipa> it's super flexible, and you don't need any script modifications at all
22:41 < kallewoof> Yeah
22:54 -!- jarthur [~jarthur@2605:6000:1019:41ab:2540:7333:ee:534f] has quit []
23:44 -!- Krellan [~Krellan@2601:640:4000:9258:4c97:fc2:4b53:b82b] has quit [Remote host closed the connection]
23:45 -!- Krellan [~Krellan@2601:640:4000:9258:202a:3d56:849:3437] has joined #bitcoin-core-dev
23:50 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
23:51 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
--- Log closed Mon Sep 10 00:00:04 2018