2014-11-29.log

--- Day changed Sat Nov 29 2014
-!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds]00:14
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards00:27
-!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards00:32
-!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]00:32
-!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards00:32
-!- Dr-G3 is now known as FBI-AGENT00:34
-!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 244 seconds]01:00
-!- wallet42 [~wallet42@e179185070.adsl.alicedsl.de] has quit [Quit: Leaving.]01:03
-!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards01:05
* andy-logbot is logging01:05
-!- webdeli [~projects@bit1642888.lnk.telstra.net] has quit [Remote host closed the connection]01:06
-!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has quit [Ping timeout: 255 seconds]01:20
-!- hollandais [~irenacob@li629-190.members.linode.com] has quit [Remote host closed the connection]01:33
-!- c0rw|sle_ is now known as c0rw|away01:33
-!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards01:35
-!- hollandais [~irenacob@li629-190.members.linode.com] has joined #bitcoin-wizards01:43
-!- bit2017 [~linker@1.54.25.127] has joined #bitcoin-wizards01:53
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards01:55
-!- coiner [~linker@1.54.25.127] has quit [Ping timeout: 255 seconds]01:55
-!- berndj-blackout is now known as berndj02:03
-!- nuke1989 [~nuke@46-136-96.adsl.cyta.gr] has quit [Read error: Connection reset by peer]02:11
-!- nuke1989 [~nuke@46-136-96.adsl.cyta.gr] has joined #bitcoin-wizards02:12
-!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards02:23
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]02:28
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 250 seconds]02:37
-!- oakpacific [~oakpacifi@2.127.106.88] has joined #bitcoin-wizards02:39
-!- c0rw|away [~c0rw1n@181.66-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds]02:49
-!- c0rw|away [~c0rw1n@91.176.95.227] has joined #bitcoin-wizards02:53
-!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]02:56
-!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards02:56
-!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]02:56
-!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards02:56
-!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]02:57
-!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards02:57
-!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards03:09
-!- adam3us [~Adium@207.134.53.206] has joined #bitcoin-wizards03:13
-!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards03:41
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Remote host closed the connection]03:43
-!- koshii [~0@50.151.108.101] has quit [Quit: leaving]03:55
-!- koshii [~0@50.151.108.101] has joined #bitcoin-wizards04:05
-!- Nightwolf [~Nightwolf@unaffiliated/nightwolf] has quit [Ping timeout: 255 seconds]04:12
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards04:14
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Read error: Connection reset by peer]04:15
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards04:16
-!- belcher [~belcher-s@5ec18bcf.skybroadband.com] has joined #bitcoin-wizards04:20
-!- belcher [~belcher-s@5ec18bcf.skybroadband.com] has quit [Changing host]04:20
-!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards04:20
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds]04:20
-!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection]04:28
-!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards04:29
-!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]04:56
-!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]04:59
-!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards04:59
-!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]05:04
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards05:16
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds]05:20
-!- mortale [~mortale@gateway/tor-sasl/mortale] has quit [Ping timeout: 250 seconds]05:22
-!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards05:37
-!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]05:38
-!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards05:39
-!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]05:41
-!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 265 seconds]05:43
-!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards05:50
-!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has quit [Ping timeout: 255 seconds]06:08
-!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving]06:09
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards06:14
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds]06:19
-!- Quanttek [~quassel@2a02:8108:d00:870:9de8:5fb:e332:653b] has joined #bitcoin-wizards06:20
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards06:20
-!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has joined #bitcoin-wizards06:25
-!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards06:29
-!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards06:31
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 256 seconds]06:38
-!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards06:40
-!- 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-wizards06:47
adam3usso 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%20files06:49
adam3usand 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
adam3usthe idea being setup is parallel but decrypt is serial06:51
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards06:52
adam3usnow 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
kanzuresounds right06:52
kanzureoh, which nodes are you expecting to farm out to?06:52
adam3usit 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:53
adam3usanyway 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:56
adam3usnow 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 setup06:58
op_nullkanzure: 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:58
kanzuremy question was actually about the upfront setup collusion actually06:59
kanzurebut anyway, key truncation.. hm.06:59
adam3usop_null: yeah but my point is you can generate KDFs with arbitrary iterations/work and your choice variance with negligible work06:59
adam3usthis 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:00
op_nullright, 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:01
op_nullI'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
adam3usop_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:02
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_nulloh yeah, of course then you're toast. alternatives are great.07:03
-!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has joined #bitcoin-wizards07:05
adam3usthere 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-phone07:06
adam3usthere is a non-parallelizable version of that (had to do extra things to make it parallelizable)07:06
adam3ushttps://bitcointalk.org/index.php?topic=311000.007:07
adam3us(thats a different use-case really.  cost-locked vs time-locked)07:08
adam3usif 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:08
adam3usan 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:12
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards07:14
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds]07:19
-!- mkarrer_ is now known as mkarrer07:19
-!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards07:19
-!- yottabit [uid36770@gateway/web/irccloud.com/x-nfsbhhqgttnqdhrt] has joined #bitcoin-wizards07:28
-!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 272 seconds]07:45
-!- rdponticelli [~quassel@gateway/tor-sasl/rdponticelli] has joined #bitcoin-wizards07:47
-!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards07:51
-!- adam3us [~Adium@207.134.53.206] has quit [Quit: Leaving.]07:54
-!- op_null [~op_null@178.62.133.216] has quit [Quit: Lost terminal]07:59
-!- antanst [~antonis@adsl-54.176.58.234.tellas.gr] has joined #bitcoin-wizards08:06
-!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has quit [Remote host closed the connection]08:08
-!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds]08:10
-!- Nightwolf [~Nightwolf@unaffiliated/nightwolf] has joined #bitcoin-wizards08:11
-!- spinza [~spin@197.89.24.35] has quit [Ping timeout: 250 seconds]08:12
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards08:14
-!- 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-wizards08:16
-!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards08:17
-!- rdponticelli [~quassel@gateway/tor-sasl/rdponticelli] has quit [Ping timeout: 250 seconds]08:17
-!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Remote host closed the connection]08:19
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds]08:20
-!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards08:23
-!- 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-wizards08:24
-!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards08:26
-!- 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-wizards08:31
-!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has quit [Quit: Leaving.]08:37
-!- Starduster [~Guest3@unaffiliated/starduster] has quit [Read error: Connection reset by peer]08:44
-!- Starduster [~Guest3@unaffiliated/starduster] has joined #bitcoin-wizards08:44
-!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has joined #bitcoin-wizards08:45
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards08:51
-!- lclc_bnc is now known as lclc08:58
-!- roconnor [~roconnor@e120-pool-d89a79cf.brdbnd.voicenetwork.ca] has joined #bitcoin-wizards09:03
-!- 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-wizards09:05
-!- bit2017 [~linker@1.54.25.127] has quit [Ping timeout: 264 seconds]09:10
-!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]09:14
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards09:14
-!- NewLiberty [~NewLibert@99-48-178-219.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards09:15
-!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards09:16
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds]09:19
-!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection]09:22
-!- lclc is now known as lclc_bnc09:25
-!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has joined #bitcoin-wizards09:27
-!- waxwing [waxwing@gateway/vpn/mullvad/x-knrbngcfmhxbeaor] has quit [Read error: Connection reset by peer]09:29
-!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-wizards09:31
-!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 256 seconds]09:37
-!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has quit [Quit: Leaving.]09:41
-!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards09:42
-!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has joined #bitcoin-wizards09:45
-!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds]09:46
-!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has quit [Client Quit]09:48
-!- waxwing [waxwing@gateway/vpn/mullvad/x-hrclowovttsoucbd] has joined #bitcoin-wizards09:49
-!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]09:53
-!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards09:53
-!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards09:56
-!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has joined #bitcoin-wizards09:58
-!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has quit [Ping timeout: 250 seconds]10:03
-!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has joined #bitcoin-wizards10:06
-!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer]10:08
-!- adam3us [~Adium@207.134.53.206] has joined #bitcoin-wizards10:09
-!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards10:09
-!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards10:12
-!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection]10:12
-!- 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-wizards10:14
-!- 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-wizards10:19
-!- spinza [~spin@197.89.10.145] has quit [Excess Flood]10:19
-!- spinza [~spin@197.89.10.145] has joined #bitcoin-wizards10:19
-!- spinza [~spin@197.89.10.145] has quit [Excess Flood]10:19
-!- spinza [~spin@197.89.10.145] has joined #bitcoin-wizards10:20
-!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards10:24
-!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]10:24
-!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards10:24
-!- samson_ [~samson_@183.89.22.186] has joined #bitcoin-wizards10:26
-!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 264 seconds]10:33
-!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards10:37
-!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection]10:37
-!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 255 seconds]10:43
-!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards10:44
-!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has quit [Ping timeout: 258 seconds]10:46
-!- Meeh [~meeeeeeh@meeh.sigterm.no] has quit [Quit: No Ping reply in 180 seconds.]10:47
-!- Meeh [~meeeeeeh@meeh.sigterm.no] has joined #bitcoin-wizards10:48
-!- spinza_ [~spin@197.89.24.188] has joined #bitcoin-wizards10:49
-!- spinza [~spin@197.89.10.145] has quit [Ping timeout: 255 seconds]10:50
-!- lclc_bnc is now known as lclc10:51
-!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]10:56
-!- lclc is now known as lclc_bnc11:02
-!- soundx_ [~soundx@37.157.195.143] has joined #bitcoin-wizards11:04
kanzurehttp://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:08
-!- askmike [~askmike@92.69.252.98] has joined #bitcoin-wizards11:25
gwillenkanzure: I propose taking the current openssl source and submitting it, alleging that you have made it subtly vulnerable11:28
gwillenand see what they find11:28
nshhah11:29
kanzurethey accept existing code only if you have modified it11:29
kanzurewhich is pretty easy to check (diffs)11:29
kanzureand i think they have you submit and make your changes obvious11:30
gwillenheh, darn11:30
-!- xuxu [~xuxu@unaffiliated/xuxu] has joined #bitcoin-wizards11:37
-!- xuxu [~xuxu@unaffiliated/xuxu] has quit [Client Quit]11:37
-!- soundx_ [~soundx@37.157.195.143] has quit [K-Lined]11:38
-!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards11:47
-!- 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:49
-!- NewLiberty [~NewLibert@99-48-178-219.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 264 seconds]11:52
-!- spinza [~spin@197.89.24.98] has joined #bitcoin-wizards12:02
-!- spinza [~spin@197.89.24.98] has quit [Excess Flood]12:02
-!- spinza_ [~spin@197.89.24.188] has quit [Ping timeout: 256 seconds]12:04
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards12:09
-!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards12:09
-!- FBI-AGENT is now known as Dr-G12:09
-!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]12:10
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards12:14
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds]12:19
adam3ussubmit ekr's patches? ;) ooh politically insensitive12:31
-!- c0rw|away is now known as c0rw1n12:32
adam3useg the one that broadcasts extra randomness to amplify the ec drbg breakage12:33
-!- adam3us [~Adium@207.134.53.206] has left #bitcoin-wizards []12:33
-!- adam3us [~Adium@207.134.53.206] has joined #bitcoin-wizards12:33
sipa?12:36
sipaah12:36
-!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards12:57
-!- 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:04
-!- MoALTz [~no@user-164-126-229-18.play-internet.pl] has joined #bitcoin-wizards13:07
-!- AnoAnon [~AnoAnon@197.37.73.249] has joined #bitcoin-wizards13:08
-!- AnoAnon [~AnoAnon@197.37.73.249] has quit [Read error: Connection reset by peer]13:08
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards13:14
-!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards13:16
-!- spinza [~spin@197.89.23.217] has quit [Excess Flood]13:16
-!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards13:16
-!- spinza [~spin@197.89.23.217] has quit [Excess Flood]13:16
-!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards13:17
-!- spinza [~spin@197.89.23.217] has quit [Excess Flood]13:17
-!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards13:17
-!- spinza [~spin@197.89.23.217] has quit [Excess Flood]13:17
-!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards13:18
-!- spinza [~spin@197.89.23.217] has quit [Excess Flood]13:18
-!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards13:19
-!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds]13:19
-!- yottabit [uid36770@gateway/web/irccloud.com/x-nfsbhhqgttnqdhrt] has quit [Quit: Connection closed for inactivity]13:21
-!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!]13:35
-!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards13:36
-!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards13:39
-!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Client Quit]13:42
-!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has quit [Remote host closed the connection]13:49
-!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]14:06
-!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards14:07
-!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]14:07
-!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards14:07
-!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has joined #bitcoin-wizards14:08
-!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 256 seconds]14:12
-!- grandmaster2 [dansmith3@knows.the.cops.are.investigat.in] has quit [Quit: quit]14:23
-!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has joined #bitcoin-wizards14:24
-!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection]14:24
-!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards14:25
tacotimesomeone wrote a paper about using a paillier cryptosystem to enhance blockchain privacy in conjunction with utxo-bearing spvs14:35
tacotimehttps://drive.google.com/file/d/0B21vncLoIlIyaVpGVFN5c1VFdmM/view14:35
-!- Aquent1 [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards14:41
-!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection]14:41
kanzurewasn't there something recent about xss vulnerabilities in google drive.. hrm.14:41
-!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards14:41
tacotimekanzure: if you are afraid i will dl the pdf and email it to you14:42
tacotimenot that pdfs are much safer14:42
kanzurei feel like my options are one terrible javascript execution environment for another terrible javascript execution environment14:47
tacotimeand good discussion from gmaxwell/adam3us here: https://bitcointalk.org/index.php?topic=872377.014:48
adam3ussee https://bitcointalk.org/index.php?topic=872377.msg9647318#msg9647318 they seem to be confused about the need for14:48
-!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has joined #bitcoin-wizards14:48
adam3ustacotime: 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:49
tacotimeyeah 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:51
adam3usthe homomorphic value is not doing anything exciting.. all standard zkp & EC dlog.  1kbit for encrypted value vs 64-bit for unencrypted.14:52
-!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 245 seconds]14:54
gmaxwelloh I was just typing what adam3us already typed.14:57
adam3usuh 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.014:57
gmaxwellIt needs proofs to prevent the wrap and I don't know how to construct those compactly (while staying with just boring cryptographic assumptions)14:58
adam3usskip to 49m on the video for the encrypted value part https://www.youtube.com/watch?v=3dAdI3Gzodo&feature=youtu.be14:59
tacotimecool, ty.14:59
adam3usi 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:02
nshgmaxwell, what's the security effect of wrapping around n?15:03
nshor cryptopathogenesis15:03
gmaxwellnsh: it's a total break. It only shows your outputs are congruent to your inputs mod n.15:05
nshhmm15:06
kanzureandy-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 exist15:06
gmaxwellso e.g. you can create enormous value outputs when you only have a few coins.15:06
andy-logbotI'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 help15:06
kanzureoops15:06
kanzureandytoshi: 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 exist15:06
gmaxwellkanzure: there are proofs for this, seem adam3us' writeup, but they are not tiny.15:06
nshoh god, the logbots are starting giving academic interjections now. skynet dawns15:07
kanzurehmm okay then15:07
nsh*have started15:07
gmaxwellreally, 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
adam3uskanzure: 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 wrap15:09
nshstill hard to intuit why proving nonwrap would require extra stronger assumptions15:15
* nsh reads more15:17
nsh(or is that just within efficiency tolerances)15:18
adam3usgmaxwell: yes i am disappointed about the size.  annoying range proofs.15:21
adam3usgmaxwell: 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:22
-!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has joined #bitcoin-wizards15:23
petertoddadam3us: 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
petertoddadam3us: (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:28
andytoshioff 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
petertoddadam3us: secondly the "farm it out" part of the problem is pretty trivial - think of how little parallelism you need to make it practical15:29
andytoshikanzure: the proofs that adam3us is talking about are in the RO model15:29
adam3uspetertodd: yeah but then you need to trust the people you farmed it out to to forget15:29
petertoddadam3us: 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 implementation15:29
adam3uspetertodd: i do agree that its preferable to use sym key, thats why i rejected pubkey variants, for hashcash15:30
adam3uspetertodd: anyway my symkey argument stands: you can do that without oursourcing.  just delete keybits.15:31
nshandytoshi, "ethereal.. fed into itself"?15:32
nshare there any actually analytically-enlightening papers on how systems break down under various departures from random oracle?15:33
adam3uspetertodd: 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
rusty2petertodd: 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:34
-!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has joined #bitcoin-wizards15:35
petertoddrusty2: my timelock scheme incentivises everyone to crack it because cracking it gets you bitcoins15:35
gmaxwellandytoshi: I am moving my eyebrows at your dismissal of RO assumptions.15:35
-!- rusty2 is now known as rusty15: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
petertoddrusty2: solves that problem, *and* gives solid proof of what's the fastest scalar implementation out there (by people willing to use it publicly)15:35
andytoshigmaxwell: specifically for SNARKs, things like KDM-secure encryption, obfuscation15:36
andytoshigmaxwell: anything that treats code as executable code (as opposed to blindly treating its input as data)15:36
petertoddrusty: tech is such that that scalar implementation is very likely close to the best possible (<10x)15:36
andytoshinsh: one sec, i have an example of a broken RO-secure system for KDM-secure encryption..15:37
gmaxwellandytoshi: the only RO assunption _required_ for a SNARK is a fiat shamir transform to make the protocol non-interactive.15:37
adam3uspetertodd: dont forget people may have an interest to crack lots of time-lock in parallel if they got used much at vastly lower J/crack15:37
andytoshigmaxwell: oh, FS i think is ok15:37
-!- adam3us [~Adium@207.134.53.206] has quit [Quit: Leaving.]15:37
andytoshibut i don't really trust that feeling because i can't tell why exactly i'm ok with fs15:37
nsh+1 economy of scale cracking15:38
rustypetertodd: 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
andytoshinsh: bottom of page 19 https://eprint.iacr.org/2007/315.pdf15:38
nshty15:39
andytoshioh, i'm OK with FS because it treats its input as raw data15:39
andytoshito contrast, the example i just gave to nsh  (which is pretty jargonny, sorry) is using the RO in a pretty integral way15:39
nshi still suspect there might be something interest, analogous to andytoshi's impossibility conjecture, if the self-referential part were clearer15:40
andytoshiKDM 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 ciphertexts15:40
petertoddrusty: you spend 1core * T computer power and make it yourself; scales linearly15:41
andytoshiand obviously, in a real system this assumption is false because your RO is instantiated with an actual function you can give to the ciphertext oracle15:41
petertoddrusty: it's meant to actually work, right now, because I had a client who actually needed it...15:41
nshbut 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 outputs15:41
nsh*unmangle()15:42
andytoshinsh: 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 interaction15:42
andytoshinsh: but maybe there is a better definition of ZK that'd give us what we want without such a requirement15:42
petertoddadam3us: 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't15:42
rustypetertodd: 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:42
nshi think we're grasping at a informational theoretical conservation law but it's a bit beyond my conceptual horizons at least15:43
petertoddrusty: the motiviation is there exist Bitcoins on the bitcoin blockchain that by cracking the timelock you get to take the bitcoins...15:43
andytoshinsh: i hope not :)15:43
andytoshibut maybe, i get that feeling too15:43
petertoddrusty: no such "ulrelated parties" systems exist without adding huge amounts of complexity and/or handwaving15:43
nshjust doesn't sit so well, aesthetically, that the assumptions can't be made less discrete/binary15:43
rustypetertodd: Thanks, I thought that might be the case :(   Unfortunately that constrains usage significantly, since the locker has to pay the solving cost.15:44
petertoddadam3us: so, AFAICT your symkey arrangement basically makes it a semi-parallelizable problem?15:45
andytoshinsh: 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/50715:45
nshvery theological :)15:45
andytoshi:P15:45
petertoddrusty: 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:45
andytoshinsh: using obfuscation they have a selectively secure candidate ... one discouraging theoretical result they have is that adaptive security is impossible even in the RO model15:46
andytoshiwhich is much stronger than my impossibility result...plus they actually finished it instead of handwaving the way i did :P15:46
nsh((iacr.org should apply some sort of latex.js for abstracts))15:46
nshhmm15:47
andytoshiso 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
andytoshii dunno, i will spend some time thinking about it over the next months15:47
nshpetertodd, you should be able to solve 5 impossible things for pre-delivery client invoicing before breakfast15:47
nshyou're not thinking MBA-dimensionally, Marty!15:47
nshandytoshi, a fine question to ponder15:48
rustypetertodd: It's nice work, for sure.15:48
andytoshinsh: right, right. I have a real problem with that.15:48
andytoshi(re "not thinking MBA-dimensionally")15:49
petertoddrusty: thanks!15:49
andytoshii had to look up marty's response :P15:49
nshwell, a lot of people have the opposite problem15:49
kanzureconsequences of that could be disastrous and destroy the entire universe15:49
nshi don't mind disaster OR eschaton. it's both at once that really messes up your weekend15:50
kanzure(context: <https://www.youtube.com/watch?v=KJRh-37H4fA>) (not worth your time)15:50
petertoddadam3us: 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 crackers15:51
kanzureandytoshi: 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
kanzureor, in particular, the forged or faulty transcripts are the thing i'm trying to place15:52
andytoshikanzure: in the CRS model, the party generating the common reference string has access to secret data which allows them to create "proofs" of false statements15:53
nshpetertodd, 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
andytoshikanzure: in the RO model, my problem was that certain ways of using ROs block attacks by sleight-of-hand assuming they cannot happen15:54
andytoshikanzure: 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:54
-!- 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
petertoddnsh: 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 succeed15:55
nshhm15:55
petertoddnsh: 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:56
kanzurejokes on you i'm holding out until the LN market falls through15:57
petertoddnsh: (or in adam's example, 2^56 dewars)15:57
nshjust think of the scrap metal value of those cannisters though; practically pays for itself15:57
andytoshimetallurgy to #bitcoin-alchemists pls15:58
petertoddnsh: 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 predictability15:58
* nsh smiles, nods15:58
petertoddnsh: 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 away16:00
petertoddnsh: scalar speed is basically just a function of how compact the circuits are and fundemental clockspeed16:01
nshright16:01
-!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has quit [Remote host closed the connection]16:01
nshcomes down to noise floor distinguishability16:02
nshbut as Feynman said, there's plenty of room at the bottom16:02
petertoddnsh: that and literally the speed of light, well, electrical wave propagation16:02
petertoddnsh: for scalar speed, no there isn't... we're already building circuits with features that countable integer number of atoms wide16:03
nshor the speed at which we think information moves while it doesn't because we're apes16:03
* nsh nods16:04
nshwell, there's a whole lot of mathematics going into the color dynamics of each minuscule bit of each minuscule bit of those atoms16:05
petertoddmeh, I wouldn'16:05
nshwhether we can overload that dynamics to perform useful calculations and derive classical results is probably an open question below atomic levels16:05
petertoddI wouldn't trust timelock to keep a secret safe for more than ~5yr anyway16:06
* nsh nods16:06
petertoddyou're talking physics voodo - 20 years? maybe? probably not16:06
nshaye16:06
-!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has joined #bitcoin-wizards16:21
-!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has quit [Remote host closed the connection]16:24
kanzureis 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
kanzurei think i am butchering it16:25
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]16:29
gmaxwellkanzure: you have a circuit (the program). There is an wire labeling. The procedure shows that I know a consistent wire labeling.16:31
kanzuresecond try.. "the output of the program is deterministically encrypted based on the program/circuit"?16:31
gmaxwell(with computational soundness, of course, both from the strength of the comittments and from the F/S sampling)16:32
gmaxwellkanzure: 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:33
-!- Quanttek [~quassel@2a02:8108:d00:870:9de8:5fb:e332:653b] has quit [Ping timeout: 258 seconds]16:45
kanzurea 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
kanzureand then they would check the encrypted output against the commitments (and this is what you call the "encrypted domain")?16:46
gmaxwellyes, note that the encryption keys are comitted too, and their value probablistic verified.16:47
-!- null_radix [Elite7851@gateway/shell/elitebnc/x-flsbdntiidiqdnwo] has joined #bitcoin-wizards16:57
-!- c0rw1n is now known as c0rw|sleep17:01
kanzurewhat can be done without revealing the output?17:03
gmaxwellthe output is whatever you want it to be; I mean, it can reveal a single bit if you like.17:03
kanzureuh, is it safe to encrypt a single bit in a public key system?17:06
kanzureoh i'm thinking of signing17:07
gmaxwellthere is no public key anything in this.17:09
gmaxwellit's all one-time-pad encryption and hashing.17:09
-!- Aquent1 [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection]17:16
lechuga_in case any1 has a use for the contracthashtool in ruby: https://github.com/aalness/contracthashtool-ruby17:23
kanzurewhat 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 consistent17:35
-!- op_null [~op_null@178.62.133.216] has joined #bitcoin-wizards17:45
-!- NewLiberty [~NewLibert@2602:304:cff8:1580:ccd8:4d7d:19ab:f9c3] has joined #bitcoin-wizards17:47
-!- NewLiberty [~NewLibert@2602:304:cff8:1580:ccd8:4d7d:19ab:f9c3] has quit [Ping timeout: 258 seconds]17:53
-!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has quit []17:56
-!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has joined #bitcoin-wizards17:59
-!- 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-wizards18:11
-!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards18:12
-!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards18:13
-!- altoz [~altoz@cpe-24-55-38-141.austin.res.rr.com] has joined #bitcoin-wizards18:30
-!- altoz [~altoz@cpe-24-55-38-141.austin.res.rr.com] has quit [Remote host closed the connection]18:36
-!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection]18:39
-!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards18:41
-!- Dr-G [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds]18:44
-!- tacotime [~mashkeys@198.52.200.63] has quit [Ping timeout: 264 seconds]18:57
-!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards19:02
-!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards19:02
-!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has joined #bitcoin-wizards19:05
-!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards19:10
-!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]19:14
-!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]19:19
-!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards19:57
rustygmaxwell: 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:00
rustygmaxwell: 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
rustygmaxwell: unless each query asks for about num-txs/2 codes.20:01
rustygmaxwell: or am I barking up the wrong tree?  Again :)20:01
lechuga_fountain code20:02
lechuga_for wat20:02
gmaxwellrusty: 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:03
rustygmaxwell: 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
gmaxwellrusty: 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:04
gmaxwelllechuga_: 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_interesting20:06
nshnice20:07
rustygmaxwell: 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:07
gmaxwellthere 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:08
rustygmaxwell: I'll play with that, see what I can come up with.  Good to know it sounds sane...20:09
lechuga_gmaxwell: is it in your alt-ideas repo?20:10
rustygmaxwell: 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:10
gmaxwelllechuga_: 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:12
lechuga_https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding20:13
lechuga_found it thx20:13
gmaxwellThats related, not quite the same thing.20:13
lechuga_ic20:14
gmaxwelllechuga_: 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:14
gmaxwellThe 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:15
lechuga_whats the motivation to only verify random parts, scaling?20:16
rustylechuga_: yes, and robustness.  AFAICT it's the only missing part of https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs20:17
gmaxwelllechuga_: 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 ok20:18
gmaxwellAnd 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 validation20:19
lechuga_swarm*20:19
phantomcircuitexcept there's only maybe 6k nodes that are public20:19
phantomcircuitso maybe not 1000x improvement :P20:19
gmaxwellphantomcircuit: 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
gmaxwellthey just have to not be partitioned.20:20
phantomcircuithmm that's true20:20
gmaxwellcertantly such a system would have more to lose from sybil attacks.20:20
gmaxwellBut there are other tools we can deploy to reduce sybil attack risks.20:21
phantomcircuitmicro pow schemes?20:22
rustygmaxwell: 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
gmaxwellrusty: I actually think that incentivized sybil attacks instead. :(20:23
* rusty thinks harder....20:23
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:24
gmaxwellI don't think it's that much of an issue, assuming the cost is made low enough.20:25
gmaxwellbut then again, I've thought lots of wrong things before.20:25
nshdozens even :)20:26
gmaxwellphantomcircuit: 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:26
rustygmaxwell: 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_nullgmaxwell: 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
gmaxwellphantomcircuit: 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
nshmm, 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
rustygmaxwell: ha, I was thinking of serving block headers via SMS.20:28
gmaxwellrusty: petertodd was relaying them via twitter; until twitter blocked it. :(20:29
gmaxwellrusty: oh! I thought you were saying that miners would pay to random nodes in their coinbases.20:29
rustygmaxwell: no, I'm not quite that dumb!20:29
gmaxwellrusty: 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
gmaxwellrusty: sorry, well, it's not that its dumb, these things are subtle and varrious similar schemes are frequently proposed. :)20:30
rustygmaxwell: 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_nullgmaxwell: via twitter is hard. 80 bytes in 140 characters.20:31
gmaxwellrusty: 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:31
gmaxwellop_null: you can fit about 2k in a tweet in fact, using unicode fun as the limits are characters, not bytes.20:32
rustygmaxwell: if everyone starts feeding you txs with UTXO proofs, UTXO commitments allows a block-header only miner.20:32
op_nullgmaxwell: oh. duh. usenet.20:33
gmaxwellBitcoin 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_nullmaybe we need a bitcoin-headers mailing list.20:33
gmaxwellThough just having the headers alone without a way to get their content is only of moderate value.20:33
gmaxwellop_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. :P20:34
gmaxweller to <140 characters of plausable chinese text.20:34
rustygmaxwell: well, having a receive-only system (eg. the bitsat project), I'd say it's 90% of the value.20:35
op_nullgmaxwell: 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
gmaxwellrusty: I'd agree with that. (actually bitsat can have enough bandwidth to send more than headers though...)20:35
gmaxwellop_null: alt.binaries uses base6420:36
-!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 272 seconds]20:36
rustygmaxwell: 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:36
nshyou can fit relatively arbitrary things into tweets via the url shortener and embedding deterministic-decodable images20:37
op_nullgmaxwell: 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:37
op_nullgmaxwell: oh right. it's ASCII but it uses the whole character set. not unicode.20:39
op_nulland not base64, either.20:40
-!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards20:40
op_nullnsh: probably hard to get data into a tweet image in any sort of reasonable density due to the JPEG compression20:42
nshjpeg can be gamed, i suspect20:43
gmaxwellhm? if you control the jpeg you just set whatever data you want.20:44
gmaxwellif it's getting compressed on your behalf, then ... yea you lose a lot of data rate that way.20:44
op_nullyou 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:45
gmaxwellyes, 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:46
nsh.title http://arstechnica.com/security/2014/05/how-to-stash-secret-messages-in-tweets-using-point-and-click-steganography/20:47
yoleauxHow to stash secret messages in tweets using point-and-click steganography | Ars Technica20:47
nsh(not particularly enlightening)20:47
nsh.title https://medium.com/@willkirkby/twitter-and-audio-steganography-568c8eae5ead20:48
yoleauxTwitter and Audio Steganography — Medium20:48
nsh(better)20:48
-!- MoALTz_ [~no@user-164-126-229-18.play-internet.pl] has joined #bitcoin-wizards20:49
phantomcircuitgmaxwell, beacon servers should be relatively easy to implement also20:49
phantomcircuitcould be something as simple as spamming you with all the headers on connect20:49
-!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards20: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-wizards20:51
gmaxwellphantomcircuit: for scalablity it would ideally be connectionless, but .. bleh, nat traversal.20:51
nshit's 2014, everyone has had ipv6 addresses for years20:52
nshoh no, that's that timeline i keep not waking up in20:52
-!- MoALTz [~no@user-164-126-229-18.play-internet.pl] has quit [Ping timeout: 265 seconds]20:52
nsh(it would just be differently awful)20:53
phantomcircuitgmaxwell, easy enough to set that up with udp and get reasonably effective nat transferval20:54
phantomcircuittraversal20:55
gmaxwell( https://twitter.com/blockheaders )20:55
gmaxwellphantomcircuit: 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
gmaxwellMight have moderately higher success if it is run over port 53.20:56
adam3uspetertodd: "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-lock21:05
-!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Ping timeout: 264 seconds]21:09
-!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]21:28
-!- maaku__ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Ping timeout: 240 seconds]21:57
-!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards22:00
-!- maaku is now known as Guest1787922:00
-!- roconnor [~roconnor@e120-pool-d89a79cf.brdbnd.voicenetwork.ca] has quit [Remote host closed the connection]22:02
-!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards22:13
-!- 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-wizards22:16
-!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards22:21
rustygmaxwell: 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:33
phantomcircuitrusty, you can remove the nonce entirely22:35
phantomcircuitindeed you can remove/guess nearly everything22:36
phantomcircuitversion. previous block hash, bits, and nonce22:36
phantomcircuitand the timestamp should be easy enough to guess22:37
phantomcircuitleaving you with basically just the merkle tree root22:37
phantomcircuitand maybe a height value to help with guessing the previous block hash22:37
phantomcircuitso 32 bytes + block height22:38
op_nullmight end up finding a different block :P22:40
op_nullit's so much easier just to squirt out the 80 bytes somehow22:42
phantomcircuitop_null, that's pretty unlikely22:43
phantomcircuitnearly all of the entropy is in the merkle tree root now22:43
op_nullI know, but it's a fun thought22:43
-!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards22:45
op_nullencrypt things with a bitcoin address! - haven't people tried this before with unfortunate results?22:52
-!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards22:53
rustyphantomcircuit: you mean do 4bn probes to figure out the nonce?22:53
op_nullthat's not that long even on a normal CPU22:54
phantomcircuitrusty, sure why not?22:55
op_nullrusty: on average it's going to be 2.1B attempts, too.22:55
phantomcircuithell throw in 1 byte  to make it <1s22:55
rustyop_null: hmm, I don't know, seems like ~1000 seconds @4MH/sec.  I guess you can send 1 byte....22:56
op_nullrusty: 4MH/s seems a little on the low size, and Intels next CPUs will have SHA256 instructions22:57
op_nulls/size/side22:57
rustyop_null: fair enough...22:59
-!- rusty is now known as rusty_afk22:59
kanzurehttps://github.com/papers-we-love/papers-we-love/tree/master/gossip23:01
kanzureand https://github.com/papers-we-love/papers-we-love/tree/master/distributed_systems23:01
gmaxwellso 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 bytes23:12
gmaxwelland 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
gmaxwellsince it's only another 10% at most.23:13
-!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards23:15
-!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection]23:18
-!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards23:18
-!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 264 seconds]23:23
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]23:25
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards23:26
-!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]23:29
-!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards23:30
-!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Client Quit]23:32

Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!