| --- 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-wizards | 00:27 | |
| -!- 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:32 | |
| -!- Dr-G3 is now known as FBI-AGENT | 00: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-wizards | 01:05 | |
| * andy-logbot is logging | 01: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|away | 01:33 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 01:35 | |
| -!- hollandais [~irenacob@li629-190.members.linode.com] has joined #bitcoin-wizards | 01:43 | |
| -!- bit2017 [~linker@1.54.25.127] has joined #bitcoin-wizards | 01:53 | |
| -!- 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] | 01:55 | |
| -!- berndj-blackout is now known as berndj | 02: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-wizards | 02:12 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 02: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-wizards | 02: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-wizards | 02: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-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:56 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] | 02:57 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 02:57 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 03:09 | |
| -!- adam3us [~Adium@207.134.53.206] has joined #bitcoin-wizards | 03:13 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 03: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-wizards | 04: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-wizards | 04: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-wizards | 04:16 | |
| -!- 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: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-wizards | 04: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-wizards | 04: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-wizards | 05: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-wizards | 05:37 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] | 05:38 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 05: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-wizards | 05: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-wizards | 06: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-wizards | 06:20 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 06:20 | |
| -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has joined #bitcoin-wizards | 06:25 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 06:29 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards | 06:31 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 256 seconds] | 06:38 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 06: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-wizards | 06:47 | |
| 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:49 |
|---|---|---|
| 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:51 |
| -!- 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:52 |
| 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:53 |
| 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:56 |
| 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:58 |
| 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 | 06:59 |
| 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:00 |
| 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:01 |
| 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: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_null | oh yeah, of course then you're toast. alternatives are great. | 07:03 |
| -!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has joined #bitcoin-wizards | 07:05 | |
| 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:06 |
| adam3us | https://bitcointalk.org/index.php?topic=311000.0 | 07:07 |
| 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:08 |
| 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:12 |
| -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards | 07:14 | |
| -!- 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:19 | |
| -!- yottabit [uid36770@gateway/web/irccloud.com/x-nfsbhhqgttnqdhrt] has joined #bitcoin-wizards | 07: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-wizards | 07:47 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 07: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-wizards | 08: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-wizards | 08: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-wizards | 08: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-wizards | 08:16 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 08: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-wizards | 08: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-wizards | 08:24 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 08: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-wizards | 08: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-wizards | 08:44 | |
| -!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has joined #bitcoin-wizards | 08:45 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 08:51 | |
| -!- lclc_bnc is now known as lclc | 08:58 | |
| -!- roconnor [~roconnor@e120-pool-d89a79cf.brdbnd.voicenetwork.ca] has joined #bitcoin-wizards | 09: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-wizards | 09: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-wizards | 09:14 | |
| -!- NewLiberty [~NewLibert@99-48-178-219.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 09:15 | |
| -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards | 09: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_bnc | 09:25 | |
| -!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has joined #bitcoin-wizards | 09: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-wizards | 09: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-wizards | 09:42 | |
| -!- adam3us [~Adium@modemcable091.205-160-184.mc.videotron.ca] has joined #bitcoin-wizards | 09: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-wizards | 09:49 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] | 09:53 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 09:53 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 09:56 | |
| -!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has joined #bitcoin-wizards | 09:58 | |
| -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has quit [Ping timeout: 250 seconds] | 10:03 | |
| -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has joined #bitcoin-wizards | 10: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-wizards | 10:09 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 10:09 | |
| -!- 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: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-wizards | 10: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-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:19 | |
| -!- spinza [~spin@197.89.10.145] has joined #bitcoin-wizards | 10:20 | |
| -!- 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:24 | |
| -!- samson_ [~samson_@183.89.22.186] has joined #bitcoin-wizards | 10: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-wizards | 10: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-wizards | 10: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-wizards | 10:48 | |
| -!- spinza_ [~spin@197.89.24.188] has joined #bitcoin-wizards | 10:49 | |
| -!- spinza [~spin@197.89.10.145] has quit [Ping timeout: 255 seconds] | 10:50 | |
| -!- lclc_bnc is now known as lclc | 10:51 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 10:56 | |
| -!- lclc is now known as lclc_bnc | 11:02 | |
| -!- soundx_ [~soundx@37.157.195.143] has joined #bitcoin-wizards | 11:04 | |
| 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:08 |
| -!- askmike [~askmike@92.69.252.98] has joined #bitcoin-wizards | 11:25 | |
| 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:28 |
| 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:29 |
| kanzure | and i think they have you submit and make your changes obvious | 11:30 |
| gwillen | heh, darn | 11:30 |
| -!- xuxu [~xuxu@unaffiliated/xuxu] has joined #bitcoin-wizards | 11: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-wizards | 11: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-wizards | 12: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-wizards | 12:09 | |
| -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 12:09 | |
| -!- FBI-AGENT is now known as Dr-G | 12: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-wizards | 12:14 | |
| -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has quit [Ping timeout: 245 seconds] | 12:19 | |
| adam3us | submit ekr's patches? ;) ooh politically insensitive | 12:31 |
| -!- c0rw|away is now known as c0rw1n | 12:32 | |
| 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:33 | |
| sipa | ? | 12:36 |
| sipa | ah | 12:36 |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards | 12: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-wizards | 13:07 | |
| -!- 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:08 | |
| -!- webdeli [~projects@42.39.233.220.static.exetel.com.au] has joined #bitcoin-wizards | 13:14 | |
| -!- 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:16 | |
| -!- 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:17 | |
| -!- spinza [~spin@197.89.23.217] has joined #bitcoin-wizards | 13:18 | |
| -!- spinza [~spin@197.89.23.217] has quit [Excess Flood] | 13:18 | |
| -!- 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: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-wizards | 13:36 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards | 13: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-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:07 | |
| -!- bitbumper [~bitbumper@c-69-254-243-205.hsd1.ks.comcast.net] has joined #bitcoin-wizards | 14: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-wizards | 14: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-wizards | 14:25 | |
| 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:35 |
| -!- 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:41 | |
| 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:42 |
| kanzure | i feel like my options are one terrible javascript execution environment for another terrible javascript execution environment | 14:47 |
| 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:48 | |
| 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:49 |
| 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:51 |
| adam3us | the 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 | |
| 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:57 |
| 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:58 |
| 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. | 14:59 |
| 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:02 |
| nsh | gmaxwell, what's the security effect of wrapping around n? | 15:03 |
| nsh | or cryptopathogenesis | 15:03 |
| gmaxwell | nsh: it's a total break. It only shows your outputs are congruent to your inputs mod n. | 15:05 |
| 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:06 |
| 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:07 |
| 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:09 |
| nsh | still hard to intuit why proving nonwrap would require extra stronger assumptions | 15:15 |
| * nsh reads more | 15:17 | |
| nsh | (or is that just within efficiency tolerances) | 15:18 |
| adam3us | gmaxwell: yes i am disappointed about the size. annoying range proofs. | 15:21 |
| 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:22 |
| -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has joined #bitcoin-wizards | 15:23 | |
| 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:28 | |
| 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:29 |
| adam3us | petertodd: i do agree that its preferable to use sym key, thats why i rejected pubkey variants, for hashcash | 15:30 |
| adam3us | petertodd: anyway my symkey argument stands: you can do that without oursourcing. just delete keybits. | 15:31 |
| nsh | andytoshi, "ethereal.. fed into itself"? | 15:32 |
| nsh | are there any actually analytically-enlightening papers on how systems break down under various departures from random oracle? | 15:33 |
| 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:34 |
| -!- 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| nsh | i don't mind disaster OR eschaton. it's both at once that really messes up your weekend | 15:50 |
| kanzure | (context: <https://www.youtube.com/watch?v=KJRh-37H4fA>) (not worth your time) | 15:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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: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 | |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 15:58 | |
| 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:00 |
| 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:01 | |
| 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:02 |
| 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:03 |
| * nsh nods | 16:04 | |
| 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:05 |
| 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:06 |
| -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has joined #bitcoin-wizards | 16:21 | |
| -!- webdeli [~projects@pa49-199-132-6.pa.vic.optusnet.com.au] has quit [Remote host closed the connection] | 16:24 | |
| 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:25 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] | 16:29 | |
| 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:31 |
| gmaxwell | (with computational soundness, of course, both from the strength of the comittments and from the F/S sampling) | 16:32 |
| 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:33 |
| -!- Quanttek [~quassel@2a02:8108:d00:870:9de8:5fb:e332:653b] has quit [Ping timeout: 258 seconds] | 16:45 | |
| 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:46 |
| gmaxwell | yes, 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-wizards | 16:57 | |
| -!- c0rw1n is now known as c0rw|sleep | 17:01 | |
| 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:03 |
| kanzure | uh, is it safe to encrypt a single bit in a public key system? | 17:06 |
| kanzure | oh i'm thinking of signing | 17:07 |
| gmaxwell | there is no public key anything in this. | 17:09 |
| gmaxwell | it'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-ruby | 17:23 |
| 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:35 |
| -!- op_null [~op_null@178.62.133.216] has joined #bitcoin-wizards | 17:45 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:ccd8:4d7d:19ab:f9c3] has joined #bitcoin-wizards | 17: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-wizards | 17: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-wizards | 18:11 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 18:12 | |
| -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards | 18:13 | |
| -!- altoz [~altoz@cpe-24-55-38-141.austin.res.rr.com] has joined #bitcoin-wizards | 18: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-wizards | 18: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-wizards | 19:02 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards | 19:02 | |
| -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has joined #bitcoin-wizards | 19:05 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 19: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-wizards | 19:57 | |
| 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:00 |
| 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:01 |
| lechuga_ | fountain code | 20:02 |
| lechuga_ | for wat | 20:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| 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:07 |
| 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:08 |
| rusty | gmaxwell: 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 |
| 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:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| lechuga_ | whats the motivation to only verify random parts, scaling? | 20:16 |
| rusty | lechuga_: yes, and robustness. AFAICT it's the only missing part of https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs | 20:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| gmaxwell | But there are other tools we can deploy to reduce sybil attack risks. | 20:21 |
| phantomcircuit | micro pow schemes? | 20:22 |
| 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: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 |
| 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:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| op_null | gmaxwell: oh right. it's ASCII but it uses the whole character set. not unicode. | 20:39 |
| op_null | and not base64, either. | 20:40 |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:40 | |
| op_null | nsh: probably hard to get data into a tweet image in any sort of reasonable density due to the JPEG compression | 20:42 |
| nsh | jpeg can be gamed, i suspect | 20:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| nsh | .title https://medium.com/@willkirkby/twitter-and-audio-steganography-568c8eae5ead | 20:48 |
| yoleaux | Twitter and Audio Steganography — Medium | 20:48 |
| nsh | (better) | 20:48 |
| -!- 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:49 |
| -!- 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:51 |
| 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:52 | |
| nsh | (it would just be differently awful) | 20:53 |
| phantomcircuit | gmaxwell, easy enough to set that up with udp and get reasonably effective nat transferval | 20:54 |
| phantomcircuit | traversal | 20:55 |
| gmaxwell | ( https://twitter.com/blockheaders ) | 20:55 |
| 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. | 20:56 |
| 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: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-wizards | 22:00 | |
| -!- maaku is now known as Guest17879 | 22: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-wizards | 22: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-wizards | 22:16 | |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 22:21 | |
| 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:33 |
| phantomcircuit | rusty, you can remove the nonce entirely | 22:35 |
| phantomcircuit | indeed you can remove/guess nearly everything | 22:36 |
| phantomcircuit | version. previous block hash, bits, and nonce | 22:36 |
| 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:37 |
| phantomcircuit | so 32 bytes + block height | 22:38 |
| op_null | might end up finding a different block :P | 22:40 |
| op_null | it's so much easier just to squirt out the 80 bytes somehow | 22:42 |
| 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:43 |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 22:45 | |
| op_null | encrypt 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-wizards | 22:53 | |
| rusty | phantomcircuit: you mean do 4bn probes to figure out the nonce? | 22:53 |
| op_null | that's not that long even on a normal CPU | 22:54 |
| 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:55 |
| rusty | op_null: hmm, I don't know, seems like ~1000 seconds @4MH/sec. I guess you can send 1 byte.... | 22:56 |
| 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:57 |
| rusty | op_null: fair enough... | 22:59 |
| -!- rusty is now known as rusty_afk | 22:59 | |
| 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:01 |
| 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:12 |
| 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:13 |
| -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards | 23: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-wizards | 23: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-wizards | 23: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-wizards | 23: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!