1 2014-12-12 00:31:58 <sipa> cfields: no
2 2014-12-12 10:30:47 <jtimon> re: "sipa wonders whether libsecp256k1 should 1) have an API where the nonce is passed in explicitly (as now) 2) an API where you pass in a bunch of function pointers to compute the nonce 3) have built-in SHA256 RFC6979 as the only way of computing the nonce"
3 2014-12-12 10:30:47 <jtimon> sipa not sure if a conclusion was reached
4 2014-12-12 10:31:03 <sipa> i'm still unsure
5 2014-12-12 10:31:39 <jtimon> I think I would prefer it implemented like 2 (in case we need something more generic later) but just expose 3 for now
6 2014-12-12 10:32:27 <jtimon> so "3 using 2 under the hood"
7 2014-12-12 10:34:34 <jtimon> I mean 2 may already be useful for different sighashes
8 2014-12-12 10:35:23 <gwillen> to what extent is this library intended for use by noncryptographers
9 2014-12-12 10:35:30 <sipa> this is for the computation of the nonce
10 2014-12-12 10:35:36 <sipa> not the sighash
11 2014-12-12 10:35:40 <gwillen> if the answer is yes, allowing them to pass a nonce in is perhaps dangerous
12 2014-12-12 10:36:56 <sipa> gwillen: i wouldn't say intended, but ot's proba ly inevitable
13 2014-12-12 10:37:05 <gwillen> ACTION nods
14 2014-12-12 10:37:14 <sipa> jtimon: 3) meams code duplication
15 2014-12-12 10:37:28 <jtimon> oh, forget about my last ccomment then
16 2014-12-12 10:38:04 <jtimon> how code duplication if you implement it via 2 ?
17 2014-12-12 10:38:20 <sipa> as it meams libsecp needs to gain a hash function/ hmac / rfc6979 implementation
18 2014-12-12 10:38:45 <gwillen> that seems like the sort of thing you write once and never modify, in which case duplication is less terrible than it could be
19 2014-12-12 10:38:47 <sipa> the only way to avoid that.is to pass in a fp to do those, which means 2
20 2014-12-12 10:39:41 <jtimon> and can't you implement an interface that just passes the same fp all the time?
21 2014-12-12 10:39:51 <jtimon> but from outside looks like 3?
22 2014-12-12 10:39:59 <gwillen> well, the question then is how you stop someone from passing their own fp
23 2014-12-12 10:40:07 <sipa> jtimon: that is 2)
24 2014-12-12 10:40:24 <sipa> not sure which "outside" you are talking about
25 2014-12-12 10:40:32 <gwillen> there's a time-honored approach there, which is to give the fp a dummy parameter with a type named something like "DONT_BE_AN_IDIOT"
26 2014-12-12 10:40:34 <sipa> the hash function has to be somewhere
27 2014-12-12 10:40:49 <gwillen> to, uh, discourage people from rolling their own
28 2014-12-12 10:41:08 <sipa> if it is not inside the library, it has to be passed in
29 2014-12-12 10:41:16 <jtimon> I was imagining something like "call3(params) {return call2(same_fp, params);}"
30 2014-12-12 10:41:19 <sipa> which means a more complicated api
31 2014-12-12 10:41:42 <sipa> and where would the hash function implementation be?
32 2014-12-12 10:42:02 <jtimon> in call2() implementation
33 2014-12-12 10:42:03 <sipa> if you have a default.implememted.in the library, you still have the code.duplication
34 2014-12-12 10:42:13 <gwillen> could you factor out the hash function into yet another library
35 2014-12-12 10:42:17 <gwillen> and have a hard dependency on it
36 2014-12-12 10:42:22 <sipa> please...
37 2014-12-12 10:43:26 <gmaxwell> gwillen: dependencies are hugely costly for us... both in build system complexity and also concerns about the consensus domain.
38 2014-12-12 10:44:55 <gwillen> gmaxwell: I guess what I'm imagining is that the code duplication comes from needing the same hash function both in libsecp256k1 and elsewhere in bitcoin, so I'm imagining creating a bitcoin-internal 'library' for the hash function and perhaps other low-level primitives, which can be depended on by both libsecp256k1 and other stuff in bitcoin
39 2014-12-12 10:45:17 <gwillen> thus eliminating the need for duplication but not actually adding a real external dependency
40 2014-12-12 10:45:33 <sipa> that complicates usage of the.library
41 2014-12-12 10:45:37 <gwillen> but... if libsecp256k1 itself is intended to be external, that doesn't fly I guess
42 2014-12-12 10:45:37 <sipa> seriously
43 2014-12-12 10:45:40 <gwillen> ACTION nods
44 2014-12-12 10:46:06 <jtimon> another solution is that the hash is on libsecp256k1 and only there
45 2014-12-12 10:46:28 <sipa> that's not.possible
46 2014-12-12 10:46:57 <gmaxwell> gwillen: yea, and if it's not used elsewhere then any concerns about interface saftey are greatly mitigated.
47 2014-12-12 10:47:08 <sipa> or.you would need a fully.generic hash function implementation there
48 2014-12-12 10:47:17 <jtimon> bitcoin is going to depend on libsecp256k1 anyway, no?
49 2014-12-12 10:47:24 <sipa> which is exposed
50 2014-12-12 10:47:38 <sipa> probably
51 2014-12-12 10:47:53 <jtimon> oh, I see, well, still another potential solutions (even though I wasn't seeing the disadvantages)
52 2014-12-12 10:48:23 <gmaxwell> its true, the hashes could just move into libsecp256k1 and be exposed. Maybe create a libsipacrypto and just move all the low level cryptographic functions we use there.
53 2014-12-12 10:48:39 <sipa> but i prefer keeping apis clean, even if it means fattening the implementation
54 2014-12-12 10:49:16 <gmaxwell> fortunately hash function implementations are really small.
55 2014-12-12 10:49:50 <sipa> it would add 20% or so to libsecp's binary size
56 2014-12-12 10:49:55 <gmaxwell> though a little less so if you go full on platform specific optimizations with them; which is less interesting for signing but perhaps more interesting elsewhere.
57 2014-12-12 10:50:09 <gmaxwell> sipa: but 0.1% to its memory footprint. :P
58 2014-12-12 10:50:17 <sipa> yup
59 2014-12-12 10:59:58 <jtimon> I like the idea of having all low level crypto functions encapsulated in a library, you guys know better if it's worth it
60 2014-12-12 11:00:29 <sipa> oh so do i, src/crypto is already mostly that
61 2014-12-12 11:01:00 <sipa> but i like libsecp to be stamdalone and reusable, without.kitchen sink of.crypto.functions that bitcoin just happens to use
62 2014-12-12 11:02:19 <jtimon> maybe they can be two libs dependent on each other, libseco256k1 uses 2 (fp approach) but crypto only exposes 3
63 2014-12-12 11:03:14 <jtimon> I don't know, it seems there's no easy answers
64 2014-12-12 11:03:19 <sipa> that is a possibility.. making libsecp lowlevel, and libbitcoincrypto higher level and.dependent on it
65 2014-12-12 11:03:56 <sipa> i like that, but it.does not benefit external users that much
66 2014-12-12 11:04:29 <jtimon> external users are the ones who may want 2 instead of 3, no?
67 2014-12-12 11:04:55 <sipa> bitcoin unit tests need 2
68 2014-12-12 11:05:01 <gwillen> I feel like the whole benefit of 3 is to prevent external users from doing that
69 2014-12-12 11:05:29 <jtimon> oh, I see, so actually you want 2 for bitcoin and 3 for external users
70 2014-12-12 11:05:29 <sipa> i should find a way to avoid that necessity.to.tweak.the nonce
71 2014-12-12 11:05:37 <gwillen> if you don't mind external users potentially shooting themselves in the foot, 1/2 is great for everyone
72 2014-12-12 11:06:01 <sipa> 1 works and exists right now
73 2014-12-12 11:06:13 <sipa> but it allows foot.shooting
74 2014-12-12 11:06:22 <sipa> and is.inconvenient.in usage
75 2014-12-12 11:06:47 <gmaxwell> (incidentally, there are already a raft of external users... even people we've specifically advised against using the library yet)
76 2014-12-12 11:07:16 <gwillen> well, that's exciting
77 2014-12-12 11:07:35 <gwillen> and here I thought I was being paranoid in suggesting crazy shenanigans just to prevent external users from being stupid
78 2014-12-12 11:07:51 <sipa> nope, not at all
79 2014-12-12 11:08:08 <jtimon> so maybe libsecp can expose 3, and bitcoin uses a custom version with 2 until the tests can be done with 3 alone?
80 2014-12-12 11:08:50 <sipa> i.think i will implement 2 for now, which works and.is.easy to.do
81 2014-12-12 11:09:08 <sipa> without any.default nonce generation function
82 2014-12-12 11:09:09 <gwillen> sipa: even though nobody reads documentation, I encourage you to document how dangerous it is
83 2014-12-12 11:09:18 <gwillen> so at least you can yell at people who use it
84 2014-12-12 11:10:08 <jtimon> implementing anything else on top of 2 should be easy so I think it's wise
85 2014-12-12 11:46:50 <sipa> 2014-12-12 12:46:38 ERROR 404: Not Found.
86 2014-12-12 11:46:50 <sipa> Fetching native_cdrkit...
87 2014-12-12 11:46:50 <sipa> http://distro.ibiblio.org/fatdog/source/c/cdrkit-1.1.11.tar.bz2:
88 2014-12-12 12:16:12 <cfields> sipa: did the fallback work properly?
89 2014-12-12 12:16:23 <sipa> cfields: no, but it was due to certificate problems
90 2014-12-12 12:16:30 <sipa> with --no-check-certificate it worked
91 2014-12-12 12:16:58 <cfields> sipa: hmm, you mentioned that once before. about bitcoincore.org? iirc at the time i couldn't reproduce that
92 2014-12-12 12:17:15 <sipa> cfields: the debian host env i have probably has too old certs
93 2014-12-12 12:18:14 <gmaxwell> yuck
94 2014-12-12 12:18:41 <sipa> we check hashes of sources anyway
95 2014-12-12 12:18:58 <cfields> sipa: we could https -> http since we check the hashes anyway, though that's bound to start some arguments
96 2014-12-12 12:18:59 <cfields> heh
97 2014-12-12 12:20:01 <wumpus> yes, let's not do that
98 2014-12-12 12:20:13 <sipa> haha
99 2014-12-12 12:20:33 <gmaxwell> better belt and suspenders.
100 2014-12-12 12:20:45 <wumpus> 'we check the hashes anyway' is kind of lousy reasoning in security, by reducing everything to one level of check you make things brittle
101 2014-12-12 12:20:53 <wumpus> right
102 2014-12-12 12:20:54 <sipa> fair enough
103 2014-12-12 12:21:09 <sipa> just wanted to see whether downloading and building otherwise works
104 2014-12-12 12:21:17 <wumpus> but what version of debian are you using?
105 2014-12-12 12:21:48 <wumpus> I'm a bit disappointed that they *still* haven't updated their certificates
106 2014-12-12 12:21:58 <sipa> whatever that VM guide said
107 2014-12-12 12:22:11 <sipa> well, minor update of it
108 2014-12-12 12:22:13 <sipa> 7.6 iirc
109 2014-12-12 12:22:33 <wumpus> well that should be ok
110 2014-12-12 12:23:26 <wumpus> maybe should switch that guide to ubuntu, I used debian because it was easier to do a minimal install, but it's given nothing but trouble
111 2014-12-12 12:24:27 <wumpus> everything is too old
112 2014-12-12 12:24:49 <sipa> is there a reason why we don't combine all gitian descriptors into one?
113 2014-12-12 12:25:02 <wumpus> you mean for all OSes?
114 2014-12-12 12:25:03 <sipa> so there's no mess with copying the results out, and signing them independently
115 2014-12-12 12:25:04 <cfields> wumpus: we're all just going to die anyway...
116 2014-12-12 12:25:06 <sipa> yes
117 2014-12-12 12:25:07 <cfields> wumpus: sounded so morbid :p
118 2014-12-12 12:25:14 <wumpus> cfields: :p
119 2014-12-12 12:25:32 <wumpus> sipa: well I really like being able to build for a certain platform independently
120 2014-12-12 12:25:49 <cfields> sipa: i've been thinking about hacking on gitian to allow for that
121 2014-12-12 12:25:49 <sipa> for releases?
122 2014-12-12 12:25:56 <wumpus> most of the time I just need linux, or windows executables
123 2014-12-12 12:26:01 <wumpus> I don't just use gitian for releases
124 2014-12-12 12:26:23 <sipa> ah, well, with the depends system it's pretty trivial to build non-release test binaries for any platform
125 2014-12-12 12:26:29 <cfields> sipa: if gitian allowed for saving output to some place, rather than blowing away the previous output, we could do that much easier
126 2014-12-12 12:26:31 <wumpus> but non-deterministic
127 2014-12-12 12:26:54 <sipa> right
128 2014-12-12 12:27:02 <wumpus> I really don't like throwing even more in one descriptor
129 2014-12-12 12:27:16 <wumpus> would be better to make a script that calls gitian three times and organizes things
130 2014-12-12 12:27:19 <sipa> ok
131 2014-12-12 12:27:29 <sipa> i had that, but i don't feel like redoing it :)
132 2014-12-12 12:27:29 <wumpus> not everything has to be moved inside
133 2014-12-12 12:28:09 <sipa> http://bitcoin.sipa.be/builds/bitcoin-build.sh.txt
134 2014-12-12 12:29:10 <wumpus> shouldn't be too hard to update, in my case it was mostly removing things
135 2014-12-12 12:29:33 <sipa> i don't think gitian is still compatible with the ugly tricks i did there
136 2014-12-12 12:29:35 <sipa> i'll try
137 2014-12-12 12:30:43 <cfields> sipa: i just use: http://pastebin.com/raw.php?i=2zzUkTsL
138 2014-12-12 12:30:59 <cfields> i suppose you'd want to add in the new source caching
139 2014-12-12 12:32:47 <sipa> cfields: my script builds from my own source tree rather than fetching it remotely, and also does gpg signing and generation of changelogs etc
140 2014-12-12 12:34:12 <cfields> sipa: ah, ok, probably not helpful then :). i just use the above for quick build checks
141 2014-12-12 12:34:48 <sipa> and puts git commit ids in the generated filenames so they don't clash (i used that script for pull requests etc too)
142 2014-12-12 12:36:02 <wumpus> generation of changelogs?
143 2014-12-12 12:36:18 <sipa> diffs with the last release etc
144 2014-12-12 12:36:43 <sipa> not useful for actual releases
145 2014-12-12 12:36:51 <sipa> but it helped keeping track of which version had what
146 2014-12-12 12:39:33 <wumpus> ah, right
147 2014-12-12 12:40:33 <cfields> sipa: other than the https issue, did you manage to get a build?
148 2014-12-12 12:41:53 <sipa> cfields: still building; dependencies take a while
149 2014-12-12 12:41:55 <sipa> but it seems fine
150 2014-12-12 12:42:40 <cfields> ok
151 2014-12-12 13:01:32 <wumpus> am I really unclear here? in how many other ways can I say the same thing? https://github.com/bitcoin/bitcoin/pull/5466
152 2014-12-12 13:03:36 <gmaxwell> wumpus: I was confused by that when he opened it.
153 2014-12-12 13:03:48 <gmaxwell> Do we display unverifyable signed ones as 'signed' in any way?
154 2014-12-12 13:04:01 <wumpus> no
155 2014-12-12 13:04:16 <gmaxwell> I think your response is clear enough.
156 2014-12-12 13:04:19 <wumpus> getMerchant returns false in the case of an error, which means 'unverified'
157 2014-12-12 13:04:37 <wumpus> which means we show the payment request in warning yellow instead of good green
158 2014-12-12 13:04:47 <wumpus> and without merchant
159 2014-12-12 13:04:53 <gmaxwell> I won't go on there and repeat it because it's going to break Diapolo. :)
160 2014-12-12 13:05:20 <gmaxwell> I guess I could give an argument in his favor: if there were ever a plan to phase out unverified ones, rejecting broken ones now might make it easier.
161 2014-12-12 13:05:25 <gmaxwell> but I don't really buy it.
162 2014-12-12 13:05:29 <wumpus> no, I'll just stop repeating, I was just afraid i was leaving something out causing him to not understand it
163 2014-12-12 13:05:52 <gmaxwell> yea, I'm sure it'll be clear to him if he sleeps on it.
164 2014-12-12 13:05:55 <sipa> cfields: osx and linux builds succeeded
165 2014-12-12 13:08:34 <wumpus> gmaxwell: in retrospect we probably shouldn't have allowed for unauthenticated payment requests; and in that case, sure, invalid signed requests should be completely rejected
166 2014-12-12 13:09:28 <wumpus> gmaxwell: but in that case getMerchant()==false simply means reject
167 2014-12-12 13:09:44 <gmaxwell> the problem with requiring authentication is that it makes the facility useless without an x509 cert, which are pita, cost money and or require a domain name, are (more or less rightfully seen as evil backdoors, though not in this case) etc.
168 2014-12-12 13:10:08 <gmaxwell> OTOH adoption of payment request between indivigual users appears to be precisely equal to zero.
169 2014-12-12 13:10:47 <gmaxwell> (actually adoption with merchants seems very low too, but regular users don't appear to be using it at all.. so not forcing the signing is probably a bad tradeoff)
170 2014-12-12 13:11:41 <wumpus> agreed that this leaves open the door for user-to-user payments
171 2014-12-12 13:11:56 <wumpus> I vaguely remember some mobile apps are doing that?
172 2014-12-12 13:12:10 <gmaxwell> Politically it might just simply be important to have a non-evil-CAs alternative. I wanted to do tor-hs onion key based auth, but the tor project talked me out of it because they have a complete redo of the onion crypto in the works. (well seems no one is actually working on it. :-/ )
173 2014-12-12 13:12:18 <wumpus> payment requests over bluetooth and such
174 2014-12-12 13:12:45 <wumpus> a non-evil CAs alternative would be incredible
175 2014-12-12 13:12:57 <gmaxwell> e.g. as an alternative to normal x509 you could take a tor HS pubkey, stuff it in a specially formed x509 cert, and we could handle that as displaying the name as a onion url.
176 2014-12-12 13:13:01 <gmaxwell> As one option.
177 2014-12-12 13:13:31 <gmaxwell> Another obvious option would be supporting pgp WOT auth, presumably in a similar manner, but bootstrapping that is hard.
178 2014-12-12 13:14:39 <wumpus> yup, supporting more open alternatives in addition to CAs would make it easier to bear to remove completely unverified payment requests
179 2014-12-12 13:15:18 <gmaxwell> maybe I should pick up the tor thing; seems progress on the HS replacement is not happening fast.
180 2014-12-12 13:15:27 <wumpus> I like the tor idea too
181 2014-12-12 13:17:34 <wumpus> the PGP WoT is in theory a good idea because it can be used for relative instead of absolute trust, but is considered ineffective because people don't check as well as they should before signing keys
182 2014-12-12 13:20:14 <gmaxwell> also obtaining the keys is often problematic, the WOT also leaks the social relations between people, which is weird. Management for controlling your trust has high overhead, etc. the last mostly being a UI issue but no one has solved it. It's hard to solve when indifference is so high.
183 2014-12-12 13:30:23 <sipa> cfields: and my laptop wasn't plugged in, so the battery died while building win...
184 2014-12-12 13:30:36 <wumpus> oops
185 2014-12-12 13:32:58 <sipa> wumpus: VM image is in ZFS; nothing happened :)
186 2014-12-12 13:57:26 <sipa> cfields: ok, all built
187 2014-12-12 14:00:01 <cfields> sipa: great. all good, then?
188 2014-12-12 14:00:21 <sipa> yup, though fixing the cert problem would be nice
189 2014-12-12 14:00:59 <cfields> sipa: easiest short-term fix would be to fix the busted dl link, no?
190 2014-12-12 14:01:09 <cfields> (not arguing against a cert fix, only taking the problems in order)
191 2014-12-12 14:07:23 <wumpus> yes, fixing the link would make sense so that it doesn't have to fall back in the first place
192 2014-12-12 14:08:16 <wumpus> the cert problem w/ bitcoincore.org will be fixed automatically when debian ever bothers to update their root certs
193 2014-12-12 14:40:25 <wumpus> maybe there's just some package that needs to be installed?
194 2014-12-12 15:11:13 <harding> wumpus: I imagine you could just install the ca-certificates package from testing or unstable. The package doesn't seem to have any dependencies not available on wheezy: https://packages.debian.org/sid/ca-certificates
195 2014-12-12 15:12:04 <wumpus> harding: that sounds like it could work
196 2014-12-12 17:12:51 <sipa> jtimon, gmaxwell: https://github.com/bitcoin/secp256k1/pull/162 implements (2)
197 2014-12-12 17:15:20 <lechuga_> should libsecp256k1 implement rfc6979?
198 2014-12-12 17:15:39 <sipa> that's an ongoing discussion
199 2014-12-12 17:15:55 <lechuga_> what's your position
200 2014-12-12 17:16:16 <sipa> the problem is that that requires a hash function and hmac implementation inside rfc6979, so you probably get code duplication, as the caller program almost certainly already has those too
201 2014-12-12 17:16:57 <lechuga_> true
202 2014-12-12 17:17:19 <lechuga_> then you have hash/hmac function ptrs or something not terribly elegant
203 2014-12-12 17:17:20 <sipa> plus, for some use cases, you want the nonce generation function to be more flexible
204 2014-12-12 17:17:30 <sipa> lechuga_: yup, see that pull request
205 2014-12-12 17:17:35 <lechuga_> saw
206 2014-12-12 17:21:43 <lechuga_> i dont completely understand whats to be gained by that PR
207 2014-12-12 17:22:00 <sipa> lechuga_: harder to shoot yourself in the foot
208 2014-12-12 17:22:07 <sipa> without losing flexibility
209 2014-12-12 17:22:21 <lechuga_> couldn't you just s/generated with a cryptographic PRNG/generated by the user either deterministically or via PRNG/ in the function description
210 2014-12-12 17:22:33 <lechuga_> ah
211 2014-12-12 17:22:46 <sipa> that doesn't change the likelyhood of shooting yourself in the foot
212 2014-12-12 17:22:51 <lechuga_> :)
213 2014-12-12 17:25:27 <aschildbach> saivann: Hi!
214 2014-12-12 17:38:31 <lechuga_> the only foot shooting i can see now is someone stuck in an infinite loop because they don't realize their nonce can;t be used
215 2014-12-12 17:56:05 <xuxu> what are the problems with stellar's design?
216 2014-12-12 17:56:52 <lechuga_> amiller lists some good discussions on the subject here: https://twitter.com/socrates1024/status/541310839811502080
217 2014-12-12 17:57:03 <lechuga_> but it's pretty much off-topic for bitcoin-dev
218 2014-12-12 20:49:12 <maraoz> I don't understand how this script is valid: https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_valid.json#L227
219 2014-12-12 20:49:57 <maraoz> shouldn't the script evaluator try to run 'abcdefghijklmnopqrstuvwxyz' as the redeemScript, given the P2SH flag is on?
220 2014-12-12 20:52:11 <ryanxcharles> maraoz: the "is P2SH" in fullnode/bitcore was subtly wrong
221 2014-12-12 20:52:26 <ryanxcharles> compare to the "is P2SH" in bitcoind
222 2014-12-12 20:52:57 <ryanxcharles> spent like an entire day figuring that one out
223 2014-12-12 20:53:56 <maraoz> ryanxcharles: ah... thanks for that info. I'll review it
224 2014-12-12 20:54:00 <Luke-Jr> maraoz: P2SH flag is only relevant when the script itself is P2SH ;)
225 2014-12-12 20:55:23 <maraoz> Luke-Jr: oops, I thought that was a a p2sh script!
226 2014-12-12 21:17:29 <maraoz> Luke-Jr: wait... is it because of the OP_PUSHDATA1? lol, tricky one
227 2014-12-12 21:18:20 <Luke-Jr> maraoz: what? It's because it isn't HASH160 <20 bytes> EQUALâ¦
228 2014-12-12 21:19:57 <Luke-Jr> ["'abcdefghijklmnopqrstuvwxyz'", "HASH160 0x4c 0x14 0xc286a1af0947f58d1ad787385b1c2c4a976f9e71 EQUAL", "P2SH,STRICTENC"],
229 2014-12-12 21:20:03 <Luke-Jr> you have 3 pushes in the scriptPubKey there
230 2014-12-12 21:21:05 <Luke-Jr> unless I'm misunderstanding the format of this
231 2014-12-12 21:22:04 <maraoz> scriptPubKey = "HASH160 0x4c 0x14 0xc286a1af0947f58d1ad787385b1c2c4a976f9e71 EQUAL"
232 2014-12-12 21:22:13 <maraoz> 0x4c = OP_PUSHDATA1
233 2014-12-12 21:23:07 <maraoz> 0x14 = 20 (1 byte size)
234 2014-12-12 21:25:53 <Luke-Jr> in any case, that isn't P2SH
235 2014-12-12 21:30:08 <maraoz> I know, thanks! It's awesome that you can still use "OP_HASH160 OP_PUSHDATA1 20 ... OP_EQUAL" without requiring the pre-image of the hash to be a script
236 2014-12-12 21:31:10 <Luke-Jr> not so awesome if Bitcore (and BitPayâ) can be tricked, though :|
237 2014-12-12 21:31:49 <Luke-Jr> ryanxcharles: I presume you reported it to them?
238 2014-12-12 21:33:12 <maraoz> nah, it's working allright in bitcore. We're re-implementing the API and that test was failing (that's what tests are for, right? we don't want regressions)
239 2014-12-12 21:34:17 <Luke-Jr> re-implementing what API? :x
240 2014-12-12 21:49:36 <maraoz> bitcore's
241 2014-12-12 21:53:45 <ryanxcharles> Luke-Jr: long and complicated story. we now have to distinct libraries, fullnode and bitcore, that share a lot of the same code. hopefully all issues fixed in one will be fixed in the other.
242 2014-12-12 22:12:08 <TheButterZone> supposedly bounty up for split-key vanity address generator coding https://bitcointalk.org/index.php?topic=890051.msg9821993#msg9821993
243 2014-12-12 22:15:57 <gmaxwell> TheButterZone: what do you mean bounty? vanitygen already supports that out of the box.
244 2014-12-12 22:18:02 <Luke-Jr> gmaxwell: it does? when you sending me optimised code? :P
245 2014-12-12 22:19:24 <TheButterZone> they're probably running vanitygen but do you remember that one site (was it BitcoinVanity.appspot.com?) where you put in your part public key that bitaddress.org gave you? they probably want either a simple submission form site so they can copy and paste into vanitygen or have it completely automated
246 2014-12-12 22:19:39 <TheButterZone> however that defunct site worked
247 2014-12-12 22:20:05 <TheButterZone> anyway, i iz not dev, bye
248 2014-12-12 22:21:15 <gmaxwell> more likely that they just want to steal people's coins.
249 2014-12-12 22:36:29 <ryan-c> Is my understanding correct that when you sign with SIGHASH_ALL|SIGHASH_ANYONECANPAY additional inputs but not additional outputs can be added?
250 2014-12-12 22:37:42 <ryan-c> re vanitygen, I actually worked out a design for a split key vanity pool that is able to reward partial work if anyone is interested.
251 2014-12-12 22:38:21 <ryan-c> (not terribly complicated to do though)
252 2014-12-12 22:38:35 <gmaxwell> ryan-c: yes.
253 2014-12-12 22:38:58 <ryan-c> gmaxwell: thanks
254 2014-12-12 22:52:33 <gmaxwell> ryan-c: yea, it's pretty easy to do that. Also it's pretty easy to support multiple targets if you don't mind the customers having to stay online.
255 2014-12-12 22:53:16 <gmaxwell> e.g. sum up the customers public shares, grind until you find something matching a single customer. ... then ask all but that customer to reveal and replace their shares... give the results to the winning customer.
256 2014-12-12 22:55:14 <ryan-c> public shares as in public keys? not sure what you mean by 'reveal and replace'
257 2014-12-12 22:56:21 <gmaxwell> Calling them public shares because they're portions of an N of N private key, but yes. pubkeys. Reveal meaning they give up their private keys (it wasn't a solution for them) and generate new ones.
258 2014-12-12 22:56:33 <gmaxwell> (and obviously you never use a 'solution' based on a private key you've given up.
259 2014-12-12 22:56:36 <gmaxwell> )
260 2014-12-12 22:56:36 <ryan-c> gmaxwell: oh, that makes sense
261 2014-12-12 22:57:51 <gmaxwell> I'd like to make a little vanity pooling thing using this, but don't really have time to port my much faster vanitygen code to a gpu. (My code is as fast on a cpu as vanitygen is on gpu).
262 2014-12-12 22:59:15 <ryan-c> gmaxwell: I started building some code for the pool, but the guy who was working on it with me decided he wasn't interested anymore so I mothballed it.
263 2014-12-12 23:00:03 <ryan-c> I'd be interested in the faster vanitygen code, might be fun for me to learn opencl on it.
264 2014-12-12 23:01:40 <ryan-c> i'd be a bit nervous about requiring all the customers stay online, I guess you could drop their public shares as soon as they're not online to minimize failed private key recovery
265 2014-12-12 23:04:17 <gmaxwell> ryan-c: yea you just have them rotate keys once a minute regardless... so at the worst you lose one minute of work.
266 2014-12-12 23:04:44 <gmaxwell> And the users can't even tell if you're rotating because you have a hit but not theirs vs rotating to check keepalive.
267 2014-12-12 23:06:35 <ryan-c> gmaxwell: ah, the customer client for the service has a "give me your private key and a new public" call for rotation or someone else's request was solved and a "here's the combined private give me a new public" for when that customer's request was solved.
268 2014-12-12 23:06:49 <gmaxwell> yes.
269 2014-12-12 23:08:25 <gmaxwell> I never really figured out a good payment model for this shared work. One thought I had was that the pool's profit is the multiple user speedup gain, users pay just the compute cost which is passed on to the miners (and offset by the mining they do themselves)
270 2014-12-12 23:10:58 <kadoban> gmaxwell: Is there any info on your faster vanitygen out there anywhere? I'm curious how you get such a drastic speedup.
271 2014-12-12 23:11:11 <ryan-c> gmaxwell: I had a bunch of notes on the possible payout models, but that sounds like a fairly good approach, maybe even passing on some of the savings from the speedup to the customers because i think that speedup savings would be an order of magnitude.
272 2014-12-12 23:11:39 <ryan-c> kadoban: the place to start is replacing openssl's elliptic curve routines
273 2014-12-12 23:11:48 <ryan-c> they are not fast
274 2014-12-12 23:11:51 <gmaxwell> I'm not using openssl at all.
275 2014-12-12 23:12:11 <kadoban> Ah, hmm
276 2014-12-12 23:12:25 <ryan-c> gmaxwell: you told me about this via pm before, donno how much of that you wanted to keep to yourself so i'll let you say more if you want
277 2014-12-12 23:12:51 <gmaxwell> well it's actually not useful for cracking, just vanitygen.
278 2014-12-12 23:13:26 <ryan-c> yeah, i was thinking that when you were telling me, but you seemed not to want to open source it
279 2014-12-12 23:13:39 <gmaxwell> I'm making use of the fact the secp256k1 is a GLV curve, so you can take any point and multiply it by (some big randomly looking number) with only a single field multiply. This alone gives a 2x speedup.
280 2014-12-12 23:14:46 <phantomcircuit> "randomly looking"
281 2014-12-12 23:14:47 <phantomcircuit> heh
282 2014-12-12 23:14:50 <gmaxwell> I'm also primarly using doubling rather than point addition with G, because with our curve equation an optimal doubling implementation is much faster than addition. (e.g. 2*P instead of P+1) thats a pretty big speedup too.
283 2014-12-12 23:15:16 <gmaxwell> phantomcircuit: well it's not actually random, it's derrived using some crazy number theory. It just doesn't have any obvious meaning like '2'.
284 2014-12-12 23:15:55 <kadoban> Interesting, thanks. I'll look into that a bit (not for any particular reason, just sounds kinda fun)
285 2014-12-12 23:17:24 <gmaxwell> I'm also making use of the fact that you can get positive and negative versions of a point by simply by writing a byte, if you're only generating compressed keys. Which is another 2x speedup.
286 2014-12-12 23:18:07 <ryan-c> gmaxwell: i think there's a gpu vanity miner with the positive/negative optimization
287 2014-12-12 23:18:17 <gmaxwell> I'm using much larger batch inversion, though batch inversion is the one thing vanitygen does (though I only need to run it on the points before the 2*2*3 expansion)
288 2014-12-12 23:18:46 <gmaxwell> Also I only need to recover the X coorid, which is only a small improvement though if you're doing it right and batching the inversion.
289 2014-12-12 23:19:30 <gmaxwell> I know another optimization that I haven't tried yet... which is that the Z ratios of the doubled jacobian points can be easily known as a side effect of the doubling, which would speed up the batch inversion.
290 2014-12-12 23:19:49 <gmaxwell> thought probably only a percent or so.
291 2014-12-12 23:20:41 <gmaxwell> In any case, if dorking with fast ECC is interesting to you, you should contribute to libsecp256k1... which now uses all these tools to the extent that they're useful for speeding up ECDSA signature validation.
292 2014-12-12 23:21:58 <ryan-c> gmaxwell: I've played around with libsecp256k1, it's about an order of magnitude faster than openssl, but I don't think I really have the math background to contribute much.
293 2014-12-12 23:24:16 <gmaxwell> The math for all this stuff is not that hard. I mean, other people have done the crazy number theory. There is plenty to be gained at the level of just doring with basic algebra... also non-mathmatical optimizations.
294 2014-12-12 23:26:12 <gmaxwell> esp just converting existing algorithims to assembly also has big room for performance speedups.
295 2014-12-12 23:26:54 <gmaxwell> Also, we're somewhat review bandwidth limited. Pieter can basically fill my review capacity on his own.
296 2014-12-12 23:27:26 <gmaxwell> "explain to me this math crap you just did" is a perfectly reasonable review response.
297 2014-12-12 23:28:22 <ryan-c> heh
298 2014-12-12 23:29:19 <ryan-c> unfortunately i can't code in assembly, though i am comfortable optimizing in c
299 2014-12-12 23:30:21 <ryan-c> ACTION needs to get some actual work done for a bit