--- Log opened Wed Sep 26 00:00:19 2018
00:01 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 240 seconds]
00:27 -!- Sinclair6 [~sinclair6@2600:1702:4020:6be0:6841:2e74:8e43:1e6c] has joined #bitcoin-core-dev
00:28 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds]
00:33 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has joined #bitcoin-core-dev
00:41 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
00:41 -!- proletesseract [~proletess@219.88.232.29] has quit [Remote host closed the connection]
00:48 -!- proletesseract [~proletess@219.88.232.29] has joined #bitcoin-core-dev
01:00 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds]
01:01 -!- josephnicholas [~josephnic@110.54.236.121] has joined #bitcoin-core-dev
01:01 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:07 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
01:09 -!- prometheus_falli [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has joined #bitcoin-core-dev
01:12 -!- t0adst00l [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has quit [Ping timeout: 256 seconds]
01:14 -!- josephnicholas [~josephnic@110.54.236.121] has quit [Remote host closed the connection]
01:17 < wumpus> [back home from Riga, will probably need to catch up on a lot of things]
01:22 < wumpus> did anything come in preventing us from tagging 0.17.0 final?
01:23 < sipa> wumpus: i'd like to make sure #14289 is not a regression
01:23 < gribble> https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub
01:24 < wumpus> okay
01:25 < wumpus> yes that one is fairly nasty
01:25 < sipa> provoostenator said he was going to retry with 0.16 tomorrow
01:25 < sipa> i guess today
01:29 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:30 < gmaxwell> even if its not a regression (... I'm pretty sure it is, just maybe not vs 0.16), we still need to do something about it, something could be a release note that just says you can't upgrade from pre-0.13 
01:40 < wumpus> breaking backwards compatibility, even temporarily, is kind of a bummer — though they could always reindex
01:40 < wumpus> would it be possible to detect this scenario and bail out? people might read over it in the release notes, which are huge for major releases
01:41 < gmaxwell> we could easily add an exit in that rewind code. though at that point, it might make sense to just fix the problem.
01:43 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
01:48 < wumpus> also depends on the risk of the change, e.g. queue limited naively at least could introduce deadlocks
01:49 < gmaxwell> yea, obviously not that.
01:55 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
02:12 < wumpus> right, that was just an example, but I mean, for master we obviously want a proper long-term solution, for 0.17 it might be safer to prevent it from happening w/ a smaller patch
02:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:36 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has joined #bitcoin-core-dev
02:37 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
03:00 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
03:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
03:12 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
03:13 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 256 seconds]
03:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev
03:24 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 252 seconds]
03:25 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
03:27 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Read error: Connection reset by peer]
03:27 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
03:37 -!- proletesseract [~proletess@219.88.232.29] has quit [Remote host closed the connection]
03:44 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
03:44 -!- reallll [~belcher@unaffiliated/belcher] has quit [Remote host closed the connection]
03:47 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
03:58 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
04:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
04:13 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
04:14 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
04:18 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Ping timeout: 250 seconds]
04:24 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 240 seconds]
04:25 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
04:25 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
04:26 -!- karelb [sid316741@gateway/web/irccloud.com/x-ixuhvjbhtkhozspu] has joined #bitcoin-core-dev
04:33 < karelb> Hello. I have been thinking about changing the RPC doc format slightly, so it is better parseable to something better looking than this - https://bitcoincore.org/en/doc/0.16.2/rpc/wallet/sendmany/
04:34 < karelb> I have tried to write something like a proposal for unified formatting that would help with parsing... I wrote it here
04:34 < karelb> https://gist.github.com/karel-3d/1490786786525b0365ea8f459a9fc683
04:34 < karelb> this is like draft 0
04:34 < karelb> do you think it's a good idea?
04:35 < karelb> It requires some small changes to current documentation
04:37 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
04:44 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]
04:47 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
04:55 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
04:58 < wumpus> the idea to have machine-parseable documentation format that is formatted on the fly has been floated before, at least
05:00 < wumpus> I remember one of the dividing issues was whether to have the documentation at the point where the RPC function is implemented (like now) versus in an external, say JSON, file that is embedded at compile time
05:00 < wumpus> all in all though it'd certainly be an improvement, the manual space-pushing that has to be done now is silly
05:01 < wumpus> and it's also hard to keep things (such as type names) consistent
05:02 < wumpus> I think your proposal has the same drawback: it's based on precise text formatting within strings, instead of something more structured; I *guess* it could be enforced by (sigh) another linter, but...
05:04 < karelb> I tried to make the current proposal close to the current format
05:05 < harding> In a prior discussion, an option was starting with a linter to get things into a uniform structure and then developing the tooling to make adhearing to that structure easy (e.g. the external JSON file).
05:06 < karelb> I think external JSON would get outdated soon and people would forget to update
05:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
05:09 < harding> karelb: although that's a risk, the project seems to have an abundance of people willing to PR minor string updates at the moment, so I wouldn't be too worried.
05:09 < wumpus> harding: yes, might be the best option in this case, fairly easy in most cases where the text is one text blob in "" (it's mostly the \ escaping of quotes inside that that makes horizontal alignment annoying to do)
05:11 < wumpus> right, in the case of an external file, *should* add a comment to each function where it's documented...
05:11 < karelb> the proposal I wrote comes from the viewpoint "let's make small changes to current format to make it parseable"... I did not think about lint-ablitiy
05:12 < harding> karelb: if it's not linted, then it'll be up to you to either hassle people to use the correct format or to PR lots of minor whitespace changes yourself, neither of which sounds very fun.  :-)
05:14 < wumpus> so if you create a format that's consistent ehough to be machine-parseable, for say, generation of formatted web docs, linting is the same process I'd say?
05:14 < karelb> the biggest changes are the Markdown stuff which would force backticks, and also would force to add spaces somewhere, so the "description" of the argument don't fall into "pseudocode" on the left
05:14 < karelb> wumpus: I guess so!
05:14 < wumpus> it doesn't even have to lint on the source code BTW - it could simply call the RPC server, request help, lint that
05:15 < harding> karelb: an alternative approach is to maintain your own diff between the `bitcoin-cli help` in its current inconsistent format and the idealized consistent format you suggest, which shouldn't be too much work as the current help is pretty stable, then develop your tooling around that, proving its worth.  Then you'll not only have stronger evidence that it's externally useful, but you'll also have the parsing tools to help create 
05:15 < harding> the linted and a list of changes that actually need to be made.
05:15 < wumpus> (FWIW this is how the manual page generation also works; it calls bitcoind &c --help and generates from that)
05:16 < wumpus> in any case work on improving the docs is always welcome, thanks for thinking about this
05:16 < karelb> harding: good idea
05:17 < karelb> wumpus: I am basically scratching my own itch :D the same with this issue
05:17 < karelb> https://github.com/achow101/btcinformation.org/issues/23
05:18 < karelb> just today I was trying to google "what is a sighash again?" (since when I do not work on bitcoin for a while I keep forgetting its terminology) and I keep ending up at bitcoin.org developer docs
05:23 -!- panako [uid322619@gateway/web/irccloud.com/x-ctwnqyalpiyyufli] has joined #bitcoin-core-dev
05:35 < wumpus> I never forget what a sighash is, but I must admit I forget what are the different combinations for it sometimes
05:38 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-mwggotwszylbocsc] has joined #bitcoin-core-dev
05:40 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 260 seconds]
05:40 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
05:42 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
05:48 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
05:51 < provoostenator> It's that time of the year again where a the new macOS breaks stuff #14327. QT from homebrew doesn't work, depends building is also broken.
05:51 < gribble> https://github.com/bitcoin/bitcoin/issues/14327 | macOS Mojave QT 5.11 compilation fails · Issue #14327 · bitcoin/bitcoin · GitHub
05:52 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Ping timeout: 245 seconds]
05:53 < provoostenator> Maybe when I buy a new laptop I'll keep the old one around to test beta releases, so we get a few months heads up.
05:56 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #bitcoin-core-dev
06:03 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
06:15 -!- baldur [~baldur@pool-72-69-77-244.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds]
06:26 -!- gertjaap [~gertjaap@88.208.3.158] has quit [Quit: ZNC 1.7.1 - https://znc.in]
06:27 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
06:28 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
06:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:35 < wumpus> why doesn't travis catch this?
06:35 < wumpus> oh, it's a build *on* mac not for mac
06:35 < provoostenator> I haven't tried a cross compile to the latest macOS SDK; we build for a much older version afaik.
06:36 < wumpus> that would be one of the most difficult things to automate unless there's something like Appveyor for windows for macs
06:36 < provoostenator> Perhaps trying to cross-compile to a beta release (~ June / July / August) might also help catch this.
07:02 -!- baldur [~baldur@pool-173-52-43-167.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:11 -!- baldur [~baldur@pool-173-52-43-167.nycmny.fios.verizon.net] has quit [Ping timeout: 272 seconds]
07:12 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
07:12 -!- jarthur [~jarthur@2605:6000:1019:41ab:1cfe:da06:7fed:9334] has quit [Ping timeout: 260 seconds]
07:16 -!- baldur [~baldur@pool-173-52-43-167.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:19 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
07:20 < promag> achow101: do you plan to fix #14019 nits?
07:20 < gribble> https://github.com/bitcoin/bitcoin/issues/14019 | Import pubkeys when importing p2sh with importmulti by achow101 · Pull Request #14019 · bitcoin/bitcoin · GitHub
07:20 < promag> I can push those fixes if you want
07:20 < provoostenator> sipa: looks like 0.16.3 memory explodes just as bad during rollback. I'll update the ticket in a bit. Perhaps the easiest solution is to disable it if there's more than ~1000 blocks since SegWit.
07:20 < provoostenator> I'll try 0.15.2 later today too.
07:21 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
07:23 < provoostenator> Speaking of 0.15.2 I'm having a hard time signing the code-signed Windows gitian binary.  macOS worked fine. v0.14.3 worked fine too. I'm using a Debian VM. Is it picky about the gitian-build.sh version?
07:24 -!- twistedline [~quassel@unaffiliated/twistedline] has quit [Ping timeout: 250 seconds]
07:24 < provoostenator> Getting "failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)"
07:32 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving]
07:35 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
07:37 -!- twistedline [~quassel@unaffiliated/twistedline] has joined #bitcoin-core-dev
07:42 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test]
07:44 -!- rex4539 [~rex4539@ppp-2-84-165-183.home.otenet.gr] has joined #bitcoin-core-dev
08:05 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Read error: Connection reset by peer]
08:09 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
08:09 < achow101> promag: oh, I didn't see those. I'll fix them later today
08:10 < promag> achow101: no problem
08:18 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 250 seconds]
08:37 -!- proletesseract [~proletess@219.88.232.29] has joined #bitcoin-core-dev
08:39 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
08:42 -!- proletesseract [~proletess@219.88.232.29] has quit [Ping timeout: 252 seconds]
08:43 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 250 seconds]
08:49 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
08:54 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 260 seconds]
08:54 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
08:59 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 250 seconds]
09:00 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
09:20 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
09:23 -!- bralyclow [~bralyclow@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
09:25 < provoostenator> (fixed Gitian by deleting images from gitian-builder and rebuilding using the v0.16 gitan script)
09:30 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 240 seconds]
09:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.4]
09:32 < andytoshi> achow101: i have a question about psbt BIP 174
09:32 < andytoshi> what's the expected behaviour regarding uncompressed ECDSA keys
09:33 < andytoshi> the spec doesn't mention this at all and the test vectors only have compressed keys in them
09:34 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
09:34 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
09:38 < sipa> provoostenator: thanks, so it's an earlier regression
09:39 < sipa> provoostenator:, gmaxwell, wumpus: agree with just listing in the release notes that upgrading from 0.13 may not be practical
09:53 -!- phwalkr [~phwalkr@194.210.89.118] has joined #bitcoin-core-dev
09:54 -!- nehan_ [~nehan@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-core-dev
09:55 -!- nehan_ [~nehan@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Client Quit]
09:55 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 272 seconds]
09:57 -!- phwalkr [~phwalkr@194.210.89.118] has quit [Ping timeout: 244 seconds]
09:58 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
10:01 -!- phwalkr [~phwalkr@194.210.89.118] has joined #bitcoin-core-dev
10:01 -!- phwalkr [~phwalkr@194.210.89.118] has quit [Read error: Connection reset by peer]
10:02 < achow101> andytoshi: the same as compressed keys
10:02 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
10:02 < achow101> bip32 is defined for compressed keys only though, so you should only use compressed keys in the bip32 derivs
10:04 < dongcarl> ARGHGGHHGHGHGHGHHGHGHHGHHHHGGHHHH
10:04 < dongcarl> k
10:04 < sipa> achow101: probably worth pointing that out in the bip
10:05 < sipa> it's also not all that clear in bip32... it just only talks about serialization using compressed form
10:06 < sipa> andytoshi: my view is that compressed and uncompressed are both legal inside bip174, but it's up to each signer/updater/... to choose what they support anyway; some may only support compressed keys
10:07 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 264 seconds]
10:07 < andytoshi> ok. the issue is that in rust-bitcoin, we don't store whether a pubkey is compressed or uncompressed, it's just a libsecp secp256k1_pubkey. (our Address and Privkey have this extra info ofc, but the raw ecdsa pubkey type does not)
10:07 < sipa> andytoshi: that sounds like it'd make your life hard :)
10:07 < andytoshi> so we'll need to do something ad-hoc when parsing public keys to preserve the fact that they were uncompressed (and i think we're just gonna reject hybrid keys)
10:07 < sipa> if you want to support uncompressed keys at all
10:08 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
10:08 < andytoshi> we haven't had trouble thus far having the compressed/uncompressed distinction only exist as part of bitcoin Privkeys that correspond to bitcoin addresses
10:08 < andytoshi> so yeah.. we're basically only supporting uncompressed keys for that one specific use case
10:08 < andytoshi> and nowhere else
10:09 < achow101> i don't follow what the problem is
10:09 < sipa> achow101: i assume the difficulty is that if they're deserializing and reserializing a psbt with uncompressed keys, the uncompressedness information would be lost
10:10 < sipa> as the internal type for pubkeys does not store this
10:10 < andytoshi> yep
10:11 < andytoshi> so if we wrote a combiner with this lib, and it was used in some multiparty protocol where somebody was giving us uncompressed keys, we'd wind up compressing them as a side-effect of combining, and confuse everyone else
10:11 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
10:12 < sipa> yeah, i think the correct thing to do is to treat a bitcoin-pubkey as a pair of (ec-pubkey, compressedness), as from bitcoin's perspective they're really different things
10:12 < sipa> hash is different, p2pkh spend is different, address is different, ...
10:13 < andytoshi> yeah
10:13 < sipa> but i also think it's more efficient to keep pubkeys in serialized form, and only convert to secp when signing
10:14 < sipa> because most operations care about its serialization and not its EC identity
10:14 < achow101> andytoshi can't you just copy the bytes instead of parsing it?
10:14 < achow101> in many cases, you don't need to know that it's a pubkey, you just need to compare the bytes.
10:15 < andytoshi> sipa: verification and bip32 operations all care about the EC identity
10:15 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Ping timeout: 240 seconds]
10:15 < sipa> andytoshi: sure, but computing a hash or lookup don't
10:15 < andytoshi> sipa: you never hash a public key directly, only scriptpubkeys containing public keys
10:16 < sipa> andytoshi: eh, no :)
10:16 < andytoshi> achow101: (a) i don't want to do this for type-safety reasons, it's very hard to reason about data structures that might have invalid data in them; (b) i'm pretty sure i need the EC identity in more cases than i need the serialization
10:16 < sipa> P2PKH addresses
10:16 < andytoshi> oh right
10:16 < sipa> andytoshi: but all things that care about EC identity tend to be one-off things; you load an sPK and a witness, convert to secp structures, and verify, and done
10:17 < sipa> so you already have the deserialization cost anyway
10:17 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 240 seconds]
10:17 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
10:18 < sipa> type safety is a good argument, but you can have a pubkey type that just stores the bytes, but still can only be filled with sensible things (starts with 02, 03, 04, length 33/65, ...)
10:18 < andytoshi> then i might as well use a (compressedness, secp pubkey) pair
10:18 < sipa> that's expensive :)
10:19 < sipa> converting a compressed serialization to that format requires deserialization
10:19 < andytoshi> i'm still not convinced that EC operations are "one off things" when i need them to verify signatures and derive public keys, which i do all the time, vs serialization which is only needed when converting to scriptpubkeys or doing network communication
10:19 < sipa> the things you do all the time are looking up "does this pubkey belong to me"
10:20 < andytoshi> in Core maybe
10:20 < sipa> fair, in a library it's less clear what the usage pattern is
10:20 < andytoshi> right.. this isn't the case in liquid for example where we spend a lot of time doing p2c derivations and verifying other peoples' signatures
10:20 < sipa> but "all the time" isn't what matters; the question is what kind of operations do you do on a pubkey in one batch
10:21 < andytoshi> or in a generic PSBT validator where you're really just checking sigs and doing derivations and never really interacting whith the blockchain
10:21 < andytoshi> does libsecp expose a way to determine that a pubkey is valid or not without decompressing it?
10:22 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 250 seconds]
10:22 < sipa> i don't think so
10:22 < andytoshi> yeah..doesn't look like it
10:22 < sipa> but whether a pubkey is valid only matters when doing validation
10:22 < sipa> or signing
10:22 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
10:22 < andytoshi> or deriving child keys
10:23 < sipa> right
10:23 < sipa> all cases where you need to convert to the secp type anyway
10:23 < andytoshi> right, but it would be much nicer if i caught invalid data when i received it
10:24 < sipa> andytoshi: concrete example: a PSBT signer is more efficient if it doesn't need to deserialize all pubkeys listed in the PSBT file before knowing which ones it can sign with
10:24 < sipa> but checking which ones you can sign with is something you can totally do on the byte representation
10:24 < andytoshi> hmm, this is true
10:26 < sipa> maybe it also doesn't matter; i think we can decompress 200000 keys per second
10:26 -!- jarthur [~jarthur@12.130.116.114] has joined #bitcoin-core-dev
10:26 < andytoshi> it would plausibly matter for an HSM
10:27 < sipa> possibly
10:27 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
10:27 < andytoshi> in any case I think for the purposes of rust-bitcoin we're not too concerned about that
10:32 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
10:33 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
10:34 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
10:44 -!- jarthur [~jarthur@12.130.116.114] has quit [Remote host closed the connection]
10:45 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 240 seconds]
10:45 -!- jarthur [~jarthur@12.130.116.114] has joined #bitcoin-core-dev
10:46 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test]
10:56 -!- phwalkr [~phwalkr@fwalunos-vip.estig.ipb.pt] has joined #bitcoin-core-dev
11:18 -!- phwalkr [~phwalkr@fwalunos-vip.estig.ipb.pt] has quit [Quit: Leaving...]
11:28 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:39 -!- jarthur [~jarthur@12.130.116.114] has quit []
11:42 < provoostenator> sipa: v0.15.2 doesn't have the issue, so it was introduces somewhere in 0.16 
11:43 < sipa> provoostenator: interesting, thanks!
11:45 < provoostenator> I might be able to do a (partial) bisect tomorrow if you're really at a loss where this bug started.
11:45 < sipa> i'm sure i can guess by looking at the PR list :)
11:56 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
11:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
12:36 -!- dqx [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection]
12:36 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
12:42 < promag> someone willing to spend a minute in #14148?
12:42 < gribble> https://github.com/bitcoin/bitcoin/issues/14148 | abandontransaction needed after spending orphaned block reward · Issue #14148 · bitcoin/bitcoin · GitHub
12:46 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
12:57 -!- proletesseract [~proletess@219.88.232.29] has joined #bitcoin-core-dev
12:58 < gmaxwell> sipa: see, I said it wasn't always there.
12:58 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
13:20 -!- proletesseract [~proletess@219.88.232.29] has quit [Remote host closed the connection]
13:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer]
13:41 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
13:45 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Client Quit]
13:52 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
13:54 -!- hebasto [~hebasto@195.60.70.234] has quit [Remote host closed the connection]
13:59 -!- proletesseract [~proletess@2403:4d00:300:5:953b:3c99:a6d7:974b] has joined #bitcoin-core-dev
14:00 -!- proletesseract [~proletess@2403:4d00:300:5:953b:3c99:a6d7:974b] has quit [Remote host closed the connection]
14:00 -!- proletesseract [~proletess@2403:4d00:300:5:953b:3c99:a6d7:974b] has joined #bitcoin-core-dev
14:01 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
14:01 -!- proletesseract [~proletess@2403:4d00:300:5:953b:3c99:a6d7:974b] has quit [Remote host closed the connection]
14:03 -!- proletesseract [~proletess@103.247.155.68] has joined #bitcoin-core-dev
14:04 -!- jpe__ [~jpe@2001:16b8:484a:e00:c43e:844e:7821:307e] has quit [Ping timeout: 240 seconds]
14:25 -!- TheCharlatan [~TheCharla@109.236.87.57] has quit [Quit: WeeChat 2.1]
14:28 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:29 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
14:32 -!- proletesseract [~proletess@103.247.155.68] has quit [Quit: Leaving...]
14:32 < phantomcircuit> gmaxwell, i simplified the ThreadSocketHandler cleanup in #14335
14:32 < gribble> https://github.com/bitcoin/bitcoin/issues/14335 | net: refactor: cleanup ThreadSocketHandler by pstratem · Pull Request #14335 · bitcoin/bitcoin · GitHub
14:34 < gmaxwell> phantomcircuit: sweet.
14:42 < promag> rfc: sounds good a bool CWallet::IsExternal() const? which returns false if wallet path is in -walletdir ?
14:42 < promag> jnewbery: ^
14:43 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 272 seconds]
15:03 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
15:04 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection]
15:05 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
15:06 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 245 seconds]
15:14 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-mwggotwszylbocsc] has quit [Quit: Connection closed for inactivity]
15:19 -!- commavir [vir@2604:180::502b:135a] has quit [Quit: leaving]
15:20 -!- commavir [~vir@23.226.237.192] has joined #bitcoin-core-dev
15:37 < phantomcircuit> gmaxwell, and #14336 actually implements poll()
15:37 < gribble> https://github.com/bitcoin/bitcoin/issues/14336 | net: implement poll by pstratem · Pull Request #14336 · bitcoin/bitcoin · GitHub
15:37 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
15:37 < phantomcircuit> im still not sure how to detect whether the poll() available is functional or not
15:38 < phantomcircuit> apparently it's broken on OS X <= 10.4
15:38 < gmaxwell> the 'brokenness' I saw reported seems irrelevant to us (or at least has a trivial workaround)
15:38 < gmaxwell> the brokenness I saw was that when called with an empty fd set it didn't sleep, and instead busylooped.
15:39 < phantomcircuit> ah
15:39 < phantomcircuit> hmm
15:40 < phantomcircuit> well it is possible for us to have no peers but is definitely extremely unusual
15:43 < gmaxwell> yes, sure but just add a check if there is an empty fdset, sleep instead of calling poll.
15:43 < gmaxwell> which is a perfectly reasonable thing to do.
15:52 < phantomcircuit> right
15:52 < phantomcircuit> should probably do the same for select() actually
15:55 < gmaxwell> yea, it would be a simple thing to do.
15:55 < gmaxwell> I mean, absent bugs, pool/select are a perfectly reasonable way to sleep.
16:00 < phantomcircuit> gmaxwell, yeah but bugs lol
16:00 < phantomcircuit> iirc the boost implementation actually uses them in certain cases but as like th absolute final thing it tries
16:01 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Quit: .]
16:02 < gmaxwell> poll*
16:08 < TD-Linux> bitcoin runs on os x 10.4?
16:09 < gmaxwell> I think in the prior discussion we concluded that it didn't but then there was some comment that someone somewhere said OSX brought the bug back.
16:18 < sdaftuar> fyi - someone seems to have mined an invalid block on testnet, exploiting the duplicate-input issue
16:18 < gmaxwell> If someone wants a lot of sweet sweet testnet coins, they should start mining with a fixed node. :P
16:18 < sdaftuar> it's currently the most work chain, though there appears to be a competing chain that is not too far behind
16:19 < BlueMatt> heh, I mean if you timewarp it it takes seconds to mine a few blocks
16:20 < gmaxwell> When the fixed chain catches up, all the vulnerable nodes will shut off, as disconnecting the inflation will trigger an assertion.
16:22 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Quit: Ping timeout (120 seconds)]
16:22 < phantomcircuit> gmaxwell, also http://www.greenend.org.uk/rjk/tech/poll.html
16:22 -!- murrayn [~murrayn@unaffiliated/murrayn] has quit [Read error: Connection reset by peer]
16:22 < phantomcircuit> doesn't actually matter for us since we do the same thing for IN/HUP/ERR
16:22 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has joined #bitcoin-core-dev
16:22 < phantomcircuit> but none the less something to keep in mind
16:23 < BlueMatt> phantomcircuit: dont you have an asic lying around? plz timewarp testnet
16:23 -!- murrayn [~murrayn@unaffiliated/murrayn] has joined #bitcoin-core-dev
16:23 < phantomcircuit> BlueMatt, effort
16:52 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev
16:53 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Killed (verne.freenode.net (Nickname regained by services))]
16:53 -!- DougieBot5000_ is now known as DougieBot5000
16:57 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
17:07 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
17:11 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Ping timeout: 260 seconds]
17:12 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has joined #bitcoin-core-dev
17:16 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test]
17:26 -!- murrayn [~murrayn@unaffiliated/murrayn] has quit [Read error: Connection reset by peer]
17:28 -!- murrayn [~murrayn@unaffiliated/murrayn] has joined #bitcoin-core-dev
17:36 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
17:56 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev
18:05 -!- jarthur [~jarthur@2600:1f18:3d:4600:699a:d6b3:76e8:9b8d] has joined #bitcoin-core-dev
18:06 < jarthur> Any of you pretty familiar with the functional tests?
18:07 < jarthur> In the ones that spin up a couple peers, I'm curious how deterministic the peer numbers are when asserting log text.
18:14 < sipa> the peer numbers are sequential
18:14 < sipa> time of connectio 
18:19 < jarthur> Makes sense. Do the multi-peer test usually connect the nodes in sequence to avoid non-deterministic output?
18:19 < jarthur> s/test/tests/
18:25 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]
18:28 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
19:01 < phantomcircuit> anybody know why the linter is failing on #14336
19:01 < gribble> https://github.com/bitcoin/bitcoin/issues/14336 | net: implement poll by pstratem · Pull Request #14336 · bitcoin/bitcoin · GitHub
19:06 < phantomcircuit> ah i see nvm
19:06 < gmaxwell> jarthur: I think they are in practice, but as a general rule a test should try to avoid being sensitive to things other than what they're testing, otherwise it makes them brittle.
19:06 < phantomcircuit> the white space linter is confusing when run against multiple commits the corresponding message are nonsensical
19:21 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: Leaving]
19:26 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
19:32 < jarthur> gmaxwell: thanks
19:45 -!- charley [~storage@storagethere.com] has joined #bitcoin-core-dev
20:02 < phantomcircuit> aight i have no idea why it's failing that test and cannot reproduce locally
20:03 < gmaxwell> phantomcircuit: looking
20:03 < phantomcircuit> https://travis-ci.org/bitcoin/bitcoin/jobs/433861290
20:03 < phantomcircuit> bitcoind exiting with code -6 during initialization
20:03 < gmaxwell> phantomcircuit: so thats an enable debug build.
20:03 < phantomcircuit> yes
20:04 < gmaxwell> so with enable debug, rpc bind functional test passes for you?
20:05 < phantomcircuit> yes
20:05 < phantomcircuit> all tests pass actually
20:06 < phantomcircuit>  ./configure --with-debug --with-incompatible-bdb --enable-zmq --with-gui=qt5 --enable-glibc-back-compat --enable-reduce-exports --enable-debug
20:08 < phantomcircuit> the only -6 is see as a constant is the addrman check but that should just write to the log
20:08 < gmaxwell> I dunno what -6 means there... like if it died on due to an unhandled signal it would one hundred and something.
20:11 < gmaxwell> perhaps, $ errno 6
20:11 < gmaxwell> ENXIO 6 No such device or address
20:11 < gmaxwell> there might be a case where the test triggers an error that the old code ignores and the new code propagates.
20:12 < gmaxwell> like what happens if you try to bind to 127.0.0.1 but there isn't a 127.0.0.1?
20:13 -!- prometheus_falli [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has quit [Remote host closed the connection]
20:16 -!- prometheus_falli [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has joined #bitcoin-core-dev
20:18 < phantomcircuit> gmaxwell, should fail in the same ways im pretty sure
20:18 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
20:21 < gmaxwell> in any case a reason that test may fail on travis and work for you, is that the travis enviroment probably has pretty different networking.
20:21 < phantomcircuit> yeah im sure it does
20:22 < gmaxwell> And the reason it would matter is if under that case, you handle errors differently, e.g. the actual bug may be elsewhere in bitcoin or in the test but were hidden by the old behavior.  The fact that you can't reproduce it locally is kind of annoying. you could try to figure out which test case is failing, by adding commits to change the test.
20:25 -!- asoltys [~adam@104.198.96.115] has joined #bitcoin-core-dev
20:30 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test]
20:45 < phantomcircuit> gmaxwell, indeed
21:06 -!- jarthur [~jarthur@2600:1f18:3d:4600:699a:d6b3:76e8:9b8d] has quit [Remote host closed the connection]
21:07 -!- jarthur [~jarthur@2600:1f18:3d:4600:699a:d6b3:76e8:9b8d] has joined #bitcoin-core-dev
21:09 < phantomcircuit> gmaxwell, i guess travis doesn't have ipv4?
21:09 < phantomcircuit> it's specifically the ipv4 rpc bind that's failing
21:11 < phantomcircuit> hmm it doesn't , not specifically 127.0.0.1
21:11 < phantomcircuit> which is what the test tries to bind to
21:22 -!- jarthur [~jarthur@2600:1f18:3d:4600:699a:d6b3:76e8:9b8d] has quit []
21:29 < phantomcircuit> gmaxwell, blargh there's still the select() calls in netbase
21:33 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
21:34 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
21:55 -!- escrivner [~user@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-dev
22:05 -!- qrestlove [~qrestlove@2605:6000:eb4a:ef00:801e:5c6d:4ab1:f03f] has quit [Ping timeout: 240 seconds]
22:13 < kallewoof> wumpus: noticed that NicolasDorier is not in the Credits list despite him being listed for 9991 at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes
22:14 < kallewoof> we just edit? I thought credits were automagic
22:19 -!- itaseski [~itaseski@213.135.176.159] has joined #bitcoin-core-dev
22:39 -!- qrestlove [~qrestlove@2605:6000:eb4a:ef00:41d2:d0e4:9822:61e] has joined #bitcoin-core-dev
22:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
22:45 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
23:08 -!- itaseski [~itaseski@213.135.176.159] has quit [Ping timeout: 272 seconds]
23:20 -!- go1111111 [go1111111@gateway/vpn/privateinternetaccess/go1111111] has quit [Ping timeout: 246 seconds]
23:33 -!- emzy [~quassel@unaffiliated/emzy] has quit [Ping timeout: 252 seconds]
23:36 -!- go1111111 [~go1111111@104.156.98.86] has joined #bitcoin-core-dev
--- Log closed Thu Sep 27 00:00:20 2018