12018-09-26T00:11:19 *** Murch has quit IRC
22018-09-26T00:17:51 *** proletesseract has joined #bitcoin-core-dev
32018-09-26T00:31:27 *** dqx has quit IRC
42018-09-26T00:32:30 *** promag has quit IRC
52018-09-26T00:35:52 *** jarthur has joined #bitcoin-core-dev
62018-09-26T00:39:17 <jarthur> MarcoFalke: on #14305 I agree about the functional test ought to have been failing prior to fixing the bad attributes. Would you want to see that addressed in the same PR or a separate one?
72018-09-26T00:39:19 <gribble> https://github.com/bitcoin/bitcoin/issues/14305 | Tests: enforce critical class instance attributes in functional tests by JustinTArthur · Pull Request #14305 · bitcoin/bitcoin · GitHubAsset 1Asset 1
82018-09-26T00:57:15 <michagogo> I seem to have lost the 0.15.2 unsigned bundles :-/
92018-09-26T00:57:46 <michagogo> Looks like the input file name is always the same, uncersionrd
102018-09-26T00:57:51 <michagogo> Unversioned
112018-09-26T00:58:19 <michagogo> And my script `mv`s the output to that input file
122018-09-26T01:03:15 *** promag has joined #bitcoin-core-dev
132018-09-26T01:05:12 <achow101> michagogo: I noticed that too. I'm working on a solution
142018-09-26T01:07:47 *** promag has quit IRC
152018-09-26T01:09:46 *** proletesseract has quit IRC
162018-09-26T01:15:29 *** promag has joined #bitcoin-core-dev
172018-09-26T01:19:52 *** promag has quit IRC
182018-09-26T01:21:21 *** gnusha has joined #bitcoin-core-dev
192018-09-26T01:25:48 *** jpe__ has joined #bitcoin-core-dev
202018-09-26T01:27:41 *** promag has joined #bitcoin-core-dev
212018-09-26T01:28:21 *** jpe_ has quit IRC
222018-09-26T01:32:15 *** promag has quit IRC
232018-09-26T01:40:06 *** promag has joined #bitcoin-core-dev
242018-09-26T01:45:14 *** promag has quit IRC
252018-09-26T01:49:47 *** Zenton has quit IRC
262018-09-26T01:50:21 *** Zenton has joined #bitcoin-core-dev
272018-09-26T01:57:54 *** promag has joined #bitcoin-core-dev
282018-09-26T01:58:26 *** grafcaps has quit IRC
292018-09-26T02:02:17 *** promag has quit IRC
302018-09-26T02:08:12 *** promag has joined #bitcoin-core-dev
312018-09-26T02:10:32 *** Sinclair_ has quit IRC
322018-09-26T02:17:32 *** promag has quit IRC
332018-09-26T02:32:21 *** Zenton has quit IRC
342018-09-26T02:32:29 *** Zenton has joined #bitcoin-core-dev
352018-09-26T02:36:32 *** Chris_Stewart_5 has quit IRC
362018-09-26T02:46:14 *** RubenSomsen has joined #bitcoin-core-dev
372018-09-26T02:50:30 *** promag has joined #bitcoin-core-dev
382018-09-26T02:55:15 *** promag has quit IRC
392018-09-26T03:04:13 *** Emcy has quit IRC
402018-09-26T03:06:18 *** Zenton has quit IRC
412018-09-26T03:07:04 *** Zenton has joined #bitcoin-core-dev
422018-09-26T03:17:00 *** gnusha has quit IRC
432018-09-26T03:18:55 *** gnusha has joined #bitcoin-core-dev
442018-09-26T03:21:45 *** promag has joined #bitcoin-core-dev
452018-09-26T03:23:34 *** bsm117532 has quit IRC
462018-09-26T03:26:06 *** promag has quit IRC
472018-09-26T03:29:41 *** proletesseract has joined #bitcoin-core-dev
482018-09-26T03:58:14 *** promag has joined #bitcoin-core-dev
492018-09-26T04:02:57 *** promag has quit IRC
502018-09-26T04:18:01 *** rh0nj has quit IRC
512018-09-26T04:19:08 *** rh0nj has joined #bitcoin-core-dev
522018-09-26T04:20:46 *** VanCo has joined #bitcoin-core-dev
532018-09-26T04:26:05 *** promag has joined #bitcoin-core-dev
542018-09-26T04:30:34 *** promag has quit IRC
552018-09-26T04:35:37 *** VanCo has left #bitcoin-core-dev
562018-09-26T04:47:52 *** spinza has quit IRC
572018-09-26T05:00:53 *** spinza has joined #bitcoin-core-dev
582018-09-26T05:01:02 *** rex4539 has quit IRC
592018-09-26T05:13:01 *** proletesseract has quit IRC
602018-09-26T05:22:25 *** proletesseract has joined #bitcoin-core-dev
612018-09-26T05:24:02 *** proletesseract has quit IRC
622018-09-26T05:24:10 *** proletesseract has joined #bitcoin-core-dev
632018-09-26T05:24:56 *** gribble has quit IRC
642018-09-26T05:35:29 *** hebasto has joined #bitcoin-core-dev
652018-09-26T05:39:02 *** warren_ is now known as warren
662018-09-26T05:39:07 *** gribble has joined #bitcoin-core-dev
672018-09-26T05:39:26 *** ppaqmj has quit IRC
682018-09-26T05:48:31 *** profmac has quit IRC
692018-09-26T05:50:44 *** promag has joined #bitcoin-core-dev
702018-09-26T05:55:29 *** promag has quit IRC
712018-09-26T06:04:22 *** proletesseract has quit IRC
722018-09-26T06:09:31 *** promag has joined #bitcoin-core-dev
732018-09-26T06:14:11 *** promag has quit IRC
742018-09-26T06:17:14 *** promag has joined #bitcoin-core-dev
752018-09-26T06:22:00 *** promag has quit IRC
762018-09-26T06:35:52 *** promag has joined #bitcoin-core-dev
772018-09-26T06:40:04 *** promag has quit IRC
782018-09-26T06:43:07 *** jarthur has quit IRC
792018-09-26T06:43:45 *** jarthur has joined #bitcoin-core-dev
802018-09-26T06:44:53 *** hebasto has quit IRC
812018-09-26T06:46:06 *** hebasto has joined #bitcoin-core-dev
822018-09-26T06:46:32 *** Krellan has joined #bitcoin-core-dev
832018-09-26T06:49:38 *** promag has joined #bitcoin-core-dev
842018-09-26T06:51:55 *** proletesseract has joined #bitcoin-core-dev
852018-09-26T06:54:26 *** promag has quit IRC
862018-09-26T07:01:47 *** Zenton has quit IRC
872018-09-26T07:27:11 *** Sinclair6 has joined #bitcoin-core-dev
882018-09-26T07:28:59 *** nullptr| has quit IRC
892018-09-26T07:33:06 *** nullptr| has joined #bitcoin-core-dev
902018-09-26T07:41:06 *** SopaXorzTaker has joined #bitcoin-core-dev
912018-09-26T07:41:24 *** proletesseract has quit IRC
922018-09-26T07:48:04 *** proletesseract has joined #bitcoin-core-dev
932018-09-26T08:00:05 *** nullptr| has quit IRC
942018-09-26T08:01:09 *** josephnicholas has joined #bitcoin-core-dev
952018-09-26T08:01:39 *** setpill has joined #bitcoin-core-dev
962018-09-26T08:07:15 *** timothy has joined #bitcoin-core-dev
972018-09-26T08:09:06 *** prometheus_falli has joined #bitcoin-core-dev
982018-09-26T08:12:13 *** t0adst00l has quit IRC
992018-09-26T08:14:46 *** josephnicholas has quit IRC
1002018-09-26T08:17:59 <wumpus> [back home from Riga, will probably need to catch up on a lot of things]
1012018-09-26T08:22:10 <wumpus> did anything come in preventing us from tagging 0.17.0 final?
1022018-09-26T08:23:34 <sipa> wumpus: i'd like to make sure #14289 is not a regression
1032018-09-26T08:23:35 <gribble> https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub
1042018-09-26T08:24:31 <wumpus> okay
1052018-09-26T08:25:20 <wumpus> yes that one is fairly nasty
1062018-09-26T08:25:29 <sipa> provoostenator said he was going to retry with 0.16 tomorrow
1072018-09-26T08:25:50 <sipa> i guess today
1082018-09-26T08:29:11 *** promag has joined #bitcoin-core-dev
1092018-09-26T08:30:01 <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
1102018-09-26T08:40:13 <wumpus> breaking backwards compatibility, even temporarily, is kind of a bummer â though they could always reindex
1112018-09-26T08:40:51 <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
1122018-09-26T08:41:25 <gmaxwell> we could easily add an exit in that rewind code. though at that point, it might make sense to just fix the problem.
1132018-09-26T08:43:37 *** Zenton has joined #bitcoin-core-dev
1142018-09-26T08:48:28 <wumpus> also depends on the risk of the change, e.g. queue limited naively at least could introduce deadlocks
1152018-09-26T08:49:48 <gmaxwell> yea, obviously not that.
1162018-09-26T08:55:52 *** SopaXorzTaker has quit IRC
1172018-09-26T09:12:38 <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
1182018-09-26T09:19:14 *** AaronvanW has joined #bitcoin-core-dev
1192018-09-26T09:36:00 *** nullptr| has joined #bitcoin-core-dev
1202018-09-26T09:37:05 *** phwalkr has joined #bitcoin-core-dev
1212018-09-26T10:00:38 *** Victorsueca has quit IRC
1222018-09-26T10:01:56 *** Victorsueca has joined #bitcoin-core-dev
1232018-09-26T10:12:14 *** belcher has joined #bitcoin-core-dev
1242018-09-26T10:13:29 *** intcat has quit IRC
1252018-09-26T10:15:23 *** intcat has joined #bitcoin-core-dev
1262018-09-26T10:24:39 *** Krellan has quit IRC
1272018-09-26T10:25:41 *** Krellan has joined #bitcoin-core-dev
1282018-09-26T10:27:21 *** Zenton has quit IRC
1292018-09-26T10:27:42 *** Zenton has joined #bitcoin-core-dev
1302018-09-26T10:37:06 *** proletesseract has quit IRC
1312018-09-26T10:44:47 *** reallll has joined #bitcoin-core-dev
1322018-09-26T10:47:58 *** belcher has quit IRC
1332018-09-26T10:58:10 *** belcher has joined #bitcoin-core-dev
1342018-09-26T11:10:39 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1352018-09-26T11:13:34 *** phwalkr has quit IRC
1362018-09-26T11:14:08 *** phwalkr has joined #bitcoin-core-dev
1372018-09-26T11:18:40 *** phwalkr has quit IRC
1382018-09-26T11:24:34 *** Krellan has quit IRC
1392018-09-26T11:25:23 *** Guyver2 has joined #bitcoin-core-dev
1402018-09-26T11:25:34 *** Krellan has joined #bitcoin-core-dev
1412018-09-26T11:26:42 *** karelb has joined #bitcoin-core-dev
1422018-09-26T11:33:08 <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/
1432018-09-26T11:34:16 <karelb> I have tried to write something like a proposal for unified formatting that would help with parsing... I wrote it here
1442018-09-26T11:34:23 <karelb> https://gist.github.com/karel-3d/1490786786525b0365ea8f459a9fc683
1452018-09-26T11:34:31 <karelb> this is like draft 0
1462018-09-26T11:34:41 <karelb> do you think it's a good idea?
1472018-09-26T11:35:50 <karelb> It requires some small changes to current documentation
1482018-09-26T11:37:34 *** Emcy has joined #bitcoin-core-dev
1492018-09-26T11:44:37 *** Emcy has quit IRC
1502018-09-26T11:47:54 *** Emcy has joined #bitcoin-core-dev
1512018-09-26T11:55:21 *** promag has quit IRC
1522018-09-26T11:58:06 <wumpus> the idea to have machine-parseable documentation format that is formatted on the fly has been floated before, at least
1532018-09-26T12:00: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
1542018-09-26T12:00:27 <wumpus> all in all though it'd certainly be an improvement, the manual space-pushing that has to be done now is silly
1552018-09-26T12:01:02 <wumpus> and it's also hard to keep things (such as type names) consistent
1562018-09-26T12:02:55 <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...
1572018-09-26T12:04:19 <karelb> I tried to make the current proposal close to the current format
1582018-09-26T12:05:02 <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).
1592018-09-26T12:06:03 <karelb> I think external JSON would get outdated soon and people would forget to update
1602018-09-26T12:08:05 *** Chris_Stewart_5 has quit IRC
1612018-09-26T12:09:47 <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.
1622018-09-26T12:09:49 <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)
1632018-09-26T12:11:00 <wumpus> right, in the case of an external file, *should* add a comment to each function where it's documented...
1642018-09-26T12:11:01 <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
1652018-09-26T12:12:17 <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. :-)
1662018-09-26T12:14:08 <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?
1672018-09-26T12:14: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
1682018-09-26T12:14:19 <karelb> wumpus: I guess so!
1692018-09-26T12:14:26 <wumpus> it doesn't even have to lint on the source code BTW - it could simply call the RPC server, request help, lint that
1702018-09-26T12:15:40 <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
1712018-09-26T12:15:40 <harding> the linted and a list of changes that actually need to be made.
1722018-09-26T12:15:41 <wumpus> (FWIW this is how the manual page generation also works; it calls bitcoind &c --help and generates from that)
1732018-09-26T12:16:39 <wumpus> in any case work on improving the docs is always welcome, thanks for thinking about this
1742018-09-26T12:16:43 <karelb> harding: good idea
1752018-09-26T12:17:35 <karelb> wumpus: I am basically scratching my own itch :D the same with this issue
1762018-09-26T12:17:35 <karelb> https://github.com/achow101/btcinformation.org/issues/23
1772018-09-26T12:18:38 <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
1782018-09-26T12:23:30 *** panako has joined #bitcoin-core-dev
1792018-09-26T12:35:51 <wumpus> I never forget what a sighash is, but I must admit I forget what are the different combinations for it sometimes
1802018-09-26T12:38:24 *** elichai2 has joined #bitcoin-core-dev
1812018-09-26T12:40:21 *** Krellan has quit IRC
1822018-09-26T12:40:58 *** Krellan has joined #bitcoin-core-dev
1832018-09-26T12:42:31 *** setpill has quit IRC
1842018-09-26T12:48:30 *** phwalkr has joined #bitcoin-core-dev
1852018-09-26T12:51:35 <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.
1862018-09-26T12:51:36 <gribble> https://github.com/bitcoin/bitcoin/issues/14327 | macOS Mojave QT 5.11 compilation fails · Issue #14327 · bitcoin/bitcoin · GitHub
1872018-09-26T12:52:58 *** phwalkr has quit IRC
1882018-09-26T12:53:15 <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.
1892018-09-26T12:56:50 *** jungly has joined #bitcoin-core-dev
1902018-09-26T13:03:04 *** csknk has joined #bitcoin-core-dev
1912018-09-26T13:15:56 *** baldur has quit IRC
1922018-09-26T13:26:56 *** gertjaap has quit IRC
1932018-09-26T13:27:01 *** rh0nj has quit IRC
1942018-09-26T13:28:07 *** rh0nj has joined #bitcoin-core-dev
1952018-09-26T13:33:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1962018-09-26T13:35:17 <wumpus> why doesn't travis catch this?
1972018-09-26T13:35:40 <wumpus> oh, it's a build *on* mac not for mac
1982018-09-26T13:35:59 <provoostenator> I haven't tried a cross compile to the latest macOS SDK; we build for a much older version afaik.
1992018-09-26T13:36:24 <wumpus> that would be one of the most difficult things to automate unless there's something like Appveyor for windows for macs
2002018-09-26T13:36:56 <provoostenator> Perhaps trying to cross-compile to a beta release (~ June / July / August) might also help catch this.
2012018-09-26T14:02:28 *** baldur has joined #bitcoin-core-dev
2022018-09-26T14:11:18 *** baldur has quit IRC
2032018-09-26T14:12:22 *** michaelsdunn1 has joined #bitcoin-core-dev
2042018-09-26T14:12:31 *** jarthur has quit IRC
2052018-09-26T14:16:24 *** baldur has joined #bitcoin-core-dev
2062018-09-26T14:19:46 *** promag has joined #bitcoin-core-dev
2072018-09-26T14:20:01 <promag> achow101: do you plan to fix #14019 nits?
2082018-09-26T14:20:04 <gribble> https://github.com/bitcoin/bitcoin/issues/14019 | Import pubkeys when importing p2sh with importmulti by achow101 · Pull Request #14019 · bitcoin/bitcoin · GitHub
2092018-09-26T14:20:28 <promag> I can push those fixes if you want
2102018-09-26T14:20:40 <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.
2112018-09-26T14:20:55 <provoostenator> I'll try 0.15.2 later today too.
2122018-09-26T14:21:13 *** SopaXorzTaker has joined #bitcoin-core-dev
2132018-09-26T14:23:54 <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?
2142018-09-26T14:24:08 *** twistedline has quit IRC
2152018-09-26T14:24:18 <provoostenator> Getting "failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)"
2162018-09-26T14:32:58 *** SopaXorzTaker has quit IRC
2172018-09-26T14:35:21 *** irc_viewer_test has joined #bitcoin-core-dev
2182018-09-26T14:37:21 *** twistedline has joined #bitcoin-core-dev
2192018-09-26T14:42:03 *** irc_viewer_test has quit IRC
2202018-09-26T14:44:21 *** rex4539 has joined #bitcoin-core-dev
2212018-09-26T15:05:10 *** Krellan has quit IRC
2222018-09-26T15:09:07 *** Krellan has joined #bitcoin-core-dev
2232018-09-26T15:09:35 <achow101> promag: oh, I didn't see those. I'll fix them later today
2242018-09-26T15:10:27 <promag> achow101: no problem
2252018-09-26T15:18:47 *** Krellan has quit IRC
2262018-09-26T15:37:58 *** proletesseract has joined #bitcoin-core-dev
2272018-09-26T15:39:27 *** Krellan has joined #bitcoin-core-dev
2282018-09-26T15:42:24 *** proletesseract has quit IRC
2292018-09-26T15:43:52 *** Krellan has quit IRC
2302018-09-26T15:49:09 *** Krellan has joined #bitcoin-core-dev
2312018-09-26T15:54:01 *** Krellan has quit IRC
2322018-09-26T15:54:40 *** Krellan has joined #bitcoin-core-dev
2332018-09-26T15:59:02 *** Krellan has quit IRC
2342018-09-26T16:00:09 *** Krellan has joined #bitcoin-core-dev
2352018-09-26T16:20:12 *** Murch has joined #bitcoin-core-dev
2362018-09-26T16:23:27 *** bralyclow has joined #bitcoin-core-dev
2372018-09-26T16:25:07 <provoostenator> (fixed Gitian by deleting images from gitian-builder and rebuilding using the v0.16 gitan script)
2382018-09-26T16:30:27 *** Zenton has quit IRC
2392018-09-26T16:32:13 *** Chris_Stewart_5 has quit IRC
2402018-09-26T16:32:42 <andytoshi> achow101: i have a question about psbt BIP 174
2412018-09-26T16:32:53 <andytoshi> what's the expected behaviour regarding uncompressed ECDSA keys
2422018-09-26T16:33:01 <andytoshi> the spec doesn't mention this at all and the test vectors only have compressed keys in them
2432018-09-26T16:34:03 *** morcos has quit IRC
2442018-09-26T16:34:20 *** morcos has joined #bitcoin-core-dev
2452018-09-26T16:38:46 <sipa> provoostenator: thanks, so it's an earlier regression
2462018-09-26T16:39:11 <sipa> provoostenator:, gmaxwell, wumpus: agree with just listing in the release notes that upgrading from 0.13 may not be practical
2472018-09-26T16:53:30 *** phwalkr has joined #bitcoin-core-dev
2482018-09-26T16:54:24 *** nehan_ has joined #bitcoin-core-dev
2492018-09-26T16:55:05 *** nehan_ has quit IRC
2502018-09-26T16:55:58 *** owowo has quit IRC
2512018-09-26T16:57:56 *** phwalkr has quit IRC
2522018-09-26T16:58:25 *** belcher has quit IRC
2532018-09-26T17:01:04 *** phwalkr has joined #bitcoin-core-dev
2542018-09-26T17:02:04 <achow101> andytoshi: the same as compressed keys
2552018-09-26T17:02:33 *** irc_viewer_test has joined #bitcoin-core-dev
2562018-09-26T17:02:39 <achow101> bip32 is defined for compressed keys only though, so you should only use compressed keys in the bip32 derivs
2572018-09-26T17:04:05 <dongcarl> ARGHGGHHGHGHGHGHHGHGHHGHHHHGGHHHH
2582018-09-26T17:04:21 <dongcarl> k
2592018-09-26T17:04:46 <sipa> achow101: probably worth pointing that out in the bip
2602018-09-26T17:05:04 <sipa> it's also not all that clear in bip32... it just only talks about serialization using compressed form
2612018-09-26T17:06:11 <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
2622018-09-26T17:07:06 *** Krellan has quit IRC
2632018-09-26T17:07: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)
2642018-09-26T17:07:36 <sipa> andytoshi: that sounds like it'd make your life hard :)
2652018-09-26T17:07:37 <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)
2662018-09-26T17:07:43 <sipa> if you want to support uncompressed keys at all
2672018-09-26T17:08:13 *** Krellan has joined #bitcoin-core-dev
2682018-09-26T17:08:35 <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
2692018-09-26T17:08:46 <andytoshi> so yeah.. we're basically only supporting uncompressed keys for that one specific use case
2702018-09-26T17:08:49 <andytoshi> and nowhere else
2712018-09-26T17:09:10 <achow101> i don't follow what the problem is
2722018-09-26T17:09:56 <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
2732018-09-26T17:10:08 <sipa> as the internal type for pubkeys does not store this
2742018-09-26T17:10:13 <andytoshi> yep
2752018-09-26T17:11:26 <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
2762018-09-26T17:11:51 *** dqx has joined #bitcoin-core-dev
2772018-09-26T17:12:16 <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
2782018-09-26T17:12:34 <sipa> hash is different, p2pkh spend is different, address is different, ...
2792018-09-26T17:13:06 <andytoshi> yeah
2802018-09-26T17:13:50 <sipa> but i also think it's more efficient to keep pubkeys in serialized form, and only convert to secp when signing
2812018-09-26T17:14:07 <sipa> because most operations care about its serialization and not its EC identity
2822018-09-26T17:14:22 <achow101> andytoshi can't you just copy the bytes instead of parsing it?
2832018-09-26T17:14:57 <achow101> in many cases, you don't need to know that it's a pubkey, you just need to compare the bytes.
2842018-09-26T17:15:07 <andytoshi> sipa: verification and bip32 operations all care about the EC identity
2852018-09-26T17:15:34 *** irc_viewer_test has quit IRC
2862018-09-26T17:15:35 <sipa> andytoshi: sure, but computing a hash or lookup don't
2872018-09-26T17:15:53 <andytoshi> sipa: you never hash a public key directly, only scriptpubkeys containing public keys
2882018-09-26T17:16:07 <sipa> andytoshi: eh, no :)
2892018-09-26T17:16:11 <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
2902018-09-26T17:16:12 <sipa> P2PKH addresses
2912018-09-26T17:16:18 <andytoshi> oh right
2922018-09-26T17:16:50 <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
2932018-09-26T17:17:00 <sipa> so you already have the deserialization cost anyway
2942018-09-26T17:17:04 *** Krellan has quit IRC
2952018-09-26T17:17:46 *** Krellan has joined #bitcoin-core-dev
2962018-09-26T17:18:10 <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, ...)
2972018-09-26T17:18:33 <andytoshi> then i might as well use a (compressedness, secp pubkey) pair
2982018-09-26T17:18:50 <sipa> that's expensive :)
2992018-09-26T17:19:08 <sipa> converting a compressed serialization to that format requires deserialization
3002018-09-26T17:19:14 <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
3012018-09-26T17:19:44 <sipa> the things you do all the time are looking up "does this pubkey belong to me"
3022018-09-26T17:20:01 <andytoshi> in Core maybe
3032018-09-26T17:20:15 <sipa> fair, in a library it's less clear what the usage pattern is
3042018-09-26T17:20:36 <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
3052018-09-26T17:20:58 <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
3062018-09-26T17:21:07 <andytoshi> or in a generic PSBT validator where you're really just checking sigs and doing derivations and never really interacting whith the blockchain
3072018-09-26T17:21:29 <andytoshi> does libsecp expose a way to determine that a pubkey is valid or not without decompressing it?
3082018-09-26T17:22:14 *** Krellan has quit IRC
3092018-09-26T17:22:15 <sipa> i don't think so
3102018-09-26T17:22:30 <andytoshi> yeah..doesn't look like it
3112018-09-26T17:22:33 <sipa> but whether a pubkey is valid only matters when doing validation
3122018-09-26T17:22:49 <sipa> or signing
3132018-09-26T17:22:51 *** owowo has joined #bitcoin-core-dev
3142018-09-26T17:22:58 <andytoshi> or deriving child keys
3152018-09-26T17:23:02 <sipa> right
3162018-09-26T17:23:10 <sipa> all cases where you need to convert to the secp type anyway
3172018-09-26T17:23:39 <andytoshi> right, but it would be much nicer if i caught invalid data when i received it
3182018-09-26T17:24:09 <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
3192018-09-26T17:24:32 <sipa> but checking which ones you can sign with is something you can totally do on the byte representation
3202018-09-26T17:24:34 <andytoshi> hmm, this is true
3212018-09-26T17:26:12 <sipa> maybe it also doesn't matter; i think we can decompress 200000 keys per second
3222018-09-26T17:26:50 *** jarthur has joined #bitcoin-core-dev
3232018-09-26T17:26:59 <andytoshi> it would plausibly matter for an HSM
3242018-09-26T17:27:11 <sipa> possibly
3252018-09-26T17:27:21 *** Krellan has joined #bitcoin-core-dev
3262018-09-26T17:27:21 <andytoshi> in any case I think for the purposes of rust-bitcoin we're not too concerned about that
3272018-09-26T17:32:16 *** timothy has quit IRC
3282018-09-26T17:33:02 *** irc_viewer_test has joined #bitcoin-core-dev
3292018-09-26T17:34:19 *** Zenton has joined #bitcoin-core-dev
3302018-09-26T17:44:31 *** jarthur has quit IRC
3312018-09-26T17:45:07 *** Zenton has quit IRC
3322018-09-26T17:45:28 *** jarthur has joined #bitcoin-core-dev
3332018-09-26T17:46:26 *** irc_viewer_test has quit IRC
3342018-09-26T17:56:12 *** phwalkr has joined #bitcoin-core-dev
3352018-09-26T18:18:37 *** phwalkr has quit IRC
3362018-09-26T18:28:42 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3372018-09-26T18:39:19 *** jarthur has quit IRC
3382018-09-26T18:42:20 <provoostenator> sipa: v0.15.2 doesn't have the issue, so it was introduces somewhere in 0.16
3392018-09-26T18:43:13 <sipa> provoostenator: interesting, thanks!
3402018-09-26T18:45:18 <provoostenator> I might be able to do a (partial) bisect tomorrow if you're really at a loss where this bug started.
3412018-09-26T18:45:54 <sipa> i'm sure i can guess by looking at the PR list :)
3422018-09-26T18:56:47 *** Victorsueca has quit IRC
3432018-09-26T18:58:04 *** Victorsueca has joined #bitcoin-core-dev
3442018-09-26T19:36:14 *** dqx has quit IRC
3452018-09-26T19:36:53 *** dqx has joined #bitcoin-core-dev
3462018-09-26T19:42:33 <promag> someone willing to spend a minute in #14148?
3472018-09-26T19:42:33 <gribble> https://github.com/bitcoin/bitcoin/issues/14148 | abandontransaction needed after spending orphaned block reward · Issue #14148 · bitcoin/bitcoin · GitHub
3482018-09-26T19:46:21 *** Murch has quit IRC
3492018-09-26T19:57:16 *** proletesseract has joined #bitcoin-core-dev
3502018-09-26T19:58:01 <gmaxwell> sipa: see, I said it wasn't always there.
3512018-09-26T19:58:22 *** Zenton has joined #bitcoin-core-dev
3522018-09-26T20:20:07 *** proletesseract has quit IRC
3532018-09-26T20:36:51 *** Chris_Stewart_5 has quit IRC
3542018-09-26T20:41:21 *** Murch has joined #bitcoin-core-dev
3552018-09-26T20:45:12 *** Murch has quit IRC
3562018-09-26T20:52:55 *** csknk has quit IRC
3572018-09-26T20:54:50 *** hebasto has quit IRC
3582018-09-26T20:59:09 *** proletesseract has joined #bitcoin-core-dev
3592018-09-26T21:00:32 *** proletesseract has quit IRC
3602018-09-26T21:00:41 *** proletesseract has joined #bitcoin-core-dev
3612018-09-26T21:01:14 *** Murch has joined #bitcoin-core-dev
3622018-09-26T21:01:45 *** proletesseract has quit IRC
3632018-09-26T21:03:15 *** proletesseract has joined #bitcoin-core-dev
3642018-09-26T21:04:04 *** jpe__ has quit IRC
3652018-09-26T21:25:39 *** TheCharlatan has quit IRC
3662018-09-26T21:28:58 *** Guyver2 has quit IRC
3672018-09-26T21:29:46 *** irc_viewer_test has joined #bitcoin-core-dev
3682018-09-26T21:32:03 *** proletesseract has quit IRC
3692018-09-26T21:32:10 <phantomcircuit> gmaxwell, i simplified the ThreadSocketHandler cleanup in #14335
3702018-09-26T21:32:12 <gribble> https://github.com/bitcoin/bitcoin/issues/14335 | net: refactor: cleanup ThreadSocketHandler by pstratem · Pull Request #14335 · bitcoin/bitcoin · GitHub
3712018-09-26T21:34:58 <gmaxwell> phantomcircuit: sweet.
3722018-09-26T21:42:28 <promag> rfc: sounds good a bool CWallet::IsExternal() const? which returns false if wallet path is in -walletdir ?
3732018-09-26T21:42:48 <promag> jnewbery: ^
3742018-09-26T21:43:30 *** tryphe has quit IRC
3752018-09-26T22:04:00 *** dqx_ has joined #bitcoin-core-dev
3762018-09-26T22:04:45 *** dqx_ has quit IRC
3772018-09-26T22:05:23 *** dqx_ has joined #bitcoin-core-dev
3782018-09-26T22:06:18 *** dqx has quit IRC
3792018-09-26T22:14:03 *** elichai2 has quit IRC
3802018-09-26T22:19:26 *** commavir has quit IRC
3812018-09-26T22:20:48 *** commavir has joined #bitcoin-core-dev
3822018-09-26T22:37:23 <phantomcircuit> gmaxwell, and #14336 actually implements poll()
3832018-09-26T22:37:24 <gribble> https://github.com/bitcoin/bitcoin/issues/14336 | net: implement poll by pstratem · Pull Request #14336 · bitcoin/bitcoin · GitHub
3842018-09-26T22:37:29 *** michaelsdunn1 has quit IRC
3852018-09-26T22:37:36 <phantomcircuit> im still not sure how to detect whether the poll() available is functional or not
3862018-09-26T22:38:03 <phantomcircuit> apparently it's broken on OS X <= 10.4
3872018-09-26T22:38:32 <gmaxwell> the 'brokenness' I saw reported seems irrelevant to us (or at least has a trivial workaround)
3882018-09-26T22:38:53 <gmaxwell> the brokenness I saw was that when called with an empty fd set it didn't sleep, and instead busylooped.
3892018-09-26T22:39:45 <phantomcircuit> ah
3902018-09-26T22:39:48 <phantomcircuit> hmm
3912018-09-26T22:40:13 <phantomcircuit> well it is possible for us to have no peers but is definitely extremely unusual
3922018-09-26T22:43:21 <gmaxwell> yes, sure but just add a check if there is an empty fdset, sleep instead of calling poll.
3932018-09-26T22:43:34 <gmaxwell> which is a perfectly reasonable thing to do.
3942018-09-26T22:52:31 <phantomcircuit> right
3952018-09-26T22:52:43 <phantomcircuit> should probably do the same for select() actually
3962018-09-26T22:55:07 <gmaxwell> yea, it would be a simple thing to do.
3972018-09-26T22:55:26 <gmaxwell> I mean, absent bugs, pool/select are a perfectly reasonable way to sleep.
3982018-09-26T23:00:26 <phantomcircuit> gmaxwell, yeah but bugs lol
3992018-09-26T23:00:52 <phantomcircuit> iirc the boost implementation actually uses them in certain cases but as like th absolute final thing it tries
4002018-09-26T23:01:35 *** dqx_ has quit IRC
4012018-09-26T23:02:11 <gmaxwell> poll*
4022018-09-26T23:08:00 <TD-Linux> bitcoin runs on os x 10.4?
4032018-09-26T23:09:36 <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.
4042018-09-26T23:18:04 <sdaftuar> fyi - someone seems to have mined an invalid block on testnet, exploiting the duplicate-input issue
4052018-09-26T23:18:38 <gmaxwell> If someone wants a lot of sweet sweet testnet coins, they should start mining with a fixed node. :P
4062018-09-26T23:18:45 <sdaftuar> it's currently the most work chain, though there appears to be a competing chain that is not too far behind
4072018-09-26T23:19:59 <BlueMatt> heh, I mean if you timewarp it it takes seconds to mine a few blocks
4082018-09-26T23:20:50 <gmaxwell> When the fixed chain catches up, all the vulnerable nodes will shut off, as disconnecting the inflation will trigger an assertion.
4092018-09-26T23:22:03 *** rockhouse has quit IRC
4102018-09-26T23:22:13 <phantomcircuit> gmaxwell, also http://www.greenend.org.uk/rjk/tech/poll.html
4112018-09-26T23:22:13 *** murrayn has quit IRC
4122018-09-26T23:22:26 <phantomcircuit> doesn't actually matter for us since we do the same thing for IN/HUP/ERR
4132018-09-26T23:22:27 *** rockhouse has joined #bitcoin-core-dev
4142018-09-26T23:22:32 <phantomcircuit> but none the less something to keep in mind
4152018-09-26T23:23:01 <BlueMatt> phantomcircuit: dont you have an asic lying around? plz timewarp testnet
4162018-09-26T23:23:35 *** murrayn has joined #bitcoin-core-dev
4172018-09-26T23:23:54 <phantomcircuit> BlueMatt, effort
4182018-09-26T23:52:22 *** DougieBot5000_ has joined #bitcoin-core-dev
4192018-09-26T23:53:22 *** DougieBot5000 has quit IRC
4202018-09-26T23:53:22 *** DougieBot5000_ is now known as DougieBot5000
4212018-09-26T23:57:18 *** Murch has quit IRC