1 2014-12-13 00:36:38 <isis> gmaxwell: using tor "nextgen" (or whatever they're going to be called) HSes to authenticate bitcoin payment requests sounds like an excellent idea
 2 2014-12-13 00:37:38 <isis> gmaxwell: and, as far as your offer to help out with the HS work, i think we'd all be super happy to have your help
 3 2014-12-13 00:53:05 <gmaxwell> isis: well in respect to nextgen, it seemed like no progress was happening. I commented some one the design. (e.g. I think it's important that the scheme support delegation .. which would also be useful for using the same addresses to authenticate payment requests: you don't really want to have your onion master keys always online where they're also being used to sign payment requests).
 4 2014-12-13 01:03:59 <isis> gmaxwell: i agree entirely. the current proposol for nextgen HSes does include "offline onion keys". https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n465
 5 2014-12-13 01:04:41 <isis> gmaxwell: unfortunately, the current design is more akin to chaumian token generation than a truly delegatable anonymous credential scheme (e.g. those which camenisch and lysyanskaya have proposed, based on groth-sahai proofs)
 6 2014-12-13 01:06:08 <isis> so, the "unfortunate" part is mainly due to the operator of the HS being required to bring the key online and generate a new pile of blinded tokens
 7 2014-12-13 01:06:35 <gmaxwell> Yes, well ... doesn't invoke pairing crypto is also an okay property to have.
 8 2014-12-13 01:07:33 <isis> yes, for ease of implementation.
 9 2014-12-13 01:09:12 <gmaxwell> I think that having to periodically spin up the offline key isn't so terrible, at least it bounds a compromise. So the interesting question would be how to handle a payment request in this framework. It could be as simple as a certificate style delegation where the master key, signs message that includes critiera like validity dates even bitcoin amounts, and an additional public key.
10 2014-12-13 01:09:19 <isis> i am starting to suspect, however, after searching for the past several years for an anonymous authentication scheme without pairings, that there isn't one, and that it might be in some way fundamentally impossible. :/
11 2014-12-13 01:12:09 <isis> the idea to place bounds on times and amounts is interesting… perhaps the old-fashioned crypto way is useful despite its hassle.
12 2014-12-13 01:13:13 <gmaxwell> isis: I beleive it's impossible without pairings.
13 2014-12-13 01:14:08 <gmaxwell> (For the same reason non-pairing compact non-interactive forward secrecy doesn't work. ... I don't have a proof of this, though certantly lots of people have battered themselves against similar problems for some time now)
14 2014-12-13 01:48:30 <petertodd> isis: re old-fashioned crypto, reminds me of a discussion I had yesterday w/ a professor re: bip32 where I pointed out that HD derivation was purely a space optimizaiton over just generating a few KB/MB worth of keys in advance
15 2014-12-13 02:59:41 <akaiiro> hey guys. i'm building and endpoint to catch Change.com transaction notifications. know about a writing on validating transaction hashes and address?
16 2014-12-13 13:28:11 <btcdrak> are you on the latest hearn?
17 2014-12-13 13:48:23 <mardokwin> hello
18 2014-12-13 13:48:27 <gribble> Admin, Alias, Anonymous, AutoMode, BadWords, BitcoinData, Channel, ChannelLogger, ChannelStats, Conditional, Config, Debug, Dict, Dunno, Factoids, Filter, Format, GPG, Games, Gatekeeper, Google, Herald, Internet, Later, Market, Math, MessageParser, Misc, Network, OTCOrderBook, Owner, Plugin, RSS, RatingSystem, Reply, Scheduler, Seen, Services, Status, String, Time, Topic, URL, Unix, User, (1 more message)
19 2014-12-13 13:48:27 <mardokwin> !list
20 2014-12-13 17:14:37 <sipa> jtimon, gmaxwell: (3) implemented in https://github.com/bitcoin/secp256k1/pull/163
21 2014-12-13 17:35:21 <jtimon> looks good, finally you implemented 2 with 3 as default
22 2014-12-13 17:35:52 <sipa> yup, it's the solution i like the most - except for the code duplication
23 2014-12-13 17:36:04 <sipa> but i was surprised that it only added 4 kb of executable code
24 2014-12-13 17:36:17 <jtimon> couldn't bitcoin use the hash functions there?
25 2014-12-13 17:36:55 <sipa> it could; but i'm not sure i like exposing the functions
26 2014-12-13 17:37:43 <jtimon> I see, but well it's either that or code duplication
27 2014-12-13 17:37:51 <sipa> indeed
28 2014-12-13 17:37:58 <sipa> or abstracting them in yet another library
29 2014-12-13 17:39:11 <jtimon> yep, althou maybe too small of a library
30 2014-12-13 17:39:39 <sipa> libsecp256k1 is now around 75 kb of object code, which is already tiny
31 2014-12-13 17:40:48 <sipa> ... and suddenly i remember my first programming language (gwbasic) which had a 75 kb interpreter...