1 2012-06-05 00:43:28 <DBordello> Something is upsetting the windows client when syncing the blockchain - http://i.imgur.com/reqyC.png
  2 2012-06-05 00:43:30 <DBordello> Ideas?
  3 2012-06-05 00:43:44 <DBordello> I am running 0.6.2-beta
  4 2012-06-05 01:59:26 <splatster> What would be the best way to "hand off" control of a wallet to another person?
  5 2012-06-05 01:59:58 <splatster> I was thinking that I could just change the wallet's password, zip it up, encrypt it, and send it like that.
  6 2012-06-05 02:00:08 <copumpkin> not sure there's a good way that doesn't require them to trust you forever
  7 2012-06-05 02:00:53 <splatster> copumpkin: It's me allowing another person access to the same set of funds.
  8 2012-06-05 02:01:11 <copumpkin> you can't both work on the same wallet
  9 2012-06-05 02:01:21 <copumpkin> not in a useful way
 10 2012-06-05 02:01:25 <splatster> Ya, I know.
 11 2012-06-05 02:01:50 <splatster> So when the wallet is "returned", I get rid of the old copy in case it has a different key pool.
 12 2012-06-05 02:03:57 <luke-jr> splatster: if there's only a few keys, dumpprivkey is nice
 13 2012-06-05 02:05:00 <splatster> But then won't there be an unencrypted copy of the keys?
 14 2012-06-05 02:05:13 <splatster> Which is more what I -don't- want.
 15 2012-06-05 02:13:16 <guruvan> splatster:  wizkid057 was talking about patching vanitygen to encrypt the private keys with gpg - you might talk to him about that - I thought it would be hugely useful
 16 2012-06-05 02:19:50 <splatster> guruvan: I really just meant encrypting the whole wallet.dat along with having the keys encrypted by bitcoind.
 17 2012-06-05 02:21:03 <weex> Joric created a minimal python address generator last night
 18 2012-06-05 02:21:09 <guruvan> ah...yeah - if you're just doing that I'd just send in an encrypted file then
 19 2012-06-05 02:21:14 <weex> it could probably be modded to encrypt before printing
 20 2012-06-05 02:24:21 <guruvan> if it was done so that the creator wouldn't have any way to recoved the privatekey  that was just generated it would be pretty cool
 21 2012-06-05 02:25:59 <weex> i put it on my github: https://github.com/weex/addrgen
 22 2012-06-05 02:26:25 <weex> i don't think you can prove a negative though
 23 2012-06-05 02:27:25 <weex> actually i read recently about a way to safely generate vanity addresses using key addition
 24 2012-06-05 02:28:09 <weex> https://bitcointalk.org/index.php?topic=56839.0
 25 2012-06-05 02:35:53 <luke-jr> weex: hey, that's pretty cool, someone made a pool!
 26 2012-06-05 02:36:39 <weex> can't tell if serious
 27 2012-06-05 02:40:36 <weex> ah yes i see it
 28 2012-06-05 03:32:02 <gribble> New news from bitcoinrss: Diapolo opened pull request 1420 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1420>
 29 2012-06-05 03:37:10 <gribble> New news from bitcoinrss: Diapolo opened pull request 1421 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1421>
 30 2012-06-05 03:42:11 <gribble> New news from bitcoinrss: Diapolo opened pull request 1422 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1422>
 31 2012-06-05 03:48:42 <sipa> m-m-m-multipull!
 32 2012-06-05 04:09:40 <luke-jr> lol
 33 2012-06-05 04:10:26 <Diablo-D3> sipa: I want to play superandroid now for some reason
 34 2012-06-05 04:12:52 <phantomcircuit> Diablo-D3, i want to play your face
 35 2012-06-05 07:01:19 <gribble> New news from bitcoinrss: dooglus opened issue 1423 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1423>
 36 2012-06-05 07:10:52 <jine> https://bitcointalk.org/index.php?topic=85574.0 v6 and bitcoin!
 37 2012-06-05 08:10:48 <kokjo> so OP_CHECKSIG?
 38 2012-06-05 08:11:27 <kokjo> what was satoshi thinking when he wrote it? its a mess and i don't understand it.
 39 2012-06-05 08:12:18 <freewil> two drops of acid and a 40oz
 40 2012-06-05 08:12:24 <freewil> then you'll be in the same mindset
 41 2012-06-05 08:12:27 <freewil> you'll understand
 42 2012-06-05 08:12:43 <kokjo> first you are replacing all the input scripts, with the output script, unless OP_CODESEP then something machilally happens
 43 2012-06-05 08:13:00 <kokjo> magicly*
 44 2012-06-05 08:14:05 <kokjo> it has just taken me ~2hours to verify the transaction in block 170 by hand, and there was alot of hacks and uglyness in it.
 45 2012-06-05 08:14:57 <kokjo> and im not sure that i know what i did, or i was just lucky
 46 2012-06-05 08:15:00 <freewil> i dont know much about the scripts, but it looks like you can make subscripts so it sounds like a OP_CODESEP would mark the beginning of a nested script
 47 2012-06-05 08:16:30 <kokjo> yes, but why should it be copied/replace into the spending tx's input script? it don't seems logically at all
 48 2012-06-05 08:17:03 <kokjo> and why the 0x04 prefix byte infront of the publickey?
 49 2012-06-05 08:18:00 <kokjo> im trying to do my own bitcoin client in python: https://github.com/kokjo/pycoin
 50 2012-06-05 08:19:11 <kokjo> it can handle reorgs, and confirm/revert transactions, but not yet fully validate a transaction(OP_CHECKSIG), or create transactions.
 51 2012-06-05 08:20:49 <freewil> this might be easier to understand
 52 2012-06-05 08:20:50 <freewil> https://github.com/bitcoinjs/bitcoinjs-server/blob/master/lib/scriptinterpreter.js#L536
 53 2012-06-05 08:25:01 <kokjo> it don't seems like its verifying the sig in anyway.
 54 2012-06-05 08:27:39 <kokjo> im currently looking at this code: https://gitorious.org/electrum/electrum/blobs/master/lib/wallet.py#line686
 55 2012-06-05 08:27:42 <kokjo> and this: https://gitorious.org/electrum/electrum/blobs/master/lib/wallet.py#line176
 56 2012-06-05 08:29:41 <freewil> TD, could probably answer your question
 57 2012-06-05 08:30:10 <TD> i'm not sure what the question is
 58 2012-06-05 08:32:28 <kokjo> TD: how does OP_CHECKSIG work? it seems a bit messy.
 59 2012-06-05 08:32:54 <TD> lol
 60 2012-06-05 08:32:56 <TD> it's complicated, yes
 61 2012-06-05 08:33:14 <TD> it reads a signature and a key, then calculates a simplified hash of the transaction, then checks the signature against the hash and the key
 62 2012-06-05 08:34:06 <kokjo> i have spend 2 hours, validating the block 170 tx by hand, to try to get a understanding of it. but it only confused me more.
 63 2012-06-05 08:34:16 <TD> jesus satoshidice is creating a ton of transactions
 64 2012-06-05 08:34:30 <TD> kokjo: try reading the bitcoinj code. there are lots of comments
 65 2012-06-05 08:35:11 <kokjo> TD: will do
 66 2012-06-05 08:35:47 <freewil> lol satoshidice... people
 67 2012-06-05 08:37:37 <TD> kokjo: i'd suggest aiming firstly for a lightweight/SPV client. it's a LOT of work to do even that. then you can try a fully-validating node later
 68 2012-06-05 08:38:17 <TD> kokjo: bitcoinj does not validate transactions (though it would not be difficult to add), because it doesn't store them all. but you can see the code to sign transactions here:
 69 2012-06-05 08:38:18 <TD> http://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/Transaction.java#625
 70 2012-06-05 08:38:19 <TD> it may help
 71 2012-06-05 08:43:00 <kokjo> this code is good: http://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/Transaction.java#705 thats what i was kind of looking for :D
 72 2012-06-05 08:43:18 <kokjo> now next question: OP_CODESEPERATOR?
 73 2012-06-05 08:49:44 <TD> kokjo: ah
 74 2012-06-05 08:49:47 <TD> kokjo: ignore it
 75 2012-06-05 08:49:52 <TD> kokjo: story for when i'm back from lunch
 76 2012-06-05 08:50:07 <kokjo> lol, fine! :)
 77 2012-06-05 09:28:56 <TD> kokjo: OP_CODESEPARATOR is obsolete and no longer has a purpose. it's left over from a broken design satoshi used in the first version
 78 2012-06-05 09:29:10 <TD> kokjo: if you want to fully validate, you still need to implement it of course. however it's useless.
 79 2012-06-05 09:29:19 <TD> kokjo: like i said. implement SPV first. it's a good first base
 80 2012-06-05 09:35:37 <kokjo> TD: are there transactions that uses OP_CODESEPERATOR?
 81 2012-06-05 09:35:50 <TD> no. it was a purely internal thing.
 82 2012-06-05 09:36:22 <kokjo> TD: not even onld ones?
 83 2012-06-05 09:36:29 <TD> it was never included in any transactions
 84 2012-06-05 09:36:30 <kokjo> old*
 85 2012-06-05 09:36:45 <TD> like i said. don't try to run scripts at first.
 86 2012-06-05 09:37:00 <TD> implement SPV. it's still a lot of difficult work. once you have a solid SPV implementation, you can extend it to full mode
 87 2012-06-05 09:37:51 <TD> wow. a megabyte of pending transactions.
 88 2012-06-05 09:38:43 <kokjo> thats much!
 89 2012-06-05 09:39:49 <kokjo> TD: but i think scripts are kind of easy, except OP_CHECKSIG.
 90 2012-06-05 09:41:36 <kokjo> finaly made some code that works: http://pastebin.com/u809EtpC
 91 2012-06-05 09:41:36 <TD> scripts are easy except the part that isn't :) it's not enough to implement a few opcodes. you have to write a crapton of unit tests to ensure you match the behavior of satoshis code EXACTLY
 92 2012-06-05 09:41:41 <TD> if you don't you could break the network in future yeras
 93 2012-06-05 09:42:47 <kokjo> TD: naaa, im just gonna hope im lucky! and i don't break anything :D
 94 2012-06-05 09:43:40 <TD> seriously. do SPV first. don't try for a full node just because it looks easy - it isn't. after you have a solid implementation that can receive transactions, create spends, handle re-orgs with the wallet properly, manage the P2P network competently, etc, then go back and do the extra stuff
 95 2012-06-05 09:48:47 <kokjo> but my implementation , handles difficulty change, reorgs, good right now. and i though that i would contineue with scripting. I guess i should just check for standart scripts, and extract the key, sig and address, instead of running the scripts.
 96 2012-06-05 09:50:28 <SomeoneWeird> ugh i wish bitcoinjs worked
 97 2012-06-05 09:54:05 <UukGoblin> hrm http://blockexplorer.com/q/difficulty errors, gribble 500s - what's the current difficulty?
 98 2012-06-05 12:18:38 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1424 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1424>
 99 2012-06-05 12:28:44 <gribble> New news from bitcoinrss: Diapolo opened issue 1425 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1425>
100 2012-06-05 13:32:09 <ciscoftw> is there a command via bitcoind that will list the connected peers 'best height'? like a getinfo command for peer related info...
101 2012-06-05 13:32:58 <ciscoftw> 'time' metric would also be nice in addition to 'best height'
102 2012-06-05 13:39:45 <BlueMatt> not currently
103 2012-06-05 13:49:23 <gavinandresen> RPC methods to get information on your peers is a Good Idea.  Somebody should design a set of RPC commands for that...  (get peer info, disconnect and/or ban, connect, etc)
104 2012-06-05 13:50:43 <gavinandresen> (I'm busy working on https://gist.github.com/2839617 )
105 2012-06-05 13:58:34 <ciscoftw> pretty sure it wont help, but worth mentioning... Andreas Schildbach's 'bitcoin wallet' for android v2.1 has a peer monitor function that gives 'client versions' 'time'  and 'best height'
106 2012-06-05 14:04:07 <BlueMatt> it would also be really nice to see rpc commands to -addnode while running and check the status of -addnode peers
107 2012-06-05 14:10:37 <sipa> gavinandresen: i'd suggest a getnetworkinfo, that returns proxy settings, connected peers, some statistics maybe, ...
108 2012-06-05 14:10:42 <sipa> known local addresses
109 2012-06-05 14:11:29 <Matt_von_Mises> What is the maximum signature size? When writing a signature to a script can I put the length before the signature, aka is it 75 bytes or less? OpenSSL doesn't say much about the range ECDSA_size returns.
110 2012-06-05 14:11:46 <Matt_von_Mises> doesn't say much -> doesn't say anything.
111 2012-06-05 14:12:45 <sipa> Matt_von_Mises: DER-serialized ECDSA signatures from secp256k1 are max 72 bytes, i believe
112 2012-06-05 14:13:56 <Matt_von_Mises> sipa: OK thanks, so it would be safe to put the number of bytes to push without OP_PUSHDATA1?
113 2012-06-05 14:14:25 <Matt_von_Mises> I was trying to find what the C++ client does for scriptSig. I'm a bit lost at the moment...
114 2012-06-05 14:16:09 <gavinandresen> sipa: openssl will take BER-encoded sigs, too, though right?
115 2012-06-05 14:16:47 <sipa> Matt_von_Mises: not sure what you're asking now
116 2012-06-05 14:17:15 <sipa> gavinandresen: yes, so for incoming data you probably need more room
117 2012-06-05 14:18:10 <Matt_von_Mises> Do the scriptSig (input script) with transactions made using bitcoin-qt use OP_PUSHDATA1 to push the signatures?
118 2012-06-05 14:18:24 <Matt_von_Mises> sipa: THat's what I meant.
119 2012-06-05 14:18:57 <gavinandresen> No, they use the single-byte "push this many bytes onto the stack" opcodes
120 2012-06-05 14:19:21 <gavinandresen> They COULD use OP_PUSHDATA1, though.  Or PUSHDATA2 or 4.
121 2012-06-05 14:19:23 <sipa> Matt_von_Mises: what gavin said, but that doesn't mean it's the only allowed way to do that
122 2012-06-05 14:19:37 <Matt_von_Mises> gavinandresen: OK thanks.
123 2012-06-05 14:19:57 <Matt_von_Mises> sipa: Yes, I just need to make a transaction with the usual DER signature.
124 2012-06-05 14:24:58 <gavinandresen> When I finish the signrawtx RPC call I plan on making non-canonical scriptSigs non-standard, because allowing different encodings of the same signature feels like a security risk.
125 2012-06-05 14:45:45 <BlueMatt> has anyone ever seen a 2500-deep block issue, or can we change the default -checkblocks to something much lower than 2500, it seems like -checkblocks, by default, eats up the majority of the load time in bitcoin?
126 2012-06-05 14:45:52 <BlueMatt> or is that just on tmpfs
127 2012-06-05 16:53:43 <rebroad> tried "make -j" for bitcoin today... didn't work ....
128 2012-06-05 16:57:34 <Matt_von_Mises> Something I need to be clear about: Does OpenSSL (and therefor bitcoin) only support BER encoding. I guess I should make it clear in my library that only BER (including DER) encoding must be used but if there are more types I'd need to make clear these must also be supported.
129 2012-06-05 16:58:59 <sipa> Matt_von_Mises: only BER
130 2012-06-05 16:59:11 <sipa> for OP_CHECKSIG, that is
131 2012-06-05 16:59:21 <sipa> message signing uses a different (shorter) encoding
132 2012-06-05 17:02:23 <Matt_von_Mises> sipa: OK thanks. That includes the public keys too?
133 2012-06-05 17:02:58 <sipa> public keys use the encoding defined by the SEC standard (which standardizes secp256k1)
134 2012-06-05 17:03:04 <BlueMatt> rebroad: yea...might wanna limit it a bit
135 2012-06-05 17:04:06 <sipa> Matt_von_Mises: that means 0x04 + x_coord + y_coord, or 0x02 + x_coord (if y_coord is even) or 0x03 + x_coord (if y_coord is odd)
136 2012-06-05 17:04:42 <sipa> openssl technically also defines 0x05, 0x00 and 0x06 as prefixes for encodings
137 2012-06-05 17:05:01 <sipa> or was it 0x06 and 0x07
138 2012-06-05 17:06:32 <Matt_von_Mises> So with OpenSSL, it expands upon the SEC standard?
139 2012-06-05 17:08:38 <sipa> i think that 0x06 and 0x07 aren't defined by SEC, and technically i suppose that if someone would use it on the bitcoin network, it would be accepted by satoshi code miner nodes
140 2012-06-05 17:09:30 <sipa> 0x00 is defined by SEC, but it represents the point at infinity, which is not a valid public key
141 2012-06-05 17:09:51 <Matt_von_Mises> So there is a problem when not implementing these OpenSSL extra codes? Hmm.
142 2012-06-05 17:10:14 <sipa> in theory
143 2012-06-05 17:10:20 <Matt_von_Mises> This doesn't make OpenSSL very good if it doesn't stick to the encryption standards.
144 2012-06-05 17:10:26 <sipa> agree
145 2012-06-05 17:10:32 <sipa> it messes with BER too, i believe
146 2012-06-05 17:10:55 <sipa> something about signed or unsigned integers
147 2012-06-05 17:11:57 <Matt_von_Mises> I want my library to be in standard C so I'm providing function pointers to external cryptography libraries. I was hoping people could use whatever library they wanted but now I need to make it clear in the docs that there could be severe compatibility problems when not using OpenSSL.
148 2012-06-05 17:12:38 <sipa> i think you should stick to openssl for now - it's not that hard to make it configurable afterwards if needed
149 2012-06-05 17:13:49 <Matt_von_Mises> In my tests I'm configuring for OpenSSL.
150 2012-06-05 17:17:22 <Matt_von_Mises> In the documentation I just put: "This function must stick to the cryptography requirements in OpenSSL. There may be compatibility problems when using libraries or code other than OpenSSL since OpenSSL does not adhere fully to the SEC1 ECDSA standards."
151 2012-06-05 17:18:50 <Matt_von_Mises> All I need to add to that is the OpenSSL version. What is the OpenSSL version bitcoin uses? I believe it is 1.0.0
152 2012-06-05 17:19:02 <Matt_von_Mises> At least that's what it says with my version of bitcoin.
153 2012-06-05 17:19:52 <sipa> actually, it may be a useful test to see what happens when a 0x06 or 0x07 pubkey is used on testnet
154 2012-06-05 17:21:53 <D34TH> matt_von_mises 1.0.1c
155 2012-06-05 17:22:40 <Matt_von_Mises> D34TH: Okay thanks, though on my bitcoin package it says "libssl.1.0.0.dylib"
156 2012-06-05 17:23:14 <D34TH> ahh you have a mac
157 2012-06-05 17:23:14 <Matt_von_Mises> The Mac version uses 1.0.0? I guess (and would hope) they are compatible with each other anyway.
158 2012-06-05 17:23:34 <luke-jr> I think the Mac version currently uses whatever Gavin has :p
159 2012-06-05 17:23:44 <rebroad> BlueMatt: have you got make -j working?
160 2012-06-05 17:23:52 <Matt_von_Mises> In my documentation I'll just put 1.0.0.
161 2012-06-05 17:23:55 <luke-jr> my cross-compiled Mac builds use 1.0.1b
162 2012-06-05 17:24:11 <luke-jr> Matt_von_Mises: probably better not to recommend a version with known exploits
163 2012-06-05 17:24:25 <luke-jr> (they don't affect Bitcoin, but might something else)
164 2012-06-05 17:24:44 <Matt_von_Mises> luke-jr: I put "OpenSSL version 1.0.0 or any compatible version"
165 2012-06-05 17:25:23 <luke-jr> also, this is one of those things that probably varies based on the bigger miners
166 2012-06-05 17:26:10 <Matt_von_Mises> I hope no one takes OpenSSL for granted. It could become a weak spot someday.
167 2012-06-05 17:26:43 <rebroad> my bitcoind seems to have stuck - last line in debug.log is about "ignoring large orphan tx"
168 2012-06-05 17:26:56 <rebroad> ah, it's unstuck now
169 2012-06-05 17:27:26 <Matt_von_Mises> rebroad: If only you waited a tiny bit longer...
170 2012-06-05 17:27:33 <D34TH> there you are rebroad
171 2012-06-05 17:27:39 <rebroad> stilll... it's unusual for it to pause so long...
172 2012-06-05 17:27:44 <D34TH> ive been meaning to get ahold of you
173 2012-06-05 17:28:06 <D34TH> remember your parallell block download pull req to bitcoin/bitcoin
174 2012-06-05 17:28:47 <rebroad> D34TH: ahuh... although, it's a work in progress....  and I'm testing it on a good connection currently from genesis block, so it needs changes to make that work better
175 2012-06-05 17:28:59 <D34TH> there were some issues in it that i patched and tried to push but it went to bitcoin/bitcoin
176 2012-06-05 17:29:08 <D34TH> so rightnow my patch is living in grimd34th/bitcoin
177 2012-06-05 17:29:24 <rebroad> ah, cool... I'll take a look. thanks
178 2012-06-05 17:29:29 <D34TH> because when i try to pullreq yours it goes straight to bitcoin's
179 2012-06-05 17:30:00 <sipa> D34TH: yes, known problem at github
180 2012-06-05 17:30:20 <D34TH> rebroad: https://github.com/grimd34th/bitcoin/commit/709227ed28b0fd9ee04ba218c1e2da91d05c509c
181 2012-06-05 17:30:23 <D34TH> my only commit
182 2012-06-05 17:30:33 <sipa> rebroad, BlueMatt: maybe you should check for overlap between parallel block download and chub, as both seem to change the logic
183 2012-06-05 17:30:52 <D34TH> it was refrencing wx and had a double define
184 2012-06-05 17:32:08 <rebroad> D34TH: ah, yes, I think I fixed those a while back and re-pushed
185 2012-06-05 17:32:41 <D34TH> also is it up on 0.6.2 yet, i think it kept dieing on 0.6.0
186 2012-06-05 17:33:07 <gavinandresen> Matt_von_Mises: "we" take openssl vulnerabilities very seriously.  0.6.2 Mac release was compiled against 1.0.1c
187 2012-06-05 17:33:56 <D34TH> also sipa, i got kvm working in virtualbox
188 2012-06-05 17:34:55 <sipa> gavinandresen: not sure if this was ever investigated, but openssl defines next to normal en compressed pubkeys, also "hybrid" pubkeys
189 2012-06-05 17:35:06 <sipa> gavinandresen: i could test what happens on testnet when those are used
190 2012-06-05 17:35:40 <gavinandresen> oh, joy, hybrid... what's a hybrid?
191 2012-06-05 17:35:58 <gavinandresen> (and testing what happens is a good idea)
192 2012-06-05 17:36:16 <sipa> from what i understand, it's not compressed, but also contains the oddness-of-Y-bit in its header byte
193 2012-06-05 17:36:36 <sipa> i fail to see its use, but i suppose openssl (and thus all satoshi code) will accept it as valid
194 2012-06-05 17:37:24 <gavinandresen> ok.  if it works, it'd be nice to get a couple of hybrid-signed transactions in the testnet3 chain
195 2012-06-05 17:37:40 <sipa> ack; shouldn't be hard to do
196 2012-06-05 17:37:45 <gavinandresen> ... which reminds me, I uploaded a testnet3-in-a-box .zip to sourceforge yesterday.
197 2012-06-05 17:42:28 <D34TH> 2.14 gh/s on the testnet3 p2pool
198 2012-06-05 17:49:18 <rebroad> hmmm. I'm seeing a number of large orphan txs.. size ~3432946639,
199 2012-06-05 17:56:50 <gavinandresen> rebroad: on main net or test net?
200 2012-06-05 17:58:50 <rebroad> gavinandresen: main
201 2012-06-05 17:59:11 <rebroad> gavinandresen: although, I am at initial block download, so perhaps it's related to that
202 2012-06-05 18:00:43 <gavinandresen> You're getting "ignoring large orphan tx" messages?
203 2012-06-05 18:02:23 <gavinandresen> Somebody might be trying to kill nodes running old code by filling their memory with orphan transactions.  That's a bandwidth-intensive attack, though....
204 2012-06-05 18:02:46 <Ukto> does orphaned data have any use anymore? curious if it can get filtered out
205 2012-06-05 18:03:03 <rebroad> gavinandresen: yes
206 2012-06-05 18:03:19 <gavinandresen> sure, if you get transactions out of order you save network bandwidth if you store the earlier transaction
207 2012-06-05 18:03:29 <gavinandresen> (as an orphan)
208 2012-06-05 18:03:52 <Ukto> sh
209 2012-06-05 18:03:54 <Ukto> ah even
210 2012-06-05 18:05:39 <chmod755> ;;seen sirius-m
211 2012-06-05 18:05:39 <gribble> sirius-m was last seen in #bitcoin-dev 51 weeks, 3 days, 20 hours, 43 minutes, and 47 seconds ago: <sirius-m> sipa: it's updated already?
212 2012-06-05 18:05:53 <chmod755> -.-
213 2012-06-05 18:06:09 <chmod755> ;;seen gavinandresen
214 2012-06-05 18:06:09 <gribble> gavinandresen was last seen in #bitcoin-dev 2 minutes and 39 seconds ago: <gavinandresen> (as an orphan)
215 2012-06-05 18:06:12 <chmod755> oh
216 2012-06-05 18:06:25 <gavinandresen> I'm not an orphan.
217 2012-06-05 18:06:34 <chmod755> hello gavinandresen
218 2012-06-05 18:06:46 <gavinandresen> hello execute bit
219 2012-06-05 18:06:54 <Ukto> lol
220 2012-06-05 18:07:02 <Ukto> gavin, do you have kids?
221 2012-06-05 18:07:23 <gavinandresen> yes, two of them.  I'm about to disappear to a little league baseball game
222 2012-06-05 18:07:29 <Ukto> hehe
223 2012-06-05 18:08:19 <Ukto> you should get the reference then, as an orphan, did your son come from the future to help fix a time machine? ;)
224 2012-06-05 18:08:35 <Ukto> (i got 4) was watching meet the robinsons w/ the kids last night heh
225 2012-06-05 18:10:37 <GTRsdk> Is anyone able to successfully sync on -testnet all of the blocks (starting with none)?
226 2012-06-05 18:17:01 <phantomcircuit> so
227 2012-06-05 18:17:16 <phantomcircuit> the stated security of yubikeys (128 bits) is wildly optimistic
228 2012-06-05 18:17:22 <phantomcircuit> real security is more like 18 bits
229 2012-06-05 18:17:41 <sipa> nobody cares about those '2' digits these days
230 2012-06-05 18:17:57 <chmod755> lol
231 2012-06-05 18:17:58 <phantomcircuit> sipa, ?
232 2012-06-05 18:18:54 <sipa> 128 -> drop 2 -> 18
233 2012-06-05 18:19:02 <chmod755> ;;action encrypts sipa with 0.5 bits
234 2012-06-05 18:19:37 <phantomcircuit> oh
235 2012-06-05 18:19:38 <phantomcircuit> clever
236 2012-06-05 18:20:12 <phantomcircuit> there is a pretty trivial workaround to bring security back to about 64 bits
237 2012-06-05 18:20:30 <phantomcircuit> but im sure a real cryptographer could completely break the scheme
238 2012-06-05 18:21:35 <phantomcircuit> im surprised nobody has found this before
239 2012-06-05 18:28:33 <Diablo-D3> >security
240 2012-06-05 18:28:50 <Diablo-D3> phantomcircuit: whats the problem now?
241 2012-06-05 18:30:51 <BlueMatt> rebroad: make -jN where N is number of cores + 1, thats what I meant by "limit it"
242 2012-06-05 18:32:12 <BlueMatt> sipa: you mean #1404?
243 2012-06-05 18:32:55 <sipa> yes
244 2012-06-05 18:35:21 <BlueMatt> is there an actual reason we have VECTOR vWorkQUEUE(s)?
245 2012-06-05 18:38:25 <BlueMatt> sipa: hmmm...I dont see much overlap here, what specifically were you referring to?
246 2012-06-05 18:40:54 <BlueMatt> rebroad: I like the idea of #1404 a lot, btw, but can you remove, afict, all the commits in that pull except the one thats actually relevant to changing downloading?
247 2012-06-05 18:42:28 <sipa> BlueMatt: just an impression - i didn't look at it too closely honestly
248 2012-06-05 18:43:58 <rebroad> BlueMatt: thanks.. I'm currently tweaking it, specifically the parallel bit, but yes, I was planning to remove the other commits, once i'd finished tweaking it.
249 2012-06-05 18:45:01 <BlueMatt> sipa: I think it will conflict and need rebasing, but I dont think anything there is too crazy doing similar stuff there
250 2012-06-05 18:45:02 <rebroad> BlueMatt: and I it needs to start off using only 1 peer, and only increase that number if problems arise... so was going to code for that too
251 2012-06-05 18:45:26 <BlueMatt> rebroad: I disagree there, it should use all the nodes it can
252 2012-06-05 18:45:44 <BlueMatt> if for no other reason than to decrease the wide bw usage swings seen by bitcoin nodes
253 2012-06-05 18:46:18 <BlueMatt> rebroad: oh, btw, I have a branch that will buffer blocks for you when you call EmitBlock, so dont worry about doing that, if you were planning on it
254 2012-06-05 18:46:20 <rebroad> BlueMatt: well, for the initial download (blocks 0 to 168000) it would seem to be faster to getdata 500 blocks at a time than the current 1 it was doing.... but maybe it can send 500 getblocks requests to several nodes at once
255 2012-06-05 18:46:47 <BlueMatt> rebroad: thats what I was thinking, send out a ton of getblocks to several nodes all at once
256 2012-06-05 18:47:01 <BlueMatt> also, since when do you only send 1 getblock at a time? my debug.log doesnt seem to show that?
257 2012-06-05 18:47:50 <rebroad> BlueMatt: well, it doesn't do that with the latest push (but it doesn't do parallel either at the moment)... it was sending just 1 getblock to each peer before today, which was much slower when going from block 0
258 2012-06-05 18:47:52 <sipa> overlapping getblocks requests shouldn't hurt too much
259 2012-06-05 18:48:20 <sipa> though a reply to one is 18 kilobytes
260 2012-06-05 18:48:25 <sipa> (up to)
261 2012-06-05 18:48:29 <rebroad> sipa, overlapping as in requesting the same block from more than one peer?
262 2012-06-05 18:48:54 <rebroad> ah.. getblocks
263 2012-06-05 18:49:39 <rebroad> plus, it shouldn't assume it will get an inv of 500 blocks from the getblocks request... it depends on the software the peer is running...
264 2012-06-05 18:49:58 <rebroad> luke-jr's nodes send invs of only 40 blocks I think
265 2012-06-05 18:50:26 <luke-jr> &
266 2012-06-05 18:50:59 <BlueMatt> we dont assume anything there, afaict, we just limit to 500
267 2012-06-05 18:51:03 <sipa> rebroad: you only get invs for blocks worth the sender's node's half output buffer size
268 2012-06-05 18:51:26 <rebroad> sipa, ah ok
269 2012-06-05 18:51:50 <BlueMatt> during IBD, afaik, we use getblocks to request 500 blocks in each request
270 2012-06-05 18:52:44 <sipa> request, yes
271 2012-06-05 18:52:59 <rebroad> BlueMatt: that's decided by the peer... getblocks doesn't specify how many blocks, AFAIK
272 2012-06-05 18:53:11 <sipa> the sender decides how many invs come back, indeed
273 2012-06-05 18:53:30 <BlueMatt> rebroad: ah, yea, ofc, but where do we "assume it will get an inv of 500"?
274 2012-06-05 18:54:07 <rebroad> BlueMatt: you're assuming there's an assumption :)
275 2012-06-05 18:54:17 <BlueMatt> <rebroad> plus, it shouldn't assume it will get an inv of 500 blocks from the getblocks request... it depends on the software the peer is running...
276 2012-06-05 18:54:39 <rebroad> yes, I'm saying it should not assume
277 2012-06-05 18:54:59 <BlueMatt> oh, does your patch?
278 2012-06-05 18:55:14 <BlueMatt> anyway...
279 2012-06-05 19:19:09 <rebroad> BlueMatt: I don't know why I mentioned about assuming... I must have gotten the impression somewhere that there might be a temptation to assume
280 2012-06-05 19:55:53 <DBordello> Something is upsetting the 0.6.2-beta windows client when syncing the blockchain - http://i.imgur.com/reqyC.png
281 2012-06-05 19:55:57 <DBordello> Thoughts?
282 2012-06-05 19:56:27 <sipa> DBordello: delete addr.dat
283 2012-06-05 19:56:40 <DBordello> sipa, okay, i'll give that a shot
284 2012-06-05 19:56:44 <sipa> DBordello: oh, run with -detachdb first
285 2012-06-05 19:56:54 <sipa> wait, that won't help
286 2012-06-05 19:56:59 <sipa> nah, just delete it
287 2012-06-05 19:57:07 <DBordello> deleted
288 2012-06-05 19:57:52 <DBordello> Resyncing..
289 2012-06-05 20:11:06 <DBordello> sipa, worked great, thanks.
290 2012-06-05 20:25:05 <qualiatative> hello
291 2012-06-05 20:43:01 <hazek> this is probably stupid since I'm super unqualified to speak about it in the first place but I just had this thought that I felt compelled to share
292 2012-06-05 20:43:33 <hazek> it's about the blockchain scalability
293 2012-06-05 20:43:58 <graingert> hazek: oh really?
294 2012-06-05 20:44:03 <hazek> I was wondering what the importance of the whole blockchain is
295 2012-06-05 20:44:17 <hazek> I mean having the whole blockchain from the genesis block on
296 2012-06-05 20:44:27 <sipa> the whole blockchain is technically only necessary for bootstrapping other nodes
297 2012-06-05 20:44:40 <hazek> I but why even that
298 2012-06-05 20:44:49 <sipa> a pruned blockchain (downloaded from a trusted source, or a full node) is all that is needed for mining
299 2012-06-05 20:45:45 <hazek> no I meant as the foundation of the bitcoin protocol
300 2012-06-05 20:45:45 <Ukto> hazek: if you dont have at least a pruned blockchain, you wouldnt have a very accurate balance ;)
301 2012-06-05 20:45:58 <Ukto> think of it as a giant transactional history (cause it is)
302 2012-06-05 20:45:59 <rebroad> a question for #bitcoin perhaps?
303 2012-06-05 20:46:03 <sipa> Ukto: disagree; all you need are your own transactions
304 2012-06-05 20:46:13 <Ukto> sipa: well, that is true
305 2012-06-05 20:46:21 <Ukto> i was giving a broad reason :)
306 2012-06-05 20:46:22 <hazek> can you define pruned?
307 2012-06-05 20:46:30 <hazek> I think I know what you mean by that
308 2012-06-05 20:46:34 <hazek> but I just want to make sure
309 2012-06-05 20:46:42 <sipa> hazek: all old/spent transactions removed from permanent storage
310 2012-06-05 20:46:49 <sipa> old+spent, that is
311 2012-06-05 20:46:50 <hazek> right
312 2012-06-05 20:47:01 <hazek> so you only have a certain amount of transactions
313 2012-06-05 20:47:09 <hazek> and all unspent
314 2012-06-05 20:47:26 <sipa> all not-completely-spent ones, and all recent ones
315 2012-06-05 20:47:35 <hazek> right
316 2012-06-05 20:47:44 <hazek> why is that a problem?
317 2012-06-05 20:47:50 <sipa> what problem?
318 2012-06-05 20:48:03 <sipa> implementing that? someone has to do it
319 2012-06-05 20:48:06 <hazek> you said it's a problem when bootstraping
320 2012-06-05 20:48:15 <sipa> yes because that implies you don't have the blocks anymore
321 2012-06-05 20:48:17 <gribble> New news from bitcoinrss: rebroad opened pull request 1426 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1426>
322 2012-06-05 20:48:23 <sipa> so you can't give em to someone else
323 2012-06-05 20:48:37 <sipa> except to someone who trusts you
324 2012-06-05 20:48:41 <hazek> what if you still had blocks
325 2012-06-05 20:48:52 <sipa> then you'd have the transactions as well
326 2012-06-05 20:48:58 <sipa> as the blocks contain the transactions
327 2012-06-05 20:49:29 <hazek> what if after a certain number of blocks
328 2012-06-05 20:49:37 <hazek> you looked a 100.000 blocks back
329 2012-06-05 20:49:43 <sipa> irrelevant
330 2012-06-05 20:49:47 <hazek> copied all the unspent into the next block
331 2012-06-05 20:49:53 <hazek> and after 100 more blocks
332 2012-06-05 20:49:55 <sipa> it doesn't work like that
333 2012-06-05 20:49:57 <hazek> prune 100 first blocks
334 2012-06-05 20:50:00 <hazek> why not
335 2012-06-05 20:50:16 <sipa> first of all, that wouldn't gain you anything
336 2012-06-05 20:50:18 <hazek> I mean I know it doesn't right now
337 2012-06-05 20:50:21 <hazek> but why couldn't it
338 2012-06-05 20:50:28 <sipa> it can
339 2012-06-05 20:50:36 <sipa> there is no problem with pruning, in theory
340 2012-06-05 20:50:44 <hazek> it would, you'd get rid of all the irrelevant txs
341 2012-06-05 20:50:52 <sipa> but you cannot serve as a zero-trust bootstrap for other nodes
342 2012-06-05 20:51:05 <hazek> hmmm
343 2012-06-05 20:51:06 <sipa> as you can't prove you legitimately left a particular transaction out
344 2012-06-05 20:51:15 <hazek> so every client looks for the genesis block?
345 2012-06-05 20:51:29 <graingert> hazek: no you get that one free
346 2012-06-05 20:51:29 <sipa> no, the genesis block is hardcoded in the client
347 2012-06-05 20:51:55 <hazek> graingert: can you please keep your thoughtless comments to yourself
348 2012-06-05 20:52:05 <sipa> he is right
349 2012-06-05 20:52:19 <hazek> ohhh
350 2012-06-05 20:52:22 <hazek> it's hard coded?
351 2012-06-05 20:52:31 <sipa> yes, it's the starting point of the chain
352 2012-06-05 20:52:38 <hazek> aaaahhhh
353 2012-06-05 20:52:55 <sipa> the client asks other nodes "hey i'm at X... tell me what you have afterwards'
354 2012-06-05 20:53:09 <hazek> riiight
355 2012-06-05 20:53:09 <Matt_von_Mises> Hmmm, i2o_ECPublicKey doesn't work for me. It doesn't seem to give any data at all.
356 2012-06-05 20:53:12 <sipa> and what is transmitted, are blocks containing transactions
357 2012-06-05 20:53:20 <hazek> right
358 2012-06-05 20:53:22 <hazek> now I get it
359 2012-06-05 20:53:30 <hazek> I forgot about that little part
360 2012-06-05 20:53:55 <hazek> hmm how could one solve that differently
361 2012-06-05 20:54:03 <hazek> is it even possible?
362 2012-06-05 20:54:17 <graingert> hazek: my comments are often vague and confusing but never thoughtless or kept to myself
363 2012-06-05 20:54:17 <sipa> yes
364 2012-06-05 20:54:43 <hazek> graingert: I apologize, I mistakenly thought you were trolling me, sorry
365 2012-06-05 20:55:00 <sipa> hazek: there is a possible improvement that would encode a merkle root of all not-fully-spent transaction hashes into the coinbase of blocks
366 2012-06-05 20:55:17 <Matt_von_Mises> In the future it may be that there are specific nodes that give out all blocks and most nodes only store information specific to them and enough to validate the block chain.
367 2012-06-05 20:55:45 <sipa> Matt_von_Mises: "enough to validate the block chain" = pruned blockchain
368 2012-06-05 20:55:53 <sipa> "enough to maintain a wallet" = SPV
369 2012-06-05 20:56:11 <hazek> sipa: what would that accomplish?
370 2012-06-05 20:56:23 <graingert> sipa: what about the MTUT ?
371 2012-06-05 20:56:30 <sipa> graingert: MTUT?
372 2012-06-05 20:56:31 <graingert> sipa: does that / will that solve anything
373 2012-06-05 20:56:38 <graingert> !google MTUT bitcoin
374 2012-06-05 20:56:38 <gribble> User:DiThi/MTUT - Bitcoin: <https://en.bitcoin.it/wiki/User:DiThi/MTUT>; User talk:DiThi/MTUT - Bitcoin: <https://en.bitcoin.it/wiki/User_talk:DiThi/MTUT>; User:DiThi - Bitcoin: <https://en.bitcoin.it/wiki/User:DiThi>
375 2012-06-05 20:56:52 <graingert> Merkle tree of unspent transactions (MTUT)
376 2012-06-05 20:57:15 <sipa> graingert: exactly that - didn't know someone wrote it out
377 2012-06-05 20:57:33 <hazek> yeah but what would that solve?
378 2012-06-05 20:57:41 <sipa> it means i could send you a pruned blockchain
379 2012-06-05 20:58:13 <sipa> and you could verify (at least with the same certainty as SPV nodes currently have about transactions) that i didn't leave anything (accidentally or maliciously) out
380 2012-06-05 20:58:42 <diki> How are huge numbers handled by bignum libraries?
381 2012-06-05 20:58:57 <hazek> yeah I'm sorry I don't get it
382 2012-06-05 20:58:59 <graingert> !google bignum implementation
383 2012-06-05 20:59:00 <gribble> Arbitrary-precision arithmetic - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic>; Bignum Arithmetic: <http://dl.fefe.de/bignum.pdf>; bignum.c: <http://www.cs.sunysb.edu/~skiena/392/programs/bignum.c>
384 2012-06-05 20:59:10 <hazek> I think it's past my understanding of how the protocol works
385 2012-06-05 20:59:17 <sipa> hazek: the problem we want to solve it that we want to prune permanently
386 2012-06-05 20:59:30 <sipa> so i could remove old+spent transactions, and forget about them
387 2012-06-05 20:59:35 <hazek> right
388 2012-06-05 20:59:50 <sipa> the problem with this, is that if i do that, i cannot send the blockchain anymore to someone who doesn't trust me
389 2012-06-05 20:59:54 <hazek> but we can't do that because we need the genesis block
390 2012-06-05 20:59:59 <sipa> no
391 2012-06-05 21:00:15 <sipa> that's completely unrelated
392 2012-06-05 21:00:25 <hazek> right
393 2012-06-05 21:00:26 <sipa> pruned nodes do not deal with blocks anymore, they only care about transactions
394 2012-06-05 21:00:31 <diki> Hmm
395 2012-06-05 21:00:36 <hazek> pruning but you still have a blockchain starting with the genesis block?
396 2012-06-05 21:00:42 <sipa> hazek: NO
397 2012-06-05 21:00:45 <diki> Will read, thanks
398 2012-06-05 21:00:52 <hazek> no blocks?
399 2012-06-05 21:00:54 <sipa> hazek: you do not have blocks anymore
400 2012-06-05 21:01:06 <graingert> sipa: what?
401 2012-06-05 21:01:09 <sipa> you can't, as you've been removed pieces of them
402 2012-06-05 21:01:10 <hazek> ok go on
403 2012-06-05 21:01:20 <graingert> sipa: oh you have the block headers
404 2012-06-05 21:01:22 <graingert> ofc
405 2012-06-05 21:01:28 <sipa> graingert: yes, sure
406 2012-06-05 21:01:33 <sipa> but not full blocks anymore, i mean
407 2012-06-05 21:01:38 <hazek> so you MTUT is basically a snapshot of the blockchain?
408 2012-06-05 21:01:54 <sipa> it's a snapshot of the state reached by applying all blocks in the blockchain
409 2012-06-05 21:01:59 <sipa> it's not the blockchain itself
410 2012-06-05 21:02:04 <hazek> right
411 2012-06-05 21:02:21 <sipa> and if that snapshot is committed through by miners
412 2012-06-05 21:02:29 <graingert> hazek: it's the current location of all the bitcoin
413 2012-06-05 21:02:29 <hazek> but this would mean you'd still need nodes with the whole actual thing
414 2012-06-05 21:02:39 <sipa> hazek: nope
415 2012-06-05 21:02:46 <graingert> hazek: no you can forget about the spent tx
416 2012-06-05 21:03:03 <sipa> as you could bootstrap by just sending someone the pruned state
417 2012-06-05 21:03:09 <hazek> how would mining and validating work using MTUT?
418 2012-06-05 21:03:17 <sipa> same as now
419 2012-06-05 21:03:28 <sipa> only they'd put the MTUT root hash in the coinbase
420 2012-06-05 21:03:38 <sipa> in addition to what is placed there now
421 2012-06-05 21:03:40 <hazek> ahhh
422 2012-06-05 21:03:41 <hazek> ok
423 2012-06-05 21:03:43 <hazek> i get it
424 2012-06-05 21:03:45 <hazek> I think
425 2012-06-05 21:03:58 <hazek> MTUT changes constantly and so would the hash
426 2012-06-05 21:04:07 <sipa> indeed
427 2012-06-05 21:04:26 <hazek> so miners wouldn't mine blocks
428 2012-06-05 21:04:31 <sipa> yes they would
429 2012-06-05 21:04:32 <hazek> but rather snapshots of the MTUT
430 2012-06-05 21:04:36 <sipa> no no no
431 2012-06-05 21:04:39 <sipa> they would mine blocks
432 2012-06-05 21:04:41 <sipa> just like now
433 2012-06-05 21:04:46 <hazek> oh
434 2012-06-05 21:04:47 <sipa> but those blocks are kept
435 2012-06-05 21:05:00 <sipa> they're only for transmission and proof-of-work
436 2012-06-05 21:05:19 <hazek> how long are they kept?
437 2012-06-05 21:05:20 <sipa> (and they are kept for a while, just to be able to deal with reorganisations nicely)
438 2012-06-05 21:05:25 <hazek> right
439 2012-06-05 21:05:46 <sipa> but i guess with keeping the last 1000 blocks you're perfectly good
440 2012-06-05 21:06:19 <hazek> I'm sorry I even came here asking this.. obviously way smarter people than me have thought about this way more than me, there was no way I could have contributed something you guys didn't think off before me :P
441 2012-06-05 21:06:29 <hazek> I just felt compelled to ask
442 2012-06-05 21:06:55 <hazek> are there any plans to use this in the future?
443 2012-06-05 21:06:59 <hazek> bitcoin 2.0 perhaps?
444 2012-06-05 21:07:20 <sipa> i'm sure if we ever do a hardfork, this would be one of the things done right from the start
445 2012-06-05 21:07:38 <sipa> but it's possible to hack it in right now without a hardfork
446 2012-06-05 21:07:41 <rebroad> BlueMatt: not sure what you meant by diff-1 blovks
447 2012-06-05 21:07:42 <rebroad> blocks
448 2012-06-05 21:08:08 <BlueMatt> rebroad: blocks mined at difficulty 1, ie the genisis block
449 2012-06-05 21:08:12 <hazek> man this really puts me at ease because before this convo I didn't properly understand the issue and had some concerns about the future
450 2012-06-05 21:09:00 <hazek> sipa: ty for explaining it to me
451 2012-06-05 21:09:06 <sipa> hazek: note that this is a scenario that would decrease a security slightly
452 2012-06-05 21:09:21 <hazek> where's the new hole?
453 2012-06-05 21:09:31 <sipa> no just the security model changes
454 2012-06-05 21:09:37 <rebroad> anyway, rather than a fork, can't a parallel chain be created with the MTUT info perhaps?
455 2012-06-05 21:09:59 <rebroad> (i mean, if a fork had been needed)
456 2012-06-05 21:10:14 <sipa> hazek: because right now, a node does not need to trust anyone when downloading, it just verifies everything it receives
457 2012-06-05 21:10:46 <hazek> how does that change with MTUT
458 2012-06-05 21:10:47 <sipa> hazek: in the scenario where you download a pruned state instead of a blockchain, and verify it against the MTUT root hash
459 2012-06-05 21:11:07 <sipa> hazek: in the scenario where you download a pruned state instead of a blockchain, and verify it against the MTUT root hash, you are trusting that the longest chain is actually valid
460 2012-06-05 21:11:30 <hazek> isn't that how it's now?
461 2012-06-05 21:11:31 <sipa> as you never see its history, there is no way to verify that it is correct
462 2012-06-05 21:11:43 <luke-jr> sipa: moreover, if you don't have the blockchain, what guarantees the longest chain is really that long?
463 2012-06-05 21:11:44 <sipa> no
464 2012-06-05 21:12:11 <BlueMatt> does anyone have a link to the full "flip the chain/MTUT" suggestion that filled out details aside from "stick merkle root in coinbase", or was there one?
465 2012-06-05 21:12:46 <sipa> luke-jr: i guess you'd still have the block headers
466 2012-06-05 21:12:51 <hazek> sipa: I think I know what you're saying
467 2012-06-05 21:13:10 <Matt_von_Mises> I'm just thinking about the SPV& With SPV a hacker sending you fake bitcoins would need to create fake blocks to do this. Even if you do not have the previous transactions to validate that the bitcoins cannot be spent, you can still look at the fake blocks. A hacker can't make these blocks at a high difficulty so it's true SPV is safe for a certain amount of confirmations, right?
468 2012-06-05 21:13:11 <sipa> hazek: right now, the longest valid chain is trusted
469 2012-06-05 21:13:31 <sipa> hazek: under pruned bootstrapping, the longest chain whatsoever is trusted
470 2012-06-05 21:13:47 <hazek> yeah
471 2012-06-05 21:14:16 <hazek> valid in the sense that each block hash in the hash of the previous
472 2012-06-05 21:14:19 <hazek> is that what you mean?
473 2012-06-05 21:14:38 <sipa> hazek: "valid" is about a 100-long checklist of things that need to be exactly right
474 2012-06-05 21:14:50 <hazek> well
475 2012-06-05 21:14:51 <hazek> ok yeah
476 2012-06-05 21:14:52 <hazek> :D
477 2012-06-05 21:14:53 <Matt_von_Mises> I haven't got to the block proof of work bit yet but from what I know I don't see why SPV is a problem after waiting for blocks.
478 2012-06-05 21:15:36 <sipa> hazek: in particular, it means signatures are valid, transaction outputs aren't spent twice, transactions outputs aren't more than the inputs, coinbases do not introduce too much money, ...
479 2012-06-05 21:16:17 <hazek> ok but wouldn't any irregularity be rejected by miners?
480 2012-06-05 21:16:31 <sipa> of course
481 2012-06-05 21:16:35 <sipa> it *should*
482 2012-06-05 21:16:43 <hazek> right, I guess that's why you said slightly less secure
483 2012-06-05 21:16:44 <sipa> but there is no mathematically perfect guarantee that they will
484 2012-06-05 21:16:46 <hazek> not insecure
485 2012-06-05 21:16:47 <graingert> but you need to verify the blocks
486 2012-06-05 21:16:58 <graingert> to determine they are behaiving
487 2012-06-05 21:17:04 <sipa> graingert: new incoming blocks would be verified of course
488 2012-06-05 21:17:26 <sipa> but you don't know whether irregularities occurred in the part of history you didn't live through yourself
489 2012-06-05 21:17:56 <Eliel> sipa: I'm not even sure it'd be sensible to care about those parts of history.
490 2012-06-05 21:18:09 <Eliel> it's the current consensus that matters.
491 2012-06-05 21:18:16 <sipa> it sounds like a reasonable compromise
492 2012-06-05 21:18:41 <hazek> eliele it's more susceptible to an attack
493 2012-06-05 21:18:49 <hazek> if say half the network goes dark for what ever reason
494 2012-06-05 21:19:04 <hazek> when it comes back online
495 2012-06-05 21:19:26 <hazek> it must trust the other half
496 2012-06-05 21:20:10 <hazek> by going dark I mean being destroyed
497 2012-06-05 21:20:15 <hazek> losing everything
498 2012-06-05 21:20:41 <Matt_von_Mises> Does anyone know how much space would be saved if the block chain was pruned?
499 2012-06-05 21:21:12 <hazek> that's a good question actually
500 2012-06-05 21:21:18 <BlueMatt> Matt_von_Mises: chain itself, havent tested, block index only-> >1/2
501 2012-06-05 21:21:43 <hazek> ty for the explanations sipa, gtg, later
502 2012-06-05 21:22:01 <BlueMatt> and thats only up to block 168,000
503 2012-06-05 21:22:24 <BlueMatt> and with satoshidice...
504 2012-06-05 21:28:36 <Matt_von_Mises> You have to use OPENSSL_malloc for i2o_ECPublicKey?
505 2012-06-05 21:29:02 <Matt_von_Mises> Saw it on here: https://groups.google.com/forum/#!msg/mailing.openssl.dev/a-s3wvtcRjo/AGWAD9ySQ3wJ
506 2012-06-05 21:29:08 <Matt_von_Mises> I thought malloc was fine...
507 2012-06-05 21:30:20 <graingert> it probably does the fancy don't page to disk stuff
508 2012-06-05 21:32:03 <Matt_von_Mises> WEll using it didn't fix my problem
509 2012-06-05 21:32:13 <Matt_von_Mises> I must be doing something very stupid in front of my face again.
510 2012-06-05 21:32:50 <Matt_von_Mises> I think this is a stackoverflow.com problem& :-(
511 2012-06-05 21:36:10 <graingert> just use the Python open ssl bindings :p
512 2012-06-05 21:36:12 <graingert> ;)
513 2012-06-05 21:48:28 <Matt_von_Mises> There we go: http://stackoverflow.com/questions/10906524/openssl-i2o-ecpublickey-not-providing-any-bytes
514 2012-06-05 21:48:34 <Matt_von_Mises> I must be doing something stupid
515 2012-06-05 21:51:36 <luke-jr> B 4 failures detected in test suite "Bitcoin Test Suite"
516 2012-06-05 21:53:48 <luke-jr> (on PPC)