1 2013-09-04 00:16:53 <cfields> gmaxwell: https://github.com/theuni/bitcoin/commit/78caa022f352fd9dc830c2482038d82024dbfc59 better?
2 2013-09-04 00:19:09 <gmaxwell> sounds good. At some point I think we should just serialize the tests and include a simple in-tree replay tool. But since I'm not volunteering to do it right now...
3 2013-09-04 00:20:19 <cfields> yea, this all seems a bit strange to me. but for now, i'm just trying to do a 1:1 port of what currently exists
4 2013-09-04 00:46:03 <Xenonucleicacid> Hey, im trying to get bitcoind to output getbalance as an intiger as opposed to a float.
5 2013-09-04 00:46:11 <Xenonucleicacid> is this a configarable option with the standard client?
6 2013-09-04 00:46:55 <gmaxwell> Xenonucleicacid: no, though the formating is such that you can drop the dot and you have an integer.
7 2013-09-04 00:47:21 <Xenonucleicacid> That would require i reqrite the entire code i think
8 2013-09-04 00:47:40 <gmaxwell> Rewrite what entire code?
9 2013-09-04 00:47:59 <Xenonucleicacid> php script connecting to it, right?
10 2013-09-04 00:48:15 <Xenonucleicacid> Im running the intersang source, albeit heavily modified
11 2013-09-04 00:50:10 <Xenonucleicacid> I tried to compile the bitcoind they reccomended I use that does this by default,
12 2013-09-04 00:50:15 <Xenonucleicacid> however, it wont compile at all.
13 2013-09-04 00:50:35 <Xenonucleicacid> And i can't figure out why. Anyways, gmaxwell, how would i edit the code to drop the dot?
14 2013-09-04 00:51:09 <gmaxwell> Xenonucleicacid: I wasn't suggesting editing the bitcoind code. I was suggesting changing your application, but it sounds like you have some large codebase there, and then I have no suggestion
15 2013-09-04 00:51:25 <Xenonucleicacid> Alright, then
16 2013-09-04 00:51:47 <gmaxwell> ... though I would also point out that if you're not able or willing to take full ownership of even minor details like this, maybe you're getting in over your head running software that would handle other people's money! :)
17 2013-09-04 00:52:07 <Xenonucleicacid> My issue is with not being able to compile the ollowing: http://gitorious.org/intersango/bitcoind/source/00c0126dd92cec4ad8428d4317467a1588d8763e:
18 2013-09-04 00:52:17 <Xenonucleicacid> the read file includes some dependanices that dont exist.
19 2013-09-04 00:52:53 <Xenonucleicacid> I just thought i'd approach it from a different way, perhaps first ask how to do it the aforementioned way
20 2013-09-04 00:53:03 <gavinandresen> customised bitcoind? How ancient is that? REALLY bad idea to run ancient versions of bitcoind.....
21 2013-09-04 00:53:26 <gavinandresen> Xenonucleicacid: also, see https://en.bitcoin.it/wiki/Proper_Money_Handling_(JSON-RPC)
22 2013-09-04 00:53:47 <gmaxwell> wow, thats like 0.3.x code!
23 2013-09-04 00:55:02 <gavinandresen> gmaxwell: osx binaries are compiled with gcc on a laptop running OSX 10.6. I'm all for deterministic mac buildsâ¦.
24 2013-09-04 00:55:09 <Xenonucleicacid> Well then I guess i'll just have to modify an existing version to output an intiger then..
25 2013-09-04 00:55:10 <Xenonucleicacid> Fuck
26 2013-09-04 00:55:13 <Xenonucleicacid> thanks for the help guys
27 2013-09-04 00:56:33 <gavinandresen> Four sets of matching gitian signatures, so I've uploaded the 0.8.4 release to: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.4/?
28 2013-09-04 00:57:22 <gavinandresen> Can y'all proofread the release notes? The big change from 0.8.4rc2 is full disclosure of the critical DoS issue.
29 2013-09-04 00:58:17 <gmaxwell> gavinandresen: should we alert now that it's more explicit or just let crashing nodes be the alert if an attack does happen?
30 2013-09-04 00:58:31 <cfields> gavinandresen: my main concern is that would mean osx releases come from linux, which will be very different binaries than the ones run/tested from osx during development
31 2013-09-04 00:58:46 <gavinandresen> I think just crashing is the right answer. There's no danger of remote exploit
32 2013-09-04 00:59:10 <gmaxwell> gavinandresen: ::nods:: makes sense to me.
33 2013-09-04 00:59:14 <phantomcircuit> Xenonucleicacid, there is a fairly trivial patch to switch various rpc calls to use integers
34 2013-09-04 00:59:25 <phantomcircuit> speaking as the person who actually wrote a good amount of that code
35 2013-09-04 00:59:28 <phantomcircuit> dont do it
36 2013-09-04 01:00:09 <phantomcircuit> also as gavinandresen said that fork is ancient
37 2013-09-04 01:00:31 <cfields> gavinandresen: if it's non-trivial, s/theuni/Cory Fields/ :)
38 2013-09-04 01:00:54 <gavinandresen> it is trivial. So I won't do it.
39 2013-09-04 01:00:58 <gavinandresen> :)
40 2013-09-04 01:01:03 <phantomcircuit> Xenonucleicacid, literally that's 2 years old Wednesday August 31 2011
41 2013-09-04 01:01:53 <cfields> heh
42 2013-09-04 01:08:33 <cfields> gavinandresen: when you get a spare min, would you mind explaining to me the significance of applying the patch (contrib/test-patches/temp-revert-2.patch) during the compare test?
43 2013-09-04 01:09:09 <gavinandresen> cfields: that is probably cruft from before we had -regtest mode
44 2013-09-04 01:09:40 <cfields> gavinandresen: so.. drop it?
45 2013-09-04 01:09:54 <gavinandresen> yes
46 2013-09-04 01:10:23 <cfields> roger. thanks.
47 2013-09-04 01:10:49 <cfields> in fact, i had not added it yet as i didn't know what it did, so i'll just not bother with it :)
48 2013-09-04 01:12:04 <gavinandresen> Default sourceforge downloads set to 0.8.4, I'm going to announce to bitcoin-development and will post to bitcointalk
49 2013-09-04 01:12:33 <gavinandresen> Speaking of bitcointalk⦠better to put the release announcements in the "important announcements" forum or bitcoin-discussion ?
50 2013-09-04 01:12:58 <gmaxwell> Put it in important announcements.
51 2013-09-04 01:13:03 <jgarzik> +1
52 2013-09-04 01:13:08 <jgarzik> ACTION disappears for baby bedtime
53 2013-09-04 01:18:48 <gavinandresen> gmaxwell: I'm not a bitcointalk moderator any more, so don't have permission to post in Important Announcements. Can you post the announcement?
54 2013-09-04 01:20:03 <gmaxwell> gavinandresen: I'm not a moderator in that subforum, however if you post the announcement in the development/technology subforum I can make magic things happen.
55 2013-09-04 01:20:12 <TheLordOfTime> hehe
56 2013-09-04 01:20:15 <Xenonucleicacid> bitcoindtalk is a ;ile of shit
57 2013-09-04 01:20:30 <gmaxwell> (I can't post there either but I can move posts there!)
58 2013-09-04 01:21:04 <gavinandresen> gmaxwell: In the past, I've done release candidates --> dev/tech, final releases bitcoin-discussion
59 2013-09-04 01:21:41 <gmaxwell> gavinandresen: sure, I'm saying post in dev/tech and then in seconds after you do that I'll move the post to Important Announcements.
60 2013-09-04 01:21:58 <gavinandresen> ok, posting now...
61 2013-09-04 01:23:10 <gavinandresen> gmaxwell: https://bitcointalk.org/index.php?topic=287351
62 2013-09-04 01:23:22 <gmaxwell> @#$#@ Darnit, theymos fixed the bug!
63 2013-09-04 01:23:40 <Luke-Jr> Xenonucleicacid: intersango's crazy code expects a String last I checked :/
64 2013-09-04 01:25:23 <phantomcircuit> Luke-Jr, that it does (actually did but that's not important)
65 2013-09-04 01:26:05 <gmaxwell> gavinandresen: K. I moved it to bitcoin-discussion, and prodded the staff forum to get someone to move it. The link is stable regardless of where its placed.
66 2013-09-04 01:28:56 <gavinandresen> gmaxwell: spiffy. I'm updating the links on the bitcoin wiki homepage
67 2013-09-04 02:01:25 <jgarzik> hurrah 0.8.4 :)
68 2013-09-04 02:03:40 <saivann> bitcoin.org is updated and I sent a email to the maintainer of weusecoins.com ( the site is actually not updated since a while )
69 2013-09-04 02:04:50 <jgarzik> saivann, thanks
70 2013-09-04 02:07:46 <gmaxwell> http://www.reddit.com/r/Bitcoin/comments/1loqvi/bitcoinqt_d_version_084_released/ reddited too
71 2013-09-04 02:08:24 <jgarzik> gmaxwell, gavinandresen: one problem with the 'move' on bitcointalk.org is that normal users cannot reply to the thread at all
72 2013-09-04 02:08:32 <jgarzik> it would be better to copy
73 2013-09-04 02:08:51 <jgarzik> (and it seems there are now two copies of the thread in Important Announcements, neither of which may be replied-to :))
74 2013-09-04 02:09:59 <gmaxwell> Seem theymos copied and someone else moved. :P
75 2013-09-04 02:10:28 <gmaxwell> Can you hear the benny hill music?
76 2013-09-04 02:18:41 <jgarzik> http://www.reddit.com/r/Bitcoin/comments/1loojy/bitcoinqt_bitcoind_version_084_released_fixes/ for the upvote. (somebody beat me to it :))
77 2013-09-04 02:25:01 <jgarzik> Man, what a dick move.
78 2013-09-04 02:25:15 <jgarzik> My comment on 0.8.4 got downvoted to -1: http://www.reddit.com/r/Bitcoin/comments/1loojy/bitcoinqt_bitcoind_version_084_released_fixes/cc1acwf
79 2013-09-04 02:25:51 <theymos> gavinandresen: IMO your 0.8.4 topic should be unlocked so that it can be bumped in everyone's Unread Topics constantly. Shall I do this?
80 2013-09-04 02:26:34 <gavinandresen> theymos: yes, thanks
81 2013-09-04 02:26:40 <theymos> ok
82 2013-09-04 02:26:54 <jgarzik> it started out as unlocked, even. The move to Important Announcements wound up locking it, I think.
83 2013-09-04 02:27:12 <theymos> I fixed all that.
84 2013-09-04 02:27:17 <jgarzik> great, thanks
85 2013-09-04 02:27:27 <cfields> gavinandresen: did you try 'make deploy' on autotools branch?
86 2013-09-04 02:28:07 <gavinandresen> cfields: no, didn't try that.
87 2013-09-04 02:28:39 <cfields> gavinandresen: mind giving it a shot? I'm trying to determine where the big snags are going to be post-master
88 2013-09-04 02:28:50 <cfields> it worked fine for me on 10.6, but it was hit-or-miss on 10.8
89 2013-09-04 02:29:29 <cfields> (when you're not knee-deep in release-mode, of course)
90 2013-09-04 02:30:46 <gavinandresen> cfields: getting pull-tester happy is higher priority
91 2013-09-04 02:35:52 <cfields> gavinandresen: pull-tester is ready on my side after a rebase afaik
92 2013-09-04 02:44:14 <midnightmagic> jgarzik: some guy is saying you just had "no" in your comment. Is he a dirty liar who needs a downvote for lying dirtily? I've seen worse.. :(
93 2013-09-04 02:45:10 <E1ven> I'm trying to figure out the right way to script a weird multi-party exchange. Is this an appropriate place to ask, or would something like StackExchange or Reddit be more appropriate? I certainly don't want to be intrusive on dev. :/
94 2013-09-04 02:47:28 <Xenonucleicacid> this is ridiculous.
95 2013-09-04 02:47:40 <Xenonucleicacid> i cant figure out how to modify bitcoind to use an intiger as opposed to a float
96 2013-09-04 02:48:40 <Luke-Jr> Xenonucleicacid: bitcoinrpc.cpp
97 2013-09-04 02:48:47 <Luke-Jr> AmountFromValue and ValueFromAmount
98 2013-09-04 02:48:53 <Luke-Jr> remove the COIN multiply/divide
99 2013-09-04 02:49:18 <Luke-Jr> pretty simple really
100 2013-09-04 02:51:14 <Xenonucleicacid> Will this modifucation allow a cuirrecnt bitcoind to work with intersango's code?
101 2013-09-04 02:51:20 <gavinandresen> must⦠resist⦠getting sucked into double-precision and JSON Numbers argumentâ¦â¦
102 2013-09-04 02:51:30 <Xenonucleicacid> i'm using the modified vrsion that was made for exchanging AUD
103 2013-09-04 02:51:51 <Xenonucleicacid> I jsut want to get something working before I make any further changes so that i know it works
104 2013-09-04 02:52:03 <Luke-Jr> Xenonucleicacid: as I mentioned earlier, intersango expects *Strings*, not Numbers, so no.
105 2013-09-04 02:52:11 <Xenonucleicacid> Wait
106 2013-09-04 02:52:20 <Xenonucleicacid> so then how do I get intersango running proepryl?
107 2013-09-04 02:52:22 <Xenonucleicacid> *properly
108 2013-09-04 02:52:31 <Xenonucleicacid> Can i modify it to pit out a string?
109 2013-09-04 02:52:40 <Luke-Jr> Xenonucleicacid: sure, but it's a bit more complex
110 2013-09-04 02:52:49 <Xenonucleicacid> im not a programmer.
111 2013-09-04 02:52:56 <Xenonucleicacid> is there an already modified version that can be downloaded?
112 2013-09-04 02:52:58 <Luke-Jr> gavinandresen: there's no argument? :P
113 2013-09-04 02:53:08 <Luke-Jr> Xenonucleicacid: no, it's not something that's ever been supported basically
114 2013-09-04 02:53:25 <Xenonucleicacid> Well then im screwed.
115 2013-09-04 02:53:32 <Luke-Jr> :/
116 2013-09-04 02:53:59 <Xenonucleicacid> I dont see how i can fix this problem then
117 2013-09-04 02:54:22 <Xenonucleicacid> is the ruby bitcoin-central code any better?
118 2013-09-04 02:55:37 <Luke-Jr> Xenonucleicacid: I have doubts that there is any exchange software that works without a programmer involved.
119 2013-09-04 02:56:16 <Xenonucleicacid> Oh no, i can use php and ruby
120 2013-09-04 02:56:18 <Xenonucleicacid> just not c++
121 2013-09-04 02:56:36 <Xenonucleicacid> i have the intersango thing set up just fine, except for the fact that i cant get the damn bitcoind to compile
122 2013-09-04 02:56:43 <Xenonucleicacid> (It's an old 0.3 version of botcoind)
123 2013-09-04 02:56:46 <Luke-Jr> then maybe it'd be easier to modify the PHP/Ruby to handle BTC Numbers?
124 2013-09-04 02:56:49 <Xenonucleicacid> which is why i dont want to use it
125 2013-09-04 02:56:56 <Xenonucleicacid> The codebase is huge dude :(
126 2013-09-04 02:57:02 <Luke-Jr> 0.3 bitcoinds will simply NOT work, even if you compile it
127 2013-09-04 02:57:20 <Xenonucleicacid> Then how do half the exchanges that use the intersango code run?
128 2013-09-04 02:57:37 <Luke-Jr> phantomcircuit mentioned the public code you linked was obsolete
129 2013-09-04 02:57:44 <Xenonucleicacid> Yes
130 2013-09-04 02:57:48 <Luke-Jr> I'm not sure if the newer code is also public or not
131 2013-09-04 02:57:53 <Xenonucleicacid> It is not.
132 2013-09-04 02:58:01 <Xenonucleicacid> But the old code still works, nonetheless.
133 2013-09-04 02:58:02 <Luke-Jr> well, that's your answer then :/
134 2013-09-04 02:58:08 <Luke-Jr> it doesn't sound like it!
135 2013-09-04 02:58:08 <Xenonucleicacid> The bitcoind that comes with it does not though.
136 2013-09-04 02:59:57 <jgarzik> midnightmagic, he is correct
137 2013-09-04 03:00:16 <jgarzik> midnightmagic, while my "No" was factually accurate, it was admittedly not as informative as it could have been
138 2013-09-04 03:03:29 <Luke-Jr> BlueMatt: ETA on PPA update? :x
139 2013-09-04 03:13:26 <warren> Was there any confirmation that the MacOS X leveldb fix worked?
140 2013-09-04 03:13:36 <warren> folks seemed uncertain about that 2 weeks ago
141 2013-09-04 03:34:39 <SomeoneWeird> http://cryptome.org/2013/09/computer-forensics-2013.pdf
142 2013-09-04 03:37:17 <SomeoneWeird> bottom of page 15
143 2013-09-04 03:38:02 <gmaxwell> â¢
144 2013-09-04 03:38:02 <gmaxwell> âFruit of the poisonous treeâ can be circumvented
145 2013-09-04 03:38:02 <gmaxwell> The use of backdoors cannot be detected or proven
146 2013-09-04 03:38:02 <gmaxwell> Vendors are legally and commercially prevented from
147 2013-09-04 03:38:04 <gmaxwell> acknowledging their backdoors. Defense will not be
148 2013-09-04 03:38:07 <gmaxwell> able to prove their existence
149 2013-09-04 03:38:09 <gmaxwell> â¢
150 2013-09-04 03:38:12 <gmaxwell> The files can be described as âforensically obtainedâ
151 2013-09-04 03:38:47 <gmaxwell> yea.. thats pretty fantastic.
152 2013-09-04 03:39:42 <SomeoneWeird> seems everything is backdoored
153 2013-09-04 03:39:45 <k9quaint> I just go in the front door
154 2013-09-04 03:40:04 <k9quaint> huge ass line of NSA nerds out back
155 2013-09-04 03:40:27 <gmaxwell> SomeoneWeird: don't use binary closed source security tools.. note that linux/dmcrypt is not listed there. :P
156 2013-09-04 03:40:49 <SomeoneWeird> truecrypt is foss is it not?
157 2013-09-04 03:40:52 <k9quaint> binary closed source security tools <-- jumbo shrimp
158 2013-09-04 03:41:14 <jgarzik> SomeoneWeird, I don't think so
159 2013-09-04 03:41:26 <SomeoneWeird> http://www.truecrypt.org/docs/source-code
160 2013-09-04 03:41:36 <jgarzik> gmaxwell, yeah, that Legality slide... wow
161 2013-09-04 03:41:36 <SomeoneWeird> "
162 2013-09-04 03:41:36 <SomeoneWeird> "TrueCrypt is open-source and free software. The complete source code of TrueCrypt (written in C, C++, and assembly) is freely available for peer review at:
163 2013-09-04 03:41:42 <gmaxwell> truecrypt has source available, but it's under a screwed up license, and very few users compile from source... and the binaries are not reproducable.
164 2013-09-04 03:41:50 <SomeoneWeird> gmaxwell, i see
165 2013-09-04 03:41:54 <jgarzik> SomeoneWeird, ah, I stand corrected
166 2013-09-04 03:42:08 <SomeoneWeird> :)
167 2013-09-04 03:42:21 <gmaxwell> would be pretty exciting to show that there was a backdoor in the binary not in the source though.
168 2013-09-04 03:42:50 <gmaxwell> it also may be the case that the presenter there is simply mistaken about truecrypt. (or, e.g. is mistaking a brutforcing tool for a backdoor in that case)
169 2013-09-04 03:43:07 <SomeoneWeird> possible
170 2013-09-04 03:44:01 <k9quaint> believe powerpoint presentations at your own peril
171 2013-09-04 03:44:23 <SomeoneWeird> i support you could compile it yourself and compare it to the binaries
172 2013-09-04 03:44:29 <SomeoneWeird> k9quaint, of course
173 2013-09-04 03:44:48 <gmaxwell> SomeoneWeird: could also be counter intel to list secure tools along with backdoored ones.
174 2013-09-04 03:45:05 <SomeoneWeird> that's quite possible too
175 2013-09-04 03:45:09 <gmaxwell> As a way to make people just give up on security: "it's all backdoored!"
176 2013-09-04 03:45:10 <SomeoneWeird> i wonder if this was classified or not
177 2013-09-04 03:45:24 <SomeoneWeird> hm probably not
178 2013-09-04 03:45:39 <k9quaint> or there could be mitigating circumstances that allow them to bypass some tools
179 2013-09-04 03:45:41 <gmaxwell> I do note that there has been some interesting discussion about how the uk was able to get into a truecrypt volume on greewald's partner's system.
180 2013-09-04 03:45:52 <SomeoneWeird> oh?
181 2013-09-04 03:45:56 <k9quaint> gmaxwell: keylogger ;P
182 2013-09-04 03:45:56 <SomeoneWeird> source?
183 2013-09-04 03:45:59 <gmaxwell> k9quaint: e.g. windows ignoring mlock and swapping out keys.
184 2013-09-04 03:46:17 <SomeoneWeird> ... purposely >.>
185 2013-09-04 03:46:18 <k9quaint> gmaxwell: I stopped reading after you typed "windows"
186 2013-09-04 03:46:22 <SomeoneWeird> lol
187 2013-09-04 03:46:33 <gmaxwell> SomeoneWeird: e.g. http://news.yahoo.com/uk-asked-n-y-times-destroy-snowden-material-175418363--finance.html
188 2013-09-04 03:46:42 <SomeoneWeird> ah, right
189 2013-09-04 03:46:46 <gmaxwell> k9quaint: well you wouldn't be using truecrypt in Linux.
190 2013-09-04 03:46:58 <SomeoneWeird> some people do
191 2013-09-04 03:47:03 <SomeoneWeird> i used to
192 2013-09-04 03:47:08 <gmaxwell> someone should point out that cryptome deck here: http://forums.truecrypt.org/viewforum.php?f=2
193 2013-09-04 03:47:08 <SomeoneWeird> (then i got smart)
194 2013-09-04 03:47:43 <k9quaint> truecrypt is windows only?
195 2013-09-04 03:47:57 <gmaxwell> k9quaint: it's not windows only but linux has native encryption.
196 2013-09-04 03:48:11 <k9quaint> ah, true that
197 2013-09-04 03:48:23 <gmaxwell> And truecrypt is kludgy and slow in comparison, the only reason you should use it in linux is if you don't know better or if you need to move media beyween OSes.
198 2013-09-04 03:48:40 <k9quaint> I leave everything unencrypted, its easier than torrenting my midget porn to the NSA
199 2013-09-04 03:49:49 <k9quaint> it turns out that compressing video streams has nothing to do with the size of the people depicted :(
200 2013-09-04 03:50:14 <gmaxwell> I like where it points out that mobile operators are scanning stuff and reporting it automatically.
201 2013-09-04 03:51:26 <midnightmagic> i was sending files to a friend via my server; watching my nginx logs I saw that the private URLs I gave him were auto-grabbed by places in taiwan, usa, and japan.
202 2013-09-04 03:51:57 <midnightmagic> not cool. we surmised it was some kind of antivirus, but not a clue proper.
203 2013-09-04 03:52:38 <midnightmagic> unfortunately the native encryption in linux is mostly linux-only. :-(
204 2013-09-04 03:53:12 <midnightmagic> (as much as a cgd volume on NetBSD appears to be *BSD-only)
205 2013-09-04 03:53:53 <SomeoneWeird> midnightmagic, yep, apparently skype does that too
206 2013-09-04 03:54:33 <k9quaint> midnightmagic: were the URLs spiderable?
207 2013-09-04 03:54:35 <midnightmagic> SomeoneWeird: very f'ing evil
208 2013-09-04 03:54:47 <gmaxwell> it would be fun to use one of these MD5 attacks to start making files that have the same md5 as known child porn.
209 2013-09-04 03:54:54 <k9quaint> and how did you communicate the file URLs?
210 2013-09-04 03:54:58 <midnightmagic> k9quaint: Absolutely not. I am 99.99% certain.
211 2013-09-04 03:55:26 <k9quaint> if you used gmail, the googlebot may have spidered them to calculate ads to show next to your plans for nuclear bombs
212 2013-09-04 03:55:36 <gmaxwell> too bad afaik none of the existing md5 attacks are agreeable to matching a particular hash. :(
213 2013-09-04 03:55:43 <k9quaint> (and now the NSA is reading these logs)
214 2013-09-04 03:55:53 <midnightmagic> k9quaint: Via ichat initially, and then via voice for a secind test.
215 2013-09-04 03:56:23 <gmaxwell> you got a URL fetched that you sent over voice?!
216 2013-09-04 03:56:31 <gmaxwell> that must be the person's machine.
217 2013-09-04 03:56:36 <k9quaint> midnightmagic: where was your friend located?
218 2013-09-04 03:57:06 <midnightmagic> gmaxwell: he had to type it in. Yes we surmisdd it was some kind of AV either hiding in his machine or semi-automatically done on the fly by telus.
219 2013-09-04 03:57:14 <midnightmagic> it was g-d creepy at first.
220 2013-09-04 03:57:24 <midnightmagic> k9quaint: canada.
221 2013-09-04 03:57:33 <gavinandresen> FYI: mac metadata files ended up in the bitcoin-0.8.4-linux.tar.gz file; I'm uploading a clean version and updated SHASUMS files to sourceforge now.
222 2013-09-04 03:57:47 <k9quaint> why were you talking with filth from canada?
223 2013-09-04 03:58:28 <k9quaint> that rules out a proxy somewhere caching it
224 2013-09-04 03:58:57 <midnightmagic> k9quaint: because it's my kind of scum.
225 2013-09-04 03:59:01 <SomeoneWeird> lol
226 2013-09-04 03:59:17 <k9quaint> midnightmagic: was kind of HTTP method were the requests?
227 2013-09-04 03:59:30 <pigeons> PROPFIND
228 2013-09-04 04:01:18 <k9quaint> /s/was/what
229 2013-09-04 04:02:32 <SomeoneWeird> HTTP/NSAPROBE
230 2013-09-04 04:13:47 <midnightmagic> k9quaint: a fetch of a limited neader of information
231 2013-09-04 04:14:02 <midnightmagic> header even
232 2013-09-04 04:15:30 <k9quaint> so it was a HEAD request?
233 2013-09-04 04:16:24 <midnightmagic> no, head won't retrieve as much data as they retrieved.
234 2013-09-04 04:16:31 <midnightmagic> one sec lemme see if i can find it again
235 2013-09-04 04:17:03 <jgarzik> Computer Forensics for Prosecutors 2012 http://cryptome.org/2013/09/computer-forensics-2012.pdf
236 2013-09-04 04:17:10 <jgarzik> (last year's version; not yet read it)
237 2013-09-04 04:18:02 <jgarzik> SilentSense Behavioral Spying on Smartphones http://cryptome.org/2013/09/silent-sense-spy.pdf
238 2013-09-04 04:20:02 <k9quaint> "Working around Encryption: âKnownâ backdoors " on page 52
239 2013-09-04 04:23:32 <jgarzik> cryptome: the real wikileaks
240 2013-09-04 04:25:09 <jgarzik> I wonder if the sudden increase in Tor usage was the government spinning up a bunch of nodes, and try and own most of the network </tin foil>
241 2013-09-04 04:25:19 <SomeoneWeird> hah
242 2013-09-04 04:25:53 <Eneerge> page 52
243 2013-09-04 04:25:55 <Eneerge> ?
244 2013-09-04 04:26:50 <phantomcircuit> jgarzik, the 2012 version says "known" (with the quotes) backdoors
245 2013-09-04 04:26:58 <phantomcircuit> but does not specifically list anything
246 2013-09-04 04:27:23 <phantomcircuit> it's also much more careful in handling of exculpatory evidence
247 2013-09-04 04:27:45 <phantomcircuit> a lot less un-constitutionalish
248 2013-09-04 04:27:51 <gmaxwell> yea, the 2012 version isn't ... scummy. also lots of neat hands on stuff.
249 2013-09-04 04:28:27 <gmaxwell> jgarzik: nah, actual usage has gone up in disproportion to the number of new nodes.
250 2013-09-04 04:30:04 <Luke-Jr> gmaxwell: that's not to say the government hasn't (already) owned most of the network
251 2013-09-04 04:31:12 <gmaxwell> sure sure, I hope to never be someone who's primary threat model is that not only a major-nation state but one that wouldn't care about giving away that they had such control.. you're really screwed at that point regardless of the specifics.
252 2013-09-04 04:31:38 <midnightmagic> 208.50.101.153 - - [01/Aug/2013:08:34:36 +0000] "GET /for_justice.rar HTTP/1.1" 200 227519 "http://temp.com" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
253 2013-09-04 04:31:44 <midnightmagic> ^^ example
254 2013-09-04 04:33:14 <midnightmagic> the file is many gigs of data
255 2013-09-04 04:34:03 <k9quaint> could you pastebin the redacted logs?
256 2013-09-04 04:34:25 <midnightmagic> huh? that is 100% full line
257 2013-09-04 04:34:46 <midnightmagic> unmodified
258 2013-09-04 04:34:49 <k9quaint> ah
259 2013-09-04 04:35:11 <midnightmagic> yes the file was called "for_justice.rar"
260 2013-09-04 04:35:13 <midnightmagic> lol
261 2013-09-04 04:35:39 <k9quaint> at least it wasn't furries+midgets.rar
262 2013-09-04 04:36:10 <gmaxwell> http://answers.microsoft.com/en-us/ie/forum/ie8-windows_other/how-to-stop-the-smartscreen-filter-from-accessing/fc74131c-35fc-4a26-adf6-864d22367de6?page=2&msgId=b99a2e0d-f476-49fb-85ad-c81c2b68b06a
263 2013-09-04 04:36:17 <gmaxwell> (google that ip)
264 2013-09-04 04:36:56 <k9quaint> the only thing nonnefarious that I can think of is if it was some sort of malware sniffing proxy
265 2013-09-04 04:38:02 <k9quaint> looks like that IP lands somewhere in MSN.net
266 2013-09-04 04:38:38 <k9quaint> you will need to hose down your nginx instance after interacting with that villainous scum of redmond
267 2013-09-04 04:40:14 <phantomcircuit> midnightmagic, check for that ip address
268 2013-09-04 04:40:22 <phantomcircuit> return gzip'd null file
269 2013-09-04 04:40:30 <gmaxwell> See the microsoft faq.
270 2013-09-04 04:40:32 <phantomcircuit> laugh as smartscreen filter stops working world wide
271 2013-09-04 04:40:58 <phantomcircuit> goto jail for violation of computer unauthorized access
272 2013-09-04 04:41:07 <phantomcircuit> stop laughing
273 2013-09-04 04:43:20 <cfields> sounds to me like the url was entered (send or receive side) into some application that uses an IE control to render part of its interface, and that control obeys IEs settings wrt smartscreen's pre-filtering
274 2013-09-04 04:43:44 <cfields> might not be nice, but that doesn't sound all that spooky to me
275 2013-09-04 04:48:21 <pigeons> yay windows!
276 2013-09-04 04:56:53 <jgarzik> hasn't reactos replaced that yet?
277 2013-09-04 04:57:54 <jgarzik> or at least some rogue "dirty white hat" produces a gitian build of leaked Windows XP source code, and works on closing all the security holes </dreaming on>
278 2013-09-04 04:58:15 <jgarzik> between WINE and ReactOS, surely Windows is 110% rewritten at this point
279 2013-09-04 05:25:52 <gmaxwell> tehehe: https://bitcointalk.org/index.php?topic=287136.msg3076181#msg3076181
280 2013-09-04 05:29:50 <k9quaint> hahaha
281 2013-09-04 05:38:40 <freewil> looks like the consensus is litecoin is better
282 2013-09-04 05:38:48 <freewil> thats what i read today
283 2013-09-04 05:39:48 <jgarzik> freewil, take it to #bitcoin or #litecoin please
284 2013-09-04 05:41:46 <freewil> i didnt start the convo
285 2013-09-04 05:42:58 <jgarzik> irrelevant
286 2013-09-04 05:43:33 <freewil> alright im sorry
287 2013-09-04 05:45:05 <gmaxwell> ACTION tanks altcoin prices, watch this:
288 2013-09-04 05:45:31 <gmaxwell> Maybe we should consider adopting new licensing terms that prevent the altcoins from just exploiting the new code and fixes we write.
289 2013-09-04 05:45:37 <gmaxwell> :P
290 2013-09-04 05:45:46 <gavinandresen> BlueMatt: I'm starting some work on the pull-tester; I'm going to clean up the fetch-from-github-and-test code (pull-tester.py), move the authentication token stuff to environment variables, and check it into the Bitcoin tree as qa/pulltester/
291 2013-09-04 05:46:52 <gavinandresen> BlueMatt: my immediate goal will be to be able to run the pull-tester locally on my development machine, so I don't have to login to jenkins to work onit
292 2013-09-04 05:59:29 <aceat64> I finally got around to making a pull request for that "copy transaction ID" thing that was bugging me
293 2013-09-04 06:12:53 <gmaxwell> gavinandresen: can you make sure that in 0.8.4 on OSX that the wallet unlock in the GUI actually works: this guy is saying it didn't work after the upgrade but worked if he downgraded: https://bitcointalk.org/index.php?topic=287434.0
294 2013-09-04 06:17:58 <gavinandresen> gmaxwell: "works for me" (I just successfully unlocked to sign a test message)
295 2013-09-04 06:19:18 <gavinandresen> sending works for me, too.
296 2013-09-04 06:21:23 <jgarzik> ACTION wants to update bitcoin.git to support the multibit-like ---BITCOIN SIGNED MESSAGE--- wrapping
297 2013-09-04 06:21:52 <jgarzik> make it a real format
298 2013-09-04 06:23:16 <warren> +1
299 2013-09-04 06:30:35 <jgarzik> BitPay is starting to use SINs, so we'll want some equivalent variant for SIN as well
300 2013-09-04 06:31:06 <Freebitcoinslist> hello all
301 2013-09-04 06:31:10 <Freebitcoinslist> I have a question
302 2013-09-04 06:32:15 <Freebitcoinslist> I would like to know if there is a way to bulk convert Private Keys formatted like this " Private Key WIF (51 characters base58, starts with a '5') " and convert them all to this " Private Key WIF (compressed, 52 characters base58, starts with a 'K' or 'L')
303 2013-09-04 06:35:03 <gmaxwell> jgarzik: "meh" makes the data a lot larger esp in cases for challenges where the data being signed is known.
304 2013-09-04 06:35:06 <sipa> Freebitcoinslist: you cannot convert them really, the resulting address will be dofferent
305 2013-09-04 06:35:13 <gmaxwell> different too.
306 2013-09-04 06:36:00 <Freebitcoinslist> would they still be valid btc addresses?
307 2013-09-04 06:36:21 <gmaxwell> Yes but they would be different addresses.. so why bother converting them, just generate new ones.
308 2013-09-04 06:37:58 <Freebitcoinslist> Ok i dont mind if they are different I just need them converted
309 2013-09-04 06:42:53 <Freebitcoinslist> So how would i convert them
310 2013-09-04 06:43:11 <sipa> i don't see the point
311 2013-09-04 06:43:21 <sipa> there is no easy way to do it
312 2013-09-04 06:43:41 <Freebitcoinslist> I am trying to import them to multibit and multibit only uses the Compressed format not the uncompressed format
313 2013-09-04 06:44:24 <sipa> so just generate a bunch of new addresses in multibit
314 2013-09-04 06:45:12 <sipa> ;;genrate 330
315 2013-09-04 06:45:15 <gribble> The expected generation output, at 330.0 Mhps, given difficulty of 86933017.7712, is 0.00190904623671 BTC per day and 7.95435931964e-05 BTC per hour.
316 2013-09-04 06:45:35 <gmaxwell> Freebitcoinslist: WHAT?! multibit won't let you import a noncompressed private key? ... I don't believe you.
317 2013-09-04 06:45:51 <sipa> gmaxwell: that would be a surprise to me as well...
318 2013-09-04 06:45:56 <gmaxwell> or generate some compressed addresses outside of multibit.
319 2013-09-04 06:46:08 <gmaxwell> ACTION tests
320 2013-09-04 06:47:22 <gmaxwell> hm. I can't see any way to just import a WIF key into it.
321 2013-09-04 06:47:45 <gmaxwell> it seems to only want to read a multibit "key" file.
322 2013-09-04 06:48:49 <gmaxwell> Import private keys from the reference client
323 2013-09-04 06:48:49 <gmaxwell> This is not currently supported. The easiest way to achieve it is to simply perform a standard Bitcoin transaction to the address provided by MultiBit.
324 2013-09-04 06:48:57 <gmaxwell> :-/
325 2013-09-04 06:49:52 <sipa> gmaxwell: for better or for worse, it is probably safer to not let people import...
326 2013-09-04 06:50:06 <gmaxwell> oh it can import, but only from bc.i and multibit wallet files.
327 2013-09-04 06:50:28 <gmaxwell> looks like the multibit key files are WIF format with a timestamp.
328 2013-09-04 06:50:39 <gmaxwell> (it also notes that an import of a bc.i wallet will rescan the whole blockchain)
329 2013-09-04 06:50:51 <gmaxwell> ACTION manually creates a multibit key file.
330 2013-09-04 06:51:49 <gmaxwell> Freebitcoinslist: I was just able to put a 5xxx private key in a multibit key file and import it.
331 2013-09-04 06:52:03 <sipa> gmaxwell: dumpwallet RPC will create suxh a file, btw
332 2013-09-04 07:02:01 <Freebitcoinslist> Gm may i pm you please
333 2013-09-04 07:10:37 <phantomcircuit> Freebitcoinslist, try his full nick to highlight him
334 2013-09-04 07:10:51 <phantomcircuit> but also why do you want to pm him
335 2013-09-04 08:52:45 <warren> You folks getting complaints from vendor and/or pools about the 4 RPC thread keep alive limit?
336 2013-09-04 08:53:15 <warren> Let's think about a real solution for that for bitcoin-0.9 ...
337 2013-09-04 08:54:00 <gmaxwell> No. The only person whos commented on it is doublec.
338 2013-09-04 08:54:09 <gmaxwell> (only pool at least)
339 2013-09-04 08:54:19 <gmaxwell> Most modern pools don't operate in a way where it matters.
340 2013-09-04 08:54:24 <warren> gmaxwell had a simple idea along the lines of refusing keep alive for the 4th and last connection. That would seem to work, as earlier versions of bitcoin lacked keepalive. But a limit of 4 seems arbitrary... although I do recognize there must be a limit.
341 2013-09-04 08:54:47 <gmaxwell> warren: we waste a bunch of ram (and a ton of VM) for per-thread stacks and heap.
342 2013-09-04 08:54:55 <warren> I know.
343 2013-09-04 08:55:39 <warren> would your earlier idea be good enough?
344 2013-09-04 08:56:31 <gmaxwell> probably. I haven't seen any cases where people really had to keep more than three keepalives up. I don't know that it would be trivial to implement though.
345 2013-09-04 09:33:34 <warren> gmaxwell: thanks
346 2013-09-04 09:33:42 <michagogo> I don't know if this is a bug, and I don't know if this has been the case in past versions or anything, but the 0.8.4 installer seems kinda glitchy on the first page: http://i.imgur.com/jDtDeoU.png
347 2013-09-04 09:34:08 <michagogo> (this is the 0.8.4 win32 setup extracted from the 0.8.4 win32 gitian zip)
348 2013-09-04 09:38:40 <phantomcircuit> michagogo, gotta love how completely unrelated changes can break things
349 2013-09-04 09:38:45 <phantomcircuit> <-- confused
350 2013-09-04 09:38:51 <michagogo> ikr
351 2013-09-04 09:39:09 <michagogo> Wait, what the hell
352 2013-09-04 09:39:14 <michagogo> I just reopened the same exe
353 2013-09-04 09:39:16 <michagogo> and it's fine
354 2013-09-04 09:39:31 <phantomcircuit> michagogo, magic
355 2013-09-04 09:39:35 <michagogo> ?
356 2013-09-04 09:39:35 <michagogo> Is that screen generated on the fly
357 2013-09-04 09:39:41 <phantomcircuit> i have no idea
358 2013-09-04 09:41:14 <michagogo> Anyone know what the bitcoin win32 installer consists of?
359 2013-09-04 09:42:36 <michagogo> Also: Is the only thing that changes between various people gitian-building and the release going up on sourceforge the binaries getting codesigned with the BTCF certificate?
360 2013-09-04 12:04:15 <gavinandresen> michagogo: the win32 installer is a NSIS installer. Source is share/setup.nsi. And yes, the only thing that changes between gitian-building and release is signing the -setup.exe file with the BTCF certificate.
361 2013-09-04 13:53:36 <dbitcoin> 0.8.2.4
362 2013-09-04 13:53:43 <jouke> BINGO
363 2013-09-04 13:54:13 <michagogo> dbitcoin: Hmm?
364 2013-09-04 13:54:20 <michagogo> The new release is 0.8.4
365 2013-09-04 13:54:32 <michagogo> no 2 in there
366 2013-09-04 13:54:53 <Luke-Jr> and at least I haven't maintained any 0.8.2.x
367 2013-09-04 13:56:50 <Luke-Jr> can anyone confirm that trying to open "bitcoin:m" as a URI results in the message "Invalid payment address 3QJmnh" indicating possible uninitialised deref?
368 2013-09-04 13:57:52 <michagogo> Er, I get "Cannot obtain a lock on data directory"
369 2013-09-04 13:58:11 <michagogo> (I have 2 bitcoin-qt running, one each main and testnet
370 2013-09-04 13:58:20 <michagogo> )
371 2013-09-04 13:58:32 <jouke> Luke-Jr: I confirm that message
372 2013-09-04 13:59:32 <Luke-Jr> ACTION hopes this isn't important, considering we just released 0.8.4 <.<
373 2013-09-04 14:00:58 <michagogo> Why am I getting the "cannot obtain lock on data directory"
374 2013-09-04 14:01:12 <michagogo> error message?
375 2013-09-04 14:01:38 <Luke-Jr> michagogo: not 0.8.4?
376 2013-09-04 14:01:42 <michagogo> Yes 0.8.4
377 2013-09-04 14:01:50 <michagogo> (the 0.8.4 installer I got out of gitian)
378 2013-09-04 14:02:13 <michagogo> I'll try rebooting my node
379 2013-09-04 14:09:55 <jgarzik> michagogo, confirmed only one bitcoin process running?
380 2013-09-04 14:10:17 <michagogo> jgarzik: Shouldn't it be 2 bitcoin processes?
381 2013-09-04 14:10:34 <jgarzik> michagogo, no
382 2013-09-04 14:10:46 <michagogo> mainnet and testnet merge their processes? o_O
383 2013-09-04 14:11:32 <dbitcoin> something wrong with 0.8.4? run with existed wallet: Error reading wallet database: CPrivKey pubkey inconsistency
384 2013-09-04 14:12:03 <kinlo> sounds like a corrupt wallet, do you still have backups?
385 2013-09-04 14:12:55 <jgarzik> michagogo, you must manually run multiple process, to access multiple networks. bitcoin won't do that for you.
386 2013-09-04 14:13:07 <michagogo> Uh, yes, I know
387 2013-09-04 14:13:29 <michagogo> So why are you saying there should be only one bitcoin process when I have both mainnet and testnet running?
388 2013-09-04 14:14:58 <jgarzik> michagogo, for 99% of users, the answer to you "shouldn't it be 2 bitcoin processes?" is no
389 2013-09-04 14:15:04 <jgarzik> *your question
390 2013-09-04 14:15:13 <jgarzik> michagogo, there are always exceptions :)
391 2013-09-04 14:15:22 <michagogo> jgarzik: But I'd just said I was running both main and test...
392 2013-09-04 14:15:54 <michagogo> Luke-Jr: When I click on <a href="bitcoin:m">test</a> I get this: http://i.imgur.com/QtaV7lh.png
393 2013-09-04 14:19:14 <dbitcoin> kinlo: previous several versions runs fine without any problem
394 2013-09-04 14:19:36 <jouke> Where can I find information on how to buld with gitian?
395 2013-09-04 14:19:50 <michagogo> jouke: release-process.m
396 2013-09-04 14:19:51 <michagogo> d
397 2013-09-04 14:20:13 <michagogo> (not the whole thing is relevant to you specifically)
398 2013-09-04 14:21:02 <michagogo> (some of the parts are for the actual packaging for release to the public)
399 2013-09-04 14:21:51 <jouke> Thanks
400 2013-09-04 15:02:49 <Luke-Jr> wumpus: Should refunds really not be displayed in Bitcoin-Qt's transaction list? O.o
401 2013-09-04 15:13:47 <jgarzik> ??
402 2013-09-04 15:19:11 <Luke-Jr> jgarzik: dcd0b0775ef63ac9e067d9eb67012332f1a72bd7
403 2013-09-04 15:20:12 <jgarzik> Luke-Jr, IMO refunds are a bit different from change
404 2013-09-04 15:20:29 <Luke-Jr> jgarzik: I agree, I'd want to see them on my transaction list
405 2013-09-04 15:20:32 <jgarzik> change is a hidden because it's part of the bitcoin protocol
406 2013-09-04 15:20:37 <jgarzik> refunds are real transactions
407 2013-09-04 15:29:24 <phrog> hello all.
408 2013-09-04 15:30:24 <gmaxwell> indeed, refunds shouldn't be change addresses. Arguably their a third kind, a parallel chain to the coins being spent. If we didn't ever reuse addresses I'd say that the change addresses should have the same index as the highest value coin being spend but on a parallel bip32 chain in the bip32 case... though it seems wasteful to have a chain so sparsely used.
409 2013-09-04 15:30:51 <phrog> I was sent .1btc w/o fees from a blockchain.info wallet and it is stuck.. can I do anything to help recive it?
410 2013-09-04 15:31:14 <phrog> tx 2a478d017df2ed94497c4878b054269105b7e4f748eb0ea71a100c2a63fc3a40
411 2013-09-04 15:31:17 <gmaxwell> phrog: define stuck?
412 2013-09-04 15:31:56 <gmaxwell> phrog: just wait, it'll go through.
413 2013-09-04 15:32:06 <wumpus> luke-jr: not sure, I guess it's debatable, in any case a show all option should be there to show everything
414 2013-09-04 15:32:10 <phrog> ok I will then, thanks :)
415 2013-09-04 15:32:32 <wumpus> luke-jr: but we don't hide any transactions do we?
416 2013-09-04 15:32:43 <wumpus> just addresses in the address book
417 2013-09-04 15:33:52 <Luke-Jr> wumpus: oh, I didn't realise that was the address book >_<
418 2013-09-04 15:34:04 <wumpus> hehe, false alarm
419 2013-09-04 15:34:09 <gmaxwell> wumpus: if you get paid to a change address that gets hidden, at least in listtransactions, I think.
420 2013-09-04 15:36:05 <wumpus> gmaxwell: could be, if it's entirely flagged as isChange, but afaik that's not triggered for refunds
421 2013-09-04 15:37:36 <gmaxwell> wumpus: Makes sense.
422 2013-09-04 15:38:26 <wumpus> it sounds pretty strange to be able to hide entire transactions that way tho, the balance will seem to have come from nowhere
423 2013-09-04 15:49:38 <Luke-Jr> wumpus: perhaps we should show something when credit > debit? the code will probably be ugly and need a lot of tests :<
424 2013-09-04 15:57:00 <gmaxwell> wumpus: we hide the payment to change and the resulting return from it, so there is no balance problem. Though I have no clue what happens if we get just an unsolicited bit of coin to a change address.
425 2013-09-04 16:00:37 <Luke-Jr> gmaxwell: sounds like we might manage to get Debian to use upstream unmodified after all :p
426 2013-09-04 16:02:05 <Luke-Jr> https://github.com/bitcoin/bitcoin/issues/2974
427 2013-09-04 16:05:21 <BlueMatt> what I like, is the number of patches debian applies to bitcoind that have never made it into upstream pull requests/issues
428 2013-09-04 16:07:30 <Luke-Jr> BlueMatt: yeah, point of this interaction with them recently is to get rid of that crap
429 2013-09-04 16:11:38 <gmaxwell> BlueMatt: have you updated the ppa for 0.8.4 yet?
430 2013-09-04 16:11:40 <wumpus> they don't even try to get it merged upstream?
431 2013-09-04 16:11:55 <gmaxwell> wumpus: don't even tell us about it.
432 2013-09-04 16:12:01 <wumpus> I see
433 2013-09-04 16:12:34 <BlueMatt> gmaxwell: yes, this morning
434 2013-09-04 16:13:01 <gmaxwell> BlueMatt: Great!
435 2013-09-04 16:13:35 <wumpus> if they break the random number generator like their ssh patches did it may be just as well :-)
436 2013-09-04 16:13:57 <gmaxwell> Hopefully we'd catch that.
437 2013-09-04 16:14:23 <BlueMatt> I love how maintainers can apply arbitrary patches without anywhere near the code-review requirements of the upstream projects
438 2013-09-04 16:14:55 <Luke-Jr> someday there will be a distro with strict rules against that <.<
439 2013-09-04 16:15:11 <gmaxwell> It's mildly terrifying that they do this... Fedora doesn't do this, if a maintainer patches something beyond a obviously trivial build system setup thing they get ask if they've taken the patches upstream.
440 2013-09-04 16:15:31 <TD> many years ago, i worked on a hybrid installer/packaging framework for linux. it achieved some moderate popularity for a while and there were even people who wanted to make a distro that didn't have big package repos, but told upstreams to use that framework
441 2013-09-04 16:15:48 <TD> and it was partly prompted by such problems
442 2013-09-04 16:15:55 <TD> needless to say, distributors (including redhat/fedora) HATED it
443 2013-09-04 16:15:58 <gmaxwell> Fedora will sometimes patch things, but its officially discouraged, and totally patches which upstream is totally unaware of basically shouldn't happen.
444 2013-09-04 16:16:08 <TD> if there was a big push towards using upstream binaries, they lose power. it's ultimately a power play.
445 2013-09-04 16:16:14 <BlueMatt> some upstreams (like us!) provide debian package scripts for packagers....that are simply ignored
446 2013-09-04 16:16:26 <gmaxwell> This was partally a backlash to the old way of doing that which was more like that debian still seems to do.
447 2013-09-04 16:16:30 <TD> eventually i got sick of the power politics and bought a mac
448 2013-09-04 16:17:28 <TD> i'm just waiting for someone to make a decent desktop android, ideally one that can run a subset of sandboxed linux/desktop java apps .... i'd so be there
449 2013-09-04 16:17:54 <gmaxwell> TD: there is value in providing a whole system that works, and sometimes that does require some integration changes.
450 2013-09-04 16:17:55 <BlueMatt> TD: or a version of chromeos that can do the same
451 2013-09-04 16:18:35 <Luke-Jr> and guarantee against trojans/viruses
452 2013-09-04 16:18:40 <TD> you can provide a whole system whilst still providing stable APIs and upstream binary distribution/packaging. from a users perspective, macos/win32/android works a whole lot better than your average linux distro
453 2013-09-04 16:18:41 <gmaxwell> TD: and there are plenty of dormant / dead upstreams.
454 2013-09-04 16:18:56 <TD> sure. so someone can fork the upstream project and become the new upstream.
455 2013-09-04 16:19:05 <Luke-Jr> TD: most developers don't want to do packaging for 2933 distros
456 2013-09-04 16:19:14 <TD> BlueMatt: well, unfortunately chromeos is rather defined by what it doesn't do :(
457 2013-09-04 16:19:54 <TD> Luke-Jr: in reality they don't need to. i had a bunch of magic toolchain wrappers for "autopackage" as it was called. building a single binary that worked on basically all distros was by no means impossible, despite the absolute lack of fucks given by distributors
458 2013-09-04 16:20:18 <BlueMatt> TD: well, my point was more that chromeos is designed to be a desktop distro that runs (one) app in a sandbox that is very tightly locked down, though I suppose android is semi-similar in intent there
459 2013-09-04 16:20:18 <gmaxwell> TD: windows dll hell is ... pretty hell. VS I think the expirence in fedora is pretty excellent, but then again, I don't have anything that I run in fedora which isn't packaged, except for the stuff where I'm developing it.
460 2013-09-04 16:20:33 <TD> but effective operating systems don't shatter into a million tiny forks, which are different only for the sake of it.
461 2013-09-04 16:20:46 <Luke-Jr> TD: it's impossible without static linking, which is STUPID
462 2013-09-04 16:20:54 <TD> dll hell hasn't been an issue on windows for decades
463 2013-09-04 16:20:58 <TD> ok
464 2013-09-04 16:21:00 <TD> "over a decade"
465 2013-09-04 16:21:26 <gmaxwell> TD: "building a single binary" yes, because this is somewhat at odds with systems built around open source. Making a mandated stable binary interface makes advancing some things much harder, and the open source world is not stuck in only haiving to provide binary compatibility when we also have the choice of source compatibility.
466 2013-09-04 16:21:35 <Luke-Jr> ACTION won't install something without a proper package for the OS
467 2013-09-04 16:22:13 <TD> binary vs source compatibility was always rather a red herring. the changes you can make that break binary but not source compatibility are invariably minor and not interesting to end users. but the proof is in the pudding. android is binary compatible back to v1.0 and has gone through massive upgrades in that time, far beyond anything the linux world has done
468 2013-09-04 16:23:21 <Luke-Jr> TD: perhaps you can help me with some advice on a bug I can't fix due to ABI concerns? :P
469 2013-09-04 16:23:25 <gmaxwell> ThomasV: https://bitcointalk.org/index.php?topic=287296.new;boardseen#new
470 2013-09-04 16:23:26 <TD> ultimately, linux distros are notorious for dependency hell, the "solution" most distributions use being simply "don't let users upgrade software beyond minor backports we provide" which is no solution at all
471 2013-09-04 16:24:19 <TD> Luke-Jr: introduce a new API and fix it that way. somehow every other OS manages this.
472 2013-09-04 16:24:28 <gmaxwell> TD: weird, you've had a very different expirence than I have. (I won't argue that yours isn't more common than mine, I have no idea. I have no or pratically no issues with respect to any of this stuff)
473 2013-09-04 16:24:44 <Luke-Jr> TD: that won't fix things using the old function
474 2013-09-04 16:25:04 <ThomasV> gmaxwell: thanks
475 2013-09-04 16:25:06 <gmaxwell> Luke-Jr: I think the idea is that you're supposted to leave old things broken.
476 2013-09-04 16:25:09 <TD> Luke-Jr: if it requires an API change then you can't fix them anyway. the apps will have to upgrade.
477 2013-09-04 16:25:18 <gmaxwell> ThomasV: I confirm that I'm getting the same MD5 that the poster reports.
478 2013-09-04 16:25:42 <TD> Luke-Jr: distros aren't gonna upgrade your component for years anyway, most likely. so no big deal :p
479 2013-09-04 16:25:46 <ThomasV> gmaxwell: I think it's been reported elsewhere a few days ago. Animazing updated the binary, iirc
480 2013-09-04 16:25:50 <ThomasV> I will check
481 2013-09-04 16:25:56 <Luke-Jr> TD: I have an enum used as a bitfield; but the functions using it have the combination specified as the enum type instead of an int type. On x86, it makes no difference, but theoretically, it may break things on other platforms; changing it to an int type also theoretically breaks ABI
482 2013-09-04 16:25:59 <BlueMatt> gmaxwell: but the nsa broke md5 and is feeding you a different binary!
483 2013-09-04 16:26:04 <BlueMatt> (well, broke it more)
484 2013-09-04 16:26:10 <Luke-Jr> TD: the API is fine with the change from enum to int type, but not the ABI
485 2013-09-04 16:26:55 <Luke-Jr> or rather, not the theoretical ABI on potentially existing platforms <.<
486 2013-09-04 16:27:28 <TD> hmm. given there are basically only 3 or 4 ISAs that matter in modern computing, that shouldn't be very hard to check.
487 2013-09-04 16:27:47 <Luke-Jr> TD: ignoring platforms because they "don't matter" is bad IMO
488 2013-09-04 16:27:47 <TD> but that kind of extreme edge case isn't a very compelling reason to build an entire OS around lack of binary compatibility
489 2013-09-04 16:27:52 <TD> er, why?
490 2013-09-04 16:28:04 <Luke-Jr> because it reenforces their "not matter"ing
491 2013-09-04 16:28:04 <TD> if I invent my own ISA will you immediately spend your weekends adding support for it?
492 2013-09-04 16:28:34 <Luke-Jr> TD: that's not the same thing; standards-compatible code shouldn't need special support for new stuff
493 2013-09-04 16:28:47 <Luke-Jr> this is a problem for me because I've done something outside of standard well-definedness
494 2013-09-04 16:29:43 <TD> in reality, end users aren't going to be downloading binaries outside of x86, amd64 and ARM, none of which should have any issues with that change. so this seems like an angels-pinhead kind of thing
495 2013-09-04 16:30:02 <TD> yes it might break things on some platform where people would compile everything from source anyway, because there are no upstream binaries
496 2013-09-04 16:30:49 <Luke-Jr> it's not especially bothering me - I've just left it unchanged for now and am comfortable doing so until some other ABI break
497 2013-09-04 17:19:04 <jgarzik> hrm
498 2013-09-04 17:19:14 <jgarzik> surely there is a function that will load all inputs of a transaction
499 2013-09-04 17:19:17 <jgarzik> in bitcoind
500 2013-09-04 17:35:11 <jgarzik> RPC: createrawtransactions gains 'fee' pseudo-address for fee safety - https://github.com/bitcoin/bitcoin/pull/2975
501 2013-09-04 17:35:45 <gmaxwell> ACTION testing
502 2013-09-04 17:36:12 <runeks> So, guys, what equation would best be able approximate the rise in difficulty?
503 2013-09-04 17:36:53 <gmaxwell> runeks: difficulty = log(runeks_annoyance)
504 2013-09-04 17:37:01 <runeks> gmaxwell: hey you!
505 2013-09-04 17:37:27 <gmaxwell> runeks: you can't model it that way. The proper "model" for difficulty absent the outside world is difficulty = whatever_difficulty_it_already_is. :P
506 2013-09-04 17:37:27 <runeks> I'm trying to see if I can predict the next difficulty using curve fitting.
507 2013-09-04 17:37:36 <gmaxwell> runeks: Try chicken bones.
508 2013-09-04 17:37:58 <gmaxwell> runeks: think for a moment what you're really predicting: you're predicting bitfury and BFL device shippments. :P
509 2013-09-04 17:38:27 <runeks> gmaxwell: Yeah I know the best equation now wouldn't always be the best. But right now it looks exponential.
510 2013-09-04 17:38:41 <runeks> But that will stop once enough ASICs are shipped.
511 2013-09-04 17:39:38 <gmaxwell> runeks: from a process perspective "exponential" doesn't make a lot of sense. Hashrate isn't bunnies. Two hashes do not begat four hashes. :P
512 2013-09-04 17:39:51 <runeks> gmaxwell: I will try exponential, and if my guess is right you owe me a millibitcoin! :)
513 2013-09-04 17:41:06 <gmaxwell> runeks: What does right even mean? you're obviously not going to get it exactly right. :)
514 2013-09-04 17:42:21 <runeks> gmaxwell: +/- 1%?
515 2013-09-04 17:42:27 <_dr> I heard the BFL monarch will reproduce exponentially
516 2013-09-04 17:42:38 <_dr> every two weeks
517 2013-09-04 17:43:01 <runeks> _dr: I think it will be stillborn.
518 2013-09-04 17:43:37 <_dr> what on earth makes you think that? obviously bfl has delivered before!!
519 2013-09-04 17:43:58 <runeks> _dr: I know, crazy thought.
520 2013-09-04 17:44:28 <k9quaint> gmaxwell: I have successfully bred hashes
521 2013-09-04 17:44:34 <runeks> Hmm. I just realized I need to consider difficulty adjustments when looking at measured block times. It may be a bigger task than first thought.
522 2013-09-04 17:44:58 <_dr> nothing a line of matlab won't solve
523 2013-09-04 17:45:18 <runeks> _dr: Give me one line of matlab that solves that :)
524 2013-09-04 17:45:38 <_dr> I'm more of a ideas guy, no details ;)
525 2013-09-04 17:46:03 <gmaxwell> runeks: I'd make a bet with you that a short term linear model fits better than an exponential one... but in fact they're close enough we couldn't call it over measurement noise.
526 2013-09-04 17:46:12 <runeks> _dr: You have the revelations, I make them into code.
527 2013-09-04 17:47:06 <runeks> I'm doing an average of 2016 blocks. That should cancel out *some* measurement noise at least.
528 2013-09-04 17:47:13 <_dr> I agree with gmaxwell. ASIC manufacturer output is hardly exponential. More like linear with increasing constant
529 2013-09-04 17:48:12 <_dr> but then again you can approximate an exponential curve with linear functions, given the small time intervals between the difficulty
530 2013-09-04 17:51:48 <runeks> I'm going to try again with measured block times adjustment for difficulty adjustments, and see which r-value is best and go with that.
531 2013-09-04 17:55:18 <Krellan> Question about "listtransactions" API
532 2013-09-04 17:55:27 <Krellan> Is there a way to query by address and not by "account"?
533 2013-09-04 17:55:37 <Krellan> Also, is there a way to include coinbase (immature) in the output?
534 2013-09-04 17:57:18 <Krellan> I noticed it doesn't include immature coins, unfortunately. Wanted to use it to monitor mining profit.
535 2013-09-04 17:58:15 <Krellan> Also, I'm using listtransactions <accountname> 99999999 0, to get as complete list as possible. Is there a cleaner way to say "all" than 99999999?
536 2013-09-04 17:58:53 <gmaxwell> Krellan: listtransactions returns immature coins.
537 2013-09-04 17:59:42 <gmaxwell> 3
538 2013-09-04 17:59:42 <gmaxwell> bitcoind listtransactions "*" 999999999 | grep immature | wc -l
539 2013-09-04 18:00:21 <gmaxwell> Krellan: no wrt address/account, but you can just assign whatever addresses to whatever accounts you want.
540 2013-09-04 18:01:28 <Krellan> Thanks, my bad. As for immature, I meant "listunspent". It doesn't include coinbase, I believe.
541 2013-09-04 18:02:09 <Krellan> Cool, so I can give a star as a wildcard.
542 2013-09-04 18:07:43 <gmaxwell> Krellan: you can tell listunspent to show unconfirmed and I think it will show immature? not sure.
543 2013-09-04 18:07:46 <gmaxwell> ACTION checks
544 2013-09-04 18:08:25 <Krellan> Thanks. I was checking too. Sadly I've been so inept mining recently that I have no immature coins at all!
545 2013-09-04 18:08:32 <Krellan> Will have to check again next time a block hits.
546 2013-09-04 18:08:59 <gmaxwell> Krellan: seems it doesn't.
547 2013-09-04 18:10:08 <Krellan> That's what I remember as well. Think it should be added?
548 2013-09-04 18:11:02 <Krellan> Reason is, I have a script "bitcron". Naturally, it runs as a cron job every minute, and queries Bitcoin. I use it to tell me when I've found a share or pool has found a block.
549 2013-09-04 18:11:42 <Krellan> First draft of script used "listunspent". It was missing immature. Then, I changed it to use "listtransactions" and filter/total the balance up myself.
550 2013-09-04 18:14:05 <Krellan> Interesting how listtransactions takes an address but listunspent takes an account.
551 2013-09-04 18:14:19 <gmaxwell> Krellan: immature is odd since it has to be special cased and no one handles it well
552 2013-09-04 18:15:16 <Krellan> That's kind of what I thought.
553 2013-09-04 18:37:59 <jgarzik> gmaxwell, it is mildly tempted to /require/ the "fee" pseudo-address for all createrawtransaction
554 2013-09-04 18:38:02 <jgarzik> *tempting
555 2013-09-04 18:38:31 <gmaxwell> jgarzik: but fee can't work when you don't know the inputs. And it's important that createraw work on unknown inputs.
556 2013-09-04 18:38:45 <jgarzik> mmm, true
557 2013-09-04 18:38:53 <gmaxwell> (signing an unknown to you input is needed for some contract forms, also offline signing)
558 2013-09-04 18:39:42 <jgarzik> scrypt competitor Catena: http://eprint.iacr.org/2013/525
559 2013-09-04 18:47:10 <gmaxwell> jgarzik: I can't seem to get anything but inputs+fee != outputs with your fee psedo patch btw.. I'm tied up elsewhere and have only spend about 60 seconds on it though. :P
560 2013-09-04 18:47:42 <jgarzik> gmaxwell, will look into it
561 2013-09-04 19:08:15 <_dr> anyone know which heuristic blockchain.info is using for estimated transaction volume/block?
562 2013-09-04 20:13:42 <davec_> hey guys - curious if the behavior in "getheaders" where it pushes an empty headers message if the block locator doesn't find anything, but it doesn't if the block locator is empty and the hash stop doesn't match anything is expected? (https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3673-L3707)
563 2013-09-04 20:13:48 <davec_> seems like both cases should send an empty "getheaders" so the caller knows the request was processed but just didn't find anything
564 2013-09-04 20:13:57 <davec_> errr "headers" message
565 2013-09-04 20:46:22 <jgarzik> gmaxwell, petertodd, amiller: has anyone ever done a design for "SPV p2pool" -- p2pool sans full block chain, that is.
566 2013-09-04 20:47:09 <jgarzik> it would be nice to give miners simple instructions for running software that was decentralized mining, yet did not require full bitcoind
567 2013-09-04 20:47:17 <jgarzik> luke-jr: ^
568 2013-09-04 20:47:23 <gmaxwell> Yes, it's called pooled mining.
569 2013-09-04 20:47:34 <jgarzik> that's not decentralized enough :)
570 2013-09-04 20:47:54 <gmaxwell> It can't be worse than doing no validation at all. :P
571 2013-09-04 20:48:23 <jgarzik> surely you could manage a share chain, and come up with an SPV design that could produce useful-to-the-network blocks
572 2013-09-04 20:49:12 <gmaxwell> If we had a comitted UTXO set something would be possible, but it is not currently possible to produce compact (low storage) proofs of a block's validity.
573 2013-09-04 20:49:55 <jgarzik> yeah, like mempool sampling + UTXO proof
574 2013-09-04 20:50:04 <gmaxwell> If you just want to save disk space you can delete the old blocks already. Excepting for the crashes when someone tries to fetch historical blocks from you that already works. But without a committed UTXO set you need to build your own chainstate and store it.
575 2013-09-04 20:50:51 <jgarzik> gmaxwell, "SPV design" so picking arbitrary goal assume <= 50MB local storage
576 2013-09-04 20:51:09 <jgarzik> i.e. enough to store headers and some additional data
577 2013-09-04 20:51:28 <gmaxwell> if there are UTXO proofs local storage can be zero.. though bandwidth would be quite high.
578 2013-09-04 20:53:22 <jgarzik> gmaxwell, we don't have any way to directly query UTXO set via P2P, alas
579 2013-09-04 20:54:02 <jgarzik> ACTION ponders "gettxouts, input: vector<hash>, output vector<transaction>"
580 2013-09-04 20:54:24 <gmaxwell> every txin (e.g. several per transaction) would need roughly log2(utxo_count) = 28 (currently) * 32 bytes + 35 bytes = about 930 kb of proof. hm. not quite as bad as I thought.
581 2013-09-04 20:55:07 <gmaxwell> The amount of proof for each txout (to prove the update is correct) is similar.
582 2013-09-04 20:56:16 <jgarzik> gmaxwell, why would bandwidth usage be high?
583 2013-09-04 20:56:30 <jgarzik> doesn't seem /necessarily/ a given
584 2013-09-04 20:56:39 <maaku> an efficiently updatable structure is likely to waste more space in the worst case, but the order of magnitude is correct
585 2013-09-04 20:56:57 <gmaxwell> jgarzik: because if you have no storage (just headers) every transaction you mine must have data to prove to you that the inputs are valid.
586 2013-09-04 20:57:06 <gmaxwell> jgarzik: because you can't just tell from local data.
587 2013-09-04 20:57:19 <gmaxwell> It's less bandwidth than I was guessing before I ran the numbers though.
588 2013-09-04 20:57:28 <jgarzik> gmaxwell, no way to merkle-ize unspent outputs?
589 2013-09-04 20:57:32 <maaku> gmaxwell: that case is interesting for hardware wallets, which could sync their wallet over a high-bandwidth usb connection
590 2013-09-04 20:58:05 <gmaxwell> jgarzik: the numbers I was giving there were assuming a merkleized utxo set. Thats where the log2() comes from.
591 2013-09-04 20:58:21 <jgarzik> in general, I think "SPV mining" could be a /big/ win for decentralized mining, if such a design is possible and healthy for the network
592 2013-09-04 20:58:23 <gmaxwell> Without that the "proof" for a spendable output is the whole blockchain. :P
593 2013-09-04 20:58:49 <jgarzik> because a lot of people will otherwise turn to pools, if mining is not "run this program" easy and quick
594 2013-09-04 20:59:41 <gmaxwell> jgarzik: I'm certantly supportive of making it possible, but my cynicism prevents me from thinking it will work. I'm also concerned that promoting it that way may make it mysterously hard to get committed utxo deployed. :(
595 2013-09-04 21:00:54 <gmaxwell> being able to make compact block validtity proofs is very important regardless: the exact same things are needed in order to have "SPV" wallets that do randomized validity testing and fraud proofs.
596 2013-09-04 21:01:19 <jgarzik> gmaxwell, definitely would like to see committed utxo out there. I'm radical enough to think we should just go ahead and stick UTXO hash_serialized or similar into our CreateNewBlock() code right now.
597 2013-09-04 21:01:42 <jgarzik> the main thing restraining me are the implications of pruning rule agreement
598 2013-09-04 21:01:50 <gmaxwell> jgarzik: hash_seralized isn't sutiable because it's insanely slow and can't be updated. :P
599 2013-09-04 21:02:05 <gmaxwell> a tree version of it, otoh, would be pretty simple.
600 2013-09-04 21:03:00 <jgarzik> just insert <tag><tree hash> into coinbase. <tag> can be changed any time there is a binary compatibility or rules change, perhaps.
601 2013-09-04 21:03:12 <gmaxwell> I'd privately suggested to petertodd that he go jump maaku's work with a four line patch that makes hash_serialized tree structured and also can emit small membership proofs. :P
602 2013-09-04 21:03:30 <gmaxwell> jgarzik: making it actually useful takes more than thatâ you need to make the correctness of such tags a block validity rule.
603 2013-09-04 21:03:31 <jgarzik> pushdata("utxo1") pushdata(hash)
604 2013-09-04 21:03:34 <gmaxwell> Simply adding the data isn't enough.
605 2013-09-04 21:03:51 <gmaxwell> (certantly it can start with just adding it)
606 2013-09-04 21:03:56 <jgarzik> agreed -- but it's an important and necessary first step, and it gives people things to work on
607 2013-09-04 21:04:35 <jgarzik> gmaxwell, and it will help accomplish your goal of making it hard to get it deployed
608 2013-09-04 21:04:40 <jgarzik> ER
609 2013-09-04 21:04:49 <jgarzik> NOT making it hard
610 2013-09-04 21:04:53 <gmaxwell> without tree-structuring the hash though, it's not very useful. Since you can't extract a compact proof out of it.
611 2013-09-04 21:05:08 <amiller> where's maaku's work
612 2013-09-04 21:05:13 <maaku> hash_serialized does not enable proof construction...
613 2013-09-04 21:05:15 <amiller> does he have notes on github or something
614 2013-09-04 21:05:17 <jgarzik> nod -- tree structure it
615 2013-09-04 21:05:31 <amiller> hi maaku, i'd really like to follow along with whatever you're doing!
616 2013-09-04 21:05:35 <maaku> amiller: here, mostly : https://github.com/monetizeio/python-bitcoin/blob/master/bitcoin/patricia.py
617 2013-09-04 21:07:08 <gmaxwell> thats a whole lot of code for something normative. :(
618 2013-09-04 21:07:11 <maaku> jgarzik: what i meant was that a standard merkle list is not efficiently updatable
619 2013-09-04 21:07:37 <jgarzik> en gross, what we need is a "merkle stream"
620 2013-09-04 21:07:53 <jgarzik> *grosse
621 2013-09-04 21:08:37 <maaku> care to expand on that?
622 2013-09-04 21:09:01 <gmaxwell> jgarzik: we actually do need a tree structure here, since we need to do random deletes and inserts. (if you want something that does efficient appends petertodd came up with the thing he calls a merkle mountain range, but thats not what we need here)
623 2013-09-04 21:09:33 <gmaxwell> maaku: how big are your update proofs?
624 2013-09-04 21:10:05 <maaku> gmaxwell: kilobytes, for the tests that i've done
625 2013-09-04 21:11:30 <gmaxwell> Sounds a bit large to me. I mean, if you do a prefix trie which is strictly key structured with no level compression, you end up with constant size lookup and update proofs of 8192 bytes.
626 2013-09-04 21:11:35 <maaku> it's level compressed and node compressed - so there's only as many levels as you need, and each level has only as many hashes as there are branches (up to 256)
627 2013-09-04 21:12:05 <gmaxwell> oh if you have more than two children of a node that will murder proof efficiency!
628 2013-09-04 21:12:14 <maaku> yes, it will
629 2013-09-04 21:12:20 <gmaxwell> since you end up having to transmit all the children if you touch a node at all.
630 2013-09-04 21:12:38 <maaku> one of the next tests I'm doing to run is trying branching factors of 16 & 4
631 2013-09-04 21:12:44 <maaku> but those have extra cpu burden
632 2013-09-04 21:13:00 <gmaxwell> Proofs will such unless your branching factor is 2.
633 2013-09-04 21:13:04 <gmaxwell> er suck. :)
634 2013-09-04 21:13:42 <jgarzik> sounds pretty far out, even if I code it ;p
635 2013-09-04 21:13:47 <gmaxwell> You can always take a scheme with a high branching factor and replace its interior nodes with a binary tree, with just special values on non-existing children.
636 2013-09-04 21:13:53 <jgarzik> ACTION goes back to pondering bounties for p2pool instructions in Chinese
637 2013-09-04 21:14:05 <gmaxwell> jgarzik: I will match your p2pool bounties. :P
638 2013-09-04 21:15:08 <gmaxwell> jgarzik: as far as decenteralizing mining, I think in the long term things like what you're talking about make sense... but in the short term, I'd like to at least get all the people who are willing to run a bitcoind node able to use one for mining without taking the variance bath.
639 2013-09-04 21:15:24 <gmaxwell> Though, its less of an issue now that p2pool has grown some more.
640 2013-09-04 21:15:51 <jgarzik> Yah -- any p2pool instructions would necessarily require bitcoind instructions, including an honest "resource requirements" preface
641 2013-09-04 21:15:54 <gmaxwell> p2pool is about 1.2% of the network hashrate now.
642 2013-09-04 21:16:39 <gmaxwell> jgarzik: yea, there are crazy people running p2pool+bitcoind on some under powerered hardware. I think being frank about the requirements is important though, because if you run it on your raspberry pi you will .. uh. not have a good expirence.
643 2013-09-04 21:16:45 <maaku> gmaxwell: yeah, a merkle-list within the interior node is current strategy for the proofs
644 2013-09-04 21:19:40 <gmaxwell> I'm not quite sure why thing can't be as simple as coding node = H(is left a leaf |H(left) | is right a leaf | H(right)) and just order by key (which is a hash)?
645 2013-09-04 21:20:41 <gmaxwell> But I confess, I've not thought much about update proofs.
646 2013-09-04 21:21:08 <maaku> that is basically it