1 2015-07-23 00:01:05 <jtimon> moa: I'm just starting to non-superficially read the rpc/rest code anyway, so don't trust me too much
 2 2015-07-23 00:05:16 <jtimon> and one day I will even (hopefully) seriously look at p2p network code and all (pretty unreadable to me until something along the lines of #4646 is merged anyway...)
 3 2015-07-23 00:08:13 <jtimon> I'm that simple: the spaces at the beginning are the hardest part of any line for me to read, and those hyper-nested elifs just repeal me (not enough when it comes to script/interpreter)
 4 2015-07-23 00:08:33 <Luke-Jr> wumpus: I have rebased it; can you reopen https://github.com/bitcoin/bitcoin/pull/3229 so when I push it gets updated?
 5 2015-07-23 00:08:41 <jtimon> sorry, kind of off-topic
 6 2015-07-23 00:09:20 <jtimon> Luke-Jr: don't force push closed PRs, better to reopen for 1 sec
 7 2015-07-23 00:10:12 <Luke-Jr> jtimon: O.o?
 8 2015-07-23 00:12:16 <jtimon> @Luke-JrI mean, I fixed it once, but it's just something irrational about how github works
 9 2015-07-23 00:12:56 <Luke-Jr> jtimon: hence asking wumpus to reopen it first
10 2015-07-23 00:13:35 <jtimon> why open PRs can get force pushes but closed can't? it doesn't make any sense to me, even after reading an explanation
11 2015-07-23 00:14:16 <jtimon> (the explanation was basically "force push is not cool")
12 2015-07-23 00:16:45 <Luke-Jr> jtimon: archival value I imagine
13 2015-07-23 00:16:46 <jtimon> Luke-Jr: what I would do (and just have done with #6423 [please wumpus tell me if there's anything worng with it]) is reopen, push and reclose without asking wumpus
14 2015-07-23 00:16:54 <Luke-Jr> I don't think non-force pushes work either
15 2015-07-23 00:17:08 <Luke-Jr> wumpus: for reminder/convenience, that's 3229
16 2015-07-23 00:20:44 <jtimon> mhmm if non-force pushes don't work maybe it makes more sense I guess, but then reopening and reclosing seems the right thing to do if you want to update a PR that you want to keep closed
17 2015-07-23 00:35:56 <Luke-Jr> jtimon: I don't want to keep it closed.
18 2015-07-23 00:38:40 <jtimon> Luke-Jr: sorry, parse error s/it/subject welcomed
19 2015-07-23 00:40:23 <jtimon> Luke-Jr: sorry again, I actually had a context, then just reopen and force push? then, yes, it makes sense to ask wumpus, we're discussing nothing
20 2015-07-23 00:42:30 <jtimon> Luke-Jr: sorry, somehow I though you were referring to the comment I just made on https://github.com/bitcoin/bitcoin/pull/3229/files#r35280251
21 2015-07-23 08:09:39 <jonasschnelli> cfields: i was reading that you have started to work on a deterministic build without running in a vm? Right? I would be interested to build a ECDSA based signing of a asserts file.
22 2015-07-23 08:25:17 <wumpus> jonasschnelli: those are completely different things
23 2015-07-23 08:26:36 <wumpus> (I think both are valid, but I don't see how they overlap in the least)
24 2015-07-23 08:26:38 <jonasschnelli> wumpus: Yes. Indeed. But i just want to make sure to add a ECDSA signing at the right place. I could try to gain support for gverify (a alternative to gverify). But before that i'd like to know what steps/changes are planed for determ. building.
25 2015-07-23 08:26:58 <wumpus> well I'd it's a detached signature, just add another file?
26 2015-07-23 08:27:01 <jonasschnelli> s/gverify/gsign
27 2015-07-23 08:27:04 <wumpus> x.assert, x.asc, x.ecdsa ?
28 2015-07-23 08:27:35 <jonasschnelli> asserts.ecsig
29 2015-07-23 08:28:27 <wumpus> an external signing utility is most useful then
30 2015-07-23 08:28:57 <jonasschnelli> Yes. I'd like to write a simple c++ signing tools (and a tiny QT app to verify builds)
31 2015-07-23 08:29:29 <wumpus> no need to bind it to either bitcoin or gitian, the goal is just to have a tiny library to verify signatures instead of importing all of gpg
32 2015-07-23 08:29:57 <wumpus> (very probably, such a tool even already exists)
33 2015-07-23 08:31:12 <jonasschnelli> Right It should be generic. And not depending on keyservers. Maybe linking a binary with its correspnding git repository (where the signing pub keys are stored) to allow auto-verifying.
34 2015-07-23 10:33:00 <waxwing> what does this mean? error: {"code":-26,"message":"64: non-mandatory-script-verify-flag (No error)"}
35 2015-07-23 10:36:51 <waxwing> ok, i see, np
36 2015-07-23 11:32:42 <wumpus> the "no error" looks weird. We should probably leave the script verification status off if it's OK.
37 2015-07-23 11:38:42 <waxwing> wumpus: yes, microsoft style error message there ;) "Error!: No error."
38 2015-07-23 11:39:46 <jonasschnelli> wumpus: didn't we just add that PR?
39 2015-07-23 11:48:45 <jonasschnelli> Hmm... i think for this particular error we should s/non-mandatory-script-verify-flag (%s)/non-mandatory-script-verify-flag/
40 2015-07-23 12:49:54 <wumpus> right - it's an error handler so it should never add (No error), so don't append the verification error if it would show that
41 2015-07-23 12:50:45 <wumpus> Luke-Jr: can't reopen it
42 2015-07-23 12:51:03 <wumpus> Luke-Jr: "The minorops_check branch was force-pushed or recreated"
43 2015-07-23 12:58:14 <jonasschnelli> sipa: available?
44 2015-07-23 13:39:30 <Luke-Jr> wumpus: try now
45 2015-07-23 15:02:11 <rodarmor> In main.cpp:2598, the code that enforces the cap on the number of sigops per block seems to indicate that that it could be a result of corruption (last argument to state.DoS is true). How can this be the case? Is it related to merkle root malliability due to a duplicated transaction?
46 2015-07-23 15:13:01 <denisx> what is the number of sipas alternate version of gavins #5835?
47 2015-07-23 16:07:24 <Bootvis_> you mean #6077?
48 2015-07-23 16:18:14 <Luke-Jr> is there an automated way to run all the qa tests?
49 2015-07-23 16:28:02 <wumpus> qa/pulltester/rpc-tests.sh
50 2015-07-23 16:47:14 <gavinandresen> What's the fastest way to reset a fully-synced blockchain to a height a few thousand blocks back?  invalidateblock is taking a very long time for me...
51 2015-07-23 17:14:05 <fronti> if you have enough space, a crude idea: ./linearize-hashes.py linearize.cfg | head -n -20000 > hashlist.txt
52 2015-07-23 17:16:16 <denisx> Bootvis_: yes, thanks
53 2015-07-23 17:16:25 <denisx> ups, fc
54 2015-07-23 17:16:38 <denisx> no, it is the correct channel
55 2015-07-23 17:17:10 <denisx> fronti: what are you doing here, you confused me! ;)
56 2015-07-23 17:18:36 <wumpus> gavinandresen: there's no fast way to do that; it has to be undoed block by block to restore the utxo set to the old state. If you want to go back enough blocks, it may be faster to start reindexing from the beginning instead.
57 2015-07-23 17:20:30 <wumpus> (although then you need a way to stop reindexing at a certain block, probably needs a code change)
58 2015-07-23 17:51:15 <gavinandresen> wumpus: recompiling with the "add transactions from block back to memory pool" commented out makes invalidateblock fast enough for me (commenting here so next time I can google search for 'faster invalidateblock' I'll see what I did....)
59 2015-07-23 17:57:27 <wumpus> gavinandresen: good to know
60 2015-07-23 18:27:35 <cfields> jonasschnelli: for building without gitian, yea, a sig generator/checker would be great to have
61 2015-07-23 18:27:54 <cfields> i wouldn't make it a priority, though
62 2015-07-23 19:37:06 <jonasschnelli> cfields: Yeah. Agreed. It's just one of the minor fun projects i'd think about from time to time...
63 2015-07-23 20:13:58 <roasbeef> gavinandresen: unsure if it was part of your caricature on the ML but, LevelDB is in fact, designed for spinning disks, that's why the LSM-tree is there: to batch writes in a sequential manner
64 2015-07-23 20:16:01 <gavinandresen> roasbeef: good to know, I could've sworn I read it is optimized for SSDs somewhere....
65 2015-07-23 20:23:03 <jps> gavinandresen: might be thinking of http://rocksdb.org/
66 2015-07-23 20:23:48 <phantomcircuit> gavinandresen, huh? it's quite explicitly optimized for rotational media
67 2015-07-23 20:24:01 <phantomcircuit> basically everything they do would be silly on an ssd
68 2015-07-23 20:24:59 <fe0> hi
69 2015-07-23 20:25:24 <fe0> bitcoin core armory first download?
70 2015-07-23 20:26:26 <phantomcircuit> fe0, #bitcoin
71 2015-07-23 20:26:36 <fe0> k
72 2015-07-23 20:35:05 <roasbeef> jps: rocksdb is a fork of leveldb uses the same underlying data structures
73 2015-07-23 20:37:57 <jps> roasbeef: rocksdb is a fork of leveldb “…to efficiently use fast storage…”
74 2015-07-23 20:38:58 <phantomcircuit> jps, they'd have been better off starting from scratch for that
75 2015-07-23 20:39:19 <phantomcircuit> with ssds you do best to have a journal and a bunch of hashtables
76 2015-07-23 20:39:43 <phantomcircuit> this is offtopic though
77 2015-07-23 20:40:06 <jps> phantomcircuit, roasbeef - was responding to gavinandresen “I could've sworn I read it is optimized for SSDs somewhere”.
78 2015-07-23 20:41:12 <phantomcircuit> jps, yeha i know
79 2015-07-23 20:41:13 <phantomcircuit> still
80 2015-07-23 23:08:58 <morcos> sipa: ok i took my best shot, see 6470 when you get a chance...