1 2013-09-19 00:21:36 <sipa> gmaxwell: heh, for RFC6979-compliant signatures... we'd have to use HMAC_doubleSHA256 ...
2 2013-09-19 00:21:56 <sipa> as our message is generated through H = doubleSHA256
3 2013-09-19 00:22:42 <gmaxwell> 17:27 * sipa is inclined to use HMAC-SHA512 instead
4 2013-09-19 00:22:42 <gmaxwell> 17:31 < gmaxwell> one thing they advise is to use the same hash in the hmac that you use for your signing. I think we could be permitted HMAC_SHA512 if it made (I push up to recover the text I was writing a few minutes ago and abandoned)
5 2013-09-19 00:23:04 <sipa> yeah, i remember i brought it up before
6 2013-09-19 00:24:48 <gmaxwell> it's surprisingly obnoxious to sign that way in openssl.
7 2013-09-19 00:26:04 <cfields> gavinandresen: our zips don't line up, but i believe the contents do
8 2013-09-19 00:26:43 <sipa> ah!
9 2013-09-19 00:26:47 <sipa> In this document, we use the same hash function H for processing the input message and as a parameter to HMAC. Two distinct hash functions could be used, provided that both are adequately secure.
10 2013-09-19 00:27:27 <gmaxwell> I couldn't find any why to just select K, instead you have to compute K inv and R before handing it off to the signing function if you want to control K.
11 2013-09-19 00:27:48 <gmaxwell> (which isn't really a big deal, but at that point you're half way to doing the signature entirely manually)
12 2013-09-19 00:28:34 <gmaxwell> (and wtf would you precompute and save inv-K and R for?! you're not allowed to reuse them!)
13 2013-09-19 00:31:53 <sipa> the document suggests ignoring the possibility that r=0
14 2013-09-19 00:32:58 <gmaxwell> sipa: doesn't it also though advise a loop for fitting into the range?
15 2013-09-19 00:33:20 <sipa> yes
16 2013-09-19 00:33:31 <gmaxwell> seems weird!
17 2013-09-19 00:33:41 <sipa> not at all
18 2013-09-19 00:34:04 <sipa> note that not all curves have a field size close to a power of 256
19 2013-09-19 00:35:09 <gmaxwell> sure. It could be more likely than it is for us, but if you've already got code to handle the upper range why not 0?
20 2013-09-19 00:35:43 <sipa> no, they loop until k is between 1 and q-1
21 2013-09-19 00:35:52 <sipa> you don't need to compute r for that
22 2013-09-19 00:36:16 <gmaxwell> Oh sorry! I see, I thought you were saying for the K=0 case.
23 2013-09-19 00:36:44 <sipa> the only reason for computing k^-1 and r, is to check that r isn't 0
24 2013-09-19 00:37:34 <sipa> hmm, s is not allowed to be 0 either
25 2013-09-19 00:37:46 <sipa> which really just means you need to do the entire signing in-loop
26 2013-09-19 00:40:26 <gmaxwell> Did you see that there was someone on the forum trying to argue that you also need to stop k == seckey? :P I suggested that he also watch out for k==11, since if he uses that value I can also recover his private key.
27 2013-09-19 00:41:01 <sipa> i haven't read the forum in ages
28 2013-09-19 00:42:08 <sipa> (ps: libsecp256k1 just asks you to pass in k, and tells you whether it could create a valid signature with it, so it'd be trivial to plug into an rfc6979 implementation)
29 2013-09-19 00:43:35 <gmaxwell> I know. When I was dorking around with cheating signers I first implemented in libsecp256k1. Then I went and implemented in a bitcoin derrived codebase and was unimpresed with openssl's interface compared to yours.
30 2013-09-19 00:44:08 <gmaxwell> (though yours, however, doesn't have a arbritary point multiply exposed, so I couldn't do ECDH)
31 2013-09-19 00:45:27 <sipa> now it does :)
32 2013-09-19 00:45:45 <gmaxwell> sipa: ha. ever see this old post: https://bitcointalk.org/index.php?topic=6175.0 ?
33 2013-09-19 00:46:41 <sipa> gmaxwell: no, but i've wondered about the same thing :)
34 2013-09-19 00:48:44 <gavinandresen> If you're mucking around with signing⦠implementing ByteCoin's idea of hiding data in signatures might be a good idea.
35 2013-09-19 00:49:07 <sipa> link?
36 2013-09-19 00:49:32 <gmaxwell> pairing short signatures are really a lot nicer than ECDSA... no nonce.
37 2013-09-19 00:50:56 <sipa> wait
38 2013-09-19 00:51:13 <sipa> ah, no
39 2013-09-19 00:51:59 <gavinandresen> fricking fracking, there's an altcoin named bytecoin⦠(makes searching forums hard)
40 2013-09-19 00:52:08 <gmaxwell> I know. :(
41 2013-09-19 00:52:43 <sipa> i'm amazed there is no altcoin called buttercoin yet
42 2013-09-19 00:54:11 <sipa> ACTION snores
43 2013-09-19 00:54:21 <cfields> isn't buttercoin some trading platform?
44 2013-09-19 00:56:50 <gavinandresen> sipa: when you wake up: can't find the link, might not have been ByteCoin, but the idea is to weaken the signature by using some of the bits in k as a side-channel for communication between sender and receiver.
45 2013-09-19 00:57:06 <nkuttler> hrm, is there a reason why calling help() through the api would not list walletfoo methods? i only see them from the command line
46 2013-09-19 00:57:23 <nkuttler> maybe because the api connection is not encrypted?
47 2013-09-19 00:57:25 <gmaxwell> gavinandresen: oh I actually implemented that the other day!
48 2013-09-19 00:57:43 <gmaxwell> gavinandresen: but for the purpose of making an ecdsa signer that gives your private keys to the wallet maker.
49 2013-09-19 00:58:23 <gavinandresen> gmaxwell: spiffy!
50 2013-09-19 00:58:47 <gavinandresen> gmaxwell: my thought is exposing "use this k for this transaction" would be useful raw transaction api
51 2013-09-19 00:59:00 <gavinandresen> ⦠or something⦠(half-baked thoughts here)
52 2013-09-19 00:59:12 <gavinandresen> Lots of opportunity to completely shoot yourself in your feet, of course
53 2013-09-19 00:59:24 <gmaxwell> Idea is that you use your sec to ECDH with the target's pubkey. And use that to derrive a secret that you use to derrive K. The holder of the far pubkey can then use their knoweldge of K to recover your secret key. If bytecoin wanted to use it for messaging he would have had you make extra outputs and then recover the messages from them.
54 2013-09-19 00:59:32 <gmaxwell> ACTION searches
55 2013-09-19 00:59:36 <sipa> actually, if you do a normal ECDSA sign once, you can do further attemps faster
56 2013-09-19 01:00:08 <gmaxwell> https://bitcointalk.org/index.php?topic=5965.msg87757#msg87757 < (knowing that he would have used Diffie-Hellman made it easy to search for)
57 2013-09-19 01:00:08 <sipa> as just increasing k by one means you can avoid the multiplication with G to obtain r
58 2013-09-19 01:01:05 <sipa> it's still an inverse mod n, but you may gain an order of magnitude
59 2013-09-19 01:01:40 <sipa> ACTION snores more
60 2013-09-19 01:01:48 <gavinandresen> Ah, those two-year-old threads where we talk about all the stuff that needs to be done that STILL isn't done....
61 2013-09-19 01:02:39 <gmaxwell> I miss Bytecoin.
62 2013-09-19 01:03:09 <gavinandresen> gmaxwell: according to his forum profile, he is still around: Last Active:
63 2013-09-19 01:03:37 <gmaxwell> Oh well, now we get the crappy altcoin instead.
64 2013-09-19 01:04:26 <gavinandresen> Heh, ByteCoin's last post to the forums: "This is the first thing written about Bitcoin that's been worth reading in quite a while."
65 2013-09-19 01:45:58 <MobGod> gmaxwell you around
66 2013-09-19 01:46:55 <MobGod> after doing the reindex on the mac seems to be working but now that i did a reboot of my machine and tried to open the gui again it gave me a error about the chain and wants to reindex all over again
67 2013-09-19 02:09:10 <MobGod> anyone have a idea for this ?
68 2013-09-19 02:13:28 <Tril> MobGod: 0.8.5?
69 2013-09-19 02:14:05 <MobGod> yes
70 2013-09-19 02:14:49 <MobGod> gmaxwell told me to reindex thats what i did was all synced than i did a reboot tried to open the GUI again and i get a error need to reindex again
71 2013-09-19 02:15:56 <Tril> just want to make sure if you go ot help, about Bitcoin it does say 0.8.5
72 2013-09-19 02:16:09 <Tril> since that problem was supposed to be fixed
73 2013-09-19 02:16:17 <gmaxwell> Tril: unrelated problem.
74 2013-09-19 02:16:48 <gmaxwell> Tril: he's just hitting OSX disk corruption. Which was improved in 0.8.4 but there are more fixes that aren't out in any release yet.
75 2013-09-19 02:17:31 <MobGod> so gmaxwell what do i need to do lets this index again and try not to reboot i take it ?
76 2013-09-19 02:17:48 <Tril> did you close Bitcoin-qt before rebooting the machine?
77 2013-09-19 02:18:29 <gmaxwell> MobGod: just close cleanly before rebooting and you should be fine until the next release.
78 2013-09-19 02:19:57 <MobGod> gmaxwell ok thats what i did i closed the qt first than i did a reboot and i get a error when trying to start it back up telling me to reindex again
79 2013-09-19 02:34:27 <jgarzik> hrm
80 2013-09-19 02:34:31 <jgarzik> anything going on, on mainnet?
81 2013-09-19 02:35:04 <jgarzik> my behind-NAT'ing-firewall node == HEAD, has several connections, downloaded blocks but is seeing no incoming TX's
82 2013-09-19 02:35:45 <jgarzik> almost nothing going into debug.log at all, which is odd for mainnet. Last log message 3 minutes ago.
83 2013-09-19 02:36:22 <Luke-Jr> jgarzik: my bitcoind stops logging sometimes, I think when the file gets to a certain size; but I've never bothered to look into it <.<
84 2013-09-19 02:37:43 <Tril> jgarzik: I don't trust the "connected nodes" reported. I need to restart bitcoind if I lose Internet temporarily to trigger it to reconnect.
85 2013-09-19 02:38:31 <jgarzik> I'm getting blocks...
86 2013-09-19 02:38:53 <jgarzik> current height 258747, best=0000bc518bdff
87 2013-09-19 02:40:00 <Tril> same here
88 2013-09-19 02:40:14 <Tril> TX coming in about 1/sec
89 2013-09-19 02:40:21 <Luke-Jr> hm
90 2013-09-19 02:40:52 <Luke-Jr> lots of tx pretty fast here
91 2013-09-19 02:41:02 <jgarzik> I've received one tx -- rejected dust -- in the past 7 minutes
92 2013-09-19 02:41:15 <SomeoneWeird> u brokez
93 2013-09-19 02:41:17 <jgarzik> this is a newly restarted node, and I saw this behavior through two restarts
94 2013-09-19 02:42:00 <Luke-Jr> otoh, I have 43 connections and an open port
95 2013-09-19 02:43:21 <SomeoneWeird> http://istouchidhackedyet.com/
96 2013-09-19 02:44:01 <Tril> jgarzik: under 8 connections? clock correct?
97 2013-09-19 02:44:22 <jgarzik> Can anyone replicate this simple environment? bitcoind, git HEAD, behind a NAT router, newly restarted?
98 2013-09-19 02:44:23 <cfields> jgarzik: i'm seeing the same. height=258747, then 2 dust after that
99 2013-09-19 02:44:53 <jgarzik> us2/eu3.exmulti (older git, long running) are seeing plenty of TX's
100 2013-09-19 02:45:18 <jgarzik> my git HEAD is seeing practically none -- zero after this most recent restart.
101 2013-09-19 02:46:26 <cfields> jgarzik: ah wait, there was just that big printf change
102 2013-09-19 02:46:40 <jgarzik> OH YEAH
103 2013-09-19 02:46:50 <cfields> i'll jump back a few commits for quick test
104 2013-09-19 02:47:04 <jgarzik> I'm sure that's it
105 2013-09-19 02:47:23 <Luke-Jr> lol
106 2013-09-19 02:47:46 <jgarzik> the new default apparently logs quite a bit less
107 2013-09-19 02:48:38 <Tril> I tried ./configure on HEAD I got this configure: error: Could not link against boost_thread-mt !
108 2013-09-19 02:48:57 <cfields> jgarzik: yep, back to normal before then
109 2013-09-19 02:49:48 <Luke-Jr> Tril: it worked before?
110 2013-09-19 02:51:31 <Tril> Luke-Jr: never done this before, usually use release branch which has no ./autogen.sh or ./configure step
111 2013-09-19 02:52:06 <cfields> Tril: the buildsystem was added in the last few weeks
112 2013-09-19 02:57:29 <phantomcircuit> sigh
113 2013-09-19 02:57:43 <phantomcircuit> so im still having trouble constructing the block header from the stratum stuff
114 2013-09-19 02:57:44 <phantomcircuit> http://pastebin.com/raw.php?i=7TYxPH47
115 2013-09-19 02:58:14 <phantomcircuit> the expected hash from cpuminer's logs is 0000000047c848a504acdc6d870159665f9fc67dc4c5b0a048f8ddbda9427dfe
116 2013-09-19 02:58:31 <phantomcircuit> and the merkle root that's calculated matches cpuminer's logs
117 2013-09-19 02:58:57 <Luke-Jr> Tril: right, by before I mean the old way
118 2013-09-19 02:59:07 <Luke-Jr> Tril: can you upload config.log?
119 2013-09-19 03:01:24 <Tril> Luke-Jr: ah, sure... in fact I can ./configure --with-boost-thread=no and it fails on the next boost library, and the next..
120 2013-09-19 03:01:53 <Luke-Jr> Tril: erm, boost-thread isn't optional. what gave you the impression you could =no it?
121 2013-09-19 03:03:17 <Tril> Luke-Jr: I expected it to fail later on, I was just trying things that were syntactically valid. Try: http://tril.tunes.org/tmp/config.log
122 2013-09-19 03:04:17 <Luke-Jr> odd - I don't see the failure it's reporting there
123 2013-09-19 03:04:27 <Luke-Jr> cfields: maybe you have some insight?
124 2013-09-19 03:07:01 <SomeoneWeird> g++: fatal error: no input files
125 2013-09-19 03:07:34 <cfields> that's supposed to happen..
126 2013-09-19 03:07:40 <SomeoneWeird> \(_o)/
127 2013-09-19 03:07:49 <cfields> error is at 11385
128 2013-09-19 03:08:10 <cfields> doesn't make sense, though
129 2013-09-19 03:08:44 <SomeoneWeird> why not? he doesn't have libdbd-dev installed?
130 2013-09-19 03:08:48 <Tril> Luke-Jr: http://pastebin.com/QMcbMv5y - same problem in 32-bits, 64-bits, and previous Debian 64 version
131 2013-09-19 03:09:04 <SomeoneWeird> Tril, do you have libdbd-dev installed? :)
132 2013-09-19 03:09:12 <cfields> oh, i bet it's reporting poorly...
133 2013-09-19 03:09:22 <cfields> Tril: i'm guessing you don't have boost unit tests installed?
134 2013-09-19 03:09:52 <Tril> no, didn't install anything extra since building 0.8.5.
135 2013-09-19 03:10:21 <Tril> I have a Berkeley DB manual install too, since they took it out of Debian..
136 2013-09-19 03:10:36 <cfields> Tril: ./configure --disable-tests
137 2013-09-19 03:10:38 <cfields> for a quick check
138 2013-09-19 03:11:30 <Tril> cfields: got further. now libprotobuf not found
139 2013-09-19 03:11:40 <cfields> Tril: ok, install that
140 2013-09-19 03:11:50 <cfields> we need to fix that reporting of boost, that's almost impossible to see
141 2013-09-19 03:12:53 <cfields> Tril: also, install libboost-test-dev
142 2013-09-19 03:13:16 <Tril> cfields: qt support requested but protoc was not found.
143 2013-09-19 03:13:50 <cfields> Tril: beginning to see a pattern here? :)
144 2013-09-19 03:13:52 <cfields> install protoc
145 2013-09-19 03:14:30 <SomeoneWeird> cfields, are you newish around here or have you changed your nick? :)
146 2013-09-19 03:14:58 <cfields> SomeoneWeird: newish
147 2013-09-19 03:15:02 <SomeoneWeird> :)
148 2013-09-19 03:15:13 <Tril> ok, found in package: protobuf-compiler
149 2013-09-19 03:17:42 <cfields> Tril: thanks for the grim reminder, will make docs a priority
150 2013-09-19 03:30:26 <Tril> it's working and not printing TX in the debug.log but it shows some in getblocktemplate.
151 2013-09-19 04:14:32 <gavinandresen> Yesterday's pull made debug.log much less chatty.
152 2013-09-19 04:14:43 <gavinandresen> Run with -debug=net if you want to see all the "got transactions" etc messages
153 2013-09-19 04:56:43 <gavinandresen> FYI: Pull-tester is experienced Technical Difficulties...
154 2013-09-19 05:03:57 <cfields> gavinandresen: i was wondering about that. was there an instance hanging around or something?
155 2013-09-19 05:29:59 <jgarzik> gavinandresen, jfyi bitcoind now logs a -lot- less than normal by default, and there does not appear to be a way to do -debug=all or -debug=*
156 2013-09-19 05:30:19 <jgarzik> gavinandresen, if pull tester scans bitcoind logs, that may have an impact.
157 2013-09-19 05:30:22 <jgarzik> BlueMatt, ^
158 2013-09-19 05:33:46 <jgarzik> heh
159 2013-09-19 05:33:58 <jgarzik> blockchain.info moves to CloudFlare. Centralization continues...
160 2013-09-19 06:00:10 <cfields> jgarzik: ah yes, it does
161 2013-09-19 06:00:52 <cfields> https://github.com/bitcoin/bitcoin/blob/master/qa/pull-tester/run-bitcoind-for-test.sh.in#L6
162 2013-09-19 06:01:03 <cfields> it waits to see "Done Loading"
163 2013-09-19 06:01:31 <cfields> i suppose that explains the timeouts from pulltester
164 2013-09-19 06:27:32 <cfields> mm, nope "Done loading" unaffected
165 2013-09-19 07:01:08 <sipa> jgarzik: they weren't using cloudflare already?
166 2013-09-19 07:09:53 <gavinandresen> jgarzik: -debug=all is a good idea.
167 2013-09-19 07:10:13 <gavinandresen> ⦠but that isn't why pull-tester is sick, I don't think
168 2013-09-19 08:58:04 <_dr> sipa: looks like the scalings on your graphs might need another update (:
169 2013-09-19 09:23:54 <warren> gmaxwell: jgarzik: argh!!!! gitian mingw32 lacks both cpuid.h and intrin.h
170 2013-09-19 09:28:28 <warren> I implemented the native MSVC compatible cpuid method
171 2013-09-19 09:29:07 <_dr> isn't there a standard way like __asm__("cpuid");?
172 2013-09-19 09:30:43 <warren> _dr: wanted to avoid it because inline assembly is not supported in MSVC anymore
173 2013-09-19 09:31:01 <warren> _dr: I was asked to avoid gratuitously breaking compat with MSVC
174 2013-09-19 10:48:14 <sipa> warren: i don't get it - MSVC is not supported in any way
175 2013-09-19 10:50:00 <warren> sipa: huh. I was told to not break it.
176 2013-09-19 10:54:05 <sipa> by?
177 2013-09-19 10:54:51 <sipa> i mean, not gratuitously breaking things further is certainly nice, as it'd make the job of someone who wants to make MSVC supported easier
178 2013-09-19 10:55:01 <sipa> but if it's such a hassle, don't bother
179 2013-09-19 10:58:24 <warren> sipa: ok, so just use inline asm until someone makes MSVC a requirement...
180 2013-09-19 11:53:17 <wumpus> warren: you could always disable the inline asm in case of other compilers, you need that for other architecture support anyway
181 2013-09-19 11:53:29 <sipa> ^
182 2013-09-19 11:55:27 <warren> wumpus: yeah, I have ARM support preserved currently
183 2013-09-19 11:56:17 <warren> wumpus: I'm writing this for Litecoin's SSE2 optimization at first, but I want a generic cpuid thing to submit for Bitcoin later. There are ways to make sha256 faster. Not a huge priority of course.
184 2013-09-19 11:59:07 <warren> hmm... is there a preprocessor define for mingw version ...
185 2013-09-19 12:40:57 <jonass> anyone here with bitcoinj experience?
186 2013-09-19 14:38:59 <sipa> http://eprint.iacr.org/2013/525
187 2013-09-19 14:40:58 <jgarzik> sipa, yep, pointed that out in #bitcoin-dev when it hit reddit, a week or two ago
188 2013-09-19 14:41:04 <gmaxwell> ah, that came out while you were on vacation.
189 2013-09-19 14:41:06 <jgarzik> gmaxwell glanced at it
190 2013-09-19 14:41:08 <gmaxwell> I like it.
191 2013-09-19 14:41:36 <gmaxwell> It think it's a mild improvement over scrypt. I should ask the author of scrypt what he thinks of it.
192 2013-09-19 14:42:14 <gmaxwell> eliminates the data dependant memory accesses, also as a side effect removes some of the time/memory tradeoff you can do.
193 2013-09-19 14:46:27 <Diablo-D3> wait
194 2013-09-19 14:46:29 <Diablo-D3> what?
195 2013-09-19 14:46:45 <Diablo-D3> gmaxwell: let me get this straight, it ISNT abusive on memory/
196 2013-09-19 14:47:00 <gmaxwell> ...
197 2013-09-19 14:47:29 <Diablo-D3> gmaxwell: because the abstract clearly says it is
198 2013-09-19 14:48:21 <Diablo-D3> what?
199 2013-09-19 14:48:39 <gmaxwell> my eyes are burning at the stupid.
200 2013-09-19 14:48:56 <gmaxwell> That isn't what I said, I said that it doesn't do _data dependant_ accesses.
201 2013-09-19 14:49:09 <Diablo-D3> gmaxwell: btw, whats a cache timing attack
202 2013-09-19 14:49:09 <gmaxwell> It access memory in a fixed pattern which is independant of the data.
203 2013-09-19 14:49:37 <Diablo-D3> ahh
204 2013-09-19 14:49:44 <Diablo-D3> but wouldnt that make it computationally easier?
205 2013-09-19 14:49:47 <gmaxwell> Diablo-D3: thats where one thread on your system measures timing very precisely and by observing cache timining noise extracts data from another task.
206 2013-09-19 14:50:17 <Diablo-D3> yeah, but how would that data be useful
207 2013-09-19 14:50:37 <gmaxwell> if it depended on some secret, you learn data about that secret.
208 2013-09-19 14:51:03 <gmaxwell> even if its only a few bits it could allow you to early terminate a search.
209 2013-09-19 14:51:14 <Diablo-D3> yeah but
210 2013-09-19 14:51:22 <Diablo-D3> isnt that the same as what openssl did years ago
211 2013-09-19 14:51:27 <Diablo-D3> so failued attempts take identical time?
212 2013-09-19 14:51:41 <gmaxwell> (there is nice code out there that recovers whole gpg keys this wayâ¦)
213 2013-09-19 14:51:53 <gmaxwell> Diablo-D3: scrypt didn't attempt to take identical time.
214 2013-09-19 14:52:07 <Diablo-D3> that sounds like its a bug in the scrypt impl, not in scrypt
215 2013-09-19 14:52:32 <gmaxwell> you could only make scrypt take identical time if you massively slowed it down.
216 2013-09-19 14:52:50 <Diablo-D3> well yeah, thats what happens
217 2013-09-19 14:53:02 <gmaxwell> which would defeat the idea, since it would mean an attacker could have a faster implementation than you.
218 2013-09-19 14:53:03 <warren> I certainly wish scrypt were slower.
219 2013-09-19 14:53:09 <sipa> warren: ...
220 2013-09-19 14:53:14 <sipa> warren: it's as slow as you want
221 2013-09-19 14:53:21 <warren> ACTION lame joke
222 2013-09-19 14:53:44 <gmaxwell> cantina had a non-data-dependant memory pattern, so it doesn't leak timing data even in a normal fast implementation.
223 2013-09-19 14:53:46 <warren> I didn't pick these parameters. It is big enough to suck, and small enough to suck.
224 2013-09-19 14:54:13 <Diablo-D3> warren: lol
225 2013-09-19 14:54:14 <sipa> warren: you're referring to the specific parameters used in litecoin?
226 2013-09-19 14:54:24 <Diablo-D3> litecoin uses scrypt wrong
227 2013-09-19 14:55:27 <Diablo-D3> it turns up the cpu hard knob, and leaves the memory hard knob alone
228 2013-09-19 14:55:31 <gmaxwell> though perhaps someone will argue that catena has less security because it would work better for a muxless "dram bucket brigade" than scrypt would.
229 2013-09-19 14:55:42 <Diablo-D3> gmaxwell: a what?
230 2013-09-19 14:56:25 <gmaxwell> an ideal catena machine would look kind of like a CCD array. Big memory delay lines, not random access.
231 2013-09-19 14:56:49 <rus> h
232 2013-09-19 14:57:16 <Diablo-D3> gmaxwell: so... uh
233 2013-09-19 14:57:25 <Diablo-D3> gmaxwell: couldnt I just asic my way out of the problem then?
234 2013-09-19 14:57:50 <rus> hello. can anyone help me understand bitcoin mining better? I dont get what target and midstate are used for. also when do you submit work to a pool
235 2013-09-19 14:58:11 <rus> vs when to get more work
236 2013-09-19 14:58:37 <Diablo-D3> rus: if you're looking to write another miner, please dont
237 2013-09-19 14:58:43 <Diablo-D3> we already have enough
238 2013-09-19 14:58:45 <rus> its not for btc
239 2013-09-19 14:58:54 <rus> but this is the largest community
240 2013-09-19 14:58:57 <jgarzik> this IRC channel is for btc ;p
241 2013-09-19 14:58:57 <rus> for dev
242 2013-09-19 14:59:07 <rus> the proto is the same from what i understand
243 2013-09-19 14:59:14 <rus> for all crypto curs
244 2013-09-19 14:59:34 <Diablo-D3> rus: okay, do you understand what difficulty is?
245 2013-09-19 14:59:34 <gmaxwell> rus: I suggest you go find the developers for the thing you're interested in.
246 2013-09-19 14:59:51 <rus> no
247 2013-09-19 15:00:00 <Diablo-D3> then I suggest you start there
248 2013-09-19 15:00:04 <Diablo-D3> go look at the bitcoin wiki
249 2013-09-19 15:00:07 <Diablo-D3> come back when you're done
250 2013-09-19 15:00:13 <gmaxwell> No, don't come back.
251 2013-09-19 15:00:23 <gmaxwell> Come back when you have questions about _bitcoin development_.
252 2013-09-19 15:00:35 <Diablo-D3> gmaxwell: hey, dont we need more alt coins?
253 2013-09-19 15:00:39 <Diablo-D3> I mean, we have at least 12
254 2013-09-19 15:00:42 <gmaxwell> For _other thing development_ try #otherthing.
255 2013-09-19 15:02:54 <rus> "If your hash is below the target, then you win. If not, you increment the nonce (completely changing the hash) and try again. "
256 2013-09-19 15:03:08 <rus> so you send the hash to the pool/network if you get it below the target?
257 2013-09-19 15:03:37 <rus> then if its correct network sends you back that you unlocked the block? otherwise if using pool it just sends that your share was acepted?
258 2013-09-19 15:03:59 <sipa> rus: you do that yourself
259 2013-09-19 15:04:22 <sipa> you hash the block with the nonce, and if the number is low enough, you submit the block
260 2013-09-19 15:04:27 <sipa> otherwise, you keep trying
261 2013-09-19 15:04:38 <sipa> ;;calc [diff]*2**48/65535
262 2013-09-19 15:04:39 <gribble> Error: invalid syntax (<string>, line 1)
263 2013-09-19 15:05:01 <sipa> and there is no unlocking by the network, you're the one who creates the block
264 2013-09-19 15:05:10 <sipa> (or the pool creates it for you)
265 2013-09-19 15:05:16 <rus> but if you submit the block it does not mean its correct does it?
266 2013-09-19 15:05:29 <rus> its just a valid try?
267 2013-09-19 15:05:31 <sipa> if the hash isn't low enough, it's just invalid
268 2013-09-19 15:05:49 <rus> yea so it shouldnt even be submitted in thta case
269 2013-09-19 15:05:54 <sipa> if it is, it's valid (given that the transactions in it are also ok), but that doesn't mean that others will accept it
270 2013-09-19 15:08:02 <rus> just debugging some miners i can see that. they calculate for x time or 100k nonce's
271 2013-09-19 15:08:16 <rus> after that they request a new block from the pool.
272 2013-09-19 15:08:38 <rus> but sometimes they send work back to the pool. passing some data in the params[] of getwork.
273 2013-09-19 15:08:53 <rus> how do they know when to pass empty params vs pass data
274 2013-09-19 15:10:12 <sipa> that's just submit vs requesting new work
275 2013-09-19 15:10:18 <sipa> but really, getwork is outdated
276 2013-09-19 15:11:32 <rus> yea but you submit work if you find a hash below target?
277 2013-09-19 15:11:40 <rus> or when do yo submit?
278 2013-09-19 15:11:43 <sipa> yes
279 2013-09-19 15:11:52 <rus> ah
280 2013-09-19 15:12:01 <sipa> well, for a pool miner, you submit it when it's an almost-block (called a share)
281 2013-09-19 15:12:15 <sipa> so the pool can keep track of how much you're hashing, even if you don't find an actual block
282 2013-09-19 15:15:42 <rus> yea so anytime the hash is below target, you submit it to the pool as a share?
283 2013-09-19 15:15:55 <rus> then every 2m ticks or 100k nonces you request more work from pool?
284 2013-09-19 15:17:50 <rus> hum... target must be: target:ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000 ?
285 2013-09-19 15:18:13 <rus> but you submit share anytime 4 trailing 0 bytes? just to show proof your doing work?
286 2013-09-19 15:23:48 <jgarzik> gmaxwell, sipa: any preference for "all log messages": -debug -debug=* -debug=all other option? As mentioned earlier in channel w/ gavin, the LogPrint stuff radically reduces the amount of messages output by default, and there appears to be no easy way to say "print all". Currently you need -debug=addrman -debug=db -debug=mempool -debug=net etc.
287 2013-09-19 15:24:29 <jgarzik> I tend to prefer something like
288 2013-09-19 15:24:38 <jgarzik> -debug=net|foo|bar|baz
289 2013-09-19 15:24:42 <jgarzik> with magic -debug=all
290 2013-09-19 15:37:04 <gmaxwell> -debug=* is problematic at the shell
291 2013-09-19 15:37:05 <gmaxwell> all is what I would have naturally done.
292 2013-09-19 15:37:05 <gmaxwell> I guess not, =* won't glob.
293 2013-09-19 15:37:05 <gmaxwell> I think?
294 2013-09-19 15:37:06 <sipa> jgarzik: comma-separated list, with 'all' meaning everything
295 2013-09-19 15:37:24 <sipa> heh, was just avout to say the same as gmaxwrll
296 2013-09-19 15:37:33 <sipa> with more typos, though
297 2013-09-19 15:37:39 <gmaxwell> Can we agree that no network triggerable message should have the word "Error" in it unless we want people showing up here to ask us about it?
298 2013-09-19 15:37:56 <sipa> yep
299 2013-09-19 15:38:28 <jgarzik> gmaxwell, some of the non-standard transaction rejections are done in Deep Code, with slightly confusing/misleading error messages due to their trigger location
300 2013-09-19 15:38:56 <jgarzik> with no apparent indication that this was simply a non-standard transaction, that we chose not to relay
301 2013-09-19 15:39:28 <sipa> i'd love to see all debug.log entries start with a standard [date time module thread] prefix
302 2013-09-19 15:41:43 <gmaxwell> right, some things are "Error" when a block, but just "meh" when in a loose transaction.
303 2013-09-19 15:45:56 <sipa> perhaps all those should just be changed to use only the word 'invalid' rather than error
304 2013-09-19 15:47:18 <gmaxwell> Well right now the case that I usually want from longs is 'invalid' (e.g. invalid block)
305 2013-09-19 15:47:23 <gmaxwell> er logs. :)
306 2013-09-19 16:20:48 <Neozonz> can someone explain to me the benefits of a createrawtransactions vs the normal way of sending bitcoin?
307 2013-09-19 16:21:05 <sipa> more flexibilit
308 2013-09-19 16:21:27 <Neozonz> does it do anything in terms of transaction fees?
309 2013-09-19 16:21:40 <Cusipzzz> yes, you have the ability to include a huge txn fee :)
310 2013-09-19 16:21:44 <Scrat> you get to do nice things like send 200 btc in fees
311 2013-09-19 16:21:50 <Scrat> dammit Cusipzzz
312 2013-09-19 16:21:50 <sipa> well with raw tranactions you choose the fee yourself
313 2013-09-19 16:21:52 <Cusipzzz> Scrat: slow pony
314 2013-09-19 16:22:06 <weex> need 200 btc in fees? Use createrawtransactions(tm)!
315 2013-09-19 16:22:10 <Neozonz> can u set the fee to the lowest possible and send?
316 2013-09-19 16:22:13 <gmaxwell> Neozonz: if you're asking that question, do not use createrawtransaction.
317 2013-09-19 16:22:44 <gmaxwell> Neozonz: thats basically the default behaviorâ it uses 0 fees unless the node itself wouldn't relay/mine it.
318 2013-09-19 16:23:09 <Neozonz> I see
319 2013-09-19 16:23:33 <Neozonz> how does it decide that though, and how long would it take for the tx to be sent?
320 2013-09-19 16:24:00 <gmaxwell> Neozonz: it just assumes the peers and miners are like itself.
321 2013-09-19 16:26:29 <Neozonz> i thought it was hardcoded in the clients to not relay unless a .0001 fee was used
322 2013-09-19 16:26:38 <Neozonz> *hard coded by default
323 2013-09-19 16:26:54 <Neozonz> sorry just set by default, not hard coded
324 2013-09-19 16:27:09 <gmaxwell> Neozonz: no, thats not the case.
325 2013-09-19 16:27:28 <gmaxwell> https://en.bitcoin.it/wiki/Transaction_fees (is sometimes a bit out of date, but will give you the idea)
326 2013-09-19 16:27:45 <Neozonz> limitfreerelay 15 (thousand bytes per minute)
327 2013-09-19 16:27:45 <Neozonz> mintxfee 0.0001 (BTC)
328 2013-09-19 16:27:45 <Neozonz> paytxfee 0.0000 (BTC)
329 2013-09-19 16:28:44 <Neozonz> ah ok
330 2013-09-19 16:28:48 <Neozonz> found my answer above
331 2013-09-19 16:29:09 <Neozonz> very interesting
332 2013-09-19 16:29:54 <Neozonz> thank you very much for taking the time to explain this to me
333 2013-09-19 16:36:39 <Neozonz> is there a way to automatically select inputs for createrawtransactions?
334 2013-09-19 16:38:20 <gmaxwell> normal sendmany is what you do when you want automatic selection...
335 2013-09-19 16:38:40 <gmaxwell> Whats your application for automatic selection in a raw transaction?
336 2013-09-19 16:39:23 <Neozonz> bascially would like to create some code to add to a pool payout system
337 2013-09-19 16:39:40 <Neozonz> to sendmany to pool miners via a raw transaction and save on tx fees
338 2013-09-19 16:39:48 <Neozonz> instead of individual sends to each miner
339 2013-09-19 16:40:13 <gmaxwell> so use sendmany.
340 2013-09-19 16:40:27 <gmaxwell> thats what its for.
341 2013-09-19 16:40:45 <Neozonz> is there any difference in tx fees rather then a rawtransaction?
342 2013-09-19 16:41:13 <Neozonz> wouldn't it make more sense to createrawtx and include it into the next mined block?
343 2013-09-19 16:41:37 <sipa> i don't understand
344 2013-09-19 16:41:46 <sipa> it's just two ways of creating transactions
345 2013-09-19 16:42:55 <Neozonz> I see, I was under the impression sendmany cost more in fees verses createrawtransaction
346 2013-09-19 16:43:08 <gmaxwell> ACTION gives up
347 2013-09-19 16:43:45 <sipa> Neozonz: with createrawtransactions you can do ANYTHING
348 2013-09-19 16:43:56 <sipa> including invalid or senseless things
349 2013-09-19 16:44:13 <sipa> sendmany will give you close to optimal behaviour, with a much easier interface
350 2013-09-19 16:46:26 <Neozonz> ok thanks, I'll read some more before bother you guys
351 2013-09-19 16:53:12 <Neozonz> hmm what happens if recipient address is incorrect in sendmany- does it fail the whole transaction? or just skip the 1 address
352 2013-09-19 16:54:33 <gmaxwell> The call fails.
353 2013-09-19 16:59:03 <imsaguy> gmaxwell: never give up. You never know when your next attempt might be the successful one.
354 2013-09-19 16:59:31 <jgarzik> ok, Tony Robbins
355 2013-09-19 17:00:07 <imsaguy> :p
356 2013-09-19 17:00:30 <imsaguy> /ms luke-jr different connection method, kthnx
357 2013-09-19 17:17:40 <gmaxwell> Can someone with an OSX build setup build a 0.8.5 with the sync fix copied into it for https://github.com/bitcoin/bitcoin/issues/2770#issuecomment-24756647 ? I'd like to get him to confirm that it makes his corruption go away.
358 2013-09-19 17:18:59 <warren> gmaxwell: our mac dev has been unable to reproduce corruption ever, so we're curious what settings/hardware it took to cause it. I'll ask him to do this build.
359 2013-09-19 17:21:07 <jgarzik> gmaxwell, if somebody can produce a dmg (installable package), have a few people at BitPay that are seeing the problem, and can test
360 2013-09-19 17:21:33 <warren> jgarzik: I asked our mac dev to do it, not sure if he'll get to it first
361 2013-09-19 17:22:44 <gmaxwell> warren: I suspect it requires some disk with really agressive write caching or something.
362 2013-09-19 17:23:24 <gmaxwell> the guy on that issue can apparently reproduce at will.
363 2013-09-19 17:23:54 <sipa> we saw people reporting corruption mid-execution
364 2013-09-19 17:24:04 <sipa> which is entirely unexplainable
365 2013-09-19 17:24:08 <gmaxwell> well, that I can't explain
366 2013-09-19 17:24:32 <gmaxwell> unless it's just latent corruption
367 2013-09-19 17:26:36 <sipa> iirc one of those reports was with someone running -reindex
368 2013-09-19 17:26:42 <Luke-Jr> gmaxwell: FWIW, apparently a bitcoin user group concluded it was SSD-specific; but I also have confirmation of the problem on non-SSDs too
369 2013-09-19 17:27:10 <sipa> so the application was never even restarted between creation of the database and thr corruption
370 2013-09-19 17:27:47 <sipa> and the corruption at startup report that went away (only) after a restart is yet stranger
371 2013-09-19 17:27:58 <gmaxwell> One problem is that there probably are a couple people with just bad ram or overheating or radioactive underpants. So you can't determine anything from single reports.
372 2013-09-19 17:28:21 <warren> could that be conflated with the neg tx version issue?
373 2013-09-19 17:28:30 <warren> (at that moment at least)
374 2013-09-19 17:28:39 <gmaxwell> warren: no, there were none of those at that time.
375 2013-09-19 19:07:37 <rus> where is litecoin dev support for getwork and related protocol stuff?
376 2013-09-19 19:08:14 <gmaxwell> #litecoin is where litecoin stuff is.
377 2013-09-19 19:12:23 <rus> thiers no help there
378 2013-09-19 19:12:46 <rus> just a bunch of wiseguys
379 2013-09-19 19:13:10 <rus> is bitcoin and litecoin getwork share send the same? like the data param
380 2013-09-19 19:13:27 <sipa> getwork is utterly deprecated
381 2013-09-19 19:13:38 <sipa> but i suppose it works similarly in litecoin
382 2013-09-19 19:15:54 <warren> rus: stop bothering the bitcoin devs, I told you minutes earlier that you are insane implementing this when many other miners exist, getwork will be removed in the near future, and implementing miners is not a dev issue and you will not get help.
383 2013-09-19 19:16:13 <warren> rus: it is not clear why you have been asking for days, just stop.
384 2013-09-19 19:16:51 <phantomcircuit> sipa, i use getwork, gotta give people the X-Stratum header somehow
385 2013-09-19 19:23:56 <rus> huh?
386 2013-09-19 19:24:31 <rus> i just want some clarification on what you send back that counts as a share how to format it
387 2013-09-19 19:26:24 <rus> wether that be getwork or something else like stratum
388 2013-09-19 19:26:44 <rus> warrens troll level up. next stage: uber
389 2013-09-19 19:32:33 <BlueMatt> gmaxwell: coverage reports are still generated afaik, and the test script that builds+tests still returns a different value if test coverage went down, it just no longer uses that info in the comments
390 2013-09-19 19:32:43 <BlueMatt> gmaxwell: actually, I think autotools broke all of that, but thats how it was before autotools
391 2013-09-19 19:33:22 <BlueMatt> jgarzik: no, pull tester doesnt do any bitcoind log-scanning
392 2013-09-19 19:33:43 <sipa> it just seems to timeout now
393 2013-09-19 19:33:54 <BlueMatt> yea, other issue
394 2013-09-19 19:35:43 <BlueMatt> sipa: did I ever give you a jar of the bitcoindcomparisontool that "supports" getheaders?
395 2013-09-19 19:36:30 <BlueMatt> gmaxwell: yea, it seems /all/ of the coverage-related code has been inexplicably removed from the scripts in the autotools versions
396 2013-09-19 19:36:37 <Luke-Jr> warren: (bitcoin) mining software dev is still on-topic :P
397 2013-09-19 19:36:38 <BlueMatt> aside from generating the reports themselves
398 2013-09-19 19:36:46 <Luke-Jr> phantomcircuit: X-Stratum isn't necessary :p
399 2013-09-19 19:36:55 <sipa> BlueMatt: you gave me a link to a jar that did some getheaders
400 2013-09-19 19:37:05 <BlueMatt> did I put it on github?
401 2013-09-19 19:37:10 <sipa> BlueMatt: but it didn't give all headers requested or something
402 2013-09-19 19:37:17 <sipa> no clue
403 2013-09-19 19:37:21 <BlueMatt> yea, I just wondered if I had generated a jar of that version
404 2013-09-19 19:37:27 <BlueMatt> oh, I did, sorry
405 2013-09-19 19:37:51 <cfields> BlueMatt: pull-tester does scan logs
406 2013-09-19 19:37:57 <cfields> all the coverage stuff was moved into autotools
407 2013-09-19 19:38:07 <BlueMatt> cfields: since when?
408 2013-09-19 19:38:13 <BlueMatt> oh, yea, it does to see if the logs exist
409 2013-09-19 19:38:17 <BlueMatt> but not actually analyze them
410 2013-09-19 19:38:22 <BlueMatt> cfields: (and removed)
411 2013-09-19 19:38:39 <cfields> hmm?
412 2013-09-19 19:38:40 <BlueMatt> cfields: there was code which checked coverage values compared to previous values, but that appears to be entirely missing
413 2013-09-19 19:38:52 <sipa> BlueMatt: do you have 'full' getheaders now, or you just didn't know where you put what you had? :p
414 2013-09-19 19:39:02 <cfields> correct, that part wasn't moved in. it just generates
415 2013-09-19 19:39:27 <BlueMatt> in fact, it looks like the scripts wont pass the proper return values up to the python script manager, where it still has code for creating the comments for it
416 2013-09-19 19:39:38 <BlueMatt> cfields: well, someone needs to readd that to get coverage :p
417 2013-09-19 19:39:57 <BlueMatt> sipa: yea, somehow the jar on jenkins is broken so I wondered if I had a jar of the latest version (even though it doesnt work with getheaders)
418 2013-09-19 19:40:45 <cfields> BlueMatt: it just needs to be added on the pull-tester side to keep the logs
419 2013-09-19 19:41:15 <BlueMatt> what? no, the code for coverage analysis was in the build-script.sh, where did it go?
420 2013-09-19 19:41:32 <BlueMatt> (and should be there, the pull-tester pythong script should be as minimal as possible)
421 2013-09-19 19:42:16 <cfields> BlueMatt: the build scripts were moved into git so that everyone can run it locally. coverage is run via 'make cov'
422 2013-09-19 19:42:54 <cfields> but saving and comparing is beyond the scope of that, they need to be done in the server-side scripts
423 2013-09-19 19:43:13 <BlueMatt> which are stored in qa/pull-tester
424 2013-09-19 19:43:14 <BlueMatt> ?
425 2013-09-19 19:43:45 <cfields> BlueMatt: yes. but pull-tester can only run one script. it has no idea where the results of the last run are, for comparison
426 2013-09-19 19:43:48 <BlueMatt> if nothing else, pull-tester.sh can do it since it only runs on pull-tester and not locally, no?
427 2013-09-19 19:43:53 <cfields> so the comparison can't be added there
428 2013-09-19 19:44:23 <BlueMatt> yes it does, it git checkout master first, and then git checkout $COMMIT
429 2013-09-19 19:44:45 <cfields> BlueMatt: https://github.com/bitcoin/bitcoin/blob/master/qa/pull-tester/pull-tester.sh
430 2013-09-19 19:44:52 <BlueMatt> oh, actually, no, it has the coverage percent but its in a static dir
431 2013-09-19 19:44:54 <BlueMatt> where its always been
432 2013-09-19 19:45:12 <BlueMatt> https://github.com/TheBlueMatt/test-scripts/blob/master/build-script.sh <-- old version of the old script
433 2013-09-19 19:45:53 <cfields> BlueMatt: understood. almost all of that behavior was moved in-repo in the form of pull-tester.sh
434 2013-09-19 19:46:16 <cfields> but what i'm trying to say is that pull-tester.sh has no concept of "this run" vs "last run", and it can't
435 2013-09-19 19:46:28 <cfields> so the responsibility of comparing results falls to the caller of that script
436 2013-09-19 19:46:42 <BlueMatt> yea, but it has a concept of "master test coverage is in dir $DIR"
437 2013-09-19 19:46:56 <BlueMatt> so it can compare and return based on that
438 2013-09-19 19:47:05 <BlueMatt> and then people who get false positives can fix it themselves :p
439 2013-09-19 19:47:43 <cfields> but there's nothing to compare it to. you have the results of this run. but each run is an island.
440 2013-09-19 19:48:13 <BlueMatt> no, because the data from master, ie what you should compare to, is available
441 2013-09-19 19:48:21 <BlueMatt> see how the old script does it
442 2013-09-19 19:48:46 <BlueMatt> assuming gavin didnt break the run side, the test coverage of master is in /mnt/test-scripts/coverage_percent.txt at runtime
443 2013-09-19 19:49:02 <cfields> BlueMatt: please read that script. there's no concept of revisions. it just launches the build tests, nothing more.
444 2013-09-19 19:49:13 <BlueMatt> yes, same with the old one......
445 2013-09-19 19:49:13 <cfields> if there's more functionality needed, it needs to be added on the side of the caller
446 2013-09-19 19:49:22 <BlueMatt> it doesnt need to know anything about revisions
447 2013-09-19 19:49:49 <BlueMatt> the caller currently provides the coverage on master which that script should compare itself to and then return that comparison
448 2013-09-19 19:52:22 <BlueMatt> well, ok, screw it, it looks like gavin removed all of the coverage code on the calling side too, so...to answer gmaxwell's question from earlier - the status of the coverage stuff is that with the autotools merge, all coverage analysis code was removed except for just generating the reports
449 2013-09-19 19:53:16 <cfields> BlueMatt: that's counter-intuitive to me as it requires either hard-coded previous results, or passing results around. the only reasonable way to accomplish is for the test to return its coverage, and the caller to compare with a control
450 2013-09-19 19:53:30 <cfields> but i'll let you and gavin hash it out
451 2013-09-19 19:54:09 <gmaxwell> I tried running the reports multiple times here and they looked stable.
452 2013-09-19 19:54:10 <BlueMatt> cfields: well, yes, that seems more intuitive, however the calling side used to be "proprietary" code (it had user/pass combos hardcoded) so I tried to keep everything out of that code
453 2013-09-19 19:54:26 <BlueMatt> now gavin wants to upload that code (has he) so he's pulled it out so...its up to y'all
454 2013-09-19 19:54:57 <BlueMatt> gmaxwell: the version on jenkins is a bit out-of-date, though it was latest at the time I tried the coverage stuff the first time
455 2013-09-19 19:55:14 <cfields> BlueMatt: i don't think he "pulled it out" so much as everything was moved into git, but the comparison functionality hasn't been re-added yet
456 2013-09-19 19:55:52 <BlueMatt> ;;later tell gavinandresen re: pull-tester broken due to jar broken: I haven't touched it, and it should be updated anyway, Im not sure which copy is the one being run, but if you grab the one from https://github.com/TheBlueMatt/test-scripts and use that, it should work
457 2013-09-19 19:55:52 <gribble> The operation succeeded.
458 2013-09-19 19:56:45 <BlueMatt> cfields: no, it was present on both the calling side script (which has now been removed) and in the build-script.sh script which forms the basis for the qa/pull-tester/* scripts
459 2013-09-19 19:56:49 <BlueMatt> so...Id call that removed
460 2013-09-19 19:56:54 <BlueMatt> even if justified
461 2013-09-19 19:57:14 <cfields> ok
462 2013-09-19 19:58:00 <cfields> BlueMatt: is there sensitive info in the calling script?
463 2013-09-19 19:58:09 <BlueMatt> used to be, not anymore
464 2013-09-19 19:58:17 <BlueMatt> gavin removed it so he can put that script somewhere in git
465 2013-09-19 19:58:20 <BlueMatt> not sure if he has yet
466 2013-09-19 19:58:21 <cfields> ok, then why not add that in-repo as well?
467 2013-09-19 19:58:31 <cfields> heh, asked and answered :)
468 2013-09-19 19:58:41 <BlueMatt> I dunno where he's gonna put it
469 2013-09-19 20:38:01 <jgarzik> hum, I don't think I can trick createrawtransaction into creating a pubkey (not pubkeyhash) output, can I?
470 2013-09-19 20:38:22 <jgarzik> maybe if I give it a pubkey instead of an address...
471 2013-09-19 20:38:23 <gmaxwell> jgarzik: pretty easy to just edit the script by hand. :P
472 2013-09-19 20:38:43 <gmaxwell> (but dangerous!)
473 2013-09-19 20:39:01 <jgarzik> everything I do is dangerous. comes with the territory.
474 2013-09-19 20:39:13 <jgarzik> ACTION is precisely <this> dangerous
475 2013-09-19 20:39:16 <jgarzik> on testnet
476 2013-09-19 20:40:09 <cfields> heh
477 2013-09-19 20:40:42 <cfields> jgarzik: you ever go to the meetups at gordon biersch?
478 2013-09-19 20:41:27 <cfields> i live in atlanta, thinking of going next week
479 2013-09-19 20:41:33 <jgarzik> cfields, I have no idea what that means
480 2013-09-19 20:41:52 <jgarzik> cfields, there was a bitcoin meetup in the BitPay building (ATV), a couple months back
481 2013-09-19 20:42:16 <cfields> heh, i suppose that answers my question
482 2013-09-19 20:42:20 <cfields> jgarzik: http://www.meetup.com/Bitcoin-Atlanta/events/137378722/
483 2013-09-19 20:42:55 <jgarzik> cfields, I should
484 2013-09-19 20:42:56 <cfields> a few of the bitpay names on that list, figured you might show now and then
485 2013-09-19 20:43:07 <jgarzik> yeah, several BP peeps always show up
486 2013-09-19 20:44:02 <jgarzik> unfortunately with two little kids to get down every night, Going Out often requires a Special Exception
487 2013-09-19 20:44:30 <cfields> heh
488 2013-09-19 20:46:34 <cfields> understood. I think i'll drop in to see what it's about. i'll consider it a bonus if you're pardoned for the night
489 2013-09-19 20:47:39 <jgarzik> ACTION wonders if he could wear the 3yr old as a shoulder drape, at a bar
490 2013-09-19 20:47:49 <jgarzik> just drape her over one shoulder, and let her sleep
491 2013-09-19 20:48:57 <cfields> jgarzik: up here in woodstock/canton, an accessorial child is nearly a requirement in bars/liquor stores
492 2013-09-19 20:50:37 <jgarzik> the wifey occasionally wears, using a front-pack, the 8 month old to social outings
493 2013-09-19 20:50:46 <jgarzik> no wine has been spilled on the baby yet
494 2013-09-19 20:51:40 <cfields> i'm pretty sure there's a good 'first communion' joke there...
495 2013-09-19 21:11:47 <jgarzik> the nice thing about testnet debugging: screw change, just pick a random unspent input
496 2013-09-19 22:29:52 <gavinandresen> howdy y'all
497 2013-09-19 22:30:16 <Luke-Jr> hello
498 2013-09-19 22:45:08 <gavinandresen> BlueMatt cfields: FYI working on pull-tester
499 2013-09-19 22:46:00 <gavinandresen> cfields: gitian-built windows dependencies should be set, my goal this morning is to get pull-tester working again and then turn on Windows builds again.
500 2013-09-19 22:46:07 <cfields> gavinandresen: great. BlueMatt and I were discussing the possibility of having it in-repo earlier. Think that's a possibility?
501 2013-09-19 22:46:56 <gavinandresen> cfields: "it" being the pull-tester.py master script? SUre, I'll commit it now.
502 2013-09-19 22:47:02 <cfields> -redundant
503 2013-09-19 22:47:29 <cfields> great, thanks
504 2013-09-19 22:47:34 <gavinandresen> ⦠but there is a chicken-and-egg problem on running it, so it will still require manual poking when it is updated
505 2013-09-19 22:50:02 <gavinandresen> cfields: pushed qa/pull-tester/pull-tester.py
506 2013-09-19 22:52:21 <gavinandresen> BlueMatt: I'm getting Exception in thread "NioClientManager" java.lang.NoSuchMethodError: java.nio.channels.SocketChannel.getRemoteAddress()Ljava/net/SocketAddress;
507 2013-09-19 22:52:38 <gavinandresen> BlueMatt: what version of java needs to be on the pull-tester to run the .jar ?
508 2013-09-19 22:52:52 <sipa> gavinandresen: i got an error with 6, installed 7, and it worked
509 2013-09-19 22:53:16 <gavinandresen> ok, new question: how do I install java7 on Ubuntu 10.04 LTS ?
510 2013-09-19 22:53:27 <cfields> gavinandresen: unsure if related, the previous pull-tester script did a LD_PRELOAD of a java dylib
511 2013-09-19 22:53:54 <sipa> sudo aptitude install openjdk-7-jre
512 2013-09-19 22:54:09 <gavinandresen> sipa: thanks!
513 2013-09-19 22:55:28 <gavinandresen> ok, even newer question: what do I put in my sources.list so apt-get can find openjdk-7-jre?
514 2013-09-19 22:56:11 <sipa> hmm, maybe it's just too old
515 2013-09-19 22:56:37 <gavinandresen> sigh
516 2013-09-19 22:56:59 <sipa> http://stackoverflow.com/questions/15197578/open-jdk-7-for-ubuntu-10-04-from-quantal-repo
517 2013-09-19 22:57:18 <sipa> why 10.04?
518 2013-09-19 22:57:32 <sipa> or does this run inside gitian?
519 2013-09-19 22:59:40 <gavinandresen> 10.04 because I dont' want to spend all day upgrading to 12 â¦.
520 2013-09-19 22:59:47 <sipa> haha
521 2013-09-19 23:00:19 <gavinandresen> ⦠although maybe it is time to do that. I'm just afraid of breaking the jenkins nightly build tester or something else I dont' know about
522 2013-09-19 23:00:52 <sipa> can you like make a backup of the VM?
523 2013-09-19 23:01:10 <gavinandresen> that is probably easy if you know how.
524 2013-09-19 23:01:25 <cfields> gavinandresen: fwiw, i run it fine locally on rarring.
525 2013-09-19 23:01:36 <gavinandresen> rarring?
526 2013-09-19 23:01:42 <cfields> though the .py hasn't been in the loop yet. I can test starting from there
527 2013-09-19 23:01:48 <sipa> gavinandresen: 13.04
528 2013-09-19 23:01:51 <cfields> 13.04
529 2013-09-19 23:01:58 <sipa> (raring)
530 2013-09-19 23:02:16 <sipa> gavinandresen: what kind of virtualization is that?
531 2013-09-19 23:02:18 <cfields> bah, i always spell that wrong. I really thought i had it this time!
532 2013-09-19 23:02:40 <gavinandresen> sipa: lookingâ¦
533 2013-09-19 23:02:57 <gavinandresen> sipa: proxmox
534 2013-09-19 23:03:14 <sipa> hmm, never heard about that
535 2013-09-19 23:11:39 <hydromet> while Bitcoin-Qt is running, does the wallet (wallet.dat) file always need to be made available to it even if there are no transactions taking place?
536 2013-09-19 23:12:22 <gmaxwell> yes.
537 2013-09-19 23:12:31 <Luke-Jr> hydromet: it's not just any file, it's a database, and it's open. so yes.
538 2013-09-19 23:12:46 <hydromet> for example I noticed my wallet.dat file gets touched (and its time/date stamp changes on OS X) when Bitcoin-Qt first runs (after not having run it for a day or so) and then it gets touched again when network synchronization is completed
539 2013-09-19 23:12:47 <gmaxwell> it's still watching for transaction in any case.
540 2013-09-19 23:13:06 <gmaxwell> it's updating the height to which it has been synchronized.
541 2013-09-19 23:13:19 <gavinandresen> okey dokey, backing up the jenkins VM (turns out it is mostly easy if you know how)
542 2013-09-19 23:13:22 <hydromet> gmaxwell: "height"?
543 2013-09-19 23:13:45 <Luke-Jr> sipa: Proxmox is a distro with a varity of VM technologies
544 2013-09-19 23:13:46 <gavinandresen> ⦠then I'll upgrade it
545 2013-09-19 23:13:54 <hydromet> hello gavinandresen: how are you, how's your Mac and how is Australia these days?
546 2013-09-19 23:14:08 <gmaxwell> hydromet: blockchain height.
547 2013-09-19 23:14:33 <hydromet> gmaxwell: thanks for the clarification
548 2013-09-19 23:14:35 <sipa> hydromet: up to which point it is synchronized with the blockchain
549 2013-09-19 23:14:51 <sipa> hydromet: so at next startup, it knows it doesn't have to rescan everything again
550 2013-09-19 23:15:24 <hydromet> sipa: is the need to have the wallet database file open unique to Bitcoin-Qt or likely any wallet app (e.g., Alan's Armoury - which I haven't tried out)
551 2013-09-19 23:16:09 <gmaxwell> hydromet: what problem are you trying to solve?
552 2013-09-19 23:16:15 <gavinandresen> hydromet: questions like that annoy usâ¦.
553 2013-09-19 23:16:15 <Luke-Jr> hydromet: it's not necessary, but it's probably not unique either
554 2013-09-19 23:16:43 <gavinandresen> (the "does it have to work this way" question, not the how am I question-- I'm fine, thanks for asking)
555 2013-09-19 23:17:03 <gmaxwell> I think it's nessary to avoid unneeded rescanning or caring around ginormous indexes.
556 2013-09-19 23:17:25 <sipa> well if wallets were dynamically loadable, that requirement wouldn't be there
557 2013-09-19 23:17:30 <gmaxwell> Well I dunno about annoyed, but when questioning follows that path I start to worry that the asker has some odd goal that has nothing to do with the questions
558 2013-09-19 23:17:30 <hydromet> gavinandresen: oh, sorry about that, I was jut being social because I really appreciated your assistance in getting Bitcoin-Qt to compile from master with autotools several days ago
559 2013-09-19 23:17:56 <gmaxwell> E.g. a misunderstanding of backup requirements might result in these questions.
560 2013-09-19 23:18:06 <gmaxwell> Or a misunderstanding of wallet encryption.
561 2013-09-19 23:18:58 <hydromet> gmaxwell: a friend of mine who I am helping out with Bitcoin-Qt wants to keep his wallet.dat file on a secure USB thumb drive and only available to his Mac when its absolutely necessary. My friend (who is not very technical) is paranoid of hackers getting access to his wallet.dat file.
562 2013-09-19 23:19:18 <Luke-Jr> hydromet: so don't leave Bitcoin-Qt running?
563 2013-09-19 23:19:24 <gmaxwell> ^ what I was typing.
564 2013-09-19 23:19:25 <sipa> or encrypt the wallet
565 2013-09-19 23:19:32 <gmaxwell> ^ do both.
566 2013-09-19 23:19:43 <hydromet> sipa: his wallet is encrypted, but he's still paranoid
567 2013-09-19 23:20:14 <gmaxwell> Which is fine, but I'm not sure what the goal in leaving bitcoin-qt running without the wallet would be. I suppose to reduce startup time?
568 2013-09-19 23:20:29 <hydromet> sipa: he is retired but used to work in finance (but crypto currencies are brand new territory for him)
569 2013-09-19 23:20:40 <Luke-Jr> hydromet: Armory supports read-only wallets
570 2013-09-19 23:21:55 <gmaxwell> Luke-Jr: you mean the watching wallet functionality.
571 2013-09-19 23:22:02 <hydromet> gavinandresen: no odd goals or motives here ... just expressing my appreciation for the help with MacPorts etc.
572 2013-09-19 23:22:05 <gmaxwell> I don't know if that makes the behavior readonly on the files.
573 2013-09-19 23:22:15 <cfields> gavinandresen: time to consider updating gitian and deps as well, then?
574 2013-09-19 23:22:18 <Luke-Jr> gmaxwell: well, the files aren't readonly, the wallet is :P
575 2013-09-19 23:22:44 <Luke-Jr> gmaxwell: I'm not sure if Armory even needs to use files in this case - it supports that mnemonic stuff
576 2013-09-19 23:23:08 <gmaxwell> Luke-Jr: dunno, it keeps those ginormous in memory indexes, so it may not.
577 2013-09-19 23:23:29 <gmaxwell> but I'm not sure if the latest version which will get rid of the ginormous in memory indexes will change that.
578 2013-09-19 23:23:52 <gavinandresen> If your friend is not very technical then he should probably use MultiBit, not Bitcoin-Qt. And keep most of his funds in paper wallets.
579 2013-09-19 23:24:12 <Luke-Jr> does Multibit support paper wallets? :o
580 2013-09-19 23:24:49 <sipa> gmaxwell: 600k $ must be able to do something :)
581 2013-09-19 23:25:18 <gavinandresen> Luke-Jr: I don't know if MultiBit can directly create paper wallets...
582 2013-09-19 23:25:22 <Luke-Jr> sipa: $600k gets time, but the time still needs to pass :P
583 2013-09-19 23:26:18 <hydromet> gavinandresen: thanks I'll mention MultiBit to him ... he said he prefers Bitcoin-Qt because its from the foundation
584 2013-09-19 23:26:37 <sipa> technically... not really
585 2013-09-19 23:26:45 <Luke-Jr> hydromet: the Foundation doesn't do software development, they just sponsor it
586 2013-09-19 23:26:47 <sipa> though the foundation funds gavin's time
587 2013-09-19 23:27:08 <hydromet> Luke-Jr: oh, that's good to know, I hadn't realized that
588 2013-09-19 23:27:10 <Luke-Jr> hydromet: which includes (in theory anyway) other clients
589 2013-09-19 23:27:11 <Scrat> hydromet: tell him that he should prefer it because it's helping the network
590 2013-09-19 23:27:12 <gavinandresen> ⦠and they are the legal owners of the code-signing keys for windows/mac
591 2013-09-19 23:27:25 <sipa> oh, really?
592 2013-09-19 23:28:07 <gavinandresen> sipa: yes. There is no "The Bitcoin Developers" to own it, and certificate authorities REALLY want to call Somebody In Charge to issue certificates
593 2013-09-19 23:28:12 <sipa> right
594 2013-09-19 23:28:18 <Luke-Jr> gavinandresen: "Gavin Andresen"?
595 2013-09-19 23:28:24 <gavinandresen> NACK
596 2013-09-19 23:28:26 <hydromet> Scrat: prefer Bitcoin-Qt or MultiBit?
597 2013-09-19 23:29:16 <gavinandresen> â¦. proxmox is 33% done backing up the jenkins machine⦠sigh, this will take all day....
598 2013-09-19 23:30:25 <gavinandresen> latest stable ubuntu is "raring" ?
599 2013-09-19 23:30:37 <sipa> yes
600 2013-09-19 23:30:51 <gavinandresen> and will I be sad if I upgrade to raring instead of the-q-one ?
601 2013-09-19 23:31:11 <sipa> quantal?
602 2013-09-19 23:31:16 <sipa> raring works fine for me
603 2013-09-19 23:31:34 <Luke-Jr> err
604 2013-09-19 23:31:41 <Luke-Jr> raring isn't LTS
605 2013-09-19 23:31:48 <Luke-Jr> which means it's deprecated in January
606 2013-09-19 23:31:58 <Luke-Jr> precise is supported until April 2017
607 2013-09-19 23:32:24 <Scrat> hydromet: Bitcoin-Qt. MultiBit is an SPV client and thus not a full node
608 2013-09-19 23:32:34 <Luke-Jr> http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Table_of_versions
609 2013-09-19 23:33:16 <Luke-Jr> probably don't want to have to upgrade gitian every 6 months IMO
610 2013-09-19 23:33:16 <sipa> 14.04 will be LTS again
611 2013-09-19 23:33:30 <sipa> upgrading gitian to 12.04 is fine be me
612 2013-09-19 23:33:37 <gavinandresen> this is the pull-tester machine, not gitian
613 2013-09-19 23:33:47 <Luke-Jr> oh ok
614 2013-09-19 23:33:53 <sipa> 12.04 should be fine for pulltester
615 2013-09-19 23:34:05 <gavinandresen> ok. Java 7 is available for 12.04?