1 2013-07-25 00:00:28 <midnightmagic> lol "no dorky key signing parties required." making fun of the entire world of PKI.
  2 2013-07-25 00:02:28 <gmaxwell> Priorities straight, had to write up that sales pitch before actually getting around to donating myself. :P
  3 2013-07-25 00:02:47 <MC1984> otr is a plugin right
  4 2013-07-25 00:02:58 <MC1984> maybe it can plug in to the new tox netowrk thing
  5 2013-07-25 00:03:43 <phantomcircuit> MC1984, it's a protocol with plugins for various chat clients
  6 2013-07-25 00:04:13 <phantomcircuit> gmaxwell, they redo the DH key on every message right?
  7 2013-07-25 00:04:20 <MC1984> ill have a look, i assumed it was anothr tool for level 40+ neckbeards
  8 2013-07-25 00:04:28 <MC1984> like PGP/GPG
  9 2013-07-25 00:04:44 <gmaxwell> phantomcircuit: yes, in a lazy way.
 10 2013-07-25 00:05:04 <phantomcircuit> MC1984, it's fairly easy to use, they "solved" the key authentication in a way that is still pretty secure but normal people can actually do
 11 2013-07-25 00:05:05 <gmaxwell> E.g. every message you send basically does the next step in advancing another DH session.
 12 2013-07-25 00:06:03 <midnightmagic> 40+ neckbeards? as opposed to lazy hipsters' kids too lazy to do a key exchange
 13 2013-07-25 00:06:25 <MC1984> indeed
 14 2013-07-25 00:06:33 <gmaxwell> The key shared secret thing they do is really brillant. It seems so simple:  You type in a question for the other party that only they could answer, they answer it. Done. But the complex math behind the scenes using a statistical zero knoweldge proof that makes it impossible for an observer or a evil counter party to bruteforce the secret.
 15 2013-07-25 00:06:39 <midnightmagic> "can't, busy putting my dojo in a django php box, woops, there's another php exploit"
 16 2013-07-25 00:06:55 <midnightmagic> "can you help me reinstall php, mr. neckbeard"
 17 2013-07-25 00:07:00 <midnightmagic> "sir"
 18 2013-07-25 00:07:41 <MC1984> it sounds like the vulnerable part of that is having something about you that only a specific friend could answer
 19 2013-07-25 00:07:52 <MC1984> its usually all on facebook now
 20 2013-07-25 00:08:23 <petertodd> MC1984: when I was 5, what did I do at wasaga beach that was horribly embarassing and I'm still ashamed to talk about?
 21 2013-07-25 00:08:50 <MC1984> shit in the sea?
 22 2013-07-25 00:09:12 <petertodd> MC1984: Main thing OTR does right, is it means that *both* "private thing we both know" and "shares secret we've geeked out on" work the same way, with the same security.
 23 2013-07-25 00:09:58 <MC1984> sounds like theyve abstracted away the scary bit
 24 2013-07-25 00:10:03 <MC1984> good
 25 2013-07-25 00:10:08 <petertodd> Yup
 26 2013-07-25 00:11:09 <petertodd> The other thing like it that comes to mind is ZRTP's scheme for verifying the other side: both read a string on the phone. Depends on the hardness of the "real-time adaptive voice replacement" problem, and that's a hard one.
 27 2013-07-25 00:11:13 <MC1984> hm anyone tell the OTR guys why its bad to serve bitcoin adresses over insecure http
 28 2013-07-25 00:11:41 <gmaxwell> MC1984: you should. :P
 29 2013-07-25 00:12:10 <MC1984> im just some punk
 30 2013-07-25 00:12:11 <midnightmagic> yeah get on it. tell them to do an inline gpg sig using an otr key
 31 2013-07-25 00:12:21 <midnightmagic> yeah but they're crypto nerds, so they already get it.
 32 2013-07-25 00:12:55 <petertodd> https can be annoying to setup, but at least do a PGP-signed statement like I did at the bottom of http://keepbitcoinfree.org/
 33 2013-07-25 00:13:12 <MC1984> yah a gpg signed message should do it, if they cant aford ssl or somthing
 34 2013-07-25 00:13:21 <MC1984> except >implying anyone ever verifies them
 35 2013-07-25 00:13:21 <midnightmagic> ssl is lame.
 36 2013-07-25 00:13:27 <petertodd> (heh, and I went to those lengths even when the next paragraph is to say I don't really want donations)
 37 2013-07-25 00:14:21 <phantomcircuit> petertodd, https is pretty easy to setup if you already have the certificate
 38 2013-07-25 00:14:29 <phantomcircuit> getting the cert can be quite annoying
 39 2013-07-25 00:14:34 <petertodd> phantomcircuit: and if you control the server
 40 2013-07-25 00:14:47 <petertodd> phantomcircuit: for keepbitcoinfree it's a dead simple github thing, so that's not an option
 41 2013-07-25 00:14:47 <phantomcircuit> if you dont control the server then dont bother
 42 2013-07-25 00:16:27 <MC1984> bitcoin addresses are not fixed length right
 43 2013-07-25 00:16:31 <petertodd> correct
 44 2013-07-25 00:17:00 <MC1984> what range is the length and could a regex filter be made to pick them up every time
 45 2013-07-25 00:17:34 <MC1984> ie automated MITM string replacement for btc addresses
 46 2013-07-25 00:18:06 <phantomcircuit> MC1984, mitm string replacement doesn't need to be 100% certain it's a bitcoin address
 47 2013-07-25 00:18:09 <petertodd> MC1984: might be cheaper to just split into words and test checksum on each one
 48 2013-07-25 00:18:15 <phantomcircuit> so just replace anything that looks like a bitcoin address
 49 2013-07-25 00:18:16 <petertodd> phantomcircuit: BTC addresses have checksums
 50 2013-07-25 00:18:22 <MC1984> ok
 51 2013-07-25 00:18:28 <phantomcircuit> petertodd, that's way more expensive than a compiled regex
 52 2013-07-25 00:19:05 <petertodd> 
ACTION needs to learn more about regex

 53 2013-07-25 00:19:50 <petertodd> MC1984: I think the answer is 34 characters
 54 2013-07-25 00:20:16 <petertodd> MC1984: wiki says 25-34, meh, match 20-40 and call it a day, don't forget to match p2sh
 55 2013-07-25 00:20:35 <MC1984> yes so its trivial
 56 2013-07-25 00:20:38 <petertodd> A really fun one would be to MITM paytopubkeyhash and repalce them with the equivalent p2sh addresses
 57 2013-07-25 00:24:08 <MC1984> welp, email sent
 58 2013-07-25 00:25:34 <MC1984> i feel like i just patronised some very smart people lol
 59 2013-07-25 00:35:18 <amiller> i think if you know a person, it should only take a short amount of voice interaction to identify them
 60 2013-07-25 00:35:58 <amiller> low latency, lots of subtle information in terms of timing and inflection and such
 61 2013-07-25 00:36:49 <stevedekorte> Intel adding support for SHA256 instructions http://software.intel.com/en-us/articles/intel-sha-extensions
 62 2013-07-25 00:36:50 <stevedekorte> (sorry if his was already posted)
 63 2013-07-25 01:16:17 <MC1984> oh thats interesting
 64 2013-07-25 01:17:43 <MC1984> not a patch on our asics though ill bet
 65 2013-07-25 01:18:10 <stevedekorte> not a "patch"?
 66 2013-07-25 01:18:29 <MC1984> why the fuck did they do hardware sha1 :/
 67 2013-07-25 01:20:23 <MC1984> so weve had hardware AES for a while and now hardware SHA
 68 2013-07-25 01:20:54 <Krellan> Wow, there's an instruction to do *2 rounds* of SHA256, with a single instruction.
 69 2013-07-25 01:21:13 <petertodd> Krellan: parallel or serial rounds?...
 70 2013-07-25 01:21:15 <Krellan> CPU mining about to make a comeback?
 71 2013-07-25 01:21:18 <MC1984> wouldnt it be a shame if they had a specific flaw that only intel knows about, that makes the processing insecure
 72 2013-07-25 01:22:06 <jgarzik> stevedekorte, very cool
 73 2013-07-25 01:22:14 <jgarzik> krellan: ha, hardly
 74 2013-07-25 01:22:15 <Krellan> http://software.intel.com/en-us/articles/intel-sha-extensions Not sure entirely. Hope it's Bitcoin-compatible. Interestingly they don't mention Bitcoin at all in the paper. As if hardware SHA256 would have another use?
 75 2013-07-25 01:22:39 <petertodd> Krellan: a use like... hashing data?
 76 2013-07-25 01:22:53 <petertodd> Krellan: Lots of stuff uses SHA256, often on huge amounts of data.
 77 2013-07-25 01:22:57 <gmaxwell> Krellan: uh, it's used in many of the same places hardware AES is.
 78 2013-07-25 01:23:49 <Krellan> makes sense, but traditional (non-mining) SHA256 is already so fast it's nearly I/O bound
 79 2013-07-25 01:23:55 <Krellan> doesn't really need a dedicated CPU instruction
 80 2013-07-25 01:24:17 <Krellan> might as well use BTC for the assembler mnemonic, that would be amusing
 81 2013-07-25 01:24:37 <gmaxwell> Krellan: thats also true for AES, and yet.
 82 2013-07-25 01:25:02 <gmaxwell> Hardware sha256 and AES is also found on some arm SOCs and on via's x86 chips too.
 83 2013-07-25 01:25:04 <MC1984> like i said, what if theres another reason for these hardware implementations
 84 2013-07-25 01:26:00 <jchp> does rdrand give you the heebie jeebies as well?
 85 2013-07-25 01:26:04 <MC1984> theres no way to verify a hardware AES block isnt flawed is there
 86 2013-07-25 01:26:23 <MC1984> whats rdrand
 87 2013-07-25 01:26:36 <jchp> get ready to get your jimmies rustled: https://en.wikipedia.org/wiki/RdRand
 88 2013-07-25 01:26:40 <petertodd> MC1984: AES is deterministic, usefully putting in a flaw isn't easy
 89 2013-07-25 01:28:03 <MC1984> oh my fucking jimmies
 90 2013-07-25 01:28:14 <MC1984> fuck that, let me spaz the mouse instead
 91 2013-07-25 01:28:48 <MC1984> do people seriously think they are not or do not try to b inside our hardware
 92 2013-07-25 01:29:11 <jchp> an RNG that's pretty much impossible to audit? sounds 100% legit guys nothing to see here
 93 2013-07-25 01:29:26 <Krellan> it would really be disappointing if Intel added hardware SHA256 and didn't double it in the same way that Bitcoin does
 94 2013-07-25 01:29:35 <Krellan> making it ineffective for mining
 95 2013-07-25 01:29:46 <Krellan> then AMD could copy Intel but add the missing instruction to do it Bitcoin-compatible
 96 2013-07-25 01:29:49 <MC1984> i herd you can sometimes use output from the thermal diode as randomness
 97 2013-07-25 01:29:57 <Krellan> and recover some sales since people aren't buying ATI GPU's anymore for mining :)
 98 2013-07-25 01:30:00 <gmaxwell> Krellan: ... it wouldn't be possible for that to be the case.
 99 2013-07-25 01:30:15 <petertodd> MC1984: you can always use output from the thermal diode... it just won't give you bits very quickly
100 2013-07-25 01:30:27 <petertodd> MC1984: randomness is additive
101 2013-07-25 01:30:28 <gmaxwell> in any case, the intel stuff is very straight forward, and the way the round function its setup you can even do the skip the last couple rounds optimization.
102 2013-07-25 01:30:44 <Krellan> as for randomness, is it still worth sampling from the sound card and using the lowest bits?
103 2013-07-25 01:30:56 <MC1984> petertodd i thought the analouge noise from those things would be sufficient
104 2013-07-25 01:31:03 <MC1984> depends on how its sampled i suppose
105 2013-07-25 01:31:20 <Krellan> or using the "camera in a can" trick (webcam in sealed black container, brightness/contrast/gain turn up all the way, essentially random noise appears on screen)
106 2013-07-25 01:31:44 <MC1984> thats the same as the thermal diode thing in a roundabout way
107 2013-07-25 01:31:50 <petertodd> MC1984: exactly, and rdrand will certainly give you bits faster. Realisticly though, just use a proper PRNG.
108 2013-07-25 01:32:12 <petertodd> MC1984: hard disk timings also depend on physical randomness due to turbulance
109 2013-07-25 01:32:45 <petertodd> Anyway, the question isn't "Is it random?" it's "Can my attacker guess those bits?"
110 2013-07-25 01:32:49 <Krellan> treat rdrand like /dev/urandom: fast random, not necessarily good random
111 2013-07-25 01:32:53 <MC1984> cool what other parts of a computer are non deterministic lol
112 2013-07-25 01:33:42 <MC1984> i seriously wouldnt trust intel hardware blocks for this stuff. They put shit in hardware for the fucking MPAA
113 2013-07-25 01:33:46 <petertodd> MC1984: A lot more than you'd think: any time there is more than one clock domain in a digital system you get randomness in the relative phase of those two domains.
114 2013-07-25 01:34:18 <MC1984> clock skew?
115 2013-07-25 01:34:28 <petertodd> yes
116 2013-07-25 01:34:35 <MC1984> isnt it all divided off a mastr crystal somewhere
117 2013-07-25 01:34:45 <petertodd> no, I said "clock domains"
118 2013-07-25 01:35:43 <MC1984> dont get it
119 2013-07-25 01:36:28 <petertodd> a clock domain is all circuits controlled by one master clock
120 2013-07-25 01:36:40 <petertodd> your computer has more than one clock, and they aren't synced exactly to each other
121 2013-07-25 01:36:53 <MC1984> theyre all multiples
122 2013-07-25 01:36:57 <petertodd> nope
123 2013-07-25 01:37:07 <MC1984> oh
124 2013-07-25 01:37:20 <petertodd> 20 years ago they were, but technology has moved on
125 2013-07-25 01:37:31 <MC1984> more than 1 crystal then
126 2013-07-25 01:37:45 <MC1984> ben a while since ive looked at PC arch
127 2013-07-25 01:37:46 <petertodd> heck, completely async logic is used for parts too, and the speed that logic executes any given operation is unpredictable
128 2013-07-25 01:38:29 <MC1984> well that seems like fuckery
129 2013-07-25 01:38:53 <MC1984> i mean, theres a reason those traces look like a game of nokia snake 10 minutes in
130 2013-07-25 01:39:16 <petertodd> that's why async logic gets used, so you don't have to do that crap
131 2013-07-25 01:39:39 <MC1984> didnt know that was a thing
132 2013-07-25 01:39:46 <gmaxwell> So exach sha256 operation with this requires:
133 2013-07-25 01:39:46 <petertodd> in theory it's more reliable, lower power, faster etc. but there's a lot of complexity to actually getting those benifits
134 2013-07-25 01:39:50 <gmaxwell> 12 _mm_alignr_epi8
135 2013-07-25 01:39:50 <gmaxwell> 12 _mm_sha256msg1_epu32
136 2013-07-25 01:39:50 <gmaxwell> 16 _mm_set_epi64x
137 2013-07-25 01:39:50 <gmaxwell> 30 _mm_add_epi32
138 2013-07-25 01:39:50 <gmaxwell> 4 _mm_loadu_si128
139 2013-07-25 01:39:53 <gmaxwell> 12 _mm_sha256msg2_epu32
140 2013-07-25 01:39:55 <gmaxwell> 32 _mm_sha256rnds2_epu32
141 2013-07-25 01:39:58 <gmaxwell> 16 _mm_shuffle_epi32
142 2013-07-25 01:40:00 <gmaxwell> 4 _mm_shuffle_epi8
143 2013-07-25 01:40:11 <petertodd> figures
144 2013-07-25 01:40:21 <gmaxwell> the timings on _mm_sha256msg1_epu32 _mm_sha256msg2_epu32 and _mm_sha256rnds2_epu32 aren't public yet.
145 2013-07-25 01:40:24 <MC1984> dat sum opcode
146 2013-07-25 01:41:15 <petertodd> gmaxwell: so basically they don't know how fast it's gonna be...
147 2013-07-25 01:43:05 <gmaxwell> oh I'm sure intel knows.
148 2013-07-25 01:43:10 <gmaxwell> They're not making it public though.
149 2013-07-25 01:43:27 <MC1984> seems legit
150 2013-07-25 01:43:47 <MC1984> arnt there already commercial sha boards
151 2013-07-25 01:43:58 <MC1984> like they do aes cards for servers
152 2013-07-25 01:44:11 <petertodd> MC1984: bandwidth two/from the cards is a killer
153 2013-07-25 01:44:28 <MC1984> pcie?
154 2013-07-25 01:44:45 <stevedekorte> This is a potentially good for Bitcoin, right? (less centralized control of mining)
155 2013-07-25 01:45:16 <MC1984> even if it works, that wont be true for long
156 2013-07-25 01:45:57 <MC1984> if it works it might be actually ok for mining considering intel is on what 8nm or something now
157 2013-07-25 01:46:02 <MC1984> and people buy the stuff any way
158 2013-07-25 01:46:16 <petertodd> more like 32nm, maybe 24?
159 2013-07-25 01:46:26 <petertodd> 8nm is forecasted for something like 2020
160 2013-07-25 01:46:30 <MC1984> thought haswall was 14
161 2013-07-25 01:47:07 <MC1984> oh is 22nm
162 2013-07-25 01:47:36 <MC1984> i dont think we have very many shrinks left
163 2013-07-25 01:47:53 <MC1984> i remember reading years ago about how civilisation would stop in 2012
164 2013-07-25 01:47:56 <MC1984> lol
165 2013-07-25 01:48:24 <MC1984> process shrinks i mean not the mayan shit
166 2013-07-25 01:49:01 <petertodd> work out how many atoms wide 8nm is... it's not very many
167 2013-07-25 01:49:15 <gmaxwell> stevedekorte: certantly not bad.
168 2013-07-25 01:49:22 <gmaxwell> may not matter much from a mining perspective.
169 2013-07-25 01:49:39 <MC1984> an atom is about 100 angstroms right
170 2013-07-25 01:49:48 <MC1984> a hydrogen
171 2013-07-25 01:52:17 <gmaxwell> if I just assume that all operations except the shuffles, adds, and the round funcations a free, and the round functions have 1 cycle throughput.  Then the whole invocation would take 106 cycles.
172 2013-07-25 01:52:47 <MC1984> no 100 angstoms is 10nm lol
173 2013-07-25 01:53:43 <gmaxwell> so that would make a quad core 3ghz chip get about 56 MH/s. I imagine in actuality it would be substantially less
174 2013-07-25 01:55:38 <MC1984> depends on how much power that 56mh costs
175 2013-07-25 01:56:24 <MC1984> you could probably discount the idle watts of the chip seeing as it would be on anyway probably, unless you made a farm on them for some reason
176 2013-07-25 01:56:37 <MC1984> so running that sha block should be almost free surely
177 2013-07-25 01:56:41 <gmaxwell> MC1984: 65 watts.
178 2013-07-25 01:56:54 <gmaxwell> (lets say, random ass number)
179 2013-07-25 01:57:02 <MC1984> seems high but ok
180 2013-07-25 01:57:26 <gmaxwell> I figure by the time this is in actual chips they'll be drawing less, but my performance guess is almost certantly an overestimate.
181 2013-07-25 01:58:11 <MC1984> anyon know how much watts it costs to run existing intl AES blocks at full tilt
182 2013-07-25 01:58:15 <MC1984> that might be representative
183 2013-07-25 01:58:54 <gmaxwell> I don't have any good way to measure usage.
184 2013-07-25 02:00:42 <MC1984> i wonder if AMD would consider something bitcoin specific
185 2013-07-25 02:00:56 <MC1984> theyve mentioned it officially atleast once
186 2013-07-25 02:01:09 <MC1984> theyre not competiing on raw performance any more, why not features
187 2013-07-25 02:01:58 <MC1984> i dont know if enough extra radeons got sold to notice on the income sheet
188 2013-07-25 02:02:00 <MC1984> prob not
189 2013-07-25 02:02:36 <gmaxwell> I don't know, estimates from our hashrate would have had us as a significant chunk of their high end gpu market, and a totally insignificant chunk of their overall gpu market.
190 2013-07-25 02:03:12 <gmaxwell> but the problem is now that dedicated asics are so fast and efficient that some feature in a general product really can't keep up.
191 2013-07-25 02:04:18 <MC1984> if they lithoed a proper double sha256 block onto their chips @ 24nm or whatever they are, that wouldnt be worth it?
192 2013-07-25 02:06:59 <gmaxwell> only to be outdone by a part with 64 of them in a slightly older process.
193 2013-07-25 02:08:46 <MC1984> i suppose i should be asking if/when companies like amd produce bitcoin asic boards
194 2013-07-25 02:09:37 <Luke-Jr> 
ACTION cries at poor documentation

195 2013-07-25 02:18:32 <gmaxwell> anyone have a patch handy to pull the pull the mempool from peers at startup (or otherwise)?  differences in mempool size after restarting are goofing up some performance measurements I'm trying.
196 2013-07-25 02:21:55 <Luke-Jr> gmaxwell: a trivial one..
197 2013-07-25 02:22:49 <gmaxwell> yea, nevermind, did it myself. :P was just trying to avoid reinventing the wheel. :P
198 2013-07-25 02:22:53 <Luke-Jr> http://codepad.org/2N2p1vdD
199 2013-07-25 02:27:08 <Luke-Jr> seems probing my LS pissed it off
200 2013-07-25 02:36:34 <Luke-Jr> "The erasing of non-volatile memories starts as soon as the CHIP_ERASE instruction is selected."
201 2013-07-25 02:36:36 <Luke-Jr> 
ACTION facepams

202 2013-07-25 02:39:19 <warren> 
ACTION facepalm.

203 2013-07-25 02:39:23 <warren> "subver" : "/MemeCoin:0.6.3/",
204 2013-07-25 02:40:08 <warren> Not sure how that's connected to my Litecoin node... but apparently that's one way Litecoin's alerts jumped onto the clone coin networks.
205 2013-07-25 02:40:52 <gmaxwell> people hack out the network version checks while trying to get stuff working?
206 2013-07-25 02:43:07 <warren> gmaxwell: need alt coin generator ASAP
207 2013-07-25 03:49:52 <stevedekorte> gjs278: is anyone using namecoin?
208 2013-07-25 03:50:02 <gjs278> people selling it for bitcoins
209 2013-07-25 03:50:09 <gjs278> that's the only real use
210 2013-07-25 04:55:34 <warren> "<gmaxwell> [12:14:41] They're frequently attacked, so we could potentially learn about attacks that people aren't bothering to perform on bitcoin."
211 2013-07-25 04:56:08 <warren> gmaxwell: study the recent FTC time traveling attack.  I bet some/many of the bitcoin pool software has the same vulnerability, just implausible to exploit.
212 2013-07-25 04:59:09 <swulf--> sipa: yet another db corrpution
213 2013-07-25 05:00:18 <jgarzik> swulf--, OSX?
214 2013-07-25 05:00:50 <swulf--> linux, atom cpu, using loop-AES
215 2013-07-25 05:01:20 <gjs278> treat yourself to some dmcrypt
216 2013-07-25 05:01:41 <swulf--> regardless
217 2013-07-25 05:06:54 <Luke-Jr> warren: we've known it does for a while..
218 2013-07-25 05:07:15 <warren> Luke-Jr: ok
219 2013-07-25 05:07:38 <warren> Luke-Jr: the one that can cause induce pools to reject all shares?
220 2013-07-25 05:17:34 <Luke-Jr> gmaxwell: fun tidbit: FRCJoe is setting up to do merged mining Freicoin (master) + Namecoin
221 2013-07-25 05:25:23 <freewil> Luke-Jr, so wait
222 2013-07-25 05:25:34 <freewil> namecoin already does merged mining with bitcoin
223 2013-07-25 05:25:45 <freewil> freicoin will do merged mining with namecoin?
224 2013-07-25 05:25:49 <Luke-Jr> freewil: Namecoin does merged mining. It doesn't care what the other chain is ;)
225 2013-07-25 05:26:19 <freewil> i guess i dont quite understand how merged mining works
226 2013-07-25 05:26:34 <freewil> why not just make freicoin do merged mining with bitcoin?
227 2013-07-25 05:26:42 <Luke-Jr> freewil: adding merged mining is a hardfork
228 2013-07-25 05:26:57 <Luke-Jr> Freicoin plans to add BC MM, but not immediately
229 2013-07-25 05:27:26 <freewil> so what's your opinion on the matter
230 2013-07-25 05:27:27 <Luke-Jr> in the year+, people have learned from NMC's MM, and FRC wants to do it better
231 2013-07-25 05:27:31 <Luke-Jr> ?
232 2013-07-25 05:27:49 <freewil> is freicoin a scamcoin
233 2013-07-25 05:28:48 <Luke-Jr> no
234 2013-07-25 05:30:11 <gjs278> if people want to make more merged mine coins, I am all for it
235 2013-07-25 09:07:55 <ahmedbodi> hey guys
236 2013-07-25 09:08:27 <ahmedbodi> would any of you be able to give me an idea on how to check what bitcoin version a wallet is based on?
237 2013-07-25 09:39:47 <sipa> swulf--: what OS were you using again, and where do the binaries come from?
238 2013-07-25 09:41:10 <warren> swulf--: and what filesystem?
239 2013-07-25 10:06:27 <warren> sipa: do you still have that blacklist patch somewhere?
240 2013-07-25 10:11:56 <sipa> warren: yes, it's a pullreq
241 2013-07-25 10:14:46 <warren> ah
242 2013-07-25 10:30:09 <ahmedbodi> could anyone give me some advice on how to set the aux chain id in a coins source
243 2013-07-25 10:55:07 <Zetas> Hey guys, I'm building a wallet site for a client and I have a couple questions. The transactions that will normally move through the site will be > 0.5 btc but I'm running some tests on the live network with less than that and they are all getting caught in transaction fees. My question is, how can i get rid of the fees? and will we get fees on larger amounts like 0.5 or 1?
244 2013-07-25 10:56:39 <Zetas> I have researched and I know "nuisance" transactions of 0.005 and such will get automatically tagged for fees but I also read that you pay fees depending on the way the bitcoins were received and not how their sent and thats very confusing to me so im worried that our larger transactions will get hit as well.
245 2013-07-25 10:58:19 <c0rw1n> Zetas, just include the tiny default tx fee, so they'll just be confirmed in 6 blocks as normal
246 2013-07-25 10:58:58 <Zetas> c0rw1n: What is the tiny default tx fee? What i read said it was 0.0001 per 100bytes or something
247 2013-07-25 10:59:57 <c0rw1n> it's "market price", whatever that is at any given time...
248 2013-07-25 11:00:42 <c0rw1n> the priority of a transaction to be included in a block is calculated from the price-per-byte, and transaction age
249 2013-07-25 11:01:03 <c0rw1n> a fee-free transaction will _eventually_ be mined
250 2013-07-25 11:01:35 <c0rw1n> just not in the very next block(s)
251 2013-07-25 11:01:48 <Zetas> That explains why these micro transactions that i pay fees on seem to be confirmed instantly but when i send 3 or 4 btc it takes hours
252 2013-07-25 11:02:09 <Zetas> I thought it was because of the size
253 2013-07-25 11:02:27 <c0rw1n> size doesn't depend on the amont afaik, but i may be totally wrong
254 2013-07-25 11:04:06 <Zetas> I thought i understood bitcoin. I've been mining and using it to buy things since before SR but this is my first time using bitcoind and it's a lot more complicated than i thought.
255 2013-07-25 11:04:35 <Zetas> I can't even figure out how to get the sending address. The bitcoind transaction data only includes the destination address. I know it's out there somewhere i just have to figure out how to find it.
256 2013-07-25 11:05:33 <c0rw1n> blockchain.info does that, right, so there must be some way... well the blockchain is a linked list, so you'd have to index it backwards and layer a little API to access it both ways
257 2013-07-25 11:06:07 <sipa> read the topic please
258 2013-07-25 11:06:11 <sipa> There is no from  address
259 2013-07-25 11:06:28 <Zetas> I read that but when i look at my wallet on other sites they have the from address
260 2013-07-25 11:06:35 <sipa> they are wrong
261 2013-07-25 11:06:39 <sipa> transactions consume coins, and produce new ones, assigning them to addresses
262 2013-07-25 11:06:57 <sipa> those consumed coins may or may not have identifiable addresses they were previously sent to
263 2013-07-25 11:07:06 <sipa> but this is not guaranteed, nor is it useful information
264 2013-07-25 11:07:21 <sipa> as it does not tell you 1) who sent it  2) where you can send them back to
265 2013-07-25 11:07:56 <jgarzik> oh brother
266 2013-07-25 11:08:03 <Zetas> Ok, cool. You got me off the hook, thanks :)
267 2013-07-25 11:08:05 <jgarzik> somebody created a CVE for this stupid RPC issue
268 2013-07-25 11:08:15 <jgarzik> "timing leak" my ass
269 2013-07-25 11:08:21 <phantomcircuit> jgarzik, huh
270 2013-07-25 11:08:38 <phantomcircuit> anybody with rpc exposed to the public is gonna have a bad time
271 2013-07-25 11:08:52 <jgarzik> phantomcircuit, indeed
272 2013-07-25 11:08:58 <sipa> well, that's not an argument
273 2013-07-25 11:09:02 <jgarzik> phantomcircuit, reference https://github.com/bitcoin/bitcoin/issues/2838
274 2013-07-25 11:09:08 <upb> 
ACTION sidechannel attacks jgarzik's ass

275 2013-07-25 11:09:09 <phantomcircuit> im pretty sure that there is a deadlock issue if you ever try to make rpc_threads-1 concurrent rpc calls
276 2013-07-25 11:09:41 <sipa> the RPC has an authentication feature, so if it can expose the password through a timing attack, then there is a problem with that feature
277 2013-07-25 11:09:43 <phantomcircuit> lolol
278 2013-07-25 11:09:53 <sipa> nonetheless, i think this is a very theoretic problem only
279 2013-07-25 11:09:58 <phantomcircuit> sipa, that timing attack is too small a window to exploit anywhere
280 2013-07-25 11:10:02 <phantomcircuit> unless you have like
281 2013-07-25 11:10:05 <sipa> phantomcircuit: that i fully agree with
282 2013-07-25 11:10:07 <phantomcircuit> 64KB passwords
283 2013-07-25 11:10:21 <sipa> phantomcircuit: but saying "the feature is useless anyway, so if it breaks, this is no issue" is wrong
284 2013-07-25 11:10:45 <c0rw1n> apart from coinbase, what transactions have not been sent "from" somewhere? how does blockhain.info determine what address coins come from? I may be ridiculously wrong, but parsing the full blockchain doesn't look unfeasible
285 2013-07-25 11:11:29 <sipa> c0rw1n: they are sent "from" previous coins
286 2013-07-25 11:11:39 <phantomcircuit> c0rw1n, bc assigns the from address based on the "to" address of the consumed transaction
287 2013-07-25 11:11:41 <sipa> those previous coins may or may not have been assigned to addresses
288 2013-07-25 11:11:46 <phantomcircuit> which isn't necessarily right
289 2013-07-25 11:11:54 <sipa> those addresses are reported as "from addresses"
290 2013-07-25 11:12:01 <sipa> but this is not useful information
291 2013-07-25 11:12:05 <c0rw1n> hm ok
292 2013-07-25 11:12:10 <sipa> you can legitimately call it a "from address"
293 2013-07-25 11:12:17 <sipa> but this fosters a misunderstanding about how bitcoin works
294 2013-07-25 11:12:31 <Zetas> Im assigning users in the system to bitcoin accounts with their username as the key (as suggested on the bitcoind wiki). the client wants the ability to delete users but It appears to be impossible to "delete" accounts. What's the best way to handle that?
295 2013-07-25 11:12:42 <sipa> if you want to identify individual transactions, use a separate receive address for each
296 2013-07-25 11:12:54 <sipa> if you want to know where to refund money to, ask for a refund address
297 2013-07-25 11:13:17 <c0rw1n> but in "normal" cases, you can call it a from address? unless the coins went to weird wallets like ShamirSecretShared multisig nlocktimed inner transactions that implement a contract?
298 2013-07-25 11:13:23 <phantomcircuit> Zetas, DO NOT USE THE ACCOUNTS FUNCTION
299 2013-07-25 11:13:37 <phantomcircuit> Zetas, it's impossible to make consistent backups
300 2013-07-25 11:13:53 <Zetas> What does that mean?
301 2013-07-25 11:14:00 <phantomcircuit> Zetas, please point me to the wiki page so i can fucking delete it
302 2013-07-25 11:14:36 <Zetas> https://en.bitcoin.it/wiki/PHP_developer_intro
303 2013-07-25 11:14:37 <sipa> c0rw1n: the point is that you should not care about where coins come from
304 2013-07-25 11:14:42 <sipa> c0rw1n: what do you need it for?
305 2013-07-25 11:14:54 <phantomcircuit> Zetas, the account -> bitcoin address map can be updated at anytime without any warning and is not deterministic
306 2013-07-25 11:15:20 <Zetas> How does it get updated?
307 2013-07-25 11:15:22 <phantomcircuit> Zetas, which means it's impossible to be 100% sure you've backed up that mapping
308 2013-07-25 11:15:33 <phantomcircuit> Zetas, it's saved in wallet.dat
309 2013-07-25 11:15:36 <Zetas> Oh, you're talking about backing up the wallet.dat
310 2013-07-25 11:15:50 <Zetas> even if you shutdown bitcoind first, backups wont work?
311 2013-07-25 11:16:58 <phantomcircuit> Zetas, im saying you have no way to know when you need to create a backup
312 2013-07-25 11:16:58 <sipa> backups can only guarantee non-loss of money
313 2013-07-25 11:17:05 <sipa> they cannot guarantee metadata changes
314 2013-07-25 11:17:31 <phantomcircuit> Zetas, the information about who should be assigned funds is essentially impossible to backup if you use the bitcoind accounts feature
315 2013-07-25 11:17:50 <Zetas> sipa: that doesn't make sense. If the metadata is stored in the wallet, shouldn't that be included in the backup?
316 2013-07-25 11:18:10 <sipa> Zetas: of course
317 2013-07-25 11:18:18 <sipa> Zetas: but you don't backup after every modification
318 2013-07-25 11:18:31 <phantomcircuit> Zetas, keys are pregenerated, so you're backup will contain the next 100 addresses you ask for, the metadata however is not
319 2013-07-25 11:18:52 <phantomcircuit> so you would need to backup everytime an address/key is assigned to an account
320 2013-07-25 11:18:56 <phantomcircuit> which would be constantly
321 2013-07-25 11:19:08 <phantomcircuit> there's also no way to know when that happens exactly
322 2013-07-25 11:19:28 <phantomcircuit> so you'd probably end up doing backups everytime you checked account statuses
323 2013-07-25 11:19:57 <phantomcircuit> Zetas, believe me i spent several days trying to untangle a mess created by using the accounts stuff
324 2013-07-25 11:19:59 <phantomcircuit> do not use it
325 2013-07-25 11:20:28 <Zetas> That's not really feasable at this point heh I've spent the last week and a half tightly implementing it into the system.
326 2013-07-25 11:20:58 <Zetas> I have bitcoind shutting down every day and manually copying the wallet.dat to a backup location, this isn't good enough?
327 2013-07-25 11:21:16 <phantomcircuit> Zetas, no it's no and also there's an rpc call to generate a backup
328 2013-07-25 11:21:20 <phantomcircuit> you dont need to shutdown
329 2013-07-25 11:21:39 <Zetas> I know i didn't trust it. A running backup of a database makes me uneasy.
330 2013-07-25 11:22:31 <sipa> the RPC essentially halts writing to the db, flushes it, closes it, copies it, and reopens it
331 2013-07-25 11:22:54 <Zetas> phantomcircuit: What happened when you had to untagle your wallet? What caused the issue?
332 2013-07-25 11:23:10 <phantomcircuit> Zetas, i had an old backup i had restored from
333 2013-07-25 11:23:28 <phantomcircuit> i had to guess about who was lying about transfers and who was telling the truth
334 2013-07-25 11:23:34 <phantomcircuit> fortunately it wasn't a lot of funds
335 2013-07-25 11:23:45 <phantomcircuit> but it could easily have been a huge mess
336 2013-07-25 11:24:08 <Zetas> Ah, well I mirror all transactions in the database when they happen so it can be reconstructed if necessary.
337 2013-07-25 11:24:22 <phantomcircuit> Zetas, just do that in the first place
338 2013-07-25 11:24:37 <Zetas> phantomcircuit: i am
339 2013-07-25 11:24:45 <Zetas> i have both, in case one fails
340 2013-07-25 11:24:48 <Zetas> i can use the other to reconstruct
341 2013-07-25 11:25:11 <phantomcircuit> why bother
342 2013-07-25 11:25:31 <phantomcircuit> assuming you're using a proper database you'll easily be able to mirror the db and have proper backups
343 2013-07-25 11:26:03 <Zetas> Well a single point of failure when handling money seems like a bad idea. This way if the mysql db dies for some reason i can reconstruct from the wallet. If the wallet dies, i can reconstruct from the sql db.
344 2013-07-25 11:26:40 <Zetas> It also makes it a lot easier to use accounts because it automatically handles balances for each user without me having to build the balance from the transaction list or maintain it somewhere else. It's very convenient programatically
345 2013-07-25 11:26:43 <phantomcircuit> Zetas, have two tables, bitcoin_addresses (user_id, bitcoin_address), bitcoin_transactions(txid, address, amount);
346 2013-07-25 11:27:09 <phantomcircuit> Zetas, just hope that nothing goes wrong
347 2013-07-25 11:27:10 <phantomcircuit> like
348 2013-07-25 11:27:11 <phantomcircuit> ever
349 2013-07-25 11:27:12 <Zetas> I started that way but when i found accounts i abandoned the addresses table lol
350 2013-07-25 11:27:20 <phantomcircuit> or you'll be super screwed
351 2013-07-25 11:27:40 <phantomcircuit> it's *much* easier to have proper mysql backups
352 2013-07-25 11:27:56 <phantomcircuit> there's synchronous streaming replication and log shipping and all sorts of fancy stuff
353 2013-07-25 11:27:58 <Zetas> I appreciate the warning. I have been scouring the internet the last two weeks and have heard nothing like what you just said.
354 2013-07-25 11:27:59 <phantomcircuit> but most importantly
355 2013-07-25 11:28:04 <phantomcircuit> it'll be self consistent always
356 2013-07-25 11:28:22 <Zetas> If there's a next time I'll definitely do it that way.
357 2013-07-25 11:32:35 <Zetas> Thanks sipa and phantomcircuit, you helped quite a bit. I'm slowly becoming a bitcoin novice lol
358 2013-07-25 11:35:02 <iwilcox> Zetas: FWIW, from a non-dev, I echo everything phantomcircuit says.
359 2013-07-25 11:35:23 <phantomcircuit> iwilcox, i enjoy oreos
360 2013-07-25 11:35:35 <iwilcox> There be dragons.  Wait for multiwallet support; in the meantime, DIY (better)
361 2013-07-25 11:35:47 <iwilcox> Except the Oreos thing.
362 2013-07-25 11:35:53 <iwilcox> Bourbons ftw :)
363 2013-07-25 11:36:43 <phantomcircuit> i wonder how much data i have to use before comcast gets mad
364 2013-07-25 11:53:15 <Santzes> Hi! Is it possible to get input address(es) from bitcoind api? I'd need my software to automatically send bitcoins back to one of the sending addresses
365 2013-07-25 11:55:18 <phantomcircuit> Santzes, you cant do that
366 2013-07-25 11:55:20 <phantomcircuit> dont even try
367 2013-07-25 11:56:18 <phantomcircuit> sipa, ^
368 2013-07-25 11:57:44 <Santzes> ok thanks, I guess I'll have to look for some other options
369 2013-07-25 12:00:28 <Zetas> God, can't you read the topic? :P
370 2013-07-25 12:01:15 <Santzes> oh damn sorry, somehow missed that
371 2013-07-25 13:15:53 <enigmuriatic> can anyone give me a couple of addresses associated with Mt. Gox?
372 2013-07-25 13:29:59 <jgarzik> sipa, Have a couple corruption reproducers in the BitPay office, which is OSX-heavy
373 2013-07-25 13:30:17 <jgarzik> hopefully can start some focused debugging in a day or two
374 2013-07-25 13:30:34 <TD> did they have resume-from-sleep failures?
375 2013-07-25 13:31:25 <fanquake> jgarzik any of the weird uncorruption instances?
376 2013-07-25 13:31:57 <TD> jgarzik: also, have you made any progress on network metrics? even stuff like how fast txns confirm at various fee levels would be good
377 2013-07-25 13:32:44 <jgarzik> TD, zero zilch nada none
378 2013-07-25 13:33:02 <jgarzik> (progress on metrics)
379 2013-07-25 13:33:22 <jgarzik> fanquake, ENOPARSE
380 2013-07-25 13:33:25 <TD> there's a forum thread from someone complaining his transactions confirm slowly.
381 2013-07-25 13:33:26 <BlueMatt> jgarzik: have you done any work on setting up monitoring in general?
382 2013-07-25 13:33:37 <TD> it's hard to get a feel for how widespread such issues are atm
383 2013-07-25 13:33:40 <jgarzik> TD, good question RE resume.  should have asked that question.
384 2013-07-25 13:33:54 <jgarzik> bluematt: zero silch nada none
385 2013-07-25 13:34:11 <BlueMatt> well, give it a month and Ill start
386 2013-07-25 13:34:14 <jgarzik> 
ACTION is at the stage:  #2, agreeing that we need metrics

387 2013-07-25 13:34:25 <jgarzik> (stage #1 is hot air ideas with zero code)
388 2013-07-25 13:34:33 <gmaxwell> TD: if you get the txid from that person complaining on the forum, be sure to look at the inputs??? I've seen a number of people suffering long confirm times after spending a coin at the end of a _long_ chain of unconfirmed txns.
389 2013-07-25 13:34:43 <TD> yeah. i asked for a txid
390 2013-07-25 13:34:54 <jgarzik> td, bluematt: there is bitcoin-based funding for responsible people who want to work on network metrics
391 2013-07-25 13:35:05 <TD> we should really fix that .... there's no reason chains of transactions shouldn't be included in the same block
392 2013-07-25 13:35:36 <gmaxwell> TD: huh? they are.
393 2013-07-25 13:35:40 <TD> perhaps we should have somewhere we collect "important projects funded by serious people for serious developers" or something
394 2013-07-25 13:35:51 <fanquake> jgarzik you'll have to excuse my noobness... enoparse?
395 2013-07-25 13:35:59 <TD> gmaxwell: i thought there was some quirk in the mining code that meant that to be included a tx inputs had to be confirmed
396 2013-07-25 13:36:06 <gmaxwell> TD: No.
397 2013-07-25 13:36:08 <TD> fanquake: it means he does not understand what you mean
398 2013-07-25 13:36:29 <BlueMatt> jgarzik: hmm..well Im doing it either way (undergrad "research")
399 2013-07-25 13:36:40 <fanquake> TD Ahh. Even google didn't seem to understand.
400 2013-07-25 13:36:43 <TD> BlueMatt: when? :)
401 2013-07-25 13:36:48 <TD> fanquake: it's a weird form of kernel-speak :)
402 2013-07-25 13:36:54 <BlueMatt> TD: starting next semester, or when I have time
403 2013-07-25 13:36:58 <TD> fanquake: -ENOPARSE is a kernel error code meaning "data failed to parse"
404 2013-07-25 13:37:25 <fanquake> TD hah, ok. Cheers for the insight.
405 2013-07-25 13:37:27 <gmaxwell> TD: but such txn can still take a long time even if miners were considering them as a group (which most do not today) just because the effective bytes/fee (or priority) is low.
406 2013-07-25 13:37:45 <fanquake> I'll make sure to scrub on my kernel error codes.
407 2013-07-25 13:38:32 <iwilcox> -EHOMEWORKNEEDED
408 2013-07-25 13:39:41 <TD> oh, hmm. odd. i wonder why i thought that. i must be misremembering something
409 2013-07-25 13:39:49 <TD> or perhaps it changed when ultraprune landed
410 2013-07-25 13:40:33 <fanquake> jgarzik When you've got a chance, if you don't mind, take a look @ issue 2785. I'm running OSX as well. I've had instances of a chainstate DB uncorrupting itself after a restart.
411 2013-07-25 13:40:59 <sipa> the uncorruption is even weirder than random corruption
412 2013-07-25 13:41:04 <gmaxwell> No, it's always been the case, IIRC.  I went back and checked some old blocks and see some examples.
413 2013-07-25 13:41:15 <TD> then i have a corruption in my memory :)
414 2013-07-25 13:41:28 <sipa> it pretty much means the OS is returning inconsistent data when reading from disk...
415 2013-07-25 13:41:35 <TD> sipa: i've seen that as well, actually. i didn't mention it because i figured i must be crazy and have re-ordered things in my brain.
416 2013-07-25 13:41:45 <TD> sipa: but now other people say uncorruption, i guess it's a real thing
417 2013-07-25 13:41:59 <TD> i am wondering if the OS has some kind of async repair process that patches up some bugs to do with failed resumes
418 2013-07-25 13:42:10 <sipa> hmmm
419 2013-07-25 13:42:14 <fanquake> sipa I
420 2013-07-25 13:42:25 <sipa> i'm no king
421 2013-07-25 13:42:41 <fanquake> sipa I'd love to know a way to better log it when it occurs.
422 2013-07-25 13:42:58 <sipa> actually, it doesn't mean that... even if corruption is detected, it doesn't mean no data was being written
423 2013-07-25 13:43:18 <sipa> in particular, the previous log maybe have been (partially) replayed
424 2013-07-25 13:44:12 <TD> BlueMatt: when do you plan to work on metrics?
425 2013-07-25 13:44:30 <TD> BlueMatt: if you need some supplementary income whilst back at university, it sounds like a good idea to take that on :)
426 2013-07-25 13:45:29 <BlueMatt> TD: Ill start not long after I get back, but Im one of the very fortunate few who's parents pay for their college, so income isnt really required
427 2013-07-25 13:46:10 <sipa> BlueMatt: which doesn't mean it isn't nice to get :p
428 2013-07-25 13:46:32 <BlueMatt> well, ok, either way
429 2013-07-25 13:46:40 <TD> income is always required. women impose it :)
430 2013-07-25 13:46:41 <TD> heh
431 2013-07-25 13:46:44 <BlueMatt> Im not really focused entirely on general metrics
432 2013-07-25 13:46:50 <jgarzik> 
ACTION scrolls back

433 2013-07-25 13:46:59 <TD> what would you do?
434 2013-07-25 13:47:01 <BlueMatt> more specifically on block relay and general network relay scaling
435 2013-07-25 13:47:14 <jgarzik> Really, the basic thing we need is simply sampling points regularly producing raw data
436 2013-07-25 13:47:15 <nsh> if you have declared income in the USA, chances are you're funding the world's worst military-industrial-surveillance-prison-general-cuntery-complex
437 2013-07-25 13:47:20 <jgarzik> The rest will sort itself out, RE metrics
438 2013-07-25 13:47:28 <BlueMatt> but building a system which gathers info on relay states is the first step
439 2013-07-25 13:47:28 <jgarzik> If you generate the data, they will come.
440 2013-07-25 13:47:29 <nsh> which is fine if that's not a problem for you. i'd have reservations though
441 2013-07-25 13:47:36 <BlueMatt> so it could probably be easily tweaked
442 2013-07-25 13:47:59 <jgarzik> fanquake, enoparse == I did not understand what you wrote
443 2013-07-25 13:48:39 <jgarzik> sipa, fanquake: what is uncorruption?
444 2013-07-25 13:48:58 <sipa> jgarzik: you start bitcoind, it errors with "database corrupted!"
445 2013-07-25 13:49:04 <sipa> jgarzik: you start it again, and everything work
446 2013-07-25 13:49:07 <fanquake> correct
447 2013-07-25 13:49:16 <jgarzik> worrying ;p
448 2013-07-25 13:50:04 <fanquake> jgarzik note that you have to restart osx before opening it the second time
449 2013-07-25 13:50:27 <gmaxwell> right, flushes the cached data. :-/
450 2013-07-25 13:50:31 <sipa> fanquake: after an uncorruption, and as fast as possible afterwards, can you run a gettxoutsetinfo, and report the resulting hash_serialized?
451 2013-07-25 13:50:38 <gmaxwell> sounds like disk / SATA bus data corruption?
452 2013-07-25 13:50:47 <sipa> fanquake: together with the bestblock value
453 2013-07-25 13:51:14 <fanquake> sipa sure
454 2013-07-25 13:51:22 <sipa> oh, you have to restart
455 2013-07-25 13:51:37 <sipa> that points very strongly towards the OS indeed returning inconsistent read data
456 2013-07-25 13:51:42 <jgarzik> what is leveldb's corrruption/fsck story?  Is each key/value pair checksummed?
457 2013-07-25 13:51:42 <TD> or at least resume and unresume again?
458 2013-07-25 13:51:57 <jgarzik> are there repair/examination tools?
459 2013-07-25 13:51:59 <TD> blocks are checksummed
460 2013-07-25 13:52:00 <fanquake> TD I haven't tried with resume/unresume yet.
461 2013-07-25 13:52:14 <TD> fanquake: i never restart my mac unless there's an OS update or it hoses itself. and i saw uncorruption.
462 2013-07-25 13:52:21 <TD> so i suspect it may be time related or resume/unresume also does it
463 2013-07-25 13:52:51 <fanquake> TD fair enough. Guess it should be somewhat easier to log then?
464 2013-07-25 13:53:36 <sipa> fanquake: with the hash_serialized value we can make sure your database is indeed perfectly intact
465 2013-07-25 13:53:44 <sipa> fanquake: actually, can you run that right now?
466 2013-07-25 13:53:55 <sipa> fanquake: on the system/database that has seen uncorruption
467 2013-07-25 13:54:24 <fanquake> sipa ok. Let me open QT
468 2013-07-25 13:56:25 <jgarzik> sipa, good thought
469 2013-07-25 13:57:17 <sipa> fanquake: tell me when you start running; i'll run it in parallel (the output is dependent on the best chain your client knows)
470 2013-07-25 13:57:26 <fanquake> sipa running now
471 2013-07-25 13:57:46 <fanquake> @ height 248324 "hash_serialized" : "98697a26e20ac38247aac860155a5b8ab74a5a2af71d076cc2670673adcb6e6d"
472 2013-07-25 13:58:27 <fanquake> Now synced @ height 248386 "hash_serialized" : "248b68badf6f54508277230ac926589815fce869504598873ab5e223f25f4a47"
473 2013-07-25 13:59:05 <sipa> that does NOT match my hash
474 2013-07-25 13:59:13 <sipa> anyone else can run a hash_serialized now?
475 2013-07-25 13:59:22 <jgarzik> ACK fanquake
476 2013-07-25 13:59:28 <jgarzik> 
ACTION matches fanquake's hash

477 2013-07-25 13:59:30 <sipa> ok
478 2013-07-25 13:59:36 <fanquake> phew
479 2013-07-25 13:59:42 <sipa> i may have run with the utxo pruning code on my node
480 2013-07-25 13:59:47 <sipa> which would cause a difference
481 2013-07-25 14:00:05 <jgarzik> running on Ubuntu inside Virtual Box VM, on OSX ;p
482 2013-07-25 14:10:33 <fanquake> jgarzik/TD can you remember the name of the OSX feature which is supposed to move your most used files to your SSD ?
483 2013-07-25 14:10:44 <jchp> fusion drive?
484 2013-07-25 14:10:47 <TD> no. but don't modern macbooks only have ssd?
485 2013-07-25 14:11:08 <fanquake> yes jchp
486 2013-07-25 14:12:00 <fanquake> I've wondered wether the randomness could be at all related to that supposed feature. I'm running a 3TB with a 128GB SSD.
487 2013-07-25 14:12:14 <jchp> it's just fancy read caching, e.g. bcache in linux
488 2013-07-25 14:12:42 <jgarzik> BitPay is SSD-only macbook pro
489 2013-07-25 14:12:53 <jgarzik> and two reports of QT crashing
490 2013-07-25 14:13:12 <jchp> yeah most new apple gear is SSD only, pretty much the only ones that use "fusion drive" is some iMacs
491 2013-07-25 14:14:01 <fanquake> Well if TD is seeing it without fusion drive guess that rules it out. Was just a thought.
492 2013-07-25 14:14:20 <TD> i *believe* my laptop has only ssd
493 2013-07-25 14:14:26 <TD> but i honestly never checked. i never heard it click :)
494 2013-07-25 14:14:38 <jchp> oh if QT is crashing it's probably in software, you should check if the machines are using replacement libraries and crazy things like that (i'm looking at you, homebrew and macports)
495 2013-07-25 14:15:20 <jchp> (assuming it's self built using linked libraries ofc)
496 2013-07-25 14:15:25 <fanquake> jchp The crashes, or mine at least, are occurring with official builds. No home grown QT.
497 2013-07-25 14:15:38 <jchp> ah never mind
498 2013-07-25 15:18:59 <iwilcox> Anyone know someone at Gox who could take down http://www.bitcoins.com/ ?  Seems to be run by them but is linking to v0.3.24.
499 2013-07-25 15:24:31 <midnightmagic> <-- still can make feeless tx that get confirms within minutes. :-D
500 2013-07-25 15:37:03 <MobPhone_> sipa you around
501 2013-07-25 15:37:26 <coinerd> can I speak here now?
502 2013-07-25 15:37:30 <coinerd> excellent :)
503 2013-07-25 15:37:57 <coinerd> I'm having trouble getting a transaction accepted by the network, I'm wondering if I can find any help/advice here
504 2013-07-25 15:38:31 <coinerd> when I create the raw transaciton with a single input it's fine, when I add other inputs, even though it signs OK the network rejects it with error code -22
505 2013-07-25 15:39:34 <gmaxwell> coinerd: look in debug.log
506 2013-07-25 15:39:39 <gmaxwell> you should get more info in there.
507 2013-07-25 15:39:46 <coinerd> ok headed to it thanks
508 2013-07-25 15:40:08 <coinerd> ohhhh man this may take a while I don't have console access
509 2013-07-25 15:45:17 <coinerd> If I try to send the signed hex from my local wallet I get a line saying 'ERROR: CTxMemPool::accept() : CheckTransaction failed' is that relevant, or is sending a signed transaction from a different wallet expected to fail anyways?
510 2013-07-25 15:45:48 <coinerd> not to go on a tangent I'm working with admin to get the data from the server's debug.log as well
511 2013-07-25 15:45:51 <gmaxwell> coinerd: when you run the sign does it return complete true?
512 2013-07-25 15:45:56 <coinerd> yessir
513 2013-07-25 15:46:04 <gmaxwell> and you're submitting the output of the sign?
514 2013-07-25 15:46:13 <coinerd> I posted some stuff on bitcointalk too
515 2013-07-25 15:46:14 <coinerd> yes
516 2013-07-25 15:46:16 <gmaxwell> and not say, truncating it at a line break?
517 2013-07-25 15:46:20 <gmaxwell> link?
518 2013-07-25 15:46:25 <coinerd> after receiving it with "complete" = 1
519 2013-07-25 15:46:39 <coinerd> https://bitcointalk.org/index.php?topic=262442.0
520 2013-07-25 15:46:55 <coinerd> I'm in infinitecoin because I don't have bitcoins to test with
521 2013-07-25 15:47:12 <gmaxwell> if you're testing you should use testnet.
522 2013-07-25 15:47:26 <coinerd> the original is being done in PHP directly there should be no truncation or line breaks
523 2013-07-25 15:48:24 <gmaxwell> both your inputs look signed.
524 2013-07-25 15:48:43 <coinerd> I tried including a high fee, too
525 2013-07-25 15:49:17 <gmaxwell> doesn't mean there aren't a billion other possible problems, some perhaps "infinitecoin" specific.
526 2013-07-25 15:49:25 <coinerd> :)
527 2013-07-25 15:49:32 <coinerd> I won't hound you for infinitecoin details
528 2013-07-25 15:49:33 <gmaxwell> are you actually spending coins that exist and are spendable?
529 2013-07-25 15:49:41 <coinerd> yes i believe so
530 2013-07-25 15:49:48 <coinerd> this is an input provided by listunspent
531 2013-07-25 15:50:04 <coinerd> and in this case both inputs are in the block chain
532 2013-07-25 15:50:18 <coinerd> I am working towards a 0 conf arrangement
533 2013-07-25 15:50:45 <coinerd> I Was sort of hopin I had just run into some noob issue
534 2013-07-25 15:51:59 <coinerd> the code in place is fine when refunding a tx using the original tx as input - it's when I try to add another input I run into this
535 2013-07-25 15:52:38 <sipa> MobPhone_: very much so
536 2013-07-25 15:58:24 <coinerd> ok i got a look at the debug.log it shows the same "CheckTransaction Failed" it leaves me stumped
537 2013-07-25 15:59:51 <sodoku> Hi, i am part of bitcoinkiez.de and would like to add shops to the bitcoin.it wiki. How do i get in the trused group?
538 2013-07-25 16:01:18 <sipa> coinerd: CheckTransaction Failed means there is something very fundamentally wrong with the transaction
539 2013-07-25 16:01:39 <sipa> coinerd: but there should be a "
540 2013-07-25 16:01:55 <sipa> coinerd: but there should be a "CheckTransaction() : <reason>" message
541 2013-07-25 16:05:54 <coinerd> ok, there's none in debug log, when I try to send the tx it gives me error code -22
542 2013-07-25 16:06:09 <coinerd> debug.log just gives me ERROR: CTxMemPool::accept() : CheckTransaction failed
543 2013-07-25 16:06:48 <sipa> really?
544 2013-07-25 16:06:55 <sipa> there is no code path that can cause that
545 2013-07-25 16:07:34 <MobPhone_> sipa check your msg please
546 2013-07-25 16:07:40 <sipa> my what?
547 2013-07-25 16:07:48 <coinerd> lol - ok that means that maybe i found an infinitecoin issue and need to stop asking here
548 2013-07-25 16:08:15 <coinerd> or I'm looking int he wrong place - I got access i can flush the log and make sure I'm finding the relevant message now
549 2013-07-25 16:11:31 <sipa> no offence, but i'm not going to do tech support for <anything>coin
550 2013-07-25 16:12:45 <coinerd> no it's no problem
551 2013-07-25 16:13:29 <coinerd> I was just hoping it was a noob issue - I appreciate the advice I already got - since I don't work with bitcoin at this time - well if I can't get past it i may create a testnet setup
552 2013-07-25 16:47:02 <jgarzik> alas.  My batch #3 avalon is lost in space (sent to old NC address, rather than new GA address)
553 2013-07-25 16:48:49 <gmaxwell> jgarzik: pretty awesome, one of my avalons did that. Sent to my old VA address. DHL left it with a random neighbor. I sent someone to go knocking on doors to rescue it.
554 2013-07-25 16:49:18 <gmaxwell> (and did successfully)
555 2013-07-25 16:49:20 <jgarzik> gmaxwell, the kicker, they acknowledged the change of address, and processed batch #2 to new address
556 2013-07-25 16:49:32 <jgarzik> then batch #3 goes back to old
557 2013-07-25 16:50:44 <gmaxwell> similarish for me roughly: I had multiple batch 1 units, they sent only one to the old address. Fortunately I knew it was coming because the other ones showed up, and DHL called me at 6am the day they went out for delivery.
558 2013-07-25 16:51:41 <gmaxwell> the DHL call had an unintelligible tracking number, but I was able to get DHL to look it up based on candidate addresses.
559 2013-07-25 16:52:10 <gmaxwell> I asked DHL to hold it for pickup, but they delivered it anyways.
560 2013-07-25 16:55:32 <jgarzik> whee
561 2013-07-25 16:55:35 <jgarzik> testnet orphan flood
562 2013-07-25 16:55:39 <jgarzik> 4000 and counting
563 2013-07-25 17:13:02 <Luke-Jr> weird, if I try to send, the balance field turns red
564 2013-07-25 17:18:52 <Luke-Jr> hum, looks like I'm reindexing from scratch
565 2013-07-25 17:19:19 <Luke-Jr> after having accidentally tried starting the client when one was still running (I closed the window instead of quitting)
566 2013-07-25 17:19:43 <Luke-Jr> hard to believe it is a coincidence
567 2013-07-25 17:20:11 <Luke-Jr> although who knows what the various patches in  next-test might have influence on
568 2013-07-25 17:20:30 <gmaxwell> we had that overlapping start theory... but I checked and it didn't look possible. :(
569 2013-07-25 17:21:17 <Luke-Jr> 2013-07-25 19:07:55 ERROR: DisconnectBlock() : added transaction mismatch? database corrupted
570 2013-07-25 17:21:36 <Luke-Jr> I did switch to an older next-test in the process - maybe this is the result of the pruning-unspendable-outputs?
571 2013-07-25 17:21:54 <Luke-Jr> are people actually sending unspendable outputs on mainnet?
572 2013-07-25 17:23:37 <gmaxwell> p2pool uses op_return..
573 2013-07-25 17:24:27 <Luke-Jr> ah, right
574 2013-07-25 17:24:36 <Luke-Jr> well, that's a bit annoying
575 2013-07-25 17:24:45 <Luke-Jr> I might have to revert that in my personal branch
576 2013-07-25 17:24:47 <Luke-Jr> or backport it
577 2013-07-25 17:24:57 <Luke-Jr> (to this older version)