1 2014-11-05 00:08:34 <dhill> aburan28: the entire mempool
  2 2014-11-05 03:57:16 <wangchun> gmaxwell: do you have plan to increase 1 MB block size limit in near future?
  3 2014-11-05 03:58:43 <phantomcircuit> wangchun, that is not going to happen
  4 2014-11-05 04:03:15 <netg> /
  5 2014-11-05 04:13:47 <justanotheruser> wangchun: it isn't his decision
  6 2014-11-05 04:14:40 <justanotheruser> netg: you have reached your daily limit of three /
  7 2014-11-05 04:16:13 <netg> jeah fuck, i gonna setup some script to deny me from speaking to this chan
  8 2014-11-05 04:16:16 <netg> sorry
  9 2014-11-05 06:41:19 <wumpus> sipa: fine with me, I was planning to bump pruning to 0.11 anyhow as no way it will be tested enough by time  of 0.10 release
 10 2014-11-05 06:41:57 <sipa> wumpus: i think it's pretty close - if there's hope of getting pruning in 0.10, i'd rather work on making that happen
 11 2014-11-05 06:43:25 <wumpus> in that case IMO we need to make sure it is mergable this week
 12 2014-11-05 06:44:37 <wumpus> I've called for testing for the pull both here and on twitter, someone even posted it on reddit, but it ddn't have much of an effect
 13 2014-11-05 06:45:12 <sipa> maybe maaku is right, and nobody is really interested in this without the ability to run a wallet on it...
 14 2014-11-05 06:45:20 <wumpus> that tells me it's not that urgent
 15 2014-11-05 06:45:53 <sipa> the reason i like it because it may help breaking people's (unnecessary) expectation that full nodes will always have all data
 16 2014-11-05 06:46:12 <sipa> +is
 17 2014-11-05 06:46:18 <wumpus> I agree
 18 2014-11-05 06:47:19 <wumpus> don't get me wrong, I think it's good to have it too - I'm just afraid merging it will cause some regressions too short before the release
 19 2014-11-05 06:47:35 <wumpus> (so with pruning disabled)
 20 2014-11-05 06:48:38 <wumpus> we can call the feature itself experimental - do you think merging the code change itself is unlikely to break non-pruning functionality?
 21 2014-11-05 06:49:52 <sipa> i think that should be reasonably safe, as the unexpected behaviour will be from combinations of blockindex states that are new
 22 2014-11-05 06:50:11 <sipa> but if you don't prune, that shouldn't happen, and without pruning there is even a check to see that all data is present afaik
 23 2014-11-05 06:50:42 <wumpus> ok
 24 2014-11-05 07:52:08 <gmaxwell> I've tested it through a couple times, but don't yet think it's adequate. ... really I don't care if it works: we can hide the option if we feel a bit uneasy about it. What I do care about is that it doesn't break anything else when its not being used.  But I don't want to prolong progress on it further. (esp since the person proposing the patch has been very responsive)
 25 2014-11-05 07:57:37 <wumpus> right
 26 2014-11-05 08:00:17 <wumpus> that would be another option, merge it but hide it, and don't announce it as 0.10 feature
 27 2014-11-05 08:01:11 <wumpus> ... but I'm not so sure of the advantages of that compared to merging it after the 0.10 branch
 28 2014-11-05 08:03:29 <gmaxwell> wumpus: it's also down grade incompatible if you use it, to that encourages getting it in earlier.
 29 2014-11-05 08:05:11 <wumpus> but how sure can we be that the autoprune that will end up as 'official feature' in 0.11 will still be compatible with what we merge now? if it's not adequate yet, then the implementation may still be quite unstable
 30 2014-11-05 08:05:38 <wumpus> then again if you prefer to merge it now, and sipa does too, I'm ok with it
 31 2014-11-05 08:06:18 <wumpus> I'm not against it, just a bit concerned
 32 2014-11-05 08:06:32 <gmaxwell> I think we're okay with the functionality now, and think it should probably be compatible... It's just review and testing.  Well as you should be.
 33 2014-11-05 09:09:36 <paveljanik> wumpus, cfields: now you can choose ;-)
 34 2014-11-05 09:21:15 <wumpus> I leave this to cfields :)
 35 2014-11-05 09:37:43 <sipa> wumpus: haha, the guy with nick 'wumpus' on github is having a hard time :)
 36 2014-11-05 09:37:56 <wumpus> yes poor him
 37 2014-11-05 09:39:46 <moa> one too many wumpi
 38 2014-11-05 09:40:02 <wumpus> wonder if github has an option to ignore mentions in a certain project
 39 2014-11-05 09:41:19 <paveljanik> I have to apologize to him ;-)
 40 2014-11-05 09:41:56 <wumpus> yes you should ;-)
 41 2014-11-05 09:45:04 <paveljanik> done ;-)
 42 2014-11-05 10:47:09 <CodeShark> would anyone happen to have any statistics on percentage of transactions that are pay-to-script-hash?
 43 2014-11-05 10:47:24 <CodeShark> or better yet, a tool that can scan the blockchain and construct a pretty graphic? :)
 44 2014-11-05 10:50:26 <moa> http://blog.greenaddress.it/2014/08/19/pay-to-script-hash-stats/
 45 2014-11-05 10:50:33 <moa> CodeShark: ^^
 46 2014-11-05 10:51:02 <CodeShark> ah, thank you :)
 47 2014-11-05 10:51:08 <moa> http://p2sh.info/
 48 2014-11-05 10:51:09 <gmaxwell> moa: thanks thats exatly the page I was looking for.
 49 2014-11-05 10:51:13 <moa> is the source
 50 2014-11-05 10:51:18 <moa> which i recalled
 51 2014-11-05 10:51:42 <moa> 1.4%
 52 2014-11-05 10:52:01 <CodeShark> wonderful, thank you
 53 2014-11-05 11:20:07 <Elbandi> hi, i need a little coding help
 54 2014-11-05 11:20:09 <Elbandi> But i dont know how to modify the TraceThread function to pass parameter(s).
 55 2014-11-05 11:20:09 <Elbandi> I make a new feature for bitcoin, and i need to run thread with parameter.
 56 2014-11-05 11:20:12 <Elbandi> https://github.com/bitcoin/bitcoin/blob/master/src/util.h#L200
 57 2014-11-05 11:20:15 <Elbandi> can anyone help me? my knowledge for this c++ "magic" is poor :(
 58 2014-11-05 11:23:03 <CodeShark> what do you not get about it?
 59 2014-11-05 11:23:18 <CodeShark> oh, you need to add a parameter...
 60 2014-11-05 11:23:53 <CodeShark> you could bind the parameter to a function and then pass that
 61 2014-11-05 11:24:01 <CodeShark> using boost::bind or something like that
 62 2014-11-05 11:25:16 <wumpus> make a template <typename Callable, typename T> void TraceThread(const char* name,  Callable func, T arg)  ... func(arg)?
 63 2014-11-05 11:25:44 <CodeShark> you can also do that :)
 64 2014-11-05 11:25:46 <wumpus> then indeed use boost::bind (which is already used) to bind the arg
 65 2014-11-05 11:29:17 <CodeShark> you can write a class for a callable object where its constructor can automatically bind the arguments for you
 66 2014-11-05 11:29:56 <wumpus> essentially what boost::bind does
 67 2014-11-05 11:30:40 <CodeShark> you wouldn't even need to make an additional TraceThread template
 68 2014-11-05 11:31:31 <Elbandi> yeah, i want to modity the current TraceThread
 69 2014-11-05 11:31:31 <wumpus> indeed! you don't, you could use boost::bind() to curry the argument into the function that you pass into it
 70 2014-11-05 11:32:04 <CodeShark> TraceThread("MyFunc", boost::bind(MyFunc, param1, param2, …));
 71 2014-11-05 11:38:13 <wumpus> CodeShark: hah, it's not so easy
 72 2014-11-05 11:38:39 <wumpus> e.g. this doesn't work (with ThreadMessageHandler(int) ): threadGroup.create_thread(boost::bind(&TraceThread<void (*)()>, "msghand", boost::bind(&ThreadMessageHandler, 10)));
 73 2014-11-05 11:38:58 <Elbandi> thx, i think, i pull the feature without threaded, i dont want to work unnecessarily if devs dont like my feature...
 74 2014-11-05 11:39:42 <wumpus> why not bypass TraceThread at first, just use thread_group.create_thread() and write your own tracing around it
 75 2014-11-05 11:40:06 <CodeShark> indeed
 76 2014-11-05 11:41:22 <CodeShark> C++11 lambdas provide an even more elegant solution :)
 77 2014-11-05 11:41:44 <wumpus> sure
 78 2014-11-05 11:41:56 <Elbandi> that a big "magic" for me :(
 79 2014-11-05 11:42:04 <wumpus> but unnecessary, I mean, passing an argument to a  thread anno 2014 should be a solved problem
 80 2014-11-05 11:44:01 <CodeShark> well, it took until recently for threading to even become a standard part of the C++ language
 81 2014-11-05 11:44:18 <CodeShark> or at least a part of the standard C++ libs
 82 2014-11-05 11:45:09 <wumpus> ... yes, it's sad when you think about it
 83 2014-11-05 11:46:19 <wumpus> so many years into the internet age and threading and networking aren't part of the standard library
 84 2014-11-05 11:46:50 <wumpus> well, threading now is
 85 2014-11-05 11:48:41 <CodeShark> as far as networking, berkeley sockets became the de facto "standard" initially…but writing async apps with berkeley sockets is a real pain in the ass
 86 2014-11-05 11:49:24 <CodeShark> the closest we have to a C++ networking standard right now is probably asio
 87 2014-11-05 11:50:45 <wumpus> nah, windows doesn't really implement berkeley sockets
 88 2014-11-05 11:51:29 <CodeShark> winsock! :)
 89 2014-11-05 11:51:31 <wumpus> a language-level standard would have made sense  - even if it was at the C level, not the C++ level... heck, even Java got that right
 90 2014-11-05 11:52:06 <CodeShark> the one thing I like about the Java ecosystem is the libraries and consistency in style convention
 91 2014-11-05 11:52:17 <CodeShark> but I think that's about it :p
 92 2014-11-05 11:53:09 <CodeShark> to be fair, though, Java was developed specifically with the intention of being able to serve applications over a network
 93 2014-11-05 11:53:27 <wumpus> but that was in the 90's
 94 2014-11-05 11:53:51 <wumpus> we're in the 10's now and we still have to worry about platform-specific networking and threading
 95 2014-11-05 11:54:42 <ubuntu_> 
 96 2014-11-05 11:54:45 <CodeShark> asio and std::thread seem to work ok :)
 97 2014-11-05 11:55:20 <wumpus> I'd be fine with that if people would finally stop complaining about boost
 98 2014-11-05 11:55:45 <CodeShark> boost has become a testing ground for what are likely to become future std features
 99 2014-11-05 11:58:50 <CodeShark> wumpus: why have people been complaining about boost?
100 2014-11-05 11:59:48 <wumpus> CodeShark: because it gives some dependency issues with dynamic linking on some platforms, ask cfields
101 2014-11-05 11:59:49 <HM_> boost is awesome
102 2014-11-05 12:00:12 <HM_> it lets me write fewer lines of code but at a slower line rate
103 2014-11-05 12:00:43 <CodeShark> I suspected it might have been cfields complaining :)
104 2014-11-05 12:00:44 <HM_> and 50 times as many ">" and "<" tokens
105 2014-11-05 12:01:18 <wumpus> CodeShark: well not only him, but he has the most convincing argument to not use it in the consensus liibrary...
106 2014-11-05 12:02:09 <CodeShark> only some parts of boost require such linking - much of it is headers-only
107 2014-11-05 12:03:01 <wumpus> indeed
108 2014-11-05 12:04:23 <HM_> wumpus, std::thread
109 2014-11-05 12:04:36 <wumpus> HM_: huh?
110 2014-11-05 12:05:00 <HM_> oh nm
111 2014-11-05 12:05:09 <HM_> i thought CodeShark had said use boost::thread
112 2014-11-05 12:05:36 <wumpus> we already use boost::thread, and will migrate to std::thread when that makes sense, but thanks...
113 2014-11-05 12:06:13 <CodeShark> %s/boost::thread/std::thread/g :)
114 2014-11-05 12:07:01 <CodeShark> still waiting for std::asio :)
115 2014-11-05 12:07:26 <wumpus> indeed
116 2014-11-05 12:07:27 <HM_> I'm praying they're conservative when importing asio
117 2014-11-05 12:08:00 <wumpus> or *any useful network library at all*
118 2014-11-05 12:08:17 <wumpus> just standardize on something already
119 2014-11-05 12:09:12 <CodeShark> https://github.com/ciphrex/CoinVault/blob/master/deps/CoinQ/src/CoinQ_peer_io.cpp
120 2014-11-05 12:10:25 <HM_> sexy use of std algorithms
121 2014-11-05 12:10:54 <HM_> like ermahgerd, you're using std::search
122 2014-11-05 12:12:21 <HM_> CodeShark, very nice
123 2014-11-05 12:12:26 <CodeShark> thx :)
124 2014-11-05 12:15:36 <HM_> CodeShark, boost::shared_ptr<uchar_vector> data(new ...
125 2014-11-05 12:15:45 <HM_> you should replace this pattern with boost::make_shared
126 2014-11-05 12:16:00 <CodeShark> what would be the advantage?
127 2014-11-05 12:17:11 <HM_> CodeShark, shared_ptr has heap allocated shared state, make_shared combines the allocations for T and that shared state
128 2014-11-05 12:17:31 <CodeShark> ah - interesting point
129 2014-11-05 12:17:42 <HM_> also it enables shared_from_this if you want to use it with class types
130 2014-11-05 12:18:57 <timothy> hi, to uniform archlinux with the rest of the world (BDB version), I'd like to use the "suggested" BDB version to build bitcoin
131 2014-11-05 12:19:26 <timothy> the problem is that actually the bitcoin packages are using 5.3.28, any advice to support downgrade?
132 2014-11-05 12:19:46 <timothy> something like database backup using new version and import to old version?
133 2014-11-05 12:19:57 <wumpus>  db5.1_dump wallet.dat.db5 | db4.8_load wallet.dat.db4
134 2014-11-05 12:21:54 <HM_> timothy, there are multiple versions in AUR
135 2014-11-05 12:22:00 <HM_> not sure if they can be installed in parallel
136 2014-11-05 12:33:29 <CodeShark> I haven't ever found the need to import wallets created using older versions :p
137 2014-11-05 12:33:40 <CodeShark> so I always use the newest BDB if I must use the bitcoind wallet
138 2014-11-05 12:34:02 <CodeShark> or rather, I haven't ever found the need to export my wallets to older versions
139 2014-11-05 12:34:56 <CodeShark> in any case, if I really want to keep a wallet backup I'd export to a universally portable format, like base58 priv keys
140 2014-11-05 12:35:37 <CodeShark> we really shouldn't be depending on the specifics of the database engine for backups
141 2014-11-05 12:35:51 <wumpus> use the dumpwallet/importwallet RPC?
142 2014-11-05 12:35:58 <CodeShark> right
143 2014-11-05 12:35:59 <HM_> i'd probably go with a brainwallet printout buried in my grandmas photo album
144 2014-11-05 12:36:13 <sipa> HM_: if you print it, it's not a brainwallet
145 2014-11-05 12:36:44 <HM_> even if you encode it as a sudoku puzzle? :(
146 2014-11-05 12:37:16 <HM_> actually that would be a pretty cool steganography hack. i wonder how much entropy is in a sudoku puzzle
147 2014-11-05 12:37:16 <wumpus> *huh, what is this brain doing in my grandmas photo album*
148 2014-11-05 12:37:34 <CodeShark> grandma was a neurosurgeon
149 2014-11-05 12:39:57 <CodeShark> interestingly, the specifics of the database engine have come to bite us in the ass at least once when it comes to blockchain storage :p
150 2014-11-05 12:41:22 <CodeShark> so for the consensus code, database version is pretty important
151 2014-11-05 12:41:33 <CodeShark> but for the wallet, meh :p
152 2014-11-05 12:41:54 <wumpus> well, yes, it be annoying at most for the wallet
153 2014-11-05 12:42:25 <wumpus> (ie, if you go from your own compiled version with 5.x to downloaded binary with 4.8 you have to manually downgrade)
154 2014-11-05 12:42:47 <HM_> Aren't wallets small enough to warrant a simplistic format?
155 2014-11-05 12:43:09 <wumpus> depends
156 2014-11-05 12:43:21 <wumpus> there's the wide gap between simple personal wallets and enterprise stuff
157 2014-11-05 12:43:42 <HM_> CSV = personal, XML = enterprise :}
158 2014-11-05 12:43:51 <CodeShark> people still use XML?
159 2014-11-05 12:43:55 <wumpus> but every wallet I know uses some form of database
160 2014-11-05 12:44:06 <wumpus> even the android/bitcoinJ ones IIRC
161 2014-11-05 12:44:18 <HM_> sqlite?
162 2014-11-05 12:44:31 <CodeShark> my wallet supports several SQL databases but can also export to a serialized text file
163 2014-11-05 12:44:54 <wumpus> it's not necessary of course, but if you have (changable) metadata associated with transactions it's no longer just a dumb list of keys
164 2014-11-05 12:45:35 <CodeShark> data migration isn't an entirely trivial issue
165 2014-11-05 12:46:53 <wumpus> sure, you can always export to a serialized text file
166 2014-11-05 12:48:34 <HM_> well that's disappointing
167 2014-11-05 12:48:46 <HM_> there are only 6,670,903,752,021,072,936,960 different 9x9 sudoku puzzles
168 2014-11-05 12:48:53 <HM_> ~72 bits
169 2014-11-05 12:49:03 <CodeShark> use two of them :)
170 2014-11-05 12:50:42 <CodeShark> or use key stretching
171 2014-11-05 12:52:48 <HM_>  12×12 would probably cut it
172 2014-11-05 12:54:53 <CodeShark> that's actually a really interesting idea - problem is if it becomes too common it becomes practically useless
173 2014-11-05 12:55:04 <sipa> why?
174 2014-11-05 12:55:44 <CodeShark> well, I suppose you could still use a secret key to transform the puzzle into your entropy bits
175 2014-11-05 12:56:03 <CodeShark> but the whole point of steganography is to hide the fact that you're hiding something
176 2014-11-05 12:56:47 <CodeShark> if everyone starts using sudoku puzzles for paper backups your backups become more suspect
177 2014-11-05 12:56:49 <HM_> stick it on your fridge, nobody will ever suspect. they'll just think you're reaaally bad as sudoku
178 2014-11-05 12:57:40 <HM_> and if you want to troll you go to a bitcoin hackathon and litter the place with sudoku puzzles :P
179 2014-11-05 12:57:48 <CodeShark> lol
180 2014-11-05 12:58:10 <Luke-Jr> ugh, these black icons are ugly
181 2014-11-05 12:58:25 <CodeShark> don't be an icon racist
182 2014-11-05 12:58:48 <Luke-Jr> HM_: CSV/XML maybe makes sense for user-servicable data, but wallets are not that.
183 2014-11-05 12:59:02 <Luke-Jr> CodeShark: pfft, the black icons are icon-racist against every other colour!
184 2014-11-05 13:00:23 <HM_> and once someone comes up with OCR for sudoku puzzles you start generating them as mangled captchas, then we end up in this weird  Salvador Dalí realisation where everyone is sitting around with contorted faces trying to solve contorted sudoku puzzles
185 2014-11-05 13:01:43 <wumpus> hehe
186 2014-11-05 13:02:10 <Luke-Jr> one time I wrote down an ECDSA privkey as a form of art.
187 2014-11-05 13:02:22 <Luke-Jr> whether I could decipher it later or not, I was unsure enough to never use it <.<
188 2014-11-05 13:04:56 <CodeShark> this idea can be nicely abstracted, though - you could provide any collection whose members can be systematically derived from the input in an injective map
189 2014-11-05 13:05:13 <CodeShark> a map that can be easily inverted
190 2014-11-05 13:05:47 <CodeShark> so all you need to do is provide the code to derive the collection member
191 2014-11-05 13:06:17 <HM_> yes...what you said
192 2014-11-05 13:06:54 <CodeShark> someone could use sudoku puzzles, someone else might use rubik's cube states
193 2014-11-05 13:07:47 <HM_> lol rubik cube states is evil, because you have to take the output of your program and actually configure your rubik cube to match it
194 2014-11-05 13:08:01 <HM_> you'd need an ancillary program that helped you with that
195 2014-11-05 13:08:06 <Luke-Jr> lol
196 2014-11-05 13:08:15 <CodeShark> it's not too hard to map the natural numbers to rubik's cube states
197 2014-11-05 13:08:30 <CodeShark> there are only so many different possible permutations and rotations
198 2014-11-05 13:09:14 <HM_> then you're going to want to dip the thing in glue, lest a child gets hold of it, or you get very bored one day while day dreaming
199 2014-11-05 13:09:27 <Luke-Jr> one time I was frustrated by a rubik's cube, so I cheated and entered its state into an online solver
200 2014-11-05 13:09:31 <CodeShark> or just take a couple photographs of it from different angles
201 2014-11-05 13:09:35 <Luke-Jr> turned out it was acutally impossible :/
202 2014-11-05 13:09:43 <CodeShark> I wrote a solver for 2x2x2
203 2014-11-05 13:10:01 <CodeShark> the 3x3x3 has been solved…but it requires something a little more clever than mere brute force
204 2014-11-05 13:10:04 <CodeShark> to be feasible
205 2014-11-05 13:10:51 <CodeShark> a brute force solver is essentially the same as chess endgame tablebases
206 2014-11-05 13:11:28 <CodeShark> you start from the won/solved position and work backwards
207 2014-11-05 13:11:53 <CodeShark> and track the distance between each state and the won/solved position
208 2014-11-05 13:11:57 <wumpus> HM_: hah, yes, I'd also be scared of that when using the old permutation of playing cards idea, someone may pick it up and shuffle it :p
209 2014-11-05 13:12:58 <HM_> because people still play with playing cards outside of a gambling context? :P
210 2014-11-05 13:13:15 <HM_> maybe if there's a solar flare and the planet loses power for 3 days
211 2014-11-05 13:15:09 <Luke-Jr> wumpus: is the 0.9.x branch still maintained in the master github?
212 2014-11-05 13:16:13 <wumpus> Luke-Jr: when necessary (ie a problem appears that needs to be backported)
213 2014-11-05 13:16:22 <CodeShark> here's a skewb puzzle solver I wrote: https://github.com/CodeShark/skewb/blob/master/src/skewb.cpp
214 2014-11-05 13:17:21 <wumpus> HM_: well in that case I'd be more worried about not being eaten than about my bitcoins :)
215 2014-11-05 13:17:38 <CodeShark> all rubik's-like puzzles can be brute-forced essentially like this…but beyond a certain statespace size it becomes infeasible :)
216 2014-11-05 13:18:34 <HM_> unless you're the NSA</conspiracy>
217 2014-11-05 13:18:46 <HM_> they've been working on theirs since the 70s ;)
218 2014-11-05 13:19:16 <HM_> i think they may have even engineered a backdoor in to the Rubik cube design ;)
219 2014-11-05 13:19:23 <CodeShark> lol
220 2014-11-05 13:19:34 <wumpus> hehe
221 2014-11-05 13:23:16 <wumpus> CodeShark: one kind of puzzle that I noticed doesn't yield to naive brute forcing that well is the sliding puzzle
222 2014-11-05 13:23:47 <HM_> patents are literally the reason we can't have nice things
223 2014-11-05 13:23:55 <wumpus> just too many possible sequences of moves (even if you exclude loops)
224 2014-11-05 13:24:28 <HM_> TLS-SRP went to RFC with SHA1 as the password deriviation function :(, unless you control the client and pre-stretch the password it's useless, and doing so wouldn't be interopable.
225 2014-11-05 13:24:31 <CodeShark> wumpus: let's see…for the 15 tile slide puzzle there are essentially 16! permutations, right?
226 2014-11-05 13:24:44 <CodeShark> assuming all permutations are reachable
227 2014-11-05 13:24:47 <CodeShark> which we have to prove
228 2014-11-05 13:24:57 <wumpus> not all permutations are reachable :-)
229 2014-11-05 13:25:10 <CodeShark> only odd permutations?
230 2014-11-05 13:25:14 <CodeShark> I mean
231 2014-11-05 13:25:14 <wumpus> you can never swap two tiles
232 2014-11-05 13:25:19 <CodeShark> only even permutations are reachable
233 2014-11-05 13:25:24 <CodeShark> so then 16!/2
234 2014-11-05 13:26:25 <CodeShark> 10,461,394,944,000
235 2014-11-05 13:26:43 <CodeShark> that's feasible with today's computers
236 2014-11-05 13:28:11 <CodeShark> err…wait
237 2014-11-05 13:28:29 <CodeShark> I'm not convinced only even permutations are reachable
238 2014-11-05 13:28:40 <CodeShark> the empty tile can surely be swapped with any adjacent tile
239 2014-11-05 13:28:57 <CodeShark> oh...
240 2014-11-05 13:29:10 <CodeShark> but then the next tile move also swaps with the empty tile
241 2014-11-05 13:30:40 <CodeShark> then there might be some symmetries that would allow us to limit the search space
242 2014-11-05 13:31:08 <CodeShark> but let's say the number is less than 16! for sure :)
243 2014-11-05 13:31:49 <sipa> HM_: what's wrong with SHA1 for derivation?
244 2014-11-05 13:36:02 <CodeShark> for the sliding puzzle there's probably an algorithmic approach to finding the shortest solution
245 2014-11-05 13:36:11 <CodeShark> that doesn't require brute force
246 2014-11-05 13:36:32 <CodeShark> because every move only affects one tile
247 2014-11-05 13:37:24 <CodeShark> with rubik's-like puzzles, it's often the case that the shortest solution (in terms of number of moves) is not the most human-intuitive solution
248 2014-11-05 13:38:08 <CodeShark> human-intuitive solutions tend to isolate portions of the state space and operate on them independently
249 2014-11-05 13:38:40 <fanquake> Are we talking sliding puzzles like this?
250 2014-11-05 13:38:47 <fanquake> http://n-puzzle-solver.appspot.com/
251 2014-11-05 13:39:27 <CodeShark> yes
252 2014-11-05 13:39:49 <wumpus> CodeShark: yes AFAIK for the NxN sliding puzzles there are more efficient solutions, my point was just that they don't yield to brute force very well. For more general sliding block puzzles there are none, you can even build logic gates from them, e.g. see http://groups.csail.mit.edu/mac/users/bob/sliding-blocks.pdf  :)
253 2014-11-05 13:40:51 <CodeShark> heh, neat :
254 2014-11-05 13:40:54 <CodeShark> :)
255 2014-11-05 13:41:09 <gribble> Error: "bloks" is not a valid command.
256 2014-11-05 13:41:09 <sipa> ;;bloks
257 2014-11-05 13:41:10 <sipa> ;;blocks
258 2014-11-05 13:41:12 <gribble> 328679
259 2014-11-05 13:41:42 <sontol> hi guys
260 2014-11-05 13:41:55 <sontol> I'm planning to create opencl version of libsecp256k1
261 2014-11-05 13:42:05 <sontol> anyone has good testcase program?
262 2014-11-05 13:42:15 <sipa> sontol: the existing unit tests  in libsecp256k1? :)
263 2014-11-05 13:42:23 <sontol> the bench?
264 2014-11-05 13:42:27 <sipa> the bench_verify program
265 2014-11-05 13:42:31 <sipa> or the tests programs
266 2014-11-05 13:42:32 <sontol> i thought that one only supposed to return 0/10000??
267 2014-11-05 13:42:35 <HM_> 
ACTION grumbles something about Intel and opencl on Linux

268 2014-11-05 13:42:50 <sontol> at least when i read the program
269 2014-11-05 13:43:03 <sipa> sontol: not anymore
270 2014-11-05 13:43:07 <sontol> oh
271 2014-11-05 13:43:08 <sontol> ok
272 2014-11-05 13:43:13 <sontol> will take a look again
273 2014-11-05 13:43:14 <sipa> it just doesn't do anything but run
274 2014-11-05 13:44:27 <sontol> is that the one in bitcoin's repo?
275 2014-11-05 13:44:40 <sipa> yes, that's the upstream repo
276 2014-11-05 13:45:17 <sipa> sontol: are you looking for a benchmark or for testing code correctness?
277 2014-11-05 13:45:24 <sontol> code correctness
278 2014-11-05 13:45:34 <sipa> there are plenty of unit tests in tests
279 2014-11-05 13:45:37 <sipa> src/tests.c
280 2014-11-05 13:46:38 <sontol> I see
281 2014-11-05 13:46:50 <HM_> I'm surprised nobody has done a CL variant of k1 already
282 2014-11-05 13:47:20 <sipa> well there's oclvanitygen :)
283 2014-11-05 13:47:32 <sontol> do you have the link for the upstream version?
284 2014-11-05 13:47:39 <sipa> sontol: you have it
285 2014-11-05 13:47:45 <sipa> sontol: github.com/bitcoin/secp256k1
286 2014-11-05 13:47:49 <sontol> oh ok
287 2014-11-05 13:47:57 <sontol> it's not standalone anymore?
288 2014-11-05 13:48:03 <sipa> define 'standalone' ?
289 2014-11-05 13:48:21 <sontol> i thought last time i could just download libsecp256k1 only
290 2014-11-05 13:48:27 <sipa> you still can
291 2014-11-05 13:48:34 <sipa> in fact, there is no other way
292 2014-11-05 13:48:35 <CodeShark> you can also use git subtree :)
293 2014-11-05 13:48:37 <sontol> i mean not inside the bitcoin
294 2014-11-05 13:48:40 <sontol> yeah
295 2014-11-05 13:48:44 <sipa> it's not part of bitcoin
296 2014-11-05 13:48:45 <sontol> still a github noob
297 2014-11-05 13:48:57 <sipa> just hosted under the bitcoin project
298 2014-11-05 13:49:17 <sontol> let me take another look
299 2014-11-05 13:49:34 <sipa> git clone https://github.com/bitcoin/secp256k1
300 2014-11-05 13:49:43 <sipa> and you'll get a repo with the latest code, and just libsecp256k1
301 2014-11-05 13:50:17 <sontol> yup
302 2014-11-05 13:50:19 <sontol> thanks
303 2014-11-05 13:50:39 <HM_> sipa, oclvanitygen presumably doesn't need all the operations?
304 2014-11-05 13:50:41 <sipa> CodeShark: i know it's been a while since you contributed anything, but by now signing should be entirely constant time in (except for potential doubling/cancellation during multiplication, which should be non-exploitable through blinding)
305 2014-11-05 13:50:45 <sontol> i believe i can get the precompute part faster
306 2014-11-05 13:50:55 <sontol> and get a larger table
307 2014-11-05 13:51:06 <sipa> faster... i doubt it
308 2014-11-05 13:51:11 <CodeShark> sipa: neat - what about cache access patterns? :)
309 2014-11-05 13:51:15 <sipa> CodeShark: dealt with
310 2014-11-05 13:51:48 <sipa> sontol: i doubt that constructing the table takes longer than sending work to the GPU and getting it back (but i'm no OpenCL expert)
311 2014-11-05 13:52:05 <sipa> and it's already very large...
312 2014-11-05 13:52:10 <sontol> well
313 2014-11-05 13:52:21 <sontol> i'm not really sure as well
314 2014-11-05 13:52:47 <sontol> basically i'm trying to get 2x,4x,6x,8x,...
315 2014-11-05 13:53:28 <sipa> you need 1x,3x,5x,7x,9x for wnaf
316 2014-11-05 13:53:43 <sontol> yeah
317 2014-11-05 13:53:49 <sontol> just subtract by 1
318 2014-11-05 13:53:57 <sontol> which can be one all at once
319 2014-11-05 13:54:04 <sipa> eh no
320 2014-11-05 13:54:16 <sontol> ??
321 2014-11-05 13:54:29 <sontol> first i get 2,4,6
322 2014-11-05 13:54:38 <sontol> 8 and 10 can be done in parallel
323 2014-11-05 13:54:42 <sipa> ah, i see
324 2014-11-05 13:54:46 <sontol> from 6+2 and 6+4
325 2014-11-05 13:54:49 <sipa> yeah, got it
326 2014-11-05 13:55:05 <sontol> not sure how i good it is though
327 2014-11-05 13:55:26 <sipa> precomputing currently takes 5ms here
328 2014-11-05 13:57:00 <sipa> CodeShark: it's a bit dense, but it's described here: https://github.com/bitcoin/secp256k1/blob/master/src/ecmult_gen_impl.h#L14-25
329 2014-11-05 13:58:01 <CodeShark> for signing performance isn't that big of an issue, though - so even a relatively inefficient implementation that's transparently constant-time will probably do
330 2014-11-05 13:59:02 <sipa> iirc it caused a 50% slowdown or when the byte slicing was introduced
331 2014-11-05 13:59:09 <sipa> *or so
332 2014-11-05 14:00:42 <sipa> sontol: more interesting use of OpenCL would be to just do multiple EC multiplications in parallel
333 2014-11-05 14:00:57 <sipa> sontol: so validation wouldn't actually be made faster, but you could do many validations at the same time
334 2014-11-05 14:01:03 <sipa> which is relevant when validating a block
335 2014-11-05 14:01:07 <sontol> hmmm
336 2014-11-05 14:02:06 <sontol> it will require you to change the downstream code though
337 2014-11-05 14:02:08 <sontol> right?
338 2014-11-05 14:02:20 <sipa> sure
339 2014-11-05 14:03:02 <sipa> but it's not like you can replace a C library with an OpenCL-based version just as a drop-in replacement either
340 2014-11-05 14:03:13 <sipa> things like OS integration, dependencies, ...
341 2014-11-05 14:06:16 <CodeShark> validation jobs could be formatted in some standard fashion
342 2014-11-05 14:06:17 <sontol> yeah
343 2014-11-05 14:06:43 <sontol> I've just started on opencl as well
344 2014-11-05 14:07:04 <sontol> just want to get some practice
345 2014-11-05 14:07:09 <sontol> to get a hang of it
346 2014-11-05 14:08:10 <CodeShark> the validation engine could check the block header, outpoints, and scripts - then produce a list of ecdsa keys, hashes, and signatures
347 2014-11-05 14:08:24 <CodeShark> then send it off to be validated by a separate process
348 2014-11-05 14:08:40 <sipa> CodeShark: what if you have an OP_CHECKSIG OP_NOT? :)
349 2014-11-05 14:08:52 <CodeShark> lol
350 2014-11-05 14:09:05 <sipa> (it's still possible, but you need some pretty complex logic to combine the results again, unfortunately)
351 2014-11-05 14:10:10 <CodeShark> in principle yes - but in practice, perhaps no
352 2014-11-05 14:10:21 <CodeShark> we're not really using very much of the bitcoin script anyhow
353 2014-11-05 14:10:35 <sipa> doesn't matter, if you do it wrong, you're vulnerable to a fork
354 2014-11-05 14:10:55 <sipa> you can of course recognize the common case, and accelerate that, and do the special cases separately
355 2014-11-05 14:11:00 <CodeShark> if 99.9% of cases can be dealt with easily, we can just detect the other .1% and handle it separately
356 2014-11-05 14:11:09 <hearn> hey sipa
357 2014-11-05 14:11:10 <sipa> what if it's suddenly not 0.1%?
358 2014-11-05 14:11:14 <sipa> hi hearn!
359 2014-11-05 14:12:10 <sipa> CodeShark: in general you should aim to optimize the worst case, and not the expected case, or you introduce a potential remotely-triggerable performance reduction
360 2014-11-05 14:12:39 <CodeShark> sipa: in any case, the script logic could be dealt with by the validation engine and only the ecdsa validation delegated to the separate process
361 2014-11-05 14:12:52 <CodeShark> the ecdsa validator could return a vector of results
362 2014-11-05 14:13:00 <sipa> yup
363 2014-11-05 14:14:30 <wumpus> yes just queue and batch and pipeline, I'm not sure how well it would work with OpenCL in practice though, most vector processors (say GPUs) work best when nearby threads follow approximately the same code path, if they don't then performance can seriously break down
364 2014-11-05 14:15:15 <sipa> wumpus: EC multiplication is actually pretty much fixed code paths
365 2014-11-05 14:15:20 <wumpus> okay
366 2014-11-05 14:15:38 <sipa> there are a few branches, but they should pretty much never occur
367 2014-11-05 14:16:53 <sipa> ed25519 is nicer in that regard, as it has no branches afaik
368 2014-11-05 14:17:40 <wumpus> would work pretty well then, although non-locality of memory access could still be a problem (ie, nearby threads preferably access nearby memory)
369 2014-11-05 14:18:08 <wumpus> so big random-access lookup tables are bad
370 2014-11-05 14:18:37 <sipa> oh, i'm confused
371 2014-11-05 14:18:51 <sipa> in verification there is a pretty strong branching effect
372 2014-11-05 14:19:16 <sipa> when using wNAF for the multiplication
373 2014-11-05 14:19:36 <sipa> i think you can have a branch-free variant though with only slightly worse average performance
374 2014-11-05 14:27:49 <HM_> sipa, looking at the tree, libsecp256k1 is looking to be merged in to the daemon?
375 2014-11-05 14:28:01 <sipa> HM_: yes, but just for signing
376 2014-11-05 14:28:20 <sipa> (for now)
377 2014-11-05 14:29:10 <CodeShark> signing is only for the wallet - which shouldn't be part of the daemon to begin with :p
378 2014-11-05 14:29:15 <HM_> have you verified the entire blockchain with it yet?
379 2014-11-05 14:29:58 <sipa> HM_: of course
380 2014-11-05 14:30:05 <sipa> but that's not really an interesting test
381 2014-11-05 14:30:14 <sipa> you need to know whether it rejects all invalid things too :)
382 2014-11-05 14:30:21 <sipa> and all possible valid things you don't know about
383 2014-11-05 14:30:44 <CodeShark> is the openssl maleability issue fixed?
384 2014-11-05 14:31:09 <sipa> CodeShark: i know of no such thing
385 2014-11-05 14:31:16 <sipa> BER is malleable, and ECDSA are malleable
386 2014-11-05 14:31:23 <sipa> openssl just implements both
387 2014-11-05 14:32:01 <CodeShark> ECDSA are malleable?
388 2014-11-05 14:32:17 <CodeShark> I mean, sure, you could use a different random k
389 2014-11-05 14:32:21 <CodeShark> but that's not what I mean
390 2014-11-05 14:32:34 <sipa> ECDSA is inherently malleable, by changing the sign of s
391 2014-11-05 14:32:56 <sipa> and BER is malleable because there are multiple encodings for the same value
392 2014-11-05 14:33:38 <sipa> oh, in addition OpenSSL adds indeed one of its own: it accepts negative numbers, and interprets them mod 2^256
393 2014-11-05 14:33:55 <sipa> all of that is dealt with in BIP62, which i'm still working on
394 2014-11-05 14:33:58 <CodeShark> it would be nice if the encoding was unique - but even if it isn't, can we say for sure we're aware of all the different possible encodings that the current implementation will accept?
395 2014-11-05 14:34:05 <sipa> no
396 2014-11-05 14:34:17 <sipa> there is no proof that ECDSA isn't malleable beyond what we already know
397 2014-11-05 14:34:50 <CodeShark> but ECDSA malleability in and of itself doesn't pose too significant a problem, does it? it's the BER encoding that does
398 2014-11-05 14:34:58 <sipa> all of them do
399 2014-11-05 14:35:03 <sipa> see BIP62
400 2014-11-05 14:35:17 <sipa> it describes all known ways to introduce malleability in scripts, and they're all equally bad
401 2014-11-05 14:36:10 <sipa> i'm not sure why BER malleability would be worse than ECDSA?
402 2014-11-05 14:36:38 <CodeShark> the most significant problem is disagreement in what constitutes a valid signature in different implementations
403 2014-11-05 14:37:18 <CodeShark> as long as all implementations agree that taking the negative s does not invalidate it, we're ok
404 2014-11-05 14:37:22 <sipa> that's indeed a serious problem, but is independent from malleability
405 2014-11-05 14:37:35 <CodeShark> let me qualify my last statement
406 2014-11-05 14:37:42 <sipa> yes i know what you're saying
407 2014-11-05 14:37:46 <CodeShark> it would be desirable for there to be no malleability at all
408 2014-11-05 14:37:55 <sipa> but you're not talking about malleability, just about uncertainty of the actually implemented rules
409 2014-11-05 14:37:56 <CodeShark> but it is absolutely essential that we don't get forking behavior
410 2014-11-05 14:38:29 <sipa> and BIP62 actually does fix that too (and is my primary interest in getting it deployed)
411 2014-11-05 14:39:02 <sipa> by requiring strict DER (even for transactions that don't choose to use the malleability protection offered by it)
412 2014-11-05 14:41:22 <CodeShark> eliminating malleability is a stronger condition…and should imply no forking behavior
413 2014-11-05 14:42:06 <sipa> well you can't eliminate malleability entirely (the sender can as you say always choose to sign again with a different k)
414 2014-11-05 14:42:27 <sipa> and we can't elimate unknown implementation behaviour either
415 2014-11-05 14:43:13 <sipa> CodeShark: anyway, one of the reasons for wanting libsecp256k1, even if just for signing, is the ability to use deterministic k
416 2014-11-05 14:43:30 <sipa> which OpenSSL still doesn't suppot
417 2014-11-05 14:43:40 <CodeShark> you can't tell openssl to use a specific k?
418 2014-11-05 14:44:11 <sipa> no
419 2014-11-05 14:44:17 <sipa> it uses its own randomizer
420 2014-11-05 14:44:28 <sipa> (which is decent, but it shouldn't be necessary)
421 2014-11-05 14:44:46 <CodeShark> yeah, that is a good reason - the randomizer is a potential security hole
422 2014-11-05 14:44:55 <CodeShark> even if done right, it's easy to mess up
423 2014-11-05 14:45:24 <sipa> there's a patch to make it us $RAND + H(message + privkey) rather than just $RAND
424 2014-11-05 14:45:31 <sipa> but it's not in any release afaik
425 2014-11-05 14:48:15 <CodeShark> https://github.com/ciphrex/CoinVault/blob/rfc6979/deps/CoinCore/src/secp256k1.cpp#L344
426 2014-11-05 14:48:30 <sipa> yeah, i have a branch implementing rfc6979 as well
427 2014-11-05 14:48:56 <sipa> wait, what?
428 2014-11-05 14:50:16 <sipa> heh, i didn't know about that
429 2014-11-05 14:53:01 <CodeShark> it's still impossible for the verifier to check that rfc6979 was used
430 2014-11-05 14:53:27 <sipa> yes, and it should be
431 2014-11-05 14:53:28 <CodeShark> the only advantage is on the signer's side - in that entropy is not required for signing
432 2014-11-05 14:53:38 <sipa> i'm well aware
433 2014-11-05 14:53:47 <Luke-Jr> sipa: my point was just that "using accounts isn't automatically misuse" as it seemed to be implied by a previous comment
434 2014-11-05 14:53:57 <sipa> Luke-Jr: oh, i see
435 2014-11-05 14:54:10 <CodeShark> sipa: point is it wouldn't get rid of the k malleability issue
436 2014-11-05 14:54:26 <sipa> CodeShark: no, you need a deterministic signature scheme for that
437 2014-11-05 14:54:34 <sipa> and EC doesn't have one
438 2014-11-05 15:00:36 <sipa> CodeShark: ooh, you've implemented rfc6979 with sha256
439 2014-11-05 15:00:41 <sipa> can i haz some test vectors?
440 2014-11-05 15:01:06 <CodeShark> sure
441 2014-11-05 15:01:33 <sipa> i see you're following the spec strictly and hashing the message before passing it to the prng
442 2014-11-05 15:01:42 <CodeShark> https://github.com/ciphrex/CoinVault/tree/rfc6979/deps/CoinCore/tests/secp256k1
443 2014-11-05 15:01:50 <sipa> even though the message is already known to be a hash, and should be for ecdsa
444 2014-11-05 15:02:33 <CodeShark> just modify https://github.com/ciphrex/CoinVault/blob/rfc6979/deps/CoinCore/tests/secp256k1/src/secp256k1_rfc6979_test.cpp to create whatever test vectors you want
445 2014-11-05 15:02:46 <sipa> awesome
446 2014-11-05 15:19:19 <CodeShark> sipa: I don't think ECDSA_sign_ex is working as expected, now that I try it
447 2014-11-05 15:19:40 <CodeShark> CoinCrypto::secp256k1_rfc6979_k seems to work, though
448 2014-11-05 15:20:45 <CodeShark> or hmmm
449 2014-11-05 15:22:25 <CodeShark> I just did a build - haven't touched this code in a couple months…and there seems to be a bug I think I had fixed…but I need to find the branch where it's fixed
450 2014-11-05 15:24:39 <CodeShark> sipa: I take that back - this is the correct branch
451 2014-11-05 15:24:57 <CodeShark> CoinCrypto::secp256k1_rfc6979_k seems to work, ECDSA_sign_ex isn't working as expected
452 2014-11-05 15:28:01 <CodeShark> perhaps I misunderstood the kinv parameter
453 2014-11-05 15:29:08 <CodeShark> according to the OpenSSL documentation, "kinv - optional pointer to a pre-computed inverse k"
454 2014-11-05 15:29:40 <CodeShark> I'm still getting different signatures for the same k
455 2014-11-05 15:39:58 <sipa> CodeShark: juddging by the source code you need to pass both kinv and R
456 2014-11-05 15:40:37 <sipa> if either one is missing, a new random one is generated
457 2014-11-05 15:44:37 <sipa> R being the x coordinate of k*G
458 2014-11-05 15:45:00 <CodeShark> aha - let me try passing that as well
459 2014-11-05 15:54:18 <CodeShark> hmm, how do we get the rp?
460 2014-11-05 15:55:35 <sipa> you EC_POINT_mul i guess
461 2014-11-05 15:56:29 <sipa> see crypto/ecdsa/ecs_ossl.c, ecdsa_sign_setup
462 2014-11-05 15:57:41 <CodeShark> I have secp256k1_point::generator_mul()
463 2014-11-05 15:57:51 <sipa> good enough
464 2014-11-05 16:01:05 <CodeShark> EC_POINT_get_affine_coordinates_GFp, I guess?
465 2014-11-05 16:01:35 <sipa> that'll do
466 2014-11-05 16:18:29 <CodeShark> alright - I did that - now I'm always getting the sam signature…but the validation is failing…so I suppose I'm not computing rp correctly
467 2014-11-05 16:18:34 <CodeShark> *same signature
468 2014-11-05 16:19:52 <stonecoldpat> make sure the hash that is being signed is the same for both signature and verification (i've had a problem in the past where they both different due to my own error)
469 2014-11-05 16:20:27 <CodeShark> that's surely not the issue
470 2014-11-05 16:20:30 <CodeShark> nothing else in the code changed
471 2014-11-05 16:20:50 <CodeShark> when I let OpenSSL choose a random k for me, the signatures are valid
472 2014-11-05 16:21:25 <CodeShark> the only difference is the rp parameter to ECDSA_sign_ex
473 2014-11-05 16:22:45 <stonecoldpat> ah sorry, when you say rp, you mean kG = (x,y) where r = x? then r should be part of the signature already (r,s)
474 2014-11-05 16:23:51 <stonecoldpat> so it may be worth checking - the deterministic 'r' you are putting into the function, is the same 'r' popping out in the signature
475 2014-11-05 16:30:48 <stonecoldpat> also make sure your using BN_mod_inverse to get kinv, and not just negating k. (sorry if comments are not useful)
476 2014-11-05 16:31:44 <CodeShark> I did check that the r I'm getting is the same as in the signature
477 2014-11-05 16:31:50 <CodeShark> and yes, I'm using BN_mod_inverse
478 2014-11-05 16:39:46 <CodeShark> http://pastebin.com/CkuHpTfV
479 2014-11-05 16:39:50 <CodeShark> there's my output
480 2014-11-05 16:46:45 <stonecoldpat> have you had a look @ https://github.com/openssl/openssl/blob/master/crypto/ecdsa/ecs_ossl.c ? the ECDSA_SIGN_SETUP method? you basically just need to copy what they do once you have 'k'
481 2014-11-05 16:47:32 <stonecoldpat> (if 'k' is the problem and not some parameter point being funny)
482 2014-11-05 16:48:09 <stonecoldpat> and it may be useful using EC_GROUP_get_order(group, order, ctx) to get the 'q' value (if q is the order) instead of hard-coding it, just to make sure its right
483 2014-11-05 16:55:46 <CodeShark> oh…the group order…not the field mod
484 2014-11-05 16:56:32 <CodeShark> ?
485 2014-11-05 16:56:57 <CodeShark> here's what I'm doing: https://github.com/ciphrex/CoinVault/blob/rfc6979/deps/CoinCore/src/secp256k1.cpp#L350
486 2014-11-05 16:59:27 <CodeShark> I tried it with the group order instead and am still getting the same issue
487 2014-11-05 17:00:36 <CodeShark> ok, just pushed the change
488 2014-11-05 17:04:20 <stonecoldpat> could try doing secp256k1_verify straight after ECDSA_sign_ex to see if it works before you leave that function
489 2014-11-05 17:04:53 <stonecoldpat> so sign then immediately verify (thats what I would do if I was debugging it) - havent got my laptop with me to debug it properly
490 2014-11-05 17:04:58 <CodeShark> what difference would that make? if I take this code and just replace rp with NULL in ECDSA_sign_ex, I get a valid signature
491 2014-11-05 17:06:27 <CodeShark> so this means the problem can only be with kinv, rp, or ECDSA_sign_ex
492 2014-11-05 17:10:52 <stonecoldpat> consistent to what openssl are doing
493 2014-11-05 17:10:52 <stonecoldpat> well you should have all the valid values in the function for the thing to verify. Although - your using point.generator_mul(k) which does EC_POINT_mul(group, point, bn, point, BN_value_one(), ctx) to generate kG = (x,y). But Open_SSL uses EC_POINT_mul(group, tmp_point, k, NULL, NULL, ctx) - it shouldnt make a great difference, but could try inserting nulls in that operation? Keep it
494 2014-11-05 17:12:45 <CodeShark> I'm using generator_mul here: https://github.com/ciphrex/CoinVault/blob/master/deps/CoinCore/src/hdkeys.cpp#L265
495 2014-11-05 17:12:51 <CodeShark> and this code has been extensively tested
496 2014-11-05 17:13:47 <CodeShark> the hdkeys code, that is
497 2014-11-05 17:15:03 <CodeShark> you'd think if there was something wrong with my implementation of generator_mul it would have triggered something by now
498 2014-11-05 17:16:21 <stonecoldpat> that is true, if you have the group available though, it's a one-line change to see if that is the problem as it does sound like its the computation of 'r' that is going wrong
499 2014-11-05 17:16:42 <helo> would be quite an exercise to design something that wasn't perfect, but passes every test you can throw at it
500 2014-11-05 17:17:24 <CodeShark> helo: you could deliberately fudge the result for one particular point :)
501 2014-11-05 17:17:38 <helo> well sure... i mean without it being obvious :)
502 2014-11-05 17:21:03 <CodeShark> oh, hmm :)
503 2014-11-05 17:21:15 <CodeShark> stonecoldpat: that change worked...strange
504 2014-11-05 17:22:06 <stonecoldpat> awesome!
505 2014-11-05 17:22:40 <CodeShark> I'm a little scared to make that change in my releases because it might break something :p
506 2014-11-05 17:23:00 <CodeShark> I've been using the generator_mul implementation you see and haven't had any issues with hdkeys yet
507 2014-11-05 17:23:46 <CodeShark> oh...
508 2014-11-05 17:23:56 <CodeShark> I think my implementation of generator_mul fails for the point at infinity
509 2014-11-05 17:24:01 <CodeShark> but perhaps works for all other points
510 2014-11-05 17:25:36 <CodeShark> thanks, stonecoldpat - I'll run tests on this new change to see if anything breaks
511 2014-11-05 17:25:47 <stonecoldpat> np :)
512 2014-11-05 17:35:37 <CodeShark> stonecoldpat: I think I might need to do EC_POINT_mul(group, point, bn, (is_at_infinity() ? NULL : point), BN_value_one(), ctx);
513 2014-11-05 17:36:26 <CodeShark> then the behavior for hdkeys should remain unchanged - and I just tested this for rfc6979 and it produced a valid signature
514 2014-11-05 18:45:57 <rubensayshi> if given a partially signed input of a N of M p2sh output, is it possible to know if it's already been signed without knowing the public keys?
515 2014-11-05 18:48:33 <rubensayshi> my case is a 2of3 where I can just sign and see if it's valid after signing, but I'm curious when it's more than 2of3 or if you wouldn't know any keys and see the transaction?
516 2014-11-05 18:50:06 <gmaxwell> the signature contains the redeemscript if it has been signed at all.
517 2014-11-05 18:53:25 <rubensayshi> okay, thanks
518 2014-11-05 20:44:26 <michagogo> Luke-Jr: uh, wtf? How the hell did you get a Rubik's Cube into an unsolvable state?
519 2014-11-05 20:44:42 <michagogo> Did you not start from a solved one?
520 2014-11-05 20:44:53 <Luke-Jr> michagogo: I didn't, no. not sure where it came from.
521 2014-11-05 20:44:58 <Luke-Jr> I guess someone moved stickers?
522 2014-11-05 20:45:04 <michagogo> Was it a trolly fake cube? One that someone had taken apart or relabelled?
523 2014-11-05 20:45:16 <Luke-Jr> all the colours were labels
524 2014-11-05 20:45:22 <michagogo> I wonder if that's a thing
525 2014-11-05 23:14:57 <cfields> sipa: sorry for delay re secp256k1 stuff, had a few things i had to do during the day this week. catching up now.
526 2014-11-05 23:21:56 <cfields> CodeShark: re boost removal, here is a good example of why: https://github.com/bitcoin/bitcoin/pull/5213
527 2014-11-05 23:22:35 <cfields> boost is far more complex than most libs, so how it's built can matter to lib users
528 2014-11-05 23:23:54 <cfields> CodeShark: also, removing boost as a dep from a compilation unit is a good start towards removing bitcoind app state. no guarantees ofc, but since we rely on it for threading/program options/etc, the two tend to line up for the most part
529 2014-11-05 23:25:05 <sipa> what is in the way of c++11 now, really?
530 2014-11-05 23:25:18 <sipa> at least for threading that would simplify things a lot...
531 2014-11-05 23:26:15 <cfields> sipa: i think not much anymore. iirc wumpus wanted to evaluate it for post-0.10
532 2014-11-05 23:26:23 <sipa> cool