1 2013-05-14 00:39:57 <nanotube> learn from chrome. version numbers should be integers!
2 2013-05-14 00:40:42 <Luke-Jr> nanotube: I have Chromium 26.0.1410.43
3 2013-05-14 00:40:52 <nanotube> chromIUM is different :)
4 2013-05-14 00:41:09 <nanotube> we are, by the way, on mainline bitcoin version 44 (or some such. :P )
5 2013-05-14 00:42:13 <nanotube> hm actually 0.8.2 will be 57
6 2013-05-14 00:43:05 <nanotube> ACTION changes topic to "latest version 57rc"
7 2013-05-14 00:43:48 <gmaxwell> 3984
8 2013-05-14 00:43:48 <gmaxwell> nanotube: watch talking about? $ git log --oneline | wc -l
9 2013-05-14 00:44:05 <nanotube> heh list the release tags :P
10 2013-05-14 01:09:57 <MC1984> mempool should be roughly the same for all nodes right
11 2013-05-14 01:10:16 <MC1984> anyone notice it pushing 2000 lately
12 2013-05-14 01:10:42 <MC1984> and not really dropping under 1000 any more
13 2013-05-14 01:12:12 <MC1984> also a lot of inputs already spent, never had that before. Those nodes should be getting banned right
14 2013-05-14 01:12:39 <ali1234> possibly spam from altcoins?
15 2013-05-14 01:13:30 <MC1984> wha
16 2013-05-14 01:13:32 <ali1234> some of them don't change genesis block or message start :(
17 2013-05-14 01:13:42 <MC1984> altcoin shit wouldnt be in the bitcoin network
18 2013-05-14 01:14:36 <ali1234> well, altcoins cross pollinating tx has already happened
19 2013-05-14 01:14:47 <ali1234> when one ends up as a hard fork of another
20 2013-05-14 01:15:10 <ali1234> i guess since most of them fork litecoin they wouldn't affect bitcoin
21 2013-05-14 01:15:32 <MC1984> wow
22 2013-05-14 01:15:33 <ali1234> however there are a few unknowns in development (seen by checking the irc channels)
23 2013-05-14 01:15:49 <MC1984> so start a scamcoin and end up making tarded bitcoin nodes instead
24 2013-05-14 01:15:53 <ali1234> yes
25 2013-05-14 01:16:00 <MC1984> thats funny
26 2013-05-14 01:16:23 <MC1984> still, i never noticed it till i installed this rc so
27 2013-05-14 01:18:27 <MC1984> the banscore is 0 -> 0 every time i get one, so maybe im seeing them coming from the same few nodes. Why doesnt it just ban them
28 2013-05-14 01:18:40 <ali1234> the ban code isn't very smart
29 2013-05-14 01:18:47 <ali1234> or at least it wasnt last time i looked at it
30 2013-05-14 01:18:56 <ali1234> it's pretty hard for a node to get banned
31 2013-05-14 01:19:18 <MC1984> yeah the most ive seen is 90
32 2013-05-14 01:21:00 <MC1984> well im running rc in order to report shit, so why not
33 2013-05-14 01:22:07 <MC1984> i dont know if any one cares, but the aplha transparency of the tiny program ico seems a bit messed up, the interior of the B is just white and before im sure it was transparent
34 2013-05-14 01:22:23 <MC1984> if theres a grand buglist someone that one goes right at the bottom, but whatever
35 2013-05-14 01:24:49 <cjd> 2980988784
36 2013-05-14 01:24:49 <cjd> -rw-rw-r-- 1 user user 4855459871 May 6 01:20 ./bootstrap.dat
37 2013-05-14 01:24:49 <cjd> user@ubnta8:~/wrk/cjdns-pvt$ cat ./bootstrap.dat | xz | wc -c
38 2013-05-14 01:24:49 <cjd> user@ubnta8:~/wrk/cjdns-pvt$ ls -la ./bootstrap.dat
39 2013-05-14 01:24:50 <cjd> user@ubnta8:~/wrk/cjdns-pvt$
40 2013-05-14 01:25:08 <cjd> ;;calc 4855459871 / 2980988784
41 2013-05-14 01:25:08 <gribble> 1.62880850041
42 2013-05-14 01:25:17 <cjd> err
43 2013-05-14 01:25:24 <cjd> ;;calc 2980988784 / 4855459871
44 2013-05-14 01:25:24 <gribble> 0.61394571538
45 2013-05-14 01:25:29 <cjd> hmm
46 2013-05-14 01:25:36 <cjd> blockchain compresses surprisingly well
47 2013-05-14 01:26:03 <MC1984> what compressor
48 2013-05-14 01:26:08 <cjd> xz
49 2013-05-14 01:26:15 <cjd> which is basically LZMA
50 2013-05-14 01:26:34 <MC1984> 40%?
51 2013-05-14 01:26:55 <cjd> well compresses to 61% of it's original size
52 2013-05-14 01:27:03 <gmaxwell> not terribly impressive.
53 2013-05-14 01:27:20 <gmaxwell> a specialized compressor can do a fair amount better.
54 2013-05-14 01:27:58 <cjd> probably so but it's interesting nonetheless
55 2013-05-14 01:28:33 <cjd> freeing up 2ish GB of space is always interesting
56 2013-05-14 01:29:08 <MC1984> only useful if it can still be worked with peicemeal in a compressed state
57 2013-05-14 01:29:15 <cjd> yeap
58 2013-05-14 01:29:51 <cjd> compress 10MB blocks or something like that
59 2013-05-14 01:29:57 <MC1984> i bet a custom compressor could squash it in megabyte chunks or somthing
60 2013-05-14 01:30:27 <cjd> using an off-the-shelf compressor has the benefit or testing behind it
61 2013-05-14 01:30:41 <cjd> don't have to reinvent the wheel, even if your wheel would be better
62 2013-05-14 01:31:17 <MC1984> every part of bitcoin must eventually be handmade in asm!
63 2013-05-14 01:31:47 <cjd> ahh but eventually is not tomorrow and handmade need not be by me :)
64 2013-05-14 01:32:56 <MC1984> whoes gunna go it? someone else! someone else!
65 2013-05-14 01:32:59 <MC1984> lol
66 2013-05-14 01:34:07 <Luke-Jr> MC1984: what asm?
67 2013-05-14 01:34:30 <MC1984> youre they guy with the darknet project right? damn i dropped into your irc just before going on holiday august last year
68 2013-05-14 01:34:31 <cjd> pdp11
69 2013-05-14 01:34:45 <MC1984> did you find a DNS solution
70 2013-05-14 01:34:54 <cjd> sorta
71 2013-05-14 01:34:56 <Luke-Jr> cjd: nooooooo
72 2013-05-14 01:35:10 <Luke-Jr> MC1984: he wrote one. it's called CJ DNS.
73 2013-05-14 01:35:12 <Luke-Jr> ACTION ducks
74 2013-05-14 01:35:19 <cjd> =]
75 2013-05-14 01:35:37 <MC1984> mctrollington
76 2013-05-14 01:35:50 <cjd> oh right, mc
77 2013-05-14 01:35:54 <Luke-Jr> sigh, ASICMiner makes annoying work for me
78 2013-05-14 01:36:02 <MC1984> didnt have a way to do distributed naming last i heard
79 2013-05-14 01:37:03 <cjd> you were the mc from the UK, not the mc who wrote namecoin
80 2013-05-14 01:37:28 <Luke-Jr> if you get static addressing, you don't need names
81 2013-05-14 01:37:37 <MC1984> forrestv did namecoin iirc
82 2013-05-14 01:37:43 <Luke-Jr> links just specify by address
83 2013-05-14 01:37:45 <Luke-Jr> MC1984: no
84 2013-05-14 01:37:58 <MC1984> oh no he did p2pool
85 2013-05-14 01:39:11 <cjd> static addressing is nice
86 2013-05-14 01:39:21 <cjd> but names are also nice
87 2013-05-14 01:39:25 <cjd> cjd [irssi@fc88:dfd0:89d4:abfe:de2:a17a:6ed5:6fb1]
88 2013-05-14 01:39:29 <cjd> not fun to type
89 2013-05-14 01:47:18 <Luke-Jr> cjd: names can be local
90 2013-05-14 01:48:31 <cjd> yeah but if I tell you about a site it's nice for you to be able to type it in
91 2013-05-14 01:49:25 <cjd> granted typing names is so much less important than it was in the late 90's
92 2013-05-14 01:52:17 <shesek> I understand that with type-2 deterministic wallets, its not safe to give the private key for one of the addresses (knowing both the master public key and one private key could expose the primary private key). is there any way around that?
93 2013-05-14 01:52:50 <shesek> I'm referring to https://bitcointalk.org/index.php?topic=19137.0
94 2013-05-14 01:52:53 <shesek> ACTION pings gmaxwell
95 2013-05-14 01:52:59 <Luke-Jr> shesek: don't disclose the master public key
96 2013-05-14 01:53:10 <Luke-Jr> shesek: also, the BIP might be more up to date
97 2013-05-14 01:54:03 <Luke-Jr> https://en.bitcoin.it/wiki/BIP_0032
98 2013-05-14 01:54:15 <shesek> the BIP mentions this weakness too
99 2013-05-14 01:54:26 <shesek> "One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key"
100 2013-05-14 01:56:54 <Diablo-D3> http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
101 2013-05-14 02:00:50 <ezdiy> Diablo-D3: i suspect cf already do something like that
102 2013-05-14 02:00:54 <ezdiy> for their anycast tcp
103 2013-05-14 02:01:54 <iddo_> shesek: our way around that is to use type-1 to break the key homomorphism, see the discussion starting at page 6 of that thread
104 2013-05-14 02:02:35 <iddo_> shesek: and you can expose the master pubkey itself, just not the master chaincode (seed)
105 2013-05-14 02:04:25 <gmaxwell> ACTION is glad that he doesn't have to constantly watch IRC??? so many other people with good answers.
106 2013-05-14 02:07:37 <iddo_> gmaxwell: here's a job for you, can you take a look at the way i described to trade coins between chains without trust/extortion and verify whether it works? https://bitcointalk.org/index.php?topic=193281.msg2058662#msg2058662
107 2013-05-14 02:09:38 <cjd> xD
108 2013-05-14 02:09:59 <gmaxwell> iddo_: I did that job so fast that it was done 11 months ago.
109 2013-05-14 02:10:11 <gmaxwell> iddo_: https://bitcointalk.org/index.php?topic=91843.msg1011956#msg1011956 (and two messages down)
110 2013-05-14 02:10:27 <iddo_> gmaxwell: i'm not completely sure about your way to avoid extortion by preparing the nlocktime payback txn, when you give it to the other person to sign, he has to verify that he isn't signing another txn that spend other coins of his?
111 2013-05-14 02:12:01 <shesek> iddo_, I want to be able to generate addresses on machines that can't sign transactions
112 2013-05-14 02:12:15 <iddo_> gmaxwell: i glanced at that thread before, but the idea there seemed a little different, and you mentioned extortion risk, i'll look again
113 2013-05-14 02:12:44 <gmaxwell> iddo_: I mentioned using nlock time two posts down to create refunds, not sure if I proposed exactly the same protocol.
114 2013-05-14 02:13:31 <iddo_> shesek: sure, you'd use type-2 for that, it's just that the root node that you'd use can be derived with type-1, to confine any possible leakage only to the addresses that interest you
115 2013-05-14 02:19:39 <gmaxwell> iddo_: actually looking at your post??? as tiernolan says, they way you're describing the refund isn't how nlocktime works. You can get that behavior by presigning locked refund transactions. If you need to be sure what the prior txn you're signing is you can make it known but still unannouncable by making it an orphan (e.g. an extra non-public input)
116 2013-05-14 02:19:39 <iddo_> gmaxwell: ok, so i suppose it's the same, my idea was based on your https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked anyway, but what about the issue of being careful when signing the refund txn? the signer sees that hash of the payment txn as the input txn, but he has to make sure that it doesn't fit other coins that he controls, otherwise you could trick him to spend his other coins?
117 2013-05-14 02:20:22 <gmaxwell> iddo_: people should never be reusing addresses, if you never reuse addresses??? no issue.
118 2013-05-14 02:20:25 <gmaxwell> :P
119 2013-05-14 02:22:54 <iddo_> you mean that if you never reuse addresses then we cannot trick because we wouldn't know the pubkey of your unspent coins?
120 2013-05-14 02:24:42 <gmaxwell> iddo_: I mean _you'd_ know which coins you were spending with, because the only time the pubkey you're signing with had _ever_ been used is in the output of that transaction.
121 2013-05-14 02:25:01 <gmaxwell> no risk of it being some other coin, you generated the pubkey just for this trade.
122 2013-05-14 02:25:25 <iddo_> ahh
123 2013-05-14 02:25:27 <gmaxwell> and if the guy trading with you randomly sent some extra coins to that address ... just to steal them back... well... good for him. :P
124 2013-05-14 02:25:30 <iddo_> that's simple
125 2013-05-14 02:33:36 <iddo_> gmaxwell: more generally the idea here is that if the digital data X that you wish to sell (with no trust involved) can be random data, then you don't need the extra ZK proof
126 2013-05-14 02:35:49 <iddo_> i tried to think of an example of e.g. selling serials of online multiplayer games, where the server supports ownership transfer where the player signs with his identity on the server a message that transfer the serial to another identity (with time lock), and the data X is this signature
127 2013-05-14 02:37:00 <iddo_> but still the data X can be random, by simply adding to the signature hash(X) and having the signature valid only if X is revealed
128 2013-05-14 02:38:05 <iddo_> so i'm trying to think of examples where X cannot be random, so that ZK proofs will be useful there
129 2013-05-14 02:39:49 <iddo_> for example if X is a counterexample to the Goldbach conjecture (even number that isn't sum of two primes), then you can sell X via ZK proof
130 2013-05-14 02:41:02 <iddo_> though i'm looking for hopefully much more mundane use cases
131 2013-05-14 03:01:12 <gmaxwell> iddo_: dude, I describe it in the page. A solution to any NP problem. A key to a crypto system. An energy minimizing solution to a protein folding. A picture a complex non-linear computer vision program believes you'd find beautiful.
132 2013-05-14 03:01:50 <amiller> you know how people complain about bayesians and frequentists fighting
133 2013-05-14 03:02:01 <amiller> it should really be about cryptographers vs the bayesian
134 2013-05-14 03:02:01 <gmaxwell> ('A key to a crypto system' e.g. magic vendor keys that break drm)
135 2013-05-14 03:02:02 <amiller> s
136 2013-05-14 03:08:19 <amiller> because the big bone to pick with bayesians that they make big decisions that relying assuming things are randomly distributed according to observable probabilities
137 2013-05-14 03:09:24 <CodeShark> a true bayesian would probably argue that the distribution is simply due to symmetry in the a priori knowledge
138 2013-05-14 03:09:50 <CodeShark> and might argue that the distribution is then constrained by knowledge
139 2013-05-14 03:10:03 <CodeShark> but represents the state of maximal entropy subject to those constraints
140 2013-05-14 03:10:15 <CodeShark> i.e. it's a state of knowledge, not a statement of reality
141 2013-05-14 03:10:53 <CodeShark> "true bayesian" is an unfortunate choice of scotsman...I should have worded it better :p
142 2013-05-14 03:11:15 <Diablo-D3> bah laddy, everyone knows a true scotsman is a bayesian too!
143 2013-05-14 03:11:55 <CodeShark> bayesians love haggis too?
144 2013-05-14 03:12:32 <Diablo-D3> who doesnt?
145 2013-05-14 03:12:58 <Diablo-D3> its like sausage with a thick outside
146 2013-05-14 03:13:13 <CodeShark> what's the probability that a bayesian likes haggis given that he's not a scotsman?
147 2013-05-14 03:13:34 <Diablo-D3> I dunno, lets ask harry potter.
148 2013-05-14 03:15:45 <iddo_> gmaxwell: yes those are very nice use cases, thanks, actually as you say any NP complete would be nice, the seller spends <= exponential time to solve an instance of the problem, then uses ZK proof for the computation that verifies his witness (this is much more mundane than open num theory conjectures)
149 2013-05-14 03:18:36 <amiller> CodeShark, or, whats the probability that my particular tx is going to be zero-conf double-spended
150 2013-05-14 03:18:47 <amiller> is it reasonable to add up all the txes and divide by double-spends
151 2013-05-14 03:19:04 <gmaxwell> well, sadly, I'm not actually sure how useful most of those are. Basic escrow transactions plus mediation to prevent holdup does a lot and doesn't need so much cryptographic wizadry.
152 2013-05-14 03:19:32 <gmaxwell> amiller: bayesians seem to be pretty willing to cheat with all kinds of really high entropy priors.
153 2013-05-14 03:20:04 <amiller> i think that approach is kind of the antithesis to security science then
154 2013-05-14 03:20:08 <amiller> or maybe its dual or something
155 2013-05-14 03:22:20 <CodeShark> amiller: in absence of any further information, that could very well be reasonable
156 2013-05-14 03:23:00 <CodeShark> and when applied to ensembles, it actually can yield useful predictions
157 2013-05-14 03:23:10 <CodeShark> but when applied to individual events, it might be utterly useless
158 2013-05-14 03:24:23 <CodeShark> unless you have some understanding for the relationship between cause and effect, you'll probably be limited to only making ensemble predictions
159 2013-05-14 03:24:24 <iddo_> gmaxwell: we wouldn't need escrow for selling digital data if the compiler for ZK proof of computation is efficient enough, and there are use cases where you don't sell anything, e.g. proving how many bitcoins you possess without revealing your addresses
160 2013-05-14 03:25:29 <CodeShark> ensemble predictions are still good enough to give casinos an edge
161 2013-05-14 03:25:51 <amiller> yeah, agreed, my favorite example is from a book and it's about a fishpacking plant that uses computer vision to sort fish on a conveyor belt
162 2013-05-14 03:25:58 <gmaxwell> iddo_: "meh" if that use case came up people would show up to provide proxied cash proofs quite quickly.
163 2013-05-14 03:26:10 <amiller> and they lose more money if they put tuna in a salmon can rather than if they put salmnon in the tuna can so they set their bayesian behavior for maximal profit
164 2013-05-14 03:26:47 <iddo_> gmaxwell: i don't understand, what do you mean by proxied cash proofs ?
165 2013-05-14 03:26:59 <gmaxwell> amiller: sure, not unusual to differentially cost type-1/type-2 errors. Some machine learning software directly supports weighted margin training for that too.
166 2013-05-14 03:27:03 <amiller> but still that doesn't necessarily help individuals make decisions about an individual decision with limited information
167 2013-05-14 03:27:38 <gmaxwell> iddo_: you want amiller to prove he has 100 BTC... but he doesn't. He comes to me and asks me to do the proof for him, and what the heck??? I do for 0.01 btc.. it's anonymous anyways, costs me almost nothing. :P
168 2013-05-14 03:27:42 <amiller> i guess that's where anonymity helps you blend in and make yourself more of an accurately random target
169 2013-05-14 03:28:33 <iddo_> gmaxwell: i see
170 2013-05-14 03:29:05 <amiller> iddo_, it's a good idea though keep going - you can also do zero knowledge proofs about some status of your coins in the block chain, like that at some block it's timelocked in someway
171 2013-05-14 03:29:45 <gmaxwell> iddo_: in any case, you wouldn't _need_ escrow.. but it's a heck of a lot easier to implement.... setup... be confident that it's secure... etc.
172 2013-05-14 03:29:47 <amiller> then the person consuming this proof, combined with their observation of the blockchain, knows that the 100 coins is available in some way
173 2013-05-14 03:30:39 <gmaxwell> And today we live on an internet where there is no easy package for us to go grab and perform a decenteralized secret ballot vote among our friends on IRC... I will not hold my breath on ZKP overtaking escrow txn anytime soon. :P
174 2013-05-14 03:32:07 <iddo_> gmaxwell: how about proving that you sent bitcoins to some public address of a merchant (or e.g. wikileaks), without revealing your address ? the ZK proof will be of the computation where you signed the txn with your privkey to the merchant address and that this txn is buried in the next e.g. 6 PoW blocks
175 2013-05-14 03:36:12 <gmaxwell> iddo_: well, the height there might give reduce your anonymity set a lot... but sure.
176 2013-05-14 03:36:46 <gmaxwell> Alternatively something like wikileaks could offer blind signatures along with every donation, thereby giving people donation tokes they could use for such proof and enjoy a much large anonymity set.
177 2013-05-14 03:39:13 <iddo_> gmaxwell: about proof that you possess coins, it still might be useful, e.g. if you're speculator who hold 100,000 BTC and you do ZK proof for signed msg that you think that the USD/BTC price will go up, if you don't actually have 100,000 BTC and you ask another person who has 100000 BTC to do it, he might ask for more than 0.01 BTC as payment, if he thinks that this statement will affect the USD/BTC price
178 2013-05-14 03:40:46 <iddo_> i don't sound too convincing :(
179 2013-05-14 03:41:02 <ezdiy> nah, billionaire-sign-as-a-service is certainly viable
180 2013-05-14 03:41:10 <iddo_> gmaxwell: not sure i understand about why the height reduces you anonymity?
181 2013-05-14 03:41:18 <ezdiy> iddo_: in fact, every bigger exchange can do it
182 2013-05-14 03:41:22 <iddo_> s/you/your
183 2013-05-14 03:41:25 <gmaxwell> iddo_: what if there was only one payment to WL in the last six blocks?
184 2013-05-14 03:41:57 <iddo_> gmaxwell: ahh, small height, ok
185 2013-05-14 03:42:15 <gmaxwell> iddo_: there are applications for it, I imagine, but many applications for it are actually hurt by the privacy of it instead of helped.
186 2013-05-14 03:42:33 <iddo_> why hurt?
187 2013-05-14 03:45:25 <gmaxwell> iddo_: because it makes billionaire-sign-as-a-service viable.
188 2013-05-14 03:45:30 <amiller> that kind of proof is a lot like the proofs of stake
189 2013-05-14 03:45:57 <gmaxwell> wherease if you know which coins are in question your ability to be bambozled by that is at least limited to how much coin the billionaire proxy signers have.
190 2013-05-14 03:47:43 <iddo_> i see
191 2013-05-14 03:47:54 <MC1984> maporphan overflow
192 2013-05-14 03:47:57 <MC1984> cool
193 2013-05-14 05:41:11 <JDuke128> hi
194 2013-05-14 07:36:45 <wallet43> who increased the difficulty again??
195 2013-05-14 07:37:24 <BlueMatt> avalon?
196 2013-05-14 07:44:54 <Luke-Jr> BlueMatt: has Avalon actually shipped anything since the last difficulty increase? XD
197 2013-05-14 07:45:39 <BlueMatt> no idea, but its probably some combination of a ton of new users due to press and asics
198 2013-05-14 07:47:49 <warren> You don't think it's ASICMINER?
199 2013-05-14 07:50:46 <BlueMatt> that falls under "asics" :)
200 2013-05-14 07:52:07 <wallet431> how much faster would an altcoin wich has signatures with curve25519 be compared to bitcoin?
201 2013-05-14 07:52:41 <chmod755> wallet431, 5mph
202 2013-05-14 07:53:03 <wallet431> mph?
203 2013-05-14 07:54:15 <wallet431> oh you mean 8.04 km/h
204 2013-05-14 07:54:16 <chmod755> wallet431, miles per hour
205 2013-05-14 07:54:19 <chmod755> ofc
206 2013-05-14 07:54:25 <wallet431> well thats quite faster
207 2013-05-14 07:54:28 <sipa> wallet431: do you mean OpenSSL ECDSA as we do today, or another implementation that does all potential optimizations specific for secp256k?
208 2013-05-14 07:56:38 <wallet431> gmaxwell has listed ed25519 on https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas
209 2013-05-14 07:56:59 <BlueMatt> ed25519 is nice for other reasons too
210 2013-05-14 07:57:25 <wallet431> so i wonder if its significantly faster than secp256k1
211 2013-05-14 07:57:32 <BlueMatt> (deterministic sigs, etc)
212 2013-05-14 07:57:38 <wallet431> (if some day we has 1000 tx/s
213 2013-05-14 07:58:29 <wallet431> could it be added with the current scripting?
214 2013-05-14 07:58:41 <wallet431> OP_CHECKSIG_ED25519?
215 2013-05-14 07:59:04 <sipa> wallet431: with a hardfork
216 2013-05-14 07:59:21 <sipa> BlueMatt: you can do deterministic sigs with ecdsa too :)
217 2013-05-14 08:00:33 <wallet431> BlueMatt, what else is ed25519 good for?
218 2013-05-14 08:01:34 <sipa> and ed25519 needs a modification to support pubkey recovery
219 2013-05-14 08:03:38 <wallet431> wow http://ed25519.cr.yp.to/python/ed25519.py is incredibly small
220 2013-05-14 08:06:19 <wallet431> deteministic sigs means always the same for the same input?
221 2013-05-14 08:06:38 <sipa> for the same key/msg combination
222 2013-05-14 08:07:30 <wallet431> so the attack of recovering the privkey when using 2 time the same random for different messages is not a threat
223 2013-05-14 08:09:44 <sipa> indeed, it means no randomness is consumed for signing a message
224 2013-05-14 08:09:48 <sipa> only for key generation
225 2013-05-14 08:10:22 <wallet431> cryptography == magic lol
226 2013-05-14 08:36:00 <t7> cryptography is just math
227 2013-05-14 08:36:20 <t7> everything is math i guess
228 2013-05-14 08:37:21 <nsh> only to a first approximation
229 2013-05-14 08:38:44 <hazrd> hi everyone
230 2013-05-14 08:39:17 <hazrd> i've been trying to configure slush's stratum pool, but keep on getting exceptions http://pastebin.com/Pe0enNqx could someone point me in a direction to fix this?
231 2013-05-14 08:39:40 <michagogo> hazrd: There's a #bitcoin-mining, I believe
232 2013-05-14 08:39:57 <hazrd> michagogo, perfect - thank you!
233 2013-05-14 08:40:30 <BlueMatt> sipa: I was under the impression you couldnt with our curve?
234 2013-05-14 08:41:50 <sipa> BlueMatt: "our curve" ?
235 2013-05-14 08:41:54 <sipa> secp256k1 you mean?
236 2013-05-14 08:42:04 <BlueMatt> yes
237 2013-05-14 08:42:19 <sipa> how do you think message signing works? :p
238 2013-05-14 08:43:01 <michagogo> Wow, there are a *lot* of results for /msg alis list #bitcoin*
239 2013-05-14 08:43:11 <BlueMatt> why does message signing require deterministic sigs?
240 2013-05-14 08:43:29 <michagogo> 2 pages plus part of a 3rd page (more than 120, fewer than 180)
241 2013-05-14 08:43:41 <sipa> BlueMatt: it doesn't
242 2013-05-14 08:43:54 <BlueMatt> are we discussing different things then?
243 2013-05-14 08:43:57 <sipa> BlueMatt: i was talking about pubkey recovery, not deterministic sigs
244 2013-05-14 08:44:02 <BlueMatt> <sipa> BlueMatt: you can do deterministic sigs with ecdsa too :)
245 2013-05-14 08:44:03 <BlueMatt> ahh
246 2013-05-14 08:44:08 <BlueMatt> well then we were
247 2013-05-14 08:44:32 <sipa> but you can do the latter with ecdsa too: just use HMAC(key=privkey,msg=msg) as nonce in the ECDSA signing algorithm
248 2013-05-14 08:45:11 <michagogo> Hmm, just noticed something in the rc
249 2013-05-14 08:45:34 <michagogo> The "9 hours behind" bar seems to actually be how many hours since last block you got
250 2013-05-14 08:45:43 <michagogo> ;;tblb 60
251 2013-05-14 08:45:45 <gribble> The expected time between blocks taking 1 minute and 0 seconds to generate is 9 minutes and 36 seconds
252 2013-05-14 08:45:47 <michagogo> uh
253 2013-05-14 08:45:51 <michagogo> ;;tblb 3600
254 2013-05-14 08:45:52 <gribble> The expected time between blocks taking 1 hour and 0 seconds to generate is 6 days, 15 hours, 14 minutes, and 56 seconds
255 2013-05-14 08:46:01 <michagogo> But that will be wrong about once a week
256 2013-05-14 08:47:02 <sipa> yes, it's an approximation in any case
257 2013-05-14 08:50:46 <BlueMatt> sipa: ok, but we cant enforce that when we check sigs, no?
258 2013-05-14 08:51:15 <sipa> you can't enforce that at all, and there's no reason for it either
259 2013-05-14 08:51:35 <sipa> it's just a way for the signer to protect himself from the effects of bad randomness
260 2013-05-14 08:51:46 <BlueMatt> tx determinism?
261 2013-05-14 08:52:57 <sipa> deterministic signatures
262 2013-05-14 08:57:51 <nsh> (reused nonces give away private keys)
263 2013-05-14 08:59:17 <sipa> nsh: when used for the same message
264 2013-05-14 08:59:29 <nsh> right
265 2013-05-14 09:00:02 <sipa> wait, no
266 2013-05-14 09:00:17 <michagogo> ;;bcverify HK+exhkVT9eQ2oNyRZOLry4bhFdgq8NosYWtHKw5UXN3PJZ2ov7/sY0YtOY43kaz9DAc+Uu2SsfBCbyxWkNlPdU=
267 2013-05-14 09:00:19 <gribble> You are now authenticated for user 'michagogo' with address 18xRDaxdJudfk5U943GNTsWfvg1soouPbc
268 2013-05-14 09:00:29 <michagogo> gah
269 2013-05-14 09:00:35 <michagogo> I thought I'd switched :-/
270 2013-05-14 09:02:49 <alaricsp> Dear devs, has anyone given any thought to recurring payments for subscriptions? Should that be handled by the vendor requesting a payment every period, with a deadline, or might there be interest in supporting a schedule periodic payments withing bitcoin-qt or bitcoind, and allowing one payment request to set up such a schedule?
271 2013-05-14 09:03:26 <michagogo> alaricsp: Just set up a cronjob to use bitcoind on the command line
272 2013-05-14 09:03:29 <michagogo> or something
273 2013-05-14 09:05:01 <michagogo> alaricsp: I mean, in theory you could make a bunch of timelocked transactions for the future
274 2013-05-14 09:05:23 <michagogo> And give them to the vendor to broadcast, and then you could cancel them by doublespending the inputs
275 2013-05-14 09:05:53 <michagogo> But that would mean tying up the funds then
276 2013-05-14 09:05:58 <alaricsp> Yeah, but that's not very fruendly for Joe Average User who wants to sign up for his pornsite subscription
277 2013-05-14 09:06:17 <michagogo> Right
278 2013-05-14 09:06:27 <alaricsp> "fruendly" is a new word I just made up, but for now imagine I meant "friendly".
279 2013-05-14 09:07:03 <alaricsp> In my Evil Banking Empire online account, I can look at a list of "standing orders" (UK terminology?), add new ones, cancel existing ones, etc.
280 2013-05-14 09:08:42 <milkshakey> Luke-Jr, stop 51% attacking my coin
281 2013-05-14 09:09:01 <sipa> what coin?
282 2013-05-14 09:09:19 <milkshakey> elacoin
283 2013-05-14 09:10:25 <rdymac> (umbr)elacoin?
284 2013-05-14 09:10:52 <milkshakey> elasticoin :P
285 2013-05-14 09:11:00 <alaricsp> What's it do?
286 2013-05-14 09:11:10 <milkshakey> It's being 51% attacked by Luke Jr
287 2013-05-14 09:11:23 <milkshakey> I don't think he should be a core dev.
288 2013-05-14 09:12:19 <rdymac> it looks like ecochele
289 2013-05-14 09:12:34 <rdymac> Skype is p2p?
290 2013-05-14 09:12:54 <alaricsp> milkshakey: Perhaps he needs a cuddle. Have you tried cuddling him?
291 2013-05-14 09:12:54 <milkshakey> used to be
292 2013-05-14 09:13:02 <milkshakey> ACTION cuddles Luke-Jr with a sharp knife
293 2013-05-14 09:25:32 <davout> he's like on some sort of crusade
294 2013-05-14 09:34:25 <sturles> Scamcoin attack?
295 2013-05-14 09:34:31 <sturles> Luke-Jr: Can I join?
296 2013-05-14 09:35:01 <davout> lol
297 2013-05-14 09:35:45 <sturles> You know it is a scamcoin whent it is "my coin". :-)
298 2013-05-14 09:57:33 <k00shi> It's incredible that there are over 500 people in here these days.
299 2013-05-14 09:57:38 <k00shi> Wasn't it less than 50 half a year ago?
300 2013-05-14 09:59:38 <gjs278> mm no, it's always been a lot here, I don't think it was 50 just 6 months ago
301 2013-05-14 10:00:20 <MCM-Mike> ACTION is just an observer where the developing is going :)
302 2013-05-14 10:01:19 <wallet431> sipa: whats pubkey recovery?
303 2013-05-14 10:34:41 <Primosz> Hi there people.
304 2013-05-14 10:51:29 <pigeons> wallet431: i think pubkey recovery is deriving the pubkey from an ecdsa signature
305 2013-05-14 12:39:16 <gmaxwell> sipa: Your graphs need reranging: http://bitcoin.sipa.be/speed-lin-10k.png
306 2013-05-14 13:38:19 <michaelwholley> Is the core Bitcoin technology still under development or just the clients?
307 2013-05-14 13:40:05 <nsh> how the clients interact is the core technology of bitcoin
308 2013-05-14 13:41:04 <michaelwholley> Okay.
309 2013-05-14 13:42:03 <michaelwholley> I was wondering if it were possible to add support to Bitcoin to add an identity, for those who wish to, to make it easier to interact with than just a non-rememberable long string of random alpha-numeric characters.
310 2013-05-14 13:43:00 <gmaxwell> michaelwholley: you'd do something like that externally to bitcoin.
311 2013-05-14 13:43:34 <michaelwholley> gmaxwell, kind of like a DNS service?
312 2013-05-14 13:45:18 <gmaxwell> If you like, there are many ways to accomplish things like that. DNS as commonly used is highly vulnerable to man in the middle attacks.
313 2013-05-14 13:45:22 <BlueMatt> there have been 100 suggestions on how to do it, dns included
314 2013-05-14 13:45:49 <BlueMatt> but, yea, have to enforce DNSSEC on the client side (in rare occasions, this is impossible)
315 2013-05-14 13:47:41 <michaelwholley> Is there a way, BlueMatt, to use a nickname system to identify people in a decentralized manner, not via a centralized DNS service?
316 2013-05-14 13:48:30 <michagogo> Well, there's something like what namecoin does
317 2013-05-14 13:49:04 <BlueMatt> there are literally hundreds of ways to do that...namecoin, DNS, HTTPS servers, etc, etc
318 2013-05-14 13:52:09 <michaelwholley> BlueMatt, I'll check out namecoin but where can I learn more about these hundreds of ways?
319 2013-05-14 13:52:20 <BlueMatt> be creative?
320 2013-05-14 13:52:36 <keystroke> hey BlueMatt.. was talking with someone at unc's comp sci phd program recently...
321 2013-05-14 13:52:36 <michaelwholley> Thanks for the help, I just want to make sure I'm not reinventing the wheel.
322 2013-05-14 13:52:42 <BlueMatt> google distributed identity?
323 2013-05-14 13:52:49 <BlueMatt> there are many ways to do it
324 2013-05-14 13:52:52 <keystroke> you should come to the raleigh btc meetup sometime :)
325 2013-05-14 13:53:02 <BlueMatt> keystroke: who?
326 2013-05-14 13:53:08 <keystroke> mac
327 2013-05-14 13:53:09 <BlueMatt> keystroke: yes, if I had a car I would...
328 2013-05-14 13:53:20 <BlueMatt> ahh, yes, I know him
329 2013-05-14 13:53:51 <keystroke> oh we carpool sometimes!
330 2013-05-14 13:54:00 <keystroke> i didn't know you were in the area until i was doing whois on the dns seednodes for fun...
331 2013-05-14 13:54:01 <keystroke> haha
332 2013-05-14 13:54:04 <BlueMatt> ahh, well ping me next time
333 2013-05-14 13:54:29 <keystroke> will do!
334 2013-05-14 13:54:52 <keystroke> i will be out of the country for the june meeting but back in july.. but i will have someone ping you if you are free... it is a good group
335 2013-05-14 13:55:05 <BlueMatt> Im out of the country until the next school year, essentially
336 2013-05-14 13:56:19 <keystroke> cool! well nice meeting you, going to run now :)
337 2013-05-14 13:56:44 <keystroke> btw any idea on final 0.8.2 release? prior to the hardfork event?
338 2013-05-14 13:57:07 <BlueMatt> probably, havent heard anything, so I assume soonish
339 2013-05-14 13:57:20 <BlueMatt> but I havent been reading scrollbacks so...dunno?
340 2013-05-14 13:57:58 <keystroke> ok, neat, will be good to see a smooth transition tonight
341 2013-05-14 13:58:20 <BlueMatt> oh, today's the 14th
342 2013-05-14 13:58:22 <BlueMatt> well then no probably not
343 2013-05-14 13:58:25 <BlueMatt> but soon enough
344 2013-05-14 13:58:44 <BlueMatt> ACTION never remembers dates...
345 2013-05-14 14:00:20 <buZz> ehr
346 2013-05-14 14:00:28 <buZz> why is there all this news about a fork
347 2013-05-14 14:00:34 <buZz> is there really gonna be a fork?
348 2013-05-14 14:00:39 <gmaxwell> buZz: huh? what news are you talking about?
349 2013-05-14 14:00:56 <BlueMatt> probably, but probably not in the first few blocks
350 2013-05-14 14:00:56 <buZz> i thought the transition to 0.8.1 would be one that didnt need a fork
351 2013-05-14 14:01:05 <BlueMatt> who knows though, maybe a miner will decide to be evil
352 2013-05-14 14:01:31 <buZz> gmaxwell: stuff like http://siliconangle.com/blog/2013/05/13/bitcoin-blockchain-hard-fork-coming-may-15th-final-warning/
353 2013-05-14 14:02:12 <gmaxwell> buZz: notice that the article there says that its own headline is misleading.
354 2013-05-14 14:02:51 <gmaxwell> I think it's not unlikely that there will be no blocks built on a dead stub because of this...
355 2013-05-14 14:03:57 <buZz> gmaxwell: yes i know, but this kind of news is causing a lot of waves
356 2013-05-14 14:04:10 <buZz> well, we'll see what the turnout will be
357 2013-05-14 14:04:58 <nsh> the sky can't fall on your head if you're already deep underground
358 2013-05-14 14:06:08 <gmaxwell> buZz: what waves where?
359 2013-05-14 14:09:41 <buZz> gmaxwell: dont worry about it ;)
360 2013-05-14 14:10:16 <gmaxwell> buZz: I mean, if you're gonna claim it's "making waves" you might expect people to ask what you're talking about.
361 2013-05-14 14:13:22 <wamatt> buZz: have no idea what ur on about??? haven't seen any waves about forks lately
362 2013-05-14 14:14:05 <wamatt> i wouldnt worry much about it :)
363 2013-05-14 14:15:25 <buZz> i never worry about money :D
364 2013-05-14 14:15:34 <buZz> besides, worrying is abuse of imagination
365 2013-05-14 14:16:58 <LorenzoMoney> buZz: I really like what you just said: Worry is Abuse of Imagination. I think I will modify it to be Anxiety is Abuse of Imagination!! Brilliant
366 2013-05-14 14:17:29 <buZz> sure, everything i say is public domain ;)
367 2013-05-14 14:17:31 <nsh> ACTION shoots LorenzoMoney in the genitals
368 2013-05-14 15:15:43 <r0sc0e> what can i do to make the synchronization of my bitcoin-qt 0.8.1 faster? have to synchronize about 1300 blocks
369 2013-05-14 15:15:53 <r0sc0e> and i see about 50 kb/s speed
370 2013-05-14 15:16:02 <r0sc0e> with an 50 mbit line
371 2013-05-14 15:16:05 <r0sc0e> any ideas?
372 2013-05-14 15:19:13 <helo> your transfer rate largely depends on what node you're downloading from. not sure how you can force it to try a different node...
373 2013-05-14 15:19:50 <CodeShark> use addnode
374 2013-05-14 15:19:57 <CodeShark> or connect
375 2013-05-14 15:19:57 <r0sc0e> or to try more than one node?
376 2013-05-14 15:20:05 <r0sc0e> via debug-console?
377 2013-05-14 15:20:22 <helo> CodeShark: addnode/connect will change the synching node to the one specified?
378 2013-05-14 15:20:33 <CodeShark> yes
379 2013-05-14 15:20:44 <CodeShark> they are startup options
380 2013-05-14 15:21:03 <r0sc0e> i have no ip for a fast node
381 2013-05-14 15:21:04 <CodeShark> so you have to either stick them into the config file or use them in the command to launch bitcoin-qt
382 2013-05-14 15:21:10 <r0sc0e> what to do now?
383 2013-05-14 15:21:24 <helo> r0sc0e: you can look at 'getpeerinfo' to see the peers you're currently using
384 2013-05-14 15:21:41 <helo> not sure if 0.8.1 shows which node is the sync node
385 2013-05-14 15:22:18 <helo> hopefully this will be a non-issue with 0.9
386 2013-05-14 15:22:51 <r0sc0e> i have 11 nodes right now
387 2013-05-14 15:23:11 <r0sc0e> but only 9 kb/s speed
388 2013-05-14 15:23:15 <r0sc0e> crazy
389 2013-05-14 15:23:18 <helo> it only downloads from one at a time
390 2013-05-14 15:23:28 <helo> you're just stuck on a slow synching node
391 2013-05-14 15:23:51 <CodeShark> the network code could use plenty of improvements :)
392 2013-05-14 15:25:33 <helo> r0sc0e: you can restart the client and it may pick a different sync node
393 2013-05-14 15:25:45 <r0sc0e> yap
394 2013-05-14 15:25:47 <r0sc0e> i will try
395 2013-05-14 15:25:50 <r0sc0e> thanks for help
396 2013-05-14 15:26:18 <helo> btw, using addnode from the debug console doesn't change the sync node while the client is running
397 2013-05-14 15:26:31 <helo> and it apparently can establish multiple connections to the same node
398 2013-05-14 15:28:22 <helo> maybe i'm doing this wrong, but i can't seem to "addnode <ip> remove" for an ip i just added
399 2013-05-14 15:28:46 <helo> Error: Node has not been added.
400 2013-05-14 16:03:26 <lolcookie> nick 1
401 2013-05-14 16:06:57 <yubrew> Hello
402 2013-05-14 16:36:37 <ikea_meatballs> anyone wannna help me build a ppcoin block chain explorer ?? $$$$$
403 2013-05-14 17:09:05 <yubrew> I have bitcoind set up on an ubuntu server. How does JSON-RPC interact with the bitcoind?
404 2013-05-14 17:09:43 <yubrew> I looked at the JSON-RPC docs, but not sure what it does that I can't do with bitcoind
405 2013-05-14 17:10:31 <sipa> bitcoind can run either as a bitcoin node + RPC server
406 2013-05-14 17:10:35 <sipa> or as RPC client
407 2013-05-14 17:11:12 <sipa> so if you type "./bitcoind getinfo", you start bitcoind as RPC client, and it's communicating with an already-running bitcoind server using JSON-RPC, sending the getinfo command, and printing the result
408 2013-05-14 17:11:40 <yubrew> I'd like to send and receive bitcoin transactions
409 2013-05-14 17:11:54 <yubrew> can that be done with either an RPC client or RPC server?
410 2013-05-14 17:11:56 <sipa> listtransactions, sendtoaddress
411 2013-05-14 17:12:15 <sipa> i don't think you understand
412 2013-05-14 17:12:35 <sipa> bitcoind (the bitcoin p2p client) can _only_ be interacted with using JSON-RPC
413 2013-05-14 17:12:44 <sipa> it's the only way you can make it do something
414 2013-05-14 17:13:45 <yubrew> ah ok, so it's how you send p2p messages?
415 2013-05-14 17:14:00 <sipa> you don't
416 2013-05-14 17:14:02 <Cusipzzz> uhh
417 2013-05-14 17:14:04 <sipa> bitcoind does thta for you
418 2013-05-14 17:15:04 <sipa> if you want to send bitcoins to someone, you send the 'sendtoaddres' JSON-RPC call to bitcoind
419 2013-05-14 17:15:24 <sipa> and it inspects your wallet, constructs a transaction, signs it, updates balances, ... and broadcasts it on the P2P network
420 2013-05-14 17:15:50 <Cusipzzz> e.g. ./bitcoind sendtoaddress 157eo1r1yhmNtbmiSSNLAf87FvFLUBr1sS 100 :)
421 2013-05-14 17:15:51 <sipa> and then returns
422 2013-05-14 17:16:58 <yubrew> ah i see
423 2013-05-14 17:17:04 <yubrew> let me make sure i understand
424 2013-05-14 17:17:23 <yubrew> so JSON-RPC is the message, like "sendtoaddress a90j2i32n342l3n4k2l3j4 1"
425 2013-05-14 17:17:40 <sipa> yes, encoded a bit differently, but with that content, indeed
426 2013-05-14 17:17:41 <yubrew> bitcoind interprets the JSON-RPC
427 2013-05-14 17:17:47 <sipa> yes
428 2013-05-14 17:17:49 <yubrew> then sends it out to other nodes
429 2013-05-14 17:17:51 <sipa> yes
430 2013-05-14 17:18:16 <sipa> although sending it out is the easiest part, probably
431 2013-05-14 17:18:23 <yubrew> yes
432 2013-05-14 17:18:26 <sipa> constructing and signing the transaction is hard :)
433 2013-05-14 17:18:52 <yubrew> so doesn't bitcoind check that for you?
434 2013-05-14 17:19:04 <dugo> not that i have a chance in hell to generate a block, but from what time can i run new bitcoind in gen mode?
435 2013-05-14 17:19:05 <sipa> of course it does
436 2013-05-14 17:19:19 <yubrew> i'm guessing it checks something like blockexplorer for matching addresses and txid
437 2013-05-14 17:19:24 <sipa> yubrew: HELL NO