00:22:47maaku:jgarzik: speaking of which: http://lunarinitiatives.com/lunarworkshops.com/home
00:22:51maaku:to the moon!
00:23:24maaku:(there's a lunar cubes workshop there)
01:03:43maaku:is it possible to encrypt to 1-of-N keys?
01:05:58maaku:e.g. to do ECDH with a combined key requiring 1-of-N keys to complete the protocol
01:36:56gmaxwell:https://www.eff.org/deeplinks/2014/02/eff-challenges-new-jersey-subpoena-issued-mit-student-bitcoin-developers :-/
01:47:14andytoshi:<.<. sounds like eff has a pretty solid case tho
01:47:26andytoshi:* andytoshi is formally operating from canada from now on, even so
02:05:58maaku:* maaku needs the protection of a canadian shell company...
02:07:1031NAAEFTQ:31NAAEFTQ is now known as IOI_
10:31:22adam3us:maaku: 1 of n encryption. at least inefficiently yes just encrypt a random sym key for each of n derived using respective ECDH pub keys. directly maybe. i presume you need non-interactively otherwise the interactive 3 party / n-party DH could be used. perhaps the non-interactive weil-pairing could be another way. otherwise as a starting point A=rG, B=m+rQ decrypt m=B-dA A is random.
10:33:48adam3us:maaku: alternatively send 1 of n secret shared encoding of m using k=dQ=eP from each of the n recipients? using k as the missing coefficients in n-1 equations or something like that
12:20:02adam3us:musing about spv committed tx. senders provide keys to committed tx to winning miners. after 6-confirmations there are up to 6 miners who have keys to decrypt the current block. to the extent you trust 6 random miners without the additional enforcement of full nodes being able to validate. then you have privacy (up to the trustworthiness of 6 random miners to not record keys after 6-confirms)
12:25:13adam3us:then you can (up to not independently validatable but spv-proof like security) respend committed tx without revealing full tx history. a spent committed coin is valid to the recipient just by presence of coin in 6-confirms block and key to decrypt forward (but not backward) given to the recipient, and repeat.
12:26:52adam3us:kinda weak, but i thought it an interesting thought experiment. this form of spv is weaker because no history past 6 blocks is considered by miners. bitcoin does full history back to genesis or to snapshot.
12:55:00iwilcox:iwilcox has left #bitcoin-wizards
13:10:27_ingsoc:_ingsoc is now known as Guest12931
13:32:31jgarzik:jgarzik is now known as home_jg
15:11:50_ingsoc:_ingsoc is now known as Guest26345
15:47:10maaku:adam3us: yes, it'd be non-interactive. the use case is group communication for coinjoin messages
15:47:50maaku:the offer is broadcast in plaintext, and has both a NetAddr (IP/Tor service + port) and public key
15:48:29maaku:I was wondering if you could combine the public keys into an 1-of-N construction, and encrypt the session key to that
15:49:08maaku:just as a matter of efficiency, so you don't have to separately do ECDH and symmetric encryption for each participant
16:14:26adam3us:maaku: not a huge help but ECIES would work, eg k=d*Q=e*G, c=m+k
16:15:36adam3us:maaku: one 256-bit ciphertext per recipient, if the Q, P are already known (should be k=d*Q=e*P above)
19:59:25maaku:adam3us: ok that would save from having to encrypt multiple times (as I presume you don't leak any information from reusing the same session key)
19:59:47maaku:but it'd be nice to eliminate the more expensive EC operations
20:10:37gmaxwell:maaku: random cpu should be able to do tens of thousands of them per second in any case.
20:26:34maaku:yeah my concern was more mobile power usage, but I suppose that is trivial compared with what it costs to broadcast these messages anyway
21:07:23roidster:roidster is now known as Guest1405
21:34:34EasyAt:EasyAt is now known as EasyAt|RollyChai
22:24:43_ingsoc:_ingsoc is now known as Guest18009
23:51:45home_jg:home_jg is now known as jgarzik