1 2014-10-22 00:00:48 <coryfields_> sipa: i've fixed up the libsecp256k1 in bitcoin (testing it in libbitcoinconsensus), and it's having trouble with a particular test. Known issue for "P2PK with high S" ?
  2 2014-10-22 00:01:05 <sipa> coryfields_: that sounds very expected
  3 2014-10-22 00:01:16 <coryfields_> ok, will just skip over it
  4 2014-10-22 00:01:53 <sipa> it needs a change in secp256k1's api, i'm afraid
  5 2014-10-22 00:02:13 <sipa> as you can't tell it to not use low-S
  6 2014-10-22 00:02:18 <coryfields_> figured as much, specifying high/low S i suppose
  7 2014-10-22 00:02:19 <coryfields_> ?
  8 2014-10-22 00:02:22 <coryfields_> right
  9 2014-10-22 00:03:11 <sipa> yup
 10 2014-10-22 00:03:16 <coryfields_> want me to take a crack at it? or is it waiting on something?
 11 2014-10-22 00:03:28 <sipa> it's trivial to do, you can if you want to
 12 2014-10-22 00:03:39 <sipa> busy with other things currently
 13 2014-10-22 00:04:20 <coryfields_> ok
 14 2014-10-22 02:37:25 <coryfields_> gmaxwell: around?
 15 2014-10-22 02:40:53 <gmaxwell> coryfields_: shockingly, yes.
 16 2014-10-22 02:42:26 <coryfields_> gmaxwell: bah, i just pasted backlog to that PR.
 17 2014-10-22 02:42:40 <coryfields_> refresh there or scroll up a few lines :)
 18 2014-10-22 02:43:04 <gmaxwell> yea, responded. OK.
 19 2014-10-22 03:00:59 <deego> RE topi: what does bc.i mean?
 20 2014-10-22 03:01:32 <lechuga_> blockchain.info
 21 2014-10-22 03:01:43 <deego> ah, thanks lechuga_
 22 2014-10-22 08:08:13 <anton000> opinions on what cirve allows for type-2 without the problems when done with secp256k?
 23 2014-10-22 08:12:55 <CodeShark> wumpus: ping
 24 2014-10-22 08:14:17 <wumpus> pong
 25 2014-10-22 08:14:58 <CodeShark> is the sync.h thing a decent temporary solution, you think?
 26 2014-10-22 08:15:23 <wumpus> I think so
 27 2014-10-22 08:16:00 <sipa> anton000: which problems?
 28 2014-10-22 08:16:01 <wumpus> it's RAII and it just pushes the locks down one level, so easier to review than having changes to the RPC method's logic
 29 2014-10-22 08:17:03 <CodeShark> exactly - the objective is to get this merged so that developers can optimize concurrency without touching rpcserver
 30 2014-10-22 08:17:18 <CodeShark> with the least risk of breaking anything :)
 31 2014-10-22 08:18:34 <wumpus> right
 32 2014-10-22 08:19:09 <CodeShark> I'm far more interested in the abstract dispatching mechanism than in the optimization of individual calls :)
 33 2014-10-22 08:20:58 <CodeShark> so once we merge this, I can continue to work on removing the table from rpcserver.cpp
 34 2014-10-22 08:21:26 <CodeShark> we can create an abstract callable base clase
 35 2014-10-22 08:21:29 <CodeShark> *class
 36 2014-10-22 08:22:56 <wumpus> right
 37 2014-10-22 08:22:58 <CodeShark> then we can add the registration methods to the different units - and call them when initializing the rpc server
 38 2014-10-22 08:25:02 <CodeShark> then the RPC server interface becomes a matter of a specific function prototype - which we can easily wrap, making it simple to improve or replace the rpc server independently from everything else
 39 2014-10-22 08:30:37 <CodeShark> it will also make it much simpler to add compiletime or runtime switches as to which APIs are loaded
 40 2014-10-22 08:32:00 <CodeShark> and in principle we could ultimately support dynamic loading of new APIs without having to stop the daemon
 41 2014-10-22 08:32:53 <CodeShark> but first things first :p
 42 2014-10-22 08:33:00 <wumpus> I doubt we're going in that direction, though, but sure it could be possible :)
 43 2014-10-22 08:34:21 <wumpus> I mean as for loading third party APIs at runtime; but modularization within the current code is very good
 44 2014-10-22 08:34:34 <CodeShark> yeah, I was getting a little carried away :)
 45 2014-10-22 08:34:51 <CodeShark> in truth, I'd actually see bitcoind have LESS core functionality rather than MORE
 46 2014-10-22 08:34:51 <wumpus> ideally if you make the RPC server general it could also move to its own directory within src
 47 2014-10-22 08:35:00 <wumpus> me too!
 48 2014-10-22 08:35:39 <ThomasV> gmaxwell: some days ago you mentioned adding a "maximum date" to seeds. what was your idea on that?
 49 2014-10-22 08:35:49 <CodeShark> ideally the RPC server should be built as an independent library :)
 50 2014-10-22 08:35:56 <wumpus> and other use-cases would be better solved by embedding bitcoin core as a library than having bitcoin core load your code ...
 51 2014-10-22 08:36:04 <CodeShark> right
 52 2014-10-22 08:37:04 <anton000> sipa: type2 bip0032 wallets.. where  private keys under a public derivation can be exposed if you have any of the private key
 53 2014-10-22 08:37:15 <sipa> anton000: EC crypto cannot avoid this
 54 2014-10-22 08:37:22 <anton000> i see
 55 2014-10-22 08:37:27 <sipa> i believe there's a proof for that, actually
 56 2014-10-22 08:38:06 <CodeShark> sipa, didn't we prove the other day that it can be avoided…but at the cost of linear increase in derived key lengths? :)
 57 2014-10-22 08:38:29 <sipa> CodeShark: then you don't need a derivation anymore
 58 2014-10-22 08:38:42 <sipa> just use a master public key that is a concatenation of all child public keys
 59 2014-10-22 08:39:07 <sipa> so yes, trivial solution is trivial
 60 2014-10-22 08:40:29 <CodeShark> I think by the same logic we can perhaps show that it is the optimal solution…which then gives the impossibility result we're after
 61 2014-10-22 08:41:14 <CodeShark> any more optimal solution ends up with insufficient unknowns
 62 2014-10-22 08:41:21 <CodeShark> which allows us to solve algebraically
 63 2014-10-22 08:41:43 <sipa> i believe Dan Boneh has a proof already
 64 2014-10-22 08:41:50 <sipa> though he never actually sent it to me :)
 65 2014-10-22 08:42:06 <CodeShark> it wouldn't fit in the margin of the page? :)
 66 2014-10-22 08:42:52 <gmaxwell> sipa: it can be done with bilinear cryptography (which is EC).
 67 2014-10-22 08:43:42 <sipa> hmm
 68 2014-10-22 08:45:42 <CodeShark> gmaxwell: you wouldn't happen to have any links to publications on that result, would you?
 69 2014-10-22 08:48:10 <gmaxwell> What, doing something like BIP32 without the leak? it's a trivial application of IBE.
 70 2014-10-22 08:49:02 <CodeShark> IBE = ?
 71 2014-10-22 08:49:31 <gmaxwell> Id based encryption,  http://www.larc.usp.br/~pbarreto/pblounge.html  see the first group under signatures. One of the papers there.
 72 2014-10-22 08:49:58 <CodeShark> ah - well, anything's trivial once you're up on it - I haven't read much on this topic
 73 2014-10-22 08:50:03 <CodeShark> so to me it's not quite trivial yet :p
 74 2014-10-22 08:50:09 <gmaxwell> The idea is there is a master pubkey  and some function that takes an ID and a pubkey and yields a new pubkey whos private key can only be computed by knowing the master private key.
 75 2014-10-22 08:52:11 <gmaxwell> http://eprint.iacr.org/2002/018 is reasonable.
 76 2014-10-22 08:54:41 <CodeShark> cool - thanks
 77 2014-10-22 08:56:05 <phantomcircuit> gmaxwell, isn't that kind of what the stealth addresses are doing?
 78 2014-10-22 08:57:58 <gmaxwell> they also have the property that leaking the private key leaks them all.  IBE does not. Which is very important for IBE because in IBE each 'identity' is normally a different user.
 79 2014-10-22 09:00:42 <phantomcircuit> oh right the difference being you have a new private key for each pubkey
 80 2014-10-22 09:00:43 <phantomcircuit> hmm
 81 2014-10-22 09:02:44 <anton000> nice thanks for the link gmax
 82 2014-10-22 09:08:40 <gmaxwell> (note, using paring crypto usually means a 100x slowdown vs ecdsa; and new cryptographic assumptions. ... which is why I didn't just immediately propose that when I saw the need for the public derrivation... :))
 83 2014-10-22 09:09:01 <sipa> also, bitcoin doesn't have an OP_IBE operator :)
 84 2014-10-22 09:09:15 <CodeShark> slowdown in key generation, signing, verification, or all of the above?
 85 2014-10-22 09:09:22 <sipa> verification
 86 2014-10-22 09:09:29 <CodeShark> ok, so then it is a problem
 87 2014-10-22 09:09:30 <sipa> that's the only thing that matter in bitcoin :)
 88 2014-10-22 09:09:37 <sipa> (though the question was about a different curve, so i guess this is a relevant answer)
 89 2014-10-22 09:10:21 <gmaxwell> when you see a e() operation in a paper on pairing crypto think 1ms. Though batch verification can be done which can help sometimes.
 90 2014-10-22 10:45:17 <kyuupichan> What's the record for block size?  326447 is 999489 bytes
 91 2014-10-22 10:46:17 <SomeoneWeird> #bitcoin pls
 92 2014-10-22 15:24:31 <coryfields_> sipa: global secp256k1_start as opposed to a returned context is proving to be a real problem when working with libbitcoinconsensus
 93 2014-10-22 15:24:52 <coryfields_> the static RAII class races with other static initializers
 94 2014-10-22 15:25:20 <sipa> we can change that
 95 2014-10-22 15:25:28 <sipa> but how are static initializers a problem?
 96 2014-10-22 15:27:22 <coryfields_> sipa: i haven't tracked down the culprit yet, but something is managing to call into the lib before _start is run. I assume somewhere there's a static CKey that's being created and initialized to something first
 97 2014-10-22 15:27:37 <coryfields_> backtrace shows the crash in the static init. i can grab you one if you're interested
 98 2014-10-22 15:27:37 <sipa> ah
 99 2014-10-22 15:28:13 <wumpus> stupid static initializers :)
100 2014-10-22 15:28:20 <coryfields_> sipa: problem is that when we're running tests from the lib interface, bitcoind, a standalone test prog using the lib, etc.. they all need calls to start in different places
101 2014-10-22 15:30:34 <coryfields_> crash: http://pastebin.com/raw.php?i=qL3NPNB6
102 2014-10-22 15:32:36 <coryfields_> it's "fixed" by running secp256k1_start in CKey's ctor
103 2014-10-22 15:33:31 <wumpus> so we must be having a CKey global somewhere... :/
104 2014-10-22 15:36:29 <coryfields_> it's odd that gdb doesn't specify. i'm sure there's some way i can smack it so that it'll be more specific?
105 2014-10-22 15:37:25 <wumpus> -g3 -ggdb  -gdwarf-4 ? :)
106 2014-10-22 15:37:40 <coryfields_> btw, it's very possible that i caused this with my changes. but imo the problem is at the libsecp level
107 2014-10-22 15:37:47 <wumpus> -O0
108 2014-10-22 15:37:58 <coryfields_> heh, will give it a try
109 2014-10-22 15:38:06 <wumpus> getting details out of gdb when debugging C++ code can be tricky
110 2014-10-22 15:40:54 <gavinandresen> clang doesn’t like current git HEAD: script.h:197:19: error: no matching conversion for functional-style cast from 'const char [57]' to 'scriptnum_error'
111 2014-10-22 15:41:54 <wumpus> weird- doesn't travis osx build with clang as well?
112 2014-10-22 15:42:23 <coryfields_> yes
113 2014-10-22 15:42:33 <gavinandresen> maybe… I’m running Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
114 2014-10-22 15:43:25 <coryfields_> gavinandresen: weird. if it refuses to cast a const char* to a string, it'll be a problem all over the place, no?
115 2014-10-22 15:44:05 <gavinandresen> coryfields_: dunno, haven’t debugged further. switching to a branch from a day or three ago all is well.
116 2014-10-22 15:44:28 <coryfields_> ah, it was made explicit
117 2014-10-22 15:44:29 <wumpus> scriptnum_error isn't a string
118 2014-10-22 15:45:11 <coryfields_> nm, already was explicit
119 2014-10-22 15:45:34 <gavinandresen> coryfields_: full error, if helpful:  https://gist.github.com/gavinandresen/3dc1733bee6488706a36
120 2014-10-22 15:45:35 <wumpus> huh indeed weird
121 2014-10-22 15:45:37 <coryfields_> so yea, that's indeed an error i'd think
122 2014-10-22 15:45:53 <wumpus> well it uses the constructor, so explicit shouldn't matter?
123 2014-10-22 15:46:36 <coryfields_> wumpus: explicit should mean that it can't implicitly cast to string, though
124 2014-10-22 15:46:44 <wumpus> explicit only avoids things being fed to scriptnum_error() accidentally, but I see no case of that on that line throw scriptnum_error("CScriptNum(const std::vector<unsigned char>&) : overflow");
125 2014-10-22 15:47:08 <coryfields_> throw scriptnum_error(std::string("CScriptNum(const std::vector<unsigned char>&) : overflow"));
126 2014-10-22 15:47:18 <wumpus> coryfields_: huh! I thought the explicit only applied directly
127 2014-10-22 15:48:01 <wumpus> so it means that a std::string can't be passed as argument to something that takes a scriptnum_error... I didn't know it also nested 'deeper' into the arguments of the constructor
128 2014-10-22 15:48:33 <wumpus> why does it call it a "functional-style cast"  if it is a constructor call
129 2014-10-22 15:48:37 <wumpus> I think it's a scope issue
130 2014-10-22 15:49:59 <coryfields_> scope?
131 2014-10-22 15:50:08 <wumpus> it doesn't recognize the constructor
132 2014-10-22 15:50:51 <wumpus> ok no the expanded error shows it does find it
133 2014-10-22 15:51:41 <gavinandresen> mmm.  I’m not a language lawyer enough to know the exact definition of what explicit does, but it seems to me we want another scriptnum_error constructor that takes a const char*
134 2014-10-22 15:52:18 <wumpus> yeah, I suppose that's the cost of using explicit then
135 2014-10-22 15:52:35 <wumpus> although it's strange that it doesn't come up in other compilers
136 2014-10-22 15:52:39 <coryfields_> wumpus: afaik this is exactly why explicit is usually used in this cases. Otherwise, NULL is a valid "const char*", and can be used to create a std::string implicitly, which will throw an error
137 2014-10-22 15:53:26 <wumpus> coryfields_: why would anyone pass NULL to it?
138 2014-10-22 15:53:43 <gavinandresen> Hmm: http://en.cppreference.com/w/cpp/error/runtime_error
139 2014-10-22 15:54:47 <coryfields_> wumpus: just in general. say you have 2 ctors, one is a const char*, the other is a std::string. You may use the "const char*" ctor with NULL to mean "I don't want a value here"
140 2014-10-22 15:55:02 <coryfields_> but you could be surprised to see it falling into the std::string implicitly instead
141 2014-10-22 15:55:07 <coryfields_> sec, i'll find a better description
142 2014-10-22 15:55:12 <wumpus> right, I get it
143 2014-10-22 15:56:19 <wumpus> I just didn't know that explicit applied to the arguments of the constructor, I just thought it applied to use of the constructor itself for automatic type conversion
144 2014-10-22 15:56:28 <wumpus> but that's clear now
145 2014-10-22 16:00:17 <coryfields_> wumpus: i think the "constructor itself" case is a side-effect of the copy ctor being unable to use the explicit ctor for implicit conversion
146 2014-10-22 16:00:46 <wumpus> ok
147 2014-10-22 16:01:35 <wumpus> though that still doesn't explain why it seems to be different in other compilers
148 2014-10-22 16:03:09 <gavinandresen> I’ll bisect and see which commit it started breaking at….
149 2014-10-22 16:03:31 <wumpus> very likely something in pull #4981
150 2014-10-22 16:05:29 <wumpus> coryfields_: for example, this http://www.hastebin.com/enagafijez.cpp  compiles ... making the Test2 constructor explicit doesn't prevent the argument from being automatically converted from int to Test
151 2014-10-22 16:05:42 <wumpus> coryfields_: it does avoid doing Test2 x = 10;
152 2014-10-22 16:09:28 <coryfields_> hmm
153 2014-10-22 16:13:03 <wumpus> if explicit applied to the *arguments*, you could use explicit also with constructors with multiple arguments; IIRC it's only used for constructors that take one
154 2014-10-22 16:18:04 <coryfields_> haha, wait
155 2014-10-22 16:18:22 <coryfields_> gavinandresen: #include <string> :)
156 2014-10-22 16:19:09 <coryfields_> ah damn, nm. it's there in your paste
157 2014-10-22 16:19:43 <coryfields_> i just repro'd the same error locally with the string include missing. error looked the same, but obviously there was another before it
158 2014-10-22 16:20:46 <gavinandresen> 85c579e3a63cf505d6cedc454755265572e97d3e is the first bad commit
159 2014-10-22 16:28:33 <coryfields_> ok, repro'd with libc++. string include fixes.
160 2014-10-22 16:29:16 <coryfields_> wumpus: looks like i need to read up on explicit.
161 2014-10-22 16:30:56 <coryfields_> not sure where my understanding broke down, afaik it's always worked as i intended. that's a bit scary now :)
162 2014-10-22 19:19:28 <hearn> cool! http://shuoyangdesign.com/2014/10/05/realtime-bitcoin-transaction-map/
163 2014-10-22 19:21:51 <gwillen> of course, they appear to be using bc.i's "first relayed IP" for location, which is dubious as an actual location
164 2014-10-22 19:21:55 <gwillen> but still neat
165 2014-10-22 19:22:51 <hearn> right
166 2014-10-22 19:22:57 <hearn> it's the best you can do i think
167 2014-10-22 19:23:04 <hearn> maybe we should have that somewhere on bitcoin.org
168 2014-10-22 20:45:26 <CodeShark> anyone seen saivann?
169 2014-10-22 20:48:18 <Luke-Jr> CodeShark: he's not often on IRC
170 2014-10-22 20:55:34 <saivann> I am usually around in case my immediate help with bitcoin.org is required.