12015-09-30T07:49:57  *** lightningbot has joined #bitcoin-core-dev
  22015-09-30T07:49:57  -sendak.freenode.net- [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
  32015-09-30T07:50:28  <aj> lightningbot: hello?
  42015-09-30T07:50:28  <lightningbot> aj: Error: "hello?" is not a valid command.
  52015-09-30T08:03:15  <wumpus> hello aj
  62015-09-30T08:08:07  <aj> wumpus: hi!
  72015-09-30T08:08:23  *** CodeShark_ has joined #bitcoin-core-dev
  82015-09-30T08:10:34  <aj> okay, seems to be working: http://www.erisian.com.au/bitcoin-core-dev/ has channel logs, as seen by lightningbot. updates are every 10m or so, timestamps should be UTC.
  92015-09-30T08:11:20  <wumpus> thanks!
 102015-09-30T08:11:52  <btcdrak> wumpus please add to the channel topic
 112015-09-30T08:12:02  *** ChanServ sets mode: +o wumpus
 122015-09-30T08:12:24  <btcdrak> thanks aj!
 132015-09-30T08:12:26  *** wumpus changes topic to "Bitcoin Core development discussion and commit log | http://www.erisian.com.au/bitcoin-core-dev/"
 142015-09-30T08:12:34  *** ChanServ sets mode: -o wumpus
 152015-09-30T08:12:46  <wumpus> uhm
 162015-09-30T08:12:48  *** ChanServ sets mode: +o wumpus
 172015-09-30T08:12:54  *** wumpus changes topic to "Bitcoin Core development discussion and commit log | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/"
 182015-09-30T08:13:01  *** ChanServ sets mode: -o wumpus
 192015-09-30T08:13:57  <CodeShark_> is it permitted to discuss software development here?
 202015-09-30T08:15:28  <wumpus> yes!
 212015-09-30T08:15:46  <wumpus> (if it concerns Bitcoin Core)
 222015-09-30T08:17:13  <CodeShark_>   ____  _ _            _        _____               _____
 232015-09-30T08:17:14  <CodeShark_>  |  _ \(_) |          (_)      / ____|             |  __ \
 242015-09-30T08:17:14  <CodeShark_>  | |_) |_| |_ ___ ___  _ _ __ | |     ___  _ __ ___| |  | | _____   __
 252015-09-30T08:17:14  <CodeShark_>  |  _ <| | __/ __/ _ \| | '_ \| |    / _ \| '__/ _ \ |  | |/ _ \ \ / /
 262015-09-30T08:17:14  <CodeShark_>  | |_) | | || (_| (_) | | | | | |___| (_) | | |  __/ |__| |  __/\ V /
 272015-09-30T08:17:14  <CodeShark_>  |____/|_|\__\___\___/|_|_| |_|\_____\___/|_|  \___|_____/ \___| \_/
 282015-09-30T08:17:18  <CodeShark_> yay! :)
 292015-09-30T08:17:34  <wumpus> whee
 302015-09-30T08:19:00  * btcdrak switches to monospaced font
 312015-09-30T08:19:06  * wumpus his IRC client has a proportional font thus distorts ASCII art, that's bad
 322015-09-30T08:19:30  <wumpus> I hate that quassel has no ncurses client
 332015-09-30T08:19:53  <aj> (doesn't work in 80 column monospace either; but logs got it right \o/)
 342015-09-30T08:28:53  <GitHub24> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c138cf976963...3f74cd2361b9
 352015-09-30T08:28:53  <GitHub24> bitcoin/master 05b5831 paveljanik: Add PR title prefix for trivial changes [skip ci]
 362015-09-30T08:28:54  <GitHub24> bitcoin/master 3f74cd2 Wladimir J. van der Laan: Merge pull request #6740...
 372015-09-30T08:28:58  <GitHub17> [bitcoin] laanwj closed pull request #6740: Trivial: Add PR title prefix for trivial changes [skip ci] (master...patch-11) https://github.com/bitcoin/bitcoin/pull/6740
 382015-09-30T08:29:15  <CodeShark_> hmm...
 392015-09-30T08:30:02  <CodeShark_> hopefully it's just merges into master...
 402015-09-30T08:30:18  <wumpus> no, it's also merges into 0.9, 0.10, and 0.11
 412015-09-30T08:30:45  <wumpus> (but those are much rare than merges to master, so I don't see the problem)
 422015-09-30T08:30:51  <CodeShark_> hmm...it's good info to have...as long as it's not happening all the time during dialog I suppose
 432015-09-30T08:31:37  <CodeShark_> hopefully travis won't be posting here ;)
 442015-09-30T08:31:52  <wumpus> don't give me ideas ;)
 452015-09-30T08:33:55  <wumpus> nah I get email spam from travis if the build is broken, I think that's enough
 462015-09-30T08:34:17  <CodeShark_> sounds a little more tolerable than the bitcoin-dev mailing list ;)
 472015-09-30T08:35:06  <wumpus> hah, right, at least it's a useful signal, that can't be said of all mailing list posts
 482015-09-30T09:02:22  <CodeShark_> do we currently have something in the RPC that allows inserting test blocks? (i.e. no PoW validation)
 492015-09-30T09:02:47  <CodeShark_> or any tool for that?
 502015-09-30T09:03:05  <wumpus> regtest?
 512015-09-30T09:03:27  <CodeShark_> yeah, I think so
 522015-09-30T09:03:35  <wumpus> there is pow validation, but it's so easy that it doesn't matter
 532015-09-30T09:03:37  *** rubensayshi has joined #bitcoin-core-dev
 542015-09-30T09:04:07  <CodeShark_> hmm...I'd like to test mainnet with fake blocks
 552015-09-30T09:04:24  <CodeShark_> I mean, not mainnet mainnet...but what my instance thinks is mainnet :p
 562015-09-30T09:05:17  <CodeShark_> I'm thinking I can disable ProcessNewBlock for network and just accept blocks from RPC...and disable PoW validation
 572015-09-30T09:08:57  <GitHub72> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3f74cd2361b9...4f44530bc38f
 582015-09-30T09:08:57  <GitHub72> bitcoin/master d76a8ac Jonas Schnelli: use CBlockIndex* insted of uint256 for UpdatedBlockTip signal...
 592015-09-30T09:08:58  <GitHub72> bitcoin/master 4f44530 Wladimir J. van der Laan: Merge pull request #6680...
 602015-09-30T09:09:02  <GitHub195> [bitcoin] laanwj closed pull request #6680: use CBlockIndex* insted of uint256 for UpdatedBlockTip signal (master...2015/09/zmq_cblockindex) https://github.com/bitcoin/bitcoin/pull/6680
 612015-09-30T09:13:04  <CodeShark_> speaking of CBlockIndex, right now we're passing around a pindexPrev variable on the call stack that seems superfluous
 622015-09-30T09:13:24  <CodeShark_> we could just be setting the pprev member
 632015-09-30T09:13:47  <CodeShark_> we're passing both class CBlockIndex& blockIndex and CBlockIndex* pindexPrev
 642015-09-30T09:14:29  <CodeShark_> but I'm mortified to touch main.cpp
 652015-09-30T09:14:49  <phantomcircuit> i guess this is #bitcoin-dev now
 662015-09-30T09:15:12  <CodeShark_> no, we've outgrown #bitcoin-dev ;)
 672015-09-30T09:15:14  <wumpus> CodeShark_: it seems duplicate, but I agree there may be subtle cases where it makes sense
 682015-09-30T09:15:49  <wumpus> e.g. before the pprev can be set, for some reason
 692015-09-30T09:16:07  <wumpus> phantomcircuit: this is #bitcoin-core-dev, not #bitcoin-dev, the distinction in channel name is relevant :)
 702015-09-30T09:16:25  <CodeShark_> well, first we have to find pprev in our index map...but once we've found it, I don't think there's any harm in setting pprev immediately
 712015-09-30T09:16:41  <CodeShark_> right now we're waiting until AddToBlockIndex to set it
 722015-09-30T09:17:16  <wumpus> I've wondered the same, a few times, that I remember
 732015-09-30T09:18:15  <CodeShark_> I have some ideas on how to clean up the block index...but as I said earlier, I'm mortified to touch main.cpp ;)
 742015-09-30T09:18:24  <wumpus> there doesn't seem to be a case where you want to call it with a *different* previous block
 752015-09-30T09:19:23  <CodeShark_> no, there really doesn't - the only case besides having it set would be having it NULL (if we either don't have it or don't know it)
 762015-09-30T09:19:58  <CodeShark_> barring a SHA256 collision ;)
 772015-09-30T09:21:31  <CodeShark_> I'd love to move the block index into its own unit...with a singleton map object
 782015-09-30T09:21:57  <CodeShark_> and it would be nice to store the block headers separately from the rest of the block data
 792015-09-30T09:23:51  <CodeShark_> that's to say, completely separate the logic
 802015-09-30T09:26:04  <CodeShark_> we've also got some redundant calls downstack from ProcessNewBlock
 812015-09-30T09:26:48  <CodeShark_> I think we're calling CheckBlockHeader twice - or one of those functions
 822015-09-30T09:28:23  <CodeShark_> I'd love to have a unit that just builds a block tree and maintains an index
 832015-09-30T09:29:35  <CodeShark_> and handles all block tree persistence
 842015-09-30T09:47:07  *** CodeShark_ has quit IRC
 852015-09-30T09:49:46  *** CodeShark has joined #bitcoin-core-dev
 862015-09-30T09:59:11  *** rusty has joined #bitcoin-core-dev
 872015-09-30T10:01:21  *** rusty has quit IRC
 882015-09-30T10:18:13  <sipa> wumpus, CodeShark l: i believe setting pprev is safe. the reason it wasn't done is historical, but i'll look in mkre detail later
 892015-09-30T10:26:53  *** rusty has joined #bitcoin-core-dev
 902015-09-30T10:33:40  <wumpus> sipa: great
 912015-09-30T10:38:46  *** paveljanik has joined #bitcoin-core-dev
 922015-09-30T10:47:06  *** rusty has left #bitcoin-core-dev
 932015-09-30T10:51:13  *** petertodd has joined #bitcoin-core-dev
 942015-09-30T11:26:29  *** kanzure has joined #bitcoin-core-dev
 952015-09-30T12:48:18  <GitHub21> [bitcoin] laanwj opened pull request #6741: doc: Change #bitcoin-dev IRC channel to #bitcoin-core-dev (master...2015_09_channel_split) https://github.com/bitcoin/bitcoin/pull/6741
 962015-09-30T12:49:17  *** fanquake has joined #bitcoin-core-dev
 972015-09-30T12:51:47  *** fkhan has joined #bitcoin-core-dev
 982015-09-30T12:53:34  *** morcos has joined #bitcoin-core-dev
 992015-09-30T12:57:18  <fanquake> Time to sit and watch the talent roll in
1002015-09-30T12:59:35  *** gavinandresen has joined #bitcoin-core-dev
1012015-09-30T13:16:36  *** sdaftuar has joined #bitcoin-core-dev
1022015-09-30T13:17:21  *** jgarzik has joined #bitcoin-core-dev
1032015-09-30T13:20:30  *** goregrind has joined #bitcoin-core-dev
1042015-09-30T13:32:06  *** dcousens has joined #bitcoin-core-dev
1052015-09-30T14:08:01  *** fanquake has quit IRC
1062015-09-30T14:09:43  *** fanquake has joined #bitcoin-core-dev
1072015-09-30T14:09:56  *** fanquake has joined #bitcoin-core-dev
1082015-09-30T14:10:31  *** fanquake has quit IRC
1092015-09-30T14:19:54  *** ParadoxSpiral has joined #bitcoin-core-dev
1102015-09-30T15:03:32  *** lecusemb1e has joined #bitcoin-core-dev
1112015-09-30T15:14:01  <GitHub156> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/1119cc3f5918575ca397518c9fd31a64704c7e4f
1122015-09-30T15:14:01  <GitHub156> bitcoin/master 1119cc3 Wladimir J. van der Laan: Merge pull request #6741...
1132015-09-30T15:14:11  <GitHub69> [bitcoin] laanwj closed pull request #6741: doc: Change #bitcoin-dev IRC channel to #bitcoin-core-dev (master...2015_09_channel_split) https://github.com/bitcoin/bitcoin/pull/6741
1142015-09-30T15:51:29  *** challisto has joined #bitcoin-core-dev
1152015-09-30T15:52:22  *** treehug88 has joined #bitcoin-core-dev
1162015-09-30T15:57:43  *** andytoshi has joined #bitcoin-core-dev
1172015-09-30T15:58:09  *** andytoshi has joined #bitcoin-core-dev
1182015-09-30T16:00:01  *** cfields has joined #bitcoin-core-dev
1192015-09-30T16:00:58  <GitHub166> [bitcoin] arnuschky opened pull request #6742: Changed logging to make -logtimestamps to work also for -printtoconsole (master...feature-logtimestamps-toconsole) https://github.com/bitcoin/bitcoin/pull/6742
1202015-09-30T16:18:29  *** harding has joined #bitcoin-core-dev
1212015-09-30T16:46:40  *** maaku has joined #bitcoin-core-dev
1222015-09-30T16:48:01  *** ProfMac has joined #bitcoin-core-dev
1232015-09-30T16:52:44  *** Arnavion has joined #bitcoin-core-dev
1242015-09-30T16:55:29  *** AtashiCon has joined #bitcoin-core-dev
1252015-09-30T16:56:04  *** helo has joined #bitcoin-core-dev
1262015-09-30T17:05:32  *** teward has joined #bitcoin-core-dev
1272015-09-30T17:09:24  *** rubensayshi has quit IRC
1282015-09-30T17:14:47  *** BlueMatt has joined #bitcoin-core-dev
1292015-09-30T17:30:41  *** fkhan has quit IRC
1302015-09-30T17:51:27  *** fkhan has joined #bitcoin-core-dev
1312015-09-30T17:57:20  *** dcousens has quit IRC
1322015-09-30T18:07:39  *** d_t has joined #bitcoin-core-dev
1332015-09-30T18:21:16  *** stonecoldpat has joined #bitcoin-core-dev
1342015-09-30T18:31:26  *** fkhan has quit IRC
1352015-09-30T18:32:36  *** ParadoxSpiral_ has joined #bitcoin-core-dev
1362015-09-30T18:35:19  *** ParadoxSpiral has quit IRC
1372015-09-30T18:45:09  *** fkhan has joined #bitcoin-core-dev
1382015-09-30T19:15:02  *** evoskuil has joined #bitcoin-core-dev
1392015-09-30T19:35:05  *** GAit has joined #bitcoin-core-dev
1402015-09-30T19:35:32  *** instagibbs has joined #bitcoin-core-dev
1412015-09-30T19:36:08  *** d_t has quit IRC
1422015-09-30T19:42:00  *** d_t has joined #bitcoin-core-dev
1432015-09-30T20:02:37  *** GAit has quit IRC
1442015-09-30T20:12:38  *** neha has joined #bitcoin-core-dev
1452015-09-30T20:17:30  *** rusty has joined #bitcoin-core-dev
1462015-09-30T20:19:25  <rusty> sipa: libsecp questions.  How do I check that the signature is in canonical form (small s value)?  You've made signature struct "opaque".
1472015-09-30T20:19:49  <rusty> Does verify do this?
1482015-09-30T20:20:04  <sipa> rusty: no, there is no functionality for doing that
1492015-09-30T20:20:25  <sipa> we should add it, though - i'm thinking about changing the signature parsing code anyway
1502015-09-30T20:20:42  <rusty> sipa: yeah... that's what I figured.  I hand around sigs in lightning as 64 byte raw vals, and I'm having to hack it.
1512015-09-30T20:21:09  <sipa> how do you convert them from/to 64 byte format?
1522015-09-30T20:21:14  <rusty> struct signature { 	u8 r[32];	u8 s[32]; };
1532015-09-30T20:21:29  <rusty> sipa: I stole the DER encode/decode from bitcoin.
1542015-09-30T20:21:35  <sipa> got it
1552015-09-30T20:22:07  <sipa> well, it would not be hard to add another parse/serialize function
1562015-09-30T20:22:18  <sipa> that converts to a well-defined 64-byte format
1572015-09-30T20:22:37  <rusty> sipa: yes, your comments even refer to it :)
1582015-09-30T20:22:38  <sipa> DER is a needless complication, both for client and library
1592015-09-30T20:22:58  <sipa> well there is such a format for the recoverable signatures
1602015-09-30T20:23:09  <rusty> "use the secp256k1_ecdsa_signature_serialize_* and  secp256k1_ecdsa_signature_serialize_* functions." :)
1612015-09-30T20:23:26  <sipa> rusty: someone sent a PR today to fix that
1622015-09-30T20:26:06  *** paveljanik has quit IRC
1632015-09-30T20:28:20  <gmaxwell> we already produce canonical form in all cases, it's just there is no way to verify it.
1642015-09-30T20:28:33  <gmaxwell> If _parse too verification flags, it could be asked to check for that trivally.
1652015-09-30T20:28:52  <rusty> sipa: secp256k1_ecdsa_signature_serialize()/_parse() then?  I'll have to dig into your slightly weird scalar system to implement it.
1662015-09-30T20:29:12  <gmaxwell> though perhaps it would better be done with a seperate sig_has_low_s().
1672015-09-30T20:29:19  <sipa> rusty: give me 5 mins, i'll implement it
1682015-09-30T20:29:39  <rusty> gmaxwell: yes, I have a couple of "assert(sig_valid(s))" scattered through my code.
1692015-09-30T20:30:05  <sipa> i don't like adding dozens of flags
1702015-09-30T20:30:06  <rusty> gmaxwell: (which is "return true;" for schnorr, and tests for top s bit for ecdh)
1712015-09-30T20:30:15  <sipa> in fact, i prefer none...
1722015-09-30T20:30:30  <rusty> gmaxwell: so in practice, a standalone check would fit me better.  I guess that's a data point?
1732015-09-30T20:30:38  <sipa> rusty: good. decided.
1742015-09-30T20:30:39  <gmaxwell> I sort of dread doing the testing if there are flags. :(  Also I think parsing for lows but sloppy DER doesn't make logical sense.
1752015-09-30T20:31:01  <sipa> i think i have a nearly-complete BER parser
1762015-09-30T20:31:20  <sipa> it's only twice as long as the current parse code
1772015-09-30T20:31:58  <gmaxwell> sipa: I am ... really not looking forward to writing tests for that. :( Also, how can it be BER, I assume it must length limit the outputs?
1782015-09-30T20:32:19  <sipa> gmaxwell: yes, up to a fixed limit
1792015-09-30T20:33:09  <gmaxwell> Also, there exist no other nearly complete BER parsers, so I dunno how I can do a differential test against it.
1802015-09-30T20:33:32  <rusty> sipa: I really want to be able to insist it's normalized.  Actually, I want that for everything.  If someone slips something in which causes me to build an invalid tx, I'm hosed.
1812015-09-30T20:33:32  <sipa> my design goal is: accept everything that is valid BER or accepted by openssl
1822015-09-30T20:33:49  <sipa> rusty: oh, absolutely... i don't want to encourage BER as default
1832015-09-30T20:34:03  <sipa> rusty: there needs to be a strict DER parser one (which is much easier)
1842015-09-30T20:34:19  <sipa> but for use in Bitcoin we can't just only have a strict DER one
1852015-09-30T20:34:51  <sipa> rusty: also, #secp256k1
1862015-09-30T21:04:55  *** treehug88 has quit IRC
1872015-09-30T21:11:05  *** ParadoxSpiral_ has quit IRC
1882015-09-30T21:36:11  *** amiller has joined #bitcoin-core-dev
1892015-09-30T21:56:08  *** pigeons has joined #bitcoin-core-dev
1902015-09-30T21:56:35  *** PRab has joined #bitcoin-core-dev
1912015-09-30T22:22:54  <michagogo> https://usercontent.irccloud-cdn.com/file/s0ybRJT5/IMG_2998.PNG
1922015-09-30T22:23:04  <michagogo> https://usercontent.irccloud-cdn.com/file/lhLarj9q/IMG_2999.PNG
1932015-09-30T22:23:56  <sipa> michagogo: it should definitely recompute things (either on the fly, or at startup and update)
1942015-09-30T22:24:10  <sipa> that's how the BIP34/66 implementation works as well
1952015-09-30T22:24:25  *** d_t has quit IRC
1962015-09-30T22:24:45  *** d_t has joined #bitcoin-core-dev
1972015-09-30T22:26:30  *** Squidicuz has joined #bitcoin-core-dev
1982015-09-30T22:34:58  <CodeShark> michagogo: I've been considering two approaches...either save state or recompute. I think it's inevitable we need to save some state at runtime (i.e. as part of the block index)...but we can recompute at startup
1992015-09-30T22:42:47  *** rusty has quit IRC
2002015-09-30T22:54:42  *** d_t has quit IRC
2012015-09-30T22:55:02  *** d_t has joined #bitcoin-core-dev
2022015-09-30T23:59:26  *** rusty has joined #bitcoin-core-dev