--- Log opened Fri Mar 08 00:00:45 2013 07:26 < HM2> sipa: how are things? 07:28 <@sipa> good, i guess 07:29 <@sipa> some strange findings though: my naive exponentiation ladder for field inversions runs in around 11us, OpenSSL needs 20us,... and GMP less than 1us 07:29 <@sipa> thankfully, we only need 1 field inversion per signature verification 07:29 < HM2> so GMP basically rocks? 07:30 <@sipa> must be 07:30 <@sipa> for normal field multiplications, my own code is still 3x faster than GMP, but it's very specialized for secp256k1 07:31 < HM2> have you got a full signature verifier built yet? 07:31 <@sipa> no 07:31 <@sipa> layer per layer :) 07:32 <@sipa> CodeShark wrote a field inversion that's a bit faster than mine, but still way slower than GMP 07:33 < HM2> perhaps GMP are using SSE and friends? 07:33 <@sipa> maybe 07:34 <@sipa> but i don't want to go into maintaining several branches of assembly code, for an operation that takes less than 10% of the total time 07:34 < HM2> Indeed 07:35 <@sipa> the fieldelem code i wrote already requires a __int128 type, which means a recent compiler and a 64-bit platform 07:35 <@sipa> so probably we'll need a more generic version that runs on 32-bit as well anyway 07:41 < HM2> pffft 32-bit 07:42 < HM2> bigints are such a pain in the arse, i'm beginning to wish all languages (at least JIT'd ones) just made them their default integer type 07:43 < HM2> Javascript has perhaps the most JIT engineering going in to it at the moment and the default numeric type is a bloody double 07:46 <@sipa> haha 11:10 <@gmaxwell> Anyone read http://matt.singlethink.net/projects/mpotr/oldblue-draft.pdf yet? (may have usefulness for some of the bank stuff where you need to avoid people hiding disclosures, without invoking a whole blockchain for byzantine agreement) 12:02 < HM2> C++ is currently making me want to kill someone 12:14 < helo> that's the problem with human-computer interfaces imo 12:14 < jgarzik> all languages suck 12:35 < HM2> indeed 22:16 <@gmaxwell> petertodd: so wrt, the provable balance bank, we'd talked about having users publish signatures of the root once they've verified their balance, after which the service could forget their past transaction history (since they can no longer dispute it), and it could recover the balances of users who stop signing for too long. (preventing bloat and loss of abandoned funds and encouraging people to check) 22:18 <@gmaxwell> that left an open question of how to avoid cases there the bank would 'fail' to recieve a signature for too long in order to steal funds. An obvious solution there is to have the users share signatures in a broadcast medium, and each signature includes a hash of all the other signatures that signer was aware of. 22:18 <@gmaxwell> so a cheating bank couldn't selectively ignore a single user they wanted to screw. 22:19 <@gmaxwell> e.g. you submit your signature, bank says— you have some sigs I don't provide them. So denying one parties signature rapidly makes the bank unable to accept any at all. 22:49 < amiller> that's really similar to truledger / opentransactions / the whole line of triple signed transactions stuff 22:50 < amiller> except that afaik none of those do it the way you described where it's better because it combines multiple users to make it harder for the server to selectively ignore just one of them... 22:51 < amiller> that's really close to a great solution i think... 22:51 < amiller> it's not in any individual's rational interest to include someone else's signatures 22:52 < amiller> it's a social good to do so - but if there's a risk that the server is trying to ignore someone's messages, if you include them then the server might try to ignore yours, so it's not your problem and you should just let someone else can help 22:53 <@gmaxwell> amiller: meh, it's ~costless and if the server ignores yours too you know the server is cheating which is the point. Someone else can them prove to themselves that the server is cheating by including yours and seeing that they also get ignored. 22:54 < amiller> well you can begin to suspect the server's cheating but you can't prove it 22:54 < amiller> i think that's fixable i don't mean to detract from the main idea there 22:55 < amiller> it's like red-balloons fixable 22:55 <@gmaxwell> Well, if you know how to make it sound I'm interest if just for novelty. The ideas we were talking about simple measures for a pratical system rather than a maximally sound one. 22:55 <@gmaxwell> s/interest/interested/ 22:59 < amiller> also just providing a hash of the signatures you know about isn't really good enough 22:59 < amiller> because then you could easily dos someone by providing them a bunch of signed transactions that you _haven't_ sent to the server itself 22:59 < amiller> then the server would send back messages like 'i don't recognize that signature' and it would be legitimate 23:00 < amiller> you could relay all the transactions you know about sure 23:01 <@gmaxwell> well I was reducing to IRC length. You'd presumably send some determinstic tree root, and the server would iteratively query you to agreement. To keep the tree small the server could sign signatures he as recieved, allowing you to prune those. 23:04 < amiller> it's probably cheaper to send a bigger packet than wait for potentially numerous round trips 23:05 <@gmaxwell> true enough, esp if server signatures are constantly pruning the set of unknown signatures. 23:06 < amiller> for the time being i don't have any good clear answer for how to properly incentive-correct this but that would be a really cool goal and the normal way you described would be practical as it is 23:07 < amiller> i think having a good incentive solution for this + metavalidation rules would be exactly the two things needed to have networks of smaller blockchains 23:09 <@gmaxwell> mostly I'm trying to think in the space of ideas that can be implemented incrementally to take a simple system e.g. IRC micropayment bots and make them into something that isn't a straight up scam hazard... stuff that still has most of the scalablity, flexibility, and pratical privacy of centeralized systems but is a little more trustworthy. --- Log closed Sat Mar 09 00:00:46 2013