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