--- Day changed Sat Feb 10 2018
01:58 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…]     
06:03 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #secp256k1     
07:15 < andytoshi> so taek has a neat application for BPs ... you can do outsourceable mining by choosing a secret x, sending H(block || x) to a miner and having them grind a PoW on it
07:15 < andytoshi> then your block header validity condition would be a zk proof "i know x and a PoW on H(block || x)", with only the block as public input
07:17 < andytoshi> the idea being that people who care about the blockchain can basically turn money into PoW without being concerned about the motivations of the hashpower owners
07:50 -!- Taek [~quassel@2001:41d0:1:472e::] has joined #secp256k1     
07:50 -!- Taek [~quassel@2001:41d0:1:472e::] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]     
07:51 -!- Taek [~quassel@2001:41d0:1:472e::] has joined #secp256k1     
10:14 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #secp256k1     
11:38 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]     
11:38 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1     
12:17 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
13:45 -!- mlz [~IRCIdent@unaffiliated/molly] has joined #secp256k1     
13:45 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #secp256k1     
15:23 < gmaxwell> andytoshi: I don't really understand the purpose there; what does the miner being able to identify their blocks harm?  Also, because the BP is somewhat slow to validate it somewhat defeats the purpose of POW for anti-dos
16:41 < gmaxwell> I'd like some help improving the handshake in BIP150.  The current one has a minor information leak that we can eliminate.
16:43 < gmaxwell> Basically the BIP is designed to not leak who a peer is expecting.  The way it works is that when a client connects to someone it would like to authenticate itself, is it sends H(session_id||expected_pubkey).  The server side can now consult its list of public keys (Which is presumably short), and if it finds a match, can complete the auth.
16:44 < gmaxwell> If it doesn't know of the public key the client is attempting, it doesn't learn anything else about the client's expectations.
16:44 < gmaxwell> So for example, you can't MITM all traffic out of a client and make a list of the pubkeys it expects in order to track it around.
16:44 < gmaxwell> The slight weakness is that if you know some of the expected public keys (e.g. due to people publishing them) then you can identify them when the client attempts to use them.
16:46 < gmaxwell> We can harden against this by instead of the hash the client sends rG,E(rP||session_id) -- an ecdh encryption of the session ID. Now you can't reconize a client's attempt without knowing the private key.
16:46 < gmaxwell> But I think if we drop the property that the server can have multiple public keys (per listening address) then we can achieve a much stronger privacy property.
16:48 < gmaxwell> I think a protocol is possible where the client, expecting a particular server public key, sends a challenge to the server, the server processes the challenge with its private key and replies. If the server's key was the one the client expected, then the client knows he's talking to the server.  Otherwise he learns nothing of the key the server used.  And the server never learns if the client successfu
16:48 < gmaxwell> lly authenticated him or not.
16:49 < gmaxwell> This would be a nice privacy improvement, because it would make it harder for me to give different keys to different clients in order to tell which of them is connected to me.
16:49 < gmaxwell> But I'm being blonde today and a candidate construction isn't coming to mind.
16:51 < gmaxwell> the closest I have right now is that we can do a private set intersection on the server's public key, where the client learns if a key the server is claiming to have is the one he was expecting, but the server learns nothing, and the client learns nothing of the server's key if it wasn't the one he was expecting... but that protocol completes even if the server doesn't know the private key.
16:52 < gmaxwell> and I want a version where the protocol only completes if the server knows the right private key.
19:08 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #secp256k1     
20:02 < gmaxwell> Got it, I'm pretty sure.
20:04 < gmaxwell> The idea is that the client uses ECDH to send the server an encryption of a random number.  If the server uses the wrong key, he gets uniform nonsense.   Client and server hash the resulting random number with the expected public key and the session ID.
20:05 < gmaxwell> Then the client constructs a polynominal which is zero only at the resulting hash.  The client then creates an elgamal encryption if the coefficients, and send them to the server.
20:06 < gmaxwell> The server evaluates the encrypted polynomial at the hash location, and multiplies the result by a random number.
20:07 < gmaxwell> It then sends this to the client, which then decrypts to find out if it got an encryption of zero.
20:08 < gmaxwell> So in this process the server learns nothing about the identity the client is looking for. And the client learns that its talking to the server if and only if it's talking to the right server.
20:08 < gmaxwell> The client can't save its traffic and try it against a list of server public keys, he can only try one server key per connection interactively.
20:08 < gmaxwell> now I only need a pithy name for it.
20:09 < gmaxwell> The server also doesn't learn if it succesfully authenticated... so it learns nothing that could help it track clients.
20:12 < gmaxwell> now I can finally eat.
21:16 < gmaxwell> This protocol generalizes to an arbritary (but visible) number of attempted and offered identities.  Though the part accepting the authetication can tell which one was accepted. Though perhaps I could make that semi-honest secure so they didn't.
21:17 < gmaxwell> e.g. you attempt ECDH with everyone that you would accept. Then make your polynomial have zeros at for each of them... but then the evaluations could be returned in some sorted order instead of the original order.  I'm not sure, in my concrete construction I do random*EncPoly(x)+x so the decryptions are distinguisable.
21:18 < gmaxwell> The server->client auth its totally reasonable to have only one candidate on each side, but client to server auth if it used the same protocol would want to have multiple candidates.
22:04 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: Later.]     
22:05 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #secp256k1     
22:19 < Taek> There are a couple of things that you can do with unlinkable outsourced mining, though it mostly relates to unfinished work (microchains, anonymous internet routing)
22:20 < Taek> Mining a block is one of the most anonymous ways to get a payment
22:20 < Taek> In a system where thousands or even millions of blockchains exist that all use the same PoW scheme, you could get anonymous money without having mining hardware yourself if you could outsource the mining to a person who had no idea what blockchain they were extending
22:22 < Taek> I was also thinking this could be useful for anonymously paying for bandwidth where you don't necessarily have payment channels open with the people you are routing thorugh
22:22 < Taek> Though I'm not sure if that's ultimately the best way to solve that problem
22:23 < Taek> Within microchains, one of the things you can do is have everyone mine their own blocks
22:23 < Taek> since blocks are very tiny, and also very infrequent, and the network has burst mining instead of continuous mining, you can outsource your PoW every time you want to make a transaction
22:24 < Taek> This means you have access to fee revenue that no other miner has access to
22:24 < Taek> (your own)
22:24 < Taek> When I was working on braids, basically the thing I really could fix was making an even playing field for transaction fees
22:25 < Taek> no matter how I mixed things up, I couldn't get to a point where better connected miners didn't also have higher revenue from transaction fees
22:25 < Taek> but if everyone is mining their own blocks, this problem completely disappears. If there is no mempool, and the best you can do as a miner is make yourself available to outsourcing, then you can't gain an advantage in fees by being well connected
22:26 < Taek> Hiding the block that you mined from the miner who mined it is not super important, but it's a nice feature to have and I think would boost overall privacy if you assume a microchains ecosystem