1 2012-12-11 00:18:12 <helo> bam! http://arstechnica.com/information-technology/2012/12/ibms-nanophotonic-tech-integrates-optic-data-right-into-chips/
  2 2012-12-11 00:26:58 <helo> so maybe hardware will just blast through all bottlenecks
  3 2012-12-11 00:33:20 <sipa> gmaxwell: where was your testnet node?
  4 2012-12-11 00:35:04 <jgarzik> sipa: if you're just looking for any old testnet node... us4.exmulti.net
  5 2012-12-11 00:35:40 <sipa> ok
  6 2012-12-11 02:19:21 <nebulus> does anyone know how long the wallet passcode can be?
  7 2012-12-11 02:19:31 <nebulus> at max
  8 2012-12-11 02:20:36 <phantomcircuit> longer than you can likely remember
  9 2012-12-11 02:20:46 <phantomcircuit> certainly longer than is really useful
 10 2012-12-11 02:21:33 <nebulus> well there was an article on arstechnica saying that now with 25 GPU any windows password can be cracked
 11 2012-12-11 02:21:53 <nebulus> prolly same applies to the wallet pass
 12 2012-12-11 02:21:53 <phantomcircuit> the article is totally retarded
 13 2012-12-11 02:21:58 <phantomcircuit> they're talking about NTLM
 14 2012-12-11 02:22:13 <phantomcircuit> which is probably the worst hashing algorithm ever
 15 2012-12-11 02:22:28 <phantomcircuit> with NTLM the maximum length of a password is 7 characters
 16 2012-12-11 02:22:35 <phantomcircuit> oh and they're always uppercase
 17 2012-12-11 02:22:42 <nebulus> wont lie i did not read it
 18 2012-12-11 02:23:00 <nebulus> hmm so they werent talking about regular windows password
 19 2012-12-11 02:23:01 <phantomcircuit> bruteforcing ntlm passwords has *always* been easy
 20 2012-12-11 02:23:05 <nebulus> that is retarded
 21 2012-12-11 02:23:09 <phantomcircuit> no they were
 22 2012-12-11 02:23:18 <phantomcircuit> windows uses a horrible password hashing algorithm
 23 2012-12-11 02:23:27 <phantomcircuit> you can optionally turn on a better one
 24 2012-12-11 02:24:05 <nebulus> wait you are saying that windows pass is 7 char max
 25 2012-12-11 02:24:19 <nebulus> how is that if i have about 12 chars for pass on my work pc
 26 2012-12-11 02:24:34 <phantomcircuit> nebulus, NTLM takes your password and splits it into two 7 character pieces
 27 2012-12-11 02:24:50 <phantomcircuit> then it calculates 2 3DES based hashes
 28 2012-12-11 02:25:14 <phantomcircuit> bruteforcing 2 7 character 3DES hashes is *much* easier than 1 14 character hash
 29 2012-12-11 02:25:41 <phantomcircuit> http://en.wikipedia.org/wiki/NTLM
 30 2012-12-11 02:26:15 <nebulus> meh dont want to go down a rabbit hole
 31 2012-12-11 02:26:34 <nebulus> just was wondering about the wallet pass phrase
 32 2012-12-11 02:26:40 <nebulus> i guess its okay
 33 2012-12-11 02:26:48 <nebulus> what i got now is ok
 34 2012-12-11 04:59:34 <nanotube> TD[gone]: hey - so it seems the first difficulty change after the block reward halving was only a minus 2% or so. i win the bet. :)
 35 2012-12-11 04:59:37 <nanotube> ;;prevdiffchange
 36 2012-12-11 04:59:39 <gribble> -1.99852
 37 2012-12-11 05:00:12 <gmaxwell> nanotube: what was the bet?
 38 2012-12-11 05:01:31 <nanotube> 20usd worth of btc, if the first difficulty change after block halving is less than 50% in magnitude.
 39 2012-12-11 05:02:38 <nanotube> i was willing to take a smaller cutoff, but he went for 50% and i said ok :)
 40 2012-12-11 05:06:57 <sta> what a a gambler...
 41 2012-12-11 05:07:07 <gribble> 1.49231457991
 42 2012-12-11 05:07:07 <nanotube> ;;calc 20/[ticker --last]
 43 2012-12-11 05:07:09 <nanotube> heh
 44 2012-12-11 05:07:21 <nanotube> sta: heh just having a little fun. ;)
 45 2012-12-11 06:00:52 <grondilu> hi, are all samples in src/test/data/base58_encode_decode.json supposed to be correct?  Somehow I can't manage to reproduce the same amount of leading '1's.
 46 2012-12-11 06:01:55 <grondilu> isn't the formula for the length of the base58 string output supposed to be 'number_of_bytes * 138/100 + 1'?
 47 2012-12-11 06:02:27 <jgarzik> grondilu: bitcoind verifies all those samples, yes.  additionally, my C implementation independently verifies all those samples.
 48 2012-12-11 06:04:55 <grondilu> Ok, there must be something I don't get, then.
 49 2012-12-11 06:06:01 <grondilu> take this example: ["00eb15231dfceb60925886b67d065299925915aeb172c06647", "1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L"]
 50 2012-12-11 06:06:26 <grondilu> the hex string represents 25 bytes
 51 2012-12-11 06:07:06 <grondilu> 25*138 + 1 = 35.5
 52 2012-12-11 06:07:37 <grondilu> So I was expecting a 35-characters-long string.
 53 2012-12-11 06:07:54 <grondilu> yet  "1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L" is 34 characters.
 54 2012-12-11 06:15:59 <grondilu> ah ok I think I get it.  'num_of_bytes*138/100 + 1' is just a maximum size used to initialize the placeover.
 55 2012-12-11 06:22:33 <nanotube> hi grondilu ltns :)
 56 2012-12-11 06:25:07 <grondilu> hi
 57 2012-12-11 07:12:41 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/zU4TNg
 58 2012-12-11 07:17:38 <DMCommit> [DiabloMiner] Diablo-D3 force-pushed master from 1a2917a to 886b7b4: http://git.io/bG-UHg
 59 2012-12-11 09:38:55 <Ferroh> What is the theoretical maximum number of transactions you can put in a block?
 60 2012-12-11 09:42:08 <sipa> something like 4000
 61 2012-12-11 09:48:51 <sipa> Guest53981: what's wrong with your connection/nick registration, jgarzik?
 62 2012-12-11 13:55:46 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/Dq73Ag
 63 2012-12-11 13:58:06 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/Kc0WRA
 64 2012-12-11 16:03:43 <Pucilowski> What format does dumpprivkey return?
 65 2012-12-11 16:05:54 <gmaxwell> dumpprivkey format.
 66 2012-12-11 16:07:15 <abracadabra> heh
 67 2012-12-11 16:09:36 <sipa> https://en.bitcoin.it/wiki/WIF
 68 2012-12-11 17:11:55 <Pucilowski> Thanks sipa
 69 2012-12-11 17:12:05 <Pucilowski> Do some WIF keys not have a hex equivelent?
 70 2012-12-11 17:13:13 <Pucilowski> I took the WIF key and put it into blockchain.info and exported a hex key that generates a completely different public key
 71 2012-12-11 17:18:15 <sipa> what was the first character of the WIF?
 72 2012-12-11 17:18:28 <Pucilowski> K
 73 2012-12-11 17:18:30 <sipa> (don't reveal any other character, ever)
 74 2012-12-11 17:18:44 <sipa> right, so it's a private key for a compressed pubkey
 75 2012-12-11 17:19:04 <sipa> so a pubkey that starts with 02 or 03 in hex
 76 2012-12-11 17:19:15 <sipa> not all software supports these yet
 77 2012-12-11 17:19:29 <Pucilowski> It generated the bitcoin address just fine so it must support it
 78 2012-12-11 17:19:54 <Pucilowski> I also used Casascius address utility to derrive the address and it checks out
 79 2012-12-11 17:20:07 <Pucilowski> I then tried to generate the address from the hex priv key and got a different address
 80 2012-12-11 17:20:36 <sipa> the hex key doesn't know whrther it's for a compressed or uncompressed pubkey
 81 2012-12-11 17:21:01 <sipa> so you'd pribably get the uncompressed equivalent one, which has a different address
 82 2012-12-11 17:21:18 <Pucilowski> I see
 83 2012-12-11 17:21:43 <drizztbsd> maybe you can convert it using https://www.bitaddress.org
 84 2012-12-11 17:21:46 <Pucilowski> Can you point to any utility that could convert my compressed with key to the traditional uncompressed hex?
 85 2012-12-11 17:22:06 <Pucilowski> Thanks drizztbsd
 86 2012-12-11 17:22:10 <Pucilowski> how safe is this to use though
 87 2012-12-11 17:22:16 <drizztbsd> I checked, it's all client-side javascript
 88 2012-12-11 17:22:36 <sipa> Pucilowski: the point is that it is for all intents and purposes two different keys, but their hex representation is the same
 89 2012-12-11 17:23:06 <sipa> there is no conversion, it's just informatiin that is not present in the hex form
 90 2012-12-11 17:24:37 <Pucilowski> How would I import it into Armory then?
 91 2012-12-11 17:26:23 <Pucilowski> oh I see now
 92 2012-12-11 17:26:36 <Pucilowski> the public address wasn't checking out because i was being shown the compressed address
 93 2012-12-11 17:28:49 <sipa> armory doesn't supposed compressed pubkeys. period
 94 2012-12-11 17:29:02 <sipa> *support
 95 2012-12-11 17:32:50 <Pucilowski> So compressed keys simply do not have an uncompressed equivelent and the support must come from the software?
 96 2012-12-11 17:33:45 <sipa> yes
 97 2012-12-11 17:34:05 <sipa> they're a new type of addresses essentially, except you can't see from the address which type it belongs to
 98 2012-12-11 17:34:20 <sipa> the reason is that old software can send to compressedpubkey addresses without problems
 99 2012-12-11 17:34:39 <sipa> but to spend from such keys, you need support
100 2012-12-11 18:07:02 <ciscoftw> orphaned vs stale... i understand how a block can become orphned by the netowkr, but what would cause a block to go 'stale'?
101 2012-12-11 18:08:40 <sipa> ciscoftw: in many cases, it's two names for the same thing
102 2012-12-11 18:09:08 <ciscoftw> ummmm, via bitminter, its uses both terms interchangable
103 2012-12-11 18:09:14 <sipa> ciscoftw: but what is called "orphan block" in the software source code (and i think that's the only meaningful definition) is a block which has no parent
104 2012-12-11 18:09:43 <sipa> vs. a stale block (which was pools typically call 'orphan block') is a block which is connected to the block tree, but not (anymore) part of the best chain
105 2012-12-11 18:09:48 <ciscoftw> right, that makes perfect sense, but 'stale'???
106 2012-12-11 18:10:13 <sipa> you create a stale block if it depended on a block which is no longer the current best
107 2012-12-11 18:10:24 <sipa> gmaxwell proposed calling it an extinct block
108 2012-12-11 18:10:31 <sipa> which probably makes more sense
109 2012-12-11 18:10:36 <ciscoftw> i got you, thanx for info sipa
110 2012-12-11 18:11:03 <sipa> the origin of the confusion is that stale/extinct blocks give rise to orphaned coinbase transactions
111 2012-12-11 18:11:16 <sipa> so the software would show your payouts from those as orphaned
112 2012-12-11 18:38:34 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/WX4uKA
113 2012-12-11 19:25:45 <midnightmagic> BlueMatt: You are using Jenkins right?
114 2012-12-11 19:27:39 <midnightmagic> BlueMatt: And if so, is there access to the dashboard somewhere, public?
115 2012-12-11 19:29:21 <midnightmagic> BlueMatt: Nevermind, found it.
116 2012-12-11 19:35:13 <midnightmagic> BlueMatt: Is this script /mnt/test-scripts/build-script.sh as referenced in http://jenkins.bluematt.me/job/Bitcoin/176/consoleFull available somewhere?
117 2012-12-11 19:37:48 <sipa> i'm sure it's on his github somewhere
118 2012-12-11 19:44:34 <midnightmagic> indeed.. https://github.com/TheBlueMatt/test-scripts/blob/master/build-script.sh
119 2012-12-11 20:13:28 <phantomcircuit> lol
120 2012-12-11 20:13:33 <phantomcircuit> loading cold storage wallet on a netbook
121 2012-12-11 20:13:44 <phantomcircuit> this takes roughly an 30 minutes
122 2012-12-11 20:36:15 <BlueMatt> midnightmagic: yes, that was all correct
123 2012-12-11 20:36:37 <BlueMatt> midnightmagic: please add more features :)
124 2012-12-11 20:37:01 <sipa> BlueMatt: I have a branch with a new LevelDB version (1.7) and new Windows port (which doesn't require Boost, and uses memory mapping)
125 2012-12-11 20:37:24 <sipa> BlueMatt: but it doesn't work in mingw32, and seems to require mingw-w64 (which also has a 32-bit version, confusingly enough)
126 2012-12-11 20:37:40 <sipa> so that would mean switching to a more recent ubuntu environment to build on
127 2012-12-11 20:37:55 <BlueMatt> sipa: if its just for the windows build, sounds good to me
128 2012-12-11 20:38:11 <sipa> yes, i don't think there's a problem for the ubuntu builds
129 2012-12-11 20:38:31 <BlueMatt> if you want me to upgrade jenkins...I can do so
130 2012-12-11 20:38:42 <sipa> i'll first try a gitian build on a more recent ubuntu image
131 2012-12-11 20:39:20 <BlueMatt> ok...I really should switch jenkins over to lxc gitian...
132 2012-12-11 20:39:54 <sipa> is there any reason why the windows build image needs to be 32-bit?
133 2012-12-11 20:40:06 <sipa> i guess the fact that it doesn't need 64-bit support is good enough a reason
134 2012-12-11 20:40:59 <BlueMatt> yea...pretty much
135 2012-12-11 20:41:55 <sipa> it's probably doable to remove the c++0x dependency of the code (just NULL instead of nullptr) but the windows header files included with mingw32 seem to miss some functions that are used
136 2012-12-11 20:42:09 <sipa> it's probably also possible to just manually define those
137 2012-12-11 20:42:24 <sipa> but it's a nice opportunity to switch to a more recent compiler anyway
138 2012-12-11 20:44:02 <BlueMatt> yea, seems like something that should be done in any case
139 2012-12-11 21:03:15 <sipa> BlueMatt: i'll try a precise image
140 2012-12-11 21:03:37 <sipa> that has g++-mingw-w64 v4.6.3
141 2012-12-11 21:05:15 <lianj> hm, is "00f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e" a valid pubkey?
142 2012-12-11 21:10:57 <BlueMatt> sipa: ok, nice
143 2012-12-11 21:32:31 <sipa> lianj: no
144 2012-12-11 21:33:14 <lianj> sipa: how did it get in the main chain then, http://blockexplorer.com/rawtx/274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857
145 2012-12-11 21:34:48 <Luke-Jr> lianj: it's just data at that layer
146 2012-12-11 21:35:08 <sipa> where do you see that?
147 2012-12-11 21:35:16 <Luke-Jr> scriptPubKey
148 2012-12-11 21:35:21 <gmaxwell> lianj: its just in the txout.
149 2012-12-11 21:35:30 <lianj> so bitcoind when running catches the invalid encoding error when trying to put that data into a ec point=
150 2012-12-11 21:35:43 <lianj> *bitcoind's script runner
151 2012-12-11 21:35:57 <sipa> really? :o
152 2012-12-11 21:36:13 <lianj> gmaxwell: but it was redeemed
153 2012-12-11 21:36:20 <Luke-Jr> lianj: it's a multisig 1-of-2
154 2012-12-11 21:36:24 <lianj> sipa: no, that was a question
155 2012-12-11 21:36:31 <Luke-Jr> lianj: the redeemer only needs 1 of the 2 keys
156 2012-12-11 21:36:35 <Luke-Jr> the other one is valid
157 2012-12-11 21:37:07 <lianj> Luke-Jr: yes, the frist one is valid already, i know. question is just why didnt the script runner fail or error/warn about the invalid second pubkey
158 2012-12-11 21:37:24 <Luke-Jr> because it doesn't check it
159 2012-12-11 21:37:51 <lianj> oh, it breaks the loop once it found enough valid sigs for the multisig?
160 2012-12-11 21:38:01 <lianj> well, that makes sense then
161 2012-12-11 21:38:25 <gmaxwell> another test case testnet needs..
162 2012-12-11 21:38:38 <sipa> yup
163 2012-12-11 21:38:43 <lianj> another way to push ascii crap in the chain
164 2012-12-11 21:44:27 <Luke-Jr> sipa: does your "non-canonical data is non-standard" address that?
165 2012-12-11 21:44:43 <lianj> thanks guys
166 2012-12-11 21:45:39 <sipa> Luke-Jr: no
167 2012-12-11 21:46:10 <sipa> it doesn't know what piece of data push is a signature or a pubkey until it is effectively used as such
168 2012-12-11 21:46:25 <sipa> it just enforces stricter rules when it does
169 2012-12-11 21:46:55 <Luke-Jr> sipa: in this case, it could
170 2012-12-11 21:47:28 <sipa> indeed
171 2012-12-11 21:47:31 <sipa> can be discussed
172 2012-12-11 21:52:30 <lianj> gmaxwell: i wonder why http://blockchain.info/tx/274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857 says "(Escrow 1 of 1NdB761LmT... 19j7nUtted... ) - (Spent)" though
173 2012-12-11 21:53:23 <lianj> oh > Bitcoin.pubkey_to_address("00f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e")
174 2012-12-11 21:53:26 <lianj> => "19j7nUttedmQymji5sLeh4V5zqTi2dDFrL"
175 2012-12-11 21:53:41 <lianj> very 'naive'
176 2012-12-11 21:58:37 <sipa> BlueMatt: seems precise i386 even has the w64 cross compiler :)
177 2012-12-11 21:58:45 <sipa> so we could build 64-bit windows binaries
178 2012-12-11 22:08:33 <lianj> what is the right address for pubkey 0351efb6e91a31221652105d032a2508275f374cea63939ad72f1b1e02f477da78?  1NdB761LmTmrJixxp93nz7pEiCx5cKPW44, 19FBCg9295EBQ4P6bSLTGyz2BdbbPcqQD or even 1PtACTbovWULQDDGxDCi1M7CURJ9PtBWkw
179 2012-12-11 22:19:08 <sipa> HUH?
180 2012-12-11 22:19:10 <sipa> + mkdir /home/ubuntu/qt
181 2012-12-11 22:19:24 <sipa> has gitian been writing to my base image the previous time?
182 2012-12-11 22:22:26 <lianj> 0351efb6e91a31221652105d032a2508275f374cea63939ad72f1b1e02f477da78 is a compressed key, right? is the bitcoin address == pubkey_to_address(compressed_key) or pubkey_to_address(uncompressed_compressed_key) then?
183 2012-12-11 22:22:57 <sipa> hash(compressed_key)
184 2012-12-11 22:24:36 <lianj> so 0351efb6e91a31221652105d032a2508275f374cea63939ad72f1b1e02f477da78 is 1NdB761LmTmrJixxp93nz7pEiCx5cKPW44 and not 19FBCg9295EBQ4P6bSLTGyz2BdbbPcqQD then?
185 2012-12-11 22:30:15 <lianj> sipa: confuses me. wouldnt hash(uncompressed_compressed_key) make more sense?
186 2012-12-11 22:35:30 <sipa> no - how would an old client validate that?
187 2012-12-11 22:36:08 <sipa> the script says "provide a pubkey and a signature such that a) the signature is valid for that pubkey and b) the hash of the pubkey is ADDRESS"
188 2012-12-11 22:36:53 <sipa> if the address where the hash of the uncompressed pubkey, you'd need to provide the uncompressed pubkey in the spending input as well
189 2012-12-11 22:37:09 <sipa> in which case you've gained nothing
190 2012-12-11 22:37:29 <sipa> *were
191 2012-12-11 22:37:34 <lianj> you dont need to provide it but bitcoind had to generate it
192 2012-12-11 22:38:49 <sipa> the point of compressed pubkeys is exactly that they take less space in the blockchain
193 2012-12-11 22:39:02 <sipa> if you'd just change how they are stored in the wallet - who cares about 32 bytes there?
194 2012-12-11 22:39:40 <sipa> the whole thing is just a very nice hack, really
195 2012-12-11 22:39:53 <sipa> it was possible because old nodes accepted compressed public keys
196 2012-12-11 22:39:59 <sipa> even though they didn't know about them
197 2012-12-11 22:41:28 <lianj> ok, just saying in my code it would be easier to generate an address from the uncompressed form of the ec point rather then checking if its compressed or not an then put the right pubkey version in the hash_to_address function
198 2012-12-11 22:42:09 <lianj> it has nothing to do with how it is in the script as data itself
199 2012-12-11 22:42:55 <sipa> the rule is just that the address is always the hash of the public key as it will be passed by the spending input script, as the output requires that hash(pubkey)=ADDRESS
200 2012-12-11 22:43:17 <sipa> if you're going to pass an uncompressed pubkey there, then the address is the hash of the uncompressed pubkey
201 2012-12-11 22:43:26 <sipa> if you're going to pass a compressed pubkey there, then the address is the hash of the compressed pubkey
202 2012-12-11 22:56:15 <lianj> right. changed my code now so when i create a openssl ec point from the data/pubkey, i know if it was compressed or not, so when outputting the pubkey from the ec point objects it does the right thing (output compressed or uncompressed form, depending on how it was given)
203 2012-12-11 23:14:27 <sipa> BlueMatt: how to change which compiler Qt uses?
204 2012-12-11 23:14:49 <D34TH> sipa: in the gui or via command line
205 2012-12-11 23:15:00 <D34TH> **creator
206 2012-12-11 23:15:02 <sipa> in gitian
207 2012-12-11 23:15:10 <D34TH> oh never mind
208 2012-12-11 23:15:11 <D34TH> D:
209 2012-12-11 23:15:40 <sipa> oh crap, i'll need to rebuild Qt
210 2012-12-11 23:53:10 <gmaxwell> oh, someone finally go through to grau.
211 2012-12-11 23:56:09 <sipa> ?
212 2012-12-11 23:57:38 <gmaxwell> I'm respondng to grau now seemingly seeing forking risk as something serious. It didn't seem to me that he did before.