--- Day changed Sat Nov 29 2014 00:14 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds] 00:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 00:32 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards 00:32 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] 00:32 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards 00:34 -!- Dr-G3 is now known as FBI-AGENT 01:00 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 244 seconds] 01:03 -!- wallet42 [~wallet42@e179185070.adsl.alicedsl.de] has quit [Quit: Leaving.] 01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards 01:05 * andy-logbot is logging 01:06 -!- webdeli [~projects@bit1642888.lnk.telstra.net] has quit [Remote host closed the connection] 01:20 -!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has quit [Ping timeout: 255 seconds] 01:33 -!- hollandais [~irenacob@li629-190.members.linode.com] has quit [Remote host closed the connection] 01:33 -!- c0rw|sle_ is now known as c0rw|away 01:35 -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards 01:43 -!- hollandais [~irenacob@li629-190.members.linode.com] has joined #bitcoin-wizards 01:53 -!- bit2017 [~linker@1.54.25.127] has joined #bitcoin-wizards 01:55 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 01:55 -!- coiner [~linker@1.54.25.127] has quit [Ping timeout: 255 seconds] 02:03 -!- berndj-blackout is now known as berndj 02:11 -!- nuke1989 [~nuke@46-136-96.adsl.cyta.gr] has quit [Read error: Connection reset by peer] 02:12 -!- nuke1989 [~nuke@46-136-96.adsl.cyta.gr] has joined #bitcoin-wizards 02:23 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 02:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 02:37 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 250 seconds] 02:39 -!- oakpacific [~oakpacifi@2.127.106.88] has joined #bitcoin-wizards 02:49 -!- c0rw|away [~c0rw1n@181.66-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds] 02:53 -!- c0rw|away [~c0rw1n@91.176.95.227] has joined #bitcoin-wizards 02:56 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] 02:56 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards 02:56 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] 02:56 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards 02:57 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] 02:57 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards 03:09 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards 03:13 -!- adam3us [~Adium@207.134.53.206] has joined #bitcoin-wizards 03:41 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards 03:43 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Remote host closed the connection] 03:55 -!- koshii [~0@50.151.108.101] has quit [Quit: leaving] 04:05 -!- koshii [~0@50.151.108.101] has joined #bitcoin-wizards 04:12 -!- Nightwolf [~Nightwolf@unaffiliated/nightwolf] has quit [Ping timeout: 255 seconds] 04:14 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 04:15 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Read error: Connection reset by peer] 04:16 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 04:20 -!- belcher [~belcher-s@5ec18bcf.skybroadband.com] has joined #bitcoin-wizards 04:20 -!- belcher [~belcher-s@5ec18bcf.skybroadband.com] has quit [Changing host] 04:20 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards 04:20 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 04:28 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection] 04:29 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards 04:56 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 04:59 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 04:59 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards 05:04 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 05:16 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 05:20 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 05:22 -!- mortale [~mortale@gateway/tor-sasl/mortale] has quit [Ping timeout: 250 seconds] 05:37 -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards 05:38 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] 05:39 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards 05:41 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit] 05:43 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 265 seconds] 05:50 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards 06:08 -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has quit [Ping timeout: 255 seconds] 06:09 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] 06:14 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 06:19 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 06:20 -!- Quanttek [~quassel@2a02:8108:d00:870:9de8:5fb:e332:653b] has joined #bitcoin-wizards 06:20 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 06:25 -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has joined #bitcoin-wizards 06:29 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards 06:31 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards 06:38 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 256 seconds] 06:40 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards 06:47 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Remote host closed the connection] 06:47 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards 06:49 < adam3us> so petertodd gengix and gwern discussed and then petertodd implemented a scheme for time-lock encryption https://github.com/petertodd/timelock and peter mentions gengix and links to gwern. http://www.gwern.net/Self-decrypting%20files 06:51 < adam3us> and if i am understanding it correctly, the idea is to farm out a say 1000 1hr hashchains to 1000 nodes starting from 1000 independent IVs, then encrypt the second IV with the k1=H^k(iv1) so you have E_k1( iv2 ) and so on. 06:51 < adam3us> the idea being setup is parallel but decrypt is serial 06:52 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 06:52 < adam3us> now this has a problem firstly it takes as much aggregate work to setup as decrypt. secondly the nodes you farm the setup to could remember the solutions and collude to decrypt with no additional work. 06:52 < kanzure> sounds right 06:52 < kanzure> oh, which nodes are you expecting to farm out to? 06:53 < adam3us> it doesnt say.. i was guessing other people? as they were talking long time-frames for decryption and presuming the person doesnt have a personal supercomputer. 06:53 < adam3us> (eg like month per parallel thread so it could take years to decrypt) 06:56 < adam3us> anyway i think its missing several solutions which are more efficient and private/secure against collusion. if you choose random key k encrypt m the message with it c=E_k(m) and and then publish c, and truncate k to delete 64-bits you get instant no work setup of a 2^64 decryption challenge. tune as you wish to get more or less work. 06:58 < adam3us> now that is random and the searcher could get lucky, but you can apply it multiple times to reduce the variance to negligible. eg iv1000=E_k1000(m), iv999=E_k999(iv1000) … iv1=E_k1(iv2) and omit the desired number of bits eg 56 bits missing from each of 1024 challenges gives the 64-bit work factor low variance, no trust, negligible cost during setup 06:58 < op_null> kanzure: the point is that you can parallelize generation. on a GPU you can do lots of concurrent threads, if you're limited to just one there's not much you can do but get an intel CPU and overclock the shit out of it. 06:59 < kanzure> my question was actually about the upfront setup collusion actually 06:59 < kanzure> but anyway, key truncation.. hm. 06:59 < adam3us> op_null: yeah but my point is you can generate KDFs with arbitrary iterations/work and your choice variance with negligible work 07:00 < adam3us> this could be done with PBKDF2 or such things. eg you could setup a high work KDF from a cell phone processor in a fraction of a second that'd take as long as you want on a desktop. 07:01 < op_null> right, I was just talking about "now this has a problem firstly it takes as much aggregate work to setup as decrypt." in particular. I don't think it's a real problem that the amount of work is the same, really. 07:02 < op_null> I'm attracted to the idea just because there's not all that many problems you have to solve by using liquid nitrogen CPU cooling. 07:02 < adam3us> op_null: well it is because work has cost, and also you cant securely outsource this work. say you need to at short notice send a very secure/time-locked message from a cell phone using a panic button. now-what. and you dont trust the network at large not to cache the parallel setup parts. 07:03 < adam3us> (they could be sold when the actual decryptors come back and pay people to decrypt things at a profit because the worker gets paid twice for the same work) 07:03 < op_null> oh yeah, of course then you're toast. alternatives are great. 07:05 -!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has joined #bitcoin-wizards 07:06 < adam3us> there is work you can securely outsource.. i made an intentionally parallelizable KDF that is blind and so securely outsourceable … not time-lock but work-locked. you can get it solved in a fraction of a second using litecoin miners (people who want to sell gpu-work at litecoin $/CPU KHrates) securely from a smart-phone 07:06 < adam3us> there is a non-parallelizable version of that (had to do extra things to make it parallelizable) 07:07 < adam3us> https://bitcointalk.org/index.php?topic=311000.0 07:08 < adam3us> (thats a different use-case really. cost-locked vs time-locked) 07:08 < adam3us> if it costs $5 per password guess that is protecting $100,000 even a weakish password will be net loss to attack (using a KDF with those properties) 07:12 < adam3us> an outsourceable non-parallel KDF could be useful also if the encrypted message is public, and the person paying for the work doesnt trust them to not decrypt the document he paid to decrypt. 07:14 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 07:19 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 07:19 -!- mkarrer_ is now known as mkarrer 07:19 -!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards 07:28 -!- yottabit [uid36770@gateway/web/irccloud.com/x-nfsbhhqgttnqdhrt] has joined #bitcoin-wizards 07:45 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 272 seconds] 07:47 -!- rdponticelli [~quassel@gateway/tor-sasl/rdponticelli] has joined #bitcoin-wizards 07:51 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards 07:54 -!- adam3us [~Adium@207.134.53.206] has quit [Quit: Leaving.] 07:59 -!- op_null [~op_null@178.62.133.216] has quit [Quit: Lost terminal] 08:06 -!- antanst [~antonis@adsl-54.176.58.234.tellas.gr] has joined #bitcoin-wizards 08:08 -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has quit [Remote host closed the connection] 08:10 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds] 08:11 -!- Nightwolf [~Nightwolf@unaffiliated/nightwolf] has joined #bitcoin-wizards 08:12 -!- spinza [~spin@197.89.24.35] has quit [Ping timeout: 250 seconds] 08:14 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 08:16 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Read error: Connection reset by peer] 08:16 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 08:17 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 08:17 -!- rdponticelli [~quassel@gateway/tor-sasl/rdponticelli] has quit [Ping timeout: 250 seconds] 08:19 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Remote host closed the connection] 08:20 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 08:23 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 08:24 -!- antanst [~antonis@adsl-54.176.58.234.tellas.gr] has left #bitcoin-wizards [] 08:24 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards 08:26 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards 08:31 -!- oakpacific [~oakpacifi@2.127.106.88] has quit [Ping timeout: 250 seconds] 08:31 -!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has joined #bitcoin-wizards 08:37 -!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has quit [Quit: Leaving.] 08:44 -!- Starduster [~Guest3@unaffiliated/starduster] has quit [Read error: Connection reset by peer] 08:44 -!- Starduster [~Guest3@unaffiliated/starduster] has joined #bitcoin-wizards 08:45 -!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has joined #bitcoin-wizards 08:51 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 08:58 -!- lclc_bnc is now known as lclc 09:03 -!- roconnor [~roconnor@e120-pool-d89a79cf.brdbnd.voicenetwork.ca] has joined #bitcoin-wizards 09:05 -!- samson_ [~samson_@183.89.22.186] has quit [] 09:05 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 264 seconds] 09:05 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards 09:10 -!- bit2017 [~linker@1.54.25.127] has quit [Ping timeout: 264 seconds] 09:14 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 09:14 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 09:15 -!- NewLiberty [~NewLibert@99-48-178-219.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards 09:16 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards 09:19 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 09:22 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection] 09:25 -!- lclc is now known as lclc_bnc 09:27 -!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has joined #bitcoin-wizards 09:29 -!- waxwing [waxwing@gateway/vpn/mullvad/x-knrbngcfmhxbeaor] has quit [Read error: Connection reset by peer] 09:31 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-wizards 09:37 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 256 seconds] 09:41 -!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has quit [Quit: Leaving.] 09:42 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 09:45 -!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has joined #bitcoin-wizards 09:46 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds] 09:48 -!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has quit [Client Quit] 09:49 -!- waxwing [waxwing@gateway/vpn/mullvad/x-hrclowovttsoucbd] has joined #bitcoin-wizards 09:53 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] 09:53 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards 09:56 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 09:58 -!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has joined #bitcoin-wizards 10:03 -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has quit [Ping timeout: 250 seconds] 10:06 -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has joined #bitcoin-wizards 10:08 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 10:09 -!- adam3us [~Adium@207.134.53.206] has joined #bitcoin-wizards 10:09 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards 10:12 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards 10:12 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection] 10:14 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 255 seconds] 10:14 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 10:19 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 10:19 -!- spinza [~spin@197.89.10.145] has joined #bitcoin-wizards 10:19 -!- spinza [~spin@197.89.10.145] has quit [Excess Flood] 10:19 -!- spinza [~spin@197.89.10.145] has joined #bitcoin-wizards 10:19 -!- spinza [~spin@197.89.10.145] has quit [Excess Flood] 10:20 -!- spinza [~spin@197.89.10.145] has joined #bitcoin-wizards 10:24 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards 10:24 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] 10:24 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards 10:26 -!- samson_ [~samson_@183.89.22.186] has joined #bitcoin-wizards 10:33 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 264 seconds] 10:37 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards 10:37 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection] 10:43 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 255 seconds] 10:44 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards 10:46 -!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has quit [Ping timeout: 258 seconds] 10:47 -!- Meeh [~meeeeeeh@meeh.sigterm.no] has quit [Quit: No Ping reply in 180 seconds.] 10:48 -!- Meeh [~meeeeeeh@meeh.sigterm.no] has joined #bitcoin-wizards 10:49 -!- spinza_ [~spin@197.89.24.188] has joined #bitcoin-wizards 10:50 -!- spinza [~spin@197.89.10.145] has quit [Ping timeout: 255 seconds] 10:51 -!- lclc_bnc is now known as lclc 10:56 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 11:02 -!- lclc is now known as lclc_bnc 11:04 -!- soundx_ [~soundx@37.157.195.143] has joined #bitcoin-wizards 11:08 < kanzure> http://underhandedcrypto.com/rules/ "The Underhanded Crypto contest was inspired by the famous Underhanded C Contest, which is a contest for producing C programs that look correct, yet are flawed in some subtle way that makes them behave inappropriately. This is a great model for demonstrating how hard code review is, and how easy it is to slip in a backdoor even when smart people are paying attention. We’d like to do the same for ... 11:08 < kanzure> ... cryptography. We want to see if you can design a cryptosystem that looks secure to experts, yet is backdoored or vulnerable in a subtle barely-noticable way. Can you design an encrypted chat protocol that looks secure to everyone who reviews it, but in reality lets anyone who knows some fixed key decrypt the messages? We’re also interested in clever ways to weaken existing crypto programs. Can you make a change to the OpenSSL ... 11:08 < kanzure> ... library that looks like you’re improving the random number generator, but actually breaks it and makes it produce predictable output?" 11:25 -!- askmike [~askmike@92.69.252.98] has joined #bitcoin-wizards 11:28 < gwillen> kanzure: I propose taking the current openssl source and submitting it, alleging that you have made it subtly vulnerable 11:28 < gwillen> and see what they find 11:29 < nsh> hah 11:29 < kanzure> they accept existing code only if you have modified it 11:29 < kanzure> which is pretty easy to check (diffs) 11:30 < kanzure> and i think they have you submit and make your changes obvious 11:30 < gwillen> heh, darn 11:37 -!- xuxu [~xuxu@unaffiliated/xuxu] has joined #bitcoin-wizards 11:37 -!- xuxu [~xuxu@unaffiliated/xuxu] has quit [Client Quit] 11:38 -!- soundx_ [~soundx@37.157.195.143] has quit [K-Lined] 11:47 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards 11:49 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection] 11:49 -!- askmike [~askmike@92.69.252.98] has quit [Read error: Connection reset by peer] 11:52 -!- NewLiberty [~NewLibert@99-48-178-219.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 264 seconds] 12:02 -!- spinza [~spin@197.89.24.98] has joined #bitcoin-wizards 12:02 -!- spinza [~spin@197.89.24.98] has quit [Excess Flood] 12:04 -!- spinza_ [~spin@197.89.24.188] has quit [Ping timeout: 256 seconds] 12:09 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 12:09 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 12:09 -!- FBI-AGENT is now known as Dr-G 12:10 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 12:14 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 12:19 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 12:31 < adam3us> submit ekr's patches? ;) ooh politically insensitive 12:32 -!- c0rw|away is now known as c0rw1n 12:33 < adam3us> eg the one that broadcasts extra randomness to amplify the ec drbg breakage 12:33 -!- adam3us [~Adium@207.134.53.206] has left #bitcoin-wizards [] 12:33 -!- adam3us [~Adium@207.134.53.206] has joined #bitcoin-wizards 12:36 < sipa> ? 12:36 < sipa> ah 12:57 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards 13:04 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] 13:04 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection] 13:07 -!- MoALTz [~no@user-164-126-229-18.play-internet.pl] has joined #bitcoin-wizards 13:08 -!- AnoAnon [~AnoAnon@197.37.73.249] has joined #bitcoin-wizards 13:08 -!- AnoAnon [~AnoAnon@197.37.73.249] has quit [Read error: Connection reset by peer] 13:14 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards 13:16 -!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards 13:16 -!- spinza [~spin@197.89.23.217] has quit [Excess Flood] 13:16 -!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards 13:16 -!- spinza [~spin@197.89.23.217] has quit [Excess Flood] 13:17 -!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards 13:17 -!- spinza [~spin@197.89.23.217] has quit [Excess Flood] 13:17 -!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards 13:17 -!- spinza [~spin@197.89.23.217] has quit [Excess Flood] 13:18 -!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards 13:18 -!- spinza [~spin@197.89.23.217] has quit [Excess Flood] 13:19 -!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards 13:19 -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] 13:21 -!- yottabit [uid36770@gateway/web/irccloud.com/x-nfsbhhqgttnqdhrt] has quit [Quit: Connection closed for inactivity] 13:35 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!] 13:36 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards 13:39 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards 13:42 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Client Quit] 13:49 -!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has quit [Remote host closed the connection] 14:06 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] 14:07 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards 14:07 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] 14:07 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards 14:08 -!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has joined #bitcoin-wizards 14:12 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 256 seconds] 14:23 -!- grandmaster2 [dansmith3@knows.the.cops.are.investigat.in] has quit [Quit: quit] 14:24 -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has joined #bitcoin-wizards 14:24 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection] 14:25 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards 14:35 < tacotime> someone wrote a paper about using a paillier cryptosystem to enhance blockchain privacy in conjunction with utxo-bearing spvs 14:35 < tacotime> https://drive.google.com/file/d/0B21vncLoIlIyaVpGVFN5c1VFdmM/view 14:41 -!- Aquent1 [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards 14:41 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection] 14:41 < kanzure> wasn't there something recent about xss vulnerabilities in google drive.. hrm. 14:41 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards 14:42 < tacotime> kanzure: if you are afraid i will dl the pdf and email it to you 14:42 < tacotime> not that pdfs are much safer 14:47 < kanzure> i feel like my options are one terrible javascript execution environment for another terrible javascript execution environment 14:48 < tacotime> and good discussion from gmaxwell/adam3us here: https://bitcointalk.org/index.php?topic=872377.0 14:48 < adam3us> see https://bitcointalk.org/index.php?topic=872377.msg9647318#msg9647318 they seem to be confused about the need for 14:48 -!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has joined #bitcoin-wizards 14:49 < adam3us> tacotime: ah yes. that :) the need for paillier at all. its avoids introducing another crypto-assumption, is more compact to use EC DLOG than paillier (256-bit ciphertext vs 6kbit) plus they did not seem to realise that you need to prevent wrapping mod n. or misread the paper they got one of the parts from to assume it implied wrapping prevention, which afaik it does not. 14:51 < tacotime> yeah i was reading about paillier and saw it was using RSA keys and became afraid. i will read over your homomorphic value scheme, must have missed it before. :) 14:52 < adam3us> the homomorphic value is not doing anything exciting.. all standard zkp & EC dlog. 1kbit for encrypted value vs 64-bit for unencrypted. 14:54 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 245 seconds] 14:57 < gmaxwell> oh I was just typing what adam3us already typed. 14:57 < adam3us> uh 1kbyte not 1kbit. i think the effect is quite exciting though :) hide the values while still validating that they add up. (though you can still tell that the person who sent it to you had at least that value). i talked about it a bit some video and slides https://bitcointalk.org/index.php?topic=509674.0 14:58 < gmaxwell> It needs proofs to prevent the wrap and I don't know how to construct those compactly (while staying with just boring cryptographic assumptions) 14:59 < adam3us> skip to 49m on the video for the encrypted value part https://www.youtube.com/watch?v=3dAdI3Gzodo&feature=youtu.be 14:59 < tacotime> cool, ty. 15:02 < adam3us> i wonder.. you could probably improve the hiding of where the money came from by proving that the sum of the inputs is the value, without revealing to the recipient the allocation of value across those inputs. didnt think of that before. 15:03 < nsh> gmaxwell, what's the security effect of wrapping around n? 15:03 < nsh> or cryptopathogenesis 15:05 < gmaxwell> nsh: it's a total break. It only shows your outputs are congruent to your inputs mod n. 15:06 < nsh> hmm 15:06 < kanzure> andy-logbot: what about non-interactive proofs where the proof isn't about some specific data, but rather just something like "the value is greater than or equal to n" or "the value is less than n"? does this exist 15:06 < gmaxwell> so e.g. you can create enormous value outputs when you only have a few coins. 15:06 < andy-logbot> I'm logging. I don't understand 'what about non-interactive proofs where the proof isn't about some specific data, but rather just something like "the value is greater than or equal to n" or "the value is less than n"? does this exist', kanzure. Try /msg andy-logbot help 15:06 < kanzure> oops 15:06 < kanzure> andytoshi: what about non-interactive proofs where the proof isn't about some specific data, but rather just something like "the value is greater than or equal to n" or "the value is less than n"? does this exist 15:06 < gmaxwell> kanzure: there are proofs for this, seem adam3us' writeup, but they are not tiny. 15:07 < nsh> oh god, the logbots are starting giving academic interjections now. skynet dawns 15:07 < kanzure> hmm okay then 15:07 < nsh> *have started 15:09 < gmaxwell> really, the problem is that expanding values to a kilo-bit for encryption would be bad enough that it would be hard to tolerate. ... having to go to several times that for all the proofs is ... considerable overhead. 15:09 < adam3us> kanzure: yes its a research area for "zk range proofs" the one i focussed on optimizing is one by berry schoenmakers which is simple & convenient for EC dlog. this kind of proof is useful in many protocols because most zkps are all modulo n so you either need to prove n is >> the values so it couldnt wrap, or that it doesnt wrap 15:15 < nsh> still hard to intuit why proving nonwrap would require extra stronger assumptions 15:17 * nsh reads more 15:18 < nsh> (or is that just within efficiency tolerances) 15:21 < adam3us> gmaxwell: yes i am disappointed about the size. annoying range proofs. 15:22 < adam3us> gmaxwell: about the only thing you could say in defence is that without hiding the value, if you actually cared about privacy to that degree you'd be sending multiple standard-sized values or something. ie these hidden value spends would be providing more privacy per transaction. 15:23 -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has joined #bitcoin-wizards 15:28 < petertodd> adam3us: you're misunderstanding the design space of timelock in a whole variety of ways - anything other than highly optimized algorithms with existing excellent scalar implementations is a bad idea. 15:28 < petertodd> adam3us: (I'll probably switch it to AES when I get around to it) 15:28 -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has quit [Remote host closed the connection] 15:29 < andytoshi> off channel i mentioned to kanzure that i believe you cannot form a NIZK without either CRS and RO (and that i would not trust an RO SNARK, or any "cryptography of programs" that assumed that a big chunk of its own code was ethereal and could not be fed into itself) 15:29 < petertodd> adam3us: secondly the "farm it out" part of the problem is pretty trivial - think of how little parallelism you need to make it practical 15:29 < andytoshi> kanzure: the proofs that adam3us is talking about are in the RO model 15:29 < adam3us> petertodd: yeah but then you need to trust the people you farmed it out to to forget 15:29 < petertodd> adam3us: e.g "I want to lock for 5 years, and I want to setup the proof in a month" -> 60 cores, not a big deal at all to just go out and buy, or if someone writes me a GPU implementation 15:30 < adam3us> petertodd: i do agree that its preferable to use sym key, thats why i rejected pubkey variants, for hashcash 15:31 < adam3us> petertodd: anyway my symkey argument stands: you can do that without oursourcing. just delete keybits. 15:32 < nsh> andytoshi, "ethereal.. fed into itself"? 15:33 < nsh> are there any actually analytically-enlightening papers on how systems break down under various departures from random oracle? 15:34 < adam3us> petertodd: but also the even optimized things get toasted if someone makes an asic for it. probably your best bet would be to use sha256 and find a way to construct it out of repurposing bitcoin miners. 15:34 < rusty2> petertodd: my problem with all timelock schemes is more meta: someone has to care about your specific time-lock. AFAICT that introduces the most variance, as valuable timelocks get attacked first. If someone produces timelocks which can be solved via merge-mining, *that* would open far more uses. 15:35 -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has joined #bitcoin-wizards 15:35 < petertodd> rusty2: my timelock scheme incentivises everyone to crack it because cracking it gets you bitcoins 15:35 < gmaxwell> andytoshi: I am moving my eyebrows at your dismissal of RO assumptions. 15:35 -!- rusty2 is now known as rusty 15:35 < nsh> (constraining algorithms and protocols in the interests of maintaining the utility of legacy hardware is definitely not something that's going to cause later regret) 15:35 < nsh> (not this time!) 15:35 < petertodd> rusty2: solves that problem, *and* gives solid proof of what's the fastest scalar implementation out there (by people willing to use it publicly) 15:36 < andytoshi> gmaxwell: specifically for SNARKs, things like KDM-secure encryption, obfuscation 15:36 < andytoshi> gmaxwell: anything that treats code as executable code (as opposed to blindly treating its input as data) 15:36 < petertodd> rusty: tech is such that that scalar implementation is very likely close to the best possible (<10x) 15:37 < andytoshi> nsh: one sec, i have an example of a broken RO-secure system for KDM-secure encryption.. 15:37 < gmaxwell> andytoshi: the only RO assunption _required_ for a SNARK is a fiat shamir transform to make the protocol non-interactive. 15:37 < adam3us> petertodd: dont forget people may have an interest to crack lots of time-lock in parallel if they got used much at vastly lower J/crack 15:37 < andytoshi> gmaxwell: oh, FS i think is ok 15:37 -!- adam3us [~Adium@207.134.53.206] has quit [Quit: Leaving.] 15:37 < andytoshi> but i don't really trust that feeling because i can't tell why exactly i'm ok with fs 15:38 < nsh> +1 economy of scale cracking 15:38 < rusty> petertodd: If I understand correctly, you don't scale. How do I make my timelocked will-and-testament, for example? Do I hook onto your current puzzles somehow? 15:38 < andytoshi> nsh: bottom of page 19 https://eprint.iacr.org/2007/315.pdf 15:39 < nsh> ty 15:39 < andytoshi> oh, i'm OK with FS because it treats its input as raw data 15:39 < andytoshi> to contrast, the example i just gave to nsh (which is pretty jargonny, sorry) is using the RO in a pretty integral way 15:40 < nsh> i still suspect there might be something interest, analogous to andytoshi's impossibility conjecture, if the self-referential part were clearer 15:40 < andytoshi> KDM security is where the attacker can request encryptions of arbitrary functions of the secret key material ... and the "security proof" of one such system assumes that RO output is uniformly random and in particular totally independent of these ciphertexts 15:41 < petertodd> rusty: you spend 1core * T computer power and make it yourself; scales linearly 15:41 < andytoshi> and obviously, in a real system this assumption is false because your RO is instantiated with an actual function you can give to the ciphertext oracle 15:41 < petertodd> rusty: it's meant to actually work, right now, because I had a client who actually needed it... 15:41 < nsh> but really it's would be nice to quantify the weakness in terms of the dependency in terms of some notion of algorithmic-information-theoretical proximity of inputs and outputs 15:42 < nsh> *unmangle() 15:42 < andytoshi> nsh: welll, the way "zero knowledge" is defined in cryptography is in terms of a simulator, so you need an oracle ... this means a CRS ("trusted setup oracle"), an RO, or interaction 15:42 < andytoshi> nsh: but maybe there is a better definition of ZK that'd give us what we want without such a requirement 15:42 < petertodd> adam3us: what's the relevance of what "people might have an interest in cracking in parallel" - I just want a solution that works and is maximally predictable - anything parallel isn't 15:42 < rusty> petertodd: and what would motivate someone to solve it? The cost of that setup seems to be the ~ cost to solve it, since I have to offer a reward. But that seems redundant: is there a system where unrelated parties can share a timelock? 15:43 < nsh> i think we're grasping at a informational theoretical conservation law but it's a bit beyond my conceptual horizons at least 15:43 < petertodd> rusty: the motiviation is there exist Bitcoins on the bitcoin blockchain that by cracking the timelock you get to take the bitcoins... 15:43 < andytoshi> nsh: i hope not :) 15:43 < andytoshi> but maybe, i get that feeling too 15:43 < petertodd> rusty: no such "ulrelated parties" systems exist without adding huge amounts of complexity and/or handwaving 15:43 < nsh> just doesn't sit so well, aesthetically, that the assumptions can't be made less discrete/binary 15:44 < rusty> petertodd: Thanks, I thought that might be the case :( Unfortunately that constrains usage significantly, since the locker has to pay the solving cost. 15:45 < petertodd> adam3us: so, AFAICT your symkey arrangement basically makes it a semi-parallelizable problem? 15:45 < andytoshi> nsh: one thing my team at UT is working on is "universal parameters" which means a single CRS which can then generate other CRS's without additional trust http://eprint.iacr.org/2014/507 15:45 < nsh> very theological :) 15:45 < andytoshi> :P 15:45 < petertodd> rusty: meh, solve problems that actually exist first - like I said, I had a client who actually needed a working timelock crypto application! (and hell, I found another person who needed one after) 15:46 < andytoshi> nsh: using obfuscation they have a selectively secure candidate ... one discouraging theoretical result they have is that adaptive security is impossible even in the RO model 15:46 < andytoshi> which is much stronger than my impossibility result...plus they actually finished it instead of handwaving the way i did :P 15:46 < nsh> ((iacr.org should apply some sort of latex.js for abstracts)) 15:47 < nsh> hmm 15:47 < andytoshi> so an open problem is, well, maybe there is a security definition between selectively secure and fully adaptively secure which evades the impossibility result ... how strong a claim do we need to make before it becomes impossible? 15:47 < andytoshi> i dunno, i will spend some time thinking about it over the next months 15:47 < nsh> petertodd, you should be able to solve 5 impossible things for pre-delivery client invoicing before breakfast 15:47 < nsh> you're not thinking MBA-dimensionally, Marty! 15:48 < nsh> andytoshi, a fine question to ponder 15:48 < rusty> petertodd: It's nice work, for sure. 15:48 < andytoshi> nsh: right, right. I have a real problem with that. 15:49 < andytoshi> (re "not thinking MBA-dimensionally") 15:49 < petertodd> rusty: thanks! 15:49 < andytoshi> i had to look up marty's response :P 15:49 < nsh> well, a lot of people have the opposite problem 15:49 < kanzure> consequences of that could be disastrous and destroy the entire universe 15:50 < nsh> i don't mind disaster OR eschaton. it's both at once that really messes up your weekend 15:50 < kanzure> (context: ) (not worth your time) 15:51 < petertodd> adam3us: so the interesting thing re adding a bit of varience back, is it may make cracking timelocks more interesting to the casual observer, becaues even though the guy with a fancy liquid nitrogen cooled rig still has a big edge, it's not a 100% guaranteed edge - helps ensure there's diversity in the community of timelock crackers 15:52 < kanzure> andytoshi: what was the problem again you had with the random oracle model for zero knowledge proofs of knowledge? something about forged or faulty transcripts? 15:52 < kanzure> or, in particular, the forged or faulty transcripts are the thing i'm trying to place 15:53 < andytoshi> kanzure: in the CRS model, the party generating the common reference string has access to secret data which allows them to create "proofs" of false statements 15:54 < nsh> petertodd, can you synopsize what adding variance means? you can make it so the expected time to crack timelock has a higher variance through parameter adjustment? 15:54 < andytoshi> kanzure: in the RO model, my problem was that certain ways of using ROs block attacks by sleight-of-hand assuming they cannot happen 15:54 < andytoshi> kanzure: but if the RO is only used in a fiat-shamir transform, this is not the case (as gmaxwell observers) 15:54 < nsh> (i don't know to what extent you can reliably project statistical distributions onto human cracking motivation) 15:55 -!- null_radix [Elite7851@gateway/shell/elitebnc/x-qdgwevqarjlsaqua] has quit [Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!] 15:55 < petertodd> nsh: so, if I understand adam's proposal, by dropping bits only some fraction of attempts to crack a given key will actually succeed, e.g. drop 1 bit, half succeed 15:55 < nsh> hm 15:56 < petertodd> nsh: though, actually, thinking about it more, that's probably not going to give us what we want, because the guy who can afford 1024 dewars full of boiling LN still wins... 15:57 < kanzure> jokes on you i'm holding out until the LN market falls through 15:57 < petertodd> nsh: (or in adam's example, 2^56 dewars) 15:57 < nsh> just think of the scrap metal value of those cannisters though; practically pays for itself 15:58 < andytoshi> metallurgy to #bitcoin-alchemists pls 15:58 < petertodd> nsh: which is bad, because we *want* people to invent in small scale but utterly pushing the limits exotic tech to crack this stuff, as that gets you as close as possible to physical limits, and in turn that gives everyone predictability 15:58 * nsh smiles, nods 16:00 < petertodd> nsh: my big question about this is basically how close is, say, the intel AES extensions to implementing optimal silicon? if fed constant data, perhaps not that far away 16:01 < petertodd> nsh: scalar speed is basically just a function of how compact the circuits are and fundemental clockspeed 16:01 < nsh> right 16:01 -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has quit [Remote host closed the connection] 16:02 < nsh> comes down to noise floor distinguishability 16:02 < nsh> but as Feynman said, there's plenty of room at the bottom 16:02 < petertodd> nsh: that and literally the speed of light, well, electrical wave propagation 16:03 < petertodd> nsh: for scalar speed, no there isn't... we're already building circuits with features that countable integer number of atoms wide 16:03 < nsh> or the speed at which we think information moves while it doesn't because we're apes 16:04 * nsh nods 16:05 < nsh> well, there's a whole lot of mathematics going into the color dynamics of each minuscule bit of each minuscule bit of those atoms 16:05 < petertodd> meh, I wouldn' 16:05 < nsh> whether we can overload that dynamics to perform useful calculations and derive classical results is probably an open question below atomic levels 16:06 < petertodd> I wouldn't trust timelock to keep a secret safe for more than ~5yr anyway 16:06 * nsh nods 16:06 < petertodd> you're talking physics voodo - 20 years? maybe? probably not 16:06 < nsh> aye 16:21 -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has joined #bitcoin-wizards 16:24 -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has quit [Remote host closed the connection] 16:25 < kanzure> is http://people.xiph.org/~greg/simple_verifyable_execution.txt really something more like "the output of the program is such that only the unmodified program could have produced that particular output, independent of the value of the output, given that someone else is actually checking my hashes and commitments"? 16:25 < kanzure> i think i am butchering it 16:29 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 16:31 < gmaxwell> kanzure: you have a circuit (the program). There is an wire labeling. The procedure shows that I know a consistent wire labeling. 16:31 < kanzure> second try.. "the output of the program is deterministically encrypted based on the program/circuit"? 16:32 < gmaxwell> (with computational soundness, of course, both from the strength of the comittments and from the F/S sampling) 16:33 < gmaxwell> kanzure: I commit to a wire labeling, without revealing the decryption keys, but tell you enough that you can check its consistency in the encrypted domain. At the end I can selectively reveal some of it (e.g. the output, or some of the inputs) 16:45 -!- Quanttek [~quassel@2a02:8108:d00:870:9de8:5fb:e332:653b] has quit [Ping timeout: 258 seconds] 16:46 < kanzure> a verifier interested in checking the validity of the output would check that they can encrypt the (decrypted, non-verifier-provided) output value (using the encryption keys for the output wires) and get the same encrypted output as the executor claims? 16:46 < kanzure> and then they would check the encrypted output against the commitments (and this is what you call the "encrypted domain")? 16:47 < gmaxwell> yes, note that the encryption keys are comitted too, and their value probablistic verified. 16:57 -!- null_radix [Elite7851@gateway/shell/elitebnc/x-flsbdntiidiqdnwo] has joined #bitcoin-wizards 17:01 -!- c0rw1n is now known as c0rw|sleep 17:03 < kanzure> what can be done without revealing the output? 17:03 < gmaxwell> the output is whatever you want it to be; I mean, it can reveal a single bit if you like. 17:06 < kanzure> uh, is it safe to encrypt a single bit in a public key system? 17:07 < kanzure> oh i'm thinking of signing 17:09 < gmaxwell> there is no public key anything in this. 17:09 < gmaxwell> it's all one-time-pad encryption and hashing. 17:16 -!- Aquent1 [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection] 17:23 < lechuga_> in case any1 has a use for the contracthashtool in ruby: https://github.com/aalness/contracthashtool-ruby 17:35 < kanzure> what is the name of the method for verifying that the encryption key for the final output wires is correct r consistent with the other known properties of the circuit? 17:35 < kanzure> *correct or consistent 17:45 -!- op_null [~op_null@178.62.133.216] has joined #bitcoin-wizards 17:47 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:ccd8:4d7d:19ab:f9c3] has joined #bitcoin-wizards 17:53 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:ccd8:4d7d:19ab:f9c3] has quit [Ping timeout: 258 seconds] 17:56 -!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has quit [] 17:59 -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has joined #bitcoin-wizards 18:11 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has quit [Ping timeout: 250 seconds] 18:11 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds] 18:11 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards 18:12 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards 18:13 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards 18:30 -!- altoz [~altoz@cpe-24-55-38-141.austin.res.rr.com] has joined #bitcoin-wizards 18:36 -!- altoz [~altoz@cpe-24-55-38-141.austin.res.rr.com] has quit [Remote host closed the connection] 18:39 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection] 18:41 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards 18:44 -!- Dr-G [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds] 18:57 -!- tacotime [~mashkeys@198.52.200.63] has quit [Ping timeout: 264 seconds] 19:02 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards 19:02 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards 19:05 -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has joined #bitcoin-wizards 19:10 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards 19:14 -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 19:19 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 19:57 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards 20:00 < rusty> gmaxwell: OK, so I've been persuing this fountain code server idea. It doesn't seem to quite work with a normal LT code (but I think it's fixable) 20:01 < rusty> gmaxwell: assuming the malicious server fails to answer any query which would reveal the corrupt tx, that's much smaller than 50% of queries. 20:01 < rusty> gmaxwell: unless each query asks for about num-txs/2 codes. 20:01 < rusty> gmaxwell: or am I barking up the wrong tree? Again :) 20:02 < lechuga_> fountain code 20:02 < lechuga_> for wat 20:03 < gmaxwell> rusty: depends on the rate of the code; and yes, you may need to move to an edge distribution that is denser than the optimal. 20:04 < rusty> gmaxwell: yes, that was what I was thinking. More like powers of two? So you get the tx you ask for, plus xor of two txs, plus xor of 4 txs ... xor of 2^N txs. 20:04 < gmaxwell> rusty: but wrt rate, you need to be treating it as an infinite rate code, so no two queries are the same, and there needs to be some overhead. (I actually think the overhead can be negligible beyond the decoding bound, but it's probably easier to prove for a factor of two) 20:06 < gmaxwell> lechuga_: Its an approach I came up with a while ago for encoding blocks so that they can be randomly verified and the server can't selectively censor the transcript. (or at least can't do so very effectively while still answering many queries) 20:06 < lechuga_> interesting 20:07 < nsh> nice 20:07 < rusty> gmaxwell: yes, any repeated queries are a waste, but I think feeding two numbers (offset, plus bit pattern of which halves to xor) and getting back log2(num_blocks) might work. 20:08 < gmaxwell> there probably is a completely regular lattice (e.. like what you're describing) that gets the properties we want, esp since we're willing to tolerate overhead. 20:09 < rusty> gmaxwell: I'll play with that, see what I can come up with. Good to know it sounds sane... 20:10 < lechuga_> gmaxwell: is it in your alt-ideas repo? 20:10 < rusty> gmaxwell: I haven't thought hard about deliberately false responses yet, nor about how you'd actually collaborate to detect cheating, given responses are unauthenticated. But perhaps the possibility is sufficient disincentive. 20:12 < gmaxwell> lechuga_: I've posted about it someplace; but IIRC its not on the altideas page as it's somewhat newer than most of the things there. 20:13 < lechuga_> https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding 20:13 < lechuga_> found it thx 20:13 < gmaxwell> Thats related, not quite the same thing. 20:14 < lechuga_> ic 20:14 < gmaxwell> lechuga_: the basic premise is straight forward, blocks are coded with a locally decodable error correcting code such that if you serve out {$blocksize} worth of requests for parts of the block, then those answers if combined could recover the whole block. 20:15 < gmaxwell> The reasoning for this is if you're imagining a model where everyone only randomly verfies parts of blocks, then one attack is to put incorrect data in a single place in the block and just 'magically fall offline' should anyone try to request specifically that part. 20:16 < lechuga_> whats the motivation to only verify random parts, scaling? 20:17 < rusty> lechuga_: yes, and robustness. AFAICT it's the only missing part of https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs 20:18 < gmaxwell> lechuga_: yes, it has better scaling. It goes hand in hand with this idea of fraud proofs.. Once you've made it efficient to randomly verify, if you find a problem it's also efficient to tell other people about the problem. 20:18 < lechuga_> ah ok 20:19 < gmaxwell> And that means that instead of having tens of thousands of nodes all verifying the same thing redundantly, we might get nearly as good security with a thousand fold reduction in computation. 20:19 < lechuga_> swam validation 20:19 < lechuga_> swarm* 20:19 < phantomcircuit> except there's only maybe 6k nodes that are public 20:19 < phantomcircuit> so maybe not 1000x improvement :P 20:20 < gmaxwell> phantomcircuit: nodes don't have to be publicly listening to particpate (and there are a _lot_ more non-listening bitcoin nodes; based on connection counts closer to 100k at least when I last tried estimating it a few months ago; probably down since then) 20:20 < gmaxwell> they just have to not be partitioned. 20:20 < phantomcircuit> hmm that's true 20:20 < gmaxwell> certantly such a system would have more to lose from sybil attacks. 20:21 < gmaxwell> But there are other tools we can deploy to reduce sybil attack risks. 20:22 < phantomcircuit> micro pow schemes? 20:23 < rusty> gmaxwell: inventivising nodes to verify is another issue. I was thinking to have miners to include a few random server responses in their coinbase. 20:23 < gmaxwell> rusty: I actually think that incentivized sybil attacks instead. :( 20:23 * rusty thinks harder.... 20:24 < gmaxwell> (e.g. just run some stupid botnet proxy to pretend to be 100,000 nodes and collect all the monies) 20:24 < gmaxwell> (and now an attack which used to have really speculative profit is guarenteed to be profitable, ... and you can cause whatever trouble you like along the way) 20:25 < gmaxwell> I don't think it's that much of an issue, assuming the cost is made low enough. 20:25 < gmaxwell> but then again, I've thought lots of wrong things before. 20:26 < nsh> dozens even :) 20:26 < gmaxwell> phantomcircuit: so some fun things for anti-sybil: friend network topologies, e.g. "I don't consider myself non-isolated unless I have authenticted connections up to at least two manually configured friends who themselves claim to be non-isolated." 20:28 < rusty> gmaxwell: I'm missing something, clearly. Asking to include server response for tx SHA(SHA(prev-blockhash | yourcoinbase-outputs)) % prev_num_txs (query seed generated similarly, etc) means (1) either the know all the block contents anyway, or (2) they asked the server. 20:28 < op_null> gmaxwell: that is something I would like to explore. having private bitcoin peering with a "friends" model would be nice for stability. I know it happens today, but you could do some nice encrypted connections and relax the DoS rules a bit inside. 20:28 < gmaxwell> phantomcircuit: another one is, beacon servers. It's pretty easy to make a server with massive scale that does nothing but serve headers on a lazy non-super realtime manner. ... so you could plausable use a federation of centeralized servers to detect partitioning. 20:28 < nsh> mm, you can possible couch that into a kind of tiling problem where you constrict the graph control of adversarial arrangement and population primitives through tiling 'shapes' 20:28 < rusty> gmaxwell: ha, I was thinking of serving block headers via SMS. 20:29 < gmaxwell> rusty: petertodd was relaying them via twitter; until twitter blocked it. :( 20:29 < gmaxwell> rusty: oh! I thought you were saying that miners would pay to random nodes in their coinbases. 20:29 < rusty> gmaxwell: no, I'm not quite that dumb! 20:30 < gmaxwell> rusty: right having "proof you know something" in your blocks is reasonable. If its in the innerloop you have a throuput proof that strongly encourages storing data. 20:30 < gmaxwell> rusty: sorry, well, it's not that its dumb, these things are subtle and varrious similar schemes are frequently proposed. :) 20:31 < rusty> gmaxwell: heh... I wasn't going to go that far! I'm trying to see how far I can push the "partial-knowledge miner" idea. 20:31 < op_null> gmaxwell: via twitter is hard. 80 bytes in 140 characters. 20:31 < gmaxwell> rusty: well so a notion there is you have an allowable notion of how partial they're allowed to be. and then let them specify what part their query should be restricted to. 20:32 < gmaxwell> op_null: you can fit about 2k in a tweet in fact, using unicode fun as the limits are characters, not bytes. 20:32 < rusty> gmaxwell: if everyone starts feeding you txs with UTXO proofs, UTXO commitments allows a block-header only miner. 20:33 < op_null> gmaxwell: oh. duh. usenet. 20:33 < gmaxwell> Bitcoin block headers are a nice and friendly 1bps on average, assuming you don't care about latency. Would be a fine fit for shortwave. :) 20:33 < op_null> maybe we need a bitcoin-headers mailing list. 20:33 < gmaxwell> Though just having the headers alone without a way to get their content is only of moderate value. 20:34 < gmaxwell> op_null: well I thought the obvious thing to do w/ twitter is see if there is an encoding from 80 bytes (really more like 40 if you do some compression) to plausable chinese text. :P 20:34 < gmaxwell> er to <140 characters of plausable chinese text. 20:35 < rusty> gmaxwell: well, having a receive-only system (eg. the bitsat project), I'd say it's 90% of the value. 20:35 < op_null> gmaxwell: yes, you're right you can git unicode characters in there just fine. that's the same sort of trick used in alt.binaries.*. 20:35 < gmaxwell> rusty: I'd agree with that. (actually bitsat can have enough bandwidth to send more than headers though...) 20:36 < gmaxwell> op_null: alt.binaries uses base64 20:36 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 272 seconds] 20:36 < rusty> gmaxwell: yes, but I argue a cubesat is too much. I'd aim for a minimal xmitter, and pay people $10k to add it to their cubesats. Since they have 6mo lifespans anyway... 20:37 < nsh> you can fit relatively arbitrary things into tweets via the url shortener and embedding deterministic-decodable images 20:37 < op_null> gmaxwell: huh, I thought yEnc was unicode? 20:37 < nsh> (yet to test whether you can construct double-linked reply lists by predicting the tweet number) 20:39 < op_null> gmaxwell: oh right. it's ASCII but it uses the whole character set. not unicode. 20:40 < op_null> and not base64, either. 20:40 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards 20:42 < op_null> nsh: probably hard to get data into a tweet image in any sort of reasonable density due to the JPEG compression 20:43 < nsh> jpeg can be gamed, i suspect 20:44 < gmaxwell> hm? if you control the jpeg you just set whatever data you want. 20:44 < gmaxwell> if it's getting compressed on your behalf, then ... yea you lose a lot of data rate that way. 20:45 < op_null> you don't though, they resize and recompress it. if you could do a PNG you'd get an almost 1-1 mapping of file size. when I messed about with this ages ago I actually got compression from binary > PNG due to it's efficient encoder. 20:46 < gmaxwell> yes, png has chunk adaptive preprocessing on top of zlib that can outperform zlib for quite a few things, not just the line art it was really optimized for. 20:47 < nsh> .title http://arstechnica.com/security/2014/05/how-to-stash-secret-messages-in-tweets-using-point-and-click-steganography/ 20:47 < yoleaux> How to stash secret messages in tweets using point-and-click steganography | Ars Technica 20:47 < nsh> (not particularly enlightening) 20:48 < nsh> .title https://medium.com/@willkirkby/twitter-and-audio-steganography-568c8eae5ead 20:48 < yoleaux> Twitter and Audio Steganography — Medium 20:48 < nsh> (better) 20:49 -!- MoALTz_ [~no@user-164-126-229-18.play-internet.pl] has joined #bitcoin-wizards 20:49 < phantomcircuit> gmaxwell, beacon servers should be relatively easy to implement also 20:49 < phantomcircuit> could be something as simple as spamming you with all the headers on connect 20:51 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards 20:51 < nsh> (more generally: http://www.cs.ox.ac.uk/andrew.ker/docs/ADK60B.pdf -- Linguistic Steganography on Twitter: Hierarchical Language Modelling with Manual Interaction) 20:51 -!- adam3us [~Adium@207.134.53.206] has joined #bitcoin-wizards 20:51 < gmaxwell> phantomcircuit: for scalablity it would ideally be connectionless, but .. bleh, nat traversal. 20:52 < nsh> it's 2014, everyone has had ipv6 addresses for years 20:52 < nsh> oh no, that's that timeline i keep not waking up in 20:52 -!- MoALTz [~no@user-164-126-229-18.play-internet.pl] has quit [Ping timeout: 265 seconds] 20:53 < nsh> (it would just be differently awful) 20:54 < phantomcircuit> gmaxwell, easy enough to set that up with udp and get reasonably effective nat transferval 20:55 < phantomcircuit> traversal 20:55 < gmaxwell> ( https://twitter.com/blockheaders ) 20:56 < gmaxwell> phantomcircuit: yea, sure it doesn't take much code when you're sure the server is never behind nat, but it will also fail to work in many places. 20:56 < gmaxwell> Might have moderately higher success if it is run over port 53. 21:05 < adam3us> petertodd: "so, AFAICT your symkey arrangement basically makes it a semi-parallelizable problem?" the stages are fully serialized. each solution needs brute forcing one by one, and cant start on stage2 until completed stage1. but the work within the stages is parallelizable yes. not clear how to do that without repeating work without having pub key construct as with the rivest time-lock 21:09 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Ping timeout: 264 seconds] 21:28 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 21:57 -!- maaku__ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Ping timeout: 240 seconds] 22:00 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards 22:00 -!- maaku is now known as Guest17879 22:02 -!- roconnor [~roconnor@e120-pool-d89a79cf.brdbnd.voicenetwork.ca] has quit [Remote host closed the connection] 22:13 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards 22:16 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 244 seconds] 22:16 -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has joined #bitcoin-wizards 22:21 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 22:33 < rusty> gmaxwell: you mentioned compressing bitcoin headers to 40 bytes. I can see how to shed ~12 bytes of block SHA, and intuit version and target (8 bytes), compress or rebuild timestamp, but I can't get below 56 bytes... 22:35 < phantomcircuit> rusty, you can remove the nonce entirely 22:36 < phantomcircuit> indeed you can remove/guess nearly everything 22:36 < phantomcircuit> version. previous block hash, bits, and nonce 22:37 < phantomcircuit> and the timestamp should be easy enough to guess 22:37 < phantomcircuit> leaving you with basically just the merkle tree root 22:37 < phantomcircuit> and maybe a height value to help with guessing the previous block hash 22:38 < phantomcircuit> so 32 bytes + block height 22:40 < op_null> might end up finding a different block :P 22:42 < op_null> it's so much easier just to squirt out the 80 bytes somehow 22:43 < phantomcircuit> op_null, that's pretty unlikely 22:43 < phantomcircuit> nearly all of the entropy is in the merkle tree root now 22:43 < op_null> I know, but it's a fun thought 22:45 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards 22:52 < op_null> encrypt things with a bitcoin address! - haven't people tried this before with unfortunate results? 22:53 -!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards 22:53 < rusty> phantomcircuit: you mean do 4bn probes to figure out the nonce? 22:54 < op_null> that's not that long even on a normal CPU 22:55 < phantomcircuit> rusty, sure why not? 22:55 < op_null> rusty: on average it's going to be 2.1B attempts, too. 22:55 < phantomcircuit> hell throw in 1 byte to make it <1s 22:56 < rusty> op_null: hmm, I don't know, seems like ~1000 seconds @4MH/sec. I guess you can send 1 byte.... 22:57 < op_null> rusty: 4MH/s seems a little on the low size, and Intels next CPUs will have SHA256 instructions 22:57 < op_null> s/size/side 22:59 < rusty> op_null: fair enough... 22:59 -!- rusty is now known as rusty_afk 23:01 < kanzure> https://github.com/papers-we-love/papers-we-love/tree/master/gossip 23:01 < kanzure> and https://github.com/papers-we-love/papers-we-love/tree/master/distributed_systems 23:12 < gmaxwell> so an encoding for batches of headers: first a minimum time, 4 bytes, then first block height varint 4+ bytes, then a tx version, 4 bytes, then 4 bytes bits, then prevhash 28-24 bytes depending on bits (or 32 if height is congruent to one mod 2016), then mroot, 32 bytes, then timestamp relative to minimum time 2 bytes (if 0xFFFF then code 4 more bytes), then nonce, 4 bytes= 78 bytes. Next (and all following) header is 1 byte ... 23:12 < gmaxwell> ... version (if version is 255 read 5 more bytes, one to select a table entry to overwrite, table initlizalzed as 0..254), if heights%2016, 4 bytes bits, 32 bytes mr, 2 bytes timestamp, 4 bytes nonce = 39.002 bytes 23:13 < gmaxwell> and yea, sure you can save more ditching the nonce, though you still need to code if the first found in the search is correct... but really, I don't think its worth the bother. 23:13 < gmaxwell> since it's only another 10% at most. 23:15 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards 23:18 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection] 23:18 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards 23:23 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 264 seconds] 23:25 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 23:26 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 23:29 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 23:30 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 23:32 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Client Quit]