1 2012-09-12 01:18:08 <jgarzik> gmaxwell: huh, I stand corrected
  2 2012-09-12 01:18:14 <jgarzik> gmaxwell: it looks like IsFinal is broken
  3 2012-09-12 01:22:21 <gmaxwell> And there is now at least one transaction in the chain with an invalid IsFinal. I think it's more than a little horrifying that we're not hearing screams from alternatie implementations.
  4 2012-09-12 01:35:06 <midnightmagic> gmaxwell: Perhaps they don't know about it, or they haven't realised the magnitude of the issue.
  5 2012-09-12 01:44:52 <gmaxwell> midnightmagic: I mean, either they impose the rule and they're stuck now, and I don't see any evidence of that.
  6 2012-09-12 01:45:18 <gmaxwell> Or they don't. In which case... so much for alternative implementations. I think it would be really hard to copy that bug if you were reading the code at all.
  7 2012-09-12 01:47:03 <Luke-Jr> lol
  8 2012-09-12 01:52:30 <kjj_> oh dear god.
  9 2012-09-12 01:53:41 <jgarzik> gmaxwell: alternative implementations tend to just cover the basics
 10 2012-09-12 01:53:44 <kjj_> is that nested test construction in CTransaction::IsFinal common enough in C++ that people can actually read it without drawing a diagram?
 11 2012-09-12 01:53:57 <jgarzik> gmaxwell: I don't know of a single alternative implementation with 100% coverage vis a vis the ref client
 12 2012-09-12 01:56:12 <jgarzik> The network relies on the protection of the satoshi reference client a great deal
 13 2012-09-12 01:57:17 <jgarzik> other implementations are "lazy" in various ways, and it doesn't usually matter, because omitting some checks is penalty-free is The Masses continue to do proper checking.
 14 2012-09-12 02:20:48 <jgarzik> gmaxwell: is Opus better than mp3, for the typical mp3 application (playing a stored collection of music)?
 15 2012-09-12 02:20:57 <jgarzik> </ot>
 16 2012-09-12 02:22:52 <kjj_> mp3 is smallish, decodes fast even on old CPUs, and sounds good if encoded properly.  also, it is supported pretty much everywhere
 17 2012-09-12 02:23:12 <Luke-Jr> jgarzik: in case you didn't see it yet: http://opus-codec.org/comparison/
 18 2012-09-12 02:23:31 <kjj_> dozens of competitors have popped up over the last 20 years, none have offered any really good reasons to switch
 19 2012-09-12 02:23:49 <Luke-Jr> but who needs Opus when you can just hack into the LHC and compress your data with its mini black hole? </troll> ;)
 20 2012-09-12 02:24:04 <Luke-Jr> kjj_: except that just about nothing uses MP3 anymore?
 21 2012-09-12 02:24:29 <kjj_> you mean, not counting every device made in the last 15 years or the next 100?  that nothing?
 22 2012-09-12 02:24:39 <jgarzik> Luke-Jr: yah, that comparison does not really cover technical issues like software decode speed, hardware implementation difficulty, etc.
 23 2012-09-12 02:25:03 <Luke-Jr> jgarzik: the FAQ talks about it being easy to use in embedded RTOS at least *shrug*
 24 2012-09-12 02:25:12 <Luke-Jr> kjj_: I mean actual data
 25 2012-09-12 02:25:32 <kjj_> the patent issue is about the only really interesting argument against mp3, and for the most part, no one cares
 26 2012-09-12 02:26:06 <kjj_> Luke-Jr: I'm no longer sure what you are talking about.  what actual data do you mean?
 27 2012-09-12 02:26:20 <Luke-Jr> kjj_: audio and video files.
 28 2012-09-12 02:26:32 <Luke-Jr> I don't recall the last time I saw them using MP3
 29 2012-09-12 02:26:48 <kjj_> who are them?
 30 2012-09-12 02:27:22 <Luke-Jr> just various files online
 31 2012-09-12 02:27:39 <Luke-Jr> then again, I don't go looking for music generally either
 32 2012-09-12 02:27:44 <gmaxwell> jgarzik: Yes, very much so.  ... well, so long as your metric for better doesn't include compatiblity with a billion preexisting devices.
 33 2012-09-12 02:27:50 <kjj_> if you are ripping yourself, mp3 is just fine, and odds are good that you already have the codec
 34 2012-09-12 02:28:11 <Luke-Jr> kjj_: if you're ripping yourself, I don't know why you wouldn't use FLAC.
 35 2012-09-12 02:28:22 <kjj_> if you aren't ripping yourself, unless you are coming from a lossless format, you lose when you re-code
 36 2012-09-12 02:28:28 <jgarzik> being a nutter open source purist, my systems do not, in fact, automatically have mp3 support
 37 2012-09-12 02:28:37 <jgarzik> even in the year 2012
 38 2012-09-12 02:28:46 <kjj_> Luke-Jr: because I own probably about 20 devices that understand mp3, but don't understand FLAC
 39 2012-09-12 02:29:29 <gmaxwell> kjj_: roughly half the bitrate of mp3, realistically, and having low enough latency to use for interactive use (voip, telepresence, real time remote music jamming), etc are not tiny selling points.
 40 2012-09-12 02:29:49 <Luke-Jr> jgarzik: if you consider that in theory, software patents are invalid, and in practice, nobody will bother you, and finally that MP3 decoders are open source, I'm not sure where the objection comes from ???
 41 2012-09-12 02:30:08 <Luke-Jr> kjj_: I see. I don't use such devices.
 42 2012-09-12 02:30:10 <kjj_> jgarzik: isn't LAME open source?  mp3 is only an issue for "free software" people because they can't legally redistribute due to patent issues
 43 2012-09-12 02:30:34 <Luke-Jr> 
ACTION facepalms

 44 2012-09-12 02:30:48 <gmaxwell> kjj_: and people do care about mp3 licensing, it's a couple bucks per decoder noq.. not joe blow on the internet.. but think about how much you've paid for mp3 over and over again in every device you've purchased made by large companies who can't count on it being bad PR to sue them.
 45 2012-09-12 02:32:14 <gmaxwell> kjj_: FWIW, I got involved with RF codecs because I deployed lame at my job (and I wrote the initial lame VBR support), and I had a sales person come in and fud me about patents when I said I didn't need his product because I'd made something superior. And, at the tender age of 18 fully expected him to walk into my legal department and get me fired from my very conservative workplace.
 46 2012-09-12 02:32:47 <kjj_> heh
 47 2012-09-12 02:33:05 <gmaxwell> In hindsight, he would have had to awfully desperate to actually do that. But he sure scared me. Didn't work for him, I jumped in with the vorbis project and rapidly switched things over.
 48 2012-09-12 02:34:41 <kjj_> meh.  in 5 years, the patents on MP3 will all have expired
 49 2012-09-12 02:36:21 <gmaxwell> kjj_: sure, and you'll have a twenty something year old format that kinda sucks. One requires vaguely twice the bitrate and has high latency that makes it unusable for realtime applications.
 50 2012-09-12 02:37:13 <kjj_> and I suspect that it will still be "good enough" in 2017, just like it is now
 51 2012-09-12 02:37:41 <gmaxwell> kjj_: It is completely unusable for realtime usage. Talking through mp3 is like talking through a sat phone.
 52 2012-09-12 02:37:46 <kjj_> for typical playback usages, it is really hard to justify re-ripping everything
 53 2012-09-12 02:37:55 <gmaxwell> kjj_: sure, don't do that.
 54 2012-09-12 02:38:19 <gmaxwell> If you rerip things it should be lossless. Diskspace is cheap. Then you can transcode to whatever mobile formats are convient for you at the time.
 55 2012-09-12 02:38:20 <kjj_> gmaxwell: haha.  I was just going to type the exact same thing about your realtime comment
 56 2012-09-12 02:38:27 <da2ce7> 320 MP3 is "ok" providing you are encoding it with a good encoder (such as lame).
 57 2012-09-12 02:39:05 <gmaxwell> But if you're streaming, or no a space constrained portable device the space matters. If it doesn't matter.. lossless is only twice again the size of a 320k mp3 for most content.
 58 2012-09-12 02:39:34 <kjj_> da2ce7: and you need very good ears, or a fairly good imagination, to hear the difference between a good encoder and a merely decent one, or from 320k to 256k
 59 2012-09-12 02:40:51 <da2ce7> kjj_: 320 vs 256 on a good encoder I would agree with you (I cannot tell the difference with my studio-grade gear), however 320 bad encoder and 320 good encoder can be night and day.
 60 2012-09-12 02:41:39 <gmaxwell> kjj_: well the spectrum isn't good vs decent, it's usually good vs bad. or good vs very bad. E.g. the iso mpeg reference source that almost everything is based on was horiffic. It managed to make the short block decision and put it in the wrong frame.
 61 2012-09-12 02:42:03 <gmaxwell> You could absolutely abx bladeenc (just a speed optimized copy of the refrence encoder) at 320kbit/sec.
 62 2012-09-12 02:43:58 <kjj_> I haven't been looking very hard, but it has been a LONG time since I came across a badly encoded mp3
 63 2012-09-12 02:47:36 <osmosis> why did I get this sanity-test fail?  http://jenkins.bluematt.me/pull-tester/224222746698db200d4c47e1611219f25fc5aa71/
 64 2012-09-12 02:49:18 <jgarzik> 
ACTION rips to FLAC, but sadly nobody supports that in any device I've ever owned

 65 2012-09-12 02:49:42 <kjj_> jgarzik: rockbox
 66 2012-09-12 02:50:27 <kjj_> not an option for your car, most likely.  but I think there are decks that support FLAC now.  and line-in is very common
 67 2012-09-12 02:51:10 <Luke-Jr> pretty sure it works on Nokia N900 <.<
 68 2012-09-12 02:52:12 <doublec> some of the korean digital media players support flac too
 69 2012-09-12 02:52:50 <xisalty> android does too
 70 2012-09-12 02:53:13 <kjj_> rockbox is pretty cool though.  you can even get an old-school Winamp skin that makes your mp3 player look just like 1996
 71 2012-09-12 02:53:38 <kjj_> er, 1997 rather
 72 2012-09-12 02:56:06 <jgarzik> neat.  it sounds like Samsung Galaxy S has FLAC support.
 73 2012-09-12 02:56:30 <Luke-Jr> 
ACTION wonders how much disk space modern smartphones have these days

 74 2012-09-12 02:56:37 <Luke-Jr> 
ACTION has 64 GB in his N900

 75 2012-09-12 02:56:40 <jgarzik> 16GB here.
 76 2012-09-12 02:56:46 <xisalty> 8GB-16GB is average
 77 2012-09-12 02:56:47 <jgarzik> easily upgradable
 78 2012-09-12 02:56:51 <xisalty> ^
 79 2012-09-12 02:56:54 <doublec> if they don't allow SD cards it's usually 8-32GB
 80 2012-09-12 02:57:03 <jgarzik> and if my phone supports it, then my car support it.
 81 2012-09-12 02:57:09 <jgarzik> *supports
 82 2012-09-12 02:57:14 <doublec> I have a 64GB card in my n900
 83 2012-09-12 02:57:35 <xisalty> thats about how much spaec my laptop has
 84 2012-09-12 02:57:56 <jgarzik> my first hard drive was 128MB :)
 85 2012-09-12 02:58:09 <osmosis> if you got an android phone, you can play FLAC files just fine
 86 2012-09-12 02:58:20 <gmaxwell> kjj_: rockbox has opus support (well, I think not yet in the latest shipping version)
 87 2012-09-12 02:58:23 <gmaxwell> :P
 88 2012-09-12 02:58:55 <jgarzik> osmosis: s//recent/
 89 2012-09-12 02:59:03 <kjj_> heh, I don't actually use it any more.  I'm rarely far enough away from a proper computer to need a MP3 player.
 90 2012-09-12 02:59:21 <kjj_> I mostly got it to look into writing a bitcoin plugin for the UI to use as a hardware wallet
 91 2012-09-12 02:59:41 <jgarzik> in 10 years, all computers will be the size of your phone.  they will be the size necessary for the various input/output plugs, and no more.
 92 2012-09-12 03:00:13 <xisalty> I wish
 93 2012-09-12 03:00:19 <jgarzik> 
ACTION chuffs at "proper computer"

 94 2012-09-12 03:00:38 <kjj_> hmm.  I'm thinking about video cards from 5, 10, 20 and 25 years ago, and I think the trend there is going in the other direction
 95 2012-09-12 03:02:14 <kjj_> the old HGC cards were friggin huge, but thin.  they got smallish for a while, but steady growth in all three dimensions since the late 90s
 96 2012-09-12 03:02:48 <kjj_> well, VLB was an exception, but that was because of the connector.
 97 2012-09-12 03:03:33 <Luke-Jr> jgarzik: we can already put 5 year old technology in that size, but still we make/use desktop PCs ;)
 98 2012-09-12 03:03:54 <jgarzik> desktop PC sales continue to fall through the floor, and nobody thinks that will recover
 99 2012-09-12 03:03:55 <kjj_> even worse, the portable things we have now, phones, tablets, etc, are FAR from real computers.  they have all of the right parts, but too often, they have a bunch of wrong parts too
100 2012-09-12 03:04:03 <Luke-Jr> no matter how advanced you get, the non-miniaturized computer will always outperform the smaller ones - and more importantly, be hand-customizable
101 2012-09-12 03:04:20 <jgarzik> desktops will disappear, and only "workstations" will remain, for the few programmers in the crowd.
102 2012-09-12 03:04:28 <xisalty> yup
103 2012-09-12 03:04:33 <Luke-Jr> kjj_: I run Gentoo and KDE on my N900.
104 2012-09-12 03:04:38 <kjj_> I absolutely despise android, for example
105 2012-09-12 03:04:38 <xisalty> its all going the way of the mobile market now
106 2012-09-12 03:05:46 <Luke-Jr> anyone know a reasonable GUI debugger that can intermix source and assembly?
107 2012-09-12 03:06:04 <Luke-Jr> I liked insight, but it seems they can't get it to work these days :/
108 2012-09-12 03:06:25 <kjj_> do you mean a debugger for a GUI, or a GUI-based debugger?
109 2012-09-12 03:06:31 <Luke-Jr> GUI-based debugger
110 2012-09-12 03:06:48 <Luke-Jr> heck, commandline would be fine too, but gdb doesn't make nice when the debugging symbols suck
111 2012-09-12 03:06:55 <kjj_> ok, phew.  for a minute there, I was wondering what the hell you were working on
112 2012-09-12 03:08:11 <kjj_> what's wrong with your symbols?  are you debugging a project with linked ASM and .c or .cpp objects?  or just have a lot of inline assembly?
113 2012-09-12 03:09:15 <Luke-Jr> I don't know. I compiled with -O0 -ggdb, and still getting weird info
114 2012-09-12 03:09:30 <Luke-Jr> shouldn't be any assembly in my current build
115 2012-09-12 03:10:40 <kjj_> that's really odd then.  usually don't run into that unless someone slips you a stripped library
116 2012-09-12 03:11:21 <Luke-Jr> ==5330== Invalid read of size 1
117 2012-09-12 03:11:23 <Luke-Jr> ==5330==    at 0x4201FE7: strtok (strtok.S:196)
118 2012-09-12 03:11:24 <Luke-Jr> ==5330==    by 0x804D6E7: load_config (miner.c:1297)
119 2012-09-12 03:11:27 <Luke-Jr> line 1297 doesn't call strtok
120 2012-09-12 03:12:01 <kjj_> what does line 1297 really do?
121 2012-09-12 03:12:09 <kjj_> or, is there a nearby strtok?
122 2012-09-12 03:12:41 <Luke-Jr> it calls a function that calls strtok (not at the end)
123 2012-09-12 03:13:10 <kjj_> the load_config function?
124 2012-09-12 03:13:18 <Luke-Jr> hmm, actually gdb itself is giving me a sane stack
125 2012-09-12 03:13:29 <Luke-Jr> load_config calls parse_config calls strtok in a loop
126 2012-09-12 03:13:57 <gmaxwell> Luke-Jr: try with -fno-builtin
127 2012-09-12 03:14:36 <Luke-Jr> gmaxwell: no change
128 2012-09-12 03:15:10 <gmaxwell> (the compiler has internal implementations of some simple ansic functions that get inlined implicitly, e.g. ABS, I think that even happens at -O0)
129 2012-09-12 03:15:14 <gmaxwell> darn
130 2012-09-12 03:15:34 <gmaxwell> Luke-Jr: so where do you endup if you run valgrind with --db-attach ?
131 2012-09-12 03:16:28 <kjj_> I guess I would try to hit a breakpoint before the load_config call and single step into it
132 2012-09-12 03:17:31 <Luke-Jr> gmaxwell: the correct line
133 2012-09-12 03:17:39 <kjj_> not exactly a subtle or skilled technique, but sometimes helps clear things up
134 2012-09-12 03:17:42 <Luke-Jr> I think I found the bug too :D
135 2012-09-12 03:18:37 <Luke-Jr> nested strtok ???
136 2012-09-12 03:18:52 <Luke-Jr> 
ACTION sighs at Windows portability of nestable strtok

137 2012-09-12 03:21:33 <kjj_> ugh.  I'd love to see the code for that.  what does it do, snoop on the stack to see which string it should be chopping?
138 2012-09-12 03:25:16 <Luke-Jr> kjj_: I imagine it just uses a static variable.
139 2012-09-12 03:25:35 <Luke-Jr> POSIX has strtok_r to sanitize it, but Windows doesn't
140 2012-09-12 03:26:15 <kjj_> yeah, the static variable part is easy.  but how do you nest that safely without cheating to figure out which level you are being called from?
141 2012-09-12 03:27:55 <kjj_> or were you talking about strtok_r shen you said "nestable strtok" ?
142 2012-09-12 03:29:12 <kjj_> ahh, you were indeed.  I missed the POSIX line.  strtok_r should be easy enough to fake if you want to run it in Windows
143 2012-09-12 03:32:38 <kjj_> so, has anyone been scanning the chain to see if there are more nLockTime violations?
144 2012-09-12 07:28:40 <jdnavarro> in the protocol specification for a tx message, when there is no output how is it represented over the wire? is it filled with 0s or just skipped?
145 2012-09-12 07:28:43 <jdnavarro> https://en.bitcoin.it/wiki/Protocol_Specification#tx
146 2012-09-12 07:39:08 <jdnavarro> just found out by looking at bitcoinjs source code that just the number of output transactions (0) is serialized in this case
147 2012-09-12 08:03:56 <wumpus> ok, please update that in the wiki
148 2012-09-12 08:49:38 <seco> hey guys, ive looked a bit into the current rc2 of bitcoin-qt, and im impressed about the speeds as well about the changes in the UI :)
149 2012-09-12 08:50:17 <seco> but you know..there is no UI someone cannot find a thing which disturbs one hehe
150 2012-09-12 09:38:28 <theorbtwo> Anybody here at the post-bitcoin-conference hackathon in the london hackspace?
151 2012-09-12 09:40:00 <theorbtwo> OK, guess not.
152 2012-09-12 09:50:48 <jeremias> lc
153 2012-09-12 09:51:18 <jeremias> theorbtwo: I plan to go there tomorrow
154 2012-09-12 09:53:51 <theorbtwo> jeremias: Cool, but maybe actually ask for permission first, or have it somewhere else?
155 2012-09-12 09:54:44 <theorbtwo> (Popping in #london-hack-space might be a good idea.)
156 2012-09-12 10:00:03 <firelegend> Was the p2sh thing accepted?
157 2012-09-12 10:00:21 <jeremias> theorbtwo: I don't know anything about that...
158 2012-09-12 10:00:49 <jeremias> theorbtwo: it seems pretty badly organized, it was supposed to be at another location, and the location changed like today
159 2012-09-12 10:01:17 <jeremias> I was organizing the previous berlin hackathon, but in this I haven't been involved
160 2012-09-12 10:01:41 <theorbtwo> jeremias: *nod*
161 2012-09-12 10:02:04 <Luke-Jr> firelegend: that was always a given, BIP 16 went active in April
162 2012-09-12 10:02:24 <theorbtwo> Anyway, it looks like there's now actual talking between the groups, so it's working, somewhat.
163 2012-09-12 10:16:25 <Luke-Jr> hmm, cute. Deepbit's blocked me
164 2012-09-12 10:30:58 <sipa> jgarzik, gmaxwell: afaik nLockTime works, but you need an nSequence in one of the inputs that is not yet INT_MAX
165 2012-09-12 10:39:08 <sipa> jgarzik: afaik it's transaction replacement that is disabled, not transaction locking
166 2012-09-12 10:39:24 <sipa> jgarzik: and that doesn't even need a softfork to re-enable
167 2012-09-12 10:41:43 <gmaxwell> sipa: why would nSequence in one of the inputs not being INT_MAX be intended to be required?
168 2012-09-12 10:42:43 <sipa> gmaxwell: if all inputs have nSequence==MAX, the transaction can't be replaced, and as such, it's inevitably final
169 2012-09-12 10:44:13 <sipa> we could *right now* just switch to nSequence==0 in all txins, and nothing would change, except nLockTime would behave are intended
170 2012-09-12 10:46:36 <kjj_> are you sure about that?  is IsFinal supposed to return true if the transaction is final like you'd expect from the name?
171 2012-09-12 10:47:35 <gmaxwell> sipa: Indeed, I follow now. I hadn't realized that.
172 2012-09-12 10:48:35 <sipa> kjj_: yes
173 2012-09-12 10:54:30 <gmaxwell> It would hae been more intutive, and useful, if a nSequence==max transaction was still time locked, but was invalid until after the time.. so that it couldn't be put into the memory pool or relayed
174 2012-09-12 10:54:52 <gmaxwell> This way you could still do 'offline' replacement, by creating a locked transaction.
175 2012-09-12 10:55:41 <sipa> indeed; i think satoshi considered transaction replacement to be the only usecase for transaction locking
176 2012-09-12 10:58:52 <gmaxwell> I think a lot of the examples for nlocktime that people have given that don't require in network replacement, are gummed up by this. E.g. prefabbing a refund transaction for an escrow to reduce risk... since the locked refund if accepted by the network would inhibit the real spend. ::sigh::
177 2012-09-12 11:00:29 <sipa> well there's no problem in using nSequence=0 in those cases
178 2012-09-12 11:01:45 <eian> good morning
179 2012-09-12 11:02:20 <eian> Where is the latest release candidate available? Is it just the github master branch?
180 2012-09-12 11:02:49 <sipa> eian: there are a few changes in git master w.r.t. rc2
181 2012-09-12 11:03:20 <eian> is rc2 on your subversion repo?
182 2012-09-12 11:03:33 <sipa> nobody uses svn anymore
183 2012-09-12 11:03:37 <eian> oh :)
184 2012-09-12 11:03:58 <gmaxwell> sipa: sure, but since you can't replace the transaction in the network, someone can just instantly announce the refund, and then it becomes hard to spend the intended real spend.
185 2012-09-12 11:04:24 <sipa> gmaxwell: hmm?
186 2012-09-12 11:05:08 <sipa> non-final transactions are accepted into the memory-pool
187 2012-09-12 11:05:19 <sipa> (mental note: DoS risk)
188 2012-09-12 11:06:41 <gmaxwell> right. Thats my point. I write an escrow transaction with you. Before I give it to you/network I make you write a refund 180 days from now that sends the funds back to me if the escrow isn't resolved. Once you do I announce the payment into the escrow.
189 2012-09-12 11:06:51 <sipa> gmaxwell: got it
190 2012-09-12 11:08:28 <kjj_> phew.  we need to get Theymos to add sequence to his dump
191 2012-09-12 11:14:28 <sipa> what dump?
192 2012-09-12 11:15:32 <michaelmclees> I have a quick question
193 2012-09-12 11:15:50 <michaelmclees> i restored a wallet but the coins are no longer showing in the client
194 2012-09-12 11:15:58 <michaelmclees> the transactions are not there either
195 2012-09-12 11:16:38 <michaelmclees> is there a rescan tool or something that will pop them up
196 2012-09-12 11:16:44 <michaelmclees> here is the address 1BkLsW9eY82rZCe9DdVYnKKeL18n98Z7kF
197 2012-09-12 11:16:56 <sipa> how old was the backup?
198 2012-09-12 11:17:08 <michaelmclees> a couple weeks
199 2012-09-12 11:17:26 <sipa> are the transactions missing, or marked unconfirmed?
200 2012-09-12 11:17:35 <michaelmclees> transactions not there at all
201 2012-09-12 11:17:40 <PK> michaelmclees, did you do that rescan thing you mentioned?
202 2012-09-12 11:17:48 <sipa> no need
203 2012-09-12 11:17:50 <michaelmclees> there should be 2 as stated in the block explorer
204 2012-09-12 11:17:55 <PK> it's bitcoind -rescan
205 2012-09-12 11:18:00 <sipa> michaelmclees: did you catch up with the blockchain entirely?
206 2012-09-12 11:18:05 <michaelmclees> yeah
207 2012-09-12 11:18:23 <sipa> ok, try running with -rescan, but i doubt it will help
208 2012-09-12 11:18:34 <sipa> (unless you're running a very old bitcoin)
209 2012-09-12 11:18:41 <michaelmclees> i have the latest
210 2012-09-12 11:19:19 <PK> michaelmclees, did you restore after catching up to the block chain? In that case the rescan works. We had the same issue in #bitcoin a few days ago and the rescan fixed it.
211 2012-09-12 11:19:59 <michaelmclees> well, yeah... but won't that always be the case?
212 2012-09-12 11:20:11 <michaelmclees> any time you restore, the block chain is longer than when you backed up
213 2012-09-12 11:20:26 <sipa> in almost all cases, bitcoin will automatically rescan the part of the blockchain that the wallet didn't know about
214 2012-09-12 11:20:42 <sipa> since 0.3.21 or so
215 2012-09-12 11:20:47 <chmod755> "This transaction is over the size limit.  You can still send it for a fee of 0.99 BTC, which goes to the nodes that process your transaction and helps to support the network.  Do you want to pay the fee?" << WTF?????? NO
216 2012-09-12 11:21:09 <sipa> chmod755: that must be one hell of a transaction
217 2012-09-12 11:21:13 <eian> haha
218 2012-09-12 11:21:14 <sipa> many very small inputs?
219 2012-09-12 11:21:55 <chmod755> mm
220 2012-09-12 11:22:03 <chmod755> omg
221 2012-09-12 11:23:07 <michaelmclees> do i run rescan while the client is closed
222 2012-09-12 11:23:16 <michaelmclees> and then open the client after i do the command?
223 2012-09-12 11:23:53 <sipa> it's a command-line option to the client
224 2012-09-12 11:24:02 <sipa> and when passed, it will do a full rescan at startup
225 2012-09-12 11:24:04 <chmod755> why does it say  "Error: Transaction creation failed"
226 2012-09-12 11:24:34 <michaelmclees> when i have the client running, i can't do the command
227 2012-09-12 11:24:36 <sipa> chmod755: because it couldn't create a valid transaction that satisfies the requirement
228 2012-09-12 11:24:44 <michaelmclees> when i have the command running, i can't open the client
229 2012-09-12 11:24:59 <michaelmclees> so now that i am doing the rescan, do i close the daemon and then open?
230 2012-09-12 11:25:07 <sipa> michaelmclees: there is no "command", it's a flag to the client
231 2012-09-12 11:25:17 <sipa> michaelmclees: so exit the client, and start it again with that flag
232 2012-09-12 11:26:23 <michaelmclees> but what I'm saying is, im rescanning now... or ive opened the command prompt, found the directory and typed "bitcoind -rescan"
233 2012-09-12 11:26:38 <michaelmclees> right now the cursor is just blinking
234 2012-09-12 11:26:53 <michaelmclees> if i attempted to open the qt client, it says bitcoin is already running
235 2012-09-12 11:26:56 <Joric> is pruning firstbits compatible?
236 2012-09-12 11:27:25 <sipa> michaelmclees: ooh, now i see; you could just have done "bitcoin-qt -rescan" as well
237 2012-09-12 11:27:36 <sipa> Joric: no, one of its many weaknesses
238 2012-09-12 11:27:37 <Joric> if not maybe it's worth to make it compatible for that matter
239 2012-09-12 11:27:46 <michaelmclees> oh... well let me try that then
240 2012-09-12 11:29:36 <michaelmclees> is rescanning going to have me download the whole chain again?
241 2012-09-12 11:29:45 <sipa> no
242 2012-09-12 11:29:56 <gmaxwell> Joric: you should have said is firstbits pruning compatible. And I don't see any way to make it so, which is just one of many reasons firstbits should not be used.
243 2012-09-12 11:30:44 <sipa> firstbits relies on the exact history of the chain, and not just its final state
244 2012-09-12 11:31:04 <sipa> so you can't calculate firstbits (or the firstbits database) without processing the history
245 2012-09-12 11:31:33 <chmod755> sipa: tried changing the transaction but it still doesnt work :/
246 2012-09-12 11:32:18 <sipa> chmod755: a small calculation shows me you're trying to create a transaction with >8000 inputs?
247 2012-09-12 11:32:27 <chmod755> no
248 2012-09-12 11:32:31 <chmod755> not really
249 2012-09-12 11:32:33 <gmaxwell> (others off the top of my head being the spam potential, the limited supply from pow searching, the severe hazard of typosquatting (esp since txn can't be reversed), the inability to securely transfer a firstbits address to another party, the unfriendlyness of the base58 charset for names)
250 2012-09-12 11:32:56 <sipa> gmaxwell: and the general encouragement of address reuse?
251 2012-09-12 11:33:05 <chmod755> ROFL "This transaction is over the size limit.  You can still send it for a fee of 2.00 BTC, which goes to the nodes that process your transaction and helps to support the network.  Do you want to pay the fee?"
252 2012-09-12 11:33:27 <michaelmclees> haha
253 2012-09-12 11:33:36 <sipa> chmod755: HOW small are your inputs?
254 2012-09-12 11:33:41 <michaelmclees> were you running a bot to bet on satoshi dice at .001btc or something?
255 2012-09-12 11:33:56 <chmod755> some are tiny, some are big
256 2012-09-12 11:34:06 <michaelmclees> bingo, the rescan worked
257 2012-09-12 11:34:07 <chmod755> michaelmclees: no
258 2012-09-12 11:34:16 <michaelmclees> thank you guys!
259 2012-09-12 11:34:48 <sipa> michaelmclees: when you made the backup, which client version were you running?
260 2012-09-12 11:35:14 <helo> it would be nice if the size limit dialog allowed you to get more details
261 2012-09-12 11:35:14 <michaelmclees> hmm.... not sure, it was probably 2 versions before i think
262 2012-09-12 11:35:28 <sipa> michaelmclees: 0.6.1 then?
263 2012-09-12 11:35:34 <michaelmclees> i think so
264 2012-09-12 11:35:39 <sipa> very strange
265 2012-09-12 11:35:42 <michaelmclees> but i can't say for certain
266 2012-09-12 11:35:51 <chmod755> sipa: looks like the client changes the suggestion based on my fee setting
267 2012-09-12 11:36:02 <chmod755> "This transaction is over the size limit.  You can still send it for a fee of 0.099 BTC, which goes to the nodes that process your transaction and helps to support the network.  Do you want to pay the fee?"
268 2012-09-12 11:36:02 <sipa> chmod755: oh, what is your fee setting?
269 2012-09-12 11:36:16 <chmod755> it was 0.02 BTC before now it's 0.001 BTC
270 2012-09-12 11:36:17 <chmod755> :d
271 2012-09-12 11:36:20 <michaelmclees> and now that you guys know my IP, guess its time to encrypt the wallet
272 2012-09-12 11:36:27 <sipa> chmod755: you know that's a fee per kilobyte, right?
273 2012-09-12 11:36:37 <chmod755> lol
274 2012-09-12 11:36:39 <chmod755> ok
275 2012-09-12 11:36:49 <chmod755> so it's a 50kb transaction?
276 2012-09-12 11:36:52 <sipa> must be
277 2012-09-12 11:36:55 <chmod755> err 100 kb
278 2012-09-12 11:38:15 <michaelmclees> once again, thank you guys!
279 2012-09-12 11:38:17 <michaelmclees> out
280 2012-09-12 11:39:35 <Joric> is bitcoin network somehow protected from the clasterisation what if say us and china will start mining independently and split the blockchain
281 2012-09-12 11:39:59 <sipa> if they have >50% combined, no
282 2012-09-12 11:44:04 <Joric> how about surprise orphaning a few hundred blocks )
283 2012-09-12 11:45:43 <epscy> Joric: i think that would require a serious network split
284 2012-09-12 11:46:00 <epscy> which would be unlikely to go unnoticed by most people
285 2012-09-12 11:46:14 <kjj_> no, they'd just have to follow different rules in their part
286 2012-09-12 11:46:21 <kjj_> which would cause a network split
287 2012-09-12 11:47:54 <epscy> right
288 2012-09-12 11:48:50 <epscy> but network segmentation seems more likely than 50% of the network agreeing to use different rules
289 2012-09-12 11:49:20 <epscy> the latter is probably less likely to get noticed straight away though, i agree
290 2012-09-12 11:50:07 <kjj_> and if they did fork the chain, we'd all have double our money
291 2012-09-12 11:52:03 <Joric> what if some guy manages to spend a few dollars to build a network-sized cluster (it's just ~15 BFL minirigs currenly, $450 worth) and start mining without communicating with the main network
292 2012-09-12 11:52:49 <Joric> 30k asic miners 1 th each x 15 = 450k$
293 2012-09-12 11:54:29 <kjj_> if he has a magic wand that can summon 15 minirigs, why can't he just use it to get what he really wants?
294 2012-09-12 12:05:34 <epscy> in that scenaerio they wouldn't be able to rewrite the whole blockchain i don't think
295 2012-09-12 12:14:36 <gmaxwell> 06:36 < sipa> chmod755: oh, what is your fee setting?
296 2012-09-12 12:15:10 <gmaxwell> I was going to say before, but got pulled off.. the largest transaction it will author without bailing out is 100k. So with the default minfee you can't end up being asked for more than 0.05 BTC.
297 2012-09-12 12:15:35 <gmaxwell> so anyone seeing a number like 0.99 has cranked their fee up.
298 2012-09-12 12:15:57 <sipa> ah, good to know
299 2012-09-12 12:16:42 <gavinandresen> Looking for ACKs on https://github.com/bitcoin/bitcoin/pull/1821   :   I'd like to pull it then tag and build a rc3
300 2012-09-12 12:18:28 <gmaxwell> Will look.
301 2012-09-12 12:19:26 <gmaxwell> gavinandresen: https://github.com/bitcoin/bitcoin/pull/1814 < going to pull this?  I ask because its a somewhat nasty IBD dos attack fix.  Perhaps we've become a little too paranoid with the DOS fixes, because it doesnt seem that anyone currently cares to dos attack.
302 2012-09-12 12:20:27 <gavinandresen> gmaxwell: yes, I will pull that-- I think being paranoid about DoS fixes is a good thing.
303 2012-09-12 12:20:52 <sipa> gmaxwell: if anything, it's a good sign that for now we care more about DoS attacks than attackers do :)
304 2012-09-12 12:21:38 <gavinandresen> being proactive about DoS attacks is something I think we've done pretty well.  "No news is good news" and all that....
305 2012-09-12 12:22:40 <sipa> gavinandresen: hmm, i wonder if there isn't a less intrusive fix for the RPC IPv6 thing
306 2012-09-12 12:22:44 <sipa> let me have a look
307 2012-09-12 12:23:08 <gavinandresen> there probably is... I don't know enough about IPv6 to reproduce the problem, so took the sledgehammer approach
308 2012-09-12 12:25:09 <sipa> there is already a backup section to deal with the ipv-failed case
309 2012-09-12 12:25:15 <sipa> but it's inside the same excpetion block
310 2012-09-12 12:26:38 <sipa> gmaxwell: by the way, managed to get a 2.5x speedup in wall-clock IBD time after the last checkpoint by using 4 sig verification checks
311 2012-09-12 12:26:59 <sipa> seems i should be able to do better on a 4-core i7...
312 2012-09-12 12:27:24 <sipa> *4 sig verification threads
313 2012-09-12 12:27:30 <wumpus> I also don't think rpc-over-ipv6 is a particularly urgent case
314 2012-09-12 12:28:23 <wumpus> and people that use that can build their own bitcoind
315 2012-09-12 12:28:47 <gmaxwell> wumpus: no, it's not urgent though it means that bitcoin still can't run ipv6 only, which isn't of great pratical importatnce but it's a certificational goodness.
316 2012-09-12 12:29:33 <gavinandresen> wumpus: I agree...  I've been thinking lately that "we" made a mistake implementing things like -rpcallowip and -rpcssl in bitcoind.  I think it would have been better to listen on only a local socket, and shipped a little RPC python proxy if you wanted to do anything more complicated.
317 2012-09-12 12:31:22 <wumpus> it's  a form of feature creep
318 2012-09-12 12:31:29 <gavinandresen> yup
319 2012-09-12 12:32:49 <gmaxwell> Well doing that wouldn't cure the need to listen on an IPv6 socket, as a v6 only host doesn't have any v4 sockets at all.
320 2012-09-12 12:33:00 <gmaxwell> Though I agree wrt SSL. That ssl code scares me.
321 2012-09-12 12:33:12 <sipa> i duplicated the try-catch block
322 2012-09-12 12:33:16 <gavinandresen> sure, but I'd be more confident that the new Ipv6 code didn't break those other features accidently
323 2012-09-12 12:33:16 <sipa> testing
324 2012-09-12 12:33:25 <gmaxwell> Big attack surface, and almost by definition the people using it will expose it to the internet.
325 2012-09-12 12:34:27 <gavinandresen> sipa: you can replicate the bug with the old code?
326 2012-09-12 12:34:46 <sipa> unfortunately, no
327 2012-09-12 12:35:12 <gavinandresen> mmm... then I think the right thing to do is ship 0.7 with the sledgehammer fix
328 2012-09-12 12:35:26 <gavinandresen> (and get full ipv6 support next release)
329 2012-09-12 12:35:34 <sipa> second
330 2012-09-12 12:38:03 <sipa> gavinandresen: if i get a fix that zvs on the forums confirms to make it work for his situation, would that be fine?
331 2012-09-12 12:38:11 <gavinandresen> sipa: yes
332 2012-09-12 13:00:54 <wumpus> nah, exposing it on the internet *without* SSL is even scarier. If you're going to remove SSL support, also remove other-than-localhost binding..
333 2012-09-12 13:06:14 <gmaxwell> wumpus: other than localhost binding does _not_ mean exposing to the internet.
334 2012-09-12 13:07:02 <gmaxwell> A fair number of people use bitcoind on private networks between web front ends and poolservers.
335 2012-09-12 13:07:42 <gmaxwell> and I wasn't suggesting removing it, my answer to the fact that I'm uncomfortable with it's security is to remind people that the rpc should never be internet exposed. :)
336 2012-09-12 13:13:20 <wumpus> I agree that other-than-localhost binding *can* be used responsibly
337 2012-09-12 13:14:15 <gavinandresen> 
ACTION goes to write a third reminder email to somebody who owes me some bitcoins....

338 2012-09-12 13:14:50 <gavinandresen> Maybe a "send email once a week until you see payment to this bitcoin address" feature for the client would be good....
339 2012-09-12 13:14:50 <gmaxwell> 
ACTION starts rumors that gavin lost all his coin to pirate40

340 2012-09-12 13:15:00 <gavinandresen> lol
341 2012-09-12 13:15:16 <wumpus> and you cannot prevent people from doing irresponsible things...
342 2012-09-12 13:15:18 <wumpus> hehe
343 2012-09-12 13:15:21 <ersi> sure you can
344 2012-09-12 13:15:25 <ersi> lock 'em up
345 2012-09-12 13:15:37 <gmaxwell> "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."   Then we'll know that bitcoin is done.
346 2012-09-12 13:16:21 <sipa> gmaxwell: i wouldn't mind a payment protocol implemented over SMTP :p
347 2012-09-12 13:16:31 <wumpus> it doesn't belong in the client, let's package a python script to do that :p
348 2012-09-12 13:17:07 <sipa> wumpus: duh :)
349 2012-09-12 13:18:35 <gmaxwell> you mean we shouldn't add an OP_CHECKEMAIL???
350 2012-09-12 13:19:33 <wumpus> I think we should, and then embed the email into the block chain
351 2012-09-12 13:19:37 <Joric> OP_LOL will look fabulous
352 2012-09-12 13:20:19 <wumpus> also we should support smoke signals and pigeons in case email is not available
353 2012-09-12 13:21:09 <gmaxwell> "Pigeons in the blockchain" sounds like a million dollar maker IOS app.
354 2012-09-12 13:22:30 <Jouke> Yes please
355 2012-09-12 13:22:31 <Joric> i'm writting ios apps, just in case
356 2012-09-12 13:24:17 <wumpus> yes such a game would certaily help make bitcoin appeal to the masses
357 2012-09-12 13:24:55 <Joric> who's sending out bitcoin announcements? newer clients to older ones?
358 2012-09-12 13:25:48 <Joric> i mean, warnings, like - your client is too old!
359 2012-09-12 13:26:10 <gmaxwell> No one is.
360 2012-09-12 13:26:16 <gmaxwell> Your client generates that on its own.
361 2012-09-12 13:26:22 <Joric> ah
362 2012-09-12 13:26:42 <gmaxwell> and if you see it, it's not currently because your client is too old, its because your blockchain is stuck for some reason.
363 2012-09-12 13:27:25 <gavinandresen> gmaxwell: the pre-0.6.3 alerts are still active, if I recall
364 2012-09-12 13:27:27 <Joric> 0.6.2 shows that i have to upgrade to 0.6.3 if i remember right
365 2012-09-12 13:27:35 <Joric> yeah, thats it, alerts
366 2012-09-12 13:28:34 <Joric> https://en.bitcoin.it/wiki/Alerts
367 2012-09-12 13:28:40 <Joric> found it
368 2012-09-12 13:29:09 <gmaxwell> Joric: okay, _that_ warning is an alert. All nodes that have it will hand it to you at startup. Gavin can generate them, though a special signing key thats set in the software. I thought you were talking about the generic "you or your peers should upgrade".
369 2012-09-12 13:30:04 <Joric> damn i thought everyone could send those :(
370 2012-09-12 13:30:19 <gmaxwell> No.
371 2012-09-12 13:30:39 <gmaxwell> hm. I know know how to encourage people to run testnet.. periodically send testnet alerts containing bitcoin private keys that have funds assigned to them.
372 2012-09-12 13:31:15 <gavinandresen> gmaxwell: good idea!
373 2012-09-12 13:31:27 <gavinandresen> gmaxwell: you could make it a game, make the alerts clues....
374 2012-09-12 13:32:01 <gavinandresen> we could call it "pigeons in the blockchain"
375 2012-09-12 13:32:03 <Joric> you could nag pirate with those
376 2012-09-12 13:40:53 <edcba> just buy testnet coins with bitcoins ?
377 2012-09-12 13:42:23 <Joric> edcba, faucet's currently giving away testnet coins in 500 coin packs
378 2012-09-12 13:45:53 <edcba> only coinbase recent enough then
379 2012-09-12 13:47:22 <edcba> choose your incentive, pay bitcoins
380 2012-09-12 13:49:10 <gmaxwell> edcba: buying testnet coins creates the wrong incentives. It's good the that coins are ~worthless because that encourages testing.
381 2012-09-12 13:49:27 <gmaxwell> If people are worried about destroying precious coins they won't do the kinds of crazy tests they already won't do on mainnet.
382 2012-09-12 14:03:21 <eian> gmaxwell, the multiparty signatures you were describing to me yesterday (that would frustrate my address clustering) - that would just introduce plausible deniability would it not?
383 2012-09-12 14:03:37 <eian> wait
384 2012-09-12 14:03:42 <eian> multi-input
385 2012-09-12 14:03:49 <eian> however you described it...
386 2012-09-12 14:04:05 <eian> the mixing
387 2012-09-12 14:04:10 <eian> bah...words escape me
388 2012-09-12 14:05:08 <Varan> eian, why are you trying to cluster addresses ... just out of curiosity
389 2012-09-12 14:05:14 <gmaxwell> eian: You have N people who togeater make one transaction with N output. You can't tell which of the outputs belonged to which of the people, and also the join transaction will confuse automated clustering that assumes that a common txn automatically means one person.
390 2012-09-12 14:05:34 <gmaxwell> s/join/joint/
391 2012-09-12 14:05:59 <gmaxwell> (web wallet private key imports might also hae the confusing property too)
392 2012-09-12 14:06:36 <eian> gmaxwell, if a single participant in a transaction is somehow deanonymized, wouldn't this implicate multiple people (i.e., you'll be sharing your cell with someone else)
393 2012-09-12 14:07:01 <eian> Varan, because it's cool!
394 2012-09-12 14:07:18 <Varan> Oke ... but i mean .. for visualization or something?
395 2012-09-12 14:07:20 <eian> gmaxwell, this might be more a legal question...
396 2012-09-12 14:07:49 <sipa> eian: it implies they create a transaction together, but i think there may be cases where they don't necessarily trust eachother
397 2012-09-12 14:07:51 <eian> Varan, I suspect it would be too much information to visualization.
398 2012-09-12 14:08:00 <eian> Varan, but i'd like to see if I can find relationships
399 2012-09-12 14:08:18 <Varan> Btw ... do these kind of multiparty transactions happen often now? .... I dont know of many clients/websites that create these kinds of transactions
400 2012-09-12 14:08:21 <gmaxwell> They don't even necessarily know each other, e.g. if some automated transaction privacy tool joined them togeather.
401 2012-09-12 14:08:52 <eian> gmaxwell, I've heard of computers being confisciated by law enforcement for simply acting as a TOR exit node
402 2012-09-12 14:08:58 <gmaxwell> Varan: They aren't often yet, but they are much easier to create now with 0.7.  The webwallet imports probably happen sometimes now.
403 2012-09-12 14:09:10 <eian> gmaxwell, does this sit within the same realm legally?
404 2012-09-12 14:09:22 <gmaxwell> eian: That doesn't happen in the US.
405 2012-09-12 14:09:40 <Varan> But if you import a key ... you do own it so ... that no issue right
406 2012-09-12 14:09:44 <gmaxwell> There was some weird histeria in germany for a while wrt that. But no one got in actual trouble just harassed due to ignorance.
407 2012-09-12 14:09:53 <Varan> thats*
408 2012-09-12 14:09:55 <gmaxwell> Ignorance wouldn't be likely in this sort of case.
409 2012-09-12 14:10:26 <gmaxwell> Varan: well not quite. E.g. some analysis is assuming that a txn with common inputs means they had a common owner, but what happens when the key changes hands? It still frustrates the analysis.
410 2012-09-12 14:10:49 <eian> gmaxwell, do you know any bitcoin lawyers? haha. What type of lawyer should I even speak to?
411 2012-09-12 14:11:05 <Varan> Yes ... true
412 2012-09-12 14:11:34 <gmaxwell> eian: You need a more concret question before you can ask a layer.  But this should be answerable on principles, not anything specific to bitcoin.
413 2012-09-12 14:12:01 <Varan> eian, how are you parsing the transactions? ... what language?
414 2012-09-12 14:12:10 <eian> gmaxwell, would being one of the N people implicate me legally if another individual did something stupid?
415 2012-09-12 14:12:14 <eian> Varan, C++
416 2012-09-12 14:13:00 <eian> Varan, I'm doing this as part of my masters thesis
417 2012-09-12 14:13:11 <eian> gmaxwell crushed my hopes and dreams yesterday lol
418 2012-09-12 14:13:21 <Varan> Lol
419 2012-09-12 14:13:24 <gmaxwell> eian: legally how? A criminal act?  No mens rea, on basic principles you can't be implicated of a crime you couldn't have known about, couldn't profit from, etc.
420 2012-09-12 14:13:24 <Varan> how so?
421 2012-09-12 14:13:27 <eian> but alas, I have a deeper understanding and appreciation for the system
422 2012-09-12 14:13:51 <Varan> Are you using https://bitcointalk.org/index.php?topic=88584.0 ?
423 2012-09-12 14:14:18 <eian> Varan, I've written all custom code
424 2012-09-12 14:14:23 <Varan> hmm oke
425 2012-09-12 14:14:24 <eian> Varan, why do you ask?
426 2012-09-12 14:14:48 <eian> gmaxwell, I see
427 2012-09-12 14:15:46 <gmaxwell> It also matters how you did the arrangement, if someone says "hey help me launder some coin" you might be implicated as being knowingly (any reasonable person would have know it was no good) involved in their crimes... if its just "hey, I'm tired of blockchain.info connecting up all my addresses and making my transactions and bitcoin net worth non-private, lets us this anonymity tool" thats a perfectly legimate thing to do.
428 2012-09-12 14:16:30 <Varan> I'm trying to get all the transactions in memory in my Java program to do some clustering stuff and maybe output something so it can be visualized in Gephi. But it's alot of data. I'm using that c++ block parser to output a file with all the transactions and then trying to read it in Java ... my C++ is not so good.
429 2012-09-12 14:16:50 <eian> Varan, what are you doing this for :)
430 2012-09-12 14:16:51 <eian> ?
431 2012-09-12 14:17:10 <eian> gmaxwell, are you certain of this legally? I guess I'm just naive to the law then :P
432 2012-09-12 14:17:21 <Varan> eian, just for fun :P
433 2012-09-12 14:17:55 <eian> Varan, I ran out of memory a long it ago
434 2012-09-12 14:18:05 <Varan> Haha
435 2012-09-12 14:18:07 <eian> Varan, I have 60+ gigs of normalized transaction data
436 2012-09-12 14:18:14 <Varan> The block parser tool is very cool...
437 2012-09-12 14:18:30 <Varan> it can do alot of stuff with only about 3 gig
438 2012-09-12 14:18:48 <eian> Varan, I looked at using gephi but I don't think it can handle this much data without narrowing the time window
439 2012-09-12 14:18:52 <Varan> what do you mean by normalized transaction data
440 2012-09-12 14:18:56 <eian> I can't even graph a weeks worth of data
441 2012-09-12 14:19:06 <eian> Varan, normalized in the database sense
442 2012-09-12 14:19:11 <Varan> eian, yeah maybe your right ... but i like to try
443 2012-09-12 14:19:12 <Varan> ah oke
444 2012-09-12 14:19:43 <eian> Varan, how many transactions are you looking at?
445 2012-09-12 14:20:08 <Varan> At the moment I am trying to load all transactions into memory
446 2012-09-12 14:20:16 <eian> in the block chain?
447 2012-09-12 14:20:22 <Varan> yeah
448 2012-09-12 14:20:26 <eian> ah, sorry....that will wokr
449 2012-09-12 14:20:28 <eian> work*
450 2012-09-12 14:20:33 <eian> that will most certainly fit in memory
451 2012-09-12 14:20:45 <gmaxwell> eian: Somewhat, or at least I've talked about these issues with actual attornies; (My SO is an attorney, and we have lots of electronic freedom interested attornies in our social circle).  But any attorney would also tell you that things depend on the facts.
452 2012-09-12 14:20:51 <Varan> what other transactions are you talking about then?
453 2012-09-12 14:21:02 <eian> gmaxwell, that's awesome :)
454 2012-09-12 14:21:13 <eian> gmaxwell, what does your SO think about bitcoin
455 2012-09-12 14:21:17 <eian> legally I mean
456 2012-09-12 14:21:22 <eian> I know the EFF stopped taking donations
457 2012-09-12 14:21:49 <eian> Varan, I'm collecting information about the real-time network
458 2012-09-12 14:22:01 <Varan> like...?
459 2012-09-12 14:22:04 <Varan> timestamps?
460 2012-09-12 14:22:07 <eian> everything
461 2012-09-12 14:22:07 <Varan> ip addrs?
462 2012-09-12 14:22:09 <eian> literally everything
463 2012-09-12 14:22:16 <Varan> oke
464 2012-09-12 14:22:18 <eian> I store it all as binary dumps
465 2012-09-12 14:22:23 <eian> and process it later
466 2012-09-12 14:22:23 <Varan> haha
467 2012-09-12 14:22:48 <eian> I need more computing power to process this crap
468 2012-09-12 14:22:52 <gmaxwell> eian: she doesn't know anything about finance regulations.  But people who do think it's generally uninteresting legally currently.
469 2012-09-12 14:22:54 <Varan> to try to identify addresses?
470 2012-09-12 14:23:06 <eian> Varan, yeah
471 2012-09-12 14:23:34 <eian> Varan, and any other patterns (because deanonymizatoin remains hard unless your client app screws something up apparently)
472 2012-09-12 14:23:38 <gmaxwell> certian activities that handle both usd and bitcoins seem like regulatory messes.
473 2012-09-12 14:23:46 <eian> gmaxwell, I see
474 2012-09-12 14:24:05 <Varan> have you tried to crawl the bitcoin forum and parse the addresses people have in their signatures?
475 2012-09-12 14:24:09 <eian> Varan, what problems are you running into loading into gephi?
476 2012-09-12 14:24:24 <eian> Varan, the block chain data should fit in memory for sure
477 2012-09-12 14:24:30 <eian> probably well under 3 gb as well
478 2012-09-12 14:24:43 <eian> especially if you normalize the data set
479 2012-09-12 14:25:06 <eian> Varan, I guess I could parse that info too
480 2012-09-12 14:25:36 <Varan> eian, I'm not that far yet .... for my first attempt I was just trying to load the transactions (input addrs + amount + tx hash + output addrs + amount) into memory ... in Java ... but I think i'm being inefficient
481 2012-09-12 14:26:03 <eian> so, don't repeat tx hashes - it is like 32 bytes
482 2012-09-12 14:26:10 <eian> read into database normalization concepts
483 2012-09-12 14:26:14 <eian> let me see if I can find an example
484 2012-09-12 14:26:23 <Varan> Yeah I was lazy ... just trying to hack something together
485 2012-09-12 14:27:25 <Varan> I have the C++ block parser dump all transactions in ascii (already bad!) and then read that form disk into a java program ... but it just hangs because it has to do so much GC ... :P
486 2012-09-12 14:27:26 <Joric> znort wrote an uncompilable thing =) c0x + 64bit only + boost i can't build it on win32 yet
487 2012-09-12 14:27:46 <Varan> uncompilable?
488 2012-09-12 14:27:52 <Varan> compiled just fine on linux :P
489 2012-09-12 14:28:05 <Varan> who uses 32 bit anyway :P
490 2012-09-12 14:28:10 <eian> Varan, http://www.youtube.com/watch?v=FZs-Qdf-Sxg
491 2012-09-12 14:28:44 <eian> It sounds like you are duplicating btc addresses
492 2012-09-12 14:29:08 <Varan> eian, I know about that kind of stuff (from school ... about 4 years ago :P) ... but I was just being lazy ...
493 2012-09-12 14:29:13 <eian> ah, I see
494 2012-09-12 14:29:29 <Varan> But do you use an actual database?
495 2012-09-12 14:29:35 <Varan> like mysql
496 2012-09-12 14:29:42 <eian> I am using mysql
497 2012-09-12 14:29:43 <Varan> of just binary dumps or something
498 2012-09-12 14:29:45 <Varan> oke
499 2012-09-12 14:29:51 <Varan> doesn't that create overhead?
500 2012-09-12 14:29:53 <eian> I take binary > csv > mysql
501 2012-09-12 14:30:46 <eian> It is basically an 'ETL' if you are familiar with data warehouse terminology
502 2012-09-12 14:30:50 <Varan> What is the subject of you master thesis?
503 2012-09-12 14:30:54 <eian> extract,transform, load
504 2012-09-12 14:31:02 <Varan> Oke
505 2012-09-12 14:31:05 <eian> Varan, at this point...collecting data? lol
506 2012-09-12 14:31:16 <eian> Varan, I was hoping to have better results with clustering
507 2012-09-12 14:31:18 <Varan> No I dont know so much about data warehouse stuff
508 2012-09-12 14:31:32 <Varan> yeah but i mean what is the goal?
509 2012-09-12 14:31:45 <eian> the goal was to see how far I could deanonymize individuals
510 2012-09-12 14:31:52 <Varan> Ah oke
511 2012-09-12 14:31:55 <Varan> Hmm :P
512 2012-09-12 14:31:58 <eian> it seems I can only do so if their clients have configuration mistakes
513 2012-09-12 14:32:12 <eian> I have seen patterns of misuse as well
514 2012-09-12 14:32:18 <eian> but it is isloated
515 2012-09-12 14:32:21 <eian> isolated**
516 2012-09-12 14:32:34 <Varan> But for the standard client you can see the ip form where the tx originated right?
517 2012-09-12 14:32:53 <Varan> if they dont use tor or something like that
518 2012-09-12 14:33:09 <eian> Varan, yes - but I have no idea if that was the actual originator of the tx, or something that was simply relaying the message
519 2012-09-12 14:33:24 <eian> Varan, so I take a guess and assume that the first time I hear about a tx, it is the originator
520 2012-09-12 14:34:05 <eian> I've only seen about 200 or so ips that use TOR, out of 130,000
521 2012-09-12 14:34:51 <Varan> blockchain.info does something similar
522 2012-09-12 14:35:14 <Varan> but I think they connect to many nodes to get the tx as fast as possible
523 2012-09-12 14:35:38 <eian> I'm connected to more than they are :)
524 2012-09-12 14:36:04 <helo> how do you know if an IP you see is using TOR?
525 2012-09-12 14:36:19 <eian> http://torstatus.blutmagie.de/
526 2012-09-12 14:36:29 <eian> I just grab the list of all nodes
527 2012-09-12 14:36:39 <eian> It's not precise, but it is good enough
528 2012-09-12 14:48:14 <Varan> I have been thinking of another way to cluster addresses. But it's much less precise. There are alot of tx chains where the addresses are only used once and a small amount is split off. The bitcoins in these addresses originate all from the same address. like: http://blockchain.info/address/12aqJLSsHwRdJNfogE8MDvGGtHkp8xuqhY
529 2012-09-12 14:49:02 <Varan> Maybe the addresses in such a chain could then be merged with the originating address ... there is ofcourse no guarantee that this is the same owner but for the visualization this does not matter much
530 2012-09-12 14:49:06 <Varan> I think
531 2012-09-12 14:52:39 <eian> Varan, yeah that is possible
532 2012-09-12 14:54:39 <Varan> But I wonder how many cluster you would get if you do that
533 2012-09-12 14:55:06 <Varan> vs if you use just tx input clustering and just addresses
534 2012-09-12 14:55:12 <Varan> clusters*
535 2012-09-12 14:55:40 <eian> People are encouraged to only use a key once
536 2012-09-12 14:56:00 <eian> In the worst possible case, you will have as many clusters as transactions
537 2012-09-12 14:56:20 <eian> use an *address once
538 2012-09-12 14:57:31 <eian> clusters on input addresses are flawed, as gmaxwell pointed out to me yesterday
539 2012-09-12 14:57:41 <eian> but I was doing that
540 2012-09-12 14:57:44 <Varan> Yeah in theory
541 2012-09-12 14:57:51 <eian> we had ~1.5 million clusters
542 2012-09-12 14:58:20 <eian> out of ~3 million total addresses
543 2012-09-12 14:58:32 <eian> don't remember the exact numbers
544 2012-09-12 14:58:35 <eian> but roughly half
545 2012-09-12 14:58:38 <Varan> But I think in practice it should work because not many people make those kinds of transactions
546 2012-09-12 14:58:39 <Varan> oke
547 2012-09-12 15:11:00 <devrandom> sipa: pushed fix to LXC arch issue
548 2012-09-12 16:08:30 <gavinandresen> Pushed:   * [new tag]         v0.7.0rc3 -> v0.7.0rc3
549 2012-09-12 16:20:26 <Luke-Jr> gavinandresen: did you merge the refactor_times fix? I really hate to find out the extent of problems it can cause???
550 2012-09-12 16:20:35 <Luke-Jr> bbiab
551 2012-09-12 16:31:20 <gavinandresen> Luke-Jr: no, I didn't merge refactor_times, that's not a showstopper bug.
552 2012-09-12 16:48:07 <Luke-Jr> gavinandresen: I would've expected it to be - if it does mess anything up, it won't be easy to fix the wallets after the fact???
553 2012-09-12 16:48:19 <BlueMatt> osmosis: looks like you updated the pull before at the wrong time, just wait, it should figure it out (unless that commit is actually the head on your pull, in which case, rebase or reword to make a new head commit sha)
554 2012-09-12 16:51:49 <osmosis> BlueMatt, the pull has already been accepted so i suppose ill just leave it.
555 2012-09-12 16:52:57 <BlueMatt> ack
556 2012-09-12 17:21:52 <gavinandresen> BlueMatt wumpus sipa : I pushed my gitian.sigs for rc3, can y'all start builds?
557 2012-09-12 17:32:29 <devrandom> gavinandresen: BTW, my latest gitian commit solves the 32 bit on 64 host for LXC
558 2012-09-12 17:32:49 <gavinandresen> devrandom: I saw that, thanks!  (works great for me)
559 2012-09-12 17:45:57 <osmosis> what format does the parse_Transaction function expect the data in the BCDataStream() class to be in?
560 2012-09-12 17:52:27 <sebicas> Hi! If there any limit of transactions the main client can handle? Will it support a high number of transactions ( over 100K / Month ) ?
561 2012-09-12 17:53:35 <gmaxwell> sebicas: transaction handling how? on the network or locally?
562 2012-09-12 17:53:44 <sebicas> Network
563 2012-09-12 17:54:01 <gmaxwell> thats only 23 transaction a block on average, we probably have more than that now.
564 2012-09-12 17:54:22 <sebicas> I mean own transactions
565 2012-09-12 17:55:04 <sebicas> For example, I understand SatoshiDice uses Bitcoinj
566 2012-09-12 17:55:54 <gmaxwell> If the transactions leave a lot of unconfirmed outputs, then it might get a bit slow... but if you're thinking of doing SatoshiDice you ought not. It's not fee efficient, and it's hostile to other users of the network, causing slower confirmations for services which actually care about confirmations.
567 2012-09-12 17:56:38 <sebicas> No, is not for that.. I understand the harn of SatoshiDice...
568 2012-09-12 17:56:49 <sebicas> harm
569 2012-09-12 17:57:30 <jgarzik> with 1MB blocks, IIRC, we max out at ~7/sec
570 2012-09-12 17:57:36 <gmaxwell> Fine enough, just had to say it.
571 2012-09-12 17:57:39 <jgarzik> assuming an avg tx size
572 2012-09-12 17:57:55 <gmaxwell> sebicas: in any case I'd expect it to work fine with that load, if you like, go create that load on testnet and try it out.
573 2012-09-12 17:58:10 <gmaxwell> If you have performance problems over time they may be helped by periodically cycling out wallets.
574 2012-09-12 17:58:34 <sebicas> ok, great??? thank you guys..
575 2012-09-12 17:58:39 <jgarzik> or just store your private keys external to bitcoind, and interact via raw rpc api
576 2012-09-12 17:59:22 <gmaxwell> the only thing that I'm aware of that gets intolerably slow fast is when you have spend with a lot of unconfirmed inputs in your wallet.
577 2012-09-12 17:59:24 <sebicas> So, private keys are the ones that may cause slow down of the client?
578 2012-09-12 17:59:38 <sebicas> If the client only holds one address ( one private key )
579 2012-09-12 17:59:46 <gmaxwell> sebicas: jgarzik was suggesting that so you could avoid using the internal wallet and local transaction tracking entirely.
580 2012-09-12 17:59:57 <gmaxwell> private keys themselves don't create any slowdown.
581 2012-09-12 18:00:06 <sebicas> Ahh ok.
582 2012-09-12 18:00:07 <gmaxwell> And you very much should be using each address only once if you can.
583 2012-09-12 18:01:22 <jgarzik> a system that stores keys external to bitcoind might, for example, take advantage of the knowledge that you will never use addresses X, Y, or Z again.  Therefore, store those keys in a "cold storage" locker, and never referenced by active online apps
584 2012-09-12 18:07:15 <MC1984> gmaxwell you did any work on opus?
585 2012-09-12 18:08:39 <gmaxwell> MC1984: yea, I wrote somehting like 10% of it, and did most of the software QA, and much of the R&D tooling.
586 2012-09-12 18:09:02 <MC1984> cool, just read your name on the wiki page
587 2012-09-12 18:10:00 <MC1984> lolling reading the list of companies with proprietary codecs that are asspained about opus
588 2012-09-12 18:12:25 <MC1984> does that mean that vorbis is dead now or what
589 2012-09-12 18:19:45 <sebicas> Guys, will it be better for the network 1) One transaction with 20 outs 2) 20 TXs with 1 output  3) Divide it in 5 outputs transactions ?
590 2012-09-12 18:25:25 <gmaxwell> sebicas: fewer outputs are better, especitally in the long term.
591 2012-09-12 18:25:50 <sebicas> ok, thx!
592 2012-09-12 18:26:04 <kjj_> wait, it is the same number of outputs in either case
593 2012-09-12 18:26:10 <kjj_> the question is how they are distributed
594 2012-09-12 18:26:14 <sebicas> Yes
595 2012-09-12 18:26:30 <gmaxwell> oh well fewer transactions are better if the total outputs are the same.
596 2012-09-12 18:26:56 <kjj_> gmaxwell: will pruning change that?  or is pruning going to hit txouts?
597 2012-09-12 18:26:58 <gmaxwell> (fewer total bytes are better, given equal total outputs, and fewer transactions will results in fewer bytes)
598 2012-09-12 18:27:28 <sebicas> Then making one transaction with 20 outputs??? if better than 20 transactions with 1 outputs, correct?
599 2012-09-12 18:27:49 <gmaxwell> kjj_: pruning, the way we'll implement it is per output.  Ideally you want to reduce the total outputs. But given the same number pruning doesn't care. Pre-pruning, less data is better.
600 2012-09-12 18:27:53 <gmaxwell> sebicas: correct.
601 2012-09-12 18:27:59 <sebicas> ok, thank!
602 2012-09-12 18:28:15 <kjj_> ok.  I wasn't sure if it was possible to prune transactions once all of the outputs were gone or not
603 2012-09-12 18:28:54 <gmaxwell> kjj_: yea ultraprune can work one output at a time.  Earlier pruning ideas people had would have had to prune the whole txn.
604 2012-09-12 18:29:29 <gmaxwell> ultraprune only stores the txid:txout (plus a few other bits of data) in the coins database.  (all the rest is there, but only used for reorgs / archival / bootstrapping etc)
605 2012-09-12 18:35:30 <BlueMattBot> Yippie, build fixed!
606 2012-09-12 18:35:31 <BlueMattBot> Project Bitcoin build #59: FIXED in 6 hr 9 min: http://jenkins.bluematt.me/job/Bitcoin/59/
607 2012-09-12 18:41:34 <CluckCreek> I'm getting http 500s when using addmultisigaddress on 0.7rc2.
608 2012-09-12 18:42:46 <CluckCreek> Does the wallet need to have the private keys for all the addresses? I don't want to unilaterally send money sent to the multisig address, I just want to generate the address.
609 2012-09-12 18:44:24 <Eliel> CluckCreek: the error 500's are probably due to non-json formatted liste in the command
610 2012-09-12 18:48:33 <CluckCreek> Well, I don't have the problem when all the addresses are from the same wallet. And it's the same code generating the list in both cases.
611 2012-09-12 18:49:46 <gmaxwell> no, you shouldn't need to have the keys in the same wallet.
612 2012-09-12 18:49:58 <gmaxwell> You will need to provide pubkeys rather than addresses.
613 2012-09-12 18:53:19 <CluckCreek> How do I get the pubkey?
614 2012-09-12 18:55:48 <gavinandresen> CluckCreek: validateaddress will tell you the pubkey (on a wallet that has the public/private keypair)
615 2012-09-12 18:56:06 <CluckCreek> cool, thanks
616 2012-09-12 19:22:53 <gmaxwell> Weee: https://chromiumcodereview.appspot.com/10825183/patch/1/2  chrome mysteriously disabling compression in openssl.
617 2012-09-12 19:24:18 <edcba> doesn't endanger bitcoin
618 2012-09-12 19:24:43 <edcba> there is no compression in bitcoin :)
619 2012-09-12 19:25:37 <doublec> a little  bit of discussion about it in this firefox bug too https://bugzilla.mozilla.org/show_bug.cgi?id=580679
620 2012-09-12 19:25:44 <doublec> comment 32
621 2012-09-12 19:26:55 <gmaxwell> edcba: earlier today I mentioned that the RPCSSL gives me hives a bit.
622 2012-09-12 19:27:45 <gmaxwell> I boggle at the rate of remote exploits in zlib.
623 2012-09-12 19:28:07 <edcba> just the word rpc afraids me
624 2012-09-12 19:29:03 <edcba> it's not a zlib problem it seems
625 2012-09-12 19:29:11 <edcba> more a general compresion problem
626 2012-09-12 19:30:03 <edcba> according to some stackoverflow post :)
627 2012-09-12 19:30:29 <gmaxwell> http://lists.randombit.net/pipermail/cryptography/2012-September/003191.html
628 2012-09-12 19:30:48 <gmaxwell> If only I was keeping up with my email I would have already seen that.
629 2012-09-12 19:30:59 <edcba> indeed this one
630 2012-09-12 19:31:52 <gmaxwell> we actually had a problem with the wikimedia board elections and gpg.  The system encrypted the votes using gpg.. and you could uniquely identify some of the ballots based on their size.
631 2012-09-12 19:32:23 <edcba> lol
632 2012-09-12 19:32:58 <gmaxwell> solution was to just disable compression.
633 2012-09-12 19:48:11 <jgarzik> a lot of things may be fingerprinted without examining their contents
634 2012-09-12 19:48:22 <eian> with bitcoin?
635 2012-09-12 19:48:46 <eian> or just in general?
636 2012-09-12 19:49:02 <jgarzik> sure.  you can easily recognize who is using bitcoin protocol over Tor, if a suspect is wiretapped.
637 2012-09-12 19:49:34 <jgarzik> with timings and luck, you might be able to identify whether or not a suspect sends a new transaction out to the world
638 2012-09-12 19:50:53 <gmaxwell> I looked into doing this and it was complicated by the fact that the cells are a rather large constant size... and the further propagation is slow.
639 2012-09-12 19:51:02 <gmaxwell> with enough txn you could, of course.
640 2012-09-12 19:51:16 <gmaxwell> (identifiying when a transaction is sent)
641 2012-09-12 19:51:57 <eian> :)
642 2012-09-12 19:52:43 <gmaxwell> Ultimately to avoid traffic analysis you must use hard constant bitrate streams...
643 2012-09-12 19:53:05 <gmaxwell> bitcoin has a low enough data rate that you could reasonably do that.
644 2012-09-12 19:53:48 <helo> is it a complete waste of time for tor clients to send out data that would look similar to a new transaction being sent?
645 2012-09-12 19:54:37 <gmaxwell> because of the tor cell size rounding the bitcoin ping messages are probably sufficient for that.
646 2012-09-12 19:59:51 <jgarzik> RE hard constant bitrate -- yep, that's how to fix it
647 2012-09-12 20:00:02 <jgarzik> sucks for network usage though
648 2012-09-12 20:01:01 <eian> setting up such a hard constant bitrate would just be a "leaky bucket" buffer right?
649 2012-09-12 20:02:05 <jgarzik> not familiar with a leaky bucket buffer
650 2012-09-12 20:02:10 <jgarzik> I consider it "padded with random data"
651 2012-09-12 20:02:30 <jgarzik> and carefully timed so that packets are sent at a clock-regular rate
652 2012-09-12 20:02:38 <eian> http://msdn.microsoft.com/en-us/library/windows/desktop/dd206751(v=vs.85).aspx
653 2012-09-12 20:05:57 <gmaxwell> eian: yes, its not important that the instant rate is constant, so long as its unrelated to anything private.
654 2012-09-12 20:06:11 <eian> right
655 2012-09-12 20:06:26 <gmaxwell> eian: e.g. if your rate is 2kbit/sec.. and you get knocked offline for 60 seconds you could reasonably have 120kbit to burst out on reconnect.
656 2012-09-12 20:06:51 <gmaxwell> a smart implementation would not buffer the data but only the obligation of data, and only use padding when there really was nothing to send.
657 2012-09-12 20:07:25 <eian> makes sense
658 2012-09-12 20:09:04 <gmaxwell> there are still attacks against anything with sustained traffic.. e.g. disrupt connectivity for groups of nodes long enough to observe their absense.  bisection search for the target.
659 2012-09-12 20:09:29 <gmaxwell> useless against signal transactions probably feasable for a state level actor against something like an underground market.
660 2012-09-12 20:09:30 <Diablo-D3> heh
661 2012-09-12 20:09:41 <gmaxwell> s/signal/single/
662 2012-09-12 20:10:37 <jgarzik> yep
663 2012-09-12 20:10:51 <gmaxwell> a non-realtime mixnet would be much stronger against that sort of thing though, if you could except very high txn delivery times.
664 2012-09-12 20:11:17 <gmaxwell> wow I can't english today.
665 2012-09-12 20:11:20 <gmaxwell> accept.
666 2012-09-12 20:11:23 <jgarzik> heh, indeed -- most mixnets are a joke because they are real-time
667 2012-09-12 20:11:30 <Diablo-D3> man
668 2012-09-12 20:11:31 <Diablo-D3> we need like
669 2012-09-12 20:11:34 <Diablo-D3> a martian mixnet
670 2012-09-12 20:11:37 <Diablo-D3> send it to mars
671 2012-09-12 20:11:40 <Diablo-D3> wait for it to come back
672 2012-09-12 20:11:42 <gmaxwell> yup. and non-realtime ones basicaly don't exist. kinda weird.. not hard to code.
673 2012-09-12 20:12:06 <jgarzik> gmaxwell: hard to trust
674 2012-09-12 20:12:08 <gmaxwell> I kinda expect the raw txn api to inspire some of this.. it's easy to do external txn forwarding now.
675 2012-09-12 20:12:24 <Diablo-D3> jgarzik: why?
676 2012-09-12 20:12:26 <Diablo-D3> if it drops tx
677 2012-09-12 20:12:29 <Diablo-D3> then you repeat them
678 2012-09-12 20:12:48 <gmaxwell> jgarzik: so you run it over a widely used realtime mixnet like tor... should be no less secure than the realtime one you're riding on.
679 2012-09-12 20:12:56 <jgarzik> people fundamentally don't like their money simply disappearing within $UnknownEntity for long spans of time
680 2012-09-12 20:13:12 <jgarzik> trusting the mixer is a sufficient stretch, even for real time
681 2012-09-12 20:13:40 <jgarzik> I'm not pretending this is logical behavior... but it's human behavior ;p
682 2012-09-12 20:13:41 <gmaxwell> ah, well I didn't mean coinmixing, just txn forwarding. it's possible to do zero trust coinmixing though.
683 2012-09-12 20:13:58 <ThomasV> a longer time increases the amount of coins, and thus the incentive for the mixnet operator to run away with the coins
684 2012-09-12 20:14:07 <jgarzik> yep
685 2012-09-12 20:14:24 <gmaxwell> (you just have all participants jointly author a transaction.. collaborating over a non-realtime mixnet, I'd guess ;) )
686 2012-09-12 20:15:43 <eian> non sequitur: Someone is sending the same tx once per hour over the course of 5 weeks. I've recorded it no less than 921 times and there is no record of it on blockchain info.
687 2012-09-12 20:16:26 <gmaxwell> eian: probably an invalid transaction. can you give us the hex dump of it?
688 2012-09-12 20:16:40 <eian> not easily, one sec
689 2012-09-12 20:17:02 <gmaxwell> eian: bitcoin can now do nice user friendly decodes of transactions from hex.
690 2012-09-12 20:17:08 <gmaxwell> 'decoderawtransaction' rpc.
691 2012-09-12 20:17:19 <eian> hah :P
692 2012-09-12 20:29:03 <midnightmagic> gmaxwell: does it do a full script decode?
693 2012-09-12 23:36:20 <dk5> was there any major change to the network on aug 22?
694 2012-09-12 23:45:52 <gmaxwell> Nothing is coming to mind.
695 2012-09-12 23:46:40 <sipa> anything groundbraking happened today?
696 2012-09-12 23:47:07 <gmaxwell> your pull worked for someone.
697 2012-09-12 23:47:47 <MC1984> groundbreaking?
698 2012-09-12 23:48:09 <gmaxwell> dk5: if you have some context it might jog my memory.
699 2012-09-12 23:48:30 <gmaxwell> dk5: logs here are public skimming them might be good.
700 2012-09-12 23:48:58 <MC1984> researchers have demonstrated stem cell regeneration of cochler cilli in an animal model
701 2012-09-12 23:49:21 <MC1984> given my hearing loss thats relevant to my interests
702 2012-09-12 23:49:31 <jgarzik> anything aerobraking happened today?
703 2012-09-12 23:53:08 <sipa> dk5: august 22 this year?
704 2012-09-12 23:53:53 <gmaxwell> MC1984: thats news for every adult perhaps; all adults, expecially men, have hearing loss believed to be from cilli death.
705 2012-09-12 23:54:17 <MC1984> quite so
706 2012-09-12 23:54:43 <BlueMatt> oh, so I can turn up the music and blast my hearing away without fear now?
707 2012-09-12 23:54:45 <sipa> cilli?
708 2012-09-12 23:54:47 <MC1984> the market for real regeneration for the aged is staggering
709 2012-09-12 23:55:04 <BlueMatt> sipa: the hair in your ears which vibrates activating the nerves to your brain
710 2012-09-12 23:55:11 <sipa> ah
711 2012-09-12 23:55:28 <gmaxwell> cilia*
712 2012-09-12 23:55:34 <MC1984> i myself am missing 4khz in my right ear and have attendant tinnitus, and i would rather not still have it the day i die
713 2012-09-12 23:55:57 <dk5> gmaxwell, sipa: yes, this year. no protocol changes or news coming out?
714 2012-09-12 23:56:16 <sipa> anything reason in particular to ask about that date?
715 2012-09-12 23:56:34 <dk5> my node's connections dropped significantly between 2-4am on that date, then went back to normal
716 2012-09-12 23:56:39 <dk5> can't explain why
717 2012-09-12 23:56:52 <sipa> may just have been a network hiccup?
718 2012-09-12 23:57:02 <sipa> of your internet connection, i mean
719 2012-09-12 23:57:18 <gmaxwell> dk5: yea, could just be upstream networks with flapping links.
720 2012-09-12 23:58:01 <dk5> hmm. lost 1000 connections.
721 2012-09-12 23:58:35 <BlueMatt> the attacker DDoSing you stopped temporarily?
722 2012-09-12 23:59:02 <gmaxwell> that or you've identified an evil massive scale data collector. :P
723 2012-09-12 23:59:22 <jgarzik> organ regeneration is ~10 years out.  full limb, 25 years.
724 2012-09-12 23:59:45 <dk5> gmaxwell: haha might be it ;-P