1 2012-03-27 00:03:40 <luke-jr> doh, gavinandresen forgot to pull #987 :p
  2 2012-03-27 00:06:10 <splatster> What was in 987?
  3 2012-03-27 00:06:35 <luke-jr> a code cleanup fix
  4 2012-03-27 00:06:47 <luke-jr> I guess not as important with Bitcoin URI handlign being disabled
  5 2012-03-27 00:07:14 <splatster> Especially if it has comments.
  6 2012-03-27 00:09:11 <luke-jr> heh
  7 2012-03-27 00:09:14 <luke-jr> it's mostly s/URL/URI
  8 2012-03-27 03:24:19 <devrandom> sipa: luke-jr: I would love to build, but I'm having issues with generating base vm images
  9 2012-03-27 03:26:28 <devrandom> I only hae a 32 bit image, so I could build for win32
 10 2012-03-27 03:31:51 <devrandom> building...
 11 2012-03-27 04:01:18 <devrandom> win32 pushed
 12 2012-03-27 04:06:16 <wumpus> I get different hashes...
 13 2012-03-27 04:06:17 <wumpus> -    2ae5ee63bbcd738db11eb90f5acd3ce5c8f6818251c220eb37f822bafdba0f5a  bitcoin-0.6.0-win32-setup.exe
 14 2012-03-27 04:06:18 <wumpus> +    411eba7b1ebf5b03af1d1c37e698db3ff76a8f6a11de9158575ae1e684e9a3be  bitcoin-0.6.0-win32-setup.exe
 15 2012-03-27 04:06:57 <wumpus> qt-win32 and boost-win32 also differ, apart from that all the files are the same...
 16 2012-03-27 04:08:55 <wumpus> guess I need to rebuild those as well...
 17 2012-03-27 04:25:09 <devrandom> wumpus: qt-win32 will not match, but the end result should match.  qt-win32 did change since rc4 so it needs rebuilding AFAIK
 18 2012-03-27 05:11:54 <wumpus> devrandom: thanks, it matches now
 19 2012-03-27 06:18:38 <gribble> New news from bitcoinrss: Diapolo opened pull request 996 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/996>
 20 2012-03-27 10:23:21 <diki> gavinandresen:I like the explanation about Joe and his wallet :D
 21 2012-03-27 10:59:07 <imsaguy2> * luke-jr ponders who else can do the 3rd build << What?
 22 2012-03-27 12:33:10 <mcorlett> How can I query for firstbits addresses myself?
 23 2012-03-27 12:39:07 <luke-jr> mcorlett: don't.
 24 2012-03-27 12:40:29 <mcorlett> luke-jr: Explain yourself.
 25 2012-03-27 12:40:45 <luke-jr> mcorlett: nobody should ever use or encourage firstbits
 26 2012-03-27 12:48:53 <Blitzboom> luke-jr: explain yourself, fascist
 27 2012-03-27 12:49:12 <luke-jr> Blitzboom: no u
 28 2012-03-27 12:49:24 <Blitzboom> no u
 29 2012-03-27 12:49:34 <luke-jr> I'm pretty sure 100% of developers agree firstbits is a bad thing
 30 2012-03-27 12:49:44 <Blitzboom> but why
 31 2012-03-27 12:49:44 <gavinandresen> firstbits is a bad thing
 32 2012-03-27 12:50:04 <luke-jr> Blitzboom: because it only encourages blockchain spam
 33 2012-03-27 12:50:05 <copumpkin> Blitzboom: because it lets the admin of the site have control over which addresses are seen
 34 2012-03-27 12:50:24 <sipa> firstbits encourages the use of static addresses, and encourages spamming the block chain
 35 2012-03-27 12:50:34 <mcorlett> copumpkin: This is why I'd like to implement it myself.
 36 2012-03-27 12:50:37 <Blitzboom> ok
 37 2012-03-27 12:52:02 <sipa> luke-jr: 7977e7508c023b8f062d32bca56ffa656ea72eb16e193f075e7da206f1f318a2  bitcoin-0.5.4-win32-setup.exe
 38 2012-03-27 12:57:14 <luke-jr> 3e9382041239e412838379547c15b456f55a5ff96dba32fe92979a706ceb63c7  bitcoin-0.5.4rc2-win32-setup.exe
 39 2012-03-27 12:57:17 <luke-jr> sipa: O.o
 40 2012-03-27 12:57:32 <sipa> 86b2d35c328092f33f2f2c907026dfecd7aa7259f56538f722cac6ef9a061010  bitcoin-qt.exe
 41 2012-03-27 12:57:35 <sipa> facefcb6eda163a4e31c231b5a0185ce653a7998d4cd0566b4208ccdd33de931  daemon/bitcoind.exe
 42 2012-03-27 12:58:06 <luke-jr> fe72a6276b01df3f2380b1d7f604fa92a66741bceecd70fec2044acb028d6f94  bitcoin-0.5.4rc2-win32/bitcoin-qt.exe
 43 2012-03-27 12:58:13 <luke-jr> facefcb6eda163a4e31c231b5a0185ce653a7998d4cd0566b4208ccdd33de931  bitcoin-0.5.4rc2-win32/daemon/bitcoind.exe
 44 2012-03-27 12:58:17 <luke-jr> stupid Qt
 45 2012-03-27 12:58:22 <luke-jr> I'll rebuild mine&
 46 2012-03-27 12:58:35 <sipa> did you use the qt build from gavin's site?
 47 2012-03-27 12:58:39 <luke-jr> in the meantime, we still need a 3rd builder
 48 2012-03-27 12:58:41 <luke-jr> sipa: no?
 49 2012-03-27 12:58:52 <gavinandresen> skypaint.com/bitcoin/ has a qt.zip
 50 2012-03-27 12:58:59 <sipa> qt builds are not deterministic, afaik
 51 2012-03-27 12:59:43 <luke-jr> gavinandresen: you forgot to pull #987 for rc5 btw :p
 52 2012-03-27 13:03:48 <sipa> i'm thinking about implementing full ipv6 support, it shouldn't be hard anymore; what do you all think: a) enable listening on ipv6 by default, but only relay non-ipv4 addresses when a reachable ipv6 interface is detected b) always listen on ipv6 and always relay non-ipv4 addresses c) have a -ipv6 switch to enable relaying/listening
 53 2012-03-27 13:18:34 <gavinandresen> sipa: RE: ipv6 : no preference from me, ipv6 support isn't on the list of things I care much about (sorry!)
 54 2012-03-27 13:19:55 <gavinandresen> What IS on the list, and that I'd like to get more brains thinking about, is the "There is a trojan on my computer rewriting bitcoin payment addresses" problem.
 55 2012-03-27 13:21:13 <luke-jr> gavinandresen: I'm not sure there's really anything we can do about that :/
 56 2012-03-27 13:21:33 <luke-jr> short of including an antivirus in the clinet
 57 2012-03-27 13:21:48 <gavinandresen> I think there is a lot we can do about that, and I think it ties into multi-device authentication
 58 2012-03-27 13:22:30 <luke-jr> IMO, users aren't going to manually go to the website on multiple devices, even if they could get the same address displayed on each
 59 2012-03-27 13:23:30 <gavinandresen> Before I describe what I'm thinking, anybody know if I'm missing existing proposals for solving the problem?
 60 2012-03-27 13:24:01 <luke-jr> if there was a known "master address", the merchant could sign the per-use address with it'
 61 2012-03-27 13:24:19 <luke-jr> not sure how viable that is either, though
 62 2012-03-27 13:46:43 <mcorlett> What's rewriting addresses? Flash applets?
 63 2012-03-27 13:48:16 <iddo> deterministic wallets help with this issue? if payment addr is derived using master_pubkey+hash(num|seed) then the sender can verify it independently, and double-check using several devices to see there are no trojans?
 64 2012-03-27 13:51:11 <gavinandresen> mcorlett: rewriting addresses is a trojan got onto your machine and replaced your bitcoin.exe with an attacker's bitcoin.exe
 65 2012-03-27 13:51:28 <gavinandresen> ... so they have complete control over what information you see
 66 2012-03-27 13:52:19 <luke-jr> ah, I thought you meant replacing what you see in your browser, as the merchant's payment address
 67 2012-03-27 13:52:22 <gavinandresen> iddo: I agree with luke that most users won't bother... but maybe if the transaction is large enough they should be prompted to bother (on a second, un-compromised device)
 68 2012-03-27 13:52:27 <helo> every transaction would have to be multisig, so that compromise of one device isn't enough?
 69 2012-03-27 13:52:36 <iddo> ah i thought just replacing receiving addresses
 70 2012-03-27 13:53:26 <luke-jr> sipa: are your builds fetchable btw?
 71 2012-03-27 13:53:39 <gavinandresen> luke-jr: I assume the attacker can replace both your bitcoin.exe and your firefox/chrome/ie/safari.exe
 72 2012-03-27 13:54:05 <iddo> helo: i thought the point was replacing multisig receiving addr with an attacker non-multisig addr, and giving the malicious addr to the sender
 73 2012-03-27 13:54:16 <luke-jr> O.O
 74 2012-03-27 13:58:26 <helo> general security problem is problem
 75 2012-03-27 13:59:37 <helo> "prolific compromise prolific"
 76 2012-03-27 14:00:59 <mcorlett> gavinandresen: How is this even a problem? If the attacker has enough access to overwrite bitcoin.exe, you can say bye-bye to your private keys. What am I missing?
 77 2012-03-27 14:01:32 <vegard> is this accurate? http://folk.uio.no/vegardno/block-hashing-algorithm.png
 78 2012-03-27 14:02:01 <gavinandresen> mcorlett: I assume a 2-device multisignature wallet to begin with
 79 2012-03-27 14:02:45 <mcorlett> That makes sense. Sorry.
 80 2012-03-27 14:04:00 <gavinandresen> mcorlett: no problem.  I'm writing up a gist with my thoughts where I'll try to lay out assumptions like that.
 81 2012-03-27 14:05:22 <devrandom> gavinandresen: have you seen this when trying to make-base-vm?  2012-03-26 23:17:31,850 INFO    : umount: /tmp/tmp8W6bEp/dev: device is busy.
 82 2012-03-27 14:05:53 <gavinandresen> devrandom: no
 83 2012-03-27 14:06:08 <luke-jr> devrandom: hey, can you do the 3rd 0.5.4rc2 build for us? :D
 84 2012-03-27 14:07:05 <luke-jr> hmm
 85 2012-03-27 14:07:39 <luke-jr> my new 0.5.4rc2 build still doesn't match sipa's for Bitcoin-Qt; what is different about Gavin's Qt that it doesn't match default gitian? :/
 86 2012-03-27 14:08:31 <devrandom> luke-jr: I have to run, but could look at it tonight.  is the qt for 0.5 same as 0.6 or does it need rebuilding?
 87 2012-03-27 14:08:48 <luke-jr> devrandom: should be the same
 88 2012-03-27 14:09:26 <devrandom> (there were some build options changing in 0.6)
 89 2012-03-27 14:10:03 <luke-jr> devrandom: they were reverted
 90 2012-03-27 14:10:47 <luke-jr> or rather, moved to the .pro file
 91 2012-03-27 14:11:36 <specular> 1 question
 92 2012-03-27 14:11:42 <specular> does the encryption cause new private keys to be generated?
 93 2012-03-27 14:12:18 <luke-jr> specular: for new addresses, yes
 94 2012-03-27 14:12:24 <specular> oh
 95 2012-03-27 14:12:35 <specular> what about for existing addresses?
 96 2012-03-27 14:12:55 <luke-jr> impossible
 97 2012-03-27 14:13:38 <luke-jr> hmm, interesting
 98 2012-03-27 14:13:51 <luke-jr> despite being different SHA256, the bitcoin-qt.exe I have disassemble the same
 99 2012-03-27 14:14:05 <luke-jr> err, nm, mine don't have different SHA256
100 2012-03-27 14:14:30 <luke-jr> guess I need to wait on sipa's
101 2012-03-27 14:21:51 <vegard> luke-jr: can you verify my infographic?
102 2012-03-27 14:23:03 <mod6> does it take a while for GLBSE to ack the coins sent into a new account?  I sent mine in yesterday, and they were confirmed +6 after 4am CDT.
103 2012-03-27 14:23:11 <mod6> (this morning, not yesterday actually)
104 2012-03-27 14:23:21 <mod6> No coins in account yet :/
105 2012-03-27 14:23:30 <luke-jr> vegard: what?
106 2012-03-27 14:23:33 <gribble> New news from bitcoinrss: runeksvendsen opened issue 997 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/997>
107 2012-03-27 14:23:48 <vegard> luke-jr: I made this infographic: http://folk.uio.no/vegardno/block-hashing-algorithm.png
108 2012-03-27 14:24:13 <specular> is it safe to create a wallet, add some addresses... back it up... then send some bitcoins to the original wallet and delete it afterwards?
109 2012-03-27 14:24:20 <specular> im a little confused on how the private keys work
110 2012-03-27 14:24:58 <mod6> bah, wrong channel.
111 2012-03-27 14:25:19 <luke-jr> vegard: I guess
112 2012-03-27 14:26:13 <specular> ?
113 2012-03-27 14:26:23 <mod6> hey whats up - Sent some coins to new GLBSE account at 2am .. was confirmed >6 at 4... still no coins in my account.  What am I missing?  Does it just take a while?
114 2012-03-27 14:26:45 <mod6> ^^^^ for smickles or splatster
115 2012-03-27 14:27:12 <splatster> mod6: I'm not sure what's wrong
116 2012-03-27 14:27:14 <vegard> luke-jr: thanks.
117 2012-03-27 14:27:21 <mod6> jesus, how did i get it in here again.
118 2012-03-27 14:27:28 <mod6> im sorry guys.
119 2012-03-27 14:28:53 <specular> anyone?
120 2012-03-27 14:30:32 <gavinandresen> specular: yes, it is safe to do that. wallet.dat will contain all of your private keys, they are never deleted (unless you do something wacky like use PyWallet)
121 2012-03-27 14:38:47 <specular> ok, so to make 100% sure... gavinandresen, if i create a wallet, with 12 addresses added to it... once that wallet.dat is saved, those keys are fixed?
122 2012-03-27 14:40:29 <gavinandresen> specular: yes... private keys are never deleted. And they are only rewritten if you encrypt the wallet.
123 2012-03-27 14:47:49 <specular> theyre rewritten if you encrypt the wallet?
124 2012-03-27 14:47:53 <specular> what do you mean?
125 2012-03-27 14:50:28 <helo> they are encrypted
126 2012-03-27 14:50:38 <specular> but the private keys remain the same?
127 2012-03-27 14:50:41 <helo> yes
128 2012-03-27 14:50:45 <specular> thx
129 2012-03-27 14:50:56 <specular> what do you recommend for encrypting the wallet on windows?
130 2012-03-27 14:51:02 <specular> if u dont wanna use the client
131 2012-03-27 14:51:39 <helo> i would probably use pgp, but i haven't used it before
132 2012-03-27 14:52:17 <specular> the one by symantec?
133 2012-03-27 14:54:42 <luke-jr> specular: you probably want an encrypted filesystem, so you can actually run bitcoin :p
134 2012-03-27 14:55:22 <twmz> luke-jr: you still looking for me about ubuntu or did you find someone else?
135 2012-03-27 14:55:27 <helo> hmm... i don't see the old "PGP Desktop" (only "PGP Desktop Email")... so i guess PGP Whole Disk Encryption, and put it on a thumb drive
136 2012-03-27 14:55:49 <luke-jr> twmz: yeah, we need a 3rd person to build 0.5.4rc2
137 2012-03-27 14:55:58 <luke-jr> twmz: (gitian requires Ubuntu)
138 2012-03-27 14:56:05 <twmz> luke-jr: what does that mean?  I am not familiar with the official processes.
139 2012-03-27 14:56:26 <luke-jr> twmz: gitian is the software we use to make deterministic builds (identical for all builders)
140 2012-03-27 14:56:43 <luke-jr> twmz: releases for SourceForge need 3 people to sign off on the output
141 2012-03-27 14:56:50 <specular> no luke-jr, i jsut want to encrypt the wallet.dat file
142 2012-03-27 14:57:26 <twmz> luke-jr: I am happy to help.  I have a variety of linux boxes that include 11.04 ubuntu and 11.10 ubuntu.  what do you need me to do?
143 2012-03-27 14:57:40 <specular> isnt that good enough?
144 2012-03-27 14:58:01 <luke-jr> specular: my point is if you use file encryption, you won't be able to USE the wallet
145 2012-03-27 14:58:15 <specular> no, i just decrypt it as needed...
146 2012-03-27 14:58:17 <luke-jr> twmz: https://gist.github.com/806265
147 2012-03-27 14:59:41 <twmz> what does apt-cacher do to my system?
148 2012-03-27 15:02:11 <twmz> following the steps now...
149 2012-03-27 15:02:30 <twmz> I assume ubuntu 11.10 is acceptable
150 2012-03-27 15:04:11 <luke-jr> I assume.
151 2012-03-27 15:04:18 <luke-jr> apt-cacher just caches dpkgs I think
152 2012-03-27 15:17:57 <specular> hi im trying to transfer bitcoins from one wallet to another in windows
153 2012-03-27 15:18:12 <twmz> it errored out: http://pastebin.com/fTGU53K3
154 2012-03-27 15:18:13 <specular> im doing it by using notepad to store the public keys and renaming the different wallet.dat files
155 2012-03-27 15:18:29 <specular> ive just transferred some bitcoins to my new wallet but its not showing up even though it has 2 confirmations with my old wallet
156 2012-03-27 15:18:30 <specular> whats wrong?
157 2012-03-27 15:28:14 <specular> ??
158 2012-03-27 15:28:51 <sipa> specular: you transfer keys by doing what?
159 2012-03-27 15:36:00 <specular> sipa: i goto my old wallet, and send the bitcoins to the new public keys in the new wallet
160 2012-03-27 15:36:09 <specular> then close the client
161 2012-03-27 15:36:15 <sipa> ok, and how is notepad involved?
162 2012-03-27 15:36:16 <specular> and rename the files so the new wallet is wallet.dat
163 2012-03-27 15:36:29 <specular> i use notepad to record the public keys in my new wallet
164 2012-03-27 15:36:32 <sipa> ok
165 2012-03-27 15:36:49 <sipa> (they're called addresses, and are derived from a hash of a public key, not the public key itself)
166 2012-03-27 15:36:51 <specular> when i open the client again there are no signs of the transaction
167 2012-03-27 15:36:56 <specular> oh i see
168 2012-03-27 15:37:13 <sipa> anyway, if the receiver is not online when the transaction is transmitted, it will not see it immediately
169 2012-03-27 15:37:38 <sipa> only when it is mined into a block
170 2012-03-27 15:39:27 <BlueMatt> specular: truecrypt - for all your windows encryption needs (tm)
171 2012-03-27 15:51:23 <specular> sipa: its got 2 confirms
172 2012-03-27 15:51:50 <specular> and that was ages ago
173 2012-03-27 15:52:11 <sipa> specular: the sender, but not the receiver?
174 2012-03-27 15:52:19 <sipa> try starting the receiver with -rescan
175 2012-03-27 15:52:32 <sipa> shouldn't be necessary, though...
176 2012-03-27 15:52:34 <specular> will that reload the blockchain?
177 2012-03-27 15:52:37 <sipa> no
178 2012-03-27 15:52:52 <sipa> it will scan the blockchain for transactions that are missing in your wallet
179 2012-03-27 15:54:19 <specular> oh i see
180 2012-03-27 15:55:37 <specular> ah its worked
181 2012-03-27 15:56:32 <sipa> which version is this?
182 2012-03-27 15:56:44 <sipa> luke-jr: http://bitcoin.sipa.be/builds
183 2012-03-27 15:56:49 <luke-jr> sipa: ty
184 2012-03-27 15:57:54 <gavinandresen> BlueMatt: ping
185 2012-03-27 15:59:42 <gavinandresen> luke-jr sipa BlueMatt and anybody else awake and interested:  https://gist.github.com/2217885   <-- thoughts on wallet and payment security
186 2012-03-27 16:00:29 <Blitzboom> great to see such plans
187 2012-03-27 16:08:47 <luke-jr> sipa: hmm, the diffs between ours look like the diff between 0.5.3 and 0.5.3.1, but neither have the bug
188 2012-03-27 16:08:59 <luke-jr> I'm going to rebuild my qt just in case
189 2012-03-27 17:01:38 <BlueMatt> gavinandresen: pong
190 2012-03-27 17:01:58 <BlueMatt> gavinandresen: Ill take a look in an hour or two
191 2012-03-27 17:02:21 <gavinandresen> BlueMatt: cool, I'm about to run out the door.  But where should I send bug reports for BIP 21 ?
192 2012-03-27 17:02:38 <gavinandresen> (there are no & 's in the BNF grammar....)
193 2012-03-27 17:02:56 <BlueMatt> pull request a fix ;), or email it
194 2012-03-27 17:03:27 <gavinandresen> ok
195 2012-03-27 17:58:48 <luke-jr> FWIW, Qt itself does seem to be deterministic to me&
196 2012-03-27 17:58:57 <luke-jr> I just recreated an input I made months ago
197 2012-03-27 18:20:06 <BlueMatt> TD: mind acking/commenting on https://github.com/bitcoin/bitcoin/pull/951
198 2012-03-27 18:20:54 <TD> LGTM
199 2012-03-27 18:21:24 <BlueMatt> alright, just wanted to make sure
200 2012-03-27 18:21:30 <BlueMatt> thanks
201 2012-03-27 18:23:41 <Diablo-D3> td: now you're just making up acronyms
202 2012-03-27 18:24:27 <BlueMatt> how is lgtm made up?
203 2012-03-27 18:25:44 <BlueMatt> TD: oh, and mr payment protocols, gavin just sketched this out in case you are interested: https://gist.github.com/2217885
204 2012-03-27 18:27:10 <Diablo-D3> I have never seen lgtm used once
205 2012-03-27 18:27:24 <upb> IMO LGTM MTSA GA ISP FYI
206 2012-03-27 18:27:39 <upb> mtsa = means the same as, isp = in software projets
207 2012-03-27 18:28:02 <BlueMatt> Diablo-D3: I have
208 2012-03-27 18:28:11 <BlueMatt> upb: now you are just going overboard...
209 2012-03-27 18:28:43 <gavinandresen> what does upb stand for?
210 2012-03-27 18:28:46 <TD> LGTM is the standard google way to sign off on a code review. i didn't see it used much outside the firm, indeed
211 2012-03-27 18:29:22 <BlueMatt> funny how google has developed its own internal culture... (at least replacing kernel acks with lgtm)
212 2012-03-27 18:29:30 <upb> looks googly to me ?
213 2012-03-27 18:29:34 <BlueMatt> heh
214 2012-03-27 18:29:44 <TD> gavins proposal looks good. it's the same as i mentioned a few times before, i think. replace user-visible addresses with SSL validated identities
215 2012-03-27 18:29:57 <TD> payment information can come from a file transferred via SSL so you know it's valid
216 2012-03-27 18:30:06 <Diablo-D3> heh, google culture
217 2012-03-27 18:30:10 <Diablo-D3> its rather disgusting in a way
218 2012-03-27 18:30:29 <TD> there are a few other useful acronyms like PTAL - please take another look
219 2012-03-27 18:30:31 <upb> SSL validated or X509 PKI validated ?:P
220 2012-03-27 18:30:34 <upb> why use SSL
221 2012-03-27 18:30:43 <BlueMatt> TD: oh that one would be useful...
222 2012-03-27 18:31:22 <gavinandresen> upb: why use SSL: because it is there and that's what 99.99% of the web uses?
223 2012-03-27 18:31:30 <Diablo-D3> does google culture at least use RSN?
224 2012-03-27 18:31:35 <gavinandresen> (I'm probably underestimating that percentage)
225 2012-03-27 18:32:12 <upb> yeah i have no idea what youre building atm but... seems fishy :P
226 2012-03-27 18:32:34 <upb> 'validating' files by requiring them to be transferred using ssl
227 2012-03-27 18:32:42 <Diablo-D3> gavinandresen: also, you do realize SSL is a complete pile of shit, right?
228 2012-03-27 18:32:45 <Diablo-D3> its not secure.
229 2012-03-27 18:32:51 <BlueMatt> ...
230 2012-03-27 18:32:53 <gavinandresen> sigh.
231 2012-03-27 18:32:56 <BlueMatt> and you recommend?
232 2012-03-27 18:33:13 <Diablo-D3> bluematt: depends entirely on whats needed
233 2012-03-27 18:33:21 <BlueMatt> https://gist.github.com/2217885
234 2012-03-27 18:33:21 <TD> read the linked article
235 2012-03-27 18:33:22 <upb> atleast TLS 1.1 :)
236 2012-03-27 18:33:30 <TD> ssl/tls is the best fit
237 2012-03-27 18:33:40 <t7> Diablo-D3: gud trol lul
238 2012-03-27 18:33:57 <BlueMatt> TD: I agree
239 2012-03-27 18:34:05 <Diablo-D3> yes, but what exactly is being secured here? just the socket layer?
240 2012-03-27 18:34:19 <BlueMatt> it would be cool if we could require bitcoin: uris to come from ssl/tls-secured sites
241 2012-03-27 18:34:31 <gavinandresen> No, the identity: are you paying "amazon.com" ?
242 2012-03-27 18:34:42 <Diablo-D3> gavinandresen: ssl isnt directly useful there
243 2012-03-27 18:34:46 <Diablo-D3> you need those special signed certs
244 2012-03-27 18:34:55 <gavinandresen> .... read the gist ....
245 2012-03-27 18:35:04 <Diablo-D3> Im in the middle of something so I cant read it
246 2012-03-27 18:35:10 <BlueMatt> then dont comment...
247 2012-03-27 18:35:12 <gavinandresen> ... then be quiet ...
248 2012-03-27 18:35:28 <Diablo-D3> I just dont want people thinking ssl is a viable security protocol when its not
249 2012-03-27 18:35:37 <gavinandresen> okey dokey
250 2012-03-27 18:36:01 <Diablo-D3> tls 1.2 with properly formed certs is enough to verify the identity of the remote host
251 2012-03-27 18:36:11 <Diablo-D3> and enough to verify the socket stream hasnt been tampered with
252 2012-03-27 18:36:16 <Diablo-D3> anything less most likely isnt secure
253 2012-03-27 18:36:27 <gavinandresen> So the one thing I'm not sure of is mentioned at the end: is it reasonable to expect web pages to be able to sign information using the server's private ssl key when they're generating payment information.
254 2012-03-27 18:36:38 <Diablo-D3> gavinandresen: no.
255 2012-03-27 18:36:40 <upb> its not
256 2012-03-27 18:36:47 <gavinandresen> why not?
257 2012-03-27 18:36:57 <Diablo-D3> why would it be?
258 2012-03-27 18:37:30 <gavinandresen> Because the web page is being generated on the server, the server MUST have access to the private key to serve up the page.....
259 2012-03-27 18:37:59 <upb> the web page might be generated on the server if its a small site
260 2012-03-27 18:38:19 <Diablo-D3> the web page isnt generated on the server if its a big one
261 2012-03-27 18:38:24 <upb> but for anything serious the private key wont be accessible to the server where the 'web page' is generated on
262 2012-03-27 18:38:27 <Diablo-D3> or its being passed through a dedicated ssl daemon
263 2012-03-27 18:38:51 <Diablo-D3> lots of bigger sites (amz/goog sized) used dedicated ssl hardware to proxy the actual shit
264 2012-03-27 18:39:36 <gavinandresen> Well, the payment information must be signed by the server at some point, to say "Yes, I really am amazon.com and I really do want you to send 11 BTC to that address to pay for order# 11,111"
265 2012-03-27 18:39:54 <Diablo-D3> gavinandresen: yes, BUT
266 2012-03-27 18:40:01 <gavinandresen> but.....
267 2012-03-27 18:40:26 <Diablo-D3> I think you want authenticated encryption
268 2012-03-27 18:41:12 <gavinandresen> No, I want the payment information signed with an identity that has some amount of trust (bestowed by a certificate authority or whatever your favorite mechanism for that is)
269 2012-03-27 18:41:13 <Diablo-D3> as in, it requires an additional component to authenticate not only is the TLS connection from amazon, but that they also explicitly allow the operation
270 2012-03-27 18:41:19 <BlueMatt> or...the bitcoin: link just gives you an https website which you can ping and it will give you the address which the bitcoin: uri links to, then both the phone and client can display send to address 1.... verified by amazon.com (Amazon LTD)
271 2012-03-27 18:41:32 <BlueMatt> then its a regular https request like anything else
272 2012-03-27 18:41:35 <BlueMatt> and its signed
273 2012-03-27 18:41:46 <Diablo-D3> bluematt: well, it wouldnt be a REGULAR https request
274 2012-03-27 18:41:53 <Diablo-D3> I said tls 1.2 for a reason
275 2012-03-27 18:42:01 <BlueMatt> ok, tls1.2-required https link
276 2012-03-27 18:42:06 <Diablo-D3> browser support seems to be lacking with tls 1.2 (they must hate security)
277 2012-03-27 18:42:15 <BlueMatt> ie bitcoin:1A...?verify=https://amazon.com/bitcoin-verify?order-id=1234
278 2012-03-27 18:42:21 <gavinandresen> BlueMatt: yeah.... but why not save a round-trip (in the case you already have the amazon cert cached) and have the server sign the payment information up-front?
279 2012-03-27 18:42:25 <Diablo-D3> yeah, a daemon that specifically just says "yeah, thats really my address"
280 2012-03-27 18:42:29 <Diablo-D3> would work
281 2012-03-27 18:42:40 <Diablo-D3> gavinandresen: cert caching is required anyhow
282 2012-03-27 18:42:44 <Diablo-D3> for security reasons
283 2012-03-27 18:42:45 <BlueMatt> gavinandresen: it would be nice, but its not as "clean" for proxy-using sites, and isnt as easy to set up
284 2012-03-27 18:42:56 <Diablo-D3> same way with TLS identity fingerprinting shit
285 2012-03-27 18:43:17 <BlueMatt> (plus I really, really hate using privkeys for more than one use, ie signing bitcoin addresses...)
286 2012-03-27 18:43:43 <BlueMatt> grumble, grumble, signmessage, grumble
287 2012-03-27 18:44:37 <TD> yeah, implementation wise having the server sign a nonce with the bitcoin key is easiest to implement
288 2012-03-27 18:44:54 <TD> mixing SSL and bitcoin keys would just get complicated. but that's fine.
289 2012-03-27 18:44:55 <gavinandresen> Hmm?  I'm not talking about bitcoin private keys, I'm talking web server private keys (and associated certificates)
290 2012-03-27 18:45:13 <BlueMatt> TD: I dont see how signing the with the bitcoin address would allow verification...
291 2012-03-27 18:45:27 <gavinandresen> If you're sending to a multisig address then there is no single bitcoin private key to sign with anyway.
292 2012-03-27 18:45:29 <BlueMatt> TD: I was commenting that I dont like using bitcoin privkeys for BOTH sending and signing messages...
293 2012-03-27 18:45:44 <TD> the first device sends (example.com, bitcoin pubkey[s]) to the second device
294 2012-03-27 18:45:52 <TD> second device contacts example.com and says "are these your keys"
295 2012-03-27 18:46:46 <TD> i agree with upb that signing some arbitrary data packet with SSL keys would be painful for large sites. it'd be annoying to implement at google, at least.
296 2012-03-27 18:47:04 <gavinandresen> ok, good to know.
297 2012-03-27 18:47:22 <TD> for obvious reasons distribution of the keys is restricted, they rotate from time to time, etc
298 2012-03-27 18:48:18 <BlueMatt> hmm...I do like that better
299 2012-03-27 18:48:23 <TD> by the way, amazon.com uses EV SSL
300 2012-03-27 18:48:38 <BlueMatt> simple https://amazon.com/bitcoin-signing-keys.txt would work nicely...
301 2012-03-27 18:49:11 <splatster> S??? Capital Management's IPO has started! Go to https://glbse.com/asset/view/SS to buy shares.  Visit https://bitcointalk.org/index.php?topic=74216.0 to learn more or join #S2CM.
302 2012-03-27 18:49:14 <TD> oh, hmm, maybe only sometimes. ok paypal.com does :) so then you can display an authenticated "friendly name"
303 2012-03-27 18:49:15 <splatster> oops
304 2012-03-27 18:49:29 <splatster> Didn't mean to post that here, sorry.
305 2012-03-27 18:49:31 <TD> BlueMatt: well you need to ask the server to sign with the keys sent by your first device, which are presumably fresh for each transaction
306 2012-03-27 18:49:47 <TD> BlueMatt: so the "well known" verify endpoint is the way to go
307 2012-03-27 18:50:42 <TD> it's simple enough. You can just POST a pubkey + nonce to the endpoint and get back a signature in the response.
308 2012-03-27 18:52:03 <BlueMatt> oh, I was thinking bitcoin:1...?sig=1234 but yea, yours is better
309 2012-03-27 18:52:21 <gavinandresen> so lets think through how it would work using pgp identities...
310 2012-03-27 18:52:40 <BlueMatt> still, it would be good to have a list of pubkeys so that we can solve the "non-repudiation" problem
311 2012-03-27 18:52:56 <BlueMatt> and then the response to the query is logged
312 2012-03-27 18:53:14 <BlueMatt> though that could be done without a list either way...
313 2012-03-27 18:53:23 <TD> given the low adoption of PGP for individuals your best bet is just to use DKIM and email, imho. it's easy / transparent for users.
314 2012-03-27 18:53:29 <TD> "pki without the pain"
315 2012-03-27 18:54:09 <TD> social networking integration also is interesting to explore
316 2012-03-27 18:54:17 <gavinandresen> if the query was "Is this your signature?" instead of "Is this your bitcoin address?" we get non-repudiation.  The private key for the signature doesn't have to be the SSL private key.
317 2012-03-27 18:55:01 <TD> how do you create such a query? the second device needs to challenge the sever
318 2012-03-27 18:55:02 <TD> server
319 2012-03-27 18:55:39 <BlueMatt> if the query is over tls its verifiable either way (given certain session details logged)
320 2012-03-27 18:55:43 <gavinandresen> Same way: query the endpoint via SSL
321 2012-03-27 18:56:12 <BlueMatt> but it would be easier to avoid having to detail session keys from the tls session
322 2012-03-27 18:57:40 <TD> so .... the first device talks to amazon.com and obtains a payment descriptor containing an output script, and a signature over the descriptor calculated using the keys in the output script?
323 2012-03-27 18:58:02 <TD> i don't get it
324 2012-03-27 18:58:03 <TD> the payment goes to keys
325 2012-03-27 18:58:18 <TD> the second device has to prove that the keys its paying to are owned by the given identity.
326 2012-03-27 18:58:20 <gavinandresen> TD: no, just a signature using whatever key is convenient for amazon.com.
327 2012-03-27 18:58:59 <TD> (or at least that one of them is)
328 2012-03-27 18:59:03 <gavinandresen> TD: the second device then does an SSL query to amazon.com (certificate checks to confirm identity) and asks "Is this your signature on this payment info?"
329 2012-03-27 18:59:37 <TD> what links the signature and the keys the device will pay to? what stops the first device providing a valid signature, but different keys?
330 2012-03-27 18:59:56 <gavinandresen> the signature comes from amazon.com, not the first device
331 2012-03-27 19:00:24 <gavinandresen> (signature over "where should the payment go to")
332 2012-03-27 19:01:01 <BlueMatt> how does a user prove that the coins they sent were to amazon?
333 2012-03-27 19:01:07 <BlueMatt> if amazon backs out?
334 2012-03-27 19:01:58 <BlueMatt> I mean you could log all the local ssl/tls session details and log the connection, but that is ugly
335 2012-03-27 19:02:00 <gavinandresen> Darn good question.  That's why I wanted to use the well-known-to-everybody CA-signed SSL private key.
336 2012-03-27 19:02:33 <BlueMatt> how about: amazon publishes the list of keys they use to sign payment info
337 2012-03-27 19:02:42 <gavinandresen> That'd work.
338 2012-03-27 19:03:12 <BlueMatt> they can rotate them, but have to do it slowly anyway to avoid issues with lag between user devices
339 2012-03-27 19:03:18 <BlueMatt> and people can log changes
340 2012-03-27 19:06:06 <BlueMatt> I kinda prefer no sig on the original bitcoin: link, just a https url to post to like https://amazon.com/bitcoin-verf?orderid=1234 and you first get the list of acceptable keys from https://amazon.com/bitcoin-keys.txt and POST https://amazon.com/bitcoin-verf?orderid=1234&nonce=2345 with the bitcoin address, amount, etc and gets a signed copy with a key from bitcoin-keys.txt
341 2012-03-27 19:06:10 <TD> i actually quite like the idea of logging the TLS traffic in such a way that you can verify it
342 2012-03-27 19:06:12 <BlueMatt> (all ssl obv)
343 2012-03-27 19:06:38 <BlueMatt> TD: is there software out there to verify a tls session given the necessary local random values?
344 2012-03-27 19:06:44 <TD> key management is a pain. i wonder if it's possible to do it well
345 2012-03-27 19:06:48 <TD> good question
346 2012-03-27 19:06:49 <BlueMatt> (Im assuming so, for decryption stuff..)
347 2012-03-27 19:06:50 <TD> i don't know
348 2012-03-27 19:07:04 <BlueMatt> also, does openssl allow us to get at that info...
349 2012-03-27 19:07:42 <BlueMatt> that said, yea its much simpler than key management via bitcoin-keys.txt...
350 2012-03-27 19:07:51 <gmaxwell> TD: thats really a pain to do especially if the far end signals PFS. Plus no one has tools to check that, and the site could change certs before you made your claim.
351 2012-03-27 19:08:11 <TD> the old cert would still be signed by the CA though, and you could keep a copy of the cert
352 2012-03-27 19:08:14 <TD> PFS?
353 2012-03-27 19:08:44 <BlueMatt> perfect forward secrecy?
354 2012-03-27 19:08:50 <gmaxwell> perfect forward secrecy, the diffie hellman ciphersuites.
355 2012-03-27 19:09:04 <gmaxwell> TD: okay, point on keeping a copy of the certchain.
356 2012-03-27 19:09:13 <BlueMatt> yea, but if you log all your local random values that you use in the exchange, its still verifiable?
357 2012-03-27 19:09:30 <BlueMatt> though, I really doubt any tls library will let us get that info
358 2012-03-27 19:09:45 <TD> openssl s_client has a -debug option that prints a lot of data
359 2012-03-27 19:09:51 <TD> i'm assuming it doesn't use any internal-only APIs
360 2012-03-27 19:09:58 <TD> but yeah, probably, annoying to do across platforms
361 2012-03-27 19:10:07 <gmaxwell> BlueMatt: I _THINK_ so ... but it's possible to make exchanges that are denyable, but the TLS ones are not I think.
362 2012-03-27 19:10:33 <gmaxwell> (e.g. OTR's usage is denyable)
363 2012-03-27 19:10:39 <BlueMatt> yea
364 2012-03-27 19:10:59 <BlueMatt> we could tell openssl to blacklist denyable algos, but that would take a lot of work...
365 2012-03-27 19:11:30 <upb> acutually not :)
366 2012-03-27 19:11:38 <upb> as you can specify the acceptable methods
367 2012-03-27 19:12:03 <BlueMatt> well either way, its an elegant(ish) solution, but it sounds like it would take a lot of work to get it to function...
368 2012-03-27 19:12:07 <gmaxwell> The hardwer work is just convincing yourself that none are. Denying PFS is bad, so I hope it isn't denyable.
369 2012-03-27 19:12:43 <TD> the thing is, if you want users to be able to prove a transaction took place with foo.com at that time, doing it entirely independently of SSL is probably a huge infrastructure
370 2012-03-27 19:12:57 <BlueMatt> yea, kinda
371 2012-03-27 19:12:59 <TD> you need lots of people to verify that the ecdsa keys used by foo.com at time X were Y
372 2012-03-27 19:13:08 <TD> sounds like .... hmm .... a distributed p2p consensus :)
373 2012-03-27 19:13:22 <BlueMatt> heh, lets put everyone's name in the blockchain
374 2012-03-27 19:14:18 <gmaxwell> ThomasV has opinions on this subject.
375 2012-03-27 19:14:30 <ThomasV> ?
376 2012-03-27 19:14:46 <gmaxwell> ThomasV: they're talking about signing payment addresses. I thought you had opinions here.
377 2012-03-27 19:15:07 <ThomasV> oh yes I do. very strong opinions!
378 2012-03-27 19:15:32 <BlueMatt> gmaxwell: actually, I really, really dont think any ssl/tls algos will have deniable authentication
379 2012-03-27 19:15:50 <BlueMatt> gmaxwell: I dont think its possible without revealing keys after the exchange
380 2012-03-27 19:15:56 <ThomasV> gmaxwell: don't you?
381 2012-03-27 19:15:57 <BlueMatt> gmaxwell: and ssl/tls certainly wont do that?
382 2012-03-27 19:15:58 <gmaxwell> BlueMatt: You're probably right.
383 2012-03-27 19:16:14 <BlueMatt> ThomasV: care to share?
384 2012-03-27 19:16:28 <BlueMatt> but yea, more research would be needed before any kind of implementation...
385 2012-03-27 19:16:30 <gavinandresen> ThomasV: I put up a straw-man to get the discussion rolling again at  https://gist.github.com/2217885
386 2012-03-27 19:16:50 <ThomasV> BlueMatt: http://ecdsa.org/bitcoin_URIs.html
387 2012-03-27 19:18:25 <TD> heh. you use a self signed cert
388 2012-03-27 19:18:39 <BlueMatt> heh
389 2012-03-27 19:20:57 <ThomasV> I guess we need to wait for a working DIANNA in order to use signed URIs
390 2012-03-27 19:21:33 <TD> why?
391 2012-03-27 19:22:02 <gavinandresen> Hmm?  the SSL Certificate Authority system is broken and nasty... and works well enough that I regularly use it to do online banking.
392 2012-03-27 19:22:53 <ThomasV> TD: it depends what you want to do with it, but I want to make sure that the owner of the alias cannot change it covertly
393 2012-03-27 19:23:14 <gmaxwell> Logging an SSL exchange isn't mutually exclusive with doing other SSL independant things inside it.
394 2012-03-27 19:23:15 <BlueMatt> gavinandresen: if we do implement aliases (not saying we should...) how would the proposal change?
395 2012-03-27 19:23:27 <TD> right. well gavins proposal is intended to be the next building block for 2-factor tx signing
396 2012-03-27 19:23:42 <gmaxwell> ThomasV: they're proposing to log the SSL exchange so I could later prove that the address I used was one they gave me.
397 2012-03-27 19:24:02 <luke-jr> gavinandresen: LOL nice
398 2012-03-27 19:24:04 <ThomasV> gmaxwell: that's not a good idea
399 2012-03-27 19:24:40 <gmaxwell> BlueMatt: actually it looks like it would be denyable... the exchange just derrives hmac and encryption keys. Either side could use it to produce payload which passes the test.
400 2012-03-27 19:25:11 <gmaxwell> (same way that OTR works the publication isn't required for the remote end to fabricate the data)
401 2012-03-27 19:25:35 <ThomasV> the SSL can only be used on websites that use SSL; it would not work on a forum with many users, each with their key
402 2012-03-27 19:25:54 <TD> yeah, but a lot of transactions are between merchant and buyer
403 2012-03-27 19:25:54 <ThomasV> and it would not work on other channels, eg IRC
404 2012-03-27 19:25:59 <TD> merchants today use SSL as a de-facto standard
405 2012-03-27 19:26:19 <TD> solving the person-to-person use case is much harder, given that ~nobody understands PKI
406 2012-03-27 19:26:40 <gmaxwell> I agree with TD but as I said above, it won't actually work.
407 2012-03-27 19:26:40 <TD> any system that requires people to actually understand public/private keys might as well be junked before you even begin, assuming you care about the mass market
408 2012-03-27 19:27:08 <BlueMatt> gmaxwell: ah, ofc, yea Im a dumbass...
409 2012-03-27 19:27:08 <TD> gmaxwell: pure SSL handshake, you mean?
410 2012-03-27 19:27:24 <gavinandresen> agreed.  Although I was hoping to throw in won't-never-be-used-except-by-crypto-geeks-who-complain-loudly pgp wot stuff
411 2012-03-27 19:28:14 <gmaxwell> TD: If you log the all the SSL data you can prove to yourself that the server sent you that but not to anyone else, because you have enough data to fabricate any address you like.
412 2012-03-27 19:28:16 <TD> gmaxwell: oh, your point is, you could fake having received a particular file
413 2012-03-27 19:28:20 <TD> right
414 2012-03-27 19:28:54 <BlueMatt> gavinandresen: now _that_ complicates things...
415 2012-03-27 19:28:54 <gmaxwell> You could do something wacked, like use the bitcoin public key as a nonce in part of the ssl exchange.. and that _would_ non-reputably bind it... but that requires far deeper intergration on the server side. :(
416 2012-03-27 19:28:57 <gribble> New news from bitcoinrss: Diapolo opened pull request 998 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/998>
417 2012-03-27 19:29:16 <gavinandresen> BlueMatt: not conceptually, it is all just identity and signatures
418 2012-03-27 19:29:28 <gmaxwell> At that point it would be easier to just make an external signing tool that writes a message file signed with the SSL cert.
419 2012-03-27 19:29:36 <BlueMatt> well, yea but in implementation, it complicates things greatly...
420 2012-03-27 19:29:48 <TD> ssl is fairly complicated. i wonder if there's a way to do it ...
421 2012-03-27 19:30:05 <gmaxwell> (and if you use a message signed with the SSL cert you could also support signing with GPG keys pretty easily)
422 2012-03-27 19:30:22 <BlueMatt> unless we have some cryptographers here?
423 2012-03-27 19:30:27 <ThomasV> lol
424 2012-03-27 19:30:28 <gmaxwell> gavinandresen: people would use the gpg signed stuff they'd just never validate it and they'd get ripped off. Alas.
425 2012-03-27 19:31:08 <gmaxwell> BlueMatt: That was a bad idea I gave. I just mentioned it to avoid some lurking pedant saying "oh sure you can do it!"
426 2012-03-27 19:31:24 <BlueMatt> ah, good
427 2012-03-27 19:31:28 <ThomasV> I think that verifying a signed URI is the job of the bitcoin client, not of the web browser.
428 2012-03-27 19:31:51 <BlueMatt> gmaxwell: just the idea of messing with ssl internals though...yuck
429 2012-03-27 19:31:51 <gmaxwell> ThomasV: this doesn't have anything to do with the web browser.
430 2012-03-27 19:31:53 <TD> hmm, i guess it's fundamental. the actual encrypted data is always done with a symmetric key
431 2012-03-27 19:32:02 <BlueMatt> TD: yep :(
432 2012-03-27 19:32:29 <ThomasV> gmaxwell: the bitcoin client would open a SSL session with the webserver?
433 2012-03-27 19:32:42 <gmaxwell> ThomasV: correct. And log the data required to prove it.
434 2012-03-27 19:32:47 <delt0r> TD: if you didn't do that it would a massive amount of CPU for even a really slow data rate
435 2012-03-27 19:32:52 <gmaxwell> But as I pointed out above, this doesn't actually work. :(
436 2012-03-27 19:32:57 <TD> yes, i know
437 2012-03-27 19:33:02 <TD> pki is expensive
438 2012-03-27 19:33:18 <ThomasV> gmaxwell: then you'll need to mess with the users password manager in order to open a session...
439 2012-03-27 19:33:19 <TD> ssl has a concept of sessions
440 2012-03-27 19:33:38 <TD> i wonder if it's possible to resume a session after the traffic and get a signed message containing some state that could only have come from the previous traffic
441 2012-03-27 19:34:33 <gmaxwell> ThomasV: no. You won't.
442 2012-03-27 19:34:48 <ThomasV> how so?
443 2012-03-27 19:35:06 <upb> but even if it was possible, in order to use that, it would require indefinite storage of session cache on the server side TD :)
444 2012-03-27 19:35:32 <TD> why indefinite? it only has to be temporary
445 2012-03-27 19:35:37 <TD> fwiw google does do distributed ssl session caching :)
446 2012-03-27 19:35:38 <gmaxwell> ThomasV: you connect to some publically accessible CGI on the server and say "my cookie is X did you just give me this address Y?" and it says "Yep".
447 2012-03-27 19:35:56 <gmaxwell> (though as mentioned it doesn't actually work, so discussing it is dumb)
448 2012-03-27 19:36:15 <ThomasV> ok, then let's not discuss it :)
449 2012-03-27 19:36:20 <BlueMatt> hummm... ok so if messing with ssl/tls gets ugly, what other solutions do we have?
450 2012-03-27 19:36:28 <gmaxwell> td: I think it's a lot harder to justify when you have to do some crazy deep manipulation on the server side.
451 2012-03-27 19:36:34 <upb> TD: oh i thought you were proposing to resume the session later to prove that the previous recorded data was valid
452 2012-03-27 19:36:40 <TD> hmm
453 2012-03-27 19:36:42 <gmaxwell> BlueMatt: you could still use the x509 public cert to sign random messages.
454 2012-03-27 19:36:47 <BlueMatt> https://amazon.com/bitcoin-keys.txt gets really complicated when you have to rotate keys
455 2012-03-27 19:36:55 <TD> yeah. but the session resume just remembers the symmetric key.
456 2012-03-27 19:37:07 <TD> gmaxwell: yes. it is.
457 2012-03-27 19:37:22 <TD> gmaxwell: too bad. it would have been convenient. i guess there needs to be a different way to do receipts
458 2012-03-27 19:37:25 <BlueMatt> gmaxwell: yea, but I still really dont like that...
459 2012-03-27 19:37:48 <BlueMatt> you try telling google's ssl privkey holder to use it for something other than https...
460 2012-03-27 19:37:56 <gavinandresen> I still like the sign-stuff with the x509 cert approach.  Could be a different x509 cert than is used for TLS if necessary....
461 2012-03-27 19:38:07 <Diablo-D3> man
462 2012-03-27 19:38:10 <Diablo-D3> why the fucking hell
463 2012-03-27 19:38:10 <gmaxwell> BlueMatt: so just have the server sign a message saying, yep my address is XXX, with the x.509 cert and the client can just do browser like validation of it and keep a copy of the cert.
464 2012-03-27 19:38:17 <Diablo-D3> are people so fucking shitty
465 2012-03-27 19:38:20 <TD> no, wait
466 2012-03-27 19:38:28 <gmaxwell> BlueMatt: yes, but well, better than telling him to apply a crazy openssl patch to pick special nonces or whatever!
467 2012-03-27 19:38:33 <TD> gmaxwell: are you sure? i thought every ssl message sent was HMACd?
468 2012-03-27 19:38:35 <Diablo-D3> if there was a country that was filled with normal goddamned people
469 2012-03-27 19:38:36 <TD> gmaxwell: including all traffic
470 2012-03-27 19:38:38 <Diablo-D3> I'd move there in a heart beat
471 2012-03-27 19:38:40 <gmaxwell> TD: it is.
472 2012-03-27 19:38:48 <BlueMatt> gmaxwell: well, yea but we are going for a good solution, not better than what we had a minute ago ;)
473 2012-03-27 19:38:57 <gmaxwell> TD: I mentioned this above. but you have the hmac key, otherwise you couldn't verify the hmac.
474 2012-03-27 19:39:09 <gmaxwell> TD: because you have the hmac key you can fake hmaced messages yourself.
475 2012-03-27 19:39:18 <Diablo-D3> seriously, someone answer my question, I fucking dare you
476 2012-03-27 19:39:22 <BlueMatt> Diablo-D3: I dont think you would be allowed in...
477 2012-03-27 19:39:25 <Diablo-D3> most of you are reasonably intelligent people
478 2012-03-27 19:39:35 <BlueMatt> intelligent != normal
479 2012-03-27 19:39:39 <gmaxwell> Diablo-D3: Antarctica
480 2012-03-27 19:39:43 <BlueMatt> in fact, they are often the opposite...
481 2012-03-27 19:39:46 <Diablo-D3> bluematt: probably not, goddamned if Im allowed to actually not hate people for once
482 2012-03-27 19:42:00 <gavinandresen> So: the bitcoin group at google gets one or more CA-signed keys, and uses them to sign bitcoin payment information.  The certificate authorities are built-in to bitcoin clients, and bob's your uncle.
483 2012-03-27 19:42:55 <TD> gmaxwell: right, got it
484 2012-03-27 19:43:34 <Diablo-D3> gavinandresen: yeah but like
485 2012-03-27 19:43:37 <t7> and the blockchain is so huge that newbies get disgruntled
486 2012-03-27 19:43:38 <Diablo-D3> what happens if the CA gets fucked.
487 2012-03-27 19:43:42 <gavinandresen> If we're not google and we're cheap, then we use the same key for both TLS and bitcoin payment information, and bob's still our uncle.  All assuming our PHP or Python or whatever web code that generates bitcon payment information URI's or files can call openssl.
488 2012-03-27 19:43:46 <BlueMatt> Diablo-D3: then so is your bank
489 2012-03-27 19:44:06 <Diablo-D3> gavinandresen: and you're going to have to enforce certain cert features
490 2012-03-27 19:45:08 <BlueMatt> gavinandresen: ok, sounds fine to me, wanna update the gist so we are all on the same page again?
491 2012-03-27 19:45:54 <gavinandresen> BlueMatt: will do.
492 2012-03-27 19:47:46 <gmaxwell> t7: pshaw. Upgrade to 0.6.
493 2012-03-27 19:47:55 <TD> gavinandresen: OCSP could be enabled for bitcoin clients, as performance is not so important for them
494 2012-03-27 19:48:50 <gavinandresen> TD: ACK
495 2012-03-27 19:49:05 <BlueMatt> should be required imo
496 2012-03-27 19:49:22 <TD> well
497 2012-03-27 19:49:29 <TD> CA outages would then prevent payments being processed
498 2012-03-27 19:49:44 <TD> (for those merchants)
499 2012-03-27 19:49:57 <TD> but yeah, maybe
500 2012-03-27 19:49:58 <BlueMatt> user-overrideable, but ocsp isnt worth much if it soft-fails
501 2012-03-27 19:50:11 <BlueMatt> mitm and you are dead
502 2012-03-27 19:50:46 <TD> alright
503 2012-03-27 19:51:03 <TD> so i guess we have agreement on this topic. big corps will just have to suck up the key distribution issues :)
504 2012-03-27 19:51:26 <BlueMatt> big corps can afford a second ssl key
505 2012-03-27 19:51:33 <TD> for person-to-person authentication. a WOT isn't inherently a bad idea, it's just a geeky word for a social network. the problem is the need to do it without keys or key exchanges ever becoming visible in the ui
506 2012-03-27 19:52:26 <TD> maybe you could use phones + bluetooth. look on your screen, see a name + photo that corresponds to the person standing in front of you. tapping them is  "good enough" to be considered a key exchange
507 2012-03-27 19:54:03 <TD> phones that find each other can exchange name+photo+key+signature sets in the background. all we have to do is hang out and now i can see your mutual acquaintances. we need never even think about bitcoin. if you wanted to key exchange with somebody but keep that fact private, i guess you'd need to mark the relationship as such
508 2012-03-27 19:54:09 <TD> so it wouldn't be handed out willy nilly
509 2012-03-27 19:54:25 <TD> spreading around social graph data is inherent in the WOT model, though
510 2012-03-27 19:55:36 <BlueMatt> I dont know about blindly exchanging info in the background if you are near another phone for long enough
511 2012-03-27 19:55:43 <BlueMatt> that could make for some interesting attacks
512 2012-03-27 19:56:10 <BlueMatt> but manual exchange with people who you wanna exchange with is cool
513 2012-03-27 19:56:21 <BlueMatt> over bluetooth or nfc or whatever
514 2012-03-27 19:56:26 <gavinandresen> https://gist.github.com/2217885 updated
515 2012-03-27 19:56:29 <BlueMatt> (nfc is better, bluetooth is too insecure...)
516 2012-03-27 19:56:51 <TD> what attacks are you imagining?
517 2012-03-27 19:57:00 <TD> i don't think a WOT has to be bullet-proof
518 2012-03-27 19:57:38 <BlueMatt> bluetooth has had too many attacks over the years, plus it works over long(ish) distances if the attacker has good hardware
519 2012-03-27 19:58:08 <TD> that's fine though
520 2012-03-27 19:58:16 <TD> bear in mind the data being exchanged is all signed
521 2012-03-27 19:58:20 <BlueMatt> bluetooth is mitmdable
522 2012-03-27 19:58:25 <t7> gmaxwell: whats new in 0.6 ?
523 2012-03-27 19:58:45 <t7> i run the git head on my server but 0.5.3.1 on windows
524 2012-03-27 19:58:56 <BlueMatt> TD: well if you sign it well on top, then you have to make users verify a short code on both sides...
525 2012-03-27 19:58:59 <TD> yes, so? my phone broadcasts my name, photo and a key. other people only "confirm" by tapping my entry in their apps list if they are actually near me and can see me
526 2012-03-27 19:59:10 <TD> so now if somebody wants to interfere with that, they could try adding another entry that looks identical
527 2012-03-27 19:59:27 <BlueMatt> wait, are you broadcasting it, I thought this was a one-on-one exchange
528 2012-03-27 19:59:28 <TD> but you'd notice because there'd be two identical looking entries in the list
529 2012-03-27 19:59:36 <BlueMatt> ie I hold my phone next to yours and it signs
530 2012-03-27 19:59:36 <TD> no, insecure bluetooth broadcast
531 2012-03-27 19:59:42 <BlueMatt> oh, well then yea nvm
532 2012-03-27 19:59:54 <BlueMatt> again, not a big fan of broadcasting though
533 2012-03-27 19:59:56 <TD> the app would presumably drop both if there were conflicting entries
534 2012-03-27 20:00:15 <Diablo-D3> heh, who really cares if it can be mitmed
535 2012-03-27 20:00:22 <gmaxwell> t7: being able to fully sync the chain in under an hour on ordinary systems.
536 2012-03-27 20:00:23 <Diablo-D3> if its signed, producing a false signature wont help
537 2012-03-27 20:00:27 <TD> well, it's an interesting social model. imagine a bunch of people going to a bitcoin meetup or conference. the WOT would automatically establish itself and anyone who attended would be able to pay anyone else, pretty much, as long as there was some chain between you and them
538 2012-03-27 20:00:28 <BlueMatt> oh, thats no good, I make 2 entries, one conflicts (the original gets dropped) and another one with a pixel in the image changed, and that gets signed...
539 2012-03-27 20:00:59 <t7> gmaxwell: what changed?
540 2012-03-27 20:01:00 <TD> BlueMatt: you could drop based on name similarity too, or flag in the UI as invalid, or something
541 2012-03-27 20:01:07 <BlueMatt> yea
542 2012-03-27 20:01:08 <t7> to the dl process
543 2012-03-27 20:01:20 <BlueMatt> anyway, I dont really get the point though, what does it provide?
544 2012-03-27 20:01:31 <BlueMatt> I thought the point was to provide secure name->address mappings
545 2012-03-27 20:01:38 <BlueMatt> not just a huge list of insecure ones?
546 2012-03-27 20:02:17 <BlueMatt> at some point you have to have users manually ack the name->address mapping that they get
547 2012-03-27 20:02:17 <TD> it's "secure enough", right? the point of the WOT is to let you send money to somebody when you aren't physically in front of them (otherwise you could just exchange a raw tx)
548 2012-03-27 20:02:25 <gmaxwell> t7: the poor performance had little to do with the download itself, and everything to do with validation and database updating speed. The bdb settings were tweaked to greatly improve performance.
549 2012-03-27 20:02:27 <TD> well, you just have to have users ack physical presence
550 2012-03-27 20:02:36 <TD> the "address" doesn't mean anything to them
551 2012-03-27 20:02:56 <TD> you just say, yes, this person is in front of me, i've met them and they did indeed tell me they were on the WOT
552 2012-03-27 20:02:58 <BlueMatt> interesting, but I just dont like the potential for abuse there...
553 2012-03-27 20:03:27 <BlueMatt> ah, and then you might as well do local nfc one-on-one exchanges
554 2012-03-27 20:03:32 <TD> now when you meet somebody else, your phone sends the key + details of the first person you met. it shows up for them automatically, and their phone trusts that it's valid because you sent it to them, and YOU were physically present
555 2012-03-27 20:03:33 <BlueMatt> which are way more secure and sane
556 2012-03-27 20:03:57 <BlueMatt> if you have to ack each person as physically present, you might as well just exchange one-on-one
557 2012-03-27 20:04:19 <TD> bluetooth is more widely supported than nfc and it's a bit more convenient if you want to ack several people. but sure.
558 2012-03-27 20:04:29 <gmaxwell> TD: I just feed you a fake wot full of addresses which belong to me. Then when you pay anyone you pay me all I have to do is meet you once?
559 2012-03-27 20:04:43 <BlueMatt> well, bluetooth or nfc doesnt matter much, I was just suggesting nfc because its much shorter range
560 2012-03-27 20:04:46 <TD> i have to confirm that i trust you by tapping your entry
561 2012-03-27 20:04:55 <TD> once i do that, i take all your WOT entries too
562 2012-03-27 20:05:01 <TD> so yes, if you scam me, i'm out of luck
563 2012-03-27 20:05:52 <BlueMatt> well take all your wot entries but mark them as 1-away
564 2012-03-27 20:06:02 <BlueMatt> and use that in calculating "trust" of an entry
565 2012-03-27 20:06:02 <TD> yes
566 2012-03-27 20:06:04 <gmaxwell> yea, I don't think it's possible to do wot trust securely without understanding.
567 2012-03-27 20:15:08 <luke-jr> sipa: I can't get a match on your bitcoin-qt :/
568 2012-03-27 20:15:16 <luke-jr> (nor on gavinandresen's qt&)
569 2012-03-27 20:18:15 <luke-jr> sipa: sorry, my mistake
570 2012-03-27 20:18:24 <luke-jr> I was comparing the wrong SHA256 this last time. it does match
571 2012-03-27 20:21:45 <bluemoon44> qt
572 2012-03-27 20:32:32 <amiller> so i posed an alternate proof of work scheme back a few weeks ago
573 2012-03-27 20:32:43 <amiller> i decided it wouldn't work, but now i think i was wrong and it _would_ work
574 2012-03-27 20:32:52 <amiller> so i'm just gonna blather about it again
575 2012-03-27 20:33:25 <amiller> there's two parameters, a 'difficulty' and a 'path-length'
576 2012-03-27 20:34:09 <amiller> the miner begins by choosing a nonce, then that nonce is used to pick a block from the blockchain
577 2012-03-27 20:34:22 <amiller> like nonce % 20000 if there are 20,000 blocks.
578 2012-03-27 20:34:55 <amiller> then you hash the nonce and the blockchain data at that block (the whole block data, not just the hash or the header)
579 2012-03-27 20:35:18 <amiller> then you use that resulting hash to index into the blockchain again, % 20000 again
580 2012-03-27 20:35:33 <amiller> you keep going N=<path-length> times
581 2012-03-27 20:35:54 <amiller> if the final hash is less than the difficulty threshold, then you win the block
582 2012-03-27 20:36:23 <amiller> the point of this alternate proof of work scheme is that the kind of equipment you would need to be a competitive miner is different than in bitcoin
583 2012-03-27 20:36:27 <amiller> to compete in bitcoin, you need GPUs
584 2012-03-27 20:36:38 <amiller> to compete with this alternate proof of work scheme, you need randomly accessible copies of the entire blockchain history
585 2012-03-27 20:37:04 <amiller> this is a significant advantage to the security of the protocol because it changes the incentives
586 2012-03-27 20:37:29 <amiller> right now, pool miners are 'mining' competitive but there's no incentive for them to independently check against double spends
587 2012-03-27 20:37:44 <sipa> if a miner can choose the nonce, wouldn't it just pick nonces of blocks it knows?
588 2012-03-27 20:37:56 <amiller> that's what i thought when i decided a few weeks ago this wouldn't work
589 2012-03-27 20:38:09 <amiller> could a miner get an advantage by just keeping a small subset of data and only checking those
590 2012-03-27 20:38:20 <sipa> it would appear so
591 2012-03-27 20:38:21 <amiller> but the thing is you don't know where the hash is going to take you next
592 2012-03-27 20:38:30 <amiller> there's a tradeoff with this path-length parameter
593 2012-03-27 20:38:47 <amiller> but even if you only store 2 blockchain entries
594 2012-03-27 20:39:07 <amiller> you could easily choose a nonce so that the first block you need to check is in your subset
595 2012-03-27 20:39:14 <amiller> but the chances are the next block you'd have to check is outside the subset
596 2012-03-27 20:39:27 <amiller> so doing that would cause you to waste a lot of time
597 2012-03-27 20:39:48 <amiller> you _could_ find a winning hash using only a subset
598 2012-03-27 20:39:52 <amiller> but it would take you exponentially more time
599 2012-03-27 20:39:59 <amiller> than someone who has the full blockchain
600 2012-03-27 20:40:45 <amiller> it's exponentially more efficient to store the whole blockchain than it is to cheat by using a subset
601 2012-03-27 20:41:14 <sipa> i see, that sounds valid
602 2012-03-27 20:43:10 <gmaxwell> amiller: Did you see see my "Forgetting the forgetful" post?
603 2012-03-27 20:43:17 <amiller> no
604 2012-03-27 20:43:51 <gmaxwell> Okay, it's from the same general class of approaches but not as a POW replacement.
605 2012-03-27 20:44:37 <gmaxwell> I hadn't thought of it as a POW replacement is simply because there is no reason to have ultrafast blockchain access it only needs to be 'fast enough'.
606 2012-03-27 20:44:47 <gmaxwell> amiller: https://bitcointalk.org/index.php?topic=68396
607 2012-03-27 20:45:18 <sipa> gmaxwell's idea is certainly easier to implement and roll our
608 2012-03-27 20:45:20 <sipa> our
609 2012-03-27 20:45:23 <sipa> ouT
610 2012-03-27 20:46:41 <gmaxwell> (regarding the last line in that message, what I really meant was 'pseudorandom based on the hash of the prior blocks' or the like)
611 2012-03-27 20:48:57 <gmaxwell> Unfortunately the thread is full of people who _just don't get it_ and I don't know how to express it any more clearly.
612 2012-03-27 20:49:20 <luke-jr> amiller: what if the path had to be based on the hash?
613 2012-03-27 20:49:38 <amiller> the path should probalby be based on the hash
614 2012-03-27 20:49:57 <gmaxwell> It was probably a mistake to even mention this in the context of 1txn blocks.
615 2012-03-27 20:50:23 <luke-jr> amiller: this sounds like it could have the same problem as scrypt
616 2012-03-27 20:50:38 <gmaxwell> Since it's really just a proof-you-know-the-blockchain  I'd been thinking about that for a while and the 1txn blocks sounded like a fine reason to make it public after people hypothesized they were due to mining without the chain.
617 2012-03-27 20:50:41 <luke-jr> hard to do on commodity hardware, so specialized equipment would have more of an advantage
618 2012-03-27 20:51:01 <sipa> luke-jr: so, what's the problem with specialized equipment?
619 2012-03-27 20:51:24 <luke-jr> sipa: any proof-of-work should be sufficiently easy that commodity hardware can keep up with specialized
620 2012-03-27 20:51:49 <sipa> there will always be a point where it becomes viable to invest in specialized equipment
621 2012-03-27 20:51:51 <gmaxwell> sipa: it means that targeted entities could get big control advantages over the general community of users.  but at least in amiller's case it would actually correlate well with txn processing ability.
622 2012-03-27 20:52:36 <luke-jr> sipa: yes, but the advantage needs to be small enough that it isn't an immediate 50% attack
623 2012-03-27 20:54:51 <Cory> After a hard crash, I used Diapolo's fix for the GUI crash which worked for me before (deleting C:ProgramDataoost_interprocess), but now I'm getting this error: http://i.imgur.com/Jx3o1.png
624 2012-03-27 20:55:24 <gmaxwell> Cory: you're using an old 0.6 RC?
625 2012-03-27 20:56:22 <sipa> Cory: it seems you're using rc4; that bug (as well as the GUI lockup) were fixed in RC5
626 2012-03-27 20:57:33 <Cory> I'll update.
627 2012-03-27 20:58:03 <Cory> Thanks. :)
628 2012-03-27 20:58:39 <amiller> ok i guess i should write this up better
629 2012-03-27 20:59:01 <amiller> that's what i'd have to argue i think, that it's a disadvantage not to have the whole blockchain
630 2012-03-27 20:59:30 <amiller> pretty much the 'commodity hardware' that would be used for this is SSDs with blockchain history on them
631 2012-03-27 20:59:47 <amiller> the more SSDs with blockchain history, the more paths you can check in parallel
632 2012-03-27 21:00:15 <amiller> so it's directly a scheme that incentivizes having tons of copies of blockchain history on extra disks
633 2012-03-27 21:00:39 <amiller> being "honest", i.e. processing txns is marginal additional effort for a competitive miner
634 2012-03-27 21:03:14 <gmaxwell> amiller: But I think that arugment will ultimately fail. I only need enough random access to validate the maximum transaction rate in << 10 minutes. Beyond that, there isn't any gain except whatever artificial one the POW creates.
635 2012-03-27 21:03:25 <gmaxwell> And the current maximum rate is helpfully pretty modest.
636 2012-03-27 21:03:56 <gmaxwell> (and if we raise the maximum rate  well, that will hose up decenteraliztaion because it will force nodes to SPV)
637 2012-03-27 21:04:55 <amiller> there's still a partial hash collision as part of this scheme
638 2012-03-27 21:05:09 <amiller> i don't think i understand your comment
639 2012-03-27 21:15:56 <nanotube> gmaxwell: interesting idea on your btalk post. i think to make it clearer, you could try adding bold on the word 'inputs'. :) and maybe explaining in parentheses that you're not talking about the transactions in the previous block, but transactions that are upstream of the transactions in the previous block, which may be anywhere in the block chain). also, fun response to maged ;)
640 2012-03-27 21:18:26 <gmaxwell> amiller: There is no advantage to the system to having people who can verify transactions faster than the maximum rate the system needs. That maximum isn't very high and can't be high because if bitcoin is to remain decenteralized a great many nodes need to be validating the rules (many more than those mining it).
641 2012-03-27 21:18:41 <gmaxwell> So once you cross that point your POW scheme is just another POW scheme work for the sake of work.
642 2012-03-27 21:19:15 <gmaxwell> Luke suggested that it might not be an excellent one because it has too much hyperspecialization gain.
643 2012-03-27 21:19:17 <t7> im unemployed
644 2012-03-27 21:19:27 <t7> how do i proof of work?
645 2012-03-27 21:20:03 <amiller> the point is for the marginal cost of being 'honest' to be zero
646 2012-03-27 21:20:20 <amiller> so the proof of work is still a lot of additional work over the necessary maximum rate
647 2012-03-27 21:20:21 <iz> t7: by presenting a valid hash with the right number of leading zero bits
648 2012-03-27 21:20:31 <amiller> but that means there's no way for a miner to save costs by not bothering to double check
649 2012-03-27 21:22:54 <gmaxwell> amiller: I think I am going to stab you now.
650 2012-03-27 21:23:13 <gmaxwell> Because I _understand_ what you're trying to accomplish. Thats not the source of the disagreement here.
651 2012-03-27 21:23:40 <gmaxwell> amiller: Lets imagine for a moment that bitcoin could by design only process one transaction per hour.
652 2012-03-27 21:24:12 <gmaxwell> amiller: You implement your system, and achieve your goal: because POW requires fast txn lookups any miner will do the txn processing work.
653 2012-03-27 21:25:00 <gmaxwell> amiller: however, you now have a POW system that makes miners that can process thousands of times faster than the system could possibly need. By itself thats harmless.
654 2012-03-27 21:26:02 <gmaxwell> amiller: but then someone implements a miner using TCAMs and can process tens of millions of times faster. Majority attacking the chain mined by SSDminers until they catch up by buying tcams. (and never mind that the ecc sig validation became the binder long before this point)
655 2012-03-27 21:26:10 <gmaxwell> This is probably not an ideal outcome.
656 2012-03-27 21:27:22 <gmaxwell> I suspect it would be better to just use enough proof-of-memory to show that you have no incentive to exclude transactions and use simple computation that general purpose devices are efficient at in order to minimize the hyperspecialization gain.
657 2012-03-27 21:27:58 <gmaxwell> "enough" can actually be set as a constant it doesn't have to be a POW race, because the network transaction rate has a constant maximum.
658 2012-03-27 21:32:02 <gmaxwell> amiller: ah, here is a killer point: that pow can't be validated without the chain. bye bye spv clients.
659 2012-03-27 21:35:20 <luke-jr> sipa: 0.6 signmessage isn't compatible with 0.5? :/
660 2012-03-27 21:36:01 <gmaxwell> 0_o
661 2012-03-27 21:36:55 <gmaxwell> amiller: hm. I guess it would be just not fully. but thats no worse than a seperate memory proof.
662 2012-03-27 21:37:00 <BlueMatt> does compressed pubkeys break that?
663 2012-03-27 21:37:33 <luke-jr> BlueMatt: I wonder
664 2012-03-27 21:38:03 <luke-jr> probably since verifymessage uses key recovery and compares :/
665 2012-03-27 21:38:11 <gmaxwell> I don't see how.
666 2012-03-27 21:38:33 <luke-jr> gmaxwell: 0.5 recovers the non-compressed key, uses that for the address, and it doesn't match?
667 2012-03-27 21:39:27 <sipa> if you sign with a compressed key, it won't be verifiable by 0.5, no
668 2012-03-27 21:39:28 <gmaxwell> ah! you're signing with a compressed key address.
669 2012-03-27 21:39:40 <luke-jr> sipa: by design, or oversight?
670 2012-03-27 21:39:42 <gmaxwell> sipa: How does it know which to use?
671 2012-03-27 21:39:52 <sipa> it sets a bit flag
672 2012-03-27 21:40:09 <gmaxwell> I totally missed that change. :(
673 2012-03-27 21:40:34 <sipa> luke-jr: actually, oversight, but it's not really possible anyway
674 2012-03-27 21:40:50 <sipa> i never thought about compatibility issues when i added then
675 2012-03-27 21:40:52 <sipa> that
676 2012-03-27 21:41:30 <luke-jr> bisect looks like it's about to confirm that's the case here
677 2012-03-27 21:41:39 <sipa> i can tell you which commit added that
678 2012-03-27 21:42:01 <luke-jr> sipa: btw, any reason not to support "long" sigs?
679 2012-03-27 21:42:33 <luke-jr> ie, base64(used-for-txn-sigs)
680 2012-03-27 21:42:59 <luke-jr> d4d9c734c315e99136fe245c5733ca75cab9f8bf is the first bad commit
681 2012-03-27 21:43:02 <luke-jr> Compact signatures with compressed pubkeys
682 2012-03-27 21:43:41 <sipa> there it is
683 2012-03-27 21:44:15 <sipa> all signatures are base64, no?
684 2012-03-27 21:44:34 <luke-jr> DER(pubkey+sig)
685 2012-03-27 21:44:36 <luke-jr> I mean
686 2012-03-27 21:45:02 <sipa> oh; what a waste
687 2012-03-27 21:45:44 <luke-jr> MtGox uses it for signmessage <.<
688 2012-03-27 21:45:55 <luke-jr> because they don't like the patent issue apparently
689 2012-03-27 21:46:08 <luke-jr> it would also have enabled workaround for this issue if it were in 0.5
690 2012-03-27 21:47:33 <gmaxwell> luke-jr: They're idiots. I offered to have a patent attorney go over it with them and declined.
691 2012-03-27 21:47:57 <luke-jr> gmaxwell: still, it turns out supporting it would have been a good idea for 0.5 :p
692 2012-03-27 21:48:56 <sipa> that wouldn't be hard
693 2012-03-27 21:49:42 <sipa> just add CKey::SetCompressed, and make verifymessage check for the bit, and call that function if it's set
694 2012-03-27 21:49:55 <luke-jr> gmaxwell: btw, can you do the final 0.5.4rc2 gitian build?
695 2012-03-27 21:50:09 <luke-jr> gmaxwell: note that you'll need to be sure to use the right qt input, or it'll come out wrong
696 2012-03-27 21:50:27 <sipa> BlueMatt: how far are we on getting qt builds deterministic?
697 2012-03-27 21:50:52 <BlueMatt> sipa: I havent bothered looking into it since bitcoin-qt is
698 2012-03-27 21:50:58 <luke-jr> sipa: they seem to be deterministic for me, but I had been using the 0.5.3.1-pre qt
699 2012-03-27 21:51:21 <luke-jr> with the final fix, that makes a subtle linking difference
700 2012-03-27 21:51:25 <luke-jr> (implicit vs explicit)
701 2012-03-27 21:51:27 <sipa> BlueMatt: bitcoin-qt is? gavin had a different build for 0.6.0rc5 than me
702 2012-03-27 21:51:35 <sipa> until he switched to the skypaint one
703 2012-03-27 21:51:50 <luke-jr> sipa: everyone needs to be sure to use the current/original qt gitian
704 2012-03-27 21:52:08 <sipa> did it change recently?
705 2012-03-27 21:52:10 <BlueMatt> sipa: oh...
706 2012-03-27 21:52:15 <BlueMatt> sipa: wait, the skypaint qt?
707 2012-03-27 21:52:23 <sipa> yes
708 2012-03-27 21:52:29 <BlueMatt> isnt that pre-fix? or did the fix move to bitcoin-qt.pro?
709 2012-03-27 21:52:53 <luke-jr> sipa: it changed for 0.6.0rc4, then changed back
710 2012-03-27 21:53:10 <sipa> i can't follow anymore
711 2012-03-27 21:53:14 <luke-jr> >_<
712 2012-03-27 21:53:22 <luke-jr> BlueMatt: pre-fix = current
713 2012-03-27 21:53:27 <luke-jr> fix is just in .pro now
714 2012-03-27 21:53:33 <BlueMatt> luke-jr: ok, thats right
715 2012-03-27 21:53:51 <sipa> so the skypaint qt build should be fine for building current?
716 2012-03-27 21:53:56 <luke-jr> sipa: yes
717 2012-03-27 21:54:13 <luke-jr> f09ab is the right input
718 2012-03-27 21:54:19 <sipa> ok, let me try to rebuild qt as it is now, and then redo 0.6.0rc5
719 2012-03-27 21:54:28 <sipa> to check whether it indeed is deterministic
720 2012-03-27 21:58:04 <sipa> where to download qt-everywhere?
721 2012-03-27 21:58:34 <BlueMatt> http://qt.nokia.com/downloads
722 2012-03-27 21:58:52 <sipa> couldn't find it there, but googling for the filename helped
723 2012-03-27 21:59:01 <sipa> http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.8.0.tar.gz
724 2012-03-27 21:59:10 <sipa> with 4.7.4 instead of 4.8.0
725 2012-03-27 21:59:21 <BlueMatt> cntl-f source
726 2012-03-27 21:59:52 <sipa> ah, missed that .tar.gz link
727 2012-03-27 21:59:54 <sipa> indeed
728 2012-03-27 22:01:10 <sipa> luke also had a different qt exe for 0.5.4rc2
729 2012-03-27 22:01:45 <BlueMatt> oh...then why did it work for 0.5.3.1...
730 2012-03-27 22:04:53 <luke-jr> sipa: https://github.com/luke-jr/bitcoin/compare/vfycompsig_0.5.0 look sane?
731 2012-03-27 22:05:17 <luke-jr> BlueMatt: ?
732 2012-03-27 22:05:59 <BlueMatt> luke-jr: the 0.5.3.1 exes were deterministic despite different qt's
733 2012-03-27 22:06:14 <luke-jr> BlueMatt: no, everyone who build 0.5.3.1 needed the same qt&
734 2012-03-27 22:06:24 <luke-jr> or else it wouldn't have been secure
735 2012-03-27 22:06:29 <BlueMatt> no, everyone built their own qt's
736 2012-03-27 22:06:42 <BlueMatt> but the exes all matched
737 2012-03-27 22:06:56 <sipa> luke-jr: looks good to me
738 2012-03-27 22:07:21 <luke-jr> can I get a few ACKs on the concept of backporting compressed-key verifysig to 0.5?
739 2012-03-27 22:08:17 <luke-jr> or at least someone who thinks it's a good idea? <.<
740 2012-03-27 22:09:09 <sipa> i'm not convinced about the necessity of 0.5.x backports - are there reasons why someone would not upgrade to 0.6?
741 2012-03-27 22:09:15 <BlueMatt> best way to phrase it: someone who dislikes the idea? ;)
742 2012-03-27 22:09:24 <BlueMatt> then youll get just as many responses and you can assume everyone agrees
743 2012-03-27 22:09:27 <sipa> (like, "i hate the Qt GUI", or "i hate forced fees", ...)
744 2012-03-27 22:09:53 <sipa> but if there is a backport, it sounds right to backport verify message signatures
745 2012-03-27 22:10:05 <luke-jr> sipa: because 0.6 is less tested
746 2012-03-27 22:10:39 <luke-jr> sipa: production environments that don't need the new features shouldn't have to upgrade to 0.6
747 2012-03-27 22:12:30 <gavinandresen> signing/verifying with compressed public keys is a new feature. If you need that new feature, you should upgrade to 0.6.
748 2012-03-27 22:18:29 <sipa> 02:00:03 < Mini_> hey guys, i'd like to donate to developers whos clients i use. i had no problem with armory and electrum, but i can't  find core development team donate address. can someone send me a link to donation page? I can't find it on bitcoin.org
749 2012-03-27 22:18:59 <BlueMatt> sipa: how many times has that question been answered?
750 2012-03-27 22:19:07 <BlueMatt> also, why does gavinandresen not put up a donation address ;)
751 2012-03-27 22:20:02 <BlueMatt> oh, sipa thats a good idea, make a p2sh address that it takes n/the core devs to sign...
752 2012-03-27 22:20:02 <gavinandresen> because I might get the lion's share of the donations and then I'd feel guilty and have to think about who deserves what.....
753 2012-03-27 22:21:32 <gavinandresen> If we can figure out some way of fairly distributing the donations to the people doing the work then I'd be all for having a p2sh donation address in the client, on the website, etc.
754 2012-03-27 22:22:36 <BlueMatt> I was thinking more along the lines of bitcoin-foundation purchases, but Im not sure what those actually would be...
755 2012-03-27 22:23:15 <luke-jr> BlueMatt: anything that encourages the non-fiat Bitcoin market?
756 2012-03-27 22:23:21 <luke-jr> maybe mining equipment :P
757 2012-03-27 22:23:35 <luke-jr> though those two are contradicting right now :/
758 2012-03-27 22:23:36 <BlueMatt> to be operated by who? and the profits go back to the same address?
759 2012-03-27 22:23:43 <luke-jr> BlueMatt: that's a good idea
760 2012-03-27 22:24:12 <BlueMatt> yay, devs get the biggest mining pool now
761 2012-03-27 22:24:17 <luke-jr> hehe
762 2012-03-27 22:24:27 <sipa> well we could have a page with a list of contributors, what they do/did, and an address
763 2012-03-27 22:24:33 <luke-jr> could always just hoard it to drive the price up, and only expense it when a dev has some kind of emergency
764 2012-03-27 22:24:39 <BlueMatt> sipa: yuck...
765 2012-03-27 22:24:49 <luke-jr> but that would be bad for my reputation cuz I have emergencies too often :/
766 2012-03-27 22:24:51 <BlueMatt> luke-jr: oh, Im outta cash, I need some...
767 2012-03-27 22:25:06 <BlueMatt> sipa: that gets way too complicated
768 2012-03-27 22:25:11 <BlueMatt> sipa: oh, their address
769 2012-03-27 22:25:11 <sipa> probably
770 2012-03-27 22:25:16 <BlueMatt> still, thats a bit complicated
771 2012-03-27 22:25:41 <luke-jr> we could just ask people to decide their "donation amount" is strictly for Bitcoin purchases, not cashing out ;)
772 2012-03-27 22:26:03 <BlueMatt> heh, yea
773 2012-03-27 22:26:05 <luke-jr> ie, "don't donate; spend it on bitcoin merchants!"
774 2012-03-27 22:27:22 <mod6> :)
775 2012-03-27 22:29:25 <gavinandresen> darn it, I thought I bookmarked an interesting programming team management website/service that let users decide how funds were split....
776 2012-03-27 22:31:16 <luke-jr> HumbleBumble.com ?
777 2012-03-27 22:31:38 <sipa> ?
778 2012-03-27 22:31:52 <sipa> that doesn't look right
779 2012-03-27 22:31:55 <BlueMatt> humblebundle?
780 2012-03-27 22:32:21 <luke-jr> http://www.humblebundle.com/ *
781 2012-03-27 22:32:23 <BlueMatt> if we got bitcoin in humblebundle (a gaming bundle)...
782 2012-03-27 22:32:29 <BlueMatt> well many bundles
783 2012-03-27 22:32:46 <copumpkin> MagicalTux said it might be coming soon
784 2012-03-27 22:32:46 <luke-jr> BlueMatt: I've mentioned a few times, it'd be nice if someone setup a Humble Bundle-alike using BitPay&
785 2012-03-27 22:32:52 <BlueMatt> average linux payment _always_ beats windows/mac...
786 2012-03-27 22:32:56 <luke-jr> and with only free games
787 2012-03-27 22:34:02 <Blitzboom> copumpkin: yeah? afaik they pussied out because POSSIBLY ILLEGAL
788 2012-03-27 22:34:37 <copumpkin> Blitzboom: last I heard they were waiting for mtgox's merchant services, which were just released recently, so I'm not sure
789 2012-03-27 22:34:41 <Blitzboom> further down there & http://bitcoinmedia.com/the-effs-own-chilling-breeze/
790 2012-03-27 22:34:59 <Diablo-D3> not this shit again.
791 2012-03-27 22:35:03 <Blitzboom> hmm, what was "last"?
792 2012-03-27 22:35:15 <Diablo-D3> and btw, if humble bundle does bitcoin, I will continue not to buy them.
793 2012-03-27 22:35:19 <MagicalTux> copumpkin: good idea, we'll remind them we now have stuff for them
794 2012-03-27 22:35:30 <copumpkin> lol
795 2012-03-27 22:35:30 <Diablo-D3> seriously, the last thing I need is detriments to my productivity
796 2012-03-27 22:35:51 <Diablo-D3> productivity is a detriment to my productivity, I swear to god
797 2012-03-27 22:37:16 <luke-jr> how about Armagetron, BZFlag, Freeciv, Frozen Bubble, Globulation 2, and Neverball ?
798 2012-03-27 22:37:31 <luke-jr> <.<
799 2012-03-27 22:37:41 <Diablo-D3> sucks, sucks, annoying as fuck, fun as a sdl perl demo, sucks, and sucks.
800 2012-03-27 22:39:49 <Diablo-D3> and throw in xonotic? guess what, all I'd be doing is buying my own code.
801 2012-03-27 22:43:30 <ternit> My client is stuck at 5% synchronising the blocks for last 20 min, usualy it rushes to at least 60% after fresh install, any idea how to speed it up?
802 2012-03-27 22:43:42 <Diablo-D3> ternit: leave it go.
803 2012-03-27 22:43:56 <Diablo-D3> if its still busted after like an hour, restart it
804 2012-03-27 22:44:05 <ternit> kk cheers
805 2012-03-27 22:44:14 <sipa> ternit: which version?
806 2012-03-27 22:44:20 <ternit> 5.3.1
807 2012-03-27 22:44:46 <Diablo-D3> btw, did 0.6.0 final ever come out?
808 2012-03-27 22:44:59 <BlueMatt> no
809 2012-03-27 22:45:02 <sipa> Diablo-D3: we're at rc5, if all goes well, 0.6.0 will be final in a few days
810 2012-03-27 22:45:13 <Diablo-D3> remind me to upgrade when that comes out
811 2012-03-27 22:45:39 <sipa> ternit: 0.6.0rc5 will be faster :)
812 2012-03-27 22:45:52 <ternit> wish i knew before i dled ;/
813 2012-03-27 22:45:55 <Diablo-D3> what sipa says is true
814 2012-03-27 22:46:03 <Diablo-D3> ternit: oh like it matters, its just a few megs
815 2012-03-27 22:46:10 <ternit> oh it moved im at 6%
816 2012-03-27 22:46:25 <ternit> 16%*
817 2012-03-27 22:47:00 <sipa> you won't lose the part of the blockchain that you've already downloaded if you restart
818 2012-03-27 22:47:19 <ternit> btw you guys got any jobs for a non programmer ? Guinea pigs for new clients testing or something in those lines?
819 2012-03-27 22:47:41 <Diablo-D3> ternit: someone was bitching about p2pool not having enough documentation, on the forums
820 2012-03-27 22:48:08 <Diablo-D3> so theres something you could go do
821 2012-03-27 22:48:28 <sipa> ternit: you're always welcome to run release candidates or git head, and report bugs
822 2012-03-27 22:49:10 <ternit> cheers
823 2012-03-27 22:49:22 <Diablo-D3> ternit: if you run from git, BACK UP YOUR WALLET.DAT FREQUENTLY