--- Log opened Sat Sep 14 00:00:36 2013 00:56 < gmaxwell> amiller: so I've been swimming in all sorts of psycho things that one way signatures enable. 00:57 < amiller> gmaxwell, word, what else have you come up with? 00:57 < amiller> one way aggregatable 00:58 < gmaxwell> amiller: I dunno if you saw me mention it, but it greatly reduces the problems of miners making more by reorging out other miners blocks instead of moving forward in a world driven by fees. 00:59 < gmaxwell> because if the fees are taken from a block using a aggregate signature you couldn't learn any more transactions from a competitors block. 01:00 < amiller> i read all your posts in that thread 01:00 < gmaxwell> well, I'd commented in here some too. 01:00 < amiller> is your idea basically that miners who receive transactions 01:00 < amiller> will merge all the transactions before broadcasting them 01:00 < amiller> so that other miners can't take them piecemeal and make easier blocks? 01:01 < gmaxwell> Right. Well they can take them, but the miners fee output will already be added and they can't remove it. 01:01 < amiller> one thing i vaguely think is the same as this but i haven't thought hard about is 01:01 < amiller> oh 01:01 < amiller> oh cool so they add their own personal fee explicitly 01:01 < amiller> okay so 01:01 < gmaxwell> yes. relayers could too. 01:01 < amiller> this is an implementation of bitcoins and red balloons basically 01:01 < gmaxwell> yes. 01:01 < gmaxwell> but it's efficient. 01:02 < gmaxwell> the signatures are smaller than ours. (only one G1 group element per transaction for the keys, and one G1 element for the aggregate signature) 01:02 < gmaxwell> and so if the paring has high k you get adequate security with just 160-256 bit G1 elements. 01:05 < amiller> that doesn't effect verification time but transmission cost sure 01:05 < amiller> you still have to transmit the expanded public keys 01:06 < gmaxwell> In any case yes, it makes red balloons scalable (so long as you don't mind one pairing operation per transaction), and it also means that even the miners themselves have the red balloons property. 01:06 < amiller> i have a friend who basically derived this in some private conversation last year :x 01:06 < amiller> i told him i didn't know any signature scheme that could be combined that way 01:06 < amiller> it was specifically about doing red balloons where you can't strip the new fee off 01:07 < gmaxwell> amiller: for ecdsa we have public + r + s for this we would have public + aggregate(s) but if it's use for anonymity you have to have an extra public key for each output. 01:07 < gmaxwell> and yea, this is really trivial with pairing crypto. 01:09 < amiller> yeah i ran through your elaboration and it made sense 01:09 < amiller> (i am not really checked out to read and securitize crypto but w/e) 01:09 < gmaxwell> the signature algorithim with one way aggregation is circua 2003. This posters contribution is the idea that if you seperate your spend and your output signatures would be insecure in isolation and aggregate them before announcing, you don't have linking. 01:09 < gmaxwell> Well .. it's pairing which uh. may not give everyone warm fuzzies. 01:10 < gmaxwell> because it's all based on carefully choosing groups withere the delusional DH problem is trivial to solve. 01:11 < amiller> yeah also all elliptic curves were generated by j.e. hoover 01:11 < gmaxwell> man I made the mistake of making a few comments on that, and have had press calling me all week about it. 01:13 < petertodd> gmaxwell: good job 01:14 < amiller> you and matt green. 01:14 < amiller> who visits my office once a week :3 01:14 < amiller> i gave him a copper bitcoin trinket today 01:14 < amiller> if you think *you* open your big mouth.... 01:14 < amiller> anyway so... 01:15 < amiller> pairings are fine w/e PBC is easy enough to use and almost fast 01:15 < gmaxwell> amiller: can you ask him what he's doing going and filling reporters heads with the idea that the NSA can steal bitcoin with SHA256 collisions? That has to be the biggest streach theory I've heard all weak and I really wanna know how the reporter got that out of him. :P 01:15 < gmaxwell> yea PBC is pretty sweet. 01:16 < gmaxwell> one pairing operation per txn is kinda lame but its not nonviable in the slighest. 01:17 < amiller> why not just merge all the tx 01:17 < amiller> miner makes one big ol operation 01:17 < amiller> one pairing and a dozen of the other things the third one 01:36 < gmaxwell> because the validation needs one pairing per message and public key. 01:37 < amiller> oh 01:43 < gmaxwell> (and one G2 multiply) 01:43 < gmaxwell> er GT multiply. 01:43 < gmaxwell> stupid paring terminology. 08:50 * jgarzik continues to work on auctionpunk 08:50 < jgarzik> new sub-idea: address servers 08:51 < jgarzik> Right now, "auctiond" communicates directly with bitcoind, obtaining addresses for payments and watching for those payments 08:51 < jgarzik> If a third component existed to serve out bitcoin addresses, this auction server need never touch a wallet at all 08:52 < jgarzik> that third component could do what auctiond does now -- call bitcoind getaccountaddress -- or read from a static file of 1 million pre-generated addresses, or any other method 12:40 < HM> or if bitcoind actually talked to a database server, everything could just talk to that :P 12:59 < jgarzik> well, this is more an administrative boundary; trying to design an API around that concept. 13:00 < jgarzik> a wallet is a kay management unit. people may choose to manage keys in different ways. 13:00 < jgarzik> an address server is one way to enable many different wallet configurations. --- Log closed Sun Sep 15 00:00:39 2013