1 2014-04-06 00:00:11 <BCB> sipa what is it?
2 2014-04-06 00:00:42 <sipa> BCB: THE F*CKING TRANSACTIONS
3 2014-04-06 00:01:05 <sipa> a block is a header with a list of transactions after it
4 2014-04-06 00:01:22 <uiop> BCB: as in "struct {....; size_t n; xxx_t x[n];}"
5 2014-04-06 00:01:40 <uiop> if you could do that in C
6 2014-04-06 00:02:15 <uiop> (you can of course do "...xxx_t x[];}")
7 2014-04-06 00:02:38 <sipa> please do your homework and read until you understand the purpose of blocks and transactions in bitcoin
8 2014-04-06 00:02:51 <BCB> ok thanks
9 2014-04-06 00:07:57 <uiop> BCB: the byte you read as txns (txns=01) is just the first 8 bits of the first transaction in the list of nine (tx_count=09)
10 2014-04-06 00:09:08 <uiop> i'm not sure at what level would be helpful for you, but that's the explicit explanation for what you've done
11 2014-04-06 00:09:56 <BCB> uiop, very help full
12 2014-04-06 00:10:15 <BCB> checking now. I just have two byte that are confusing me
13 2014-04-06 00:10:16 <BCB> 0901
14 2014-04-06 00:10:23 <BCB> (off the wire)
15 2014-04-06 00:10:45 <BCB> reading from memory
16 2014-04-06 00:11:09 <uiop> transactions are variable-length as well, on account of the script
17 2014-04-06 00:11:34 <BCB> uiop yes I'm aware
18 2014-04-06 00:11:54 <andyleap> has anyone done hardware wallet stuff on something like an arduino?
19 2014-04-06 00:12:59 <BCB> uiop, mind a pm. I don't want to piss anyone else off
20 2014-04-06 00:13:34 <uiop> so you have move forward hopping between the embedded length fields. on some level the exact same reason don't know how many bytes into a utf8-encoded string the "10th character" is
21 2014-04-06 01:59:03 <vetch> andyleap: if there's a way of locking the things against reprogramming over usb, then I guess there's not a heap stopping you. no source of good entropy means you need to source that manually, externally for the initial setup I would imagine.
22 2014-04-06 01:59:54 <andyleap> found a library where someone had managed to do random off of jitter from watchdog timer
23 2014-04-06 02:00:56 <andyleap> generated 400 mb of random data over a couple months or so, and tested, and it looked like relatively high quality random
24 2014-04-06 02:01:41 <andyleap> tested in 10mb chunks, so I think that's decent, at least for signing transactions
25 2014-04-06 02:04:20 <andyleap> it's just fun, cause I didn't know anything about cryptography until yesterday(other then the basics of public/private and one way functions)
26 2014-04-06 02:04:35 <andyleap> and I haven't found any code for an arduino so far
27 2014-04-06 02:04:52 <BCB> have some great documentation: https://github.com/conformal/btcwire/blob/master/msgblock_test.go#L511-L550
28 2014-04-06 02:04:52 <BCB> sipa, Luke-Jr Figured it out. I had my tnx count and txn bytes confused. They guys at btc have at irc.conformal.com:6697 #btcd
29 2014-04-06 02:05:03 <BCB> *btcd
30 2014-04-06 02:05:19 <Luke-Jr> we only told you that like 4208942 times
31 2014-04-06 02:05:40 <BCB> Luke-Jr, clearly it was not effective
32 2014-04-06 02:06:28 <vetch> andyleap: there's absolutely no way you should be using that for a cryptographic purpose. signing doesn't necessarily need any random input anyway, there's ways for it to be deterministic but still secure.
33 2014-04-06 02:07:21 <vetch> private key generation absolutely needs random input though, be it straight random numbers or a generated bip32 seed.
34 2014-04-06 02:08:08 <andyleap> yeah, was planning on it being a "load only" wallet
35 2014-04-06 02:08:29 <andyleap> so you generate the key on an offline desktop or something, then load it into the wallet
36 2014-04-06 02:08:35 <andyleap> and it can go from there
37 2014-04-06 02:10:48 <andyleap> like I said, I'm still learning about the cryptography involved
38 2014-04-06 02:12:42 <vetch> bitcoin probably isn't that place to learn basic crypto concepts. mistakes are literally expensive here.
39 2014-04-06 02:14:18 <andyleap> well, I have no bitcoins, and it seems that bitcoin and related currencys use crypto in different ways then most other crypto
40 2014-04-06 02:14:40 <andyleap> i.e. most usages of crypto don't involve a forthlike scripting language, that I know of
41 2014-04-06 02:15:09 <andyleap> I understand crypto, I'm just getting into the actual math and bitcoins implementation of crypto
42 2014-04-06 02:16:11 <vetch> the scripting language isn't really crypto in that sense. its fairly easy to get your head around once you have the basics. I was more talking about the EC parts, where things get complicated.
43 2014-04-06 02:16:44 <andyleap> yeah, the EC stuff isn't actually that complex
44 2014-04-06 02:16:44 <vetch> I would be shocked if there's a usable EC library for whatever micro the arduino uses.
45 2014-04-06 02:17:27 <andyleap> I'm not exactly new to programming, so the biggest complexity was more "how the crap did they come up with this?"
46 2014-04-06 02:19:14 <Zarutian> andyleap: eliptic curve crypto or the idea behind bitcoin in general?
47 2014-04-06 02:19:45 <andyleap> a little of both
48 2014-04-06 02:20:14 <gmaxwell> andyleap: Bitcoin (and its clones) is the only deployment of a programable signature system, though there has been writing about this stuff for eons.
49 2014-04-06 02:20:41 <gmaxwell> (there is even far out theoretical work on making _encryption_ work with script like conditions on the keys)
50 2014-04-06 02:21:02 <andyleap> some of the operations in EC are a little "I'll take your word on that", like the whole EC double thing, it seems a little wack compared to the standard point add
51 2014-04-06 02:21:09 <vetch> andyleap: ask blockchain.info how you can screw up an otherwise happily functional EC signature system and reveal people's private keys.
52 2014-04-06 02:21:48 <Zarutian> ACTION is just glad that satoshi didnt go with SHA512 lamport signitures.
53 2014-04-06 02:22:03 <gmaxwell> andyleap: some curves don't need a special defintion of doubling (e.g. ones without a constant in the curve equation). But all this arises out of a pretty standard geometric law for addition.
54 2014-04-06 02:22:36 <vetch> andyleap: implementation details, like you can't use web workers in Firefox to sign transactions because they all are spawned with the RNG state. not strictly related to the conversation, but too hilarious not to mention.
55 2014-04-06 02:22:54 <gmaxwell> vetch: well they were warned that their code there was unsafe long ago. ::shrugs:: DSA is a bit brittle in general though but thats DSA's fault.
56 2014-04-06 02:23:27 <Zarutian> oh, I recall that Sony Playstation debacle regarding DSA
57 2014-04-06 02:23:41 <gmaxwell> vetch: it's actually even worse than that, it was using window.crypto which just doesn't exist in web workers (no dom access) but it was wrapped with a try block that replaced it with math.random if the window.crypto failed! (the crazyness of doing that is what they'd been warned about)
58 2014-04-06 02:23:58 <vetch> Zarutian: they were even worse, used a static value for ALL signatures intentionally.
59 2014-04-06 02:24:11 <gmaxwell> they just didn't know that you couldn't do that. (doh)
60 2014-04-06 02:24:16 <gmaxwell> (presumably)
61 2014-04-06 02:24:34 <olalonde> hmmm I did "brew link openssl --force" but "openssl version" returns "OpenSSL 0.9.8y 5 Feb 2013"
62 2014-04-06 02:24:36 <gmaxwell> one thing about security bugs in general is that the fault is usually completely invisble until someone goes and exploits it.
63 2014-04-06 02:24:45 <vetch> gmaxwell: wait what. the worlds most secure web wallet signs transactions with math.random?
64 2014-04-06 02:24:59 <vetch> that's hysterical!
65 2014-04-06 02:25:18 <archrs> rule 1 of quantatative risk analysis: never underestimate human stupidity/genius
66 2014-04-06 02:25:18 <gmaxwell> vetch: it did when the secure rng wasn't failed... which normally never happened, ... until they moved the signing into a web worker.
67 2014-04-06 02:25:30 <gmaxwell> vetch: "don't use web wallets" is in the topic for many reasons.
68 2014-04-06 02:26:11 <Zarutian> ACTION has a whole gouard filled with bitterness regarding web 'security'
69 2014-04-06 02:26:13 <gmaxwell> One of them being that no one who authors a web wallet is competent, because competent people give up at the hopelessness of being secure against script substitution.
70 2014-04-06 02:26:33 <gmaxwell> crap this is #bitcoin-dev and not #bitcoin, we're kinda OT.
71 2014-04-06 02:26:36 <vetch> gmaxwell: that's gnarly. remind me why people trust that service to store millions of dollars?
72 2014-04-06 02:27:28 <archrs> because they can, vetch
73 2014-04-06 02:27:29 <Zarutian> gmaxwell: well the discussion is half on topic, half off.
74 2014-04-06 02:27:33 <gmaxwell> (to be fair the green address people are trying really hard to do better and are learning fast). In any case, security is a lemon market.
75 2014-04-06 02:28:09 <Zarutian> ACTION was going to mention a certain party but doesnt.
76 2014-04-06 02:28:29 <olalonde> seems it linked /usr/local/bin/openssl but not /usr/bin/openssl .. interesting
77 2014-04-06 02:28:39 <gmaxwell> Zarutian: really even the technical stuff in this discussion belongs in #bitcoin this channel is for _production_ discussion regarding the network and reference client. It's not for bitcoin technology musing or tech support, or whining about insecure bitcoin services.
78 2014-04-06 02:29:21 <vetch> gmaxwell: I was (again off topic) talking to the developer of greenwallet.it earlier. not thoroughly convinced but better than the alternatives available presently.
79 2014-04-06 02:29:26 <gmaxwell> (as much as I also like to join in those things. Basically the channel should be run in such a way that alt. implementors and engineers at bitcoin services find it worth their time to read or at least skim the backscroll)
80 2014-04-06 02:29:42 <vetch> to #bitcoin with this.
81 2014-04-06 02:39:17 <kuzetsa> 53 connections (about the same) but with a longer averaging period it looks like the average outbound bandwith is more than 30% lower at 1.15 mbit/s & the peak bandwidth spikes still hasn't exceeded 5.32 mbit/s so like... I guess I just never realized how intense running a "full node" with bitcoin-core was & it's probably been this bandwidth intensive all along?
82 2014-04-06 02:40:58 <kuzetsa> gmaxwell, phantomcircuit: thanks for the input earlier
83 2014-04-06 02:41:34 <kuzetsa> also, I confirmed my ntp server isn't vulnerable & usable for the reflection attacks, so that bandwidth really is mostly from bitcoind :(
84 2014-04-06 02:44:43 <vetch> kuzetsa: really depends who your peers are. you might get new nodes requesting blocks all day, or an spv client that cranks up the bloom filters and burns your CPU. luck of the draw.
85 2014-04-06 02:46:59 <kuzetsa> uhg :(
86 2014-04-06 02:47:47 <kuzetsa> vetch: allright then, thanks... I guess it was unreasonable to expect I could run it on the same relatively modest hardware I was using in 2012
87 2014-04-06 02:48:18 <vetch> kuzetsa: $5 a month on digitalocean will probably be enough for you to run a full node and never worry about bandwidth.
88 2014-04-06 02:48:33 <kuzetsa> hmm
89 2014-04-06 02:49:38 <kazcw> there's also -maxconnections
90 2014-04-06 02:49:48 <kuzetsa> well yeah, I'm currently paying $20/mo for 50 gig SSD-backed with 8-core CPU & 2 TB/mo transfer
91 2014-04-06 02:50:24 <kuzetsa> looks like digitalocean doesn't really sell 8-core developer friendly boxes I can compile stuff nearly as fast on
92 2014-04-06 02:51:19 <kuzetsa> vetch: digitalocean's $5 plan only has 20 gig SSD and the blockchain won't fit on that
93 2014-04-06 02:52:02 <vetch> kuzetsa: oh, things have changed since last year. probably a bit more costly now then.
94 2014-04-06 02:52:24 <kuzetsa> what?
95 2014-04-06 02:52:38 <kuzetsa> my $20/mo plan isn't digitalocean
96 2014-04-06 02:52:39 <vetch> well last year it wasn't 20gb and would have fitted.
97 2014-04-06 02:52:56 <kuzetsa> speaking of blockchain...
98 2014-04-06 02:53:18 <Zarutian> what is bip32 again?
99 2014-04-06 02:53:38 <kuzetsa> I've got a 3 gigabyte debug.log in my ~/.bitcoin directory... will it crash my node if I delete that while it's running?
100 2014-04-06 02:54:38 <kuzetsa> 3,807,214,045 bytes is actually closer to 4 gigabytes... large enough to annoy me quite a lot :(
101 2014-04-06 02:56:38 <kuzetsa> nevermind, a restart doesn't really hurt me & this question doesn't feel suited for #b -dev anyway
102 2014-04-06 02:59:48 <Burrito> Don't think it would crash it.
103 2014-04-06 03:00:24 <gmaxwell> kuzetsa: you can delete it.
104 2014-04-06 03:00:42 <gmaxwell> kill -HUP the process after doing so for it to release it and make a new one.
105 2014-04-06 03:00:52 <gmaxwell> If you were not running with debug=1 it would autorotate it.
106 2014-04-06 03:05:05 <kuzetsa> gmaxwell: there's an autorotate option? does that go in my .conf or what?
107 2014-04-06 03:05:23 <gmaxwell> kuzetsa: it's not an option, it's just what it does when you don't have debug=1
108 2014-04-06 03:06:30 <gmaxwell> (really having the daemon itself autorotate is pretty ununixyâ but bitcoind does a number of ununixy things, but fewer than it used to, though personally I'd prefer to not log by default, but instead just keep a circular buffer that gets emited on dying gasp)
109 2014-04-06 03:06:46 <kuzetsa> ...
110 2014-04-06 03:07:40 <kuzetsa> wait, so disable the debug log if I really don't care to do debugging on this node and if there's ever a problem I'd better hope it's reproducable and turn debug logging back on? heh
111 2014-04-06 03:07:53 <kuzetsa> 'cause that makes sense :)
112 2014-04-06 03:08:19 <kuzetsa> how do I disable / re-enable debug logging anyway? is debug=1 (or some other value) a .conf option?
113 2014-04-06 03:09:16 <kuzetsa> on forums (from october 2011) someone said: You can replace the logfile with a symbolic link to /dev/null
114 2014-04-06 03:09:28 <gmaxwell> of course you can.
115 2014-04-06 03:09:46 <kuzetsa> so a symbolic link to /dev/null won't break it?
116 2014-04-06 03:09:54 <kuzetsa> bitcoind will just happily use that instead of an actual log?
117 2014-04-06 03:09:57 <gmaxwell> kuzetsa: you must have debug=1 in your conf or in your command line or it would be auto-rotating already.
118 2014-04-06 03:10:07 <kuzetsa> oh
119 2014-04-06 03:10:14 <gmaxwell> kuzetsa: yes, this works generally for all programs.
120 2014-04-06 03:10:21 <kuzetsa> I wouldn't know
121 2014-04-06 03:10:26 <gmaxwell> debug=1 turns up the amount of logging and stops auto-rotation.
122 2014-04-06 03:10:53 <kuzetsa> I'm a very un-unixy sysadmin (mcsa / mcse like a decade ago & worked in a microsoft shop or two)
123 2014-04-06 03:11:43 <kuzetsa> no
124 2014-04-06 03:11:54 <kuzetsa> I just checked & my bitcoin.conf does not have debug=1
125 2014-04-06 03:13:09 <gmaxwell> what does it have?
126 2014-04-06 03:13:27 <kuzetsa> no is there a reference to "debug of any kind" in my /etc/conf.d/bitcoind or /etc/init.d/bitcoind
127 2014-04-06 03:14:59 <kuzetsa> https://gist.github.com/kuzetsa/10001041 <-- redacted bitcoin.conf (4 lines had things which I'd rather not be made public)
128 2014-04-06 03:16:13 <gmaxwell> hm. Interesting. well my memory was slightly fault we only rotate the log automatically at start. You said yours was 4gb?
129 2014-04-06 03:16:25 <gmaxwell> interesting that it got so big during a single run and without -debug.
130 2014-04-06 03:16:38 <kuzetsa> well yeah, something like that (3,807,214,045 bytes)
131 2014-04-06 03:16:50 <gmaxwell> close enough to 4gb.
132 2014-04-06 03:17:04 <gmaxwell> do you still have the file?
133 2014-04-06 03:17:06 <kuzetsa> ... it was actually still growing / timestamp was from just moments before I deleted it and restarted
134 2014-04-06 03:17:11 <gmaxwell> K.
135 2014-04-06 03:17:12 <kuzetsa> nah I deleted it
136 2014-04-06 03:17:27 <vetch> have you got dedicated "connect" lines? could be just the spam of connect failures every n seconds bulking up the log.
137 2014-04-06 03:17:42 <kuzetsa> come to think of it, that might be really huge [tm] because the other day I deleted the chainstate stuff and had to rebuild it
138 2014-04-06 03:17:46 <kuzetsa> and never deleted the log afterward
139 2014-04-06 03:17:52 <gmaxwell> if it bloats up again bug me before you delete it and I can have you check which messages are spamming it.
140 2014-04-06 03:17:55 <gmaxwell> ohhh
141 2014-04-06 03:18:03 <gmaxwell> okay indeed, a rebuild adds a lot, not 4gb a lot but a lot.
142 2014-04-06 03:18:09 <kuzetsa> no clue
143 2014-04-06 03:18:18 <vetch> it retries -connected nodes every second or something ridiculous.
144 2014-04-06 03:18:24 <kuzetsa> I'm just gonna ln -s debug.log /dev/nul
145 2014-04-06 03:18:38 <gmaxwell> vetch: nothing that happens every N seconds is going to make the log 4gbyte in a short time. :)
146 2014-04-06 03:18:40 <kuzetsa> wait, or is that backwards
147 2014-04-06 03:18:47 <kuzetsa> I can never remember ln syntax heh
148 2014-04-06 03:19:13 <vetch> gmaxwell: clutching at straws, but a failed connect to a very long DNS name every second for a few weeks?
149 2014-04-06 03:19:17 <kuzetsa> yeah, backwards (target, link name)
150 2014-04-06 03:19:24 <gmaxwell> vetch: 50 bytes, once per second, would take like 3 years to reach 4gb.
151 2014-04-06 03:20:04 <gmaxwell> kuzetsa: it's like cp [thing you already have] [thing you want]
152 2014-04-06 03:20:04 <vetch> point taken. something else weird going on.
153 2014-04-06 03:20:31 <kuzetsa> that doesn't make sense to me
154 2014-04-06 03:20:35 <gmaxwell> I dunno what it is that makes everyone (including me) get it backwards sometimes, since it makes perfect sense.
155 2014-04-06 03:21:03 <kuzetsa> I would think "create a link" command, first argument is "name of link"
156 2014-04-06 03:21:05 <kuzetsa> but it's not
157 2014-04-06 03:21:39 <gmaxwell> kuzetsa: no one gets confused by c(o)p(y) source destination why would link source destination be confusing?
158 2014-04-06 03:22:02 <kazcw> I think it's because the direction you create it in is opposite the direction it's followed in
159 2014-04-06 03:22:10 <kuzetsa> <a href="/dev/nul">this seems counter intuitive to me as well</a> [but with markdown syntax](/dev/nul) ... makes more sense
160 2014-04-06 03:22:25 <kazcw> copied files don't have a natural "direction" concept pointing back to their source
161 2014-04-06 03:22:44 <kuzetsa> ya know, I've never made a symbolic link to /dev/nul before today
162 2014-04-06 03:22:56 <gmaxwell> kazcw: well if your filesystem does cow they do. :P
163 2014-04-06 03:23:00 <kuzetsa> is it normal to be red background with white text according to the default colorization on ls?
164 2014-04-06 03:23:20 <gmaxwell> there is no default ls colorization, thats system specific.
165 2014-04-06 03:23:28 <kuzetsa> ...
166 2014-04-06 03:23:48 <gmaxwell> it's different on fedora, and ubuntu and such.
167 2014-04-06 03:23:48 <kuzetsa> I've never had a gentoo install without ls colorization enabled by default and bash as the default shell
168 2014-04-06 03:23:57 <vetch> speaking of. bitcoin logs could do with some colour.
169 2014-04-06 03:24:00 <gmaxwell> sure it's just not likely the same as mine.
170 2014-04-06 03:24:03 <gmaxwell> lrwxrwxrwx. 1 gmaxwell gmaxwell 9 Apr 5 20:23 foofoo -> /dev/null
171 2014-04-06 03:24:07 <kazcw> in the gentoo default, white on read is a dead link
172 2014-04-06 03:24:11 <gmaxwell> thats ^ cyan ^ brown
173 2014-04-06 03:24:20 <kuzetsa> hmm ok then
174 2014-04-06 03:24:31 <kazcw> it's /dev/null, not /dev/nul
175 2014-04-06 03:24:48 <kuzetsa> this one is cyan, light gray: bitcoin.conf -> /etc/bitcoin/bitcoin.conf
176 2014-04-06 03:25:44 <kuzetsa> oh crap, I wonder if it's because I forgot to chown bitcoin:bitcoin debug.log and it's currently root owned instead of owned by my bitcoin user
177 2014-04-06 03:27:14 <kuzetsa> hmm... owned by bitcoin this time and it's still red background / white text
178 2014-04-06 03:28:26 <kazcw> try: ls $(readlink debug.log)
179 2014-04-06 03:29:26 <kuzetsa> kazcw: already killed my screen session & don't have any terminals open... but your usage of readlink is fascinating enough that I'm gonna fire one up out of curiousity O_O
180 2014-04-06 03:31:26 <kuzetsa> $ ls $(readlink debug.log) --[output]--> ls: cannot access /dev/nul: No such file or directory
181 2014-04-06 03:31:30 <kazcw> yeah, that's because it's /dev/null, not /dev/nul
182 2014-04-06 03:31:38 <kuzetsa> oh crap
183 2014-04-06 03:31:42 <kuzetsa> kazcw: thanks
184 2014-04-06 03:31:58 <kuzetsa> it's supposed to be /null eh?
185 2014-04-06 03:32:05 <kuzetsa> /dev/null even
186 2014-04-06 03:32:09 <kuzetsa> that... seems wrong
187 2014-04-06 03:32:17 <kuzetsa> echo test > nul
188 2014-04-06 03:32:40 <kuzetsa> on dos / windows that's correct
189 2014-04-06 03:32:47 <kuzetsa> but it's /dev/null on posix platforms?
190 2014-04-06 03:34:16 <kuzetsa> ah HA!
191 2014-04-06 03:34:56 <kuzetsa> I guess so (now I have cyan symbolic link named debug.log pointing at gold /dev/null according to ls -l debug.log)
192 2014-04-06 03:36:16 <olalonde> windows uses nul instead of null? weird...
193 2014-04-06 03:36:51 <kuzetsa> olalonde: I was using dos before linux existed, and windows uses dos syntax... that's not weird at all
194 2014-04-06 03:36:59 <gmaxwell> CPMism
195 2014-04-06 03:37:10 <olalonde> well it's weird in the sense that they made a spelling mistake :)
196 2014-04-06 03:37:47 <olalonde> ah nevermind, apparently nul is a word too
197 2014-04-06 03:38:14 <kuzetsa> http://www.bluesock.org/~willg/dev/ascii.html <-- in ascii a proper zero byte is (nul)
198 2014-04-06 03:39:00 <olalonde> didn't realize there was both a "nul" and "null" word in English
199 2014-04-06 03:39:38 <kuzetsa> well yeah, nul is a cardinal zero
200 2014-04-06 03:41:07 <olalonde> if you are not sure about what it is next time, check what the file is called with ls (ls /dev/)
201 2014-04-06 03:42:02 <kuzetsa> https://tools.ietf.org/html/rfc20#section-5.2 -- NUL (Null): The all-zeros character which may serve to accomplish
202 2014-04-06 03:42:02 <kuzetsa> time fill and media fill.
203 2014-04-06 03:42:10 <kuzetsa> oops sorry about the linewrap
204 2014-04-06 03:42:34 <kuzetsa> RFC 20 is from 1969, awesome hehe
205 2014-04-06 03:43:05 <kuzetsa> https://tools.ietf.org/html/rfc20#section-2 <-- fancy chart using 3-letter spellings, etc.
206 2014-04-06 03:43:42 <olalonde> in unix, input/output devices are represented as files so you can list them and manipulate them as regular files mostly
207 2014-04-06 03:44:06 <kuzetsa> good point
208 2014-04-06 03:44:47 <kuzetsa> windows NT sdk-style / api-level you need special trickery to open up a handle for various things like serial ports
209 2014-04-06 03:45:39 <kuzetsa> interracting with something as though it's a file is still alien to me even though I've theoretically had some experience with posix platforms going back to around '93 or '94 or so :(
210 2014-04-06 03:46:16 <olalonde> "cp /dev/urandom /dev/fb0" will write random colors to your screen on linux... anyways, this is getting OT :)
211 2014-04-06 03:47:58 <kuzetsa> yeah, I have a "correctly" named /dev/nul symlink now, thanks for the troubleshooting assist :)
212 2014-04-06 03:48:09 <kuzetsa> err, /dev/null even :(
213 2014-04-06 03:48:14 <olalonde> right :)
214 2014-04-06 03:48:18 <kuzetsa> ACTION shivvers
215 2014-04-06 03:59:52 <olalonde> trying to build on OS X... I ran "make" but it says "make[6]: Nothing to be done for `all-am'."
216 2014-04-06 04:01:28 <olalonde> oops , nevermind
217 2014-04-06 04:01:46 <olalonde> the binary files are in src/
218 2014-04-06 04:24:47 <gmaxwell> So I think I figured out why the AV things are alarming on the chainstate SSTs and not the block files: clamav at least just doesn't alarm at all if the file is >32 mbytes in size (even if the 'virus' signature is at the front)
219 2014-04-06 04:28:58 <olalonde> weird
220 2014-04-06 04:34:08 <olalonde> fix: make SST files larger than 32mbytes :P
221 2014-04-06 05:02:34 <aynstein> anyone have a well connected testnet node ?
222 2014-04-06 05:13:39 <IBEGONE> ACTION is away -> <- Page [FRIENDS] Log [ON]
223 2014-04-06 05:34:08 <cmendes0101> I was trying to develop for blockchain.info/api/api_receive but real testing doesnt show it working correctly and many people have posted the same issues. Anyone know a good alternative to create an address w/ custom call backs? Coinbase doesnt appear to create on the fly passing data points
224 2014-04-06 05:38:05 <warren> cmendes0101: if you need absolute reliability you need to host your own infrastructure
225 2014-04-06 05:39:54 <vetch> cmendes0101: their uptime is ridiculously bad too. you don't ever want to rely on them.
226 2014-04-06 05:41:05 <cmendes0101> I just had finished coding everything and then real test transfers are just getting lost. I'm not too familiar with performing that locally. I'll try to look into that
227 2014-04-06 05:49:00 <olalonde> cmendes0101: have a lookg at insight-api
228 2014-04-06 05:49:11 <olalonde> cmendes0101: https://github.com/bitpay/insight-api
229 2014-04-06 05:51:58 <cmendes0101> olalonde: awesome, I was actually trying googling trying to figure out how to get started in that direction
230 2014-04-06 05:52:39 <cmendes0101> Looks like theres a lot of good activity on the repo, except there site is down http://insight.bitcore.io/
231 2014-04-06 05:53:48 <vetch> cmendes0101: your url is wrong. http://live.insight.is/
232 2014-04-06 05:54:52 <cmendes0101> yah I just found that one. From there notes the project has split into 2. api is still documented with site at .io and the frontend is .is
233 2014-04-06 05:55:21 <cmendes0101> But looks cool, I'll check this out. Thanks for the info guys
234 2014-04-06 05:56:39 <olalonde> it's basically a database/http layer on top of bitcore (#bitcore)
235 2014-04-06 06:12:40 <olalonde> is there a built in way in the protocol to establish an encrypted connection with a node?
236 2014-04-06 06:13:47 <vetch> rpc supports ssl. p2p does not.
237 2014-04-06 06:14:10 <olalonde> ok
238 2014-04-06 06:14:23 <olalonde> I guess I coudl create a ssh tunnel / use openvpn
239 2014-04-06 06:14:31 <vetch> dont expose your rpc port publically though, thats just silly.
240 2014-04-06 06:14:53 <vetch> why do you think you need to encrypt your p2p traffic?
241 2014-04-06 06:15:23 <olalonde> I want need a trusted node to run bitcore and I'd like to host bitcoind on a separate machine
242 2014-04-06 06:16:04 <vetch> bitcore reads the block files directly as well. you will struggle doing that.
243 2014-04-06 06:16:45 <olalonde> I don't think it needs access to the block files... at least insight-api doesn't afaik
244 2014-04-06 06:17:48 <vetch> insight does its initial sync using the raw block files.
245 2014-04-06 06:18:21 <olalonde> right but it's optional and the local files can be removed afterwards
246 2014-04-06 06:18:38 <olalonde> anyways, you answered the question :)
247 2014-04-06 06:21:18 <olalonde> I agree it probably doesn't make much sense to run bitcore on a different machine in most cases
248 2014-04-06 08:26:54 <olalonde> I'm bootstrapping the block download with bootstrap.dat.. if i stop the process, will it continue from where it last stopped or will it start again from the start?
249 2014-04-06 08:29:10 <gmaxwell> Yes.
250 2014-04-06 08:29:39 <gmaxwell> (it'll start at the start but rapidly scan past the part it's has already processed)
251 2014-04-06 08:39:24 <olalonde> gmaxwell: ok thanks
252 2014-04-06 08:46:46 <olalonde> gmaxwell: any way to disable block verification to speed up the import? the bootstrap.dat comes from a trusted node...
253 2014-04-06 08:47:15 <Luke-Jr> olalonde: it still needs to build the index
254 2014-04-06 08:47:42 <gmaxwell> olalonde: no, but most of the time until it hits the signature verification recent blocks is just sha256 and updating the indexes.
255 2014-04-06 09:05:08 <olalonde> seems its not possible...well, i'll have to wait :P
256 2014-04-06 09:11:55 <qqStrat> Anyone here ?
257 2014-04-06 09:20:18 <olalonde> yep
258 2014-04-06 09:43:43 <ning> Hi, everybody. I have a question here. The wiki (https://en.bitcoin.it/wiki/Protocol_specification#addr) says an address takes 30 bytes, but I found that an address sent over the network takes only 26 bytes. Did I miss something?
259 2014-04-06 09:44:51 <dexX7> well there is a question mark behind it
260 2014-04-06 09:45:27 <dexX7> but i think it's 4 byte timestamp + 26 byte addr
261 2014-04-06 09:45:29 <dexX7> = 30 byte
262 2014-04-06 09:50:48 <ning> When I received the "addr" message, the entire payload has 27 bytes (one for address count), 26 bytes are used to represent an address.
263 2014-04-06 10:13:45 <ning> I figured out. The addresses sent over the wire are not prefixed with a timestamp. But why?
264 2014-04-06 10:38:31 <olalonde> ning: "Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up." maybe an old client?
265 2014-04-06 10:40:53 <olalonde> dexX7
266 2014-04-06 10:45:50 <vetch> olalonde: a client that old wouldn't be able to keep with the network. that's prehistoric.
267 2014-04-06 10:46:46 <olalonde> vetch: do you have a better theory? :P
268 2014-04-06 10:48:26 <olalonde> oh.. wire protocol
269 2014-04-06 10:50:50 <olalonde> does that refer to something else than https://en.bitcoin.it/wiki/Protocol_specification?
270 2014-04-06 10:52:43 <ning> I was connecting to a node that advertises itself as /Satoshi:0.8.6/
271 2014-04-06 10:53:34 <ning> and my tool advertises itself as /Satoshi:0.7.2/ protocol version 60002
272 2014-04-06 10:53:37 <olalonde> imo, the most likely is that this node is connected to a pre 31402 node... what's the address anyways?
273 2014-04-06 10:54:16 <ning> I was connecting to 69.43.163.188
274 2014-04-06 10:54:35 <ning> this node is not mine, and I picked it randomly
275 2014-04-06 10:55:30 <olalonde> but the IP in the "addr" message .. the one without a timestamp
276 2014-04-06 10:56:03 <Luke-Jr> [10:53:30] <ning> and my tool advertises itself as /Satoshi:0.7.2/ protocol version 60002 <-- don't do that -.-
277 2014-04-06 10:57:02 <ning> Okay I won't. But why?
278 2014-04-06 10:58:05 <gmaxwell> because it makes it very hard to diagnose and debug things if you lie in the version string.
279 2014-04-06 10:58:22 <gmaxwell> none of the software behavior depends on the version string
280 2014-04-06 10:58:50 <ning> Is this good --> /MyTool:0.0.1/ protocol version 60002
281 2014-04-06 10:59:08 <gmaxwell> s/version/vendor/
282 2014-04-06 10:59:16 <Apocalyptic> protocol version 60002 // sounds a bit old
283 2014-04-06 10:59:22 <gmaxwell> ning: sure though why are you 60002?
284 2014-04-06 10:59:24 <aynstein> sorry, I am kinda whoring out testnet, gunna be done in about 20 minutes
285 2014-04-06 10:59:47 <aynstein> oops
286 2014-04-06 11:01:28 <ning> gmaxwell, I picked it randomly. I will bump it up in later experiments:)
287 2014-04-06 11:01:32 <Luke-Jr> x.x
288 2014-04-06 11:02:45 <olalonde> from the bitcoin wiki: "And here's a modern (60002) protocol version client advertising itself to a local peer..."
289 2014-04-06 11:03:13 <volante> can anyone help with this problem? i'm running bitcoind but when i run bitcoin-cli it says: "error: resolve: Host not found (authoritative)". im not sure what host it's trying to resolve.
290 2014-04-06 11:05:17 <aynstein> gmaxwell: is it possible to half tetnet blockrewards or is it just 50?
291 2014-04-06 11:05:42 <aynstein> halve
292 2014-04-06 11:06:28 <vetch> olalonde: the wiki is very out of date.
293 2014-04-06 11:06:44 <ning> Another inconsistency with the wiki is that everytime I connect to a remote node, send a version message, I expect a verack message to be sent back. But all I'm getting is addr message or inv message.
294 2014-04-06 11:06:51 <olalonde> vetch: yes.. that's my point. can't blame him for not knowing which protocol version to chose
295 2014-04-06 11:07:12 <vetch> its a wiki, if you find something wrong then correct it.
296 2014-04-06 11:07:35 <olalonde> I think you need to pay for editing right though
297 2014-04-06 11:07:46 <olalonde> unless this is no longer the case
298 2014-04-06 11:08:11 <volante> i can see that bitcoind is listening on port 8332 but for some reason bitcoin-cli complains about not being able to resolve a host.. i just want it to connect to localhost
299 2014-04-06 11:08:23 <olalonde> and as I am not a core developer, I have no idea how protocol versions are supposed to work :P
300 2014-04-06 11:11:40 <volante> http://pastebin.com/jpa4vCZz
301 2014-04-06 11:15:29 <olalonde> ning: maybe because you already sent the message once? https://github.com/bitcoin/bitcoin/blob/8556b0298d6b7101b063862fb4ab6b4a67dd2361/src/main.cpp#L3369
302 2014-04-06 11:22:48 <ning> olalonde, yes, I think you are right, I was getting the "reject" message (which is not documented in the wiki either). Thanks.
303 2014-04-06 11:23:12 <olalonde> ning: good
304 2014-04-06 11:25:13 <Luke-Jr> ning: it should be..
305 2014-04-06 11:28:22 <olalonde> volante: how do you call bitcoin-cli?
306 2014-04-06 11:42:20 <volante> olalonde: im getting some help in #bitcoin now. the problem only happens when i disconnect the machine from the internet. does rpc not work offline?
307 2014-04-06 11:42:45 <olalonde> volante: bitcoind is on the same machine?
308 2014-04-06 11:43:29 <volante> yep
309 2014-04-06 11:43:55 <volante> i can telnet to it just fine when the network is disconnected.. but bitcoin-cli won't connect
310 2014-04-06 11:44:09 <gmaxwell> volante: rpc works fine offline
311 2014-04-06 11:44:36 <gmaxwell> (I just tested)
312 2014-04-06 11:44:38 <gmaxwell> but spreading things over multiple channels isn't so helpful, and tech support shouldn't be in here.
313 2014-04-06 12:05:25 <axilla> is there a better forum than bitcointalk for talking about bitcoin projects?
314 2014-04-06 12:18:42 <melvster> anyone know of any examples of the transaction object in BIP22 : https://en.bitcoin.it/wiki/BIP_0022#Transactions_Object_Format
315 2014-04-06 12:19:16 <Luke-Jr> melvster: libblkmaker's example has a coinbasetxn
316 2014-04-06 12:19:48 <Luke-Jr> melvster: or you can just call bitcoind getblocktemplate..
317 2014-04-06 12:20:06 <melvster> Luke-Jr: thanks!
318 2014-04-06 12:20:35 <melvster> i have the coinbasetxn ... just looking for additional tx
319 2014-04-06 12:21:29 <Luke-Jr> same format
320 2014-04-06 12:22:06 <wyrag> hi, anyone know how to fix this? ./bitcoin-qt: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./bitcoin-qt)
321 2014-04-06 12:22:13 <wyrag> running debian 7
322 2014-04-06 12:22:30 <wyrag> bitcoin version 9
323 2014-04-06 12:22:56 <aynstein> wyrag: probably more of a #bitcoin question but your missing the path, or the compiler itself it looks like
324 2014-04-06 12:23:34 <wyrag> thanks
325 2014-04-06 12:24:40 <sipa> wyrag: known problem; my best advice is to compile it yourself
326 2014-04-06 12:25:13 <aynstein> sipa: what is the "problem"?
327 2014-04-06 12:42:59 <sipa> aynstein: unnecessary dependency on a newer libc
328 2014-04-06 13:03:31 <aynstein> sipa: thanks.
329 2014-04-06 14:21:37 <Happzz> what gives an input it's priority, that affects the fee to send it
330 2014-04-06 14:21:58 <sipa> priority only affects whether it is accepted without fee or not
331 2014-04-06 14:22:17 <sipa> and priority is bitcoin days destroyed divided by size in bytes
332 2014-04-06 14:22:28 <sipa> fee itself is just per-byte
333 2014-04-06 14:24:09 <roybadami> How does one get wiki edit permissions these days?
334 2014-04-06 14:24:17 <sipa> one pings HaltingState
335 2014-04-06 14:24:34 <roybadami> Thanks
336 2014-04-06 15:21:05 <olalonde> return (CBigNum(1)<<256) / (bnTarget+1);
337 2014-04-06 15:21:11 <olalonde> in CBigNum GetBlockWork() const
338 2014-04-06 15:21:37 <olalonde> anyone knows why CBigNum is shifted and why 1 is added to bnTarget?
339 2014-04-06 15:21:54 <PRab> Found a minor Display bug in Bitcoin-QT 0.9 for Windows.
340 2014-04-06 15:23:16 <lclc> what's the maximum n out of m for multi-signature? Last time I heard 10 out of 15. Now yesterday someone told me 3 out of 5 is the maximum miners will accepts with luck, more likely is only 2 out of 3? is that right?
341 2014-04-06 15:23:16 <PRab> If I move it all the way to the right side of the screen (so it automatically resizes to half the screen), then close and re-open it, it ends up hanging off the right side of the screen instead of restoring to the same position.
342 2014-04-06 15:23:36 <vetch> PRab: raised an issue on GitHub about it?
343 2014-04-06 15:23:55 <PRab> Not yet. I wanted to make sure that was the correct action to take.
344 2014-04-06 15:24:39 <vetch> lclc: I think the limit is the size of the resulting transaction more than anything else. you most certainly will never get a 10 of 15
345 2014-04-06 15:24:51 <tiago> Is there any RSS feed for bitcoin releases/github tags?
346 2014-04-06 15:25:05 <tiago> I would like to know when a new version is released so I can gitian build
347 2014-04-06 15:25:19 <olalonde> lclc: I don't think there's a theoretic limit apart from the fact your transaction should not exceed max block size. I'm not sure what's the min/max most miners will accept to mine though
348 2014-04-06 15:25:25 <lclc> vetch, yes that's what he said
349 2014-04-06 15:26:01 <vetch> PRab: probably a very low priority bug, but if you can reliably reproduce it then go right ahead. sounds like a windows 8 thing though right?
350 2014-04-06 15:26:04 <tiago> lclc: there is a variable named MAX_MONEY or something like that
351 2014-04-06 15:26:13 <tiago> that limits the maximum output of a transaction
352 2014-04-06 15:26:17 <tiago> correct me if I'm wrong
353 2014-04-06 15:26:29 <PRab> vetch: Yep, I agree low priority. Windows 7 64bit.
354 2014-04-06 15:26:37 <vetch> tiago: that has no impact here.
355 2014-04-06 15:26:38 <sipa> olalonde: work is defined as the expected number of hashes performed
356 2014-04-06 15:26:45 <sipa> olalonde: that is the formula
357 2014-04-06 15:26:59 <tiago> vetch: misread the question, sorry
358 2014-04-06 15:27:24 <vetch> olalonde: there's a maximum transaction size. you can't make 1mb (max block size) transactions.
359 2014-04-06 15:27:37 <olalonde> sipa: yes I understand that... so basically the sum of all block difficulties
360 2014-04-06 15:27:56 <olalonde> vetch: ah ok didn't know. what's the max transaction size?
361 2014-04-06 15:28:08 <lclc> any chance that this maximum size will be bigger in the futures?
362 2014-04-06 15:28:08 <olalonde> sipa: but still I don't understand that code :(
363 2014-04-06 15:28:26 <sipa> olalonde: there are 2^256 possible hashes
364 2014-04-06 15:28:40 <sipa> olalonde: the ones equal or below the target are fine
365 2014-04-06 15:28:50 <vetch> olalonde: I don't know off the top of my head.
366 2014-04-06 15:28:54 <sipa> olalonde: if the target was 0, only hash 0 would be valid
367 2014-04-06 15:29:03 <sipa> olalonde: which is one in 2^256
368 2014-04-06 15:29:42 <sipa> olalonde: if the target was 1, there would be in 2^256 valid hashes
369 2014-04-06 15:29:46 <sipa> so you need 2^256/2 hashes to find one on average
370 2014-04-06 15:29:51 <sipa> olalonde: it's just math
371 2014-04-06 15:30:25 <sipa> it computes 2^256 / (target + 1)
372 2014-04-06 15:32:12 <vetch> sipa: is the sigop-per-block hard limit mentioned in BIP10 still a thing?
373 2014-04-06 15:32:26 <olalonde> sipa: ah ok makes sense.. I just thought it could have simply been 1/target... but then you'd have to deal with floats I guess
374 2014-04-06 15:32:38 <sipa> vetch: it would require a hard fork to remove it
375 2014-04-06 15:33:30 <vetch> sipa: right, stupid question in hindsight.
376 2014-04-06 15:35:10 <vetch> I suppose nothing has ever really taxed it before. its not like there's 1000 multisig transactions in a block to fill the limit. we don't even have that many normal transactions.
377 2014-04-06 15:39:47 <tiago> Found an answer to my question (thanks to michagogo|cloud's ifttt recipe) - https://github.com/bitcoin/bitcoin/tags.atom
378 2014-04-06 15:40:00 <michagogo> cloud|ACTION is pinged
379 2014-04-06 15:40:07 <michagogo> cloud|Ah
380 2014-04-06 15:43:54 <tiago> michagogo|cloud: Now I get an SMS when bitcoin has a new tag :D
381 2014-04-06 15:44:07 <michagogo> cloud|As do I :P
382 2014-04-06 15:44:12 <michagogo> cloud|But you already know that.
383 2014-04-06 15:44:18 <tiago> yep
384 2014-04-06 15:45:12 <tiago> i wonder what the ifttt sms thing is powered by
385 2014-04-06 15:46:22 <olalonde> probably twilio
386 2014-04-06 15:48:09 <tiago> olalonde: correct http://www.quora.com/IFTTT-1/Which-SMS-provider-does-ifttt-use/answer/Alexander-Tibbets
387 2014-04-06 15:48:19 <vetch> I still don't see how they're not haemorrhaging money. like all of these sort of things they'll likely disappear suddenly some day.
388 2014-04-06 15:48:46 <vetch> they have no visible income and probably have insane bills.
389 2014-04-06 15:49:03 <michagogo> cloud|Supposedly it's a Level3 VoIP line
390 2014-04-06 15:49:11 <tiago> vetch: yeah, twilio changes 4.7¢/message to my number
391 2014-04-06 15:50:01 <vetch> tiago: yep. just look at how popular some of the "text me the weather every morning" type ones are and you can calculate some of their running costs.
392 2014-04-06 15:50:51 <tiago> vetch: I guess they get money from stuff like this - http://www.belkin.com/wemo/ifttt/
393 2014-04-06 15:51:22 <vetch> 20,000 people have the weather SMSed to them every morning. what.
394 2014-04-06 15:51:53 <sipa> OT
395 2014-04-06 15:52:07 <vetch> sorry.
396 2014-04-06 15:53:02 <tiago> sorry sipa.
397 2014-04-06 15:55:54 <melvster> just want to confirm something, it's possible to send change back to the original input, right, but unusual?
398 2014-04-06 15:56:06 <melvster> (original input address)
399 2014-04-06 15:57:09 <sipa> as 'change' does not exist at the protocol level, sure
400 2014-04-06 15:57:23 <sipa> it's just a regular output that you do with what you want
401 2014-04-06 15:58:42 <melvster> thanks
402 2014-04-06 16:49:36 <langerhans> Hi. Following the OS X build instructions gives me an executable that links against dylibs (from macports). I obv. can only use that on the build machine. Is there some flag missing to tell the build tools to link statically? This is relevant, but I don't know how to tell autotools to do this: http://stackoverflow.com/a/846194/1902129
403 2014-04-06 17:18:27 <Kireji> of interest http://www.reddit.com/r/Bitcoin/comments/22cohy/8024121746_mining_18_blocks_today_containing - someone is saying an IP from Germany is mining blocks with increased efficiency but not processing very many transactions to get the reward
404 2014-04-06 17:19:48 <Kireji> http://blockchain.info/blocks/80.241.217.46
405 2014-04-06 17:23:17 <maaku> for people building services, choice of database *matters* : hackingdistributed.com/2014/04/06/another-one-bites-the-dust-flexcoin/
406 2014-04-06 17:23:43 <maaku> do not build financial services on top of eventually consistent infrastructure
407 2014-04-06 17:26:00 <cmendes0101> With insight-api, does it have a way to do getnewaddress?
408 2014-04-06 17:32:31 <speed-> Kireji what's with this
409 2014-04-06 17:32:34 <speed-> anyone said something?
410 2014-04-06 17:37:41 <andytoshi> can somebody more familiar with mining (and more willing to actually read that stupid reddit link) write a response to it?
411 2014-04-06 17:38:01 <andytoshi> all i have right now is that the surface claims are nonsensical, but i'm getting slammed by it on #bitcoin
412 2014-04-06 17:39:23 <speed-> there is something really fishy going on with this.. they could have not found so many blocks
413 2014-04-06 17:39:54 <speed-> gmaxwell, or any other dev, is there some info maybe? :)
414 2014-04-06 17:43:09 <andytoshi> speed-: bc.i publishes nonsense
415 2014-04-06 17:43:35 <andytoshi> you cannot associate an IP address to a block like that, please do not post this crap on #bitcoin-dev
416 2014-04-06 17:47:02 <Kireji> speed-: no reply yet
417 2014-04-06 17:47:22 <area> andytoshi: You're right, but the fact that the blocks all have 2^n transactions in them does point to them coming from the same source
418 2014-04-06 17:48:01 <speed-> andytoshi I don't know I just read it as Kireji linked it, so it got me kinda worried
419 2014-04-06 17:48:06 <area> (I'm just going off of what that reddit thread is saying, I've not looked to see if that's actually true)
420 2014-04-06 17:48:20 <andytoshi> speed-, area: it is just FUD and it does not belong on -dev
421 2014-04-06 17:49:18 <Kireji> andytoshi: ok can you elaboborate on why? maybe a link or pointer to somehwere w/ description
422 2014-04-06 17:54:59 <axiomist> Kireji: +1 clearly there will be more people asking for this so... It may be a good thing to offer some kind of quick eli5-explanation. maybe not in here though, dunno.
423 2014-04-06 17:58:47 <Kireji> axiomist: yes, not a dev question BUT this needs a swift and definative technical eval and explanation to prevent it being spun into a problem
424 2014-04-06 17:59:23 <axiomist> Kireji: yup. top post on /r/bitcoin
425 2014-04-06 17:59:24 <sipa> what is the problem
426 2014-04-06 17:59:26 <sipa> ?
427 2014-04-06 17:59:40 <Kireji> sipa: http://www.reddit.com/r/Bitcoin/comments/22cohy/8024121746_mining_18_blocks_today_containing
428 2014-04-06 18:00:23 <Kireji> people are spreading a story that one IP in germany is hashing s^n transactions at a rate far above the norm for transaction processing, and getting unfair rewards without processing enough transactions
429 2014-04-06 18:00:26 <andytoshi> sipa: there is a reddit post along the lines of the random oracle assumption on SHA256d being broken by some 14-month-old algorithm which some IP address is using, because [gibberish about merkle something] and [bc.i points to this IP address]
430 2014-04-06 18:01:04 <andytoshi> Kireji: wtf is an "unfair reward", miners can and have always been able to choose what transactions they include
431 2014-04-06 18:01:04 <sipa> sigh
432 2014-04-06 18:01:07 <Kireji> this IP http://blockchain.info/blocks/80.241.217.46
433 2014-04-06 18:01:14 <sipa> when will people learn the first rule of bitcoim?
434 2014-04-06 18:01:22 <sipa> do not believe blockchain.info
435 2014-04-06 18:01:29 <sipa> it's the second rule as well
436 2014-04-06 18:02:00 <axiomist> the nth rule (:
437 2014-04-06 18:02:07 <sipa> just ignore it
438 2014-04-06 18:02:08 <Kireji> andytoshi: unfair as in "they get the 25 bitcoins, but do not process enough transactions to keep the network functional"
439 2014-04-06 18:02:21 <sipa> Kireji: miner's discretion
440 2014-04-06 18:02:35 <sipa> Kireji: if they choose to ignore the fees from that, it's their full right
441 2014-04-06 18:02:45 <sipa> if people don't like that, they should pay more fee
442 2014-04-06 18:03:17 <sipa> now, #bitcoin please
443 2014-04-06 18:03:20 <Kireji> compeltely agree
444 2014-04-06 18:05:12 <asdjfgapsudgaasy> Hi guys ! I have a small question about data from https://en.bitcoin.it/wiki/BIP_0032_TestVectors : what does the "'" mean ? (like in "Chain m/0'/1/2'/2"). I've been reading the BIP32 and haven't found mention of that notation (sorry if it's a stupid question)
445 2014-04-06 18:16:23 <kazcw> it means not a hardened child
446 2014-04-06 18:16:39 <chmod755> guys........i just had the weirdest computer bug ever
447 2014-04-06 18:17:10 <sipa> kazcw: no, it means hardened
448 2014-04-06 18:17:12 <chmod755> actual insects sitting on my bitcoin miner caused it to stop, because i forgot to close the door
449 2014-04-06 18:17:26 <asdjfgapsudgaasy> @kazcw : thanks
450 2014-04-06 18:17:46 <sipa> asdjfgapsudgaasy: it's the old notation for hardened, but it was ambiguous
451 2014-04-06 18:18:13 <sipa> asdjfgapsudgaasy: i'll update the test vectors too
452 2014-04-06 18:47:06 <phantomcircuit> sipa, lol yeah that's just a well connected server
453 2014-04-06 18:50:47 <sipa> HectorJ: what was the solkution to the problem you tweeted?
454 2014-04-06 18:52:46 <oneblitz> Hi
455 2014-04-06 18:53:05 <oneblitz> Is there anyone here
456 2014-04-06 18:53:13 <oneblitz> .
457 2014-04-06 18:53:19 <chmod755> Yes
458 2014-04-06 18:54:37 <oneblitz> I'm trying to get in to github/bitcoin...
459 2014-04-06 18:57:25 <sipa> ok?
460 2014-04-06 18:57:52 <sipa> http://github.com/bitcoin/bitcoin
461 2014-04-06 18:58:46 <oneblitz> Newbie here..can u offer me some advice in learning btc .. the technical part..
462 2014-04-06 18:58:58 <sipa> read the paper
463 2014-04-06 18:59:00 <sipa> the wiki
464 2014-04-06 18:59:08 <sipa> stackexchange
465 2014-04-06 18:59:13 <oneblitz> Bitcoin.it...?sure
466 2014-04-06 18:59:26 <sipa> yes, though much is outdated there
467 2014-04-06 18:59:49 <oneblitz> I'll check it out on stackexchange
468 2014-04-06 19:00:00 <tommygunner> http://bitcoin.org/bitcoin.pdf
469 2014-04-06 19:01:08 <oneblitz> Thx for all these..I'll try hard
470 2014-04-06 19:01:12 <midnightmagic> oneblitz: Also the bitcoin-development mailing list archives; satoshi's posts in bitcointalk.
471 2014-04-06 19:01:49 <oneblitz> Where are the btc dev mailing list archives?
472 2014-04-06 19:02:16 <oneblitz> I'll Google it..thx
473 2014-04-06 19:02:36 <midnightmagic> http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/ I think?
474 2014-04-06 19:03:32 <oneblitz> Thx
475 2014-04-06 19:35:51 <jiffe98> if I have a message and a signature for that message which is based on a key of low entropy is it possible to determine the key from that information alone?
476 2014-04-06 19:39:15 <sipa> jiffe98: it can be done with *any* message and corresponding signature
477 2014-04-06 19:39:43 <sipa> jiffe98: it is how message signature work, by computingnthe public key that would have signed it, and comparing its hash with the claimed address
478 2014-04-06 19:40:17 <jiffe98> sipa: sorry I meant can you determine the private key used to sign
479 2014-04-06 19:40:34 <shesek> jiffe98, how would that make any sense? o_O
480 2014-04-06 19:40:59 <kazcw> A single value, considered on its own, cannot be "of low entropy". Entropy per bit is a property of a distribution.
481 2014-04-06 19:41:19 <shesek> I mean... if you can easily brute force the private key from the private key, you could do that regardless of having a signature with that key
482 2014-04-06 19:41:21 <jiffe98> I'm trying to determine if password based private keys is a bad idea
483 2014-04-06 19:41:29 <HectorJ> Any "official" test vector for BIP32 testnet keys ?
484 2014-04-06 19:41:34 <kazcw> YES they're a bad idea
485 2014-04-06 19:41:42 <shesek> * from the public key
486 2014-04-06 19:41:46 <shesek> it doesn't really effect anything in this regard
487 2014-04-06 19:41:56 <kazcw> but that isn't what you asked at all
488 2014-04-06 19:42:44 <jiffe98> sure it is, if you can determine the private key with that information then that method of security isn't valid
489 2014-04-06 19:43:01 <shesek> kazcw, I don't think so... if you force strong passwords, require them to include personally identifiable information like an email address (the approach that Vitalik is pushing for) and use a KDF that requires some CPU work
490 2014-04-06 19:43:02 <jiffe98> I really hate dealing with passwords
491 2014-04-06 19:43:35 <shesek> it is pretty safe
492 2014-04-06 19:44:08 <shesek> and less prone to getting lost
493 2014-04-06 19:44:12 <jiffe98> what I was hoping to do was to have a client side private key and they send me the public key for storage and verification, and any api calls I receive they sign and I can verify with their public key
494 2014-04-06 19:45:25 <shesek> jiffe98, what does that have to do with basing the private key on a password?
495 2014-04-06 19:45:52 <jiffe98> because if you can intercept just one of those messages and brute force the password from that then that is a bad situation
496 2014-04-06 19:46:12 <kazcw> shesek: I think including personally identifiable information to strengthen the randomness is a dangerous practice, since if you do that yet actually fail to provide enough randomness you have revealed additional personal information to the brute forcer. If you do it right it's fine, but why add a greater failure mode?
497 2014-04-06 19:46:47 <shesek> kazcw, its mostly a way to force attackers to attack each account separately
498 2014-04-06 19:47:15 <HectorJ> jiffe98 : why use Bitcoin keys for that ? Isn't there more suited asymmetric crypto algo ?
499 2014-04-06 19:47:15 <shesek> and I would assume that a brute force attack on all possible emails AND all possible passwords isn't really doable
500 2014-04-06 19:47:44 <kazcw> oh, relatively public information. I'd seen it suggested with stuff that was supposed to be more secret, but a non-private client-side salt makes sense
501 2014-04-06 19:47:47 <shesek> an attacker would probably use a list of emails that are known (are very likely) to be using the service
502 2014-04-06 19:48:00 <michagogo> cloud| 08:02:33 <aynstein> anyone have a well connected testnet node ?
503 2014-04-06 19:48:00 <shesek> so he would already have the identifiable information to begin with
504 2014-04-06 19:48:05 <michagogo> cloud|aynstein: still looking for one?
505 2014-04-06 19:49:27 <shesek> kazcw, yeah, there's no reason to use something really private... just something unique. a name, phone number pr email address would work fine for that
506 2014-04-06 19:52:43 <sipa> jiffe98: password based private keys are a bad idea for the simple reasons that humans cannot judge entropy correctly
507 2014-04-06 19:53:00 <sipa> jiffe98: they will think their password is safe because it is hard to guess for human
508 2014-04-06 19:53:32 <sipa> jiffe98: unaware that their enemy is the eternity of a massive amount of computer power
509 2014-04-06 19:55:32 <jiffe98> sipa: that's what I'm leaning towards, only way of really using a password is with server side verification to slow down an attack on it
510 2014-04-06 19:55:57 <venzen> sipa: are you saying that BIP38 keys are kinda weak?
511 2014-04-06 19:56:52 <Apocalyptic> <sipa> jiffe98: password based private keys are a bad idea for the simple reasons that humans cannot judge entropy correctly // can't agree more
512 2014-04-06 19:57:40 <sipa> venzen: bip39 you mean?
513 2014-04-06 19:58:01 <venzen> hold on i'm checking what i mean!
514 2014-04-06 19:58:18 <sipa> venzen: not necessarily, as they can be computer-generated, but i think bip39 is a bad idea because it encourages human generated entropy, yes
515 2014-04-06 19:58:25 <Apocalyptic> you guys actually care about what Vitalik is pushing for N
516 2014-04-06 19:58:27 <Apocalyptic> ?
517 2014-04-06 19:58:40 <sipa> what is vitalik pushing for?
518 2014-04-06 19:58:57 <Apocalyptic> <shesek> kazcw, I don't think so... if you force strong passwords, require them to include personally identifiable information like an email address (the approach that Vitalik is pushing for) and use a KDF that requires some CPU work
519 2014-04-06 19:59:10 <sipa> ah
520 2014-04-06 19:59:26 <sipa> i think that just gives a false sense of security
521 2014-04-06 19:59:30 <Apocalyptic> ^
522 2014-04-06 19:59:36 <sipa> sure, in practice it will make things harder
523 2014-04-06 19:59:52 <sipa> but it remains very hard to judge how strong a password really is
524 2014-04-06 20:00:04 <sipa> i don't see why you would bother risking that
525 2014-04-06 20:00:16 <sipa> use a computer generated password, store the key in a trusted device
526 2014-04-06 20:00:23 <sipa> and encrypt it with a password
527 2014-04-06 20:00:28 <sipa> best of all worlds
528 2014-04-06 20:00:40 <sipa> *computer generated key, i mean
529 2014-04-06 20:04:12 <venzen> sipa: i do mean BIP38 - as in priv keys encrypted with a passphrase for paper wallets, etc... which is a bit different than bip39's mnemonic idea... i see there are guys offering cold storage wallets imprinted on metal -so they ask the customer for a priv key... and hence BIP38
530 2014-04-06 20:06:45 <gmaxwell> pretty scarry, a lot of people have lost funds manually handling private keys like that.
531 2014-04-06 20:13:09 <venzen> gmaxwell: i feel bad for having lol'ed... but it occured to me that despite the high risk they must have chosen some lame passwords! :)
532 2014-04-06 20:14:12 <gmaxwell> users, including you and me, always choose lame passwordsâ its the law of passwords.
533 2014-04-06 20:14:46 <phantomcircuit> gmaxwell, and this is why all of my passwords are two parts
534 2014-04-06 20:14:56 <gmaxwell> they're losing funds not through paper wallets, they lose funds due to key mishandling... sending change off to keys they delete, destroying the only copy they have of a key, etc.
535 2014-04-06 20:15:00 <phantomcircuit> something random which i keep in a safe place and something less random that i made up
536 2014-04-06 20:15:20 <venzen> or as sipa says, they have the "eternity of a massive amount of computer power" working against their human fallibility
537 2014-04-06 20:15:52 <venzen> ah.. losing or destroying keys... ouch
538 2014-04-06 20:17:13 <gmaxwell> there have been a bunch of posts where someone imports a 'paper wallet' into multibit. sends funds, multibit sends change to the first address in the wallet as it always does... then they destroy the multibit wallet.. bye bye funds.
539 2014-04-06 20:17:28 <gmaxwell> or they spend via something like brainwallet and manage to send all the change to fees.
540 2014-04-06 20:18:38 <gmaxwell> then there are things like the guy who had a great security procedure, including re-printing his QR code one a month to prevent the printout from fading ... whos basement flooded and turned the paper to pulp.
541 2014-04-06 20:20:29 <gmaxwell> then you have the fallability of memoryâ which is much greater than people often think... and you have a rarely used key (data you need to use it for is on paper) which they were trying to choose a secure password for... and of course many people forget it.
542 2014-04-06 20:21:06 <gmaxwell> Lulled by the security they get outside of cryptography where lost passwords are always recoverable...
543 2014-04-06 20:22:24 <phantomcircuit> gmaxwell, lol yeah i have 5BTC on a hdd i cant remember the passphrase too
544 2014-04-06 20:22:33 <phantomcircuit> someday i shall bruteforce it
545 2014-04-06 20:22:48 <BCB> gmaxwell, https://twitter.com/maraoz/status/452869864487911425
546 2014-04-06 20:22:54 <tommygunner> i just had a look at my mnemonic again
547 2014-04-06 20:22:57 <venzen> that's sad about the guy with the flooded basement...
548 2014-04-06 20:23:05 <tommygunner> i should bury a copy in the woods
549 2014-04-06 20:23:42 <gmaxwell> phantomcircuit: I've never lost BTC due to a forgotten password, because I learned that lesson before bitcoin existed. I know there are people around here who have lost more than 5 btc that way, I think people are not so public with those losses because they're embarassing.
550 2014-04-06 20:24:08 <Apocalyptic> very true
551 2014-04-06 20:24:45 <phantomcircuit> gmaxwell, heh, well im 100% sure that it's a prefix plus a weird pattern of keys on a specific keyboard
552 2014-04-06 20:24:49 <gmaxwell> BCB: next will he demonstrate how to shoot up maybe-heroin purchased from an online blackmarket?
553 2014-04-06 20:24:59 <phantomcircuit> it would just require sitting there for hours trying to figure it out
554 2014-04-06 20:25:00 <michagogo> cloud|Someone I know from another channel (supposedly) has 160 BTC on an encrypted HD to which he has lost the key
555 2014-04-06 20:25:32 <BCB> gmaxwell, isn't he a bitpay guy. I would think those guys would know better...
556 2014-04-06 20:25:45 <venzen> phantomcircuit: that sucks... have you tried recreating the circumstances under which you created that password... or going to a hypnotherapist?
557 2014-04-06 20:26:02 <Apocalyptic> lol
558 2014-04-06 20:26:09 <gmaxwell> it's too attractive a bad idea, suckers in a lot of otherwise perfectly reasonable people...
559 2014-04-06 20:26:10 <phantomcircuit> no? im sure i can figure it out i just have to sit down and work at it
560 2014-04-06 20:27:24 <venzen> there's that special feeling - not sure if it's got a name - that you get when a password suddenly eludes you months later...
561 2014-04-06 20:27:40 <tommygunner> bioproof an sd card and implant it in your forearm
562 2014-04-06 20:28:05 <tommygunner> the thought of having to cut yourself open should have you remember your password
563 2014-04-06 20:29:01 <phantomcircuit> that sounds like a bad idea
564 2014-04-06 20:29:11 <phantomcircuit> like someone cutting your arm open bad idea