| 00:22:47 | maaku: | jgarzik: speaking of which: http://lunarinitiatives.com/lunarworkshops.com/home |
| 00:22:51 | maaku: | to the moon! |
| 00:23:24 | maaku: | (there's a lunar cubes workshop there) |
| 01:03:43 | maaku: | is it possible to encrypt to 1-of-N keys? |
| 01:05:58 | maaku: | e.g. to do ECDH with a combined key requiring 1-of-N keys to complete the protocol |
| 01:36:56 | gmaxwell: | https://www.eff.org/deeplinks/2014/02/eff-challenges-new-jersey-subpoena-issued-mit-student-bitcoin-developers :-/ |
| 01:47:14 | andytoshi: | <.<. sounds like eff has a pretty solid case tho |
| 01:47:26 | andytoshi: | * andytoshi is formally operating from canada from now on, even so |
| 02:05:58 | maaku: | * maaku needs the protection of a canadian shell company... |
| 02:07:10 | 31NAAEFTQ: | 31NAAEFTQ is now known as IOI_ |
| 10:31:22 | adam3us: | 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:48 | adam3us: | 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:02 | adam3us: | 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:13 | adam3us: | 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:52 | adam3us: | 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:00 | iwilcox: | iwilcox has left #bitcoin-wizards |
| 13:10:27 | _ingsoc: | _ingsoc is now known as Guest12931 |
| 13:32:31 | jgarzik: | jgarzik is now known as home_jg |
| 15:11:50 | _ingsoc: | _ingsoc is now known as Guest26345 |
| 15:47:10 | maaku: | adam3us: yes, it'd be non-interactive. the use case is group communication for coinjoin messages |
| 15:47:50 | maaku: | the offer is broadcast in plaintext, and has both a NetAddr (IP/Tor service + port) and public key |
| 15:48:29 | maaku: | 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:08 | maaku: | just as a matter of efficiency, so you don't have to separately do ECDH and symmetric encryption for each participant |
| 16:14:26 | adam3us: | maaku: not a huge help but ECIES would work, eg k=d*Q=e*G, c=m+k |
| 16:15:36 | adam3us: | maaku: one 256-bit ciphertext per recipient, if the Q, P are already known (should be k=d*Q=e*P above) |
| 19:59:25 | maaku: | 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:47 | maaku: | but it'd be nice to eliminate the more expensive EC operations |
| 20:10:37 | gmaxwell: | maaku: random cpu should be able to do tens of thousands of them per second in any case. |
| 20:26:34 | maaku: | 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:23 | roidster: | roidster is now known as Guest1405 |
| 21:34:34 | EasyAt: | EasyAt is now known as EasyAt|RollyChai |
| 22:24:43 | _ingsoc: | _ingsoc is now known as Guest18009 |
| 23:51:45 | home_jg: | home_jg is now known as jgarzik |