1 2013-06-21 02:25:57 <The_Fly> so many testnet blocks
  2 2013-06-21 02:26:13 <bloke> indeed
  3 2013-06-21 05:48:54 <Goonie_> petertodd: ping
  4 2013-06-21 05:51:50 <sipa> Goonie_: the encryption for key backups you use... it uses a single iteration of md5 strengthening, it seems...
  5 2013-06-21 05:53:19 <sipa> Goonie_: didn't check the java code, just what openssl enc does by default, though
  6 2013-06-21 05:55:15 <Goonie_> md5 for what exactly? actually it uses aes.
  7 2013-06-21 05:55:33 <sipa> to derive the key from the password
  8 2013-06-21 05:55:35 <Goonie_> Java code is in EncryptionUtils.java
  9 2013-06-21 05:55:39 <sipa> not for the encryption itself
 10 2013-06-21 05:56:10 <Goonie_> key derivation uses PKCS5
 11 2013-06-21 05:56:19 <Goonie_> 1024 iterations
 12 2013-06-21 05:57:37 <Goonie_> its in the method getAESPasswordKey()
 13 2013-06-21 05:58:37 <sipa> hmm, strange, maybe i misread, or openssl-encrypted files do it differently
 14 2013-06-21 05:58:59 <sipa> 1024 is still very low, but it's not nothing at least
 15 2013-06-21 05:59:35 <Goonie_> what command line are you using to decrypt?
 16 2013-06-21 06:00:05 <sipa> none, i just looked at the source code :)
 17 2013-06-21 06:00:20 <sipa> so i may have looked at thr wrong thing
 18 2013-06-21 06:00:27 <Goonie_> the source code of openssl?
 19 2013-06-21 06:00:30 <sipa> yes
 20 2013-06-21 06:00:58 <Goonie_> ok, I think Jim chose 1024 because that already takes some seconds on mobile devices
 21 2013-06-21 06:04:02 <Goonie_> unrelated: do you know the status of the testnet dns seeds?
 22 2013-06-21 06:04:05 <Goonie_> testnet-seed.bitcoin.petertodd.org is unresolvable
 23 2013-06-21 06:04:06 <Goonie_> and testnet-seed.bluematt.me refuses connection.
 24 2013-06-21 06:04:20 <Goonie_> BlueMatt: ping
 25 2013-06-21 06:04:45 <sipa> i think matt's had a problem that hr wouldn't fix immediately
 26 2013-06-21 06:05:16 <sipa> don't know about peter's
 27 2013-06-21 06:05:52 <Goonie_> hmm are there any alternatives?
 28 2013-06-21 06:06:39 <sipa> Goonie_: one common trick is make the number of iteratioms depend on your hardware (do a short benchmark rjn first, then continue based on how long the benchmark took), and store the number of kterations (unencrypted) in the file
 29 2013-06-21 06:07:16 <sipa> i know of no alternatoves
 30 2013-06-21 06:07:24 <gwillen> sipa: that's kind of self-defeating if you generate on your laptop and want to use the same key on your mobile device
 31 2013-06-21 06:07:35 <gwillen> mind you I don't think mobile devices are actually as crippled as all that
 32 2013-06-21 06:07:54 <gwillen> my keypass database takes 1s on my mbp, and only about 5s on my phone
 33 2013-06-21 06:08:12 <sipa> sure, there are downsides
 34 2013-06-21 06:08:33 <sipa> but at least it will scale automatically with technological progress
 35 2013-06-21 06:09:24 <gwillen> *nod*
 36 2013-06-21 06:09:27 <gwillen> that's the right way to do it, anyway
 37 2013-06-21 06:11:45 <Goonie_> I can imagine if the benchmark runs fails (e.g. because of a clock jump or maybe or another process stealing lots of cpu time for a second) the user ends up with "no encryption" at all.
 38 2013-06-21 06:12:30 <sipa> hmm, you don't store the iteration count in the file
 39 2013-06-21 06:12:45 <sipa> and you don't specify it on the commandline to decrypt using openssl
 40 2013-06-21 06:12:54 <sipa> how soes it know that number 1024?
 41 2013-06-21 06:13:49 <sipa> Goonie_: yeah, in bitcoin-qt iirc we jse a benchmark but use at least 100k iterations anyway
 42 2013-06-21 06:13:56 <sipa> use
 43 2013-06-21 06:19:20 <Goonie_> sipa: its probably a magic number?
 44 2013-06-21 06:19:47 <sipa> ok, could be hardcoded of course
 45 2013-06-21 06:20:00 <sipa> but since you said you chose it...
 46 2013-06-21 06:20:10 <gmaxwell> 01:09 < Goonie_> I can imagine if the benchmark runs fails (e.g. because of a clock jump or maybe or another process stealing lots of cpu time for a second) the user
 47 2013-06-21 06:20:32 <gmaxwell> there is a minimum of 25,000 iterations in the wallet encryption bitcoin uses.
 48 2013-06-21 06:21:01 <gmaxwell> (which was 100ms on the slowest test computer that was handy when the feature was created)
 49 2013-06-21 06:22:31 <Goonie_> for the records, there is a little bit of doc here, but it does not tell about num iterations:
 50 2013-06-21 06:22:32 <Goonie_> https://github.com/jim618/multibit/wiki/Export-and-limited-import-of-private-keys
 51 2013-06-21 06:25:10 <Goonie_> assuming that pkcs5 iteration count is 1, what would be the implications?
 52 2013-06-21 06:26:44 <TD> good morning
 53 2013-06-21 06:27:21 <Goonie_> but anyway, our code sets the number of iterations:
 54 2013-06-21 06:27:23 <Goonie_> \tprivate static CipherParameters getAESPasswordKey(final char[] password, final byte[] salt)
 55 2013-06-21 06:27:25 <Goonie_> \t{
 56 2013-06-21 06:27:27 <Goonie_> \t\tfinal PBEParametersGenerator generator = new OpenSSLPBEParametersGenerator();
 57 2013-06-21 06:27:30 <Goonie_> \t\tgenerator.init(PBEParametersGenerator.PKCS5PasswordToBytes(password), salt, NUMBER_OF_ITERATIONS);
 58 2013-06-21 06:27:33 <Goonie_> \t\tfinal ParametersWithIV key = (ParametersWithIV) generator.generateDerivedParameters(KEY_LENGTH, IV_LENGTH);
 59 2013-06-21 06:27:37 <Goonie_> \t\treturn key;
 60 2013-06-21 06:27:39 <Goonie_> \t}
 61 2013-06-21 06:27:42 <Goonie_> private static final int NUMBER_OF_ITERATIONS = 1024;
 62 2013-06-21 06:27:59 <Goonie_> private static final int KEY_LENGTH = 256;
 63 2013-06-21 06:28:06 <Goonie_> private static final int IV_LENGTH = 128;
 64 2013-06-21 06:28:34 <Goonie_> moin TD
 65 2013-06-21 06:28:34 <sipa> please don't copy paste more than 3 lines in IRC
 66 2013-06-21 06:29:40 <Goonie_> sipa: sorry, it did not appear to me that I was disturbing another conversation
 67 2013-06-21 06:30:25 <Tykling> Goonie_: you didn't, it's just common courtesy to use a pastebin :)
 68 2013-06-21 06:30:33 <duSn> gmaxwell: you are retarded and a fucking hypocrite - you clown LOL
 69 2013-06-21 06:30:41 <duSn> and a shitty programmer
 70 2013-06-21 06:30:46 <duSn> LOL
 71 2013-06-21 06:32:15 <Tykling> wth just happened
 72 2013-06-21 06:32:34 <gwillen> it's not clear
 73 2013-06-21 06:32:39 <Tykling> :)
 74 2013-06-21 06:33:21 <sipa> Goonie_: irc clients rate-limit how quickly tjey send messages (typically a burst of 3 and then one per second), so even if there is nothing going on, it is very annoying to see a message appear over 10s time, and ignore whatever is being said in the mean time
 75 2013-06-21 06:33:35 <sipa> alsp it screws up logs for people who aren't interested
 76 2013-06-21 06:33:56 <sipa> anywau, just checked openssl source code again... i don't see thag 1024 constant anywhere
 77 2013-06-21 06:34:14 <sipa> so i really wonder how that decryption is possible
 78 2013-06-21 06:35:12 <gwillen> sipa: erm, what am I missing? The constant is in the code Goonie pasted, that calls openssl
 79 2013-06-21 06:35:22 <gwillen> sipa: unless there's some other code that also has to compatibly generate the same key
 80 2013-06-21 06:35:36 <sipa> gwillen: openssl commandline tool
 81 2013-06-21 06:35:54 <sipa> is claimed to support decrypting the key backups
 82 2013-06-21 06:36:18 <Goonie_> you can use
 83 2013-06-21 06:36:20 <Goonie_> openssl enc -d -aes-256-cbc -a -in <filename>
 84 2013-06-21 06:36:22 <Goonie_> to decrypt the backup.
 85 2013-06-21 06:36:39 <Goonie_> It asks for the password of course.
 86 2013-06-21 06:37:00 <sipa> yes, my question is how does ot know the number of iterations
 87 2013-06-21 06:37:12 <sipa> afaics, jt uses iteration count = 1
 88 2013-06-21 06:37:27 <gwillen> that does seem troubling
 89 2013-06-21 06:37:35 <sipa> though i haven't tried
 90 2013-06-21 06:37:58 <sipa> and maybe i should shit up until i either know it works or doesn't
 91 2013-06-21 06:38:02 <sipa> eh
 92 2013-06-21 06:38:03 <sipa> shut up
 93 2013-06-21 06:38:10 <sipa> :$
 94 2013-06-21 06:38:46 <TD> smirk
 95 2013-06-21 06:40:54 <Goonie_> hmm openssl dec -v does not print the number of iterations )-:
 96 2013-06-21 06:41:05 <Goonie_> sipa: did you see in the source any way to debug this?
 97 2013-06-21 06:41:52 <sipa> it just passed 1 as a constant to EVP_BytesToKey... no way afaics to change the iteration count
 98 2013-06-21 06:42:14 <gwillen> there's a patch from Feb that lets you change it: http://openssl.6102.n7.nabble.com/openssl-org-2995-PATCH-Added-ability-to-set-the-iteration-count-for-the-enc-function-of-the-openssl--td43916.html
 99 2013-06-21 06:42:25 <TD> crypto is hard, eh
100 2013-06-21 06:42:29 <gwillen> dunno if it's made it into anything yet
101 2013-06-21 06:42:38 <sipa> i doubt it will
102 2013-06-21 06:42:48 <sipa> the EVP family of functioms are marked deprecated
103 2013-06-21 06:42:57 <sipa> they're only kept for compatibility
104 2013-06-21 06:43:15 <TD> they are?
105 2013-06-21 06:43:33 <TD> doh. i used them in the payment protocol code, and gavin based his code on mine. so they're still there
106 2013-06-21 06:43:45 <sipa> they're also known to be incompatible with with modern standards
107 2013-06-21 06:43:49 <TD> i don't recall seeing anything about deprecation in the docs. openssl--
108 2013-06-21 06:43:58 <gwillen> ahahahahahahahahhahahahahahah
109 2013-06-21 06:44:03 <gwillen> ahahahahahahahhahahaha
110 2013-06-21 06:44:06 <gwillen> http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/crypto/generators/OpenSSLPBEParametersGenerator.html
111 2013-06-21 06:44:07 <sipa> let me check then before i say more nonsense
112 2013-06-21 06:44:17 <gwillen> "Initialise - note the iteration count for this algorithm is fixed at 1."
113 2013-06-21 06:44:22 <gwillen> it is ignoring your iteration count
114 2013-06-21 06:44:23 <gwillen> because it sucks
115 2013-06-21 06:44:44 <gwillen> (silently, I might add)
116 2013-06-21 06:44:45 <Goonie_> hmmm nice
117 2013-06-21 06:44:52 <gwillen> nice catch, sipa
118 2013-06-21 06:44:53 <TD> bouncy castle--
119 2013-06-21 06:45:04 <TD> i'd like to junk it at some point
120 2013-06-21 06:45:11 <Goonie_> ok what is the implication of this?
121 2013-06-21 06:45:35 <gwillen> let me note that it's 2 AM and I'm punchy, and I am totally unqualified to judge BouncyCastle, and it very likely does not actually suck, but just happens to have a single misfeature.
122 2013-06-21 06:46:07 <sipa> it's not a misfeature
123 2013-06-21 06:46:14 <gwillen> Goonie_: well, 1024 was not (as sipa pointed out) very many iterations to begin with. So the implication is that, if a user has a weak password, and an aversary gets their hands on the file, that they can crack the password; but this was probably already the case anyway.
124 2013-06-21 06:46:14 <sipa> it is being compatible with openssl
125 2013-06-21 06:46:19 <TD> it is. it should assert if you try and pass anything other than 1 for the parameter
126 2013-06-21 06:46:28 <sipa> right
127 2013-06-21 06:46:32 <sipa> agree, TD
128 2013-06-21 06:46:50 <gwillen> well, and also, now there's a patch for openssl to support an iteration count, but who knows if or when BC will pick that up
129 2013-06-21 06:47:00 <TD> bouncy castle is poorly documented, slow, and generally like most other crypto libraries i'm familiar with (i.e. not excellent). that said, it does at least exist and have all the needed features.
130 2013-06-21 06:47:07 <gwillen> if they didn't ignore the parameter, at least it would fail loudly instead of silently
131 2013-06-21 06:47:32 <TD> not that i can really preach. bitcoinj tries to avoid obvious sharp edges like that but i'm sure there are still plenty.
132 2013-06-21 06:47:36 <TD> in fact i know there are
133 2013-06-21 06:47:41 <gwillen> (of course, it would be confusing as hell, because people would expect the parameter to be encoded in the output, which it's not.)
134 2013-06-21 06:47:57 <TD> this is for the custom key export code that jim wrote, i guess?
135 2013-06-21 06:48:02 <sipa> Goonie_: no way i'd support adding that encryption to key export/import in the reference client, though...
136 2013-06-21 06:48:22 <Goonie_> TD: yes
137 2013-06-21 06:48:53 <Goonie_> sipa: agree
138 2013-06-21 06:48:58 <TD> i realize there's a desire to be able to use openssl from the command line, but that's a pretty nerdy feature imo. it'd be better to just export a regular encrypted wallet.
139 2013-06-21 06:49:04 <TD> that way at least we get more review of the code.
140 2013-06-21 06:49:30 <Goonie_> sipa: if the reference client allows importing backup files, the need for openssl compatibility is mostly gone
141 2013-06-21 06:49:46 <Goonie_> sipa: so we can change to just about anything
142 2013-06-21 06:49:50 <sipa> Goonie_: ok, good
143 2013-06-21 06:50:13 <Goonie_> sipa: however, jim should join the conversation
144 2013-06-21 06:50:44 <sipa> TD: it's just EVP_BytesToKey that is "deprecated"; the man page says you need to use more standard algorithms in future code, but gives no clye how to do that programatically
145 2013-06-21 06:50:50 <TD> oh
146 2013-06-21 06:50:51 <sipa> Goonie_: agree, and no hirry
147 2013-06-21 06:51:04 <TD> ok, then i misunderstood. openssl++ back to normal :)
148 2013-06-21 06:53:00 <sipa> Goonie_: while we're at, i wonder if it wouldn't make senae to just add the transactions + merkle path too to the format, so you don't need rescanning...
149 2013-06-21 06:54:12 <Goonie_> sipa: and perhaps HD-wallets?
150 2013-06-21 06:55:10 <sipa> yes, that'd just mean some extended prjvate keys
151 2013-06-21 06:55:48 <Goonie_> hmm, and some info about the structure of the wallet? perhaps counts how many keys have been derived from its "parent"?
152 2013-06-21 06:56:18 <Goonie_> (I'm not sure if every wallet will follow the proposed "standard structure")
153 2013-06-21 06:56:34 <sipa> i think we need a functioning hd-wallet implementation before we know for sure what is needed
154 2013-06-21 06:56:45 <Goonie_> sipa: agree
155 2013-06-21 06:57:05 <TD> merkle branches in a wallet backup?
156 2013-06-21 06:57:11 <TD> why? you think users are going to load untrusted wallets?
157 2013-06-21 06:57:39 <sipa> good point
158 2013-06-21 06:57:54 <sipa> at least the block hash those transactions are known to be part of
159 2013-06-21 06:58:06 <TD> bitcoinj does not currently store merkle branches for transactions. it does store block hashes because those are needed for re-orgs
160 2013-06-21 06:58:21 <sipa> ok, agree that is enough
161 2013-06-21 07:02:45 <sipa> TD: btw, what about using privkey@unixtimestamp to serialize privkeys with a known birth time?
162 2013-06-21 07:03:08 <TD> why introduce a new syntax?
163 2013-06-21 07:03:26 <sipa> what would you do?
164 2013-06-21 07:04:36 <sipa> amend the key format to include it? people still haven't picked up the "extension" to support the compressed flag
165 2013-06-21 07:04:36 <TD> probably try and design a file format that contains structured data.
166 2013-06-21 07:04:42 <TD> it's not like keys are human readable anyway :)
167 2013-06-21 07:04:47 <TD> hmm, i did
168 2013-06-21 07:04:54 <sipa> thankfully!
169 2013-06-21 07:04:54 <TD> bitcoinj can import compressed privkeys as exported by bitcoind
170 2013-06-21 07:04:59 <sipa> i know
171 2013-06-21 07:05:05 <sipa> wasn't talking about you
172 2013-06-21 07:05:33 <sipa> bip32 defines a serialization format from the start, so hopefully people will pick that one up
173 2013-06-21 07:05:52 <sipa> but i still feel that birth data is not the key itself but key metadata
174 2013-06-21 07:06:23 <sipa> and yes, we should a for wallet interchange, not key interchange
175 2013-06-21 07:06:28 <sipa> *aim
176 2013-06-21 07:11:00 <Goonie_> sipa: +1 wallet interchange
177 2013-06-21 07:12:31 <Goonie_> however, importing wallets rather than keys implies that your client can handle multiple wallets. to my knowledge, the only client capable of doing this is multibit.
178 2013-06-21 07:12:47 <sipa> still doesn't mean i think a common wallet format is feasible
179 2013-06-21 07:12:58 <sipa> but a common wallet interchange format may be
180 2013-06-21 07:13:21 <sipa> Goonie_: i hope we can get that soon in the ref client
181 2013-06-21 07:22:42 <grau> sipa: I just added "slave" configuration option to Bits of Proof. If you start with that option, it connects to trusted bitcoind's and skips verification. It builds its own indexed db and serves wallets.
182 2013-06-21 07:23:41 <grau> was only a few lines...
183 2013-06-21 07:23:52 <sipa> cool!
184 2013-06-21 07:24:57 <grau> I am testing for a while now and will announce it as a feature in 1.1. Thanks for the idea.
185 2013-06-21 07:27:45 <grau> sipa: Birth would be really useful part of the serialization of BIP32. But we had that discussion before. I think all wallets will have that for optimization and it would be rather meaningful to export/import keys too.
186 2013-06-21 07:28:15 <sipa> it's not necessarily something you need per-key either
187 2013-06-21 07:28:36 <sipa> in deterministic wallet, a birth timestamp per master may be enough, for example
188 2013-06-21 07:28:45 <sipa> depending on how derivation works
189 2013-06-21 07:28:58 <grau> It is the most likely use. And there is no extra serialization for master
190 2013-06-21 07:29:09 <sipa> or if you're serializing a wallet with transactions in it, you only really care about the time up to which you are synced
191 2013-06-21 07:30:15 <grau> I really like read-only wallets. That is transactions are not stored. They can be retreived if there is an indexing server and birth date.
192 2013-06-21 07:30:59 <sipa> grau: that's how your software works, and maybe that is what the future looks like
193 2013-06-21 07:31:19 <sipa> grau: but i dislike the idea that you'd need access to a fully indexed blockchain to use a wallet
194 2013-06-21 07:32:17 <sipa> for large-scale operations where many wallet users trust the same indexing server, it's likely the better solution
195 2013-06-21 07:32:20 <grau> You either have indexed blockchain or a wallet that is in fact a small blockchain, since it has to be reorged
196 2013-06-21 07:33:16 <sipa> s/small blockhain/block headers in SPV mode/
197 2013-06-21 07:33:28 <sipa> but yes, there is a degree of duplication, as discussed before
198 2013-06-21 07:33:43 <sipa> but that's what makes bitcoin decentralized: everyone keeping their own idea of what the current state is
199 2013-06-21 07:33:47 <grau> I agree there is not a single right solution here. Read only wallet with indexed blockchain is good for a mobile. An exchange likely rather wants a wallet storing transactions.
200 2013-06-21 07:34:00 <sipa> SPV wallets work great on mobile too :p
201 2013-06-21 07:34:53 <sipa> it's just different approaches, and it all depends on the circumstances
202 2013-06-21 07:34:57 <grau> Most people are not patient enough to use an SPV mobile
203 2013-06-21 07:35:27 <sipa> patient?
204 2013-06-21 07:35:38 <sipa> it syncs faster than i can type an amount i want to send...
205 2013-06-21 07:36:23 <sipa> and if inconvenience is the cost of decentralization, then we need technical solutions to improve that
206 2013-06-21 07:36:28 <sipa> not just drop decentralization
207 2013-06-21 07:36:30 <grau> Even if it needs to discover peers first?
208 2013-06-21 07:37:39 <sipa> never been a problem here
209 2013-06-21 07:37:56 <sipa> but sure, there are downsides, that's inevitable
210 2013-06-21 07:38:10 <sipa> decentralized systems are inevitably less efficient than centralized ones
211 2013-06-21 07:38:16 <grau> I have limited experience, admittedly. I tried Bitcoin Wallet using SPV once months ago and it was quite slow.
212 2013-06-21 07:38:40 <sipa> before version 3?
213 2013-06-21 07:38:49 <grau> dunno
214 2013-06-21 07:39:05 <sipa> the sync speed difference is night and day
215 2013-06-21 07:39:18 <grau> Will give it an other try.
216 2013-06-21 07:39:24 <sipa> anyway, i think "it's inconvenient" is a bad reason to promote a centralized solutions
217 2013-06-21 07:39:39 <sipa> there are others, like cases where there is already an implicit trust in the indexing server
218 2013-06-21 07:40:11 <grau> There is another issue: SPV is good for payments but has no features for e.g. transaction history or importing a private key.
219 2013-06-21 07:40:26 <sipa> you shouldn't need to import a private key
220 2013-06-21 07:40:28 <grau> These are also features people would like to have on a wallet.
221 2013-06-21 07:40:43 <sipa> you should move wallets, not keys
222 2013-06-21 07:40:58 <grau> I thnk there is a valid use case for paper bitcoins that you want to import to wallet as you need them online
223 2013-06-21 07:41:27 <sipa> i don't think that's scalable in a decentralized setting
224 2013-06-21 07:41:40 <sipa> but we'll see what the future brings i guess
225 2013-06-21 07:41:54 <Goonie_> +0.5 for a sweep keys feature in spv clients
226 2013-06-21 07:41:55 <grau> what is not scaleable ?
227 2013-06-21 07:42:12 <sipa> grau: needing access to a trusted fully-indexed blockchain
228 2013-06-21 07:42:31 <sipa> except if committed UTXO trees get implemented
229 2013-06-21 07:42:42 <sipa> and that's still only for balances, not for history
230 2013-06-21 07:42:50 <grau> then that is the way to go.
231 2013-06-21 07:43:10 <sipa> it has significant impact on verification load, though
232 2013-06-21 07:44:06 <sipa> Goonie_: i'd love "sweep coin", where you import a privkey + transaction crediting it + merkle tree
233 2013-06-21 07:44:26 <sipa> Goonie_: sweep privkey... would be nice, but harder
234 2013-06-21 07:45:06 <Goonie_> sipa: true. i assume it wouldn't fit into a qr code?
235 2013-06-21 07:45:23 <sipa> Goonie_: i'm pretty sure it would, but it'd be a larger one
236 2013-06-21 07:45:35 <sipa> i think you can get up to a few kilobytes in one
237 2013-06-21 07:46:17 <Goonie_> sipa: I tried once, I think everything above 2k was very hard to scan and the maximum is something above 3k.
238 2013-06-21 07:46:18 <grau> sipa: doesnt sweep key just mean: fetch all output accessible for that key, create and broadcast a transaction transfer to one of your own key?
239 2013-06-21 07:46:26 <sipa> grau: ys
240 2013-06-21 07:46:53 <sipa> grau: yes, which means at least an address-indexed UTXO set (which is far easier than an address-indexed blockchain, but still... hopefully unnecessary)
241 2013-06-21 07:47:13 <sipa> grau: bitcoin's strength is the fact that you don't need to trust anyone to handle your money
242 2013-06-21 07:47:42 <sipa> grau: doesn't mean that you can't trust others... i also have some coins on a web service because the convenience worth more to me than the risk
243 2013-06-21 07:48:11 <grau> but it needs protocol extension to query UTXO
244 2013-06-21 07:48:13 <sipa> grau: but if we're going to build an infrastructure that depends on trusted services to exist, i think we're on the wrong path
245 2013-06-21 07:48:37 <sipa> you can't do an authenticated UTXO query today
246 2013-06-21 07:48:43 <sipa> not without committed UTXO trees
247 2013-06-21 07:49:19 <grau> that is what I mean. You say we should not use trusted servers. I say at the moment no other choice.
248 2013-06-21 07:49:33 <grau> If you want these features
249 2013-06-21 07:49:49 <sipa> maybe we should build high-level solutions that don't require such features
250 2013-06-21 07:50:30 <grau> How would they solve key sweep?
251 2013-06-21 07:50:51 <sipa> a "key" to sweep would contain the transaction being sweeped with it
252 2013-06-21 07:51:21 <sipa> key sweep isn't a feature; it's a means to accomplish for example offline tokens representing coins
253 2013-06-21 07:51:41 <melvster> you can have trust, but it doesnt have to be black and white, you dont need 100% trust, but some servers can be *slightly* more trustworthy than others
254 2013-06-21 07:52:21 <sipa> melvster: i think you misunderstand trust - it's about being able to choose who you trust
255 2013-06-21 07:52:35 <sipa> and if you choose to trust nobody, then the system shouldn't break
256 2013-06-21 07:52:39 <melvster> there are many trust and reputation systems that are an improvement on the neutral 'one size fits all'
257 2013-06-21 07:52:42 <sipa> though you may lose some convenience
258 2013-06-21 07:52:50 <grau> so the offline token is not just the key but the UTXO commanded by the key? How do you ensure that UTXO set is complete?
259 2013-06-21 07:52:59 <melvster> sipa: you're confusing trust and reputation
260 2013-06-21 07:53:03 <sipa> melvster: no
261 2013-06-21 07:53:16 <sipa> melvster: reputation is a way to know who you can trust
262 2013-06-21 07:53:39 <sipa> grau: a merkle tree for the transaction
263 2013-06-21 07:54:21 <sipa> grau: and if your argument is "that doesn't prove the coin isn't spent yet!", you're right, but if that is a worry, you shouldn't be importing keys in the first place, since the person giving it to you could just spend it from under you
264 2013-06-21 07:54:37 <melvster> sipa: look at it this way, reputation is observable data points, trust is a calculation .... you can always choose who you trust, and you may choose to trust all people equally, that's fine, we have the system as it is today ... but prohibiting trust it is unclear that is beneficial
265 2013-06-21 07:55:06 <sipa> melvster: no need to prohibit trust; but bitcoin is built on not _needing_ to trust anyone
266 2013-06-21 07:55:29 <sipa> if you do have trust (for whatever reason, reputation being one), more efficient solutions are possible
267 2013-06-21 07:55:34 <sipa> for example off-chain transactions
268 2013-06-21 07:56:01 <melvster> sipa: sure ... you distribute trust away from a TTP, to many nodes ... that's robust ... but there's many algorithms that give good trust intervals, e.g. the ELO ratings in chess
269 2013-06-21 07:56:17 <melvster> TTP = Trusted Third Party
270 2013-06-21 07:56:20 <sipa> melvster: i don't have time for this discussion now