| --- Log opened Mon Nov 24 00:00:00 2014 | ||
| -!- Dizzle [~Dizzle@50.246.254.221] has quit [Quit: Leaving...] | 00:06 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 00:12 | |
| -!- Qfwfq [~WashIrvin@unaffiliated/washirving] has quit [Ping timeout: 250 seconds] | 00:13 | |
| -!- askmike [~askmike@83.162.194.88] has joined #bitcoin-wizards | 00:15 | |
| -!- Qfwfq [~WashIrvin@unaffiliated/washirving] has joined #bitcoin-wizards | 00:19 | |
| -!- AaronvanW [~ewout@255pc208.sshunet.nl] has joined #bitcoin-wizards | 00:27 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 00:40 | |
| -!- OX3_ [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards | 00:40 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 00:48 | |
| -!- OX3_ [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Remote host closed the connection] | 00:50 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has joined #bitcoin-wizards | 00:51 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection] | 01:05 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards | 01:05 | |
| * andy-logbot is logging | 01:05 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] | 01:05 | |
| -!- OX3 [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards | 01:06 | |
| -!- OX3___ [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards | 01:08 | |
| -!- OX3 [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Ping timeout: 264 seconds] | 01:11 | |
| -!- lclc is now known as lclc_bnc | 01:22 | |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 01:22 | |
| -!- jb55_ [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection] | 01:23 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 01:23 | |
| -!- fanquake_ [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 01:25 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Ping timeout: 245 seconds] | 01:26 | |
| -!- fanquake_ is now known as fanquake | 01:26 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 240 seconds] | 01:27 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 01:38 | |
| -!- OX3___ [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 258 seconds] | 01:42 | |
| -!- Rynomster [~quassel@41.183.16.70] has joined #bitcoin-wizards | 01:50 | |
| -!- nuke_ [~nuke@46.246.205.87.dsl.dyn.forthnet.gr] has joined #bitcoin-wizards | 01:53 | |
| -!- nuke1989 [~nuke@ppp-2-87-144-35.home.otenet.gr] has quit [Ping timeout: 264 seconds] | 01:53 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 01:54 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Ping timeout: 272 seconds] | 01:55 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Read error: Connection reset by peer] | 01:56 | |
| -!- jb55_ [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 01:56 | |
| -!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has joined #bitcoin-wizards | 01:57 | |
| -!- Rynomster [~quassel@41.183.16.70] has quit [Changing host] | 01:58 | |
| -!- Rynomster [~quassel@unaffiliated/rynomster] has joined #bitcoin-wizards | 01:58 | |
| -!- askmike [~askmike@83.162.194.88] has quit [] | 01:58 | |
| -!- jb55_ [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 240 seconds] | 02:00 | |
| -!- todaystomorrow [~me@d114-78-97-176.bla803.nsw.optusnet.com.au] has joined #bitcoin-wizards | 02:00 | |
| -!- lclc_bnc is now known as lclc | 02:01 | |
| -!- nuke_ [~nuke@46.246.205.87.dsl.dyn.forthnet.gr] has quit [Max SendQ exceeded] | 02:03 | |
| -!- nuke_ [~nuke@46.246.205.87.dsl.dyn.forthnet.gr] has joined #bitcoin-wizards | 02:04 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 02:06 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-titdtsrcmugngrzg] has quit [Quit: Connection closed for inactivity] | 02:13 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 02:14 | |
| -!- OX3_ [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards | 02:16 | |
| -!- nuke_ [~nuke@46.246.205.87.dsl.dyn.forthnet.gr] has quit [Ping timeout: 272 seconds] | 02:23 | |
| -!- vdo [~vdo@unaffiliated/vdo] has joined #bitcoin-wizards | 02:33 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 02:40 | |
| -!- Rynomster [~quassel@unaffiliated/rynomster] has quit [Ping timeout: 240 seconds] | 02:44 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 02:56 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 255 seconds] | 03:01 | |
| -!- op_null [~op_null@178.62.133.216] has joined #bitcoin-wizards | 03:13 | |
| -!- OX3_ [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Ping timeout: 244 seconds] | 03:17 | |
| -!- HM [~HM@curly.anarchicsheep.net] has joined #bitcoin-wizards | 03:20 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] | 03:21 | |
| -!- OX3_ [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards | 03:24 | |
| -!- samson_ [~samson_@183.89.168.206] has joined #bitcoin-wizards | 03:47 | |
| -!- samson2 [~samson_@183.88.24.69] has joined #bitcoin-wizards | 03:50 | |
| -!- samson_ [~samson_@183.89.168.206] has quit [Ping timeout: 272 seconds] | 03:52 | |
| -!- samson_ [~samson_@183.89.18.167] has joined #bitcoin-wizards | 03:53 | |
| -!- samson_ [~samson_@183.89.18.167] has quit [Client Quit] | 03:54 | |
| -!- samson2 [~samson_@183.88.24.69] has quit [Ping timeout: 256 seconds] | 03:55 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 03:57 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 265 seconds] | 04:02 | |
| -!- OX3_ [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Ping timeout: 265 seconds] | 04:16 | |
| -!- OX3 [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards | 04:28 | |
| -!- nuke1989 [~nuke@46.246.205.87.dsl.dyn.forthnet.gr] has joined #bitcoin-wizards | 04:29 | |
| -!- vdo [~vdo@unaffiliated/vdo] has quit [Ping timeout: 245 seconds] | 04:39 | |
| -!- Flyer33 [~f@unaffiliated/fluffybunny] has joined #bitcoin-wizards | 04:41 | |
| -!- OX3 [~OX3@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Remote host closed the connection] | 04:49 | |
| -!- OneNomos [~OneNomos@pool-71-178-102-22.washdc.east.verizon.net] has joined #bitcoin-wizards | 04:51 | |
| -!- OneNomos [~OneNomos@pool-71-178-102-22.washdc.east.verizon.net] has quit [Ping timeout: 256 seconds] | 04:56 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 04:58 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 255 seconds] | 05:02 | |
| -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards | 05:10 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 250 seconds] | 05:17 | |
| -!- Muis [sid26074@gateway/web/irccloud.com/x-jvoxunsohhbfhdwt] has quit [Read error: Connection reset by peer] | 05:23 | |
| -!- kumavis [sid13576@gateway/web/irccloud.com/x-exhofsdpgzcedyfh] has quit [Read error: Connection reset by peer] | 05:24 | |
| -!- mappum [sid43795@gateway/web/irccloud.com/x-nnwjelfmqqgwtqsm] has quit [Read error: Connection reset by peer] | 05:24 | |
| -!- Muis [sid26074@gateway/web/irccloud.com/x-eapbcqzygobjmepk] has joined #bitcoin-wizards | 05:24 | |
| -!- btc_ [sid40798@gateway/web/irccloud.com/x-phapfasnnqdarfzk] has quit [Read error: Connection reset by peer] | 05:24 | |
| -!- michagogo [uid14316@wikia/Michagogo] has quit [Write error: Connection reset by peer] | 05:24 | |
| -!- artifexd [sid28611@gateway/web/irccloud.com/x-vewubqzbnntlymsk] has quit [Read error: Connection reset by peer] | 05:24 | |
| -!- hguux_ [sid17919@gateway/web/irccloud.com/x-csitnxjoojonxmqr] has quit [Read error: Connection reset by peer] | 05:24 | |
| -!- mappum [sid43795@gateway/web/irccloud.com/x-aqieegezkljayorw] has joined #bitcoin-wizards | 05:25 | |
| -!- Nekokamisama [sid13576@gateway/web/irccloud.com/x-dqscwmrloymuxclz] has joined #bitcoin-wizards | 05:25 | |
| -!- btc__ [sid40798@gateway/web/irccloud.com/x-xdjrdehcphxbndtd] has joined #bitcoin-wizards | 05:25 | |
| -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-wizards | 05:26 | |
| -!- hguux_ [sid17919@gateway/web/irccloud.com/x-ltzxsqjetxpnnggy] has joined #bitcoin-wizards | 05:26 | |
| -!- Guest48334 [sid28611@gateway/web/irccloud.com/x-bfhigtkjnzpisipb] has joined #bitcoin-wizards | 05:27 | |
| -!- jbenet [sid17552@gateway/web/irccloud.com/x-hkzxdtktochozhiw] has quit [Ping timeout: 265 seconds] | 05:27 | |
| -!- jbenet [sid17552@gateway/web/irccloud.com/x-cmwcqmslaorctdhx] has joined #bitcoin-wizards | 05:30 | |
| -!- jgarzik_ [~jgarzik@12.226.55.2] has joined #bitcoin-wizards | 05:30 | |
| -!- jgarzik_ [~jgarzik@12.226.55.2] has quit [Changing host] | 05:30 | |
| -!- jgarzik_ [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 05:30 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 05:35 | |
| -!- drawingthesun [~drawingth@106-69-12-113.dyn.iinet.net.au] has joined #bitcoin-wizards | 05:39 | |
| -!- drawingthesun [~drawingth@106-69-12-113.dyn.iinet.net.au] has quit [Read error: Connection reset by peer] | 05:39 | |
| -!- c0rw|sleep is now known as c0rw1n | 05:39 | |
| -!- hearn [~mike@185.25.95.132] has quit [Ping timeout: 265 seconds] | 05:49 | |
| -!- nuke1989 [~nuke@46.246.205.87.dsl.dyn.forthnet.gr] has quit [Ping timeout: 240 seconds] | 05:50 | |
| -!- nuke1989 [~nuke@ppp-2-87-143-28.home.otenet.gr] has joined #bitcoin-wizards | 05:53 | |
| -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards | 05:57 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 05:59 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Read error: Connection reset by peer] | 06:00 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 06:00 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 272 seconds] | 06:05 | |
| -!- samson_ [~samson_@180.183.167.221] has joined #bitcoin-wizards | 06:07 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards | 06:11 | |
| -!- samson_ [~samson_@180.183.167.221] has quit [Read error: Connection reset by peer] | 06:34 | |
| -!- samson_ [~samson_@183.89.172.189] has joined #bitcoin-wizards | 06:38 | |
| -!- hearn [~mike@185.25.95.132] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 06:39 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 06:44 | |
| -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards | 06:49 | |
| -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards | 06:57 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 07:01 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 240 seconds] | 07:05 | |
| -!- cryptokeeper [c08b7d80@gateway/web/cgi-irc/kiwiirc.com/ip.192.139.125.128] has joined #bitcoin-wizards | 07:07 | |
| -!- MoALTz [~no@user-164-126-106-206.play-internet.pl] has joined #bitcoin-wizards | 07:09 | |
| -!- HM [~HM@curly.anarchicsheep.net] has quit [Ping timeout: 265 seconds] | 07:09 | |
| -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 265 seconds] | 07:10 | |
| -!- hearn [~mike@185.25.95.132] has quit [Excess Flood] | 07:12 | |
| -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards | 07:13 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 07:13 | |
| -!- coiner [~linker@113.161.87.238] has quit [Ping timeout: 240 seconds] | 07:14 | |
| -!- Quanttek [~quassel@ip1f1331f3.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 07:15 | |
| -!- Quanttek [~quassel@ip1f1331f3.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] | 07:18 | |
| -!- Quanttek [~quassel@2a02:8108:d00:870:48d8:29d1:8e63:de01] has joined #bitcoin-wizards | 07:22 | |
| -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has quit [Ping timeout: 272 seconds] | 07:22 | |
| -!- paulpasc_ [~paul@206.223.168.190] has joined #bitcoin-wizards | 07:27 | |
| -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards | 07:33 | |
| -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has joined #bitcoin-wizards | 07:34 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards | 07:43 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 07:46 | |
| -!- HM3 [~HM@2001:470:6bbb:1:3513:992b:6e2e:a5d4] has joined #bitcoin-wizards | 07:59 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer] | 08:00 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards | 08:01 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] | 08:01 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 08:01 | |
| -!- dansmith_btc [~dansmith@85.25.117.24] has joined #bitcoin-wizards | 08:01 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 08:02 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 08:02 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 265 seconds] | 08:07 | |
| -!- HM [~HM@2001:470:1f11:b4f:cb0b::1] has joined #bitcoin-wizards | 08:10 | |
| -!- HM3 [~HM@2001:470:6bbb:1:3513:992b:6e2e:a5d4] has quit [] | 08:10 | |
| -!- bitjedi [~bitjedi@unaffiliated/bitjedi] has joined #bitcoin-wizards | 08:12 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 08:19 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has quit [Read error: Connection reset by peer] | 08:19 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has joined #bitcoin-wizards | 08:20 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has quit [Read error: Connection reset by peer] | 08:20 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has joined #bitcoin-wizards | 08:20 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has quit [Read error: Connection reset by peer] | 08:21 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] | 08:21 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has joined #bitcoin-wizards | 08:21 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 08:21 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has quit [Read error: Connection reset by peer] | 08:22 | |
| -!- profreid [~profreid@a88-115-210-162.elisa-laajakaista.fi] has joined #bitcoin-wizards | 08:22 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has joined #bitcoin-wizards | 08:22 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has quit [Read error: Connection reset by peer] | 08:23 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has joined #bitcoin-wizards | 08:24 | |
| -!- Jokosh [~sark@37-252-108-40.ip.skylogicnet.com] has quit [Read error: Connection reset by peer] | 08:25 | |
| -!- paulpasc_ [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 08:27 | |
| -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards | 08:27 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds] | 08:28 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 08:39 | |
| -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:44fa:3cfd:f8a7:3926] has quit [Ping timeout: 258 seconds] | 08:44 | |
| -!- jbenet [sid17552@gateway/web/irccloud.com/x-cmwcqmslaorctdhx] has quit [] | 08:48 | |
| -!- jbenet [sid17552@gateway/web/irccloud.com/x-ivavqwcqzpovlrwp] has joined #bitcoin-wizards | 08:48 | |
| -!- ryanxcharles [~ryanxchar@162.245.22.162] has joined #bitcoin-wizards | 08:59 | |
| -!- ryanxcharles [~ryanxchar@162.245.22.162] has quit [Client Quit] | 09:03 | |
| -!- digitalmagus [~digitalma@unaffiliated/digitalmagus] has quit [Ping timeout: 240 seconds] | 09:03 | |
| -!- ryanxcharles [~ryanxchar@162.245.22.162] has joined #bitcoin-wizards | 09:04 | |
| -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has joined #bitcoin-wizards | 09:07 | |
| -!- OX3__ [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards | 09:14 | |
| -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 250 seconds] | 09:16 | |
| -!- doopers [doopers@75-132-239-120.dhcp.stls.mo.charter.com] has joined #bitcoin-wizards | 09:24 | |
| -!- Dizzle [~Dizzle@50.246.229.126] has joined #bitcoin-wizards | 09:25 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 244 seconds] | 09:29 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 09:29 | |
| -!- epscy [~epscy@176.126.241.239] has quit [Ping timeout: 255 seconds] | 09:30 | |
| -!- jgarzik_ [~jgarzik@unaffiliated/jgarzik] has quit [Quit: apple apple apple] | 09:40 | |
| -!- hearn [~mike@185.25.95.132] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 09:43 | |
| -!- coiner [~linker@118.69.162.103] has joined #bitcoin-wizards | 09:44 | |
| -!- op_null [~op_null@178.62.133.216] has quit [Quit: Lost terminal] | 09:52 | |
| -!- doopers [doopers@75-132-239-120.dhcp.stls.mo.charter.com] has quit [Ping timeout: 250 seconds] | 09:53 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection] | 09:53 | |
| -!- OX3__ [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 256 seconds] | 09:54 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 09:54 | |
| -!- lclc is now known as lclc_bnc | 09:55 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 258 seconds] | 09:58 | |
| -!- heath [~ybit@131.252.130.248] has quit [Changing host] | 09:59 | |
| -!- heath [~ybit@unaffiliated/ybit] has joined #bitcoin-wizards | 09:59 | |
| -!- bitjedi [~bitjedi@unaffiliated/bitjedi] has quit [Remote host closed the connection] | 10:00 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] | 10:03 | |
| -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has quit [Read error: Connection reset by peer] | 10:03 | |
| -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards | 10:06 | |
| -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Remote host closed the connection] | 10:17 | |
| -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards | 10:17 | |
| -!- profreid [~profreid@a88-115-210-162.elisa-laajakaista.fi] has quit [Quit: profreid] | 10:18 | |
| -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has joined #bitcoin-wizards | 10:18 | |
| -!- OneNomos [~OneNomos@pool-71-163-228-243.washdc.east.verizon.net] has joined #bitcoin-wizards | 10:29 | |
| -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 240 seconds] | 10:30 | |
| -!- Sub|zzz is now known as SubCreative | 10:32 | |
| -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has quit [Remote host closed the connection] | 10:40 | |
| -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards | 10:40 | |
| -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards | 10:41 | |
| -!- mkarrer_ [~mkarrer@193.Red-79-155-137.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 10:43 | |
| -!- mkarrer [~mkarrer@193.Red-79-155-137.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 10:46 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 10:50 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards | 10:51 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 10:52 | |
| -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has quit [Quit: leaving] | 10:52 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 10:55 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Client Quit] | 10:56 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Read error: Connection reset by peer] | 11:00 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards | 11:00 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 11:07 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 11:09 | |
| -!- tdlfbx [~bsm117532@64.253.217.244] has joined #bitcoin-wizards | 11:14 | |
| -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection] | 11:19 | |
| -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards | 11:20 | |
| -!- cashmen [~cashmen@jonny.cloakcoin.info] has joined #bitcoin-wizards | 11:25 | |
| -!- mortale [~mortale@gateway/tor-sasl/mortale] has quit [Remote host closed the connection] | 11:26 | |
| -!- epscy [~epscy@176.126.241.239] has joined #bitcoin-wizards | 11:26 | |
| -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards | 11:28 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Ping timeout: 240 seconds] | 11:28 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 11:31 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 11:34 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 11:40 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 11:42 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 11:43 | |
| -!- Dizzle [~Dizzle@50.246.229.126] has quit [Remote host closed the connection] | 11:44 | |
| -!- samson_ [~samson_@183.89.172.189] has quit [Read error: Connection reset by peer] | 11:47 | |
| -!- samson_ [~samson_@183.89.172.189] has joined #bitcoin-wizards | 11:47 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 11:48 | |
| -!- cbeams_ [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards | 11:50 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer] | 11:50 | |
| -!- orik [~orik@remote.snococpa.com] has joined #bitcoin-wizards | 11:52 | |
| -!- cbeams_ [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Read error: Connection reset by peer] | 11:55 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 11:55 | |
| -!- OneNomos [~OneNomos@pool-71-163-228-243.washdc.east.verizon.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 12:00 | |
| -!- cbeams_ [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards | 12:07 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer] | 12:07 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 12:12 | |
| -!- spinza [~spin@197.89.10.224] has quit [Quit: Coyote finally caught up with me...] | 12:15 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-hkvcimlkhqbqmqmk] has joined #bitcoin-wizards | 12:16 | |
| -!- spinza [~spin@197.89.10.224] has joined #bitcoin-wizards | 12:16 | |
| -!- spinza [~spin@197.89.10.224] has quit [Excess Flood] | 12:16 | |
| -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection] | 12:17 | |
| -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards | 12:17 | |
| -!- spinza [~spin@197.89.10.224] has joined #bitcoin-wizards | 12:17 | |
| -!- jb55_ [~jb55@208.98.200.98] has joined #bitcoin-wizards | 12:19 | |
| -!- jb55 [~jb55@208.98.200.98] has quit [Read error: Connection reset by peer] | 12:20 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Ping timeout: 264 seconds] | 12:22 | |
| -!- cbeams_ [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Remote host closed the connection] | 12:23 | |
| -!- jb55_ [~jb55@208.98.200.98] has quit [Remote host closed the connection] | 12:27 | |
| -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards | 12:27 | |
| -!- orik [~orik@remote.snococpa.com] has quit [Read error: Connection reset by peer] | 12:35 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 12:36 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 12:36 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Client Quit] | 12:39 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 12:47 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 13:05 | |
| -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards | 13:05 | |
| -!- paulpaschos [~paul@206.223.168.190] has quit [Ping timeout: 264 seconds] | 13:10 | |
| -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards | 13:28 | |
| -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has quit [Ping timeout: 244 seconds] | 13:28 | |
| -!- OneNomos [~OneNomos@pool-71-163-228-243.washdc.east.verizon.net] has joined #bitcoin-wizards | 13:31 | |
| -!- RoboTeddy [~roboteddy@2604:5500:13:5fc:20e3:a255:2c37:bc0] has joined #bitcoin-wizards | 13:34 | |
| -!- OneNomos [~OneNomos@pool-71-163-228-243.washdc.east.verizon.net] has quit [Ping timeout: 245 seconds] | 13:36 | |
| -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 13:37 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards | 13:39 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] | 13:39 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 13:39 | |
| -!- Quanttek [~quassel@2a02:8108:d00:870:48d8:29d1:8e63:de01] has quit [Ping timeout: 265 seconds] | 13:42 | |
| gmaxwell | "As a result it became common first to develop a protocol with nice properties that | 13:44 |
|---|---|---|
| gmaxwell | has a proof of security in the random oracle model, and then to publish a modified | 13:44 |
| gmaxwell | version, usually with slightly less desirable properties but with a security proof | 13:44 |
| gmaxwell | in a “standard” model. This was an important advance for the profession, since in | 13:44 |
| gmaxwell | one fell swoop it increased the number of papers that could be published on | 13:44 |
| gmaxwell | provably secure protocols from N to 2N." | 13:44 |
| -!- Quanttek [~quassel@ip1f12eb0d.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 13:46 | |
| -!- Quanttek [~quassel@ip1f12eb0d.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] | 13:47 | |
| kanzure | "what we really need is a merkle tree of cryptography researcher sign-offs" | 13:50 |
| -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has quit [Quit: Leaving] | 13:55 | |
| -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 13:55 | |
| -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has quit [Client Quit] | 13:59 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 14:00 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection] | 14:01 | |
| tromp_ | anyone here planning to go to bitcoin'2015 in puerto rico? | 14:01 |
| tdlfbx | Does anyone have anything nice to say about Paycoin or Hashcoin? I'm marking it as garbage, but I'd be interested if someone disagrees. | 14:06 |
| heath | tromp_: i plan on being at the north american bitcoin conference | 14:11 |
| -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has joined #bitcoin-wizards | 14:12 | |
| -!- Dizzle [~Dizzle@67.139.65.194] has joined #bitcoin-wizards | 14:15 | |
| -!- orik [~orik@remote.snococpa.com] has joined #bitcoin-wizards | 14:17 | |
| -!- AnoAnon [~AnoAnon@197.37.103.36] has joined #bitcoin-wizards | 14:20 | |
| -!- AnoAnon [~AnoAnon@197.37.103.36] has quit [Read error: Connection reset by peer] | 14:20 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 14:21 | |
| tromp_ | heath: did that one have a call for papers? | 14:29 |
| -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 14:32 | |
| -!- Dizzle [~Dizzle@67.139.65.194] has quit [Remote host closed the connection] | 14:38 | |
| -!- orik [~orik@remote.snococpa.com] has quit [Quit: Textual IRC Client: www.textualapp.com] | 14:39 | |
| -!- Alanius [~alanius@ssh2.ulyssis.student.kuleuven.be] has quit [Quit: leaving] | 14:39 | |
| -!- Alanius [~alanius@ssh2.ulyssis.student.kuleuven.be] has joined #bitcoin-wizards | 14:40 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 14:40 | |
| -!- Dizzle [~Dizzle@67.139.65.194] has joined #bitcoin-wizards | 14:41 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-hkvcimlkhqbqmqmk] has quit [Quit: Connection closed for inactivity] | 14:43 | |
| -!- woah [~woah@75-101-111-82.dedicated.static.sonic.net] has joined #bitcoin-wizards | 14:43 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 14:44 | |
| -!- op_null [~op_null@178.62.133.216] has joined #bitcoin-wizards | 14:55 | |
| op_null | tdlfbx: there's nothing to say really. the "white paper" for paycoin is nothing but marketing wank. there's no technical detail, and the only attempts they made at adding some is some nonsense "proof of concept code" that says quite literally nothing. | 14:56 |
| tdlfbx | op_null: agreed. | 14:56 |
| -!- Dizzle [~Dizzle@67.139.65.194] has quit [Quit: bbiab] | 14:58 | |
| op_null | tdlfbx: I've avoided bringing it up too much because it's just free publicity. this alone is proof that nobody technical is behind the concept or execution. https://i.imgur.com/7L4qs7F.png | 14:58 |
| tdlfbx | WTF is that? | 15:00 |
| op_null | that's the only technical detail in paycoin's "whitepaper", it's supposed to prove how "immutable transactions" work, or something. there's no way that does anything of course, just mindless nonsense. | 15:01 |
| phantomcircuit | tdlfbx, gaw is a ponzi scheme | 15:05 |
| tdlfbx | I was guessing that from the photos of embossed H on aluminum. | 15:06 |
| phantomcircuit | they can under price everybody else but they cant do so wildly (since that would be too obvious) | 15:06 |
| phantomcircuit | since the price has dropped im sure they have seen significantly fewer people buying their ponzi contracts | 15:06 |
| phantomcircuit | thus they need a new way to get cash for their ponzi | 15:06 |
| phantomcircuit | enter hash/pay coin | 15:07 |
| -!- tdlfbx [~bsm117532@64.253.217.244] has quit [Quit: Leaving.] | 15:12 | |
| -!- bram__ [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 15:17 | |
| bram__ | Hey everybody | 15:17 |
| gmaxwell | tromp_: I'm planning on going to bitcoin'2015 in puerto rico; though I haven't booked anything yet. | 15:18 |
| -!- bifforoni [~zorin@84.108.84.113] has joined #bitcoin-wizards | 15:19 | |
| midnightmagic | Why did they choose PR as a venue? | 15:19 |
| -!- bram__ is now known as bramm | 15:19 | |
| bramm | I have some posts on proofs of work up on bramcohen.com | 15:20 |
| gmaxwell | op_null: you should send them a patch to their slide that fixes the parenthese imbalance. | 15:20 |
| bramm | So far all feedback has been... how to put this... from people unfamiliar with the inner workings of existing proofs of work schemes. | 15:20 |
| phantomcircuit | gmaxwell, ha | 15:20 |
| tromp_ | gmaxwell: the reserved hotel rates of $260/night inclusive seem a little steep. | 15:20 |
| midnightmagic | oh, hey bramm. | 15:21 |
| phantomcircuit | that group is very good at the "conference in tropics" racket | 15:21 |
| * midnightmagic waves | 15:21 | |
| tromp_ | hi, Bram | 15:21 |
| op_null | bramm: have you read alts.pdf? | 15:21 |
| gmaxwell | bramm: You're a bit behind the times wrt using collissions for asymetrically memory hard functions, let me introduce you to John Tromp. | 15:22 |
| bramm | Oh I was going to ask if that was John Tromp, we met years ago | 15:22 |
| tromp_ | i've met with Bram many years ago in Amsterdam | 15:22 |
| bramm | Yes, we played some games | 15:22 |
| tromp_ | yep. please have a look at my Cuckoo Cycle pow at https://github.com/tromp/cuckoo | 15:23 |
| bramm | Any links to existing work on asymmetrically memory hard functions would be appreciated, the thing I posted is simple enough that it seems like it should already be known | 15:23 |
| op_null | gmaxwell: heh well, seeing as the "whitepaper" was really 50MB of images I doubt they can edit the text anymore :P | 15:23 |
| gmaxwell | Though, ... I still of of the opinion that memory hardness is an strongly ill advised criteria. I really need to find the time to further formalize the arguments there ... | 15:23 |
| Eliel | bramm: read up on cuckoo cycle | 15:25 |
| bramm | Reading on cuckoo cycle now | 15:25 |
| gmaxwell | bramm: haven't read your post yet, but most early efforts in that space suffer pretty substantial time-memory-tradeoff optimization attacks that the cuckoo cycle work tries to avoid. | 15:25 |
| phantomcircuit | gmaxwell, the easiest argument is that dram is about 2x cheaper when it's not on a dimm module | 15:26 |
| gmaxwell | phantomcircuit: there is a more fundimental one. | 15:26 |
| bramm | gmaxwell, for the password hashing scheme I gave no time/memory tradeoffs are available | 15:26 |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:a531:7326:888e:3863] has joined #bitcoin-wizards | 15:27 | |
| bramm | although of course password hashing schemes aren't a great fit for proofs of work | 15:27 |
| op_null | why not? | 15:27 |
| bramm | op_null, because they're expensive to verify | 15:27 |
| gmaxwell | bramm: the observation about memory hard functions (of the scrypt lineage at least) that concerns me the most is this; That the cost analysis for a cracking machine ignores operating costs. We know from practice that for compute intensive hardware on modern silicon process (e.g. <=45nm) the energy to power it dwarfs the marginal mfgr cost within a short time horizion (e.g. a month or two). So an analysis of the costs which is ... | 15:28 |
| gmaxwell | ... ignoring operating costs is ignoring the bulk of the costs, and moreover the mfgr is one time, and so if the hardware is used for a long time that cost is amortized across many attacks. Ultimately this lowers the gap between the attacker and the defender. | 15:28 |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 15:28 | |
| op_null | bramm: I guess I was taking SHA256 to be a "password hashing" method. it's easy enough to verify that it's a totally dwarfed by almost everything else in block validation. you only need about 680k hashes to verify the full block chains PoW at the moment. | 15:29 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 15:29 | |
| op_null | there's probably more SHA256 operations in script validation than in the block headers, but I don't have numbers to back that up. | 15:30 |
| -!- altoz [~kvirc@cpe-24-55-38-141.austin.res.rr.com] has joined #bitcoin-wizards | 15:31 | |
| gmaxwell | bramm: hm, certantly there is. For example using negligble memory I compute only the first two entries in your list. | 15:31 |
| tromp_ | bramm, how did you manage to overlook cuckoo cycle? did you try googling for proof-of-work memory ? | 15:31 |
| bramm | tromp_, I did too much looking at password hashing schemes and not enough looking into proofs of work separately | 15:34 |
| op_null | (actually I do, there's 12.8M P2PKH outputs in the chain versus 2*320000 block PoW validations) | 15:34 |
| bramm | The proofs of work stuff I've seen stuff on was x11 or x13 or whatever amount of vomit they've had fun throwing together at this point | 15:34 |
| tromp_ | bramm: ppl have asked me if i cant make a good password hash out of cuckoo cycle, and indeed i do not see any good fit there | 15:35 |
| gmaxwell | bramm: well you're mostly looking into near-pure asset speculation games. There is very little technical thought that goes into most of those "altcoin" things. | 15:35 |
| -!- moa [~moa@opentransactions/dev/moa] has joined #bitcoin-wizards | 15:35 | |
| gmaxwell | ( see also alts.pdf linked on http://bitcoin.ninja/ ) | 15:35 |
| op_null | hah. they're up to X17 by the way, but I think they kind of ran out of cryptographic hashes they could find easy implementations for. | 15:36 |
| bramm | op_null, vanilla sha256 is an extremely bad password hashing scheme, it's way too easy to do and allows someone to launch an attack on a password file effectively | 15:36 |
| -!- altoz [~kvirc@cpe-24-55-38-141.austin.res.rr.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] | 15:36 | |
| bramm | tromp_, yes password hashing and proofs of work are very different things | 15:36 |
| bramm | gmaxwell, the lack of talent pool in the alt coins is something I clearly noticed | 15:37 |
| op_null | bramm: I don't disagree in the least, but I'm also not very convinced that memory hard is a desirable property either. the mining landscape you'd end up with is a lot different to what we have today. | 15:38 |
| -!- bifforoni [~zorin@84.108.84.113] has quit [Quit: Leaving] | 15:38 | |
| gmaxwell | It's not a "lack of talent pool"; it's that work with technical merit isn't merely unneeded, it's actually at odds with the goal. The business model there is to churn out an unending sea of new speculative assets, the sales pitch only has to be as thick as the generally non-tecnical audience... and buidling and verifying new cryptosystems is work that takes long spans of time. | 15:38 |
| bramm | gmaxwell, I don't understand your objection to memory hardness. Ideally a memory hard scheme will require the CPU to sit around bored most of the time. | 15:39 |
| op_null | bramm: part of the nice thing about mining botnets is that they are totally obvious. people don't like it when their hardware turns to lava, so they find the infection and stop it. | 15:40 |
| gmaxwell | bramm: Consider the argument for memory hardness in the first place, it's given most in depth in the scrypt white paper. It's an economic arugment about the costs to an attacker. However, it completely neglects the operating costs. When you consider the combined cost of an attack, memory hard functions maximize the upfront at the expense of the operating cost. This may be ill advised since the upfront is a one time cost which is ... | 15:41 |
| gmaxwell | ... amortized over extended use. | 15:41 |
| gmaxwell | I'm not sure how else to state that one. | 15:41 |
| -!- Myagui is now known as Iocohammerhead | 15:42 | |
| -!- Iocohammerhead is now known as Myagui | 15:42 | |
| Alanius | someone might invest massively in memory and cut the costs of all future memory hard pow's or password hash cracks | 15:42 |
| bramm | What is your model of 'operating costs'? There's power and... ? | 15:42 |
| rusty | gmaxwell: to add to your business model comment: it also means interesting experiments get drowned out in the sea of altcoins; it's hard to attract dev interest in the sea of noise. I hope the rise of pegged sidechains will change that. | 15:43 |
| HM | memory has a running cost... | 15:43 |
| Alanius | basically, you want every single password hash crack to be hard, not just the first one | 15:43 |
| gmaxwell | There are other arguments, of the sort phantomcircuit would be more likely to make... e.g. along fact that there exist different hardware architectures like Computational-RAM which may provide big optimizations (or even just 3d SST ram); but they're hard to reason about because that technology is not mature. | 15:43 |
| gmaxwell | bramm: power primarily, I'd not fault an analysis for ignoring any operating costs except power. :) | 15:43 |
| -!- Myagui is now known as EI_Kabong | 15:43 | |
| -!- EI_Kabong is now known as Myagui | 15:43 | |
| bramm | If someone invests massively in memory they're buying fairly vanilla memory, there's nothing you can do about an attacker just plain spending money on COTS | 15:43 |
| tromp_ | a 1GB ram chip draws on the order of 1W | 15:43 |
| bramm | gmaxwell, so you're saying that the CPU sitting around bored is a problem? | 15:44 |
| op_null | gmaxwell: one of the bigger flash manufacturers is doing stacked dies in consumer products now, samsung possibly. | 15:44 |
| tromp_ | but for many ppl that is already a sunk cost, so there will be many more "defenders" | 15:44 |
| bramm | I would think that a bored CPU means that an ASIC can't do more than have a bunch of memory, and if you do it right you should be talking about totally normal memory | 15:44 |
| gmaxwell | bramm: In general, when talking about password kdf functions any resource the honest user has idle is at best a lost advantage they could have against an attacker. | 15:45 |
| bramm | Or maybe special low latency memory. I'm okay with subsidizing research into low latency memory. | 15:45 |
| tromp_ | bramm: that's not quite true for cuckoo cycle, bramm | 15:45 |
| bramm | tromp_, What isn't quite true? The CPU isn't sitting around bored? | 15:45 |
| tromp_ | it could benefit from custom memory that's 2 bit-wide rather than 32 or 64-bit wide | 15:45 |
| tromp_ | sorry; gotto go. i'll catch up later | 15:46 |
| tromp_ | that commodity memory is near optimal for memory hard pow | 15:46 |
| gmaxwell | bramm: well in the case of a POW as applied to bitcoin, having special implementation paths available is a violation of the optimization-freeness criteria we'd expect to see from a sound choice in a POW function; optimization freeness is relevant to different degrees in different POW applications though. | 15:46 |
| bramm | tromp, Okay, I'll read through the docs on cuckoo and hopefully have some coherent questions later | 15:46 |
| gmaxwell | rusty: Right. A seperation of concerns. Or maybe we find that the interest in non-speculative asset creation is actually almost zero. :-/ (oh well, good to have interesting things to discover) | 15:47 |
| op_null | it's samsung doing stacked NAND now. they call it v-nand. 24 stacked dies in 2013 products, 32 stacked dies in 2014 products. | 15:47 |
| bramm | gmaxwell, It is of course possible to have a proof of work which both requires lots of memory and CPU | 15:48 |
| HM | I prefer the sound of "perpendicular NAND" | 15:48 |
| rusty | gmaxwell: yes, pettycoin has discovered that to be true :). Though it's nicer to have a handful of technical people interested than hordes of speculators. | 15:48 |
| bramm | I kind of doubt that side chains are going to happen. Requiring that acceptance of a bit coin block chain have a non-deterministic dependency on something else seems like a nonstarter. | 15:49 |
| gmaxwell | bramm: Ah. Seems you don't actually understand them. | 15:49 |
| op_null | one of the problems is that the only altcoin for a while that was super interesting was Bytecoin with sing signatures, but they squandered that by attempting to scam with it and intentionally adding backdoors and vulnerabilities. | 15:49 |
| op_null | s/sing/ring | 15:50 |
| midnightmagic | gmaxwell: If you loosely show that it costs less to supply electricity to memory-hard PoW in ASIC, and costs insignificantly more to manufacture memory-hard-PoW silicon vs. CPU-hard I think it would make more sense to people who haven't been reasoning about the economic costs of mining for a bunch of years already. Showing that CPU-hard PoW is the most effective waste of electricity might require some kind of | 15:50 |
| midnightmagic | information-theoretic lemma, but it feels fairly straightforward. | 15:50 |
| gmaxwell | bramm: A non-determinstic dependency on external data would indeed be a unthinkable non-starter. | 15:50 |
| bramm | gmaxwell, What don't I understand? The releasing of a coin step is hugely problematic | 15:50 |
| bramm | releasing from the side chain back again I mean | 15:50 |
| midnightmagic | (like, in the future, when the topic comes back to it) | 15:51 |
| gmaxwell | bramm: It sounds like you've misunderstood the release mechenism. The release is completely self contained and doesn't make the validity of a bitcoin block conditional on external data. | 15:51 |
| bramm | gmaxwell, Then how does it work? I asked Adam Back about it and he said there has to be a limited time to undo it, sounds very conditional to me | 15:52 |
| rusty | bramm: the block is still valid, the tx output might not be spendable. | 15:53 |
| bramm | I have a very simple question: What information is necessary to show that a coin is released? | 15:53 |
| gmaxwell | A SPV proof extracted from the neighboring system is put by the user moving the data as the signature of their transactions. | 15:54 |
| bramm | And what calculation is done to know what account the coin has been released to? | 15:54 |
| -!- Dizzle [~Dizzle@12.130.116.6] has joined #bitcoin-wizards | 15:54 | |
| bramm | What is an SPV proof? | 15:54 |
| -!- zwischenzug [~zwischenz@33.Red-79-158-209.staticIP.rima-tde.net] has joined #bitcoin-wizards | 15:54 | |
| rusty | bramm: Um, you might want to read the whitepaper, it's reasonably well referenced and explained. | 15:54 |
| gmaxwell | bramm: Section 8 of bitcoin.pdf. It's a hash tree membership proof. | 15:55 |
| bramm | This is aside from my thought that side chaining is really shackling a system to bit coin's limitations rather than helping, but that's a separate issue | 15:55 |
| gmaxwell | (Used widely by lite bitcoin clients today to verify transaction membership in a blockchain) | 15:55 |
| phantomcircuit | gmaxwell, im not so sure about the operating costs exceeding the capital costs for memory hard pow | 15:55 |
| gmaxwell | bramm: so the essance of the SPV two-way peg. Is that coins assigned to a peg are assigned to a scriptPubKey that requires that a valid signature consist of a hash tree membership proof from the target chain that show that the target chain has released the coins to a particular new bitcoin scriptPubKey. | 15:57 |
| Eliel | bramm: for most systems that's fine. Others will either become partial side chains or be completely separate. | 15:57 |
| gmaxwell | bramm: This is explained in some detail in the sidechains whitepaper, (also linked on bitcoin.ninja); I'm unlikely to do it justice in a few lines of IRC. :) | 15:58 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 15:58 | |
| bramm | But what does it accept as the valid root of the side chain? That seems hugely problematic. It seems to do it based on the amount of work in the side chain (I think, not sure I'm reading it right) but that's rather unrelated to the amount of work on the bit coin block chain, which is what everything else uses to decide what the current valid root is. | 15:59 |
| Eliel | bramm: root? that's of course defined in when the coins are moved to the sidechain. | 16:00 |
| kanzure | bramm: have you read https://download.wpsoftware.net/bitcoin/alts.pdf or https://download.wpsoftware.net/bitcoin/pos.pdf or https://download.wpsoftware.net/bitcoin/asic-faq.pdf ? | 16:00 |
| rusty | bramm: the suggestion was there would be a some calculation limiting amount of bitcoins which could be transferred from any particular sidechain to the number which were moved there. This contains any damage. | 16:01 |
| bramm | From the side chains whitepaper: "Such a proof may be invalidated by another proof demonstrating the existence | 16:01 |
| bramm | of a chain with more work which does not include the block which created the output." | 16:01 |
| gmaxwell | bramm: sure, but this has nothing to do with block validity. It's still internal to the transaction entirely. | 16:01 |
| gmaxwell | bramm: Work on the sidechain. To spend a sidechain coin your signature shows a spend in the sidechain, and then some (per-sidechain parameter) amount of additional work on top of it. | 16:02 |
| bramm | kanzure, the ASIC faq says some things which are just plain wrong | 16:02 |
| gmaxwell | bramm: The signature can only sign for transactions which produce txouts which are CHECKLOCKTIMEVERIFY (or analogous). | 16:03 |
| op_null | bramm: what do you think in it is wrong? | 16:03 |
| kanzure | so... yes? | 16:03 |
| bramm | Q: Is ASIC resistance desirable? A: No | 16:03 |
| gmaxwell | ... | 16:03 |
| kanzure | are we sure this is bram | 16:04 |
| op_null | bramm: can you provide a counter for that? | 16:04 |
| kanzure | quick, someone come up with an obscure dht question | 16:04 |
| fenn | kanzure: unlikely a troll would go to such lengths to get -wizards to review his proof of work scheme posted on bramcohen.com | 16:05 |
| kanzure | excellent point | 16:05 |
| kanzure | carry on | 16:05 |
| gmaxwell | bramm: asic faq spends quite a few pages explaining it's argument as to what 'asic resistance' is not desirable. If _thats_ your example of something 'just plain wrong', then I really recommend you give the page a serious read. | 16:06 |
| midnightmagic | That's not necessarily correct, as the discussion, the twitter back-and-forths, and related info has been noticed and commented-on by some well-known troll types who are capable of manufacturing reasonably consistent technical argumentation. | 16:07 |
| bramm | gmaxwell, I'm still not following what these proofs are, it seems to be that the main thing you need to release a coin from a side chain is a proof of a bunch of work, and then a ... allegation? of the release happening | 16:07 |
| midnightmagic | no offence, bram. | 16:07 |
| bramm | gmaxwell, Reading through the argument, it seems to be saying that ASIC manufacturers spend more money on power than on hardware? | 16:08 |
| bramm | ASIC miners I mean | 16:08 |
| gmaxwell | bramm: they do. | 16:08 |
| gmaxwell | (was also true of gpus, for that matter) | 16:08 |
| bramm | Could have just said that up front rather than forcing me to read through pages of argumentation :-P | 16:08 |
| bramm | Anyway, that's an interesting point. The question then becomes what is already well optimized on regular CPUs that the ASICs can't do it with less power | 16:09 |
| gmaxwell | Useful feedback, I suppose. The page makes a number of other important points about criteria we've reconized as being important for good POW schemes, e.g. progress freeness, approximation freeness, optimization freeness. | 16:10 |
| op_null | the question is more if that is desirable. | 16:10 |
| bramm | Or alternatively can you come up with a scheme which uses such mass quantities of memory that the costs are primarily memory depreciation rather than power? | 16:10 |
| bramm | Both of which are very different takeaways than 'ASIC resistance is futile' | 16:11 |
| kanzure | why is it important to you to have asic resistance? | 16:11 |
| bramm | to avoid centralized control | 16:11 |
| bramm | And to avoid general waste of resources. Its not like all this manufacturing and CPU burning is contributing to society in any meaningful way. | 16:11 |
| kanzure | non-asic centralization is impossible? | 16:11 |
| kanzure | wait, what's waste here? | 16:11 |
| gmaxwell | bramm: in the context of cryptocurrency, the answer may be not much. Since we're in (in theory) perfect competition, even only a small factor efficiency difference puts everyone else out of business. It's hard to imagine some instruction sequence that couldn't at least be made 10x more efficient on specialized hardware ... you can likely get that much just from eliminating peripheral and IO costs. | 16:11 |
| op_null | without ASICs we would still be owned by botnets. the Skynet botnet thrashed the Bitcoin network from what I've read of it's size. | 16:12 |
| gmaxwell | Though, e.g. for a password hardening KDF getting an attacker down to operting only 10x more efficient than the defender would be pretty great. | 16:12 |
| kanzure | there are many who argue that proof of work is not wasteful because of the purpose it is being put to | 16:12 |
| bramm | Saying 'other things could kill us, we should throw in the towel' isn't a particularly useful argument | 16:12 |
| bramm | kanzure, I'm not even going to address that argument | 16:13 |
| kanzure | hmm. | 16:13 |
| op_null | I'm saying we shouldn't throw away the best security we have. | 16:13 |
| kanzure | bramm: so the concern is that the costs of a decentralized system are greater than the costs of running a centralized ledger..? | 16:14 |
| bramm | op_null, I don't think we have to worry about doing such a great job of asic resistance that the asics have no advantage at all, the bigger problem right now is the asics running everything | 16:14 |
| op_null | you can have your dreams of a grand hyper decentralised network, but if we can be owned by a botnet the dream is ruined out of the gate. | 16:14 |
| bramm | kanzure, I didn't suggest fixing things by switching to a centralized ledger | 16:14 |
| -!- instagibbs [6c1c1eb9@gateway/web/freenode/ip.108.28.30.185] has joined #bitcoin-wizards | 16:14 | |
| phantomcircuit | botnet operators loved the X11 algo | 16:15 |
| op_null | phantomcircuit: and the Monero one. | 16:15 |
| kanzure | bramm: if your concern was waste and it's not worth addressing waste, then i was left assuming you would choose waste-minimizing solutions.. | 16:15 |
| instagibbs | more to the point, look at what gmaxwell said: "Since we're in (in theory) perfect competition, even only a small factor efficiency difference puts everyone else out of business." it's a temporary win | 16:15 |
| instagibbs | and the more complex the ASIC is in the end, the higher the barrier to manufacture | 16:15 |
| phantomcircuit | gmaxwell, we're at the point were it makes sense to run hw, but not to buy more | 16:16 |
| bramm | kanzure, there is a very real question as to what value bit coin is providing at all, but for the sake of research it's best to assume that its hyper-decentralization is the thing of value and that concept needs to be worked within | 16:16 |
| instagibbs | censorship resistant ledger, imo. | 16:17 |
| bramm | I mean, if you take away hyper-decentralization then there isn't anything interesting in bit coin protocol at all. | 16:17 |
| Alanius | if hyper decentralization is the important thing, why worry about waste? | 16:17 |
| kanzure | a definition of what is and is not waste would be useful here | 16:17 |
| bramm | Alanius, because you can keep the hyper decentralization while reducing the amount of waste | 16:18 |
| instagibbs | bramm: how | 16:18 |
| bramm | burnt CPU = waste | 16:18 |
| gmaxwell | I'm confused about this 'waste' stuff. | 16:18 |
| -!- discreteunit [~discreteu@70.105.37.119] has joined #bitcoin-wizards | 16:18 | |
| gmaxwell | Becuase it's taking as given that there is non-trivial waste to begin with; and that is not at all obvious to me. | 16:18 |
| bramm | This is my new painting. It is worth $100 million. I call it DEADBEEFDEADBEEFDEADBEEF | 16:19 |
| kanzure | is that your fingerprint? | 16:19 |
| fenn | the waste is electricity turned to heat | 16:19 |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 16:19 | |
| bramm | Hey zooko | 16:19 |
| kanzure | (i am reminded of 0xFEEDBEEF) http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0xFEEDBEEF | 16:19 |
| gmaxwell | thats a pretty flawed understanding of economics there. When I make the same argument I talk about a smashed hope diamond which has been urinated on by the pope; ... very rare item. So obviously valuable. :P | 16:19 |
| Alanius | Isn't waste subjective, i.e., what's waste for one person might not be waste for another | 16:20 |
| zooko | Hi there, bramm! | 16:20 |
| phantomcircuit | gmaxwell, iono i could see certain people paying big money for that | 16:20 |
| zooko | Heh heh. | 16:20 |
| bramm | instagibbs, One possible improvement would be to make mining costs be based on memory depreciation rather than CPU usage | 16:20 |
| gmaxwell | But none of that is an understanding of Bitcoin. Bitcoins aren't produced from work, they're just handed out by the system. The work in bitcoin exists to provide security, and there no spurrious economic argument exists. | 16:20 |
| bramm | There are some other crazy techniques for reducing waste but I'm keeping mum about them for now. | 16:21 |
| op_null | I hope they're not "useful" PoW sort of techniques. | 16:21 |
| gmaxwell | bramm: if I may be so bold, based on your ideas posted so far I think they're likely to be long since considered, found wanting, and discarded. :) | 16:22 |
| bramm | op_null, oh hell no, much saner and more interesting than that | 16:22 |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 16:22 | |
| gmaxwell | and if so, keeping them secret just prolongs your ignorance, not anyone elses. :) | 16:22 |
| bramm | gmaxwell, No, my most interesting idea is based on a primitive which I had to improve considerable on the state of the art, for a problem where there's actual published academic work about it | 16:23 |
| kanzure | so about that definition of waste... | 16:24 |
| Alanius | < bramm> burnt CPU = waste | 16:24 |
| Alanius | so if I understand correctly, bramm is proposing to burn RAM instead of CPUs | 16:25 |
| bramm | Also all of your arguments against anything I'm saying apply equally against cuckoo, maybe you should take it up with tromp | 16:25 |
| -!- folksngoats [~gues@193.138.219.233] has quit [Ping timeout: 264 seconds] | 16:25 | |
| gmaxwell | bramm: That kind of statement is also true about e.g. say the proposals that replace proof of work with timelock encryption ticking; or about the proposals related to efficient asymetrically verifyable disk storage... or proposals related to efficient relaying using network coding. | 16:25 |
| op_null | bramm: we have, in length. | 16:25 |
| gmaxwell | Tromp understand them. There just doesn't exist a clear paper arguing about memory hardness being useful or not. If it is, tromps work is interesting. | 16:26 |
| bramm | Is there any written proposal about time lock encryption ticking? | 16:26 |
| gmaxwell | (or well, more likely to be interesting that most other proposals. E.g. it doesn't have the trivial TMTO that most attempts have; I'm not sure if you missed it: But I believe I pointed out that your own proposal has a trivial time memory tradeoff) | 16:27 |
| bramm | what time memory tradeoff? To which of my two proposals? | 16:27 |
| gmaxwell | bramm: on timelock... A couple, one handy to me right now its that it's mentioned in passing on https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas (though a construction based on ideal lattices seems like it works better) | 16:28 |
| gmaxwell | bramm: in your first proposal say instead of computing a great many values to find a collision I just compute two, using ~no storage. and grind the outer function. This is a time memory tradeoff (in the other direction-- I abandon memory hardness but do more computation). There are in between values, for example, only remember values that begin with 0xdeadbeef. (distinguished points, to use the pollard-rho nomenclature) to get any ... | 16:31 |
| gmaxwell | ... degree of incremental memory usage that I want. Oh also, you can avoid the n*log(n) sort in that model too simply by using a hashtable and evicting (though ... in hardware I dunno if the muxing for random access is really cheaper than a structured sort) | 16:31 |
| -!- Myagui is now known as bilIotronic | 16:31 | |
| -!- folksngoats [~gues@se5x.mullvad.net] has joined #bitcoin-wizards | 16:32 | |
| -!- bilIotronic is now known as davidIatapie | 16:32 | |
| -!- davidIatapie is now known as Myagui | 16:32 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-aqmgiirqjkisxvte] has joined #bitcoin-wizards | 16:32 | |
| bramm | gmaxwell, I mentioned that tradeoff in my post, it results in n*n instead of n*log(n) computation, not exactly appealing | 16:32 |
| -!- Myagui is now known as MatyIda | 16:32 | |
| bramm | Also using a hash table like that is basically doing a sort, it's hiding the log(n) under the rug by assuming that it's a constant operation | 16:33 |
| -!- MatyIda is now known as Myagui | 16:33 | |
| bramm | And it's a disaster in practice because of all the random memory accesses | 16:33 |
| gmaxwell | bramm: a distinction there is that you only need to find one. so you may terminate early. But sure. | 16:34 |
| -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards | 16:34 | |
| bramm | When I post about these things publicly I generally get responses along the lines of 'Have you heard of script? It's awesome!' hence my dumb questions | 16:35 |
| gmaxwell | Yes, asytomptic difference between the fully memoized version and the memoryless is a sqrt(). But you suggest a 'modest constant', so the concrete difference in efficiency is something that can be evaluated. | 16:35 |
| bramm | Yeah going for a factor of 2 or 4 with memory/cpu tradeoff might work | 16:36 |
| -!- folksngoats [~gues@se5x.mullvad.net] has quit [Ping timeout: 244 seconds] | 16:36 | |
| bramm | gmaxwell, I'm not following the usage of the time lock you propose on your alt ideas. What utility is there in people making encryptions which can be decrypted at some fixed point in the future? Seems rather unrelated to proofs of work | 16:40 |
| -!- tdlfbx [~bsm117532@64.253.217.244] has joined #bitcoin-wizards | 16:40 | |
| gmaxwell | The other thing that memory hard functions run into that tromp's also suffers from is a lack of progress freeness. Though he thinks he's picked parmaters where they're okay. You observe something kind of close to this problem in your post with giving an upper limit. | 16:40 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 16:41 | |
| gmaxwell | (the main motivation when we talk about progress freeness is that an algorithim which has progress gives an advantage to faster participants over independantly operating ones, e.g. a centeralization advantage) | 16:42 |
| -!- folksngoats [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards | 16:43 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 16:43 | |
| bramm | Yes that is an issue. It has more to do with the usage of the function than the function itself though. | 16:44 |
| gmaxwell | right. | 16:44 |
| fenn | bramm: proof of work is measured in CPU/ASIC cycles which reduces to energy, but in timelock-POW the scarce resource is time (theoretically; i haven't read the timelock papers) | 16:45 |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer] | 16:45 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 16:45 | |
| bramm | fenn, I'm way ahead of you on this one :-) | 16:45 |
| zooko | bramm: why is your idea better than tromp's cuckoopow? Feel free to answer by link to previous writing. | 16:46 |
| zooko | bramm: and also, are you going to be patenting your thing? | 16:46 |
| gmaxwell | bramm: It has many utilities in the cryptocurrency space, e.g. avoiding miners censoring transactions by getting encrypted versions mined... the motivation there is dual-using the work without compromising (maybe) other useful pow properties, and doing so with something that can't be delivered otherwise... But more specifically related to consensus itself, with functioning timelock encryption you can do things like fairly elect ... | 16:46 |
| gmaxwell | ... participants. but the motivation there was the dual use. | 16:46 |
| bramm | zooko: I haven't read through cuckoopow, that may well be better (I'm expecting it is, only heard about it a few hours ago) | 16:47 |
| bramm | zooko, I'm not doing any patenting on this stuff | 16:47 |
| gmaxwell | fenn: well time is not a good material for consensus; relativity precludes the universality of time, as lamport first observed. :) | 16:47 |
| fenn | yeah i can't see how timelock could possibly work | 16:47 |
| op_null | have you looked at peter todds timelock? | 16:48 |
| gmaxwell | fenn: it's a computational ticking (you've seen the old rivest timelock puzzles paper?) | 16:48 |
| fenn | both already on my reading list, which is far too long | 16:48 |
| gmaxwell | fenn: in any case, since time is not really something universal, you can still impose universality onto it if you have a consensus.. e.g. instead of asking what time can do for consensus, ask what consensus can do for time; and you get this old writeup: http://people.xiph.org/~greg/decentralized-time.txt | 16:49 |
| -!- Dizzle [~Dizzle@12.130.116.6] has quit [Remote host closed the connection] | 16:50 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer] | 16:50 | |
| -!- Dizzle [~Dizzle@12.130.116.6] has joined #bitcoin-wizards | 16:50 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards | 16:50 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] | 16:50 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 16:50 | |
| zooko | bramm: why are you not-patenting any of this stuff? Is this a project you intend to profit from? | 16:51 |
| zooko | bramm: disclosure: I'm intending to profit from a cryptocurrency project right now. | 16:51 |
| zooko | I mean I'm right now intending. Not I'm intending to profit right now. ☺ | 16:51 |
| bramm | Somehow I don't think trying to extract value from a system designed to not be taken down by attacking it with patents would appear to be unlikely to work | 16:52 |
| bramm | gmaxwell, Having transactions be introduced encrypted is an interesting idea, but I think it can be done without time lock | 16:53 |
| zooko | *nod* | 16:53 |
| bramm | Sorry about the number of negatives in that last comment of mine | 16:53 |
| zooko | bramm: adam3us has proposed encrypted transactions to prevent miners from discriminating among them. | 16:53 |
| gmaxwell | bramm: you'd think. It's proven to be particularly resistant. Adam has written a fair amount (search term: comitted transactions). A problem arises where someone can't censor the _transaction_ but they can censor the key reveal, which is pretty much as good as censoring the transaction. Functional timelock encryption would solve that. | 16:54 |
| zooko | Another problem with it is that it doesn't prevent the recipient from discriminating among payment-histories. | 16:55 |
| bramm | Here's a paper which may be of interest: https://eprint.iacr.org/2011/553.pdf | 16:56 |
| tdlfbx | I've been thinking of using the blockchain as a clock source... | 16:56 |
| kanzure | bramm: here are some things you may be interested in http://diyhpl.us/~bryan/papers2/bitcoin/ and less relevant but whatever http://diyhpl.us/~bryan/papers2/security/ | 16:57 |
| tdlfbx | Just compare clocks upon any inta-node communication. Don't accept anything if the clock is too far off. This would incentivize everyone to agree on clocks. | 16:57 |
| tdlfbx | Randomize who revealize their clock first... | 16:57 |
| tdlfbx | e.g. via D-H secret % 21. | 16:57 |
| tdlfbx | err. D-H secret % 2. | 16:58 |
| -!- woah [~woah@75-101-111-82.dedicated.static.sonic.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 16:58 | |
| tdlfbx | *reveals. I'm going to go take a tiping class new. | 16:58 |
| bramm | bit coin already has significant interaction with clocks | 16:59 |
| op_null | not really. | 16:59 |
| bramm | Well, clock interactions are minimized, but they're there, specifically it won't accept transactions too far in the future | 17:00 |
| op_null | blocks, you mean. transactions don't have timestamps for obvious reasons. | 17:00 |
| tdlfbx | But it's very, very lenient. | 17:00 |
| -!- discreteunit [~discreteu@70.105.37.119] has quit [Read error: Connection reset by peer] | 17:00 | |
| bramm | Yes I meant blocks | 17:00 |
| tdlfbx | op_null: what are the "obvious reasons" for not putting timestamps on transactions? | 17:01 |
| gmaxwell | bramm: ah, wrt sequential functions you may find https://bitcointalk.org/index.php?topic=310323.0 interesting (the goal there is different but what it wants at its heart is a sequential function with trapdoor verification; the rivest timelock puzzles come up in that thread too) | 17:01 |
| op_null | tdlfbx: you can't prove anybody is telling the truth. what would you gain from it? | 17:01 |
| tdlfbx | You always compare to your own clock, and reject anything that is too far outside it. | 17:01 |
| op_null | if we had some way of proving transaction timestamps were right without trust, we could just forget the whole block chain entirely. | 17:01 |
| bramm | gmaxwell, Note that time lock puzzles and proofs of sequential work are rather different animals | 17:02 |
| op_null | tdlfbx: how would that help? that just means you can't sign transactions for some time in the future. | 17:03 |
| tdlfbx | Simply rejecting anything with an odd timestamp incentivizes nodes to figure out their clock bullshit, without specifying how they should achieve that. | 17:03 |
| op_null | it doesn't do that at all. | 17:03 |
| tdlfbx | Why not? There are lots of clock sources with different attack vectors. Including simply taking the average from communicating nodes. | 17:04 |
| op_null | why do I care if other people's transactions get rejected by my node? | 17:05 |
| tdlfbx | If you want your node to agree with the longest chain you care. | 17:05 |
| op_null | you're making a faulty assumption that all transactions are broadcast exactly when they are signed too. | 17:05 |
| op_null | what, you want transaction timestamps to be a validity rule too? | 17:05 |
| tdlfbx | They are, because if I don't receive them in a timely manner, I'd reject them. | 17:05 |
| tdlfbx | Yes. | 17:05 |
| op_null | ..no. | 17:05 |
| bramm | You always accept all transactions which are referenced by the root you accept | 17:06 |
| bramm | Any other policy would be insane | 17:06 |
| op_null | assuming that block is valid of course. you don't accept invalid transactions, that would make the block itself invalid. | 17:06 |
| -!- ryanxcharles [~ryanxchar@162.245.22.162] has quit [Ping timeout: 240 seconds] | 17:06 | |
| tdlfbx | bramm: within a window of communications latency. | 17:07 |
| gmaxwell | bramm: I know. just some related space there. Also in relation to sequential proof of work, are you aware of the compact spv proofs (appendix C of the sidechains whitepaper)? In it we show how to compress a proof of the total work in a blockchain to a proof log(blocks) size. This is also a kind of sequential proof of work (e.g. because the blocks themselves make progress they're inherently sequential). | 17:08 |
| bramm | I'm not sure what the policies are around what transactions miners accept. The sanest thing would be to accept everything currently valid | 17:08 |
| op_null | why is that sane? | 17:08 |
| tdlfbx | gmaxwell: I really like that part. | 17:09 |
| bramm | op_null, because you get to the commission on all of them :-) | 17:09 |
| tdlfbx | Anyone plan on implementing it in their coin | 17:09 |
| tdlfbx | ? | 17:09 |
| -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 240 seconds] | 17:09 | |
| gmaxwell | tdlfbx: it's just an additional commitment, like height in coinbase. Doesn't require a different system to implement, miners could be including it today in bitcoin. Fortunately the block headers are small enough that most applications don't care about the compression. | 17:10 |
| op_null | bramm: not all valid transactions pay fees. not all valid transactions pay enough fees for their size. you might not want to include any transactions at all. you might not want to include some because you find their content unfriendly. | 17:10 |
| bramm | op_null, fair enough | 17:10 |
| tdlfbx | Hence encrypted transactions. I worry a lot about this one too, especially as "bitcoin 2.0" implementations like counterparty, mastercoin come online, there is an incentive to omit transactions that bet against the house. | 17:11 |
| bramm | gmaxwell, hmm, yeah, might be that that trick applies to sequential work generally, I haven't read that part yet | 17:11 |
| op_null | tdlfbx: I think that's a positive thing. | 17:11 |
| tdlfbx | huh? If I'm the house, and I'm also mining, I would exclude transactions that bet in a way so as to decrease my profit. That's not a positive thing. | 17:12 |
| tdlfbx | Where "house" is doing bid-ask matching, for instance, or operating a derivatives market | 17:13 |
| op_null | my block my choice. if your system is that fragile you shouldn't have designed it that way. | 17:13 |
| bramm | gmaxwell, I think you meant appendix B, not appendix C | 17:14 |
| tdlfbx | Heh. You're speaking as a malfeasant derivatives market operator, and I'm speaking as a customer. Customers don't design such things. | 17:14 |
| op_null | I didn't say anything about the customer. | 17:16 |
| bramm | gmaxwell, And if I'm reading it right there's a remarkably similar thing sitting on my hard drive right now :-) | 17:16 |
| tdlfbx | So here's how to make money by omitting transactions: operate a derivatives market. Also bet on the same market. Exclude transactions which bet in the same direction as you. | 17:17 |
| tdlfbx | In bitcoin, a miner *can* choose to exclude transactions. | 17:17 |
| tdlfbx | And that's a critical part in enabling malfeasance. | 17:17 |
| op_null | why are you designing such a shitty system that relies on transactions being confirmed right away? if you make the assumption that all miners will include all transactions in every block you're going to be in a lot of pain. | 17:17 |
| bramm | Usually a transaction will just have to wait for a later miner to accept it if there's one miner who's trying to suppress it | 17:18 |
| tdlfbx | So include bid/ask offers in the blockchain, and wait for them to be confirmed? Might fix my concern...but god it's slow. | 17:19 |
| op_null | why on earth are you wanting to do orderbook stuff on the block chain!? | 17:19 |
| bramm | Yeah the block chain just has transactions in it. The utility of smart transactions is still highly questionable | 17:20 |
| bramm | The only smart transaction which makes any sense to me at all is currency exchanges | 17:20 |
| gmaxwell | bramm: oops yes. | 17:21 |
| gmaxwell | Got the order of them wrong. | 17:21 |
| op_null | bramm: what? | 17:22 |
| op_null | other than cross chain swaps it's totally unusable for that. | 17:23 |
| bramm | op_null, crypto currency exchanges :-) | 17:23 |
| op_null | it's even of limited use for that. | 17:23 |
| tdlfbx | op_null: so to avoid malfeasance by excluding transactions one has to include bid/ask offers in the blockchain, and have to confirm them. But you object to having them in the blockchain? Can't have it both ways. | 17:24 |
| op_null | you almost always end up in a state where one party or the other can stall, and use the delay to hedge against the counterparty. | 17:24 |
| bramm | gmaxwell, the question of an attacker using up everyone's peer connections is an interesting one. The best solution isn't to have a single way to accept connections, it's to reserve some number of connection slots to peers who do the best proof of work, some number who have the best IP match, some number who you've known the longest, etc. | 17:25 |
| op_null | tdlfbx: I really have no idea what you're talking about. | 17:25 |
| bramm | op_null, Yeah smart transactions suck | 17:25 |
| gmaxwell | bramm: yes. Oh I'm glad to hear you validate that. Thats also my prefered solution. Here is a snazzy criteria which I'm not sure you've considered: Lowest minimum rtt time. It's trivially measured and impossible to forge. | 17:26 |
| gmaxwell | (though it results in bad topology) | 17:26 |
| -!- rdponticelli [~quassel@gateway/tor-sasl/rdponticelli] has joined #bitcoin-wizards | 17:27 | |
| -!- folksngoats [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 250 seconds] | 17:27 | |
| op_null | bramm: I don't think I said that. | 17:27 |
| -!- Dizzle [~Dizzle@12.130.116.6] has quit [Remote host closed the connection] | 17:28 | |
| gmaxwell | in any case, that storage proof stuff actually came out of discussions about which grab-bag soup of connection options to use. E.g. if you're not in one of the freeby categories, maybe you'd be willing to burn some disk space. | 17:28 |
| -!- Dizzle [~Dizzle@12.130.116.6] has joined #bitcoin-wizards | 17:28 | |
| bramm | Bitcoin has very real problems: mining centralization, the block chain not scaling. It doesn't have problems with needing smart transactions. It doesn't really even have problems with transactions not going through fast enough | 17:28 |
| -!- AaronvanW [~ewout@255pc208.sshunet.nl] has quit [Ping timeout: 265 seconds] | 17:29 | |
| -!- folksngoats [~gues@cpe-66-68-60-163.austin.res.rr.com] has joined #bitcoin-wizards | 17:29 | |
| bramm | gmaxwell, Yes low ping time is the other one which I didn't remember off the top of my head | 17:29 |
| tdlfbx | bramm: have you read the sidechains paper? 2 days to bail in/bail out of a sidechain? I'd say that's not fast enough. | 17:29 |
| tdlfbx | op_null: I have not designed a market which I think works, using the blockchain. Just brainstorming. | 17:30 |
| gmaxwell | tdlfbx: hm? have _you_ read it? :P see appendix c. The primary method to move and out isn't the 2wp. | 17:30 |
| tdlfbx | Still waiting on the atomic implementation :-P | 17:30 |
| amiller | tdlfbx, that's an awful comment; it doesn't have anything to do with bitcoin, and it's not inherent to sidechains either | 17:31 |
| gmaxwell | No one really cares. (you can actually see there have been some swap transactions in the blockchain) | 17:31 |
| bramm | gmaxwell, The protocol should be that normally you accept all new incoming connections and delete and existing one if you're over limit, but peers have the option to become persistent with proofs of work if they're having trouble connecting | 17:31 |
| tdlfbx | @amiller 2 days is too slow is an awful comment? | 17:32 |
| bramm | side chains are not a core part of bit coin. In fact currently they aren't a part of bit coin at all | 17:32 |
| op_null | bramm: the problem is the sort of people who are going to be flooding you with connections have a lot more CPU power than you. this is the reason that hashcash failed to become a thing in the first place. | 17:33 |
| op_null | ie, legit people have less CPU power than the non-legit ones. | 17:33 |
| -!- folksngoats [~gues@cpe-66-68-60-163.austin.res.rr.com] has quit [Ping timeout: 250 seconds] | 17:33 | |
| bramm | op_null, that's why you also reserve spots for best IP matches, closest peers, and longest-known peers | 17:33 |
| op_null | IP match with what? | 17:34 |
| bramm | With yourself, you hash together the IPs of the end points | 17:34 |
| -!- folksngoats [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards | 17:34 | |
| op_null | I don't see what that gains you. | 17:34 |
| gmaxwell | tdlfbx: with respect to markets, you haven't seen the freimarkets paper? http://freico.in/docs/freimarkets-v0.0.1.pdf | 17:34 |
| op_null | a botnet operator who wants to flood you can just pair nodes who "match" and then assign them specific zombies. | 17:35 |
| bramm | That one has the nice property of producing very good interconnectedness. It also results in being resistant to attackers who don't have huge numbers of IP addresses. | 17:35 |
| gmaxwell | yes, it's annoying botnets actually have a lot of cpu power relative to honest ordinary nodes. That was part of the rational for storage there. | 17:35 |
| tdlfbx | @gmaxwell no. Thanks! Neat! | 17:35 |
| -!- Dizzle__ [~Dizzle@12.130.116.6] has joined #bitcoin-wizards | 17:35 | |
| * tdlfbx wonders why Counterparty gets all the press on this topic...and what's wrong with it. | 17:36 | |
| op_null | bramm: if you are a criminal you have no problem purchasing botnets with hundreds of thousands, maybe millions of exit points. you can't make the assumption that your opponent doesn't have nearly unlimited IP addresses. | 17:36 |
| bramm | op_null, that's why it's only one of several different techniques used | 17:36 |
| gmaxwell | op_null: the idea is that you carve up your capacity into varrious chunks, and so even if an attacker can optimize for one kind of chunk they can only monopolize that particular set of connections. | 17:36 |
| op_null | though really, Bitcoin vs. Botnet would end in 7500 hosts being flooded off the map. | 17:37 |
| op_null | sausage through the eye of a needle, and all that. | 17:37 |
| bramm | The Bitcoin peer protocol is not terribly well optimized for defending against botnets. We're talking about things it *could* do | 17:38 |
| -!- Dizzle [~Dizzle@12.130.116.6] has quit [Ping timeout: 255 seconds] | 17:38 | |
| gmaxwell | Indeed. thats part of why better inbound hurestics haven't been a high priority compared to the scalablity improvements needed to just encourage more nodes to run. :) | 17:38 |
| op_null | gmaxwell: yes, it's probably more optimal than what we currently use which is pretty dumb. | 17:38 |
| gmaxwell | op_null: hey now, what we currently use has some nice properties. | 17:38 |
| gmaxwell | It's very strong against short term attacks against already running nodes. So it's not totally dumb. | 17:39 |
| gmaxwell | You could do worse. e.g. doing nothing else but randomly evicing when new connections come in over the limit would be much worse. | 17:39 |
| -!- jb55_ [~jb55@208.98.200.98] has joined #bitcoin-wizards | 17:40 | |
| bramm | IP addresses are stronger than you might think - if even 10% of your connections are to legit peers, you're fine | 17:40 |
| op_null | gmaxwell: I don't see why a very small botnet couldn't exhaust all of the sockets on the network. requires almost zero bandwidth, requires people filling up their iptables ruleset with zombies, and is incredibly cheap. | 17:40 |
| bramm | A bonnet would have to crowd out legit peers to a ridiculous degree to be successful | 17:41 |
| bramm | botnet | 17:41 |
| gmaxwell | we only need a single connection to the honest network. | 17:41 |
| bramm | gmaxwell, You need at average of more than two connections for the network as a whole to function | 17:41 |
| gmaxwell | op_null: because once you're already up the botnet cannot evict your existing connections. They can give a hard time to newly starting nodes, indeed. | 17:41 |
| op_null | bramm: bitcoin peers have a reasonably high churn. as each node DCs it is replaced with a zombie socket. | 17:41 |
| gmaxwell | op_null: the nodes that count the most do not have high churn. | 17:42 |
| gmaxwell | (in particular it's important that miners not be partitioned from each other, and that merchants not be partitioned from miners) | 17:42 |
| -!- folksngoats [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 244 seconds] | 17:42 | |
| -!- Dizzle [~Dizzle@12.130.116.6] has joined #bitcoin-wizards | 17:42 | |
| gmaxwell | I am not defending the idea that we couldn't do much better, doing better has been on the long term roadmap for some time. Just pointing out that it could be much worse too. :) | 17:43 |
| op_null | gmaxwell: what version did the null vin bug get fixed? there's still a clear 10% of the network on 0.8.* | 17:43 |
| bramm | Do bit coin peers view age of the peers they're talking to based on IP address or public key? | 17:43 |
| gmaxwell | bramm: fair enough. | 17:43 |
| bramm | Sorry about saying 'bit coin' all the time, by the way, xchat keeps autocorrecting to that | 17:43 |
| -!- jb55 [~jb55@208.98.200.98] has quit [Ping timeout: 264 seconds] | 17:43 | |
| gmaxwell | bramm: there isn't really any age used at all in bitcoin. We never disconnect peers when our connections fill. So we're at least minimally robust against a working topology being made non-working by a short term attack. | 17:44 |
| -!- folksngoats [~gues@se5x.mullvad.net] has joined #bitcoin-wizards | 17:44 | |
| -!- jb55_ [~jb55@208.98.200.98] has quit [Ping timeout: 244 seconds] | 17:44 | |
| bramm | gmaxwell, If a peer goes down and comes back they don't get credit for being old and get to displace someone newer? | 17:45 |
| -!- Dizzle__ [~Dizzle@12.130.116.6] has quit [Ping timeout: 244 seconds] | 17:45 | |
| op_null | gmaxwell: if you want churn, a malicious actor with some sort of memory exhaustion nasty can cause that. if we assume everybody uses the defaults, there's a maximum of (6500*125) listening sockets on the network. if we assume maximums based on linux defaults we have (6500*1024) neither is huge. | 17:45 |
| gmaxwell | bramm: there is no keying or authentication at all in the p2p protocol. The system generally assumes any peer is malicious, and doesn't do any identity tracking with peers. (for better or worse) | 17:45 |
| bramm | Well that explains that | 17:45 |
| gmaxwell | op_null: this is why we fix memory exhaustion attacks. :) | 17:46 |
| gmaxwell | (more than any other reason, in fact!) | 17:46 |
| op_null | if you make a wild assumption and say that a botnet zombie can make 125 outgoing connections, you'd only need to match listening nodes with zombies to totally take up the whole listening ability of the network. | 17:46 |
| op_null | but yes, I realise that. | 17:48 |
| op_null | long lived connections are gold. private peering is gold. | 17:49 |
| gmaxwell | Yea, not sure what we're arguing about since I think we understand each other completely. | 17:49 |
| op_null | I don't think we're arguing | 17:49 |
| gmaxwell | oh okay. :) | 17:49 |
| op_null | if I was coming across like that, totally didn't mean t | 17:51 |
| -!- folksngoats [~gues@se5x.mullvad.net] has quit [Ping timeout: 240 seconds] | 17:53 | |
| bramm | gmaxwell, Trying to take a high level view of it, is it fair to say that the method of a coin getting released back from the side chain that there has to be a proof that an intention of release happened on the side chain followed by a certain amount of work in the side chain? | 17:55 |
| -!- folksngoats [~gues@se3x.mullvad.net] has joined #bitcoin-wizards | 17:55 | |
| gmaxwell | bramm: right. And the party that wants that coin released goes and gathers up that proof, and uses it as the signature of a bitcoin transaction. | 17:56 |
| -!- c0rw1n is now known as c0rw|sleep | 17:57 | |
| -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:350e:1093:a0ee:57ed] has joined #bitcoin-wizards | 17:57 | |
| bramm | And the assumption is that the parameters will be set properly when the coin is pegged that it will be impractical for an attacker to pull the transaction out without the benefit of the side chain's mining? | 17:58 |
| bramm | And if there are multiple transactions for releasing the coin back whichever valid one gets accepted into the bit coin block chain first wins? | 17:59 |
| bramm | What is the point of petty coin? | 18:00 |
| gmaxwell | bramm: That, and somewhat more. It's a little more elaborate: When you release the coin it isn't released directly. It's released into a holding state (a time locked transaction), if nothing more happens then it becomes available some time later. In the interm the holding state has a secondary exit condition, that you can abort the transfer if you show with more sidechain work that the chain didn't happen. | 18:00 |
| -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has joined #bitcoin-wizards | 18:01 | |
| -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has quit [Client Quit] | 18:01 | |
| bramm | gmaxwell, I see. It would be a lot easier to understand if this concept was explained up front in the paper | 18:01 |
| gmaxwell | And this works without changing the bitcoin consensus model. | 18:01 |
| bramm | Or rather, it would be more understandable to me if it were were explained this way up front, because from that explanation it's obvious to me how to fill in all the details. | 18:02 |
| gmaxwell | bramm: section 3.2 (see also the diagram). sorry, communication is hard. There are actually a lot of details, hitting the right level of abstraction is an art. | 18:03 |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:a531:7326:888e:3863] has quit [Ping timeout: 258 seconds] | 18:05 | |
| bramm | I will grant you that it is in fact a deterministic problem to decide what to accept, although it adds a lot of stuff to the acceptance process, and the side chains are very shackled to how bit coin does things | 18:06 |
| bramm | Also, the shortened proofs sketch me out. I've run numbers on those things, it takes a lot of samples to get a decent amount of assurance | 18:07 |
| gmaxwell | It does limit how the sidechain can express its willingless to allow a coin to move. And also potentially what constutites 'work'. In the most abstract sense, e.g. if script were upgraded to run arbitrarily complex programs... then the only real constraint on the external system is that it be "compactly transcript verifyable", e.g. that you can extract a compact transacript from it to prove it authorized something. | 18:08 |
| bramm | Running arbitrarily complex programs in verification scripts sketches me out | 18:09 |
| gmaxwell | As it should. | 18:09 |
| -!- OneFixt [~OneFixt@unaffiliated/onefixt] has joined #bitcoin-wizards | 18:10 | |
| op_null | bramm: you'll love Ethereum then. | 18:10 |
| gmaxwell | bramm: I'm not sure if the construction you're using is precisely the same. Ours doesn't require a fiat shamir transform to get a result that has the same expected work to forge as it shows. (though additional sampling or just limtiting how long the jumps it permits prevents you from 'getting lucky' with even low probablity) | 18:10 |
| bramm | op_null, see my earlier comments on the utility of smart transactions or lack thereof | 18:10 |
| op_null | Ethereum is scary for other reasons | 18:10 |
| bramm | gmaxwell, I have a construction with similar overall properties, it does a somewhat different thing for a somewhat different purpose | 18:11 |
| bramm | well, a very different thing for a very different purpose. It does a similar sampling trick though. | 18:11 |
| bramm | op_null, how do you find ethereal scary? | 18:12 |
| bramm | I mean, I don't particularly have confidence in the developers... | 18:12 |
| gmaxwell | bramm: smart contracts are more useful then you're likely giving them credit for... and also much less useful that 1001 enthusastic doofuses give them credit for. (uh, wtf, replacing internet services?!)... but the reality is that there are relatively few people interested in building production tools with them; not when centeralized services are so much easier to construct and have clear monetization models (e.g. get people to ... | 18:13 |
| gmaxwell | ... deposit lots of funds then get "hacked"). :) | 18:13 |
| op_null | bramm: writing consensus code in three languages simultaneously is essentially suicidal. the ones they chose are not ideal either. | 18:13 |
| bramm | gmaxwell, My point being, you need a lot of samples to get a reasonably high degree of confidence, basically you might as well include everything until your number of samples is well into the thousands. | 18:14 |
| bramm | op_null, Yikes! That's just bad engineering, ship your fucking product in a reference language to begin with, especially when there's crazy edge cases with how long scripts are allowed to run. | 18:15 |
| bramm | gmaxwell, Yeah, umm, the biggest problem with bit coin right now is that it scales so poorly that the only way it really works is for people to do their transactions in unregulated banks which claim to be backing their transactions in bit coins, which works about as well as unregulated banks have historically worked | 18:16 |
| bramm | Well, that and the lack of demonstration of valuable commerce besides speculation happening, but if you're working on the underlying technology you have to assume as a given that that will improve over time. | 18:17 |
| phantomcircuit | bramm, that's not exactly true | 18:17 |
| gmaxwell | bramm: have you seen their ... crazy thing about not wanting to have any CISC like macroscopic operations like for slow cryptographic functions? so instead they make it so you can call functions from any past transactions by hash, and then implementations would replace scripted implementations with native ones... but the native ones would use less of the consensus criticitical instruction cycle counter. ... god knows how they plan ... | 18:18 |
| gmaxwell | ... to verify to any level of assurance that the optimized functions are actually unconditionally identical. | 18:18 |
| kanzure | are spv clients unregulated banks now? | 18:19 |
| op_null | bramm: you'd think seeing bitcoin ruby would have put them off it, but who knows. | 18:19 |
| gmaxwell | bramm: thats not actually a material problem in the bitcoin ecosystem today. I agree its a potential issue in the future, but it's not the enviroment now. | 18:19 |
| gmaxwell | (people do use unregulated banks, but not due to scaling reasons) | 18:19 |
| gmaxwell | If someone has told you otherwise, they've misinformed you. | 18:20 |
| bramm | kanzure, I'm holding different conversations at once, if you mash them together my statements are going to be gibberish | 18:21 |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 18:21 | |
| -!- Dizzle [~Dizzle@12.130.116.6] has quit [Quit: Leaving...] | 18:21 | |
| gmaxwell | bramm: I think kanzure was pointing out that you can directly transact in bitcoin using a standard lite wallet (SPV) client, without using an unregulated bank-like entity. | 18:22 |
| gmaxwell | And that many many bitcoin users do so. | 18:22 |
| bramm | Oh god. Well, I'm going to cover my ears and go LALALALALA about ethereum development now. The main developer is like 20 years old. Unfortunately for him he's already accepted a bunch of money for ether, which is bad enough because there's a strong implication that he's now selling an unlicensed financial instrument if he's representing that it will have value in the future, and he's still vaporware with all this crap... | 18:22 |
| kanzure | nah, best to assume i'm just spitting out gibberish | 18:22 |
| kanzure | </snark> | 18:22 |
| bramm | Yes you can do lightweight transactions in bit coin, but this is basically a subsidized activity. If everybody did it the system would melt. | 18:23 |
| kanzure | you can use spv clients even if you are running a full client too | 18:23 |
| kanzure | so everyone can use spv safely | 18:23 |
| kanzure | i am not sure why you are pwlugging your ears about ethereum. your concerns seem to track everyone else's. | 18:24 |
| gmaxwell | bramm: I'm not sure why you think this. Yes, the security and incentives of the system depend on there being _many_ users of full nodes. But that doesn't make the use of spv clients subsidized in any substantial way. | 18:24 |
| bramm | I mean, it wouldn't take much for most of the peers currently running full nodes to fold under the load | 18:25 |
| Luke-Jr | gmaxwell: I assume he means SPV nodes rely on full nodes doing the verifications of blocks for them. It makes sense. | 18:25 |
| Luke-Jr | otoh, those full nodes do the same work basically either way | 18:25 |
| bramm | kanzure, Some people I know are somewhat around it, and I see it resulting in the developers winding up in jail | 18:25 |
| gmaxwell | bramm: yes, those concerns are concerns others have had too. :( sad. | 18:26 |
| bramm | Not that there's anything wrong with lightweight wallets | 18:26 |
| -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards | 18:26 | |
| op_null | bramm: you're not alone in thinking that by far. I'm in that boat, they contradict a lot of the "we are just selling fuel" arguments by making blog posts that include the phrase "price of ethereum" and "ethereum exchange rate" | 18:27 |
| gmaxwell | bramm: following along with the chain requires no more than 14kbit/sec per client maximum by the current protocol rules. There also isn't a trust requirement there, e.g. so single large nodes with lots of bandwidth could support large numbers of spv clients if required. | 18:27 |
| gmaxwell | It's also technically possible for spv clients to relay to each other, though no one bothers implementing this today. | 18:27 |
| bramm | gmaxwell, the problems come up when you increase the transaction rate by orders of magnitude (the current rate is kind of sad). Then the lightweight wallets keep working but the full nodes become alarmingly centralized. | 18:29 |
| gmaxwell | In any case, fair enough that you understand it... but no one today is being forced into using any banklike service on account of it. SPV clients work fine now, and have worked fine since they've existed. e.g. there haven't been any incidents where people had to stop using them. | 18:29 |
| gmaxwell | Sure, if the rules of the system were changed to unhinge the limits it might immediately become completely centeralized. | 18:29 |
| * gavinandresen groans at the “we’re doomed to centralization if we’re successful” argument | 18:29 | |
| -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 240 seconds] | 18:30 | |
| gmaxwell | (the current limits being sad is debatable, ... I mean, we currently can handle more daily volume than the bank of england does... :P but those are mostly disputes over which benchmark to use). | 18:30 |
| Luke-Jr | bramm: we can only speculate on what might happen when we begin hitting the current transaction rate limits | 18:30 |
| bramm | Also, just because something isn't an active scaling problem right now doesn't mean it isn't having an effect no what's going on right now. There might be SOME PEOPLE who have considered doing things and not done them to avoid causing huge problems | 18:31 |
| bramm | gavinandresen, I'm not portending doom, I'm discussing technical challenges | 18:31 |
| Luke-Jr | bramm: maybe those things are a bad idea? | 18:31 |
| Luke-Jr | especially if they don't need to do them.. | 18:31 |
| op_null | I don't think many people stop doing crappy things in order to save the network some trouble. look at how big satoshi dice was for a while. | 18:31 |
| gmaxwell | bramm: yes, sure, but I'm speaking to you with as much expirence in this space as anyone and I can assure you that that kind of sophicated thinking is not a major factor. | 18:31 |
| gmaxwell | it's been brutally hard to get people to consider things like that in the past. | 18:32 |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d1e0:6eae:20cb:e70c] has joined #bitcoin-wizards | 18:32 | |
| bramm | Well, it's been brutally hard to discuss it with the bad actors. The good actors you might never have heard about, because they were too polite | 18:32 |
| gmaxwell | bramm: there are additional scaling tools available that require no fundimental change to bitcoin that improve the scale vs decenteralization tradeoff. Though absent a demand most have not been developed yet beyond the initial ideas and requirements, e.g. fraud proofs for fractional validation https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs | 18:32 |
| -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-wizards | 18:33 | |
| bramm | kanzure, we had an acronym collision in the discussion a bit earlier | 18:33 |
| -!- mkarrer [~mkarrer@193.Red-79-155-137.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 18:33 | |
| * gmaxwell bbl | 18:35 | |
| bramm | Oh god, does satoshi dice use the hash of the root to decide who gets a coin? | 18:35 |
| op_null | no, they used a blinded nonce | 18:36 |
| -!- mkarrer_ [~mkarrer@193.Red-79-155-137.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 18:36 | |
| op_null | post a hash of the nonce, hash the incoming TX with the nonce, if it's above a target they win, after the day is over post the nonce list. something like that. | 18:36 |
| bramm | Still, it's an abuse of the expressiveness of the language for accepting coins | 18:37 |
| -!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has quit [] | 18:37 | |
| op_null | oh it was totally abusive. their transactions made up half the block chain at one point. | 18:38 |
| -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards | 18:38 | |
| op_null | 9940075 total satoshi dice transactions | 18:38 |
| gmaxwell | well, 'inefficient' ... the half wouldn't be a concern as much has the half of that half which consistented of nothing but 1e-8 "you lost" payments. | 18:38 |
| op_null | 4.1GB | 18:38 |
| bramm | Ouch | 18:39 |
| op_null | in july 2013 they made up 54% of the entire block chain size. | 18:39 |
| gmaxwell | but its more complicated than it seems; e.g. their transaction volume ended immediately when they were no longer a publically traded asset. | 18:39 |
| op_null | uh | 18:39 |
| gmaxwell | So I personally think its likely likely that most of the activity was just manufactored to pump the valuation of their 'cryptostock' (by whom is anyone's guess). | 18:40 |
| op_null | I might have to write some scripts to see if I can identify that sort of action. their behaviour is so obvious and the volumes so high that it would be hard to obscure something like that. | 18:40 |
| kanzure | how would you "agree" on "the appropriate number of full nodes" on the network anyway? re: scalability. someone has to have the full blockchain... at least one person. and idealy not just one person. | 18:40 |
| gmaxwell | bramm: yea, it's still exploitable, though. since you just look to see if you'd lose and selectively double spend. It also doesn't prove what many people have thought it proved. E.g. the operator was free to play himself and pick the outcome. Which would be especially bad news for 'shareholders', since if the site ran lucky funds could be embezzled via preselected. | 18:41 |
| gmaxwell | kanzure: hm? no one technically needs to have the whole thing. | 18:41 |
| kanzure | are you sure | 18:41 |
| -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds] | 18:41 | |
| kanzure | like what if i want to see all transactions anyway | 18:41 |
| bramm | gmaxwell, It *could* be implemented properly, although it would still be a stupid thing | 18:41 |
| gmaxwell | kanzure: too bad? system works fine even if you can't. :) | 18:41 |
| gmaxwell | bramm: yep. | 18:41 |
| -!- wallet421 [~wallet42@f052161246.adsl.alicedsl.de] has joined #bitcoin-wizards | 18:42 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Killed (barjavel.freenode.net (Nickname regained by services))] | 18:42 | |
| -!- wallet421 is now known as wallet42 | 18:42 | |
| kanzure | gmaxwell: i'm out at dinner with andytoshi and he said the exact same thing [3~ | 18:42 |
| kanzure | andytoshi and i believe that you are a long-range telepath | 18:42 |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-aqmgiirqjkisxvte] has quit [Quit: Connection closed for inactivity] | 18:43 | |
| gmaxwell | kanzure: absent recursive snarks (which make everything nicely O(1) if their security holds), you still only need to witness the history to build a current state for forward evaluation. That doesn't require that any one person have the whole thing, e.g. you can go gather it from many hosts and build your state and forget it. | 18:43 |
| bramm | kanzure, it would always be better to have less bandwidth necessary to keep up/start and be able to run a partial rather than full node | 18:43 |
| phantomcircuit | gmaxwell, i hadn't actually thought of the site operator gaming the system | 18:43 |
| phantomcircuit | that's interesting | 18:43 |
| kanzure | bramm: so in your ideal environment, nobody would have the entire blockchain? who would have parts of it? | 18:43 |
| gmaxwell | kanzure: and once you have a state, see the fraud proofs writeup I gave... it's possible to just trust updates to the state, and randomly verify them... such that so long as you're not partitioned from honest hosts you will learn of any misbehavior with arbritary confidence. | 18:44 |
| kanzure | s/environmet/insert correct word here | 18:44 |
| op_null | phantomcircuit: it's been done. some of the "dice" sites did it really badly and got caught incrementing nonces in funny ways to avoid winning ones. | 18:44 |
| bramm | kanzure, People would have as much of it as they could reasonably handle | 18:44 |
| kanzure | isn't that how it already works | 18:44 |
| gmaxwell | kanzure: not really because the pruning knob isn't exposed to users, and we have no p2p facility for gattering a blockchain from sparse peers. But it will, it's the design... | 18:45 |
| gmaxwell | e.g. no consensus changes needed for that. | 18:45 |
| bramm | gmaxwell, I'm not sure that it can be done quite right, I need to read through your comments on proofs which can be done to have an opinion | 18:46 |
| gmaxwell | To not have to even few whole blocks at the tip requires fraud proofs, which need a few additional commitments. (or an interactive protocol with your peers) | 18:46 |
| bramm | Obviously building a new block chain from scratch it could be done very well | 18:46 |
| bramm | (for some definitions of 'obvious' :-) ) | 18:46 |
| phantomcircuit | gmaxwell, i think you accidentally a word there | 18:47 |
| gmaxwell | bramm: I mean some of this was considered in the original design of bitcoin. E.g. section 7 explains why you need not store everything, section 8 on spv clients points out "prompting the user's software to download the full block and alerted transactions to | 18:47 |
| gmaxwell | confirm the inconsistency" but that isn't actually efficient in bitcoin as it is today, not without additional comittments in the blocks. | 18:48 |
| zooko | gmaxwell: I like your idea of selecting peers by short rtt. | 18:48 |
| zooko | What's wrong with the topology is clumpiness, right? | 18:48 |
| zooko | Or something else? | 18:48 |
| gmaxwell | zooko: well it can't be used exclusively, as it results in degenerate topology. | 18:48 |
| gmaxwell | yea, it is really prone to partition. | 18:48 |
| gmaxwell | e.g. if you take the n lowest rtt... well as soon as you have >threshold peers in north america they helpfully partition themselves from europe completely. :P | 18:49 |
| bramm | The nearest neighbor heuristic isn't nearly as bad for a DHT because a DHT has leaves which ensure non-clumpiness | 18:49 |
| gmaxwell | but it's a fine thing to do for some subset of your connections, so long as there isn't a feedback loop. | 18:50 |
| -!- instagibbs [6c1c1eb9@gateway/web/freenode/ip.108.28.30.185] has quit [Quit: Page closed] | 18:50 | |
| gmaxwell | e.g. the probablity that you accept a connection for your {most favororite netblock} slots cannot be proportional to {also connected to my RTT prefered hosts}. | 18:51 |
| gmaxwell | Actually being sure that no such feedback loops exist is one reason I've not run headlong into implementing this stuff. | 18:51 |
| bramm | gmaxwell, Better to keep it simple and only reserve a set number of slots for near RTTs | 18:51 |
| bramm | gmaxwell, section 7 of what? | 18:51 |
| gmaxwell | there are some very nice poisoning attacks for address rumoring systems with limited state where an attacker can exponentially boost their concentration of slots. | 18:52 |
| gmaxwell | bramm: the bitcoin whitepaper https://bitcoin.org/bitcoin.pdf | 18:52 |
| gmaxwell | We've implemented state pruning in bitcoin core-- and you can happily run a node with a gig of space--, but its not exposed yet; in part because we haven't yet done the p2p support for gathering up the blockchain from a network where not every full node has the full chain. | 18:53 |
| bramm | gmaxwell, Yes of course merkle trees should be used. It would be preferable if their hashes were in the actual transaction log so you could catch up from a point not at the very beginning of time based on them. | 18:53 |
| gmaxwell | bramm: hm? you can start in the middle. SPV clients do. | 18:54 |
| bramm | Then how do they know what the state was at the point they start? | 18:55 |
| tromp_ | faith in the accumulated pow difficulty since | 18:55 |
| gmaxwell | A SPV client is only concerned about its own wallet(s), so they start syncing from the point where their wallet was created, and they know they had no transactions before they existed. | 18:55 |
| bramm | Oh I see. Still it has limitations where it actually has to sync from that point instead of being able to sleep for a while and then wake up and catch up quick | 18:56 |
| gmaxwell | They do pull older headers, but they're 80 bytes each, so whoptie do... they need them for total work comparisons, compact proofs could be used in theory but it hardly seems worth it since ten years of headers is only 40 megs. | 18:56 |
| op_null | doing an SPV sync is ridiculously fast. | 18:57 |
| * gmaxwell actually goes to dinner now | 18:57 | |
| op_null | "catching up" isn't really a problem in any sense, even with remote peers. | 18:57 |
| op_null | it's a massive *privacy* problem, but not a speed one. | 18:57 |
| bramm | In any case, everything is better if headers include references to hash roots of merkles trees of the current state | 18:58 |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection] | 18:59 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Remote host closed the connection] | 19:02 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 19:04 | |
| bramm | tromp_, I meant the state of their wallet, not the hash root | 19:05 |
| tromp_ | yes, i realized that after gmaxwell correct answer | 19:06 |
| bramm | tromp_, I'm trying to read through your cuckoo docs now but I've been too busy chatting on irc | 19:07 |
| tromp_ | yes' i figured you might have reached the end of the abstract by now | 19:08 |
| bramm | It's good to have found the place where there's coherent discussion of block chain engineering. The discussion in most forums is utter drivel. | 19:10 |
| tromp_ | your proposal is very similar to Momentum, where they require a full collision H(A)=H(B), with an additional difficulty constraint on H(A,B) | 19:10 |
| tromp_ | that version can be seen as a special case of Cuckoo Cycle | 19:11 |
| bramm | I basically suggested making it 4sum instead of 2sum to lower CPU load. Other than that what I suggested is not very clever. | 19:12 |
| bramm | I'd be very curious to hear commentary on what operations require almost as much power on ASICs as on CPUs. | 19:13 |
| bramm | tromp_, gmaxwell was showing... skepticism that requiring requiring more memory is better than more CPU on the grounds that ASIC miners spend more on power than on CPU | 19:15 |
| bramm | than on hardware I mean | 19:15 |
| tromp_ | i'd like to see the numbers on that. how long do you have to run the most efficient ASIC miner to have spent as much on power as on hardware? | 19:18 |
| op_null | not long. | 19:19 |
| tromp_ | has anyone written down such a calculation? | 19:19 |
| op_null | SP20 is 1.3TH/s at 1152W. costs 795 USD. | 19:19 |
| bramm | op_null, how much time is that? | 19:20 |
| bramm | And how many general purpose CPUs is it equivalent to? | 19:20 |
| op_null | pretend 20 US cents / kw/h. so $5.5296 a day. | 19:21 |
| bramm | Equivalent to how many CPUs? At what marginal cost to produce each one? | 19:22 |
| op_null | so 143 days for the power costs to exceed the capital cost for that miner. | 19:22 |
| bramm | I've been told the cost of designing an ASIC is around $1 million | 19:22 |
| op_null | depends a lot on the CPU and the workload. | 19:22 |
| op_null | depends a lot on the ASIC and the design. | 19:22 |
| tromp_ | 143 days is on the order of hardware depreciation time | 19:22 |
| fenn | dumb question, why do bitcoin ASICs depreciate? | 19:23 |
| bramm | Yeah that doesn't look like there's a clear winner | 19:23 |
| bramm | fenn, moore's law | 19:23 |
| op_null | a core i7 4770 has a TDP of 95W, but it's probably more like 200W with minimum accessories. | 19:23 |
| tromp_ | fenn, try making money with 1-year-old asics... | 19:23 |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection] | 19:24 | |
| tromp_ | they're pretty much obsolete in terms of hash/watt | 19:24 |
| op_null | bitfury stuff isn't that far behind. | 19:24 |
| fenn | is it because smaller transistors use less power? | 19:24 |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 19:24 | |
| tromp_ | yes, that's the major reason | 19:25 |
| op_null | partly. process size isn't everything. | 19:25 |
| bramm | fenn, yes the two things which are still dropping are power needed to do an operation and time to fetch stuff from memory | 19:25 |
| bramm | clock speed has basically stopped improving | 19:25 |
| op_null | KNCminer has a 20nm process ASIC that's woefully higher power than the 50nm Bitfury | 19:25 |
| op_null | bramm: ASIC miners for Bitcoin don't have memory. | 19:26 |
| tromp_ | reduced leak current in better processes is another reason | 19:26 |
| bramm | op_null, true but if they did cuckoo they would | 19:26 |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake] | 19:26 | |
| tromp_ | then they'd incur a 50ns hit when switching rows in a memory bank | 19:27 |
| op_null | bramm: I can't say anything about an ASIC that doesn't exist and hadn't been designed. | 19:27 |
| tromp_ | assuming use of commodity DRAM | 19:28 |
| bramm | presumably ASIC DRAM would depreciate similarly to commodity DRAM | 19:30 |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 19:30 | |
| tromp_ | there's no such thing as high capacity affordable custom DRAM | 19:30 |
| bramm | tromp_ Why is that? | 19:31 |
| -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has quit [Ping timeout: 272 seconds] | 19:31 | |
| tromp_ | there's billions of technology investment in the current DRAM markets | 19:32 |
| bramm | The same can be said for CPUs but you can make an ASIC which can beat those at specific tasks for a million | 19:32 |
| tromp_ | because the ASIC is orders of magnitude more efficient | 19:33 |
| bramm | Not sure what you mean. What's different between DRAM and aspics? | 19:34 |
| tromp_ | but if you spend millions to develop a custom DRAM and they're only 10x more efficient but cost 100x more due to lacking economies of scale... | 19:34 |
| tromp_ | then they're still not cost effective | 19:34 |
| -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has joined #bitcoin-wizards | 19:34 | |
| tromp_ | with a memory hard pow, dram costs dominate the mining | 19:35 |
| -!- op_null [~op_null@178.62.133.216] has quit [Quit: leaving] | 19:35 | |
| tromp_ | so you need not only be more efficient than commodity dram, but also price competitive | 19:36 |
| tromp_ | that may require on the order of a billion $ to develop | 19:37 |
| -!- Flyer9933 [~f@unaffiliated/fluffybunny] has joined #bitcoin-wizards | 19:37 | |
| -!- Flyer33 [~f@unaffiliated/fluffybunny] has quit [Ping timeout: 256 seconds] | 19:39 | |
| tromp_ | i don't know of any ASICs developed with more than a few MB | 19:39 |
| tromp_ | cuckoo can also scale to require multiple memory chips, so that you cannot embed all computing logic within one chip | 19:41 |
| bramm | A person who knows ASICs told me that you can put memory on them. I should ask him for more color on that. | 19:41 |
| tromp_ | yes, you an. scrypt asics have on the order of 1MB on them | 19:42 |
| tromp_ | but cuckoo requires at least 2 orders of magnitude more, for each single instance | 19:42 |
| -!- Flyer33 [~f@unaffiliated/fluffybunny] has joined #bitcoin-wizards | 19:43 | |
| tromp_ | the point of cuckoo is that it (appears to) reduce to just doing random memory accesses | 19:44 |
| -!- Flyer9933 [~f@unaffiliated/fluffybunny] has quit [Ping timeout: 256 seconds] | 19:44 | |
| tromp_ | with almost all computation just being cheap hashes to make the memory accesses random | 19:44 |
| -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards | 19:44 | |
| -!- coiner [~linker@118.69.162.103] has quit [Ping timeout: 245 seconds] | 19:45 | |
| tromp_ | so if you can do that vastly more efficiently with some custom ram, then you may have just improved a large class of applications | 19:46 |
| bramm | To my mind if you're going to make a proof of work rely on memory, it should be a reasonable amount of memory, like 1 gig or 10 gigs | 19:46 |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 19:46 | |
| tromp_ | i planned to, but cuckoo takes a lot of time on 1GB | 19:47 |
| bramm | Define 'a lot of time' | 19:47 |
| tromp_ | each attempt taking a few dozen seconds | 19:47 |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] | 19:47 | |
| fenn | our future robot overlords are laughing at 1GB being "a lot of memory" | 19:48 |
| bramm | That's an interesting thing to work into engineering, but hardly a disaster | 19:48 |
| bramm | As long as verification is fast... | 19:48 |
| tromp_ | cuckoo can scale in memory size dynamically | 19:48 |
| tromp_ | but 10GB is currently only feasible if your block interval is like an hour or mor | 19:49 |
| tromp_ | the single attempt time has to be significantly less than block interval time | 19:49 |
| bramm | Maybe you could give a bonus to amount of work based on how much memory it used | 19:49 |
| tromp_ | to have some semblance of progress freeness | 19:50 |
| bramm | Not clear how that function should scale though | 19:50 |
| tromp_ | yes, bramm, the paper proposed that | 19:50 |
| bramm | log(n) might be appropriate | 19:50 |
| tromp_ | in the style of myriad coin | 19:50 |
| -!- c0rw|sle_ [~c0rw1n@129.66-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 19:50 | |
| bramm | What function does myriad coin use? | 19:51 |
| tromp_ | i only proposed a constant number of sizes | 19:51 |
| tromp_ | it has 5 different pows, each with its own independent difficulty | 19:51 |
| tromp_ | so if one powe gets used more heavily, it will becomes more difficult to copensate | 19:51 |
| tromp_ | in the end each pow should end up with freq 20% | 19:51 |
| -!- c0rw|sleep [~c0rw1n@102.79-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 258 seconds] | 19:53 | |
| bramm | I'll have to digest that later, right now just trying to get what the basic pow is | 19:53 |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-hmtycgolpgaohezp] has joined #bitcoin-wizards | 19:53 | |
| bramm | By 'takes an hour' does that mean always takes an hour, or takes on average an hour with equal likelihood at any given moment of finishing? | 19:54 |
| tromp_ | pretty much always (for fixed hardware) | 19:54 |
| tromp_ | if you find a solution, it will always come near the end of the attempt | 19:54 |
| tromp_ | well, 1 hr for the hypothetical block interval. the single attempt time could be something like 5 mins | 19:55 |
| bramm | Trying to parse through the paper now. If I understand correctly, you're looking for circular chains? | 19:58 |
| tromp_ | they're called cycles:) | 19:58 |
| tromp_ | a standard notion in graph theory | 19:58 |
| bramm | And how many edges are there? Is it, like, half of all possible ones, or does each node have roughly a constant number, or what? | 19:58 |
| tromp_ | there are half as many edges as nodes | 19:59 |
| tromp_ | e.g. 2^32 nodes, 2^31 edges | 19:59 |
| tromp_ | each node has expected degree 1 | 19:59 |
| tromp_ | this makes the expected number of cycles constant | 20:00 |
| bramm | And that's an exact value, enforced by making edges using a PRF seeded with the challenge? | 20:00 |
| tromp_ | yes, number of nodes and edges is exact | 20:00 |
| bramm | When you say 2^32 nodes, do you mean that many nodes in the whole graph or only one half of the bipartite graph? | 20:00 |
| tromp_ | in whole graph | 20:00 |
| bramm | Are you looking for a fixed size cycle or is bigger better? Is there an exponential drop off in the chances of there being a cycle of a given length? | 20:02 |
| tromp_ | fixed size | 20:02 |
| tromp_ | yes, there's a plot of distribution of cycle lenghts | 20:02 |
| bramm | What is the fixed size? Is it related to the amount of nodes? | 20:02 |
| tromp_ | i propose 42 | 20:02 |
| tromp_ | but it's up to the pow implementor really | 20:03 |
| -!- MoALTz_ [~no@user-164-126-106-206.play-internet.pl] has joined #bitcoin-wizards | 20:03 | |
| tromp_ | i argue why it should be over 10 | 20:03 |
| tromp_ | maybe i'll llet you read the whole paper:) | 20:03 |
| bramm | Is the expected length of the largest cycle logarithmic on the number of nodes? | 20:03 |
| bramm | Getting answers from you is very helpful for context. I have a lot of trouble reading math notation. | 20:04 |
| tromp_ | i don't know, but it could well be something like that | 20:04 |
| tromp_ | with sizes around 2^30, the largest cycles i see is several thousand | 20:05 |
| tromp_ | so it seems more than logarithmic | 20:05 |
| tromp_ | but maybe its log^2 or something... | 20:06 |
| -!- rdponticelli [~quassel@gateway/tor-sasl/rdponticelli] has quit [Ping timeout: 250 seconds] | 20:06 | |
| -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has quit [Remote host closed the connection] | 20:06 | |
| -!- MoALTz [~no@user-164-126-106-206.play-internet.pl] has quit [Ping timeout: 255 seconds] | 20:06 | |
| tromp_ | well, to see several thousand you'd need to try many graphs... | 20:06 |
| bramm | Interesting. It isn't at all obvious to me what the best algorithm is for this, so I'll have to digest the paper | 20:07 |
| tromp_ | i would think that largest size is log(N)^Theta(1) | 20:07 |
| bramm | Those large numbers would seem to imply that there are outliers, so you can't just credit someone with more work if they find a longer graph | 20:07 |
| bramm | longer cycle I mean | 20:08 |
| -!- DoctorBTC [~DoctorBTC@unaffiliated/doctorbtc] has quit [Ping timeout: 272 seconds] | 20:08 | |
| tromp_ | cycle length must be fixed before the attempt | 20:08 |
| tromp_ | for each graph only one size will be accepted | 20:08 |
| tromp_ | this gives a few % of probability of success | 20:09 |
| tromp_ | the paper doesn't consider using multiple cycle lengths in one PoW | 20:10 |
| -!- DoctorBTC [~DoctorBTC@unaffiliated/doctorbtc] has joined #bitcoin-wizards | 20:10 | |
| tromp_ | i don't see a use for that | 20:10 |
| zooko | I'm currently planning to use cuckoo PoW | 20:13 |
| zooko | . | 20:13 |
| bramm | So it seems like best use for this is to have a fixed cycle length based on the amount of memory and have the 'value' of the pow be how many zeros its hash ends in | 20:13 |
| tromp_ | the difficulty is controlled by a 256bit target | 20:14 |
| tromp_ | where the 42 nonces must hash to something less than the target | 20:15 |
| bramm | Yes that's what I meant | 20:15 |
| tromp_ | so you have some finer resolution than just #zeroes | 20:15 |
| zooko | I had a conversation with nwilcox and amiller about it at a Hack Fest at my house last week, and I came up with a more specific argument for why I want a stronger PRF than SipHash-with-attacker-chosen-key. | 20:16 |
| tromp_ | but you were right if you considered fractional number of zeroes:) | 20:16 |
| tromp_ | what was the argument, zooko? | 20:16 |
| -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Ping timeout: 272 seconds] | 20:17 | |
| gmaxwell | "< bramm> tromp_, gmaxwell was showing... skepticism " yes, I just don't think it's resolved. I don't know. The initial argument to promote memory hard functions is the scrypt paper, and analysis is clearly lacking because it focused only on mfgr costs. Colin Percival agreed with my opinion that it was short in that respect; but he said he didn't know how to estimate energy usage. Well, sadly, I don't really either except on ... | 20:17 |
| gmaxwell | ... materialalized designs... and the initial results of ltc scrypt vs sha256 don't bode well for the memory hard camp, but its easy to dismiss the ltc scrypt numbers as 'not memory hard enough'. | 20:17 |
| -!- coiner [~linker@113.161.87.238] has joined #bitcoin-wizards | 20:17 | |
| -!- Dizzle [~Dizzle@12.130.116.11] has joined #bitcoin-wizards | 20:17 | |
| zooko | tromp: It is that there is a class of attacks which are prevented by the random graph being random. | 20:18 |
| zooko | And if I understand correctly, the randomness of it is enforced by the hash function being a good PRF in the attacker's hands. | 20:18 |
| bramm | gmaxwell, Yeah script is hobbled by being a password hashing function rather than a proof of work function so the amount of memory it can require is fairly small | 20:19 |
| -!- nubbins` [~leel@stjhnf0157w-047055221135.dhcp-dynamic.FibreOp.nl.bellaliant.net] has joined #bitcoin-wizards | 20:19 | |
| -!- nubbins` [~leel@stjhnf0157w-047055221135.dhcp-dynamic.FibreOp.nl.bellaliant.net] has quit [Changing host] | 20:19 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards | 20:19 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection] | 20:19 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 20:20 | |
| zooko | tromp: When you and I last talked about this, you pointed out that real hash functions, e.g. BLAKE2, emit too much output, and there isn't a good way to use all of that output. | 20:20 |
| zooko | But I later thought "Wait, that's no problem, just truncate." | 20:21 |
| tromp_ | zooko, the graph is still only pseudo random even with a blake2 hash | 20:21 |
| zooko | Um, I don't think we're talking the same language yet. | 20:21 |
| -!- DoctorBTC [~DoctorBTC@unaffiliated/doctorbtc] has quit [Ping timeout: 272 seconds] | 20:21 | |
| zooko | "pseudo random" is not a word in my lexicon. :-) | 20:21 |
| tromp_ | cuckoo aims to limit computation relative to memory accesses | 20:21 |
| bramm | Would using a cryptographic hash function dramatically increase the amount of CPU needed or is it not a major factor? | 20:21 |
| zooko | So, what I mean is, there are conceivable ways to break cuckoo, if you can choose your own graph structure. | 20:21 |
| zooko | I think the security of cuckoo is much improved by the attacker not being able to choose that. | 20:22 |
| tromp_ | you cannot choose your own graph structure with siphash | 20:22 |
| zooko | And I think SipHash was not designed to prevent that. | 20:22 |
| zooko | It may indeed prevent it, but it hasn't been analyzed by cryptographers with an eye to whether it prevents it. | 20:22 |
| -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has joined #bitcoin-wizards | 20:22 | |
| bramm | Getting a handle on the size of this, I guess the size of a pow is the length of the seed, plus the lengths of specifying all of the nodes in the cycle, which is 42 times what? | 20:22 |
| zooko | Contrasted with secure hash functions, which have. | 20:23 |
| tromp_ | there's no conceivable attack on siphash that lets you find large cycles in graphs on a billion nodes any easier | 20:23 |
| zooko | That's not the sort of argument that cryptographers like. | 20:23 |
| bramm | True, cycle finding is itself a form of cryptographic hashing | 20:23 |
| tromp_ | i know | 20:23 |
| tromp_ | it's a "gut" argument:( | 20:24 |
| zooko | Cryptographers like the sort of argument that "any algorithm which would crack cuckoo would have to violate the pseudorandom property of the underlying hash function". | 20:24 |
| gmaxwell | wrt miner power, e.g. Bitmain S3 is $199 retail for 453GH/s, and 355W at the wall. so energy and price are equal at $117. Though this is distorted a bit by markup. On actual cost the numbers are much lower, and on parts sold in a competative marketplace (e.g. gpus) you see numbers in 30-60 days range. In any case, the operating costs are considerable. So there are a couple of interesting avenues that come out of this: e.g. ... | 20:24 |
| tromp_ | yes, proof size would be 42*4 = 168 bytes | 20:24 |
| gmaxwell | ... centeralization advantages for amortized hardware; improvements in density (right now sha256 parts are largely thermally limited). I'd like to see more study in this area; otoh POW functions are some of the least interesting / superficial elements of these systems. | 20:24 |
| -!- DoctorBTC [~DoctorBTC@unaffiliated/doctorbtc] has joined #bitcoin-wizards | 20:24 | |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 250 seconds] | 20:24 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d1e0:6eae:20cb:e70c] has quit [Ping timeout: 258 seconds] | 20:24 | |
| bramm | I guess if there are 2^32 nodes, that's 31 bits for each one because you have the bonus from it being bipartite? Minus a few more for compression cleverness? | 20:25 |
| tromp_ | more if the graph size exceeds 2^33 | 20:25 |
| zooko | The top-tier secure hash functions have been studied rather intensively by the symmetric-crypto crowd, because of the SHA-3 process, and any measurable deviation from random got published as a result for other cryptographers to study. | 20:25 |
| zooko | That hasn't been done for SipHash. | 20:25 |
| zooko | And in fact the remaining top tier ones, e.g. the SHA-3 finalists, are only the ones for which no deviation from random could be found, even in reduced-round subsets. | 20:26 |
| bramm | zooko, the kinds of attacks you worry about in the design of cryptographic hash functions simply don't apply in this case | 20:26 |
| zooko | bramm: We don't know that you can't break cuckoo PoW by manipulating the graph structure. | 20:26 |
| tromp_ | zooko, you can attack individual edges in a graph that has a billion | 20:26 |
| bramm | tromp_, As a memory-lookup-saving measure, in addition to filtering out the nodes of degree one, couldn't you optimize out nodes of degree 2? | 20:27 |
| zooko | Or otherwise taking advantage of some pattern or malleability of the hash function. | 20:27 |
| gmaxwell | I like to point out that MD5 would be a fine pow... but I'm less clear on that argument in the case of the interior hash in the cuckoo cycle. Optimization freeness is important, and it may be that there is some interesting bias that can give you an exploitable optimization. | 20:27 |
| bramm | zooko, The existence or not of cycles is itself a form of cryptographically secure hashing | 20:27 |
| tromp_ | bramm, nodes of degree 2 can be part of the cycle | 20:27 |
| zooko | gmaxwell: Yeah, I'm concerned that SipHash has not been analyzed for the security properties that Cuckoo seems to need. | 20:28 |
| bramm | tromp_, right but you can switch to making edges have length | 20:28 |
| gmaxwell | zooko: hey, it's cryptocurrency, and particularly non-bitcoin cryptocurrency I'm pretty sure that means that you're free from any expectation to evaluate the security of your construction. | 20:28 |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 20:28 | |
| gmaxwell | :-/ | 20:28 |
| zooko | gmaxwell: And also I think that BLAKE2 would be acceptably efficient as a replacement for SipHash in Cuckoo, and it has been so studied. | 20:29 |
| tromp_ | zooko: if it makes you happier, you can consider Cuckoo being parametrized on internal hash functoin, and substitute your own:) | 20:29 |
| bramm | The only security property cuckoo needs is that you didn't manually put a cycle in there | 20:29 |
| -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has quit [Ping timeout: 256 seconds] | 20:29 | |
| zooko | tromp: thanks! That does make me happier, and indeed what I was planning to do, but I want to suggest it to you, both to get other people who hear about it from your publications to study it, and in order to warn you that it may be a real problem. | 20:29 |
| bramm | That said, it *might* be the case that even shoving in a cryptographic hash function doesn't make it CPU bound anyway | 20:29 |
| tromp_ | bramm: i really want edges to havbe length 1 | 20:29 |
| gmaxwell | tromp_: but is it that simple, I mean, if you put a much slower internal hash function your progress freeness suffers. | 20:29 |
| zooko | bramm: We don't know that there aren't other ways to break cuckoo than that way. | 20:30 |
| bramm | tromp_, but it might save you half your memory lookups to allow edges to have length 2 or more and optimize out the edges of degree 2 as a first pass and put them back in at the end | 20:30 |
| zooko | bramm: It definitely doesn't. BLAKE2 instead of SipHash-2-4 would probably only double the CPU cycle count. | 20:30 |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds] | 20:30 | |
| tromp_ | yes, gmaxwell, it would clearly affect many cuckoo properties | 20:30 |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 20:30 | |
| zooko | gmaxwell: if that turns out to be a problem then we'll probably used a reduced-round BLAKE2. | 20:31 |
| -!- Dizzle [~Dizzle@12.130.116.11] has quit [Quit: landing] | 20:31 | |
| gmaxwell | zooko: IIRC with the parameters tromp_ was talking about it was already somewhat edging on progress freeness problems. | 20:31 |
| tromp_ | i doubt it, zooko, considering blake2 has to output 256 bits?! | 20:31 |
| gmaxwell | But I'm not sure how to 'measure' sufficient progress freenewss, which makes a decision other than 'very progress free' harder to justify. | 20:31 |
| zooko | tromp: no, just truncate the output. | 20:32 |
| bramm | zooko, the problem which cuckoo is based on is based much more directly on a fundamental problem in computer science than the core of secure hash functions | 20:32 |
| bramm | zooko, or use one output to define multiple edges :-P | 20:32 |
| zooko | gmaxwell: hm, I had thought I could measure it by whether the concrete performance is "sufficiently" less than the block latency... | 20:32 |
| tromp_ | but you still need to compute many more (internal) bits, zooko | 20:32 |
| bramm | And why do you want to use blake2 instead of sha3? | 20:32 |
| zooko | bramm: yeah, tromp and I talked about that multiple-edges thing a bit, but I couldn't see a nice clean way to do it. | 20:32 |
| zooko | That would be great, actually. | 20:32 |
| zooko | bramm: I liked BLAKE more than I liked Keccak, so I collaborated on the definition of BLAKE2. | 20:33 |
| zooko | Relevant to this usage, it is faster than Keccak in CPU. | 20:33 |
| gmaxwell | bramm: thats a bit handwaving. You don't have to break the normal graph thoretic properties to have a very bad day as a proof of work. (e.g. an attacker discovering they can approximate your work function and get a substantial constant factor speedup, may not tell you anything about cockoo graphs ... but it can ruin your security) | 20:33 |
| zooko | Here is my rationale for BLAKE2: https://blake2.net/acns/slides.html | 20:33 |
| zooko | Also relevant to this usage, BLAKE was studied a bit better than Keccak was studied in the SHA-3 process. | 20:34 |
| tromp_ | zooko, if you implement blake2 with 64bit ops, how many such ops do you need? | 20:34 |
| zooko | gmaxwell: Now you're talking. :-) | 20:34 |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake] | 20:34 | |
| bramm | To define an edge you need 64 bits (well 62 but whatever) so 256 bits can define 4 edges straightforwardly | 20:34 |
| zooko | tromp: you mean in CPU? | 20:34 |
| * zooko looks at http://bench.cr.yp.to/results-hash.html | 20:34 | |
| tromp_ | bramm, that's a very bad approach, as i explained to zook o before | 20:34 |
| bramm | Presumably if you reduce the rounds of blake2 enough its security properties and cpu usage look a lot like sip except that it has a lot more bits of internal state | 20:35 |
| zooko | I think it takes about 350 cpu cycles to run BLAKE2s on a 64-bit CPU. | 20:35 |
| zooko | On a small input, I mean, less than one block. | 20:35 |
| zooko | bramm: Yes, that's true. | 20:36 |
| zooko | SipHash might be fine. :-/ | 20:36 |
| -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 20:36 | |
| tromp_ | i even considered using siphash12 instead of siphash24 :) | 20:36 |
| zooko | *nod* | 20:36 |
| tromp_ | it didnt affect the cycle length distribution | 20:36 |
| zooko | I think it takes something like 140 CPU cycles to run SipHash-2-4. | 20:36 |
| zooko | tromp, can you confirm that? | 20:36 |
| bramm | tromp_, do you mean the multiple edges in an output thing is a bad idea or optimizing out edges of degree 2 is a bad idea? | 20:37 |
| zooko | bramm: I suggested the same thing, BLAKE2 is generating 256 bits of output, and an edge needs only 64, so generate 4 edges. | 20:37 |
| tromp_ | using a 256 bit hash output to define 4 edges is a bad idea, bramm | 20:37 |
| bramm | gmaxwell, The problem cuckoo is based on really is a coherent understandable problem. The problems which the core of cryptographically secure hash functions are based on amount to 'looks like it mashes it up real good and we haven't been able to break it' | 20:37 |
| tromp_ | because in the edge trimming phase you end up only using one of the 4 | 20:38 |
| -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 20:38 | |
| zooko | tromp: I don't understand that, now. | 20:38 |
| bramm | Do you have to recalculate edges later, or are they all done up front? | 20:38 |
| tromp_ | did you read the section on edge trimming, zooko? | 20:38 |
| -!- maaku is now known as Guest100 | 20:38 | |
| zooko | I'll go look at the current draft now ... | 20:39 |
| tromp_ | it processes only the "alive" nonces, which becomes sparser and sparser | 20:39 |
| zooko | Is this the right link? https://github.com/tromp/cuckoo/blob/master/cuckoo.pdf?raw=true | 20:39 |
| gmaxwell | zooko: '"sufficiently" less than the block latency' I agree but I do not know how to quantify 'sufficiently', except in very broad numbers. E.g. functions whos execution is a small fraction of the latency skew between nodes on the network would be hard to argue as potentially problematic. (if they were, then latency between network nodes would be more problematic). Is 1 second okay against a 10 minute block? against a 10 minute ... | 20:39 |
| tromp_ | bramm, you generate edges many tims | 20:39 |
| gmaxwell | ... block a very fast centeralized party could have a .16% advantage (e.g. if it took them no time to prove, and everyone else 1 second). Is that okay? I dunno. | 20:39 |
| tromp_ | bramm but in later rounds, you generate smaller and smaller subets | 20:40 |
| zooko | gmaxwell: Hm. | 20:41 |
| tromp_ | gmaxwell, i thought 10s attempts in a 10min block time was quite ok | 20:41 |
| tromp_ | which is already several % | 20:41 |
| gmaxwell | bramm: You can keep repeating that, but the repetition won't enlighten me. The security/incentives considerations are much simpler than the 'underlying problem' (e.g. you do not and are not likely to find a strong reduction argument that the security and economics of the cuckoo work function in application as a proof of work reduce to any well studied problem) | 20:42 |
| tromp_ | so that's a price you have to pay with cuckoo | 20:42 |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 272 seconds] | 20:42 | |
| gmaxwell | it's quite easy to construct POW functions based on well studied things which would be weak in practice, and people have done so many times on the forum. | 20:42 |
| zooko | tromp: I really fail to understand this: | 20:42 |
| zooko | “Next, for all alive edges, compute its even endpoint and increase the corre- | 20:42 |
| zooko | sponding counter, capping the value at 2. Next, for all alive edges, compute its even endpoint and if | 20:42 |
| zooko | the corresponding counter is less than 2, set the edge to be not-alive.” | 20:42 |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:43 | |
| -!- folksngoats [~gues@se3x.mullvad.net] has quit [Ping timeout: 272 seconds] | 20:43 | |
| tromp_ | zooko: i'm identifying leaf nodes among the current set of live edges | 20:43 |
| tromp_ | so i compute degrees, and check for degrees equal to 1 | 20:44 |
| gmaxwell | E.g. there was one proposal that was to generate randomized boolean satisfiability... arguing that it was 'secure' because 3-sat is NP-complete. But ... most sat problem instances are not hard, and you could simply grind the instance generator until you got a problem that a hurestic solver could immediately answer. | 20:44 |
| tromp_ | "less than 2" ight be confusing since it will be at least 1:( | 20:44 |
| -!- folksngoats [~gues@se5x.mullvad.net] has joined #bitcoin-wizards | 20:44 | |
| zooko | tromp: ah | 20:46 |
| tromp_ | bramm: i dont understand what you meant with "optimizing out edges of degree 2" | 20:47 |
| zooko | gmaxwell: it reminds me of the tradition of insecure public key cryptosystems based on classic hard problems. | 20:47 |
| bramm | gmaxwell, As someone who's a bit of an expert in boolean satisfiability, I can tell you that random satisfiability is an absolutely horrible problem, but clique and related (for example, cycle finding) are quite good | 20:47 |
| bramm | tromp_, I think I need to digest the core algorithm before I know if I'm talking sense on that one | 20:47 |
| zooko | What classic problem is cuckoo most like, and how does it differ? | 20:47 |
| tromp_ | my intuition (and experience as a theoretical computer scientist) agrees with bramm's | 20:47 |
| bramm | Trust us, we're scientists :-) | 20:48 |
| gmaxwell | Funny, because thats not what you sound like here. | 20:48 |
| bramm | It's funny how little crossover there is between programmers and theoretical computer scientists | 20:48 |
| bramm | gmaxwell, that's because you're judging based on your prejudices of how you expect scientists to talk | 20:49 |
| -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit] | 20:49 | |
| tromp_ | if i don't sound like one, it's because i cannot prove any security properties of cuckoo | 20:49 |
| gmaxwell | Because how tidy a particular problem is ... is more or less uncorrelated with the security of a particular algorithim based on it in a particular enviroment. Especially when the notion of security hinges heavily on economic arguments and can be broken throughly by small constant factor considerations. | 20:49 |
| bramm | gmaxwell, certain problems tend to have similar average case and worst case runtimes, clique-like things are most definitely one of those | 20:50 |
| bramm | Also there are ways of avoiding fixing the constants by allowing several different ones and counting them as different amounts of work | 20:51 |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 20:51 | |
| tromp_ | i only want to do that with graph size | 20:51 |
| tromp_ | see section on dynamic sizing | 20:51 |
| gmaxwell | bramm: No, actually I'm saying that based on your continued disregard for the substantial expertise built up over years by people expirenced in this space; and by your arguments which form a pattern similar to that used to justify many broken cryptographic security arguments in the past. | 20:51 |
| bramm | gmaxwell, I'm not disregarding anyone's expertise, I just hadn't had a conversation with anyone who could tell me about the current state of the art of any of this stuff until today | 20:52 |
| bramm | Its not like I haven't made multiple posts about my thoughts asking for input. I've gotten diddly for response | 20:53 |
| gmaxwell | Saying cycle finding is a good problem is one thing; that does not actually end the discussion for it making a good POW in practice. Maybe it does, maybe it doesn't; you can build a good POW out of tasks that aren't 'good' too. | 20:53 |
| gmaxwell | bramm: well the only post I saw of yours about cryptocurrency stuff prior to today was a remarkably poorly researched "vulnerability" in bitcoin that didn't exist; and which would have been quickly pointed out to you on bitcoin talk though you dismiss it as being full of fools. :) | 20:54 |
| -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has joined #bitcoin-wizards | 20:55 | |
| zooko | Something that would be great for ending certain discussions would be a reduction (also known as a security proof) showing that if you can crack cuckoo then you can use the cuckoo-cracker to find cycles in random graphs. | 20:55 |
| bramm | gmaxwell, In that post I directly say that it might already be in there, I was posting it mostly as part of my process analyzing such things and to explain the reasoning behind it to people who don't know. Nothing I said in that post is wrong | 20:55 |
| phantomcircuit | gmaxwell, being fair, it *is* full of fools | 20:55 |
| gmaxwell | zooko: well reduction arguments ... also have known limitations. I'm not really sure that one would help here (though it would be nice to have) | 20:55 |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 20:55 | |
| tromp_ | zooko, it would also be great if you could prove that any amount of memory was needed to solve cuckoo with any particular efficiency. but i dont expect we'll ever be able to prove such tthings | 20:56 |
| bramm | gmaxwell, You are far more knowledgeable and sensible that the vast majority of people I've spoken to who claim to be bit coin experts (and are really fanboys) although you can be a bit of a jerk :-P | 20:56 |
| -!- nubbins` [~leel@stjhnf0157w-047055221135.dhcp-dynamic.FibreOp.nl.bellaliant.net] has joined #bitcoin-wizards | 20:56 | |
| -!- nubbins` [~leel@stjhnf0157w-047055221135.dhcp-dynamic.FibreOp.nl.bellaliant.net] has quit [Changing host] | 20:56 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards | 20:56 | |
| gmaxwell | bramm: Your post wasted about a hour of my time in aggregate dealing with people who were concerned about the 'flaw' you found in bitcoin. So, no offsense, but I think I'll reach my own conclusions about how wrong your post was. | 20:56 |
| gmaxwell | Sorry if I've been too rude. uh. I had the notion in my head that you were not likely to take offense. I'll take more care. I do not wish to offend you. | 20:57 |
| tromp_ | cuckoo is the sort of pow that can at best get a reputation of hardness from prolonged widespread use and failure to find big efficiency gains | 20:57 |
| bramm | gmaxwell, Sorry about that, I thought saying that the problem might already be fixed in the very first sentence and giving exactly the trivial fix which is already in there at the end and explaining just how easy it would be to stop the attack if it wasn't already fixed in the body of the post would stop people from flying off half-cocked | 20:58 |
| tromp_ | somewhat like crypto primiteves gaining a reputation of being secure | 20:58 |
| gmaxwell | tromp_: Well I'm not sure if there is really a better approach than that. But it's not great, in that no one is required to publish their optimizations. | 20:59 |
| gmaxwell | There exist non-trivial unpublished optimizations to bitcoin's work function. | 20:59 |
| tromp_ | yes, just like no one is required to publish their RSA and SHA256 breaks:) | 20:59 |
| bramm | gmaxwell, I don't take offense easily, but a few times I've had to check myself from getting mad at you | 20:59 |
| bramm | If you ask people in crypto they're actually much more skeeved by RSA than lots of other things | 21:00 |
| bramm | Mostly because its encoding issues are such a nightmare | 21:00 |
| -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Client Quit] | 21:01 | |
| gmaxwell | bramm: ha. sorry, I'll turn it down a notch then. I'm certantly glad to have you around here in any case... and indeed most bitcoin "experts" are really just enthusiasts... one of the downsides of how surprisingly accessible the basics of the technology here are. | 21:01 |
| gmaxwell | You mean to suggest someone might create a vulnerability in their RSA padding scheme?!? | 21:01 |
| tromp_ | gmaxwell: it seems that for a pow to get some notion of provable security, it has to be related to random oracles such as scrypt did | 21:01 |
| phantomcircuit | gmaxwell, ha | 21:02 |
| bramm | But yes, it would be nice to have a reduction for the PoW in cuckoo, but there are some good theoretical reasons to trust max-clique, I'll dig some up now | 21:02 |
| zooko | One thing that I think is under-appreciated about security reductions is that they can be valuable *components* of a larger picture. | 21:02 |
| gmaxwell | tromp_: academic cryptographers don't give RO enough love these days. A statement about POW security on the RO model is interesting. | 21:02 |
| gmaxwell | (regardless of what academic cryptographers think) | 21:03 |
| zooko | I think that the phrase "provable security" contributes to overlooking that, by implicitly focusing on the idea that you can prove the whole thing. | 21:03 |
| bramm | gmaxwell, I'm guessing you're being sarcastic about RSA padding. That high order byte freaking sucks. | 21:03 |
| zooko | For example, I'd like to understand more precisely what relationship there is, if any, between a well-studied problem like cycle-finding in random graphs, and cuckoo. | 21:03 |
| bramm | What are you using RO as an acronym for? | 21:03 |
| -!- op_null [~op_null@178.62.133.216] has joined #bitcoin-wizards | 21:03 | |
| gmaxwell | zooko: yea, really the words "provable security" should be banned. it's almost a joke how many systems with security proofs are vunerable, ... usually because to get a security proof something stupid needs to be done that makes the proof wrong or worthless... but taken as what they are worth and no more they can be useful. | 21:04 |
| tromp_ | random oracle | 21:04 |
| bramm | zooko, all that cuckoo is doing is finding cycles in random graphs | 21:04 |
| zooko | bramm: So, inasmuch as that is true, then we ought to be able to write a reduction (don't call it a "security proof") in which we take as input a cuckoo-pow-cracker, and we emit as output a cycle-finder-in-random-graphs. | 21:05 |
| zooko | But I don't think it is precisely true. | 21:05 |
| zooko | For starters, with that thing that I have been bugging tromp about for a while now, that cuckoo's graphs are not necessarily random. | 21:05 |
| phantomcircuit | gmaxwell, the security of most crypto systems of course being based on things which are believed to be difficult, but for which nobody has actually proven them to be difficult | 21:05 |
| op_null | gmaxwell: by "unpublished" do you mean some people know about them, or that they have made it into hardware? I'm not interested in what they are as you're obviously not shouting them out. | 21:05 |
| gmaxwell | bramm: yes.. But really bad crypto is easy, even in a nice cofactor-1 EC group like ours; see e.g. the first 'message encryption' thing electrum had. It didn't quite manage to leak the secret key, but decryption acted as an oracle to decrypt other messages... and there were even some messages which its encryption process would corrupt without detection even absent an attacker. | 21:06 |
| zooko | So, if I have a cuckoo-pow-cracker that works by exploiting patterns in siphash, then you can't use that to find cycles in random graphs, therefore there can be no such security reduction as the one I wished for above. | 21:06 |
| bramm | zooko, not quite, no, but the algorithms for finding cliques are remarkably weak - there's a trivial approach, and then it hits a hard impassable wall which there simply aren't any optimizations on | 21:06 |
| zooko | So now we have to expand our security reduction a little, and say, okay here's a machine that eats cuckoo-pow-crackers and shits out *either* cycle-finders-in-random-graphs *or* siphash-pattern-finders. | 21:07 |
| zooko | See how security reductions can actually be useful tools for cognition and argument? | 21:07 |
| zooko | Not that I've ever actually written one. | 21:07 |
| gmaxwell | op_null: Sometimes I'm not clear on what I came up with, and what someone told to me, and what someone told to me in confidence... so the only safe thing to do is not comment. As I don't want to discourage people from telling me things by blabbing about them. But yes, there are optimizations which some people know about which AFAICT are not widely publically known. I dunno if any hardware is actually using them yet. | 21:07 |
| zooko | Before I get too tired, let me just throw out the specific angle of attack that I came up with in my kitchen with Nathan Wilcox and amiller last week... | 21:08 |
| bramm | zooko, that may be doable. My intuition boils down to saying that the patterns found in sip hash would have to be extraordinarily powerful, far beyond the security sip hash is assumed to have | 21:09 |
| bramm | Although I don't know how one would do any such reduction, for the same reasons that cycle finding is hard, unfortunately | 21:09 |
| op_null | gmaxwell: thanks, that's literally all I wanted to know. | 21:09 |
| zooko | I've refrained from mentioning it until now, because I wanted to focus on the general class of possible issues, and I didn't want my *general* objection to be overlooked if this *particular* | 21:10 |
| zooko | angle of attack doesn't pan out. | 21:10 |
| zooko | So, my vague general idea is: I'm going to figure out how to generate candidate graphs in cuckoo which are related to one another in such a way that my work on one of them can benefit me on the next one. | 21:11 |
| zooko | Possibly sequentially, violating progress-free-ness, or possibly in parallel, allowing me to get > O(N) cuckoo-pow-work out of O(N) RAM. | 21:11 |
| gmaxwell | zooko: but see, even that much isn't enough for security in a POW context. Say you can run one operation of the cuckoo finder and with 0.1% precision if you will find a solution 100x earlier than normal. Such a black box would not break your normal reduction arguments, but it would allow you to grind insances of the problem and get a speedup. | 21:12 |
| zooko | For example, if I generate many graphs which share some common subgraphs, then when I do the pruning, or other work, on that common subgraph, that might help me make progress on all the graphs. | 21:12 |
| -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has quit [Ping timeout: 255 seconds] | 21:12 | |
| zooko | gmaxwell: um, doesn't that just mean the tightness of the reduction matters in practice for us? | 21:13 |
| bramm | zooko, that wouldn't really help you, even being able to recalculate on half the edges in advance wouldn't speed things up all that much | 21:14 |
| zooko | Well, it has been a very nice evening of -wizards. Thanks. Must sleep now. Took melatonin pill an hour ago and it is kicking in. | 21:14 |
| tromp_ | identifying common subgraphs is more work than just looking for the cycle:( | 21:14 |
| -!- folksngoats [~gues@se5x.mullvad.net] has quit [Ping timeout: 256 seconds] | 21:14 | |
| tromp_ | unless the cycle is the common subgraph?! | 21:14 |
| gmaxwell | zooko: well normally you ignore constant factors and it may be only a constant factor difference, but a constant factor can all you need to make it so only the person knowing the optimization can mine economically. | 21:14 |
| zooko | No, no, silly, not *identifying* common subgraphs. | 21:14 |
| zooko | Generating ... | 21:14 |
| zooko | Assume, counterfactually, for a moment, that cuckoo-pow lets you pick any graph you want for your "random" graph. | 21:15 |
| zooko | Then, you would just pick one that had a cycle in it that you knew to look for, right? | 21:15 |
| zooko | Okay, that was useless. Let me try agian. | 21:15 |
| gmaxwell | A more concrete example of that ... There was a memory hard POW that I broke (the first one from the proshares people) which had some large 128MB state that it filled and updated as it ran. But I observed that it only very rarely read the updated states during its execution. The initilization could be completed in parallel... so it was trivial to make an approximation of it that was just as fast and used no memory at all.. but it ... | 21:16 |
| gmaxwell | ... was wrong about 1% of the time. You could have had a nice security reduction saying there was no way to compute the function without the state or whatever.. and yet for POW purposes it was fine to substitute it with an approximation. | 21:16 |
| -!- folksngoats [~gues@se3x.mullvad.net] has joined #bitcoin-wizards | 21:16 | |
| zooko | Assume that you can generate graphs with certain control over them, but not enough cont5ol to just force a specific cycle. | 21:16 |
| gmaxwell | sorry for the overlapping conversation. | 21:16 |
| zooko | But, let's say you can for example | 21:16 |
| bramm | zooko, the problem is that there are zillions of chains of length 21 everywhere, but their structure is so complicated that they can't be summarized, and only one is likely to lead to a cycle of length 42 | 21:16 |
| zooko | have *compression* between many graphs, because of their common structure. | 21:16 |
| zooko | You can then use your RAM to perform many cuckoo-pow's in parallel, effectively re-using the same RAM to work on multiple graphs at once, because of the inter-graph compression. | 21:17 |
| zooko | sleep is taking me... | 21:17 |
| bramm | Yeah, like i said, unlikely to help | 21:17 |
| zooko | gmaxwell: what you said sounded super relevant and interesting but I was reading the other converastion and now I'm too tured. | 21:17 |
| gmaxwell | zooko: we'll talk later. | 21:18 |
| tromp_ | it's getting too late for me too | 21:18 |
| op_null | gmaxwell: wish I had the resources to decap chips. I'd love to be able to get some pictures of all the different died, from the huge 110nm asicminer chips to the tiny tiny spondoolies ones. | 21:18 |
| tromp_ | g'night folks | 21:18 |
| amiller | gmaxwell, failing to account for approximations is a sign of a shitty pow formalism.. | 21:18 |
| op_null | actually decapping them probably isn't the problem, that's acid and heat. getting decent pictures of the silicon would be the bit I can't do with any level of quality. | 21:19 |
| bramm | Night Tromp... wait, are you in the USA now? | 21:19 |
| tromp_ | yes, since 2007 | 21:19 |
| bramm | Ah, I didn't know that | 21:19 |
| zooko | sweet come over to my house. | 21:19 |
| tromp_ | if i'm ever in the neighbourhood... | 21:20 |
| amiller | nick szabo has a really nice essay in favor of more precise reductions than "polynomial time", i think the only reason that's not in common is that the general equivalence of "reasonable" computing machines is that coarse, hence anything more precise has to be tuned to a particular computing systems like circuits or turing machines | 21:20 |
| andytoshi | today may have been the most productive and complete discussion of pow we've had ever had here in one go | 21:20 |
| amiller | which is actually really relevant to pow, because we are interested in preventing asics given some kinds of assumptions about the design space of those | 21:20 |
| -!- folksngoats [~gues@se3x.mullvad.net] has quit [Ping timeout: 255 seconds] | 21:20 | |
| bramm | amiller, the polynomial hierarchy has been studied, but particular exponents are of course nowhere near as robust a class as polytime itself | 21:21 |
| bramm | andytoshi, Yeah is seems like the conversation actually got somewhere | 21:21 |
| kanzure | op_null: there's a few people doing chip decapping in this community's fringes | 21:22 |
| amiller | bramm, well, welcome :) dunno what took you so long to get here | 21:22 |
| kanzure | op_null: a few people have open offers if you send them chips and some peroxide they will happily run it under a SEM for you | 21:22 |
| -!- folksngoats [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards | 21:22 | |
| bramm | amiller, I wasn't working on anything related | 21:22 |
| andytoshi | bramm: a big part of it was that when things got heated everyone acknowledged and calmed down .. it doesn't happen too often, but tempers flare up here and sometimes it's just a shitshow | 21:22 |
| andytoshi | oh and let me add my voice to the "welcome"s | 21:22 |
| kanzure | op_null: http://siliconpr0n.org/archive/doku.php?id=digshadow | 21:23 |
| op_null | kanzure: heh, sending nitric acid in the mail seems like a good way to have people knocking on my door and telling me kindly to stop | 21:23 |
| gmaxwell | amiller: sure, and then you run into e.g. DJB's rant that the quantum collisions finding algorithims are not really any faster than the clasical ones. (they claim to be faster but they're not counting hardware parallelism or communications costs)... All algorithims that complete within the life of the universe are O(1) if your computing devices are extra universes. :P | 21:23 |
| op_null | kanzure: ooo. | 21:23 |
| bramm | I tend to avoid working on things where no clear promises can be made: like, I move data from point A to point B because you can strongly say that the data was in fact moved, but I don't like claiming that a secret has been kept or data is stored because those are such fuzzy promises into the indefinite future | 21:23 |
| bramm | Likewise I view claiming that a bit coin is worth something as a completely ludicrous claim to make, but I do believe that bit coin can strongly make the claim that a particular transaction has been executed in an extremely distributed database without a double spend, so I find that an interesting problem to work on | 21:25 |
| op_null | kanzure: I'm pretty tempted to remove a few from the end of a bitfury chain and see if anybody wants to decap them for me. I only have a couple of types though sadly. asicminer, gridseed and bitfury/antminer (same thing). | 21:25 |
| kanzure | instead of promising data storage you can offer locked/microchannel-style funds for correct data transmission in the future or something (i agree that it is hard or wrong to try to prove data storage) | 21:25 |
| bramm | But you'll never hear me cheering increases in the value of a crypto currency or freaking out about its value falling, because I don't view that as important or interesting | 21:26 |
| andytoshi | i'm not sure anyone here can justify bitcoin's value, but i think the double-spend protection depends on it ;) | 21:26 |
| -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has quit [Ping timeout: 250 seconds] | 21:26 | |
| andytoshi | because the idea is that the "real" history is the only one whose coins have value | 21:26 |
| kanzure | op_null: email me with a short proposal and i can send it along (kanzure@gmail.com) | 21:26 |
| bramm | andytoshi, you mean bit coin's value depends on not having double spending, yes that's most definitely true | 21:26 |
| andytoshi | bramm: hmmm, i meant its not having double-spending depends on its value, otherwise there is no incentive for miners to agree on a canonical history | 21:27 |
| bramm | Avoiding double spending is in fact the only claim which bit coin's core actually claims to make | 21:27 |
| andytoshi | but yeah, there is an opposite implication. weird | 21:27 |
| op_null | kanzure: I'll have a shot with someone locally first, if they can't I'll shoot you an email about it. | 21:27 |
| bramm | It does appear that a bit coin style system critically depends on having mining, unfortunately | 21:28 |
| phantomcircuit | bramm, i might have missed it, but do you have a different system to prevent double spends? | 21:28 |
| moa | it's not unfortunate it seems inevitable | 21:28 |
| andytoshi | yeah, seems that way.. | 21:28 |
| gmaxwell | bramm: nonthing in the bitcoin system assigns any value to the coins ... the users of it may (and, seemingly, do) but thats largely outside of the scope of the system itself. (and also an area I consider fairly boring, filled with hype and noise) | 21:29 |
| bramm | phantomcircuit, no I don't, at least not one which is as anywhere near as distributed and robust | 21:29 |
| bramm | gmaxwell, On that point we're in agreement | 21:29 |
| andytoshi | but fwiw there is no inherent reason that we have to use the thermodynamic limit (eg the stuff we do understand is totally compatible with memory-hard pow, which is using the universe's bandwidth limit) | 21:29 |
| andytoshi | i share skepticism on the economics, but don't have anything to add to what's been said there | 21:30 |
| moa | physics | 21:30 |
| gmaxwell | We normally direct people who want to talk about market prices to other channels; there are some cases where the fact that its considered valueable at all matters though; since it's somewhat essential to an economically motivated security argument. | 21:30 |
| -!- todaystomorrow [~me@d114-78-97-176.bla803.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds] | 21:30 | |
| phantomcircuit | gmaxwell, somewhat? :P | 21:30 |
| bramm | Yes but the attachment is very weak: If it was worth less then less work would be done | 21:31 |
| moa | it's that damned messy real world imposing reality all the time ... | 21:31 |
| gmaxwell | phantomcircuit: well you can still argue bitcoin is secure completely without value; if you argue it in a model where you take as an axiom that the majority of hashpower is 'honest' (conforms with the system's rules). | 21:32 |
| gmaxwell | now, how you'd justify that axiom is another question. But then again, lots of things happen that seem to have little justification beyond inertia. :P | 21:32 |
| phantomcircuit | heh | 21:32 |
| phantomcircuit | it would be interesting if the price drops sub $200 to see what happens | 21:33 |
| phantomcircuit | (that is ~ the break even point for most miners at $0.10/kWh) | 21:33 |
| bramm | Even if you have a majority of the hash power your potential attacks are fairly weak - basically you can retroactively reject transactions, but you can't change them | 21:33 |
| op_null | the latency in mining makes that harder to see the effects | 21:33 |
| bramm | That's my big ongoing beef with side chains - an attack with enough power can not only reject a release but redirect it, but that's a whole long discussion | 21:34 |
| op_null | ie, people might mine at a loss rather than breaking their operation down and just hoping for it to rise back up. a sudden increase in price has a high latency where you can't spin up more hardware easily. | 21:34 |
| gmaxwell | bramm: up to a limit, past 100 blocks reorged and you can make new coins yours and not other people's and that effectively replaces transactions. | 21:34 |
| bramm | gmaxwell, I don't view retroactively changing mining as a particularly meaningful attack | 21:34 |
| kanzure | you can change your own transactions | 21:34 |
| kanzure | (in deep reorgs) | 21:35 |
| gmaxwell | bramm: really? at the limit it changes the ownership of every single coin. | 21:35 |
| kanzure | (in deep reorgs that you generate) | 21:35 |
| op_null | phantomcircuit: where does your farm sit with regard to clocks? do you underclock, overclock, hardware dependant? | 21:35 |
| kanzure | (in deep reorgs that you generate that change transactions you sent earlier) | 21:35 |
| phantomcircuit | op_null, any hardware which can be overclocked is not properly spec'd | 21:35 |
| moa | how many full nodes on the network at any oone time? ... still around 7500? | 21:35 |
| bramm | Probably the strongest attack is that you could double-spend by spending a coin, undoing the transaction, and then re-spending it. You can't fraudulently change other peoples's transactions | 21:35 |
| kanzure | yes you can | 21:36 |
| kanzure | wtf man | 21:36 |
| gmaxwell | bramm: likewise SPV clients (which constitute the majority of end users wallets) will also happliy be lied to about you spending other people's coins, or coins that never existed. But indeed, it's not precisely the same security model as a plain full node (well ignoring the deep reorgs). | 21:36 |
| phantomcircuit | op_null, with a lot of systems underclocking allows for only slight improvements to efficiency | 21:36 |
| kanzure | you can totally mutate various transactions like crazy | 21:36 |
| kanzure | especially if you are interested in invalidating large trees of related transactions | 21:36 |
| -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has joined #bitcoin-wizards | 21:36 | |
| bramm | gmaxwell, I view changing transactions as a problem. People not getting the returns they hoped for on mining, for whatever reason, is their problem | 21:37 |
| op_null | phantomcircuit: I doubt you run any, but underclocking bitmain/bitfury hardware is deeply impressive. they seem to have run them pretty hard at stock, when you bring them down they run basically cold and at ridiculous efficiency. | 21:37 |
| bramm | kanzure, How can you do that without being able to forge signatures? Aside from being able to reject transactions I mean | 21:37 |
| gmaxwell | bramm: oh but its not those people I'm saying lose their coins; though they do to... it's also every ancestor transaction after them. | 21:37 |
| gmaxwell | And _every_ coin was ultimately mined. | 21:37 |
| kanzure | bramm: signatures don't actually sign for the entire transaction, surprise :( | 21:37 |
| moa | how practical would it be to spin up ~10,000 nodes malicious nodes that intentionally avoid connecting to each other but attempt to isolate, blockTX and corrupt comms between the 'honest' nodes? | 21:37 |
| bramm | gmaxwell, I haven't really thought much about spv clients, aside from wishing that the merkle roots were there for them to operate off of | 21:38 |
| phantomcircuit | op_null, iirc that's only because they dont have effective dynamic voltage control | 21:38 |
| gmaxwell | bramm: kanzure is talking about transaction malleability. | 21:38 |
| andytoshi | bramm: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki has a list of ways you can change txes without changing the signature | 21:38 |
| andytoshi | bramm: note that you can't redirect coins this way (except if the transactions were deliberately crafted to allow this) but you can break chains of transactiosn | 21:39 |
| phantomcircuit | op_null, minimum vdd changes with die temperature, which itself fluctuates | 21:39 |
| kanzure | (transaction malleability has been at the top of my mind today because i have been implementing relevant software that has to handle deep reorgs and mutated transactions) | 21:39 |
| gmaxwell | bramm: also wrt your wish, what you're thinking of there may be less of an improvement than you're think it is, simply because the privacy model of bitcoin strongly assumes that your wallet is private to you. The blockchain itself does not know which mixes of addresses share a wallet. | 21:39 |
| bramm | gmaxwell, If you had substantially more than 50% and wanted to really fuck shit up and take the time to do it, yeah, a lot of problems come up. It isn't a fine white line at 50% though, some problems start below that and don't become severe until well above | 21:39 |
| phantomcircuit | i would expect a lot of equipment to be turned off before it was underclocked/undervolted | 21:39 |
| kanzure | ( https://en.bitcoin.it/wiki/Transaction_Malleability ) | 21:39 |
| op_null | phantomcircuit: they don't have any at all I don't think. | 21:40 |
| bramm | gmaxwell, I view privacy as a largely accidental feature of bit coin | 21:40 |
| gmaxwell | bramm: see also the many forum posts where I make exactly that point only to be mobbed by fanboys who obsess over "50%" as a magical value. :) | 21:40 |
| kanzure | "While transactions are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash, the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does ... | 21:40 |
| kanzure | ... mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block. (and potentially even after a confirmation if the block chain is reorganized) In addition clients must always actively scan for transactions to them; assuming a txout exists ... | 21:40 |
| kanzure | ... because the client created it previously is unsafe." | 21:40 |
| op_null | bramm: there is almost no privacy in Bitcoin at all. | 21:40 |
| phantomcircuit | op_null, right | 21:41 |
| phantomcircuit | op_null, it's my understanding that you have to manually undervolt them when you underclock them | 21:41 |
| phantomcircuit | i dont see that being done widely | 21:41 |
| gmaxwell | bramm: Section 10 of bitcoin.pdf ... Not that its great, but its stronger than you may credit it for, and the performance optimizations are largely only avilable if it's broken completely. Doesn't seem like a good tradeoff considering how fast spv clients already are. | 21:41 |
| op_null | phantomcircuit: that's right. | 21:41 |
| bramm | andytoshi, I'm afraid that reading that link will give me an aneurysm | 21:42 |
| -!- mortale [~mortale@gateway/tor-sasl/mortale] has quit [Remote host closed the connection] | 21:42 | |
| kanzure | maintaining multiple simultaneous aneurysms is the name of the game | 21:42 |
| kanzure | my brain tumor receives #bitcoin-wizards all the time | 21:42 |
| bramm | (I have opened it in a new tab though, to look at later) | 21:43 |
| gmaxwell | kanzure: in any case, I don't think that the malleability is that great an example in this case because it's primarily a DOS attack. I really do think that pointing out that redirecting coinbases ultimately redirects all the coins, not juts miner's coins.. as a stronger example of how badly a high hashpower attacker can break things. | 21:43 |
| kanzure | fair enough | 21:43 |
| kanzure | yeah i am over-compensating for the other cases | 21:43 |
| kanzure | because i have had to deal with them more recently | 21:43 |
| op_null | the more you look into it really the less private Bitcoin transactions are. they are only private in that people don't bother to look at the transactions. people leak a lot about their addresses, transactions. | 21:43 |
| op_null | if a motivated individual spent some time doing some aggressive scraping of Bitcoin related content they would rapidly gain a picture of a large number of address ownerships. | 21:44 |
| -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards | 21:44 | |
| bramm | Yes it's the later transactions getting undone which is the real problem, not the initial mining being undone | 21:44 |
| gmaxwell | Some of the malleability is an intentional and useful feature, e.g. that you can author transactions for multiple people to supply input coins to non-interactively. ... some of it is a design bug. Though mostly it results in DOS attacks against conventional uses at worst. Unconvientional uses are another matter. | 21:44 |
| andytoshi | bramm: :P i almost posted one about anonymity/privacy, then remembered how much shit we've thrown at you all day | 21:44 |
| op_null | a website like blockchain.info has even more. they have the wallet information of every user, and the information of all the peeople who search for their own transactions and addresses to see how they are going. they no doubt know who owns almost all the BTC in the network, just from their logs. | 21:45 |
| bramm | There was a colloquium at Stanford the other day on figuring out the IP address of someone who did a bit coin transaction. It's remarkably easy, and attempting to stop attackers from being able to DOS peers by hogging all their peer slots makes the lack of anonymity problem worse | 21:45 |
| gmaxwell | bramm: right, yea, I don't give a crap about miners in that context, they can look out for themselves. But if their coins are lost, all decendant coins are lost. I wasted an unfortunate amount of time trying to figure out how to socialize double spending losses (e.g. by turning them into inflation) but never was able to come up with a scheme where it wasn't just an instant incentive for miners to form themselves. :) | 21:45 |
| kanzure | bramm: that's why you should just give your recipient the raw signed bitcoin transaction itself | 21:46 |
| op_null | bramm: that sounds like mostly bullshit to me. the layout of the network doesn't permit that sort of thing happening. | 21:46 |
| bramm | op_null, Peers announcing who they're talking to via gossip leaks a LOT of information | 21:47 |
| op_null | bramm: that doesn't tell you were a transaction has come from though. | 21:47 |
| kanzure | if you are all of their peer slots, you know when they send you something that you never sent them | 21:47 |
| bramm | This particular work was by Ivan Pustogarov | 21:48 |
| gmaxwell | bramm: sometimes research suffers from not knowing what high security users are doing in practice. (in particular, high securit applications of bitcoin do not announce transactions from persistantly on nodes.) | 21:48 |
| bramm | op_null, it tells you who introduced it to the network | 21:48 |
| op_null | bramm: only if you own every one of their connections, which is extremely unlikely. | 21:48 |
| -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards | 21:48 | |
| kanzure | no you don't need to be every single one | 21:48 |
| kanzure | (welcome to stats) | 21:49 |
| bramm | gmaxwell, Well yeah there are simple countermeasures to that particular one, but the point is that there's a lot more information leaking than most people might think | 21:49 |
| gmaxwell | op_null: you should read the paper, if you haven't. (there is a paper on this) | 21:49 |
| bramm | op_null, You don't have to know all their connections, you just see who announces to you that they have a transaction first and triangulate who they're all connected to | 21:49 |
| kanzure | link? | 21:49 |
| op_null | ditto. | 21:49 |
| op_null | I saw one a while back which was mostly nonsense, by the sounds of it this is something different. | 21:50 |
| bramm | https://crypto.stanford.edu/seclab/sem-14-15/pustogarov.html | 21:50 |
| bramm | The really terrifying thing is how easy it is to bust Tor | 21:50 |
| kanzure | http://diyhpl.us/~bryan/papers2/bitcoin/Deanonymisation%20of%20clients%20in%20Bitcoin%20P2P%20network.pdf | 21:50 |
| bramm | Although of course everybody involved with core Tor development knew from the beginning how inherently fragile the whole thing is. It was always a 'hold your nose and accept the threat model' bow to practicality. | 21:52 |
| gmaxwell | bramm: sure. But you must admit that narrow leaks to active attackers who are connected to you or your neighbors is quite a bit different than a largely unforgable highly replicated cryptographic ledger publishing information. | 21:52 |
| gmaxwell | The Tor website is very frank about the limits; the users are largely happy to ignore the caution. | 21:52 |
| gmaxwell | Likewise, the bitcoin tech community is very frank... worse for us becaues we have fanboys who give outright misinformation, and trying to correct them is pointless. | 21:53 |
| bramm | gmaxwell, Like I said, I view anonymity features of bit coin as accidental and not central | 21:53 |
| op_null | gmaxwell: haha. like if anybody tries attacking the network with massive amounts of hashpower we'll just ban them from the network :P | 21:54 |
| midnightmagic | Worse is trying to give normal people enough information to recognise that the people spreading misinformation, are spreading misinformation, and as a subset of that, where to find more-accurate data. | 21:54 |
| op_null | gmaxwell: that quote still hurts. | 21:54 |
| bramm | Yes, there's definitely a pattern of central devs being far saner than fanboys, I've found a common pattern of being ready to be mad at people for what I thought were their views only to find out that their views were either horribly misrepresented or far more nuanced or both | 21:54 |
| gmaxwell | bramm: it's not accidental. It's a day one part design, and also pretty important... since fungibility risk is a big problem for any money. A loss of fungibility can make the decenteralization pointless if you find yourself needing to consult a centeralized taint registry to find out if a coin is one you want to accept. | 21:54 |
| gmaxwell | Also few parties are really interested in using a money which make their every economic transaction visible to the competition, theieves, or personal enemies. | 21:55 |
| bramm | gmaxwell, anonymity can probably be brought on much better at the access point than in the middle of the thing. This is a common theme in anonymity: You much give people pseudonyms, and much be very clear about what the boundary of that pseudonym is | 21:55 |
| kanzure | after a certain point of using a pseudonym you have leaked too many bits anyway | 21:56 |
| midnightmagic | A good signal is information about bitcoin which marginalizes or minimalizes actual cryptographer or bitcoin developer (in most of the senses) works. | 21:56 |
| kanzure | (in the stye of http://www.gwern.net/Death%20Note%20Anonymity ) | 21:56 |
| kanzure | *style | 21:56 |
| bramm | The difficulty of making such claims is why I don't work on anonymity systems. Although Tor did start with the digital equivalent of me scribbling some stuff on a napkin | 21:57 |
| gmaxwell | bramm: I think you've got that backwards. If a system is perfectly fungible it's easy to layer on compromises on top of it (e.g. knowing who you're transacting with). The other way around not at all. Most of the information leak in bitcoin is because the pattery of spending interlinks pseudonymous identities. This is especially so in that people are trading scarce assets... | 21:57 |
| midnightmagic | reconsider linking to that site, kanzure | 21:57 |
| kanzure | haha | 21:57 |
| kanzure | yeah, i should.. | 21:57 |
| bramm | gmaxwell, Not sure what you're saying, the block chain of course leaks practically everything except the association of keys to real world identities | 21:57 |
| gmaxwell | s/pattery/pattern/ | 21:58 |
| op_null | gmaxwell: bramm: ah, yep, this paper references the one I was thinking of which identified listening full nodes as the sources of transactions. | 21:58 |
| midnightmagic | neglecting the difficulty of associating node entities on multiple networks? | 21:59 |
| op_null | bramm: that pairing is easy to get though. going from identity > address is ridiculously easy. once you've found a pool of addresses you can isolate the boundaries, or what could be boundaries, but looking at how the transactions are formed. different software makes different transaction types. | 21:59 |
| op_null | s/but/by | 21:59 |
| phantomcircuit | bramm, there are practical schemes which would correct that | 22:00 |
| phantomcircuit | coinjoin combined with standard sized outputs for example | 22:00 |
| gmaxwell | bramm: links of transactions among themselves leak even that if the system doesn't have privacy. Say, for example, that you said privacy wasn't really the job of bitcoin software. Great, now how could you ever hope to hide your salary from your land lord, or the costs of supplies to your customers? If someone wanted to stalk you, they could just keep paying you a penny every day and see where the funds end up to learn about your ... | 22:00 |
| gmaxwell | ... identities. So well written bitcoin software should make the pseudonymous identities meaningful by avoiding linking them (as a basic, table stakes feature). If you're trying to optimize client sync by forcing linkage or making privacy costly (people often don't realize they need privacy until its too late)... then I think thats not a good tradeoff. | 22:00 |
| phantomcircuit | at the extreme blocks could contain the coinbase and a single coinjoin transaction | 22:00 |
| bramm | gmaxwell, I think you're referring to slip-ups which I would view as so amateurish as to be unthinkable. A lot of in the wild protocols have really surprised me. | 22:02 |
| gmaxwell | bramm: good wallet software (anything with a positive score for this on bitcoin.org) doesn't encourage address reuses and avoids needlessly linking up histories. Better practices are possible but its an evolving area, and one thats hurt by fanboys exagerating the current level of privacy... reducing consumer demand for more. | 22:02 |
| bramm | True, you can try to make subsequent transactions only come out of one incoming previous payment. That doesn't always work though, and makes having a database of everything require more space | 22:03 |
| bramm | Also it's really easy to screw up. If you pay using whatever loose change is convenient then your various sources of loose change are likely to all wind up going to every possible output you have, which leaks a lot more than if you simply had two separate accounts with clear balances and never mixed them | 22:04 |
| op_null | small defined amounts are probably not what you want either though | 22:05 |
| bramm | And it of course won't work anywhere near as well as a delinking service, and those should really use standard quantized values to avoid obvious linkages | 22:05 |
| gmaxwell | There are other reasons why payments need to be seperate (replay attacks; or at least solved via something that has just as much overhead as making them seperate). Existing wallets already do have the basic pro-privacy features. Obviously total seperation is better but has a cost to the user which is quite considerable including needing to know in advance what seperation they need, and not working when the fund flows are imbbalanced. | 22:06 |
| op_null | delinking service? well. no. | 22:06 |
| gmaxwell | bramm: also, linkage in bitcoin is less evidence than you might think it is.. due to coinjoin. | 22:06 |
| bramm | If I pay $1,528.32 to one person to delink it and they give $1,528.32 to some other account, people can probably guess who's who | 22:06 |
| -!- spinza [~spin@197.89.10.224] has quit [Excess Flood] | 22:06 | |
| -!- spinza [~spin@197.89.10.224] has joined #bitcoin-wizards | 22:07 | |
| gmaxwell | (also, any explicit 'service' of the classical centeralized source has costs which are unacceptable to the point of uselessness, alas... but fortunately we have tools that don't require centeralized services) | 22:07 |
| op_null | bramm: naturally. you can do a neat attack on blockchain.info's "shared coin" in which you pick the inputs and outputs, and match the pairs. | 22:07 |
| op_null | no sorry, "shared send", "shared coin" is a different service. | 22:08 |
| bramm | gmaxwell, Of course conjoin is the exact opposite of delinking, so the relative merits aren't all that obvious | 22:08 |
| bramm | argh, xchat autocorrects coinjoin to conjoin | 22:09 |
| gmaxwell | bramm: It means that linkage doesn't mean what you might think it means. At the limit, linking is the same as delinking. :P Complete anonymity set. | 22:09 |
| gmaxwell | hah well coinjoin is a play on conjoin, so fair enough. | 22:09 |
| op_null | gmaxwell: I feat people will expose themselves by leaving different fingerprints on each side of the coinjoin transaction. that's a very real risk, and it goes beyond compressed/uncompressed keys. | 22:10 |
| gmaxwell | Coinswap ( https://bitcointalk.org/index.php?topic=321228.0 ) is the disjoint version... but it's less interesting due to overheads, IMO. | 22:10 |
| bramm | What's the usual algorithm for putting together a payment out of loose change? | 22:10 |
| kanzure | "coin selection" | 22:11 |
| kanzure | https://github.com/bitcoin/bitcoin/blob/33d5ee683085fe5cbb6fc6ea87d45c5f52882232/src/wallet.cpp#L1232 | 22:11 |
| op_null | depends on the wallet software. some of it like bitcoin core is pretty random, some like Breadwallet seem to be fairly insane (they spend more outputs than they really should for no real reason, as far as I can see) | 22:12 |
| gmaxwell | bramm: in bitcoin core we use a knapsack solver, that first tries to assemble a transaction from whole coins, then it tries to minimize the distinct number of inputs. | 22:12 |
| gmaxwell | op_null: so I've seen a fair number of greenback wallet authors decide that a good algorithim is a greedy one that spends the smallest coins first... and produces awful transactions. Normally they learn the error of their ways quickly. :) | 22:12 |
| kanzure | so waiting around forever for confirmations is not ideal? whaaat | 22:13 |
| bramm | If you're minimizing the number of inputs, won't it work to repeatedly add the largest coin until you go over? | 22:13 |
| midnightmagic | bramm: There are a few ways; one includes getting a list of fresh addresses from the recipient exactly as long as the number of inputs you want to spend on to them. Another is a coinjoin with split entity outputs; manually selecting coins via a patch to core; using intermediaries over time with randomized outputs; etc. I.e. there is no usual algorithm, because as gmaxwell said people are convinced bitcoin is anonymous | 22:14 |
| kanzure | i thin he means picking solutions that have a tending-to-be-minimum number of inputs | 22:14 |
| midnightmagic | already. | 22:14 |
| kanzure | *think | 22:14 |
| gmaxwell | No, because the problem isn't convex like that. The greedy solution isn't optimal. | 22:14 |
| gmaxwell | bitcoin core's solver adds random subsets and prunes them and retries a number of times to get the best run it comes up with. | 22:14 |
| op_null | gmaxwell: I'll have to look at it's code some day, breadwallet was doing something weirder than that. (example) I saw it spending 0.9 + 0.1 for a 0.05 output with the rest change, which seems pretty nuts. | 22:14 |
| gmaxwell | op_null: that .. does seem a bit weird. Whats the source say its doing? | 22:15 |
| op_null | gmaxwell: finding out. | 22:15 |
| gmaxwell | There are a couple of dumb things bitcoin core is doing here, if anyone wants to hack on that for 0.11 feel free to nag me and I'd be glad to go over what I know and don't like. | 22:16 |
| midnightmagic | bramm: One of my favourite, unfortunately only reserved for people with significant capital and lots of patience, is to buy lots of mining hardware, and then pay from coinbase payouts, which arguably could have the least identity associated with them. | 22:17 |
| phantomcircuit | midnightmagic, i do that | 22:18 |
| gmaxwell | midnightmagic: yea, mining is good for privacy ... but, mostly I don't find privacy techniques that are burdensom very interesting. Someone who knows they need privacy and are willing to work for it will get it (this is true of the world in general). In terms of protecting ordinary users from more conventional problems other approaches are needed. | 22:18 |
| phantomcircuit | mostly for kicks though | 22:18 |
| -!- samson_ [~samson_@183.89.172.189] has quit [Remote host closed the connection] | 22:18 | |
| -!- samson_ [~samson_@183.89.172.189] has joined #bitcoin-wizards | 22:19 | |
| midnightmagic | phantomcircuit: me too it's my favourite | 22:19 |
| midnightmagic | But I think I may have misunderstood Bram's question. I don't think he was asking for the usual ways to be private, just how core or the wallet software actually does it. | 22:20 |
| bramm | Yes one could make the argument that certain coins are 'new' and hence don't leak information. Also one could argue that coins which haven't been used for a longer time leak less information. Or that you should try to use up a complete coin so that it will leak less information on later transactions | 22:20 |
| bramm | midnightmagic, a combination of what can and should be done | 22:20 |
| op_null | bramm: humans like whole numbers, which makes that harder. you're almost always left with a little change, or needing another output to make up the fee. | 22:21 |
| bramm | A reasonable algorithm is to take the largest coin you have less than or equal to the amount you want to spend, then add the rest out of the smallest remaining coin larger than the remainder | 22:22 |
| gmaxwell | What I'd like to have is better automatic link avoiding support, there is some now in the strategy but it makes some bad assumptions which are no longer true like users won't reuse addresses. And after that automatic coinjoining on spends so that analysis of what leakage remains is less reliable. | 22:23 |
| -!- folksngoats [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 264 seconds] | 22:23 | |
| bramm | That always use one or two coins out, and reduces the number of coins you have by one every time | 22:23 |
| bramm | So you're minimizing conjoining, which one could argue is very good for anonymity | 22:23 |
| op_null | gmaxwell: would be nice to have lazy transactions too. send this money to this address, sometime in the next 24 hours. no rush. | 22:23 |
| gmaxwell | bramm: one must also consider the size of your change and how that influences your further transaction selection. e.g. minimizing change size has a negative property of producing a lot of 'dust' ... it can be preferable when change happens to be sized like your future spends. | 22:24 |
| bramm | gmaxwell, the algorithm I just said always reduces your number of coins by one with every transaction | 22:24 |
| -!- folksngoats [~gues@se5x.mullvad.net] has joined #bitcoin-wizards | 22:24 | |
| bramm | But it does have the problem that the total number of coins everywhere doesn't go down | 22:25 |
| gmaxwell | it also always links inputs even when it coudl be avoided. There was someone working on some different selection hurestics that created a simulator, on one of the bitcoin github issues. | 22:26 |
| bramm | Actually no it can reduce by more: I didn't specify what to do when you want to spend 9 credits and you have a bunch of singles and a 10 | 22:26 |
| gmaxwell | Haven't heard from him in a bit. | 22:26 |
| -!- folksngo1ts [~gues@se5x.mullvad.net] has joined #bitcoin-wizards | 22:26 | |
| bramm | It isn't clear what behavior you want. You can either slowly merge coins or do it never until you put all your spare change into one big transaction | 22:26 |
| gmaxwell | I think ideal behavior has some knoweldge of what your future spending amounts look like (or a guess) and then splits or merges to move more torwards that distribution. | 22:27 |
| phantomcircuit | which is hard to do, thus powers of two | 22:28 |
| gmaxwell | If in some transaction you can be especially efficient constructing it one way (e.g. no change), then do that. | 22:28 |
| gmaxwell | We certantly do not want schemes which cause unbounded utxo set growth... but fortunately ones that do are bad all around, bad for privacy, bad for tx fees, etc. | 22:29 |
| -!- folksngoats [~gues@se5x.mullvad.net] has quit [Ping timeout: 272 seconds] | 22:29 | |
| op_null | gmaxwell: that's a nice touch. breadwallet rolls back the block chain on launch and rescans for it's keys just in case somebody gave false negatives. | 22:29 |
| gmaxwell | op_null: how far back? | 22:30 |
| op_null | wait, I misread that, it only does that if users request it. | 22:30 |
| gmaxwell | ah okay. | 22:30 |
| gmaxwell | op_null: I was going to suggest you contact them and find out if they've ever seen that attack. | 22:30 |
| kanzure | re: simulations in a github issue, | 22:31 |
| kanzure | https://github.com/bitcoin/bitcoin/pull/4906 | 22:31 |
| bramm | If you're optimizing for dust you can keep all your coins as powers of two. That does a lot of coin merging though | 22:31 |
| bramm | And you have an unpleasant decision to make if someone gave you a bunch of nickels | 22:32 |
| bramm | But the general gist of what everybody is saying here amounts to is 'eh, we do something, maybe we could do better' | 22:32 |
| bramm | Doing knapsack leaks all kinds of stuff. If I suspect person A and person B are the same, then even if they have a huge wallet I can give person A $112.32 and ask person B for $112.32 and see if they give me an exact coin | 22:33 |
| gmaxwell | well, you can always ignore coins... though this can have a bad effect on the network. E.g. even though litecoin has less than 1/10th the number of utxo with >$0.01 in value, it has something like 100x more utxo in general, in part because they responded to penny flooding attacks by making wallets just ignore the inputs and never spend them... and as a result a 'lite'coin node is more resource intensive than a bitcoin node. | 22:34 |
| gmaxwell | bramm: yes any kind of passive security e.g. avoiding gratitious linkage is vulnerable to confirmation attacks. | 22:35 |
| bramm | There's a deep problem with transaction costs in general that whoever's accepting them gets paid but doesn't have to deal with the storage costs for everybody else later | 22:35 |
| gmaxwell | Yep. well it's _not_ a deep problem if the system is limited enough that the costs are negligible. Agreed its a problem otherwise. One of the more complex schemes on the alt ideas page was a notion of prepaying fees. | 22:36 |
| gmaxwell | I've also been a fan of utxo expiration (amiller too) but suggesting that can get you crucified around bitcoin-land. | 22:37 |
| gmaxwell | The prepayment idea is cute, basically creation of the utxo reduces the maximum blocksize for the block that creates it... and increases the maximum blocksize for the block that spends it. ... by an amount specified in the utxo as the expected signature size. (and subject to some limits, which is where it starts getting complex) | 22:38 |
| bramm | I can't seem to find a good web page on max clique. If I recall correctly, if half the edges are filled in then it's easy to find a clique of size n^.5 but extremely hard to find one even slightly larger and there's almost always one of that size | 22:38 |
| bramm | almost always one of size 2*n^.5 I mean | 22:39 |
| bramm | Apparently max-clique isn't sexy enough for people to like pontificating about it online | 22:39 |
| bramm | What is a utxo? | 22:39 |
| gmaxwell | unspent transaction output. The utxo set is the actual data a full node tracks for forward validating new blocks that come in. | 22:40 |
| gmaxwell | a utxo entry maps {txid, output index} -> {version,height,coinbase_flag,value,script_pubkey} or logically equal. | 22:41 |
| bramm | Yeah I assume that making small utxos time out would not be popular | 22:42 |
| bramm | What does bit coin do to prevent ddos by small transaction? | 22:43 |
| -!- lclc_bnc is now known as lclc | 22:43 | |
| op_null | fees, and nodes won't relay floods of no-fee transactions. | 22:43 |
| gmaxwell | and regardless of fees transactions which create very tiny 'dust' outputs are not relayed or mined by most nodes. This is 'policy' not a consensus rule, so nodes don't have to be consistent in it. | 22:44 |
| gmaxwell | (so, e.g. it's fine for different versions of the software to just twiddle around these thresholds) | 22:44 |
| bramm | What's to stop a miner from doing a DDOS with lots of small transactions? | 22:45 |
| gmaxwell | also, adding to what op_null said... very low fees (configurable node local policy) are treated as zero for the purposes of e.g. the relay limiting and mining priority. | 22:45 |
| bramm | Since a miner can put whatever they want into the chain, and it only takes one jerk to add a huge amount of stuff... | 22:45 |
| gmaxwell | A miner? nothing at all. Except that he's recieving some ten grand in bitcoins and it probably isn't in his interest to debase their value by crapping on the system. He can only add 1mb of data at most. | 22:46 |
| bramm | Do you mean there's a hard limit of 1mb on transactions for each block? | 22:46 |
| gmaxwell | He takes some very small increase in orphaning risk by mining a big block full of txn that weren't previously relayed and validated... but that effect is probably fairly negligible. | 22:46 |
| gmaxwell | bramm: absolutely. | 22:46 |
| op_null | 1MB of crap that hasn't been seen by their peers will take a lot longer to validate than 1MB of previously seen transactions too. | 22:46 |
| bramm | That would seem to be a hard limit which would have to be lifted at some transaction volume | 22:47 |
| gmaxwell | bramm: technically a million bytes and the block header comes out of that too. | 22:47 |
| midnightmagic | main.h:static const unsigned int MAX_BLOCK_SIZE = 1000000; | 22:47 |
| op_null | it is literally a hard limit though. can't twiddle with it without a lot of bother. | 22:48 |
| bramm | That could cause an interesting problem in the future | 22:48 |
| op_null | well, a fork. | 22:48 |
| bramm | How much forkage has there been in the past? | 22:48 |
| midnightmagic | potentially; unless sidechains works out, in which case some forms of scaling can go into those | 22:49 |
| gmaxwell | bramm: potentially, it's a protocol rule, not policy lifting it is like lifting the supply of bitcoins technically. Though presumably easier. I guess this explains some of your earlier incentive concerns wrt scaling. Those issues of a slippery slope that loses decenteralization can't sneak up on us because of the limits. | 22:49 |
| op_null | depends on your definition. there was a hard fork early on which disabled a lot of dangerous opcodes, and the fork where BDB issues caused some nodes to stick and fork on blocks (but not all at the same time). there's been no others. | 22:49 |
| bramm | How likely are side chains to actually happen? That would seem to be a much more immediate and potentially serious forage | 22:50 |
| gmaxwell | bramm: subject to some slight definitional debate we've never had a hard fork. E.g. you can take a first release node of bitcoin and with a little gatewaying it _should_ sync up to the current tip. Should because bdb had non-determinstic behavior which would potentially make old nodes get stuck under some conditions. | 22:50 |
| midnightmagic | bramm: It depends on what you call forking. The codebase itself has changed the way it interprets a valid block a few times, but much of what I would consider to be a forking change I typically get yelled down about. :-P | 22:50 |
| gmaxwell | We've had many soft forks, which are backwards compatible with old software. | 22:50 |
| gmaxwell | If you include the fact that 0.8 removed the non-determinstic behavior from prior versions and thus potentially is happy with chains old versions would non-determinstically reject; then we've had one hard fork. | 22:51 |
| bramm | You mean the very first release of bit coin would accept the entire current history? | 22:51 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] | 22:51 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 22:51 | |
| gmaxwell | bramm: it should. At least if you feed it to to it in one go without reorgnizations, the bdb getting stuck mostly prevents reorgs. | 22:52 |
| gmaxwell | I haven't done it for about a year. | 22:52 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] | 22:52 | |
| bramm | What does it use now? bdb isn't exactly known for stability, for no apparent reason | 22:52 |
| gmaxwell | You might grow a bit old while wating ... it syncs easily 100x slower than current code (maybe several hundred x) | 22:52 |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-hmtycgolpgaohezp] has quit [Quit: Connection closed for inactivity] | 22:53 | |
| op_null | leveldb. | 22:53 |
| midnightmagic | leveldb for the blockchain, bdb for wallet | 22:53 |
| bramm | gmaxwell, Did it not pipeline requests from peers? | 22:53 |
| gmaxwell | well more than leveldb, we use leveldb in a way that makes it less likely to cause any future issues than the way bdb was used. | 22:53 |
| midnightmagic | .. how about: leveldb for the blockchain indices; raw block data for actual block storage; bdb for wallet? | 22:54 |
| bramm | bdb is known for just plain getting garbled. Because key/value storage is apparently a problem which takes decades to debug :-P | 22:54 |
| op_null | midnightmagic: * bdb for wallets for historical reasons but it's totally overkill now | 22:54 |
| bramm | why not, say, tokyo tyrant, or is leveldb functionally equivalent? | 22:55 |
| gmaxwell | bramm: it would request multiple blocks at once, but it was just slow in every way... keep in mind that the history has 52,266,519 transactions, and probably 10x that number of utxo. It's not a small task. Git master can full sync to tip in about 2.5 hours on a fast desktop... its a lot of work to do in a small time. | 22:56 |
| * Taek scrolls for 12 minutes looking for the start of the conversation | 22:56 | |
| bramm | How does it have 10 times as many utxos as transactions? | 22:56 |
| gmaxwell | bramm: all we need is a key value store with atomic transactions. | 22:57 |
| bramm | Don't you need a transaction or a mining operation to make a utxo? | 22:57 |
| gmaxwell | bramm: because some transactions have hundreds of outputs. | 22:57 |
| bramm | Taek, might take you a while, I've been here all day | 22:57 |
| midnightmagic | Taek: 07:40m ago | 22:57 |
| midnightmagic | bramm: A single transaction can have multiple individual outputs. | 22:58 |
| bramm | midnightmagic, but a factor 10? What kind of transaction would you be doing for that? | 22:58 |
| bramm | Unless everything is basically mining pool redistribution | 22:59 |
| gmaxwell | bramm: the median transaction has two outputs (payment and change) | 22:59 |
| midnightmagic | bramm: p2pool and other mining operations can sometimes includes hundreds of outputs in coinbase. early forms of spam would do it. current spam + mining collusion are doing it. plus the normal -core transaction only rarely has a single output, usually it has two.. ah, what gmaxwell said. | 22:59 |
| bramm | but doesn't the mean transaction have to have 10 outputs for there to be 10 times as many utxos as transactions? | 23:00 |
| gmaxwell | Then some services batch their payments to reduce the transaction count, uses will sometimes make multiple payments in a single transaction (which is supported in the ui in bitcoin core and I think most wallets). Various mining pools, lotteries, ... etc. use large numbers out of ouputs. | 23:00 |
| midnightmagic | ah, right, satoshidice bloat. | 23:00 |
| gmaxwell | bramm: I might have been exagerated there, I'm not sure what the mean is. Don't have a quick way to count it. I know it's more than 3. | 23:00 |
| op_null | midnightmagic: down to a third of the block chain now. | 23:01 |
| midnightmagic | "come help me stress test the bitcoin blockchain" as voorhees said. | 23:01 |
| bramm | gmaxwell, A fascinating data point, regardless | 23:01 |
| midnightmagic | op_null: brutal man | 23:01 |
| go1111111 | "How likely are side chains to actually happen?" -- you know gmaxwell and a bunch of other smart dudes just raised 21 million dollars from Reid Hoffman and some others to make sidechains a reality right? so my guess is more likely than not | 23:01 |
| gmaxwell | I can count the ratio for the existing utxo set easily enough. But that may not reflect the overall history well. | 23:01 |
| bramm | I have a suspicion that a huge fraction of all the payouts to date are mining pool redistribution | 23:02 |
| gmaxwell | go1111111: That the systems get build it not a guaretee that they become a market reality however, which is why I wasn't going to debate it. Best to show. :) | 23:02 |
| gmaxwell | bramm: they're a lot, but you underestimate the really inefficient gambling services I suspect. :) also other 'interesting' things like dividends on cryptostocks. (read: unregulated securities traded primarly by conartists :) ) | 23:03 |
| bramm | midnightmagic, what are the 'current spam' and 'mining collusion'? | 23:04 |
| bramm | gmaxwell, Yes there's an obvious business model for 'interest bearing accounts' | 23:04 |
| midnightmagic | bramm: Spam still exists in the form of transactions of very tiny one-or-two satoshis, including a message (which shows up in blockchain.info because they're stupid) and since most nodes don't accept it, I'm presuming mining collusion to get them actually into the blockchain. | 23:05 |
| bramm | midnightmagic, Ah gotcha | 23:05 |
| phantomcircuit | midnightmagic, it's people running patches which include all valid transactions into the block prioritized by fee/kb only | 23:06 |
| gmaxwell | bramm: blockchain.info has a really ill advised 'send a message with your transaction' feature, it doesn't actually put the data into the blockchain (somehow we managed to yell them out of doing that)... but there are a whole bunch of idiots that use that feature to send advertisments to people. The aformentioned filtering blocks most of it, but some gets through. | 23:06 |
| bramm | On side chains, I can see the political force behind getting them accepted, but I also see tremendous technical barriers on the other side, including that it's a hard fork | 23:07 |
| phantomcircuit | not a hard fork | 23:07 |
| gmaxwell | so the current utxo set has 15103752 txouts from 4194830 transactions. So 3.6, how this reflects the history is anyones guess... since spending patterns probably are different for many out vs few out transactions. | 23:07 |
| gmaxwell | bramm: oh, it's not a hard fork. | 23:07 |
| op_null | bramm: the sort of neat thing is that opcodes can be "added" without a hard fork. | 23:08 |
| phantomcircuit | gmaxwell, i've probably been increasing the ratio a bunch | 23:08 |
| phantomcircuit | all the cloudhashing payouts are sendmany | 23:08 |
| dgenr8 | interest accounts... i'm not sure where the demand for bitcoin loans would come from today. other than those who want to short-sell it | 23:08 |
| phantomcircuit | (they're all paid from the same address anyways so it doesn't much matter) | 23:08 |
| gmaxwell | bramm: and they can be used with a security reduction without any changes to bitcoin at all. (see appendix A) so there is an on ramp for adoption prior to convincing people that its a good thing to have. | 23:08 |
| bramm | Oh god, the headline list on blockchain.info... | 23:08 |
| op_null | bramm: you'll notice the top item, though it's not stated, it's paid advertising. | 23:09 |
| gmaxwell | (and we've extended script successfully in the past with soft-forks and are likely to do so again very soon; we have two soft-fork script changes pending that basically just slipped 0.10) | 23:09 |
| bramm | op_null, Yeah that screams 'this is a scam' if ever I've seen one | 23:09 |
| bramm | gmaxwell, How are releases of pegged coins treated by non-updated software? | 23:10 |
| op_null | bramm: blockchain.info are fools on a number of levels, that barely scratches the surface. | 23:10 |
| gmaxwell | bramm: everything about that site is ... unfortunate. pretty much. I like the fact that they have a JS web wallet on the same domain that displays weakly validated third party data (ads and data scraped from the blockchain)... they've had several severe xss bugs. | 23:10 |
| midnightmagic | bramm: tangential, potentially unfortunate side-effect of blockchain.info being irresponsible: https://github.com/bitcoin/bitcoin/issues/2653 | 23:11 |
| gmaxwell | bramm: For script enhancements in soft-forks, old nodes see payments to the new script types as "non-standard, anyone can spend" so while they won't relay or mine them, they'll happily accept anything that spends them in a block. | 23:11 |
| bramm | gmaxwell, Couldn't that cause a miner to accept them being spent counter to the new script rules? | 23:12 |
| bramm | Do you ever get the feeling that the goodwill of your good crypto work is being exploited by overt scammers to make a lot more money off of it than you ever will? | 23:13 |
| bramm | (my last two comments were totally unrelated) | 23:13 |
| gmaxwell | Yes/no. Because they're non-standard, miners won't add them to blocks themselves. But if someone else does, they'll accept the block. The way soft forks work is that miners signal in blocks with a flag, that "e.g. when 950 of the last 1000 blocks have this flag, I'll start imposing this new rule" | 23:14 |
| gmaxwell | bramm: I've sometimes felt that way, at times _but_ (1) most of the scammers aren't actually making much money, and aren't manging to hold onto it if they do. (2) that someone else benefits isn't really my problem (3) if they do manage to get some more crypto stuff developed and deployed thats good for everyone ultimately (so far, track record here is poor). | 23:16 |
| bramm | So as a matter of policy miners will play nice, but if one wanted to be a jerk it could really fuck things up? | 23:16 |
| gmaxwell | bramm: well kinda, what happens is that after the enforcement has kicked in, e.g. 950 of 1000... if they put in a bogus spend, the 5% of miners who are not updated it yet will extend that block and potentially get orphaned along with them. There will be a bit of chain reorging, but its just at the tip. So they can be disruptive, but it's pretty costly. | 23:17 |
| bramm | Er, well, I guess if you waited until most miners said they spoke the new thing, then miners who spoke the new thing could outright ignore history which has 'bad' transactions in it | 23:17 |
| Taek | can someone confirm this: a miner with a properly strict set of rules for rejecting non-standard transactions can still produce blocks that the network will accept after a softfork? | 23:17 |
| gmaxwell | bramm: yep | 23:18 |
| gmaxwell | Taek: absolutely, thats part of the goal. | 23:18 |
| bramm | gmaxwell, I understand now. Are there any plans on what that threshold might be for side chains? | 23:18 |
| gmaxwell | For p2sh it was more like 70% and the txn weren't even non-standard so unmodified old miners would mine garbage. It caused some moderate amount of forking. We agreed that was too permissive after the fact. | 23:19 |
| bramm | How long did the 70% take to happen? | 23:20 |
| Taek | if softforks are not harmful to conservative miners, why wait until a full 95%? Seems like you could execute successfully at a lower percentage, maybe 85% - especially if you're looking at the past 1000 blocks. | 23:20 |
| gmaxwell | For height in coinbase the lock-in was at 95% and that took a long time to hit. I think that was perhaps to agressive in retrospect... esp for something where unmodified miners can't footgun themselves. | 23:20 |
| op_null | bramm: the one that gets me is people being paid to stand up in front of people and present themselves as a cryptography expert. earning money for spreading misinformation is pretty insane. | 23:20 |
| gmaxwell | bramm: two months? something like that. | 23:20 |
| bramm | op_null, Given that schneier is viewed as the world's preeminent crypto expert, I think that one's a lost cause | 23:21 |
| op_null | bramm: heh, you can go far worse, trust me. | 23:21 |
| gmaxwell | we need to make these decisions for BIP62 and BIP65 soon. | 23:21 |
| gmaxwell | op_null: show him that image. :P | 23:22 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 23:22 | |
| gmaxwell | For BIP65 I'm going to probably suggest 70-80% and see what people argue. In any case, at a minimum it must be a decisive supermajority, so that if any doofus does produce an invalid block its rapidly orphaned. | 23:23 |
| op_null | https://i.imgur.com/tvAlMPf.png - this one? | 23:23 |
| gmaxwell | E.g. 51% is pretty pessimal, someone produces an invalid block and it might take an uncomfortably long time for the majority to orphan it. This doesn't generally present _that_ much risk, since the same transactions will be in both sides of the fork, for the most part... but any large fork has some risk. | 23:24 |
| bramm | Of course, being able to play such games raises the question of how decentralized bit coin really is... | 23:25 |
| bramm | op_null, Oh I'm sure you can | 23:26 |
| gmaxwell | Well soft forking power is very narrow, you can only restrict the set of valid transactions. ... and it's no secret that Bitcoin miners can freely censor the chain. ... I don't know why people aren't more frank about that, its a very serious limitation. | 23:27 |
| gmaxwell | but a helpful one in that it allows smoothly rolling out targeted fixes and enhancements. | 23:27 |
| gmaxwell | soft forks have been used to fix several end of the world bugs. | 23:28 |
| bramm | My experience has been that people throw a shitfit if you say anything other than than bit coin farts rainbows | 23:28 |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d1e0:6eae:20cb:e70c] has joined #bitcoin-wizards | 23:28 | |
| gmaxwell | bramm: well it's been worse since early 2013... got a LOT of new users since then, and "sepetember" hasn't ended yet. | 23:29 |
| bramm | By 'soft fork', you mean changes where something which would have been accepted before is no longer accepted now? | 23:29 |
| gmaxwell | bramm: correct. | 23:29 |
| bramm | I literally got on the net in september '93 | 23:29 |
| gmaxwell | :P (thats roughly when I got reliable net access myself, to be fair) | 23:31 |
| gmaxwell | E.g. in the original bitcoin software you could spend any coin with the signature (effectively) "return true". | 23:31 |
| gmaxwell | a most unhelpful feature that was removed via a soft-forking change. :P | 23:32 |
| bramm | That would seem more bug fix than soft fork | 23:32 |
| op_null | you could also blow up the stack and crash the node trying to validate a script by using OP_CAT. that was removed in the hard fork early on. | 23:33 |
| gmaxwell | Well, one in the same, that distinction is social, not technical. | 23:33 |
| gmaxwell | op_null: soft fork. (if that change was actually a hardfork due to some subtle reason, e.g. the encoding straddling, it's still latent) | 23:33 |
| bramm | I'm rather skeeved by the expressiveness of bit coin's coin spending syntax | 23:33 |
| * op_null squints | 23:34 | |
| op_null | I could have sworn pieter mentioned it as being a hard fork | 23:34 |
| op_null | must be misremembering or something | 23:34 |
| gmaxwell | bramm: The justification is straight forward though... what use is a strongly decenteralized cryptocurrency system if it lacks enough affordances to go build decenteralized services on top of it? A coin that you can only use in interesting ways by handing it over to third parties, might as well be centeralized to begin with (and thus have much better performance/scale) | 23:35 |
| bramm | gmaxwell, the only sane use I've heard of it so far is supporting multi key spending. Side chains are a whole other ball of wax | 23:35 |
| gmaxwell | op_null: there is some back and forth over if it is or isn't based on a push opcode straddling the script concat boundary. I think we've gone back and forth over it being hardforkable, but whichever it actually is, the fork hasn't been triggered yet. | 23:36 |
| gmaxwell | bramm: oh, it's used for other stuff. Just not in any great amount. Some of the uses are hampered by some other system limitations, basically protocols thats require refund transactions to avoid holdup risk are unsafe currently, and this is fixed by BIP62 and BIP65. So we may see more uses. | 23:37 |
| op_null | gmaxwell: bah, don't pose it like a challenge to peter. I was trying to work out why there's a few SignatureHash() : nOut=2 out of range errors during sync. googled it and his name on a hunch, and what do you know. | 23:37 |
| gmaxwell | bramm: most common uses beyond multisig are hash-reveal transactions which have been used for atomic swaps. There are also some lottery transaction uses, but no shock the poeple savvy enough to do secure decetneralized coinflips aren't really into gambling. :) | 23:38 |
| bramm | Other uses, like satoshi dice :-) | 23:38 |
| bramm | What would you be swapping with an atomic swap? | 23:39 |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards | 23:40 | |
| Taek | securely trading bitcoins for othercoins | 23:41 |
| bramm | Oh, you mean you put the same hash reveal on the other coin? | 23:41 |
| bramm | That's cute, takes care of the only 'real' use of smart transactions I know of | 23:41 |
| bramm | What are 'return transactions'? | 23:42 |
| op_null | bramm: run and tell the ethereum developers :) | 23:43 |
| gmaxwell | But even relatively simple 'powerful' features can be used to do a lot at least thoretically; https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment ... but look at the state of cryptographic software in general. A lot of things are possible just just don't have tools for them. (I rant: https://en.bitcoin.it/wiki/User:Gmaxwell/things_im_surprised_dont_exist ) | 23:43 |
| bramm | op_null, The ethereum developers are on their own, I think it would be a waste of my time, and possibly a danger to my person, to try to help them | 23:43 |
| gmaxwell | bramm: yea, you can trade with compatible altcoins; or with a slightly more complex transaction pattern for other people's bitcoins in a way that doesn't link the tansactions. | 23:43 |
| op_null | bramm: agreed completely. | 23:44 |
| bramm | gmaxwell, How does the unlinking transaction work? | 23:46 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 23:47 | |
| bramm | gmaxwell, On your list of things which don't exist, re: high latency mixes, that's what pynchon gate is, but there's been little interest in it so it hasn't been built. There are more secure but less scaleable things in the literature for doing voting, because that requires a decrypt + unknown permutation operation, but those just exist in the academic literature | 23:48 |
| gmaxwell | yes, all these things exist in the lit. | 23:48 |
| gmaxwell | They don't exist in any pratical sense as far as I know though. | 23:49 |
| bramm | threshold cryptography is used in nuclear weapons | 23:49 |
| gmaxwell | you and I generate keys. You and I place our respective coins into 2 of 2 escrows, but don't publish the escrow placing transactions until we've recieved timelock refunds. Then we publish our escrow payments, locking up our coins. Then we exchange releases of the payments that look like payments into an atomic swap, but do not publish them. After doing this we are both confident that we can get our funds via the swap should the ... | 23:49 |
| gmaxwell | ... other party defect, and so we can just happily pay out of the escrow directly. ... thus keeping the hashlocked atomic swap out of the chain. This is a really short description, a full protocol is at https://bitcointalk.org/index.php?topic=321228.0 | 23:49 |
| gmaxwell | bramm: it's also used in Bitcoin. :) considering how compromised every computing device out there is, you'd think that we ought to use it for a bit more than bitcoin and nukes. | 23:50 |
| bramm | Okay I'll put that on my list of things to read later, too exhausted right now | 23:51 |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection] | 23:52 | |
| bramm | I'm still not sold on anything beyond multiple keys being all that useful, but am open to being convinced | 23:52 |
| -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!] | 23:55 | |
| bramm | gmaxwell, On steganography there are deep and interesting problems in making it practical. I came up with a big improvement in the state of the art but whether it's 'useful' is another matter | 23:55 |
| -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards | 23:58 | |
| -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has quit [Ping timeout: 255 seconds] | 23:59 | |
| --- Log closed Tue Nov 25 00:00:01 2014 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!
