1 2015-04-23 00:00:00 <jtimon> mhmm, I think of them mostly as places to maintain lists of dependencies
2 2015-04-23 00:00:34 <jtimon> but yeah I should have less of them
3 2015-04-23 00:01:01 <jtimon> one for all the consensus stuff opened should be enough
4 2015-04-23 00:01:38 <jtimon> one dependent one only to maintain the list of opened relevant independent PRs
5 2015-04-23 00:02:48 <cfields_> ok, thanks
6 2015-04-23 00:03:19 <jtimon> so I should close at least 3
7 2015-04-23 00:03:27 <jtimon> dependent ones
8 2015-04-23 00:06:49 <jtimon> I'm sorry, but as said #6050 would greatly facilitate things and it's moved only (and the constants have been acked)
9 2015-04-23 00:07:19 <Luke-Jr> gmaxwell: didn't complete header space recovery BIP because it seemed it was not the best direction; also did not publish it in any form because doing so was more complicated than it was worth
10 2015-04-23 00:08:24 <gmaxwell> meh, it was a fine boring change once all the details got worked out (like the factor of 4 correction, :P )
11 2015-04-23 00:10:03 <cfields_> jtimon: if it seem a bit grumpy, it's because i think everyone was ok with the constants movement, but now we're starting over with the declaration movement lumped in which is pretty ugly even as a temporary measure, imo
12 2015-04-23 00:12:34 <petertodd> gmaxwell, sipa: re: libsecp256k1, are we confident that at least for non-consensus applications libsecp256k1 is safe to use? (or at least, as safe as OpenSSL?)
13 2015-04-23 00:13:06 <jtimon> #5595 is still open, we can merge that first too, or anything I had opened and you think was ready, I'm only looking for more potential ways to get something that will facilitate later things soon
14 2015-04-23 00:13:15 <jtimon> there's many possibilities
15 2015-04-23 00:14:33 <jtimon> my latest conclusion is most of the moveonly first, but I'm happy reabasing on anything else that gets merged sooner
16 2015-04-23 00:15:46 <jtimon> seriously if you want me to reopen and/or rebase any PR I'm happy to do so
17 2015-04-23 00:16:27 <cfields_> jtimon: https://github.com/jtimon/bitcoin/commit/691161d419fe3d82d7a49b511ef80e2b24332aac by itself would likely be merged very quickly. but when that same change is included (plus some other stuff) in a handful of other PRs, it becomes impossible to tell what's ready
18 2015-04-23 00:16:57 <cfields_> so there's my suggestion, then :)
19 2015-04-23 00:20:49 <jtimon> sure, I'm happy to do that first, that was #5696 minus the policy stuff we discussed about should I reopen a rebased and nit-safe version of https://github.com/bitcoin/bitcoin/pull/5696 ?
20 2015-04-23 00:22:23 <jtimon> s/about should/about, should
21 2015-04-23 00:22:55 <cfields_> yea, that's the one i was thinking of earlier
22 2015-04-23 00:23:22 <cfields_> that'd be great
23 2015-04-23 00:24:52 <jtimon> great, will have some dinner and reopen that
24 2015-04-23 00:26:37 <cfields_> thanks. mind closing 6050 in favor of that, then? If you just do them rapid-fire, opening the next one as soon as one is merged, i bet they'll start to move in very quickly
25 2015-04-23 00:26:53 <cfields_> (assuming the high-level movement is sane, of course. seems to be)
26 2015-04-23 00:30:40 <jtimon> well, couldn't wait that much #5696 reopened
27 2015-04-23 00:32:15 <jtimon> and sure, can close 6050 until 5696 is merged
28 2015-04-23 00:35:43 <cfields_> dropping the policy stuff in 5696 though, right?
29 2015-04-23 00:42:52 <jtimon> oops, sorry, wrong branch with the nits unsolved
30 2015-04-23 00:43:18 <jtimon> oh, you mean only the consensus commit then?, I'm fine with that too
31 2015-04-23 00:44:14 <cfields_> yea
32 2015-04-23 00:44:54 <jtimon> fixed, PR renamed
33 2015-04-23 00:45:00 <cfields_> sipa/gmaxwell: what's the plan for libbitcoinconsensus api wrt libsecp256k1 contexts once we start using it for verification?
34 2015-04-23 00:45:02 <cfields_> jtimon: thanks
35 2015-04-23 00:48:31 <jtimon> thanks to you, please let's put consensus.h in the makefile soon
36 2015-04-23 00:50:42 <cfields_> heh, indeed. Food time, but I'll give it a quick once-over and re-ack later tonight
37 2015-04-23 01:00:53 <jtimon> cool
38 2015-04-23 01:04:02 <jtimon> btw do you have a problem with having function definitions in txverfiy.cpp and blockverify.cpp but all declarations in consensus.h ?
39 2015-04-23 01:05:05 <jtimon> that will serve us to be ready to expose whatever is ready first without using anything that is not needed yet in libconsensus
40 2015-04-23 01:06:11 <jtimon> I mean expose verifytx or verifyblockheader, the one that is ready later just waits for verifyblock
41 2015-04-23 01:08:50 <morcos> jtimon: sorry to jump in the middle here, but i've also been thinking about 5159 and how to make sure it doesn't get too out of control.. so i'm just going to take a few of your commits and squash them into a clean up commit at the end (as well as change my moveonly commit to be to your fees name)
42 2015-04-23 01:09:45 <morcos> then perhaps we can open another PR after 5159 gets merged to do the refactors and other code movement (txmempoolentry and allowfree). i like those ideas but just seems like i'm piling too much into a PR no one wants to review already
43 2015-04-23 01:11:10 <jtimon> sure morcos, I gave you the stuff in little commits so that you could chose what to get in
44 2015-04-23 01:11:44 <jtimon> simplifying AddUnchecked is cool but increases the diff quite a lot
45 2015-04-23 01:11:51 <morcos> yeah i got greedy, took it all and then felt bloated. :)
46 2015-04-23 01:12:08 <jtimon> so I completely undesrtand if you leave that out, for example
47 2015-04-23 01:12:42 <morcos> i will squash my existing commits before merge, so the hasnoinputs stuff only goes into the history once, but leave it for now, so gavin can pick up review from where he had it last
48 2015-04-23 01:13:38 <morcos> ok thx, bbiab
49 2015-04-23 01:14:16 <jtimon> sure, maintaining the id of your commit until reviewers ack the potential squash is a good practice
50 2015-04-23 01:14:59 <jtimon> if they dislike one of the little changes you just leave that one out
51 2015-04-23 01:16:25 <jtimon> but I think the ones I labelled with "SQUASHME" didn't increased the diff much and are easy to read individually, let's see
52 2015-04-23 04:46:29 <olalonde> Anyone knows what's going on in the second output of http://blockexplorer.com/testnet/tx/ad0a426817666f56d5b4fba97177f455bbfba3b80faca32a58ae9f947896ec68 ?
53 2015-04-23 04:52:03 <CodeShark> so much for the "raw transaction" page - it just displays "error" for the scriptPubKey - you need a better tool :p
54 2015-04-23 04:52:31 <CodeShark> this isn't the raw tx - this is a parsed tx put into json
55 2015-04-23 04:52:56 <CodeShark> blockexplorer should call this page "jsontx" or something :p
56 2015-04-23 04:55:31 <olalonde> Yep. Strangely, I got the same error in my parsing tool.
57 2015-04-23 06:48:27 <jonasschnelli> olalonde: https://www.biteasy.com/testnet/transactions/ad0a426817666f56d5b4fba97177f455bbfba3b80faca32a58ae9f947896ec68
58 2015-04-23 06:50:33 <jonasschnelli> olalonde: i think the 2nd output is non-standard but somehow got broadcaseted and mined?
59 2015-04-23 06:52:06 <sipa> testnet does not have standardness
60 2015-04-23 06:52:26 <jonasschnelli> okay. Than that's why.
61 2015-04-23 07:32:59 <olalonde> are there rules for validating output scripts in mined blocks or does anything go?
62 2015-04-23 07:33:42 <sipa> wrt consensus rules, only the sigop operations matter
63 2015-04-23 07:34:54 <sipa> there is a limit of 20000 sigops per block
64 2015-04-23 07:35:16 <sipa> checksig and related operations in output scripts count towards this limit (as well as checksig in p2sh spends)
65 2015-04-23 07:38:48 <olalonde> Ok, let me know if I got this right
66 2015-04-23 07:40:41 <olalonde> There's no validation done on the output script itself except calculating how many sigops it contains and checking that the total sigops for the block is not over the 20000 limit.
67 2015-04-23 07:41:36 <sipa> correct
68 2015-04-23 07:41:55 <sipa> so technically, the contents of a transaction output may matter, if the block is otherwise close to the sigop limit
69 2015-04-23 07:42:50 <kadoban> Can output scripts contain reserved opcodes and such? I didn't think they could.
70 2015-04-23 07:43:08 <sipa> kadoban: define reserved
71 2015-04-23 07:43:36 <sipa> and define "can". are you talking about standard relay/mining rules as implemented in bitcoin core, or are you talking about the consensus rules?
72 2015-04-23 07:43:57 <olalonde> https://en.bitcoin.it/wiki/Script#Reserved_words guess he is referring to this
73 2015-04-23 07:44:26 <kadoban> OP_RESERVED, OP_VER, all of the unassigned ones. By "can" I meant ⦠wouldn't a block containing transactions with output scripts that contain reserved opcodes be an invalid block?
74 2015-04-23 07:44:31 <olalonde> If I understand correctly, the relay/mining rules are much scricter than consensus rules but reserved OP codes should be valid in mined blocks.
75 2015-04-23 07:44:51 <kadoban> Oh, I think I misunderstood the context of the conversation possibly.
76 2015-04-23 07:45:02 <sipa> kadoban: first, are you tallking about relay policy, or about consensus rules?
77 2015-04-23 07:45:30 <sipa> (the first is something that each client can do differently, the second can cause forks if not every client implements them exactly identically)
78 2015-04-23 07:46:21 <olalonde> Oh, seems I'm wrong. Wiki says "Transaction is invalid unless occuring in an unexecuted OP_IF branch"
79 2015-04-23 07:46:24 <sipa> if you're talking about blocks, i assume you mean consensus rules
80 2015-04-23 07:46:34 <kadoban> Hmm, I'm not sure which I'm talking about. I thought it would be invalid for both. Yes, I'm talking about blocks.
81 2015-04-23 07:46:42 <sipa> for the consensus rules, transaction scripts are only evaluated when they are spent
82 2015-04-23 07:46:57 <sipa> transaction outputs are just byte arrays
83 2015-04-23 07:47:04 <sipa> they don't even need to be parseable
84 2015-04-23 07:47:10 <kadoban> Oh, huh. That's not how I thought it worked. Interesting.
85 2015-04-23 07:47:14 <olalonde> Oh ok makes sense.
86 2015-04-23 07:47:17 <kadoban> Thanks :)
87 2015-04-23 07:47:19 <sipa> (apart from the sigop limit)
88 2015-04-23 07:47:25 <olalonde> I also learned this today :)
89 2015-04-23 07:47:58 <sipa> for standardness (which is used in relay, mempool, and mining policies), they are parsed, and there are various restriction on them
90 2015-04-23 07:48:17 <olalonde> Right.
91 2015-04-23 07:48:32 <sipa> as od 0.10, you would be able to use OP_RESERVED inside a P2SH script
92 2015-04-23 07:48:41 <sipa> but obviously won't be able to spend it, as it makes the script evaluate to false
93 2015-04-23 07:48:49 <kadoban> sipa: By mining policies, you mean what transactions miners will include in blocks, in the default implementation?
94 2015-04-23 07:48:58 <sipa> kadoban: indeed
95 2015-04-23 07:49:05 <kadoban> Okay, cool. I think I understand then.
96 2015-04-23 07:49:07 <sipa> i call it policy, because there is no harm from individual miners changing this
97 2015-04-23 07:50:54 <kadoban> It seems kinda weird that you could make a block with a bunch of transactions that are completely impossible to spend from, but later on might be, depending on which opcodes ever get implemented (if any). Heh. But I suppose there's no real harm in that, it'd just be waste of time and money and ⦠space in the blockchain.
98 2015-04-23 07:51:52 <sipa> kadoban: you misunderstand, we cannot ever make an opcode that is invalid now become valid later
99 2015-04-23 07:52:02 <sipa> kadoban: unless we do a hardfork
100 2015-04-23 07:52:17 <sipa> (which means anything could happen - in a hardfork we can make the client a frontend for paypal)
101 2015-04-23 07:52:52 <jeremyrubin> sipa: does it make it eval to false or make in invalid?
102 2015-04-23 07:52:59 <kadoban> Ah, hmm. Right, that's true.
103 2015-04-23 07:53:03 <sipa> jeremyrubin: what is the difference?
104 2015-04-23 07:53:26 <jeremyrubin> ie, x = 1|| x == 2 evals to false, but is valid?
105 2015-04-23 07:53:42 <sipa> you have a weird definition of "valid"
106 2015-04-23 07:54:22 <jeremyrubin> well... for example if ... fi is valid whereas if ... is invalid, correct?
107 2015-04-23 07:54:44 <sipa> jeremyrubin: there are various reasons why a script evaluation can fail
108 2015-04-23 07:54:51 <sipa> buts its outcome is a boolean
109 2015-04-23 07:54:55 <sipa> it is true or false
110 2015-04-23 07:55:17 <sipa> reasons for it resulting in false do include parse errors, stack manipulation errors, unbalanced if/then/elses
111 2015-04-23 07:55:20 <sipa> ...
112 2015-04-23 07:55:54 <jeremyrubin> I'm pretty sure there is a difference
113 2015-04-23 07:56:02 <olalonde> But they are not evaluated until referenced by an input right? (except to check for sigops)
114 2015-04-23 07:56:13 <sipa> olalonde: correct
115 2015-04-23 07:56:22 <sipa> jeremyrubin: a difference for what?
116 2015-04-23 07:56:35 <sipa> jeremyrubin: you may be right, but i'm not sure what you mean :)
117 2015-04-23 07:56:41 <sipa> if you're more specific i can clarify
118 2015-04-23 07:56:47 <jeremyrubin> can I include a txn with: (x == 1 && x ==2)?
119 2015-04-23 07:57:03 <jeremyrubin> It's valid (equiv to an op_return)
120 2015-04-23 07:57:11 <sipa> jeremyrubin: bitcoin scripts don't have brackets, or x'es
121 2015-04-23 07:57:23 <sipa> (sorry, but the syntactic details matter here)
122 2015-04-23 07:57:39 <jeremyrubin> (didn't think they did for this.. will write in forth)
123 2015-04-23 07:58:09 <sipa> no, write in bitcoin script (which is similar to forth, but far from the same)
124 2015-04-23 07:58:59 <olalonde> jeremyrubin: If I understand correctly, when a block is validated, there is no validation done on the output scripts (except counting sigops), so anything goes. However, if there is a "syntax" or "logic" error in the output script, no input script will ever be able to spend those outputs.
125 2015-04-23 07:59:11 <sipa> olalonde: indeed
126 2015-04-23 07:59:34 <sipa> jeremyrubin: script evaluation takes as input a spending scriptSig AND the scriptPubKey of the output being spent
127 2015-04-23 07:59:44 <sipa> jeremyrubin: and the result in a boolean
128 2015-04-23 07:59:53 <jeremyrubin> op_dup <1> op_eq op_swap <2> op_and
129 2015-04-23 08:00:13 <sipa> jeremyrubin: with which input?
130 2015-04-23 08:00:21 <sipa> if the input is <1> or <2>, the result is TRUE
131 2015-04-23 08:00:25 <sipa> if not, the result is FALSE
132 2015-04-23 08:00:35 <jeremyrubin> no it's an op_and
133 2015-04-23 08:00:40 <jeremyrubin> unless I miswrtoe the logic
134 2015-04-23 08:00:43 <sipa> ah, sorry
135 2015-04-23 08:00:48 <sipa> then the result will be always FALSE
136 2015-04-23 08:00:51 <jeremyrubin> yes
137 2015-04-23 08:00:58 <jeremyrubin> but it could be included in a block, yes
138 2015-04-23 08:01:05 <sipa> yes
139 2015-04-23 08:01:14 <jeremyrubin> (olalonde has what I'm saying correctly I think)
140 2015-04-23 08:01:15 <sipa> every script can be included in a block
141 2015-04-23 08:01:18 <sipa> even unparseable ones
142 2015-04-23 08:01:52 <sipa> scripts only constrain how outputs can be spent
143 2015-04-23 08:01:55 <sipa> not how they can be created
144 2015-04-23 08:01:57 <jeremyrubin> really? even: op_if op_true
145 2015-04-23 08:02:02 <sipa> yes
146 2015-04-23 08:02:13 <jeremyrubin> (as opposed to op_if op_true op_endif
147 2015-04-23 08:02:19 <sipa> even push_100_bytes <50 bytes follow>
148 2015-04-23 08:02:26 <sipa> perfectly "valid" script
149 2015-04-23 08:02:43 <sipa> it's only evaluated when you try to spend it
150 2015-04-23 08:03:55 <jeremyrubin> hmm ok; I was mistaken on that.
151 2015-04-23 08:04:47 <sipa> (he only exception being the sigop limit, which is weird, because it even applies if the script cannot be possible parsed)
152 2015-04-23 08:05:44 <jeremyrubin> Also what about the "disabled" ops?
153 2015-04-23 08:05:57 <sipa> they cause the script evluation to fail, when executed
154 2015-04-23 08:06:01 <sipa> nothing more
155 2015-04-23 08:06:03 <jeremyrubin> gotcha
156 2015-04-23 08:06:22 <sipa> you could have a script output of the form OP_CHECKSIG OP_IF
157 2015-04-23 08:06:33 <sipa> which cannot possibly ever succeed, due to unbalanced if
158 2015-04-23 08:06:38 <sipa> but it still counts as 1 sigop
159 2015-04-23 08:06:45 <jeremyrubin> (I should read the source for it, was going based on the bitcoin.it/wiki/Script
160 2015-04-23 08:06:46 <sipa> and thus may be invalid to put in a block
161 2015-04-23 08:07:07 <sipa> the first rule of #bitcoin-dev is: do not assume the wiki is right :)
162 2015-04-23 08:07:15 <kadoban> I guess it was done like that just to make it /really/ easy to check the sigop limit condition? Does seem pretty odd though :)
163 2015-04-23 08:07:45 <sipa> kadoban: well, someone (presumably satoshi) implemented a sigop limit in a particular way
164 2015-04-23 08:07:56 <sipa> whatever the implementation did, implicitly became a consensus ruke
165 2015-04-23 08:08:00 <jeremyrubin> Also; re: hardforking by changing opcode, would be cool to maybe use proof of stake on hardforks
166 2015-04-23 08:08:01 <sipa> this is not intentional
167 2015-04-23 08:08:07 <sipa> jeremyrubin: oh please
168 2015-04-23 08:08:09 <kadoban> Ah, right
169 2015-04-23 08:08:17 <olalonde> Was the sigop limit in the original client? I was under the impression it was added later.
170 2015-04-23 08:08:19 <jeremyrubin> Hear me out :P
171 2015-04-23 08:08:34 <sipa> sorry, not here :)
172 2015-04-23 08:08:47 <sipa> not ever going to happen in bitcoin, whether it's a good idea or not
173 2015-04-23 08:10:08 <jeremyrubin> ah I forgot I'm in #bitcoin-devs ;)
174 2015-04-23 08:10:23 <sipa> olalonde: added in 0.3.12, it seems
175 2015-04-23 08:10:32 <sipa> sep 2010
176 2015-04-23 08:10:34 <jeremyrubin> banter; not a serious suggest
177 2015-04-23 08:12:35 <sipa> ;;diff
178 2015-04-23 08:12:36 <gribble> 4.761056451347126E10
179 2015-04-23 08:13:25 <jeremyrubin> sipa: thanks for making me rewrite in script btw, rereading I realized my ( x =1 || x==2) was majorly confusing... brain damage from some coq code notation where || was a program/state separator.
180 2015-04-23 08:15:40 <sipa> hehe
181 2015-04-23 08:15:40 <sipa> yw
182 2015-04-23 08:56:27 <priidu> can anyone point me to an example of an "alertnotify" message?
183 2015-04-23 08:56:47 <priidu> just kind of curious
184 2015-04-23 08:57:36 <priidu> I imagine it should avoid any kind of special characters (e.g. quotes etc) at all costs
185 2015-04-23 08:57:52 <sipa> special charatcers are stipped
186 2015-04-23 08:59:01 <priidu> since many of the "-alertnotify="echo %s... commands would otherwise break, wouldn't they?
187 2015-04-23 08:59:04 <priidu> hmm, ok
188 2015-04-23 09:37:17 <jonasschnelli> am i right that scrypt should be preferred (over SHA512) as KDF when derive a key from a phrase?
189 2015-04-23 09:39:07 <sipa> there was recently an online competition to create a key derivation scheme
190 2015-04-23 09:39:14 <sipa> was or is, unsure
191 2015-04-23 09:42:08 <sipa> i still like https://bitcointalk.org/index.php?topic=102349.0 though (it can be adapted to use scryypt)
192 2015-04-23 09:42:13 <sipa> :p
193 2015-04-23 09:42:44 <sipa> there is already BIP39 (which i think is silly), and electrum has its own scheme too now
194 2015-04-23 09:44:25 <sipa> fragmentation is unfortunate, here
195 2015-04-23 09:47:34 <jonasschnelli> Bip39 is truly questionable. But how would one creates a offline paper backup of his Bip32 master seed? Printing (no, seed goes through to many chips, wires) writing down hex (high chance of typos), nmemonic at least has a kind of failure-tolerance. But keeping the wallet in mind?! Not really.
196 2015-04-23 09:48:07 <jonasschnelli> s/keeping the wallet in mind/keeping the seed nmemonic in mind/
197 2015-04-23 09:48:41 <sipa> if you don't plan to print or remember, you shouldn't be using such a scheme at all and just randomly generate the keys
198 2015-04-23 09:48:46 <sipa> the point is to make them reproducible
199 2015-04-23 09:48:53 <sipa> which definitely has security tradeofss
200 2015-04-23 09:49:17 <sipa> and i would absolutely advise against remembering keys (this results in either keys which are very weak and remberable, or strong and forgotten)
201 2015-04-23 09:52:05 <jonasschnelli> sipa: but after creating a new master seed. How do you would recommend to make "a backup of it"? Printing? I would prefer a way where i can write down by hand with a possible failure tolerance.
202 2015-04-23 09:52:58 <sipa> writing down is probably the best possible tradeoff between security and risk of loss
203 2015-04-23 09:53:03 <sipa> not sure
204 2015-04-23 09:53:48 <sipa> maybe it needs a password still too...
205 2015-04-23 09:54:00 <sdaftuar> have you seen what armory does for printing?
206 2015-04-23 09:54:10 <sipa> mm, no
207 2015-04-23 09:54:14 <sdaftuar> one more password that encrypts the document if you don't trust your printer
208 2015-04-23 09:54:24 <sdaftuar> and they display it on the screen, so you can write it down on the document after it's printed
209 2015-04-23 09:54:27 <sdaftuar> for your records
210 2015-04-23 09:54:37 <sipa> sdaftuar: thanks for all the work rebasing autoprune so far, i really hope to merge it soon
211 2015-04-23 09:54:45 <sipa> sdaftuar: nice
212 2015-04-23 09:54:58 <sdaftuar> sure! me too :)
213 2015-04-23 09:56:36 <jonasschnelli> sdaftuar: yes. Nice work with autoprune! Do you have plans to continue the work to support the current wallet implementation in pruned mode?
214 2015-04-23 09:57:49 <sdaftuar> thanks, to be honest i know very little about the wallet interactions with the node...
215 2015-04-23 09:58:11 <sdaftuar> i guess there are two more things to be done after this pull
216 2015-04-23 09:58:27 <sdaftuar> one is the wallet support, the other is figuring out how pruning nodes can still participate in (limited) relaying
217 2015-04-23 09:59:04 <sdaftuar> i guess the wallet is probably the more important of those two, assuming there are no fundamentally hard problems there
218 2015-04-23 09:59:39 <sipa> they can relay perfectly fine
219 2015-04-23 09:59:48 <sipa> just not serve historical blocks
220 2015-04-23 10:00:12 <sdaftuar> that distinction seems like the thing to figure out though? do we have a p2p message for "block not found"?
221 2015-04-23 10:00:37 <sipa> yes, but i think that is irrelevant
222 2015-04-23 10:00:59 <sipa> if a node requests a block you don't have, we have already wasted connections
223 2015-04-23 10:01:05 <sdaftuar> ah rigt
224 2015-04-23 10:01:47 <sdaftuar> do you have an implementation in mind for how to communicate that a node isn't serving historical blocks?
225 2015-04-23 10:02:03 <jonasschnelli> p2p version infos height?
226 2015-04-23 10:02:16 <sdaftuar> (but is relaying)
227 2015-04-23 10:02:33 <sipa> sdaftuar: there has been a proposal of mine for ages, but it's very limited and there is a lot of controversy
228 2015-04-23 10:02:51 <sipa> mine uses 2 service bits
229 2015-04-23 10:05:44 <sdaftuar> do you have a link by any chance i could read?
230 2015-04-23 10:06:53 <sipa> idea was to just have 4 levels (i have everything, i have a lot, i have little, i have nothing)
231 2015-04-23 10:07:22 <sipa> where a lot and little could mean 2016 resp 288 blocks, for example
232 2015-04-23 10:12:03 <sdaftuar> what's the nature of the controversy?
233 2015-04-23 10:12:14 <sipa> not specific enough
234 2015-04-23 10:12:21 <sdaftuar> ok
235 2015-04-23 10:12:32 <sipa> you can't use it for sharding
236 2015-04-23 11:15:09 <jonasschnelli> hmm.. just figured out that the bip32_test.cpp is not included in the Makefile.test.include
237 2015-04-23 11:15:10 <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.test.include
238 2015-04-23 11:15:34 <sipa> heh
239 2015-04-23 11:15:42 <sipa> i think i realized that months ago
240 2015-04-23 11:15:43 <jonasschnelli> not by purpose i assume?
241 2015-04-23 11:15:54 <sipa> i thought i fixed it.
242 2015-04-23 11:16:26 <jonasschnelli> do you? should is?
243 2015-04-23 11:16:30 <jonasschnelli> *should i
244 2015-04-23 11:16:36 <sipa> go ahead
245 2015-04-23 11:30:15 <wumpus> ACTION is testing autoprune
246 2015-04-23 11:30:49 <wumpus> jonasschnelli: hah, all the good those tests do if they're not even compiled by default
247 2015-04-23 11:31:53 <jonasschnelli> Right. After adding some code in bip32_tests.cpp i was wondering why it never fails. :)
248 2015-04-23 14:37:40 <jtimon> coryfields_ I updated and reopened #6051, mostly for discussion on my short term plans for libconsensus
249 2015-04-23 17:40:12 <michagogo> 01:10:17 <@gmaxwell> "the git repo" there isn't a the git repo. Alert key is basically depricated, and largely useless; we just haven't mustered the will to remove it yet, the key is effectively compromised in any case. I think it's likely that we'll remove it before ever using it again. <-- "effectively"?
250 2015-04-23 17:56:56 <phantomcircuit> michagogo, people who probably should not have it at this time have the key
251 2015-04-23 17:57:06 <phantomcircuit> not people who *clearly* should not have it
252 2015-04-23 17:57:10 <phantomcircuit> but probably should not have it
253 2015-04-23 18:02:45 <michagogo> Ah
254 2015-04-23 18:48:43 <chron0> ahoy, any armory devs/ops here?
255 2015-04-23 19:50:43 <chris___> hello guys
256 2015-04-23 20:30:43 <jonasschnelli> Right. After adding some code in bip32_tests.cpp i was wondering why it never fails. :)
257 2015-04-23 20:31:06 <jonasschnelli> sorry... was a old history entry!
258 2015-04-23 20:31:24 <jonasschnelli> wrong window
259 2015-04-23 21:08:26 <cfields_> jonasschnelli: haha, nice find on that though
260 2015-04-23 21:08:36 <cfields_> i've done the same thing before, never figured out why
261 2015-04-23 21:09:26 <cfields_> i was _sure_ that by messing around I would've broken the bip32 code, but it never failed. Now I know why :)
262 2015-04-23 21:09:28 <cfields_> sipa: ping
263 2015-04-23 21:10:58 <cfields_> sipa: wrt #6047, we're going to have to handle libsecp256k1 contexts in libbitcoinconsensus eventually. Have you thought about how that might look?
264 2015-04-23 22:03:58 <lmatteis> what protocol does bitcoin use to propagate messages across the network, and how are peers discovered?
265 2015-04-23 22:17:52 <harding> lmatteis: https://bitcoin.org/en/developer-reference#p2p-network for protocol and https://bitcoin.org/en/developer-guide#peer-discovery for peer discovery.
266 2015-04-23 23:34:34 <riezai> is there a reason for why commits have dropped since Jan? https://github.com/bitcoin/bitcoin/graphs/commit-activity
267 2015-04-23 23:38:38 <phantomcircuit> riezai, there's less stuff that obviously needs to be fixed?
268 2015-04-23 23:38:43 <phantomcircuit> sipa is tired?
269 2015-04-23 23:38:46 <phantomcircuit> hard to tell
270 2015-04-23 23:39:07 <CodeShark> sipa's obviously up to something ;)
271 2015-04-23 23:40:26 <gmaxwell> riezai: commit counts are a pretty useless metric, most of the volume by commits are moving code around.
272 2015-04-23 23:41:08 <gmaxwell> Things also tend to cycle between building up PRs (which generates no 'commits' by that count) and merging them prior to release.
273 2015-04-23 23:41:42 <CodeShark> it's also that we're short on code review ;)
274 2015-04-23 23:41:45 <CodeShark> the other side of that equation
275 2015-04-23 23:42:40 <CodeShark> there are currently 118 outstanding PRs
276 2015-04-23 23:43:06 <CodeShark> outstanding as in not yet completed - not as in they're amazing...although some might be ;)
277 2015-04-23 23:43:11 <gmaxwell> Sure, thats not 'short on code review' in all cases, it's a pipeline.
278 2015-04-23 23:43:32 <gmaxwell> there are only a couple which are clearly mergeable but for review.
279 2015-04-23 23:43:56 <gmaxwell> (well, a couple outside of the very recently opened ones)
280 2015-04-23 23:45:35 <CodeShark> what would be a better metric of progress than commit count or lines of code changed (neither of which is particularly good)?
281 2015-04-23 23:46:27 <moa> awesomeness
282 2015-04-23 23:46:34 <ZjP> I find astrology works well
283 2015-04-23 23:47:01 <CodeShark> I guess rather than just counting lines removed and lines added the merge tools could provide more sophisticated detection of things like copy/pastes or symbol substitutions
284 2015-04-23 23:47:56 <CodeShark> I'd especially like the latter - it's a feature that is hard to do well in git
285 2015-04-23 23:48:19 <CodeShark> oftentimes you don't really want to commit changes to lines of code - you want to commit a global regex substitution, i.e.
286 2015-04-23 23:48:29 <moa> CodeShark: point being if you knew that metric then these pay-the-devs-per-awesomeness ideas could actually fly
287 2015-04-23 23:48:59 <CodeShark> sounds good - how do we measure awesomeness?
288 2015-04-23 23:49:10 <moa> but it's like Turing's test for intelligence, you'll knwo it when you see it
289 2015-04-23 23:50:16 <ZjP> So, a qualified examiner asks two commits any questions it wants, and whichever one convinces the examiners its awesome wins?
290 2015-04-23 23:52:40 <gmaxwell> As far as other things going on; there has been a lot of time sunk into QA for 0.10 which we've still not recovered from (we're still spending time on 0.10 QA)
291 2015-04-23 23:59:59 <CodeShark> I'm having a blast finally getting to play around with the satoshi script