1 2014-09-23 02:26:20 <dabura667> Anyone know if any of the javascript libraries for bitcoin can handle basic calculations between bases in bigint?
  2 2014-09-23 02:26:47 <dabura667> I am looking for something like parseInt() but where the integer that comes out is a bigint
  3 2014-09-23 02:32:15 <SomeoneWeird> dabura667: there are bignum implementations in js
  4 2014-09-23 02:32:38 <SomeoneWeird> wait that might not be what you're asking
  5 2014-09-23 02:32:40 <SomeoneWeird> 
ACTION shrugs

  6 2014-09-23 02:44:39 <phantomcircuit> dabura667, whatever you're thinking of doing, i would suggest asking very specifically for advise on how to do it
  7 2014-09-23 02:44:53 <phantomcircuit> more than likely the answer will be that whatever it is, is not safe
  8 2014-09-23 02:48:08 <dabura667> converting base 6 dice rolls into hex
  9 2014-09-23 02:48:57 <dabura667> phantomcircuit: similar to what you can do in bitaddress
 10 2014-09-23 02:49:48 <dabura667> I kind of answered my own question there... *runs off to check bitaddress source*
 11 2014-09-23 02:52:02 <phantomcircuit> dabura667, as in literally someone rolling dice?
 12 2014-09-23 02:52:46 <gmaxwell> 
ACTION places a bet on 'throws out your dice information and uses math.random()'

 13 2014-09-23 02:53:20 <sipa> 
ACTION invokes xkcd 221

 14 2014-09-23 02:53:25 <dabura667> gmaxwell: great solution. thanks everybody *walks away*
 15 2014-09-23 02:53:39 <dabura667> j/k
 16 2014-09-23 02:53:49 <dabura667> literally someone throwing dice.
 17 2014-09-23 02:54:18 <gmaxwell> dabura667: it's quite difficult to get a uniform random number over some range. The safest thing to do is just to capture an interger on a unform range strictly larger and then throw out if your value is too big.
 18 2014-09-23 02:54:51 <phantomcircuit> gmaxwell, he's trying to generate private keys with dice rolls
 19 2014-09-23 02:55:02 <phantomcircuit> dabura667, amirite
 20 2014-09-23 02:55:56 <dabura667> pretty much. Except BIP39 phrases, but yeah.
 21 2014-09-23 02:57:27 <dabura667> gmaxwell: I am searching for sweet spots, 6^53 is very close to a multiple of 2^128, so I am thinking 53 times exactly for a 12 word seed.
 22 2014-09-23 02:59:36 <dabura667> or I could just go eat pizza and make the function just be return 4;
 23 2014-09-23 02:59:58 <dabura667> choices...
 24 2014-09-23 03:02:01 <gmaxwell> 53?! you'll almost always have to reroll in that. Perhaps you meant 50? That has a failure probability of about 57%
 25 2014-09-23 03:05:04 <sipa> you can roll 53 times, and then divide the result by 512
 26 2014-09-23 03:06:06 <gmaxwell> Yea, 53 into 137 bits is a .2% failure rate.
 27 2014-09-23 03:07:27 <gmaxwell> still kinda high. You could just go compute the expected number of dice rolls for each n over 128, perhaps some other one is better.
 28 2014-09-23 03:21:13 <dabura667> I am missing some mathematical theorem that is common knowledge amongst you all.
 29 2014-09-23 03:21:13 <dabura667> sorry for my ignorance. why is 53 bad? the number space provided by 6^53 / 2^128 = 513.07024... meaning if I mod by 2^128, the resulting number of 6^53 will only overlap the lower 7% of the number space. Plus taking into count that it's passing over the whole space 513 times, that would lower the probability of getting those lower 7% significantly... unless
 30 2014-09-23 03:23:44 <dabura667> btw 6^50 / 2^128 is 2.3753... so the lower 38% of the number space is highly weighted and much more likely to appear when modded by 2^128
 31 2014-09-23 03:25:18 <dabura667> again... if there's some sort of theory that is behind choosing the proper number of dice rolls for a given number space I would love to learn... (actually, I would appreciate it greatly)
 32 2014-09-23 03:25:42 <gmaxwell> dabura667: you discard if the number is too big to achieve perfect uniformity.
 33 2014-09-23 03:26:59 <dabura667> gmaxwell: ok, that makes sense. What were you talking about with failure rate?
 34 2014-09-23 03:27:22 <gmaxwell> How likely you are to need to discard.
 35 2014-09-23 03:27:41 <dabura667> oh I see
 36 2014-09-23 03:28:13 <dabura667> ok that makes sense.
 37 2014-09-23 03:28:27 <gmaxwell> often you can make the failure rate very low, and then its fine. Looks like for 6,2 and targets around 128 there aren't any super awesome options.
 38 2014-09-23 03:28:45 <dabura667> 49 rolls is way less than 2^128...
 39 2014-09-23 03:29:09 <dabura667> and 50 rolls is 2.4 times as large, so there's a large chance of needing to discard
 40 2014-09-23 03:29:18 <gmaxwell> Thats what I said.
 41 2014-09-23 03:29:46 <gmaxwell> 53 works out okay— you shift off 9 bits and then have a 0.2% discard chance.
 42 2014-09-23 03:32:30 <dabura667> ok
 43 2014-09-23 03:42:15 <dabura667> it looks like Bitcoinjs has a Biginteger class that accepts base as an arg. I'll require 53 rolls for 128 bits and it looks like 106 rolls for 256 bits sounds good. if I shift off 18 bits I get 0.4% discard chance.
 44 2014-09-23 03:47:08 <gmaxwell> you don't need a base anything as an arg. Just multiply and add.
 45 2014-09-23 04:06:17 <dabura667> gmaxwell: the base as an arg this was to convert the user's 0-5 string into a Bigint object
 46 2014-09-23 04:06:35 <dabura667> which seems to be a byte array
 47 2014-09-23 04:09:16 <gmaxwell> dabura667: you can just run a loop multiplying by 6 and adding the next digit.
 48 2014-09-23 04:10:15 <gmaxwell> (which, if you read most significant first like that, I suppose that lets you terminate early if the number is going to be too big)
 49 2014-09-23 04:10:32 <dabura667> gmaxwell: javascript caps out at 32 bit though...
 50 2014-09-23 04:12:43 <gmaxwell> just pointing out that you don't need any base-foo support beyond getting back a byte sequence.
 51 2014-09-23 04:12:55 <dabura667> well yeah, true.
 52 2014-09-23 04:13:05 <dabura667> if this were python I'd just use a for loop
 53 2014-09-23 05:55:21 <chaosagent> hi
 54 2014-09-23 05:55:25 <chaosagent> anyone here?
 55 2014-09-23 05:58:14 <b-itcoinssg> yes
 56 2014-09-23 06:00:11 <sipa> no
 57 2014-09-23 06:00:54 <NikolaiToryzin> I can confirm no one is here.
 58 2014-09-23 06:01:47 <b-itcoinssg> maybe he's waiting for 6 confirmations
 59 2014-09-23 06:19:21 <dabura667> Yes (confirmation 2)
 60 2014-09-23 06:21:10 <dabura667> gmaxwell: I was wondering what the difference of cutting off bits and modding by a power of 2... My understanding is that ie. If you mod by 256 you are bitwise ANDing 0xff
 61 2014-09-23 06:21:34 <dabura667> Or are those not the same somehow...
 62 2014-09-23 06:38:11 <gwillen> dabura667: that should be the same, yes
 63 2014-09-23 06:39:06 <gmaxwell> Take care. Mod your target size does _nothing_ if the number is small enough, and if it's too big you'll end up non-uniform.
 64 2014-09-23 06:39:40 <dabura667> gmaxwell: You were talking about shifting off bits.
 65 2014-09-23 06:39:51 <dabura667> you mean right shift, right?
 66 2014-09-23 06:40:00 <gmaxwell> You must first have an input a power of two in size first to avoid non-uniformity. The mod will just then be needlessly slow (compared to masking or a shift), but harmless.
 67 2014-09-23 06:40:55 <gmaxwell> dabura667: yes.
 68 2014-09-23 06:42:12 <dabura667> ok
 69 2014-09-23 06:42:44 <Luke-Jr> usually, compilers will change a mod-power-of-two into a bitmask
 70 2014-09-23 06:43:10 <gmaxwell> Luke-Jr: not on a bignum. :P
 71 2014-09-23 06:43:25 <Luke-Jr> oh, I missed context then
 72 2014-09-23 07:06:30 <phantomcircuit> gmaxwell, i remember something about being able to do n of m signatures without the multisig stuff
 73 2014-09-23 07:06:39 <phantomcircuit> does that actually work in a useful way
 74 2014-09-23 07:13:23 <gmaxwell> phantomcircuit: not for ecdsa, it works for schnorr signatures.
 75 2014-09-23 07:19:00 <phantomcircuit> hmm
 76 2014-09-23 07:19:13 <phantomcircuit> gmaxwell, schorr signtures are big and slow aren't they
 77 2014-09-23 07:19:50 <phantomcircuit> implementing signature stuffs for a minimum viable coin now
 78 2014-09-23 07:20:07 <phantomcircuit> trying to keep the signature stuff as close to constant size as possible
 79 2014-09-23 07:22:02 <gmaxwell> phantomcircuit: what? no!
 80 2014-09-23 07:22:18 <gmaxwell> also, ...uh, when did you get in the altcoin making business?
 81 2014-09-23 07:22:26 <gmaxwell> 
ACTION gives a look of disapproval :)

 82 2014-09-23 07:22:36 <phantomcircuit> gmaxwell, mostly entertainment value
 83 2014-09-23 07:22:56 <phantomcircuit> certainly not going to be some silly altcoin...
 84 2014-09-23 07:23:21 <gmaxwell> they're basically the same as ecdsa, but simpler and easier to verify... and have a security proof.
 85 2014-09-23 07:23:40 <gmaxwell> the only mark agains them is that they were patented until two-ish years ago.
 86 2014-09-23 07:23:54 <gmaxwell> which is, of course, no longer a mark against them.
 87 2014-09-23 07:26:17 <phantomcircuit> gmaxwell, huh
 88 2014-09-23 07:41:14 <midnightmagic> ಠ_ಠ
 89 2014-09-23 07:47:20 <phantomcircuit> midnightmagic, ಠ_ಠ
 90 2014-09-23 07:56:27 <chichov> how come that a script loop like: while(start < end && script.GetOp(start, opcode, buf) throws a memory access violation?
 91 2014-09-23 07:57:32 <chichov> more precisely, it throws a suberror in allocators.h LockedPageManagerBase<Locker> ... Assertion 'this->GetLockedPageCount() == 0' failed. Odd error.
 92 2014-09-23 07:57:45 <wumpus> chichov: that's just a shutdown check
 93 2014-09-23 07:57:54 <wumpus> chichov: the actual assertion will be before that
 94 2014-09-23 07:58:45 <chichov> why would this be even used in a command like GetOp?
 95 2014-09-23 07:59:36 <wumpus> I'm not sure what you're asking
 96 2014-09-23 08:00:08 <chichov> I'm looping through a script to individually output its components
 97 2014-09-23 08:00:29 <chichov> and when I do so, with the loop I've described above, it throws me this strange error
 98 2014-09-23 08:00:36 <chichov> and I'm wondering - why?
 99 2014-09-23 08:01:00 <wumpus> as I said, the error that you see is not the error that causes the shutdown to be set in motion, it is just a symptom of an unclean shutdown
100 2014-09-23 08:01:40 <chichov> shutdown of the client?
101 2014-09-23 08:01:50 <wumpus> you could comment out the assertion in the destructor of LockedPageManager and it would still be crashing
102 2014-09-23 08:02:07 <wumpus> because if it gets there in the first place the program has left main()...
103 2014-09-23 08:03:18 <chichov> this is strange because if I comment out the aforementioned loop, then it works neatly
104 2014-09-23 08:03:39 <wumpus> it's clear that your loop causes an exception or assertion
105 2014-09-23 08:03:54 <chichov> it does so even when it's empty
106 2014-09-23 08:04:11 <chichov> that's the strange thing
107 2014-09-23 08:04:53 <wumpus> chichov: as said, can you try commenting out the assertion in ~LockedPageManagerBase() ?
108 2014-09-23 08:05:02 <chichov> yea, lemme try
109 2014-09-23 08:05:22 <wumpus> maybe then the actual exception that gets it there becomes more clear
110 2014-09-23 08:06:19 <chichov> well, the first exception is a memory access violation
111 2014-09-23 08:06:58 <wumpus> ok, that's the one you should debug
112 2014-09-23 08:07:00 <chichov> maybe GetOp tries to reach too far out?
113 2014-09-23 08:07:19 <wumpus> sure - start<end doesn't guarantee that GetOp doesn't reach beyond end
114 2014-09-23 08:07:52 <chichov> well, the logic should be the same as in script.cpp where scripts are evaluated
115 2014-09-23 08:08:17 <chichov> same story, they first use while(start < end) and then if(!script.GetOp(...)) return false;
116 2014-09-23 08:10:45 <wumpus> well, single step through it and see where it goes wrong
117 2014-09-23 08:12:19 <chichov> good idea, I'll try that
118 2014-09-23 08:29:54 <chichov> wumpus: odd, the error exists in when I'm using boost for test cases but not in a normal program
119 2014-09-23 08:44:05 <wumpus> a true heisenbug
120 2014-09-23 08:59:34 <chichov> hehe, true true.
121 2014-09-23 10:31:13 <michagogo> 13:54:12 <wumpus> I think it's time to tag 0.9.3 final <-- haven't you said that a couple times in the past day or two? :P
122 2014-09-23 10:31:33 <wumpus> michagogo: yes
123 2014-09-23 10:31:55 <wumpus> so someone is paying attention, woohoo :)
124 2014-09-23 10:33:05 <michagogo> I do see 3 commits in v0.9.3rc2..0.9.3
125 2014-09-23 10:33:33 <wumpus> only doc and auxilary build system changes
126 2014-09-23 10:33:42 <michagogo> But I see none of it is to the actual softw- yeah
127 2014-09-23 10:35:30 <michagogo> Is http://pkgs.fedoraproject.org/repo/pkgs/cdrkit/cdrkit-1.1.11.tar.gz/ a link that we can expect to remain stable?
128 2014-09-23 10:35:44 <wumpus> no clue, it works now, if it changes again we'll change it again
129 2014-09-23 10:36:01 <michagogo> Looks like older releases there do stay in place
130 2014-09-23 10:36:07 <michagogo> (when going up a level)
131 2014-09-23 10:36:25 <wumpus> you can't predict that in advance - you'd say the cdrkit.org link when stable, but then the complete domain went away
132 2014-09-23 10:36:36 <michagogo> well, yeah
133 2014-09-23 10:36:41 <michagogo> (maybe we should ask fedora...)
134 2014-09-23 10:37:11 <wumpus> I don't think that's necessary. The URI in the md is only a suggestion in any case, if it's not there, any other place will do.
135 2014-09-23 10:37:18 <michagogo> I guess so
136 2014-09-23 10:37:28 <michagogo> (also, the commit message refers to the wrong file...)
137 2014-09-23 10:37:29 <wumpus> (gitian verifies the integrity, so you don't have to worry about that)
138 2014-09-23 10:37:32 <michagogo> Right.
139 2014-09-23 10:38:02 <wumpus> sigh...
140 2014-09-23 10:38:58 <michagogo> BTW, from tomorrow afternoon through Saturday night or Sunday morning I'll be offline for Rosh HaShana
141 2014-09-23 10:39:12 <wumpus> yes,  Gavin isn't there either
142 2014-09-23 10:39:24 <michagogo> (it's 2 days, and immediately followed by Shabbat this year)
143 2014-09-23 10:39:57 <michagogo> So if the tag happens during that time my build may be a bit delayed
144 2014-09-23 10:40:07 <wumpus> that's fine, there is no hurry
145 2014-09-23 10:40:17 <michagogo> Yeah, just wanted you to be aware
146 2014-09-23 10:40:31 <michagogo> s/may/will/
147 2014-09-23 10:44:00 <wumpus>  * [new tag]         v0.9.3 -> v0.9.3
148 2014-09-23 11:02:27 <michagogo> aaand there's my SMS
149 2014-09-23 11:05:39 <michagogo> now let's see if the latest gitian update fixed the problem
150 2014-09-23 11:05:55 <michagogo> Sounds like it should have made it use lxc-start again my default, so it should, I hope
151 2014-09-23 11:37:56 <michagogo> btw, is there no way to do a partial build of boost, just including what we need?
152 2014-09-23 11:38:04 <michagogo> I was watching the build log just now
153 2014-09-23 11:38:23 <michagogo> Do we really need the code to calculate electrical resistance?
154 2014-09-23 11:46:31 <wumpus> yes, you can select exactly what sub-libraries you want while building boost
155 2014-09-23 11:48:11 <wumpus> although it doesn't really matter in our case, there is a one-time build overhead when the boost dependency version changes, which is very rare
156 2014-09-23 11:49:21 <wumpus> looking at the depends mechanism ,it already makes a subselection: $(package)_config_libraries=chrono,filesystem,program_options,system,thread,test
157 2014-09-23 12:25:20 <michagogo> The "warning: -fPIC ignored for target (all code is position independent)" is kinda annoying
158 2014-09-23 12:25:42 <michagogo> I'm sure it's harmless, but it's a bit spammy when watching the build.log
159 2014-09-23 12:27:07 <michagogo> (specifically, this is in the Windows build, not Linux I don't think)
160 2014-09-23 12:28:24 <michagogo> wumpus: hm, watching the nsis output I happened to notice something
161 2014-09-23 12:28:32 <michagogo> the doc/release notes only goes up to 0.9.0
162 2014-09-23 13:10:17 <SomeoneWeird> also the release-process page is outdated (inputs etc0
163 2014-09-23 13:10:18 <SomeoneWeird> )
164 2014-09-23 13:31:01 <wumpus> SomeoneWeird: any specifics?
165 2014-09-23 13:31:23 <SomeoneWeird> wumpus: about to pr, just a couple outdated inputs
166 2014-09-23 13:31:30 <wumpus> release-process.md should be up to date for the release it is in
167 2014-09-23 13:31:50 <wumpus> so the one in 0.9.3 applies to 0.9.3, the one in master applies to master
168 2014-09-23 13:32:20 <SomeoneWeird> wumpus: oh yeah i might be ridiculously tired
169 2014-09-23 13:32:22 <SomeoneWeird> 
ACTION checks

170 2014-09-23 13:33:02 <SomeoneWeird> wumpus: as usual you are correct, i thought i had switched branches but obviously not haha
171 2014-09-23 13:33:29 <wumpus> hah
172 2014-09-23 13:38:40 <michagogo> wumpus: oops
173 2014-09-23 13:38:43 <michagogo> I had the dir name wrong
174 2014-09-23 13:40:58 <michagogo> wumpus: fixed in #60
175 2014-09-23 13:41:50 <wumpus> you realize you can't just change the dir name, you need to re-sign the assert as well
176 2014-09-23 13:42:06 <michagogo> eh?
177 2014-09-23 13:42:30 <michagogo> What do you mean?
178 2014-09-23 13:43:12 <wumpus> hm I'm not sure, one time I just renamed the dir and gverify wouldn't validate the sig, not sure why, assumed the .assert would contain the name as well
179 2014-09-23 13:43:39 <michagogo> Our .asserts seem to match?
180 2014-09-23 13:43:42 <wumpus> 0.9.3-linux/michagogo/bitcoin-build.assert → 0.9.3/0.9.3-linux/michagogo/bitcoin-build.assert
181 2014-09-23 13:43:53 <michagogo> er, what?
182 2014-09-23 13:43:56 <michagogo> crap
183 2014-09-23 13:43:56 <wumpus> you added another directory level? :p
184 2014-09-23 13:44:08 <wumpus> yes, that explains why gverify doesn't pick it up hehe
185 2014-09-23 13:44:22 <michagogo> -_-
186 2014-09-23 13:44:41 <SomeoneWeird> lmao
187 2014-09-23 13:44:45 <SomeoneWeird> woops :P
188 2014-09-23 13:45:41 <michagogo> fixed
189 2014-09-23 13:46:22 <michagogo> 
ACTION goes to re-read the git-mv manpage

190 2014-09-23 13:46:48 <michagogo> Oh, derp
191 2014-09-23 13:47:09 <michagogo> The 0.9.3 dir already existed, so it moved into there rather than moving to there
192 2014-09-23 13:47:36 <michagogo> I should probably squash those, actually
193 2014-09-23 13:48:09 <michagogo> er, wait, what?
194 2014-09-23 13:48:54 <michagogo> .....
195 2014-09-23 13:51:17 <michagogo> no, no, no...
196 2014-09-23 13:53:32 <michagogo> 
ACTION is not good at git

197 2014-09-23 13:53:43 <michagogo> Okay, I think I fixed it now
198 2014-09-23 13:54:24 <michagogo> I made something like 3 commits to sequentially try and fix the error, then realized I should just squash them
199 2014-09-23 13:54:53 <michagogo> So I rebased interactively, but I think I went too far back and so it recreated the original commit
200 2014-09-23 13:54:56 <michagogo> or something
201 2014-09-23 13:55:38 <michagogo> I think I fixed it now, though...
202 2014-09-23 13:56:01 <michagogo> I just used `git reset --hard upstream/master` and made the change again
203 2014-09-23 13:56:23 <michagogo> wumpus: okay, should be right now
204 2014-09-23 14:07:46 <wumpus> michagogo: it verifies now, thanks
205 2014-09-23 15:25:55 <wumpus> BlueMatt: (as promised last time) ping, 0.9.3 final has been tagged
206 2014-09-23 15:26:27 <timothy> now I only need to wait for the tar
207 2014-09-23 15:30:56 <wumpus> timothy: https://github.com/bitcoin/bitcoin/archive/v0.9.3.tar.gz?
208 2014-09-23 15:31:21 <wumpus> executables will take a while, need wait for a number of signers, to do code signing etc
209 2014-09-23 15:42:43 <aschildbach> I'm already building…
210 2014-09-23 16:25:28 <Ghosty_CC> any bitcoin / altcoin wallet expert? Could use some help for a little wallet recovery. Willing to donate if it works :) Pm me
211 2014-09-23 16:32:44 <FXOR> ;;sell 80 btc @ 400  USB
212 2014-09-23 16:32:44 <gribble> Error: For identification purposes, you must be identified via GPG to use the order book.
213 2014-09-23 16:39:21 <aschildbach> I pushed my signatures for 0.9.3.
214 2014-09-23 16:50:36 <ajweiss> wumpus: ok to pm?
215 2014-09-23 17:00:54 <michagogo> wumpus: that's not the "official" 0.9.3 tarball though, right?
216 2014-09-23 17:02:18 <michagogo> (Am I misremembering, or do we tell people that the tarball that should be used is the one generated by make/gitian?)
217 2014-09-23 17:03:54 <BlueMatt> wumpus: much appreciated
218 2014-09-23 17:04:21 <BlueMatt> ;;seen cfields
219 2014-09-23 17:04:21 <gribble> cfields was last seen in #bitcoin-dev 1 week, 2 days, 10 hours, 28 minutes, and 41 seconds ago: <cfields> nnite
220 2014-09-23 17:04:25 <BlueMatt> :(
221 2014-09-23 17:05:15 <michagogo> BlueMatt: do you know what the story is with the different tarballs?
222 2014-09-23 17:05:22 <BlueMatt> hmm?
223 2014-09-23 17:05:27 <michagogo> see above
224 2014-09-23 17:05:38 <michagogo> (at 2:17 past the hour)
225 2014-09-23 17:06:28 <BlueMatt> michagogo: not sure what you're referring to (though I see the message), so no, I have no idea :)
226 2014-09-23 17:06:40 <michagogo> BlueMatt: GitHub provides a tarball for tags
227 2014-09-23 17:06:49 <michagogo> e.g. https://github.com/bitcoin/bitcoin/archive/v0.9.3.tar.gz
228 2014-09-23 17:06:50 <BlueMatt> yes, those are identical to git archive iirc
229 2014-09-23 17:07:02 <michagogo> But there's something else that make outputs
230 2014-09-23 17:07:06 <BlueMatt> thanks, I was literally 30 seconds from going to github to find that link....
231 2014-09-23 17:07:07 <michagogo> Oh, are they?
232 2014-09-23 17:07:26 <michagogo> I could have sworn I remembered someone saying that one should use the gitian-outputted tarball instead
233 2014-09-23 17:07:56 <BlueMatt> gitian-outputted tarball should have built binaries and such, no?
234 2014-09-23 17:07:59 <michagogo> no
235 2014-09-23 17:08:06 <michagogo> There's a source tarball that gitian spits out
236 2014-09-23 17:08:42 <BlueMatt> i dont know what you're trying to do with this tarball?
237 2014-09-23 17:09:01 <michagogo> BlueMatt: I'm not trying to do anything with it myself
238 2014-09-23 17:09:21 <michagogo> But someone was saying 18:26:26 <timothy> now I only need to wait for the tar
239 2014-09-23 17:10:23 <BlueMatt> they should verify wumpus' signature and run git archive
240 2014-09-23 17:10:40 <BlueMatt> or, if they're not gonna verify the sig anyway, just github
241 2014-09-23 17:10:52 <michagogo> 
ACTION downloads the gh tarball to compare

242 2014-09-23 17:10:55 <jintelletec> Anyone want to work for a cool btc hardware company- Remote work is fine C/C++ Engineer?
243 2014-09-23 17:20:20 <michagogo> Okay, it's definitely different
244 2014-09-23 17:20:55 <michagogo>    724 gitian-list
245 2014-09-23 17:20:55 <michagogo>    918 github-list
246 2014-09-23 17:20:55 <michagogo> $ wc -l git{ian,hub}-list
247 2014-09-23 17:28:39 <wumpus> ajweiss: sure
248 2014-09-23 17:29:12 <wumpus> michagogo: there is no "official" source tarball, as BlueMatt says people can verify the signature on the git tag for v0.9.3, that's assurance of the release
249 2014-09-23 17:30:10 <michagogo> I'm looking now and there's a big difference between the github tarball and the gitian tarball
250 2014-09-23 17:32:47 <BlueMatt> michagogo: then the gitian tarball is some custom format
251 2014-09-23 17:33:01 <BlueMatt> probably in compatibility with the original format that satoshi used, but I have no idea anymore
252 2014-09-23 17:33:01 <michagogo> Right
253 2014-09-23 17:33:06 <wumpus> BlueMatt: yes, make dist format
254 2014-09-23 17:33:08 <BlueMatt> ask cfields, who seems to be on vacation
255 2014-09-23 17:33:13 <BlueMatt> ahh
256 2014-09-23 17:33:45 <michagogo> So which should people be using for various purposes?
257 2014-09-23 17:34:25 <asoltys> can you BIP38 encrypt a BIP32 extended private key?
258 2014-09-23 17:34:44 <coryfields> hmm?
259 2014-09-23 17:35:23 <coryfields> wumpus: there is an official tarball, we've just not pushed it very hard yet
260 2014-09-23 17:35:32 <coryfields> it's bootstrapped and deterministic, produced by gitian
261 2014-09-23 17:35:50 <coryfields> rather, i suppose, I'd like that to be considered the official one :)
262 2014-09-23 17:35:51 <BlueMatt> coryfields: you changed nicks....
263 2014-09-23 17:36:17 <coryfields> BlueMatt: freenode nick change has my clients messed up, haven't messed with it yet
264 2014-09-23 17:36:22 <coryfields> *pass change
265 2014-09-23 17:36:24 <BlueMatt> ahh
266 2014-09-23 17:41:10 <michagogo> Here's a diff between the gitian tarball and the github tarball, with the timestamps normalized
267 2014-09-23 17:41:11 <michagogo> http://www.diffnow.com/?report=ni27q
268 2014-09-23 17:42:23 <michagogo> (that is, github's timestamp sed'ed to gitian's timestamp to remove that element of diff)
269 2014-09-23 17:50:42 <wumpus> coryfields: why don't we zip up the entire repository for the gitian tarball, btw? quite a lot is missing right now, for example the stuff in contrib/debian
270 2014-09-23 17:51:23 <michagogo> Well, we may not need everything
271 2014-09-23 17:51:43 <michagogo> For example, .gitignore doesn't need to be in our tarball releases
272 2014-09-23 17:52:16 <coryfields> wumpus: it uses the enumerated files for the dist tarball. That way there's no chance of local files slipping in
273 2014-09-23 17:52:31 <coryfields> that's why pull-tester fails if you forget to add a .h to the list, for ex
274 2014-09-23 17:52:36 <michagogo> Oh, just realized how I can make just a plain list of files -_-
275 2014-09-23 17:52:40 <coryfields> but, no reason why we couldn't add those files as extras
276 2014-09-23 17:54:23 <coryfields> wumpus: the main point of the dist tarball is that it's already bootstrapped. auto* aren't needed for the builder, since they've all been converted to shell scripts already
277 2014-09-23 17:54:35 <wumpus> I'm not sure it makes sense to enumerate any file we need, sure, if you ship it all there may be some redundant files (such as .gitignore) but that's no big issiue is it?
278 2014-09-23 17:55:02 <wumpus> coryfields: agreed, but those are extra files
279 2014-09-23 17:55:15 <coryfields> wumpus: for source files it's necessary. for extras, i'd be fine with globbing
280 2014-09-23 17:55:15 <michagogo> Okay, here's a better diff
281 2014-09-23 17:55:20 <wumpus> I'm not sure it makes sense to squeeze out a few bytes here at risk that something is missed
282 2014-09-23 17:55:21 <michagogo> http://www.diffnow.com/?report=ny0hr
283 2014-09-23 17:55:43 <michagogo> That shows everything that's only in GH (right) and everything that's only in the gitian output (left)
284 2014-09-23 17:55:45 <coryfields> wumpus: nah, it's not about size, it's about ensuring that local files don't slip in
285 2014-09-23 17:56:29 <coryfields> wumpus: anyway, i agree. adding contrib stuff like debian to extras is fine by me. no need to enumerate
286 2014-09-23 17:56:44 <michagogo> hmm
287 2014-09-23 17:57:18 <michagogo> So there are src files missing from the gitian tarball
288 2014-09-23 17:57:27 <michagogo> e.g. bitcoin-0.9.3/src/json/json_spirit_value.cpp
289 2014-09-23 17:58:05 <michagogo> oh, wait, I messed up the sorting
290 2014-09-23 17:58:06 <michagogo> bah
291 2014-09-23 17:58:35 <coryfields> michagogo: that tarball is used for the final build
292 2014-09-23 17:58:47 <michagogo> Wait, it is?
293 2014-09-23 17:59:06 <michagogo> How come it works with src files missing?
294 2014-09-23 17:59:23 <michagogo> Anyway, http://www.diffnow.com/?report=cjn0g is sorted properly
295 2014-09-23 18:09:42 <ajweiss> sipa: ok to pm?
296 2014-09-23 18:09:49 <sipa> sure
297 2014-09-23 19:27:20 <michagogo> http://i.imgur.com/dpL95uX.png
298 2014-09-23 19:27:20 <michagogo> whoa
299 2014-09-23 19:27:38 <michagogo> Apparently Gmail detects GitHub emails and adds buttons...
300 2014-09-23 19:27:46 <sipa> nope
301 2014-09-23 19:27:54 <sipa> github sends a mail header that gmail interprets
302 2014-09-23 19:30:21 <coryfields> ah neat, i was wondering about that
303 2014-09-23 19:31:23 <gwillen> seems to be documented at https://developers.google.com/gmail/actions/getting-started
304 2014-09-23 19:31:41 <sipa> google has been using that internally for a while for its code review and bug tracker system :)
305 2014-09-23 19:31:49 <gwillen> it's not a header, it goes in the html body of the message apparently
306 2014-09-23 19:31:59 <gwillen> and to use it externally you have to be whitelisted with manual review
307 2014-09-23 19:33:30 <sipa> makes sense
308 2014-09-23 19:38:15 <michagogo> <script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","description":"View this Pull Request on GitHub","action":{"@type":"ViewAction","url":"https://github.com/bitcoin/gitian.sigs/pull/62","name":"View Pull Request"}}</script>
309 2014-09-23 19:46:19 <earlz> So, are there any cases where the comment of a transaction would be lost, or associated with a different transaction?
310 2014-09-23 19:46:31 <earlz> through the reference client's RPC interface
311 2014-09-23 22:09:54 <BlueMatt> is there a reason upgrading to master from 0.9.X would significantly limit mempool contents
312 2014-09-23 22:09:56 <BlueMatt> ?
313 2014-09-23 22:11:47 <BlueMatt> sipa: ^
314 2014-09-23 22:12:25 <sipa> i doubt it?
315 2014-09-23 23:12:06 <Luke-Jr> [19:27:55] <sipa> github sends a mail header that gmail interprets <-- I see no generic header. If Gmail is using some standardish header for this, that is more of "Gmail detects GitHub emails and adds buttons" IMO
316 2014-09-23 23:14:41 <Luke-Jr> ah, body