1 2014-03-05 00:01:03 <alex_fun> hello, I saw there is QR facility in wallet, so how i can pay someone if I got their QR code?
2 2014-03-05 00:01:11 <alex_fun> can qt somehow scan it?
3 2014-03-05 00:01:54 <gmaxwell> Persopolis: we would prefer someone not be able to identify which node a transaction originated from. If you have many nodes observing the network and watch timing, and transactions are frequent you can use traffic analysis to make reasonable guesses. I don't think there is anything especially weird about it.
4 2014-03-05 00:02:10 <gmaxwell> It's similar, though not quite the same as the traffic analysis attacks you get in tor from controlling the entrance nodes.
5 2014-03-05 00:02:56 <alex_fun> yes tor have been analyses via such tech imo
6 2014-03-05 00:03:02 <HaltingState> sipa, if a person has n*G where G is the base point, and they know n, can they compute the inverse of n*G for addition operator in curve
7 2014-03-05 00:03:16 <Persopolis> gmaxwell: so rotating should in theory help?
8 2014-03-05 00:03:24 <HaltingState> can you get inverse of n*G without knowing n?
9 2014-03-05 00:04:01 <HaltingState> inverse for addition is easy, but inverse for n times addition is intractable without n?
10 2014-03-05 00:05:18 <sipa> HaltingState: correct
11 2014-03-05 00:06:30 <HaltingState> oh, so if they know n*G, then they compute additive inverse of G and then do addition addition on it n times
12 2014-03-05 00:06:32 <gmaxwell> Persopolis: no, rotating increases your chance of being discovered eventually to 100% under most parameter sets in that model.
13 2014-03-05 00:06:37 <HaltingState> ok, this makes sense now
14 2014-03-05 00:06:56 <gmaxwell> Persopolis: while just using a constant set makes your risk the same as your initial risk (some constant factor on the number of attacker controlled nodes)
15 2014-03-05 00:07:05 <sipa> HaltingState: i don't understand what you're talking about; the group operation doesn't really come into play ever
16 2014-03-05 00:07:21 <HaltingState> sipa, addition is the group operator?
17 2014-03-05 00:07:24 <sipa> yes
18 2014-03-05 00:08:24 <HaltingState> you need inverse operator for addition, to apply to the base point
19 2014-03-05 00:08:32 <sipa> heh?
20 2014-03-05 00:09:04 <Persopolis> gmaxwell: understood
21 2014-03-05 00:09:56 <alex_fun> sipa have u ever managed to compiled pkg config on windows to install qr libraries for QT? :)
22 2014-03-05 00:10:10 <sipa> alex_fun: i haven't used windows in 15 years
23 2014-03-05 00:10:16 <alex_fun> sipa lol oki
24 2014-03-05 00:10:39 <alex_fun> Persopolis: are u trying to futher anon coins use?
25 2014-03-05 00:10:56 <alex_fun> that zero coin solution seems kinda complex
26 2014-03-05 00:11:44 <Persopolis> alex_fun: no we were just discussing connection strategey for bitcoind
27 2014-03-05 00:12:01 <alex_fun> oki
28 2014-03-05 00:12:14 <sipa> HaltingState: i don't understand where the inverse operation comes into play
29 2014-03-05 00:12:22 <alex_fun> I so far learn how initial diff set and how its works abit
30 2014-03-05 00:12:28 <sipa> HaltingState: it's used in practice to optimize the multiplication a bit
31 2014-03-05 00:12:33 <alex_fun> as to how make transactions anon yet to see :)
32 2014-03-05 00:13:05 <sipa> HaltingState: but semantically it's not really needed
33 2014-03-05 00:14:18 <alex_fun> maybe someone here came across this error GLib must be build with -march=i486 or later. when trying to add qr lib for WIN QT, on OSX it works fine :)
34 2014-03-05 00:14:53 <alex_fun> sipa: btw osx wallet came out to be easy, once I used macdeploy :)
35 2014-03-05 00:15:16 <sipa> i have no idea what you're even trying to do
36 2014-03-05 00:15:20 <sipa> or talking about
37 2014-03-05 00:15:27 <HaltingState> sipa, i am trying to figure out what information each person has and what they can derive from that information so addition comes into play a little bit
38 2014-03-05 00:15:59 <sipa> HaltingState: you have a and B, i have A and b
39 2014-03-05 00:16:09 <sipa> where A = a*G and B = b*G
40 2014-03-05 00:16:24 <sipa> so both can compute a*B = b*A = a*b*G
41 2014-03-05 00:16:40 <HaltingState> but what if you dont have my pubkey
42 2014-03-05 00:16:47 <sipa> i always do
43 2014-03-05 00:16:51 <HaltingState> i have to send my pubkey with the message
44 2014-03-05 00:16:52 <sipa> you can't do ECDH otherwise
45 2014-03-05 00:16:59 <sipa> yes?
46 2014-03-05 00:17:14 <sipa> so in that case, one of the keys is the actual receiver's pubkey
47 2014-03-05 00:17:20 <sipa> the other is an ephemeral key
48 2014-03-05 00:17:29 <sipa> created by the sender, just for this message
49 2014-03-05 00:17:36 <HaltingState> so my pubkey is in plaintext, so i should generate new random pubkey for first part until session key is setup for symmetric encryption
50 2014-03-05 00:17:50 <sipa> so i want to send an encrypted message to you
51 2014-03-05 00:17:58 <sipa> i have you public key P = p*G
52 2014-03-05 00:18:12 <sipa> i generate an ephemeral key E = e*G
53 2014-03-05 00:18:38 <sipa> and compute H(e*P), and send (E,enc(key=H(e*P),msg))
54 2014-03-05 00:19:09 <sipa> the receiver than has p and E, so can compute p*E = p*e*G = e*p*G = e*P, and the hash thereof
55 2014-03-05 00:19:15 <sipa> and can thus decrypt the message
56 2014-03-05 00:22:50 <keyboard> is that el gamal?
57 2014-03-05 00:24:16 <sipa> almost
58 2014-03-05 00:24:40 <sipa> el gamal uses the shared secret directly and multiplies it with the message, which put very strict constraints on the message
59 2014-03-05 00:24:53 <sipa> sorry, adds to
60 2014-03-05 00:25:15 <sipa> first hashing it and using that as key for a symmetric encryption algorithm is almost always better
61 2014-03-05 00:29:14 <Persopolis> ACTION bids you good night
62 2014-03-05 00:32:51 <HaltingState> sipa, if someone cracks the ephemeral key E, they can recover e, but without knowing P or p, they still cant recover the symmetric key?
63 2014-03-05 00:33:21 <sipa> recovering either e or p is enough
64 2014-03-05 00:33:32 <sipa> as E and P are public
65 2014-03-05 00:33:38 <HaltingState> but if P is not public
66 2014-03-05 00:33:50 <sipa> at least the sender knows P
67 2014-03-05 00:33:55 <sipa> you must assume the attacker does too
68 2014-03-05 00:34:09 <sipa> otherwise, you could just use P as key
69 2014-03-05 00:34:37 <HaltingState> if the attacker is only reading the packet stream, they can get E, and crack E to get e, but without knowing p or P (which are not sent in packet) they cant decrypt it; so they have to get p/P (somehow)
70 2014-03-05 00:34:54 <sipa> you arguing beside the point
71 2014-03-05 00:35:09 <sipa> if your attack model is an attacker who doesn't know P, then you should be using P as key
72 2014-03-05 00:35:46 <sipa> in every other case, you must assume the attacker knows E and P
73 2014-03-05 00:35:51 <sipa> and that's fine
74 2014-03-05 00:36:04 <sipa> the security is based on not being able to recover e or p from those
75 2014-03-05 00:36:14 <sipa> which requires solving the ECDLP problem
76 2014-03-05 01:03:26 <HaltingState> sipa, does djb have any opinions on the koblitz curves? is he using them for nacl?
77 2014-03-05 01:04:16 <gmaxwell> djb has his own pet curve whos implementation gets performance in other ways.
78 2014-03-05 01:04:34 <HaltingState> is he critical of the NIST curves?
79 2014-03-05 01:04:41 <gmaxwell> sure, who isn't?
80 2014-03-05 01:04:49 <gmaxwell> (good thing we don't use one)
81 2014-03-05 01:05:19 <HaltingState> i was screaming at telehash/xmpp guy for using the r1 curve and he thought it was the "secure" one, with those hidden parameters
82 2014-03-05 01:05:31 <gmaxwell> he's whined about the rho speedup that endomorphism in our curve gives.. about a 1.5 bit reduction in security, but then his own preferred curve of this size is several bits weaker rho security wise to begin with.
83 2014-03-05 01:05:33 <HaltingState> curves with "random" parameters are safer, suppodely, lol
84 2014-03-05 01:05:55 <HaltingState> is the secp256k1 curve in prime field or what is the order of the field?
85 2014-03-05 01:06:15 <gmaxwell> it's a prime field.
86 2014-03-05 01:06:36 <gmaxwell> (DJB's own preferred curve has a cofactor which is a bit boggling)
87 2014-03-05 01:07:23 <jcorgan> ACTION is just happy i can finally follow this conversation and have a reasonable understanding of what you're talking about :)
88 2014-03-05 01:09:11 <HaltingState> gmaxwell, there was graduate student with some paper on parameters for ecc curves and potential insecure if some polynomial held, but only held for very specificly constructed curves and he wasnt allowed to publish paper or something
89 2014-03-05 01:09:19 <HaltingState> and no one will tell me exactly what was in paper
90 2014-03-05 01:09:39 <gmaxwell> ACTION expresses skepticism
91 2014-03-05 01:11:42 <HaltingState> gmaxwell, non-prime field ECC
92 2014-03-05 01:12:53 <gmaxwell> ah, well my skepticism is independant of that, but yea, I really would be hard pressed to use a non-prime field.
93 2014-03-05 01:13:20 <gmaxwell> though I'm not aware of any reason why DJB's cofactor of 8 would itself break anything.
94 2014-03-05 01:15:35 <HaltingState> something with koblitz curves
95 2014-03-05 01:15:59 <HaltingState> http://crypto.stackexchange.com/a/2882
96 2014-03-05 01:16:22 <gmaxwell> the word koblitz is usless.
97 2014-03-05 01:16:38 <gmaxwell> what is commonly called koblitz is not the curve we use.
98 2014-03-05 01:16:55 <gmaxwell> most things called koblitz are implemented over a binary field, which I wouldn't touch with a 5 foot pole.
99 2014-03-05 01:17:19 <gmaxwell> our curve has a cofactor of 1.
100 2014-03-05 01:20:27 <HaltingState> i remember in undergraduate doing index calculus algorithm and remember something value about groups with order divisible by small primes being weak. but wiki says the attack doesnt work for ecc
101 2014-03-05 01:34:59 <sipa> gmaxwell: why wouldn't you use curves over a binary field?
102 2014-03-05 01:46:49 <gmaxwell> sipa: there a bunch of transfer like attack progress for characteristic-2 fields, not enough to break anything. None of these techniques look applicable to large characteristic (though they could be applied to any small characteristic like 2 or 3)
103 2014-03-05 01:49:10 <gmaxwell> (and the other reason I would generally avoid characteristic 2 is that there are a whole lot of patents around it.. like seas of patents that look like "do obvious thing in a field with characteristic-2")
104 2014-03-05 02:24:18 <Belxjander> maybe a completely dumb question...but what are the PoW scripting limitations for transactions?
105 2014-03-05 02:24:45 <Belxjander> can you specify for within a set time the transaction then initiates a reversal transaction ?
106 2014-03-05 03:52:54 <lnovy> !seen bd_
107 2014-03-05 03:52:55 <gribble> bd_ was last seen in #bitcoin-dev 1 year, 18 weeks, 2 days, 18 hours, 22 minutes, and 31 seconds ago: <bd_> when most of the data is pseudorandom keys and signatures, compression doesn't make much difference. on-disk, of course, there's index data and stuff too though
108 2014-03-05 03:53:11 <lnovy> !seen bd__
109 2014-03-05 03:53:12 <gribble> bd__ was last seen in #bitcoin-dev 2 years, 3 weeks, 1 day, 18 hours, 21 minutes, and 25 seconds ago: <bd__> and/or those inputs can be internal wallet keys that are used only for splits
110 2014-03-05 03:53:17 <lnovy> hmm
111 2014-03-05 04:00:38 <jcorgan> what's the recommend method for doing RPC with bitcoind from Python these days? I've turned up bitcoin-python from wlaanj, python-bitcoinrpc from jgarzik, and of course using raw python-jsonrpc. Is it a matter of taste or is there a clear preference one way or the other?
112 2014-03-05 04:05:35 <jgarzik> jcorgan, no one holy grail official way. python-bitcoinrpc is generally recommended, but some python3 people complain about it. python-bitcoinlib, the more general and larger lib, includes it also.
113 2014-03-05 04:06:16 <jcorgan> great, thanks
114 2014-03-05 04:26:09 <Tril> git master doc/build-unix.md wrong? "--with-miniupnpc No UPnP support miniupnp not required"
115 2014-03-05 04:28:24 <Tril> should probably say --without-miniupnpc
116 2014-03-05 04:45:13 <sugarpuff> i don't get the disk space problem. someone want to help? https://bitcointalk.org/index.php?topic=501039.0
117 2014-03-05 04:49:53 <maaku> jcorgan: it doesn't really matter so long as you are using decimal values for interpretation of amount values
118 2014-03-05 04:50:15 <maaku> i maintain python-bitcoin which uses the requests package for connections
119 2014-03-05 07:07:47 <just[dead]> Do most programs that require the blockchain and making tx modify the reference client, or have a program that starts an instance of bitcoind while interacting with its json rpc?
120 2014-03-05 07:24:40 <wumpus> just[dead]: most just use the reference client
121 2014-03-05 07:28:13 <just[dead]> wumpus: doesn't really answer my questions...
122 2014-03-05 07:28:32 <just[dead]> *question
123 2014-03-05 07:32:27 <antephialtic> just[dead]: pretty rare to modify the reference client unless you are at a large scale, and even then that can be dangerous unless you really know what you're doing. I would stick to json-RPC
124 2014-03-05 07:33:02 <just[dead]> antephialtic: So if I make a program that will be run locally by people, it should just make an instance of bitcoind?
125 2014-03-05 07:33:16 <wumpus> to make tx you certainly don't need to modify the reference client
126 2014-03-05 07:33:50 <wumpus> just submit them with sendrawtransaction
127 2014-03-05 07:34:03 <antephialtic> just[dead]: that is the usual way of doing things. Have your users setup their own instance of bitcoind, and then have your app connect to it to connect with the network
128 2014-03-05 07:34:11 <just[dead]> wumpus: I mean building the program off of the reference client so there doesn't need to be local http communication
129 2014-03-05 07:34:33 <wumpus> just[dead]: you can do that, but why would you?
130 2014-03-05 07:34:46 <antephialtic> alternatively, check out bitcoinJ, it can connect to the network on its own and has some nice classes for constructing transactions
131 2014-03-05 07:34:48 <just[dead]> wumpus: so it is all in one
132 2014-03-05 07:34:59 <wumpus> just[dead]: seperation into processes is a good thing usually
133 2014-03-05 07:35:05 <just[dead]> antephialtic: ehh, I don't think I want to stray from the reference client
134 2014-03-05 07:36:16 <antephialtic> just[dead]: bitcoinJ is very high quality. Using the reference client is key if you need to fully verify transactions, but if you are just generating them and sending them out to the network, bitcoinJ is a good choice
135 2014-03-05 07:36:29 <just[dead]> wumpus: It can be separated into processes without requiring the users to download two programs
136 2014-03-05 07:36:45 <wumpus> just[dead]: obviously; many installers install multiple programs
137 2014-03-05 07:36:51 <just[dead]> antephialtic: I basically need all bitcoind capabilities
138 2014-03-05 07:37:13 <just[dead]> wumpus: I suppose. I'd rather have a standalone executable though
139 2014-03-05 07:37:39 <just[dead]> And I'd rather not have the user have to mess with making sure they aren't running two bitcoind instances and all that
140 2014-03-05 07:38:02 <wumpus> just[dead]: yes if you insist on that it leaves only very few options
141 2014-03-05 07:38:06 <just[dead]> But I guess if it just works with the other bitcoind, then there is no risk of the user having two blockchains
142 2014-03-05 07:38:31 <antephialtic> just[dead]: either way the experience will be shitty if you bundle bitcoind, the user will still need to download the whole blockchain, etc.
143 2014-03-05 07:38:32 <just[dead]> wumpus: Do you have examples of desktop applications using bitcoind separately?
144 2014-03-05 07:38:43 <antephialtic> check out chromawallet
145 2014-03-05 07:38:47 <just[dead]> antephialtic: yeah, but that is needed for anonymity
146 2014-03-05 07:38:54 <just[dead]> and non-SPV security
147 2014-03-05 07:38:57 <wumpus> just[dead]: there are also some other libraries and frameworks that can be used for interaction with the bitcoin network, for example picocoin, libbitcoin, and probably many others
148 2014-03-05 07:39:04 <wumpus> just[dead]: armory
149 2014-03-05 07:40:00 <just[dead]> wumpus: I'd rather not stray from the reference client and risk consensus breaking. Along with that, bitcoind is very useful for automating tasks
150 2014-03-05 07:40:03 <wumpus> but bitcoinj is the most mature of the alternative implementations
151 2014-03-05 07:40:17 <wumpus> only drawback, you're stuck with java :)
152 2014-03-05 07:40:25 <just[dead]> wumpus: I don't doubt it, but I think it is still a risk
153 2014-03-05 07:40:55 <antephialtic> wumpus: bitcoinj has fixed chain-splitting bugs in every release :(
154 2014-03-05 07:40:58 <wumpus> multibit as well as all of the android clients use it, and it has a very good testing framework
155 2014-03-05 07:41:16 <just[dead]> Okay, so ask if the user has the blockchain downloaded, ask if they have bitcoind and then based on that, give them a certain executable?
156 2014-03-05 07:42:15 <wumpus> antephialtic: yeah you wouldn't want to use it for mining :) it's only used for SPV clients for a good reason
157 2014-03-05 07:42:30 <antephialtic> wumpus: agreed.
158 2014-03-05 07:43:28 <antephialtic> just[dead]: if you don't mind answering, what features are you trying to build in your app that require the full blockchain?
159 2014-03-05 07:50:07 <Diablo-D3> gmaxwell: bot bullshit in #bitcoin?
160 2014-03-05 07:50:39 <justanotheruser> antephialtic: Decentralized marketplace based on bitcoin and bitmessage
161 2014-03-05 08:28:47 <TD> good morning
162 2014-03-05 09:14:16 <paveljanik> How do I change a commit message on github?
163 2014-03-05 09:16:12 <maaku> paveljanik: by rewriting history
164 2014-03-05 09:18:30 <paveljanik> maaku: and in UI/click level?
165 2014-03-05 09:19:51 <maaku> i'm not sure you can
166 2014-03-05 09:19:59 <maaku> on purpose, mind you, because it breaks stuff
167 2014-03-05 09:20:14 <maaku> when you change the commit message, you change the commit hash
168 2014-03-05 09:20:43 <maaku> but maybe there is a UI way to do the same, I don't use the UI much
169 2014-03-05 09:21:21 <jcorgan> paveljanik: you can use git gui and check "amend last commit" to change the commit. when you push you'll need to force push
170 2014-03-05 09:21:48 <paveljanik> jcorgan: and github interface?
171 2014-03-05 09:22:27 <paveljanik> https://github.com/bitcoin/bitcoin/pull/3798#issuecomment-36722048
172 2014-03-05 09:22:38 <jcorgan> ah, not sure, i use github most for storing a backup of repos but not their interface stuff
173 2014-03-05 09:33:08 <SomeoneWeird> paveljanik, you can't do it from github interface, on purpose
174 2014-03-05 09:33:13 <SomeoneWeird> it's a destructive change
175 2014-03-05 09:33:23 <SomeoneWeird> also, s/server/daemon/
176 2014-03-05 09:34:55 <paveljanik> Hmm.
177 2014-03-05 09:34:56 <paveljanik> Bitcoin Core Daemon version v0.9.0rc2-4-gc975e99-dirty-beta
178 2014-03-05 09:34:56 <paveljanik> bitcoind [options] Start Bitcoin server
179 2014-03-05 09:34:56 <paveljanik> pavel@opencl:~/bitcoin/src> ./bitcoind --help | head
180 2014-03-05 09:34:56 <paveljanik> Usage:
181 2014-03-05 09:35:13 <paveljanik> I thought that Bitcoin Core Daemon is a high level name
182 2014-03-05 09:35:20 <paveljanik> abd we are starting Bitcoin server
183 2014-03-05 09:35:28 <paveljanik> as I wrote in the message.
184 2014-03-05 09:35:36 <sipa> hmm?
185 2014-03-05 09:35:50 <sipa> ah
186 2014-03-05 09:36:09 <paveljanik> this is trivia, I just want to learn how to contribute.
187 2014-03-05 09:36:23 <sipa> the message should probably say "Bitcoin Core Daemon" too
188 2014-03-05 09:38:55 <paveljanik> ok, so I will change it again.
189 2014-03-05 09:43:23 <paveljanik> https://github.com/bitcoin/bitcoin/pull/3798/files
190 2014-03-05 09:45:00 <jouke> Goonie: is there a way to help debug the wallet? Are there log files somewhere maybe? We are testing the latest version with bip71-support, but it keeps failing with "wrong signature"
191 2014-03-05 09:45:28 <jouke> While the reference client accepts the paymentrequest without a problem.
192 2014-03-05 09:49:47 <paveljanik> sipa: you mean like this? https://github.com/paveljanik/bitcoin/commit/974a26f17cf4425d1b0da75dc9a2844b343373a8
193 2014-03-05 09:51:25 <Joric> just wondering did anyone try bruteforcing github commits? it uses 7 digits in markup, difficulty appears to be it's less than 1 in btc terms, 28 bits vs 32 bits
194 2014-03-05 09:52:46 <Joric> one could use vanity commit numbers this way, eg. 0000001, 0000002 etc %)
195 2014-03-05 09:52:56 <jouke> Goonie: sorry, i mean bip72
196 2014-03-05 09:53:15 <paveljanik> this is git...
197 2014-03-05 10:02:15 <wumpus> Joric: if it's like the command-line tool, it uses as many digits as needed to distinguish the commit uniquely (starting at 7)
198 2014-03-05 10:46:22 <Goonie> jouke: still there?
199 2014-03-05 10:47:04 <jouke> yes
200 2014-03-05 10:47:38 <jouke> The request is served via an http connection with an other domainname the request is signed with.
201 2014-03-05 10:48:02 <Goonie> there is the android logfile. If you're running ubuntu, "apt-get install android-tools-adb" and then use "adb logcat"
202 2014-03-05 10:48:24 <Goonie> That should not be an issue.
203 2014-03-05 10:49:04 <Goonie> the payment protocol even works via non-http, e.g. Intents or NFC.
204 2014-03-05 10:54:23 <jouke> Goonie: trying to get adb to work, will get back to you
205 2014-03-05 10:54:52 <Goonie> jouke: If you want, you can give me an URL and I'd test myself.
206 2014-03-05 10:55:37 <Goonie> I'm off to lunch for an hour. If you're still having trouble, it'd be best if you mail me the relevant part of log and the exact error message.
207 2014-03-05 10:56:22 <jouke> Goonie: k
208 2014-03-05 10:56:30 <jouke> It is not on a public server yet
209 2014-03-05 10:56:46 <TD> ugh
210 2014-03-05 10:56:47 <TD> http://eprint.iacr.org/2014/161
211 2014-03-05 10:57:04 <TD> looks like the era of doing bitcoin wallets on cloud hosted datacenters is over
212 2014-03-05 10:57:19 <TD> at least once someone writes an open source version of that
213 2014-03-05 11:02:13 <jouke> TD: thanks
214 2014-03-05 11:03:11 <gmaxwell> TD: sidechannel free signing can be done... not fast, but it pretty much never has to be.
215 2014-03-05 11:03:16 <gmaxwell> but weeee.
216 2014-03-05 11:03:21 <TD> there are some mitigating factors
217 2014-03-05 11:03:27 <gmaxwell> pretty impressive numbers there.
218 2014-03-05 11:03:30 <jouke> TD: don't reuse keys
219 2014-03-05 11:03:52 <TD> indeed. avoiding address re-use is one of them. also, it's not entirely clear to me that you can execute clflush across hypervisor boundaries
220 2014-03-05 11:04:06 <TD> i think their attack assumes you can run a process on the same VM next to bitcoind
221 2014-03-05 11:07:12 <gmaxwell> might also be possible to employ the blind ecdsa technique proposed recently to help strenghten against this.
222 2014-03-05 11:08:48 <stonecoldpat> for a bitcoin address, is a version byte still appended to the front of it? https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
223 2014-03-05 11:09:01 <stonecoldpat> or this out of date nowadays?
224 2014-03-05 11:09:28 <wumpus> stonecoldpat: yes the version byte is still in the same place
225 2014-03-05 11:10:26 <wumpus> it's out of date though (uses a non-compressed public key instead of a compressed one)
226 2014-03-05 11:10:36 <ruukasu> how can I create a bitcoin address/WIF pair manually, using random bytes from /dev/(u)random?
227 2014-03-05 11:11:11 <stonecoldpat> wumpus: ah ok, so you just change step 1 to a compressed version then do the rest ?
228 2014-03-05 11:11:58 <stonecoldpat> ruukasu: if you mean after you have generated an ECDSA key pair, i guess you follow these steps https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses (just happens im reading it now myself)
229 2014-03-05 11:12:33 <wumpus> ruukasu: manually? as in, do the computations with hand?
230 2014-03-05 11:12:37 <sipa> stonecoldpat: my guess is that he wants to create keypair from /dev/urandom itself
231 2014-03-05 11:12:58 <ruukasu> wumpus, like with bash and python
232 2014-03-05 11:13:17 <ruukasu> stonecoldpat, I assume we're currently using version 1 addresses?
233 2014-03-05 11:13:26 <wumpus> ruukasu: python-bitcoinlib will help a lot there, it has functions for that IIRC
234 2014-03-05 11:13:29 <sipa> with python there are likely a dozen implementations already
235 2014-03-05 11:13:36 <sipa> i'd probably want to kill myself before doing it in bash
236 2014-03-05 11:13:58 <ruukasu> wumpus, I mean just experimentally, library would defeat the purpose
237 2014-03-05 11:14:10 <wumpus> doing it in bash sounds like a very bad idea, almost impossible to do anything secure or robust, too much edge cases and gotchas
238 2014-03-05 11:15:01 <ruukasu> don't need it to be secure at all, just want to see the actual process of private key --> address in action
239 2014-03-05 11:15:07 <jouke> https://bitcointalk.org/index.php?topic=23081.0
240 2014-03-05 11:15:13 <wumpus> ruukasu: well, start by looking up ECDSA math on the secp256k1 curve then
241 2014-03-05 11:15:28 <wumpus> that you need to go from private key to public key
242 2014-03-05 11:16:06 <samson_> ruukasu: You could simply obtain the 32 byte number from your entropy source and then encode it into Wallet Import Format then import into BTC client
243 2014-03-05 11:16:13 <wumpus> having done that, all that is left is encoding the resulting numbers in the appropriate base58 format
244 2014-03-05 11:18:37 <samson_> ruukasu: You don't need to know anything about ECDSA to create a key - just do this : https://en.bitcoin.it/wiki/Wallet_import_format
245 2014-03-05 11:18:41 <wumpus> the ECDSA part is interesting, second step is pretty annoying to implement, so I do suggest using a library
246 2014-03-05 11:20:16 <ruukasu> samson_, will any 32 bytes be a valid ECDSA private key?
247 2014-03-05 11:20:48 <wumpus> ruukasu: almost; 0 is not valid, as well as >= a certain number
248 2014-03-05 11:21:06 <vegard> https://en.bitcoin.it/wiki/Private_key#Range_of_valid_private_keys
249 2014-03-05 11:21:09 <samson_> ruukasu: I believe there is a valid range like wumpus says
250 2014-03-05 11:22:59 <wumpus> the range is very close to the full 2^256, you grab random bytes then there is a 99.9999% chance or more that the resulting key will be valid, but you do need to check ofcourse
251 2014-03-05 11:23:30 <sipa> the odds for a random 256-bit number to not be a valid private key are around 1 in 2^127
252 2014-03-05 11:23:32 <samson_> I've been writing some simple tests in C using the Polar SSL library which has it's own bignum implementation and a lot more documentation that OpenSSL - it also compiles quite easily almost anywhere and comes with a comprehensive set of example programs covering everything needed. To create a BTC address from a bignum you need sha256, repimd160 and a bignum library to convert to base58
253 2014-03-05 11:25:01 <samson_> Polar SSL also does ECDSA operations using secp256k1 since the new release came out last month and it's free for open source projects
254 2014-03-05 11:25:17 <olalonde> hey guys, I'm writing a language that compiles to bitcoin script -> https://github.com/olalonde/bitscript it's still a work in progress and it outputs very unoptimized code
255 2014-03-05 11:35:23 <ruukasu> "Perform SHA-256 hash on result of SHA-256 hash"
256 2014-03-05 11:35:25 <ruukasu> why?
257 2014-03-05 11:40:00 <stonecoldpat> further obsecures it
258 2014-03-05 11:40:01 <paveljanik> ruukasu: https://en.bitcoin.it/wiki/Hashcash#Double_Hash
259 2014-03-05 11:40:21 <stonecoldpat> pon
260 2014-03-05 11:40:26 <stonecoldpat> obscure* god cant type today
261 2014-03-05 11:42:30 <wumpus> it increases the number of hashing steps (makes the function twice as computationally intensive)
262 2014-03-05 11:59:06 <Goonie> jouke: Back again. Did manage to access the logfile?
263 2014-03-05 12:14:50 <jouke> Goonie: sorry, not yet.
264 2014-03-05 12:51:38 <berndj> TD, re your "Why you think the PKI sucks": i think you've at least slightly misrepresented dkg's "let's allow multiple cert chains" argument. #justsaying, for now
265 2014-03-05 13:08:00 <TD> berndj: how so
266 2014-03-05 13:08:09 <disident> hello, whats the way to generate the genesis block ? I can't find the code that generated the bit coin genesis
267 2014-03-05 13:08:21 <TD> disident: there is none. you have to modify the code to do it
268 2014-03-05 13:08:32 <disident> TD: OK
269 2014-03-05 13:08:51 <disident> tried https://github.com/Gnaf/GenesisBlockZero but can't fns the same merkle hash
270 2014-03-05 13:08:54 <berndj> TD: i read "politically active CA" as just an example of what a user might prefer, not a necessary attribute of an alternate CA
271 2014-03-05 13:10:02 <berndj> TD, and re "SSL doesnt allow multiple cert chains to be presented because nobody is asking for this feature." - what point is there in asking when the protocol (SSL) is already graven in stone? also, i'm asking for this feature right now!
272 2014-03-05 13:10:42 <berndj> (really i'm asking "please help me do it right" (that doesn't just amount to "don't do it"), and not "please do it for me")
273 2014-03-05 13:11:08 <TD> SSL gets extended all the time
274 2014-03-05 13:11:32 <TD> by "nobody is asking for this feature" I mean, if browser makers and major site operators were asking for this feature, it'd get funded and done, as is the case with other SSL features
275 2014-03-05 13:11:36 <TD> but they aren't
276 2014-03-05 13:12:02 <TD> my point about "politically active CA" is general - there are few reasons to pick one CA over another beyond price and perhaps the quality of the CA's own website/purchasing experience.
277 2014-03-05 13:12:31 <TD> it used to be that there were big differences in coverage, but as auto update systems got better a new CA can get huge coverage much faster than before.
278 2014-03-05 13:12:43 <TD> though if the long tail matters to you then coverage is also a factor
279 2014-03-05 13:16:16 <berndj> sigh, i know i'm not going to convince you that it's a valid desire. i don't know what else to say other than writing the code (but it'll probably be wrong without proper engagement)
280 2014-03-05 13:17:06 <TD> well, i probably wouldn't be thrilled about implementing that in bitcoinj even if someone else wrote the code, as i'd have to maintain it.
281 2014-03-05 13:17:36 <TD> so far you haven't given any reasons why my reasoning is wrong though. it's not that i can't be convinced or i'm ideologically opposed to this feature. it's that i can't see any good arguments for it existing
282 2014-03-05 13:27:54 <berndj> TD: btw one of my pet peeves is people changing SSH host keys willy nilly :) classic case of how human factors can defeat what might have been a not-totally-bad protocol (but btw^2 lsh(1) makes it a bit harder to just yes-by-default accept a host key, so it's less TOFU than openssh)
283 2014-03-05 13:28:24 <TD> well, there are legitimate reasons to change a key
284 2014-03-05 13:28:41 <TD> the problem is the way to detect "bad" vs "good" reasons for a key change is just pushed onto the user with ssh
285 2014-03-05 13:28:57 <TD> if your primary adversary is someone who can eavesdrop but not do MITM attacks, then it's not a bad model
286 2014-03-05 13:29:18 <TD> once you assume active MITM is possible then it rapidly becomes unworkable. TOFU could be useful as a way to opportunistically encrypt the p2p network for instance
287 2014-03-05 13:29:48 <sipa> berndj: TOFU?
288 2014-03-05 13:30:22 <TD> trust on first use
289 2014-03-05 13:31:08 <TD> we're discussing an article i wrote on the pki: https://medium.com/p/b64cf5912aa7
290 2014-03-05 13:34:49 <CodeShark> is the trezor available already? I ordered one months ago and no word
291 2014-03-05 13:37:38 <xeroc> CodeShark: unfortunatelly not ..
292 2014-03-05 13:37:43 <xeroc> no idea why..
293 2014-03-05 13:37:53 <CodeShark> I would love to add support for it in my wallet
294 2014-03-05 13:38:10 <CodeShark> and would love to collaborate on the multisig stuff in particular
295 2014-03-05 13:38:30 <CodeShark> oh well - I guess I'll look for slush on skype :p
296 2014-03-05 13:40:22 <TD> i think they're intending to ship early dev units RSN
297 2014-03-05 13:42:07 <CodeShark> RSN?
298 2014-03-05 13:42:30 <sipa> really soon now (tm)
299 2014-03-05 13:42:37 <CodeShark> lol
300 2014-03-05 13:42:46 <CodeShark> haven't seen that one before
301 2014-03-05 13:44:35 <CodeShark> TD: do you have a link to that usability study review that doesn't require signing in anywhere?
302 2014-03-05 13:44:51 <TD> https://medium.com/p/d04ea6a2c771 doesn't work for you?
303 2014-03-05 13:45:02 <CodeShark> ah, that one does
304 2014-03-05 13:45:21 <TD> oops. just spotted a link that had an /edit trailer on it. fixed.
305 2014-03-05 14:27:51 <stonecoldpat> with the error "Disk space is low: error" - is there a way to keep bitcoind running ?
306 2014-03-05 14:28:15 <stonecoldpat> im waiting for the admin to give me more gb, and would like to run the daemon to test stuff
307 2014-03-05 14:28:17 <CodeShark> yeah, get a bigger disk or delete some files :)
308 2014-03-05 14:28:20 <stonecoldpat> haha
309 2014-03-05 14:31:48 <CodeShark> use a different computer until the admin gives you more gb
310 2014-03-05 14:32:11 <stonecoldpat> yeah, that seems like the only option atm
311 2014-03-05 15:35:28 <gpmnlxdw> 2014-03-05 15:33:03 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
312 2014-03-05 15:35:28 <gpmnlxdw> 2014-03-05 15:33:23 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
313 2014-03-05 15:35:28 <gpmnlxdw> 2014-03-05 15:33:49 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
314 2014-03-05 15:35:52 <gpmnlxdw> Hi guys, does it means the amount is to small to accept?
315 2014-03-05 15:36:01 <xeroc> jup
316 2014-03-05 15:41:08 <gpmnlxdw> input is : 0.00015 + 0.0002 + 0.0001; output is 0.0004 + 0.00005; it is 0.00005 to small to accept, is it?
317 2014-03-05 15:41:55 <gpmnlxdw> how could I get to know the minimum amount?
318 2014-03-05 15:47:25 <Apocalyptic> gpmnlxdw, check the source
319 2014-03-05 15:47:44 <Apocalyptic> it's something like 5** satoshis if I remember correctly
320 2014-03-05 15:48:13 <Apocalyptic> "it is 0.00005 to small to accept, is it?" definitely
321 2014-03-05 15:48:50 <gpmnlxdw> I got it! thank you Apoca!!!!
322 2014-03-05 16:30:00 <k3d3> "There is no from address" very nice
323 2014-03-05 16:34:21 <michagogo> cloud|re: ~16 hours ago...
324 2014-03-05 16:34:35 <michagogo> cloud|It's really annoying that Ubuntu keeps their repos outdated
325 2014-03-05 16:35:11 <michagogo> cloud|They've removed the package from trusty and blacklisted it from the Debian autosync
326 2014-03-05 16:35:44 <michagogo> cloud|But they apparently are unable to remove the package from precise..saucy
327 2014-03-05 16:37:22 <michagogo> cloud|Anyone know how to package for Ubuntu? I've been told that they might consider accepting an "update" to the packages that effectively removes them (removes the binaries, replaces with a message to that effect)