1 2013-06-26 00:40:36 <Mad7Scientist> How do I remove the hard linked database files in the .bitcoin directory and just leave them in blocks
  2 2013-06-26 00:41:29 <Mad7Scientist> I guess I just delete the files
  3 2013-06-26 03:57:56 <TradeFortress> Am i using blocknotify right? It is not calling.
  4 2013-06-26 03:58:08 <TradeFortress> ./bitcoind -blocknotify="wget -o /dev/null https://inputs.io/checkblock"
  5 2013-06-26 03:59:02 <TradeFortress> oh wow "--no check-certificate. screw wget"
  6 2013-06-26 04:04:47 <Luke-Jr> TradeFortress: that's inputs.io's fault
  7 2013-06-26 04:05:04 <TradeFortress> Luke-Jr, yeah, actually improper use of wget :)
  8 2013-06-26 04:05:16 <Luke-Jr> I'd use curl there tbh
  9 2013-06-26 04:05:31 <Luke-Jr> and what's the point of encrypting it? :o
 10 2013-06-26 04:05:41 <TradeFortress> I redirect all http traffic to https.
 11 2013-06-26 04:07:20 <TradeFortress> 
ACTION ticks *find out why checkblock / txpool isn't working*, time to track down cross browser compatiblity issues in parsing dates via JS! web dev is fun.

 12 2013-06-26 04:08:55 <Luke-Jr> TradeFortress: that's stupid if you don't have a valid-everywhere cert
 13 2013-06-26 04:09:21 <TradeFortress> Luke-Jr, what do you mean? it works, it's just that I don't think this server has any root CTs.
 14 2013-06-26 04:09:41 <Luke-Jr> TradeFortress: what OS doesn't preinstall a set of reasonable CAs?
 15 2013-06-26 04:09:58 <TradeFortress> Ubuntu 12.04 LTS?
 16 2013-06-26 04:10:04 <Luke-Jr> srsly?
 17 2013-06-26 04:10:16 <TradeFortress> Well, the certificate is valid in every browser I look, but wget doesn't like it.
 18 2013-06-26 04:10:21 <wumpus> it does have CAs but yeah only a very limited set
 19 2013-06-26 04:10:37 <Luke-Jr> Error: The issuer certificate of a locally looked up certificate could not be found
 20 2013-06-26 04:10:47 <phantomcircuit> TradeFortress, wget often has problems with certificates
 21 2013-06-26 04:10:55 <phantomcircuit> you need to specify the directory they're in
 22 2013-06-26 04:11:00 <Luke-Jr> TradeFortress: it's not (supposed) to be a browser-specific thing
 23 2013-06-26 04:11:00 <phantomcircuit> it's some option
 24 2013-06-26 04:11:02 <phantomcircuit> read the man page
 25 2013-06-26 04:11:38 <wumpus> it shouldn't be.. right... it is, though, the set of supported root CAs differs wildly per browser
 26 2013-06-26 04:11:52 <Luke-Jr> wumpus: I use a browser that uses the OS certs like it should
 27 2013-06-26 04:12:13 <wumpus> ok, in that case it's a matter of what OS certs you have installed, which still differs per machine
 28 2013-06-26 04:12:22 <Luke-Jr> anyhow, back to "not universally-valid"
 29 2013-06-26 04:13:25 <Luke-Jr> too bad namecoin died, it could have very well solved  the CA problem
 30 2013-06-26 04:14:29 <wumpus> agreed, CAs are a terrible solution in the first place
 31 2013-06-26 04:14:34 <Luke-Jr> I suppose DNSSEC could too, to a limited extent
 32 2013-06-26 04:15:06 <Diablo-D3> lol dnssec
 33 2013-06-26 05:42:47 <gmaxwell> $ find ./ -type f -path "*autom4te.cache*" -printf "%s %p\\n" | awk '{aa+=$1} END {print aa}'
 34 2013-06-26 05:42:47 <gmaxwell> oh autofools, how I love thee:
 35 2013-06-26 05:42:51 <gmaxwell> 165202099
 36 2013-06-26 08:48:38 <gribble> The expected generation output, at 5000.0 Mhps, given difficulty of 19339258.2724, is 0.130022183206 BTC per day and 0.0054175909669 BTC per hour.
 37 2013-06-26 08:48:38 <sipa> ;;genrate 5000
 38 2013-06-26 08:55:30 <jouke> heh, -rpcconnect assumes ssl by default apparent, took a while to figure that one out.
 39 2013-06-26 08:57:07 <joeykrim> ;;genrate 300
 40 2013-06-26 08:57:08 <gribble> The expected generation output, at 300.0 Mhps, given difficulty of 19339258.2724, is 0.00780133099234 BTC per day and 0.000325055458014 BTC per hour.
 41 2013-06-26 08:57:18 <sipa> jouke: shouldn't be?
 42 2013-06-26 09:03:40 <jouke> No opition on that. I just didn't expect it to be.
 43 2013-06-26 10:56:01 <sipa> ;;genrate 336
 44 2013-06-26 10:56:02 <gribble> The expected generation output, at 336.0 Mhps, given difficulty of 19339258.2724, is 0.00873749071142 BTC per day and 0.000364062112976 BTC per hour.
 45 2013-06-26 11:02:53 <nsh> 
ACTION blinks until gribbles choice of precision makes sense

 46 2013-06-26 11:02:57 <nsh> gribble's
 47 2013-06-26 12:07:17 <helo> does a -rescan happen with bitcoind automatically when reverting to a backup?
 48 2013-06-26 12:07:26 <sipa> yes
 49 2013-06-26 12:08:07 <sipa> it has been half-broken for many versions (between 0.3.21 and 0.8.0, iirc), though
 50 2013-06-26 12:12:47 <helo> a user's 0.8.3precise bitcoind (sans -rescan) was apparently crashing. ./bitcoin-qt -rescan appears to work though.
 51 2013-06-26 12:13:24 <helo> they didn't try bitcoind -rescan
 52 2013-06-26 12:14:33 <sipa> debug.log?
 53 2013-06-26 12:17:44 <helo> they're reproducing it
 54 2013-06-26 12:22:09 <helo> ahh, they installed the bitcoin-qt ppa, but bitcoind from the ubuntu repos (0.3.24-beta)
 55 2013-06-26 12:28:17 <BlueMatt> helo:  how did they manage to do that?
 56 2013-06-26 12:28:29 <BlueMatt> as soon as they upgraded packages, bitcoind should have been upgraded
 57 2013-06-26 12:28:45 <BlueMatt> ahh, didnt read it all, sorry
 58 2013-06-26 12:45:44 <michagogo> BlueMatt: hi
 59 2013-06-26 12:45:58 <BlueMatt> hi
 60 2013-06-26 12:46:03 <michagogo> BlueMatt: What *is* the /contrib/gitian-downloader/ folder?
 61 2013-06-26 12:46:17 <BlueMatt> its wizard magic!
 62 2013-06-26 12:46:28 <michagogo> (gavin told me it's a secure automatic updater thing, how does it work?)
 63 2013-06-26 12:46:52 <BlueMatt> no, its the set of signatures and config files to use gitian-updater which downloads a special zip that has signatures in it and verifies that at least 3 devs signed it and such
 64 2013-06-26 12:47:10 <BlueMatt> https://github.com/devrandom/gitian-builder/blob/master/share/gitian_updater.py
 65 2013-06-26 12:47:21 <michagogo> Specifically, [2013-06-25 21:52:28] <gavinandresen> michagogo: gitian-downloader is a secure, automatic update system that we don't use (yet).  Poke BlueMatt, he should write a README for that folder.
 66 2013-06-26 12:47:41 <BlueMatt> though we never publish the magic zip folders which you need, so you have to make them yourself right now
 67 2013-06-26 12:47:56 <BlueMatt> eventually I want to actually get those part of release-process, but havent done it yet
 68 2013-06-26 12:48:15 <michagogo> BlueMatt: So what, exactly, is the /contrib/gitian-downloader/ for? What do the files in it do?
 69 2013-06-26 12:48:33 <michagogo> (or, when will there be a README answering that?)
 70 2013-06-26 12:49:09 <michagogo> BTW, I've just filed a PR to fix an issue in release-process
 71 2013-06-26 12:53:15 <BlueMatt> the folder has a set of keys for gitian's download config scripts which are in there
 72 2013-06-26 12:53:22 <BlueMatt> when...I write one?
 73 2013-06-26 13:01:06 <jouke> How many simultaneous RPC-connections are possible with bitcoind?
 74 2013-06-26 15:32:12 <bloke> Should pools payout miners using "sendtoaddress" or "sendmany" (assuming that payouts are processed in batches)?
 75 2013-06-26 15:37:12 <michagogo> sendmany
 76 2013-06-26 15:37:24 <michagogo> sendtoaddress is one transaction per sendtoaddress
 77 2013-06-26 15:37:24 <sipa> yes, sendmany
 78 2013-06-26 15:37:29 <michagogo> sendmany is one transaction
 79 2013-06-26 15:38:27 <sipa> smaller effect on the blockchain, and smaller effect on the UTXO set
 80 2013-06-26 15:38:32 <sipa> and smaller fee :p
 81 2013-06-26 15:39:00 <bloke> cheers.
 82 2013-06-26 15:39:04 <michagogo> Though as a pool you don't need to worry about that :-D
 83 2013-06-26 15:39:28 <runeks> BlueMatt: You told me to let you know when bitcoind had successfully run on a armhf system for 14 days. It has now. I compiled bitcoind for my Raspberry Pi, and it has been running since June 19.
 84 2013-06-26 15:40:50 <runeks> BlueMatt: So it would be cool if you could enable armhf builds in the Ubuntu PPA. If you do I will try running the resulting binary on my Pi to see if that works as well just to confirm.
 85 2013-06-26 15:47:10 <BlueMatt> runeks: dont think I meant to be so specific about the date, but...good to hear
 86 2013-06-26 15:47:34 <BlueMatt> sipa: didnt you have a theory about a commit that may have fixed the bad_allocs around the time of ultraprune?
 87 2013-06-26 15:47:53 <BlueMatt> runeks: Ill look into enabling it when I next look at the ppa
 88 2013-06-26 15:48:53 <runeks> BlueMatt: Yup! So it's either a compiler bug or it has been fixed. I used ct-ng with gcc-linaro-4.6-2013.01
 89 2013-06-26 15:48:58 <runeks> BlueMatt: Cool!
 90 2013-06-26 15:49:22 <BlueMatt> Id assume fixed over compiler issue, but in any case good to know
 91 2013-06-26 15:49:49 <sipa> BlueMatt: can't remember that
 92 2013-06-26 15:51:46 <BlueMatt> 
ACTION is too lazy to dig through logs, oh well...sounds like its ok in any case

 93 2013-06-26 15:53:11 <michagogo> Anyone have an opinion about #2798?
 94 2013-06-26 15:53:58 <sipa> michagogo: no objection
 95 2013-06-26 15:54:27 <michagogo> Ah, good -- was worried I was overlooking some detail
 96 2013-06-26 15:55:11 <michagogo> Some requirement gitian has, or something like that
 97 2013-06-26 16:33:40 <warren> petertodd: https://github.com/bitcoin/bitcoin/pull/2791  We would use something similar to this, except the 1-satoshi txo after the 95% miner vote?
 98 2013-06-26 16:50:10 <Vinnie_win> Hey you guys said there were LevelDB corruption issues which happened randomly and can't be tracked down?
 99 2013-06-26 16:50:23 <CodeShark> say I have a transaction with one p2sh input and one output and I'm using SIGHASH_ALL
100 2013-06-26 16:50:30 <CodeShark> the redeem script is a 2-of-2
101 2013-06-26 16:50:36 <CodeShark> OP_2 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG
102 2013-06-26 16:50:38 <sipa> Vinnie_win: yes
103 2013-06-26 16:50:42 <CodeShark> how exactly must the txTmp look like before signing?
104 2013-06-26 16:50:46 <CodeShark> what should be in the input's scriptSig?
105 2013-06-26 16:51:40 <sipa> OP_0 <sig1> <sig2> <redeemscript>, IIRC
106 2013-06-26 16:51:45 <CodeShark> I'm using SIGHASH_ALL, the specific unsigned tx blob is 0100000001a13b2e9304da48db3a12a2a6a6d71a74968b8f6e9716a4717acfdd619f26c6a901000000475221037d32081bf4a1be6e8f2d5dbb98ee9408bd0559988f4c5a779dc40d92b6251a8021021574b25c88eb3c407bf2f9d18221a6bf15bf69ed5c120012300706c141f966e952aeffffffff0130d39700000000001976a914c308c5392a7535fe0033b24db9bac46e890fad1988ac0000000001000000
107 2013-06-26 16:52:02 <CodeShark> yet VerifySignature is failing on this in bitcoind
108 2013-06-26 16:53:18 <CodeShark> sipa, OP_0 <sig1> <sig2> <redeemscript> is the signed transaction scriptSig
109 2013-06-26 16:53:29 <CodeShark> I'm talking about what you need to sign
110 2013-06-26 16:53:48 <sipa> well your txin at least looks wrong to me
111 2013-06-26 16:54:00 <CodeShark> what's wrong with it?
112 2013-06-26 16:54:18 <sipa> you're including the redeemscript, not pushing it as a serialized element
113 2013-06-26 16:54:37 <sipa> and i don't see the 0
114 2013-06-26 16:54:54 <CodeShark> so byte for byte what should the scriptSig look like?
115 2013-06-26 16:55:10 <sipa> 2 037d32081bf4a1be6e8f2d5dbb98ee9408bd0559988f4c5a779dc40d92b6251a80 021574b25c88eb3c407bf2f9d18221a6bf15bf69ed5c120012300706c141f966e9 2 OP_CHECKMULTISIG
116 2013-06-26 16:55:16 <sipa> is the current script
117 2013-06-26 16:55:36 <sipa> right?
118 2013-06-26 16:55:44 <CodeShark> I believe so, yes
119 2013-06-26 16:55:48 <sipa> that seems to be only the redeemscript
120 2013-06-26 16:55:53 <sipa> not the actual inputs
121 2013-06-26 16:56:02 <CodeShark> actual inputs?
122 2013-06-26 16:56:04 <sipa> ah, unsigned
123 2013-06-26 16:56:07 <sipa> never mind
124 2013-06-26 16:56:30 <CodeShark> do I need to prefix the redeemscript with an OP PUSH?
125 2013-06-26 16:56:31 <sipa> so the scriptSig should be "OP_0 <sig1> <sig2> <redeemscrip>"
126 2013-06-26 16:56:34 <sipa> not "redeemscript"
127 2013-06-26 16:56:40 <CodeShark> I can't sign a signature
128 2013-06-26 16:56:50 <sipa> you're not even at the point were you can try signing
129 2013-06-26 16:56:59 <sipa> the redeemscript itself is pushed on the stack as a data element
130 2013-06-26 16:57:07 <sipa> it's not included as a script in the scriptSig
131 2013-06-26 16:57:35 <CodeShark> it isn't?
132 2013-06-26 16:57:41 <Vinnie_win> sipa: We've had 1 or 2 reports of LevelDB corruption in Ripple, under FreeBSD. We're using the same branch of LevelDB as the one it Bitcoin. Is there a post or some sort of discussion regarding the corruption you're seeing in Bitcoin that we can compare it against and maybe get it sorted?
133 2013-06-26 16:58:10 <sipa> Vinnie_win: search the issue tracker, there are several reports
134 2013-06-26 16:58:48 <sipa> https://github.com/bitcoin/bitcoin/issues/2770
135 2013-06-26 16:58:59 <Vinnie_win> sipa: Thank you. I will look through it and let you know what we find.
136 2013-06-26 16:59:00 <CodeShark> sipa: it seems the redeemscript is EXACTLY what's in scriptSig
137 2013-06-26 16:59:11 <sipa> https://github.com/bitcoin/bitcoin/issues/2745
138 2013-06-26 16:59:23 <CodeShark> does the redeemscript need to be prefixed with a push command?
139 2013-06-26 16:59:34 <sipa> CodeShark: that's one way to look at it, yes
140 2013-06-26 17:00:07 <sipa> CodeShark: you're now just including the redeemscript in the scriptsig, that's not correct: you have to push the serialized redeemscript as a single data element on the stack
141 2013-06-26 17:00:41 <sipa> https://github.com/bitcoin/bitcoin/issues/2726
142 2013-06-26 17:01:12 <sipa> https://github.com/bitcoin/bitcoin/issues/2631
143 2013-06-26 17:02:15 <Vinnie_win> sipa: Man...that's really scary. LevelDB is not up to Google snuff.
144 2013-06-26 17:02:29 <sipa> Vinnie_win: i'm not convinced it's leveldb's fault
145 2013-06-26 17:02:40 <sipa> Vinnie_win: i'm sure some of these reports are just from faulty hardware
146 2013-06-26 17:02:49 <sipa> Vinnie_win: but i really doubt it's all of them
147 2013-06-26 17:04:08 <Vinnie_win> sipa: Good to know. Thanks.
148 2013-06-26 17:04:19 <sipa> Vinnie_win: i work for google, btw :)
149 2013-06-26 17:05:37 <Vinnie_win> sipa: haha okay. well...since you work for google is there any way to get our changes sent up to the mothership, a.k.a. LevelDB upstream? Because it seems they still haven't made the windows/android ports "official"
150 2013-06-26 17:08:13 <sipa> Vinnie_win: i was hoping we'd learn where those corruption reports come from, as there seem to be more on windows (which may also be due to those users having weaker hardware...)... though OSX also has a share
151 2013-06-26 17:08:36 <sipa> Vinnie_win: but yes, i intend to try to get it upstream at some point
152 2013-06-26 17:10:06 <sipa> CodeShark: so the scriptsig should be "OP_0 <push of sig1> <push of sig2> <push of <op_2 <push of pubkey1> <push of pubkey2> op_2 op_checkmultisig>>"
153 2013-06-26 17:10:16 <CodeShark> ok, I added the PUSH byte. this is what I'm signing: 0100000001a13b2e9304da48db3a12a2a6a6d71a74968b8f6e9716a4717acfdd619f26c6a90100000048475221037d32081bf4a1be6e8f2d5dbb98ee9408bd0559988f4c5a779dc40d92b6251a8021021574b25c88eb3c407bf2f9d18221a6bf15bf69ed5c120012300706c141f966e952aeffffffff0130d39700000000001976a914c308c5392a7535fe0033b24db9bac46e890fad1988ac0000000001000000
154 2013-06-26 17:10:29 <sipa> you're trying to sign yourself, not using signrawtransaction?
155 2013-06-26 17:10:40 <CodeShark> yes, that's the whole point of this exercise!
156 2013-06-26 17:10:42 <sipa> ok
157 2013-06-26 17:10:54 <sipa> well, i don't feel like decoding your hex
158 2013-06-26 17:11:07 <CodeShark> decoderawtransaction to the rescue :)
159 2013-06-26 17:11:17 <sipa> but maybe this helps: https://github.com/bitcoin/bitcoin/pull/2645
160 2013-06-26 17:12:06 <CodeShark> I'm fairly certain that my scriptSig format is correct in the signed transction but my signatures are not
161 2013-06-26 17:12:15 <CodeShark> and the reason is that I'm not signing the correct data
162 2013-06-26 17:12:25 <sipa> you have to replace the vin scriptSig with the scriptPubKey of the output being consumed, no?
163 2013-06-26 17:12:39 <CodeShark> that's exactly what I'm wondering - what goes in the scriptSig?
164 2013-06-26 17:12:42 <CodeShark> I've tried a bunch of different things
165 2013-06-26 17:12:45 <CodeShark> none of them have worked
166 2013-06-26 17:13:05 <CodeShark> for pay-to-address, I've just stuck the scriptPubKey of the claimed output
167 2013-06-26 17:13:07 <CodeShark> and it's worked fine
168 2013-06-26 17:13:17 <CodeShark> but I tried that with p2sh and fail
169 2013-06-26 17:13:23 <CodeShark> fail
170 2013-06-26 17:13:23 <CodeShark> I also tried sticking in just the redeem script
171 2013-06-26 17:13:36 <CodeShark> redeem script + scriptPubKey of previous transaction - fail
172 2013-06-26 17:13:52 <sipa> well maybe the fail is because of another thing being wrong
173 2013-06-26 17:13:53 <CodeShark> OP_0 + redeem script + scriptPubKey of previous transaction - fail
174 2013-06-26 17:14:06 <CodeShark> I've stuck tracers in bitcoind
175 2013-06-26 17:14:20 <CodeShark> EvalScript is returning true but the last byte is 0
176 2013-06-26 17:14:39 <CodeShark> and I'm getting VerifySignature failures
177 2013-06-26 17:14:58 <CodeShark> which all seems to point at me passing in the incorrect data to the signer
178 2013-06-26 17:15:59 <CodeShark> specifically, I'm only tinkering with the scriptSig of the input and am postpending a big endian hash type - SIGHASH_ALL
179 2013-06-26 17:16:07 <CodeShark> and signing that
180 2013-06-26 17:17:48 <CodeShark> I guess I'll continue digging in the source and sticking more tracers in
181 2013-06-26 17:18:23 <CodeShark> clearly the scriptSig of the blob to sign cannot contain the signatures
182 2013-06-26 17:18:46 <CodeShark> so I must be missing some opcode or some endian crap
183 2013-06-26 17:20:48 <CodeShark> anyhow, thanks for the help - I'll figure it out eventually :)
184 2013-06-26 17:22:23 <sipa> for P2SH, it looks like the scriptcode (the thing whose script is put in place of the scriptSig being signed) is the redeemScript
185 2013-06-26 17:22:43 <sipa> unsure whether packed or not
186 2013-06-26 17:27:01 <CodeShark> here's a 4-of-4 scriptSig I dissected from the block chain: http://pastebin.com/rdYBCuDU
187 2013-06-26 17:27:13 <CodeShark> that's exactly how I'm formatting my scriptSig
188 2013-06-26 17:27:28 <CodeShark> I think the only problem I'm having is my signatures are invalid because I'm not signing the correct data
189 2013-06-26 17:28:36 <CodeShark> which means that the scriptSig of the txTmp (before signing) is probably wrong
190 2013-06-26 17:29:51 <CodeShark> notice the signatures have a 0x01 appended (SIGHASH_ALL)
191 2013-06-26 17:30:18 <CodeShark> and it is my understanding that it's necessary to append 0x01000000 (32-byte big endian) to the transaction prior to signing
192 2013-06-26 17:30:33 <CodeShark> all that's worked fine for my pay-to-address signer
193 2013-06-26 17:35:38 <sipa> CodeShark: instrument the bitcoind code to print the txTmp being signed, before hashing it?
194 2013-06-26 17:36:07 <CodeShark> I did that - it was showing the redeemscript in the scriptSig
195 2013-06-26 17:36:34 <CodeShark> but perhaps I made a mistake
196 2013-06-26 17:36:41 <sipa> ok, sounds right
197 2013-06-26 17:38:41 <CodeShark> I'll try that again - the trick is not getting it to overwhelm the output with everyone else's transactions :)
198 2013-06-26 19:56:21 <sipa> ;;blocks
199 2013-06-26 19:56:22 <gribble> 243489
200 2013-06-26 20:14:18 <lianj> why is bitcoind using rand_bytes with its own (range)check instead of EC_KEY_generate_key ?
201 2013-06-26 20:15:08 <sipa> faster
202 2013-06-26 20:15:40 <sipa> there's no need for an EC multiplication just to create a private key
203 2013-06-26 20:18:36 <lianj> where does the ec multiplication happen in EC_KEY_generate_key -> BN_rand_range ?
204 2013-06-26 20:18:54 <sipa> EC_KEY_generate_key computes both private key and public key
205 2013-06-26 20:19:06 <sipa> which means an EC multiplication
206 2013-06-26 20:20:29 <lianj> oh that makes sense now. so its /slower/ because it creates the pubkey aswell. thanks!
207 2013-06-26 20:20:46 <sipa> well, we need the pubkey too anyway
208 2013-06-26 20:21:00 <sipa> but because of how the code is structured now (which simplifies a lot), CKey is only a private key
209 2013-06-26 20:22:21 <lianj> i'm just curious because bitcoind uses RAND_bytes and EC_KEY_generate_key seems to use BN_rand_range which doesn't use RAND_BYTES but instead does some bignum calc which i haven looked into deep yet
210 2013-06-26 20:23:51 <lianj> sipa: but you think its fine to just use EC_KEY_generate_key and still have the same security bitcoind wallet keys have?
211 2013-06-26 20:24:20 <sipa> it's only git head that doesn't use EC_KEY_generate_key
212 2013-06-26 20:24:29 <sipa> that key refactor was merged a month ago or so
213 2013-06-26 20:24:53 <sipa> so yes, sure
214 2013-06-26 20:26:10 <lianj> oh gotcha, thanks! damn me for reading only head
215 2013-06-26 20:54:43 <sipa> in the last week, out of 286584 relayed transactions, 1360 had non-canonical signatures
216 2013-06-26 20:55:11 <sipa> though it's maybe more interesting to see how many of those still get into blocks
217 2013-06-26 20:59:32 <pigeons> sipa: how did you count the non-canonical signatures?
218 2013-06-26 21:00:58 <sipa> pigeons: tail -n 10000000 ~/.bitcoin/debug.log | fgrep -A1 -i canonical | fgrep 'VerifySignature failed' | cut -d ' ' -f 6 | sort | uniq | wc
219 2013-06-26 21:03:58 <pigeons> thanks :)
220 2013-06-26 21:05:18 <LorenzoMoney> How do you get an ASICMiner USB stick to work on an XP machine?
221 2013-06-26 21:05:38 <sturles> You install Linux on it.
222 2013-06-26 21:05:51 <sturles> -> #bitcoin-mining, btw.
223 2013-06-26 21:06:02 <LorenzoMoney> thanks!
224 2013-06-26 21:12:30 <sturles> You are all going to hate me for this, but I'm leaving it here anyway: http://www.coinheist.com/rubik/a_regular_crossword/grid.pdf
225 2013-06-26 21:15:51 <gwillen> sturles: that was a great puzzle
226 2013-06-26 23:26:17 <imd23> hi
227 2013-06-26 23:27:14 <imd23> can someone explain me the script part of the transactions?
228 2013-06-26 23:28:09 <phantomcircuit> imd23, https://en.bitcoin.it/wiki/Script
229 2013-06-26 23:28:21 <phantomcircuit> https://en.bitcoin.it/wiki/Transactions
230 2013-06-26 23:30:17 <A2501> any programer here that uses ruby?
231 2013-06-26 23:30:43 <gwillen> A2501: oddly enough, yes, why?
232 2013-06-26 23:32:30 <A2501> I need someone to finish a work some idiot did not finish
233 2013-06-26 23:32:35 <A2501> sorry my language
234 2013-06-26 23:32:51 <gwillen> ah sorry, I'm not doing contract work
235 2013-06-26 23:32:54 <gwillen> but good luck :-)
236 2013-06-26 23:33:07 <A2501> well, is ready
237 2013-06-26 23:33:14 <A2501> just need few things
238 2013-06-26 23:33:43 <imd23> phantomcircuit: Thanks, I tried to read that but my head is a mess, i need some lower level explanation.