--- Log opened Tue Nov 25 00:00:01 2014
00:01 -!- Grishnakh [~grishnakh@dsl-espbrasgw1-50dfb6-218.dhcp.inet.fi] has quit [Ping timeout: 265 seconds]
00:13 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has joined #bitcoin-wizards
00:19 -!- shesek [~shesek@77.125.14.5] has quit [Ping timeout: 264 seconds]
00:20 -!- SubCreative is now known as Sub|zzz
00:22 -!- go1111111 [~go1111111@162.244.138.37] has quit [Quit: Leaving]
00:22 -!- go1111111 [~go1111111@50.23.131.238] has joined #bitcoin-wizards
00:23 -!- op_null [~op_null@178.62.133.216] has quit [Quit: Lost terminal]
00:24 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection]
00:25 -!- cbeams_ [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards
00:25 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer]
00:28 -!- cbeams_ is now known as cbeams
00:28 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]
00:28 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
00:35 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards
00:37 -!- go1111111 [~go1111111@50.23.131.238] has quit [Ping timeout: 240 seconds]
00:44 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer]
00:44 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards
00:44 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]
00:44 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
00:44 -!- AaronvanW [~ewout@255pc208.sshunet.nl] has joined #bitcoin-wizards
00:46 -!- bramm [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection]
00:49 -!- cbeams_ [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards
00:49 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer]
00:50 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
01:00 -!- todaystomorrow [~me@d114-78-126-229.bla803.nsw.optusnet.com.au] has joined #bitcoin-wizards
01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection]
01:05 -!- cbeams_ [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Read error: Connection reset by peer]
01:05 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards
01:05 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]
01:05 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards
01:05  * andy-logbot is logging
01:05 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
01:09 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has quit [Ping timeout: 250 seconds]
01:09 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has joined #bitcoin-wizards
01:09 -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 265 seconds]
01:26 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has joined #bitcoin-wizards
01:31 -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has joined #bitcoin-wizards
01:38 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-wizards
01:41 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
01:41 -!- vdo [~vdo@unaffiliated/vdo] has joined #bitcoin-wizards
01:42 -!- cryptokeeper [c08b7d80@gateway/web/cgi-irc/kiwiirc.com/ip.192.139.125.128] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
01:47 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
01:47 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards
01:51 -!- RoboTeddy [~roboteddy@2604:5500:13:5fc:20e3:a255:2c37:bc0] has quit [Ping timeout: 258 seconds]
01:58 -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards
02:00 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
02:05 -!- paulpaschos [~paul@24-212-224-219.cable.teksavvy.com] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
02:09 -!- lclc is now known as lclc_bnc
02:11 -!- moa [~moa@opentransactions/dev/moa] has quit [Quit: Leaving.]
02:12 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d1e0:6eae:20cb:e70c] has quit [Ping timeout: 258 seconds]
02:15 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
02:23 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards
02:23 -!- cashmen [~cashmen@jonny.cloakcoin.info] has left #bitcoin-wizards ["Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is"]
02:32 -!- todays_tomorrow [~me@d122-111-39-14.bla803.nsw.optusnet.com.au] has joined #bitcoin-wizards
02:34 -!- lclc_bnc is now known as lclc
02:35 -!- todaystomorrow [~me@d114-78-126-229.bla803.nsw.optusnet.com.au] has quit [Ping timeout: 240 seconds]
02:45 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: Sleeping]
02:51 -!- todaystomorrow [~me@d122-111-39-14.bla803.nsw.optusnet.com.au] has joined #bitcoin-wizards
02:52 -!- sipa [~pw@2a02:348:5e:5a29::1] has quit [Quit: leaving]
02:53 -!- todays_tomorrow [~me@d122-111-39-14.bla803.nsw.optusnet.com.au] has quit [Ping timeout: 240 seconds]
02:56 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-wizards
02:58 -!- vdo [~vdo@unaffiliated/vdo] has quit [Quit: Lost terminal]
03:11 -!- c0rw|sle_ is now known as c0rw1n
03:40 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 264 seconds]
03:40 -!- c0rw1n is now known as c0rw|work
03:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
03:44 -!- damethos [~damethos@unaffiliated/damethos] has quit [Remote host closed the connection]
03:45 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
03:45 -!- Qfwfq [~WashIrvin@unaffiliated/washirving] has quit [Ping timeout: 264 seconds]
03:51 -!- Qfwfq [~WashIrvin@unaffiliated/washirving] has joined #bitcoin-wizards
03:51 -!- c0rw|work is now known as c0rw1n
03:57 -!- nubbins` [~leel@stjhnf0157w-047055221135.dhcp-dynamic.FibreOp.nl.bellaliant.net] has joined #bitcoin-wizards
03:57 -!- nubbins` [~leel@stjhnf0157w-047055221135.dhcp-dynamic.FibreOp.nl.bellaliant.net] has quit [Changing host]
03:57 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
04:02 -!- shesek [~shesek@77.125.14.5] has joined #bitcoin-wizards
04:05 -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 264 seconds]
04:17 -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards
04:17 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
04:26 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
04:42 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds]
04:51 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: Sleeping]
04:57 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
05:13 -!- rdponticelli [~quassel@gateway/tor-sasl/rdponticelli] has joined #bitcoin-wizards
05:14 -!- Grishnakh [~grishnakh@dsl-espbrasgw1-50dfb6-218.dhcp.inet.fi] has joined #bitcoin-wizards
05:19 -!- bit2017 [~linker@113.161.87.238] has joined #bitcoin-wizards
05:23 -!- coiner [~linker@113.161.87.238] has quit [Ping timeout: 258 seconds]
05:24 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
05:29 -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Remote host closed the connection]
05:29 -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards
05:33 -!- cbeams_ [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards
05:33 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer]
05:37 -!- AaronvanW [~ewout@255pc208.sshunet.nl] has quit [Remote host closed the connection]
05:42 -!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has joined #bitcoin-wizards
05:42 -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards
05:54 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:350e:1093:a0ee:57ed] has quit [Ping timeout: 258 seconds]
05:54 -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 255 seconds]
06:00 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:350e:1093:a0ee:57ed] has joined #bitcoin-wizards
06:04 -!- luny [~luny@unaffiliated/luny] has quit [Read error: Connection reset by peer]
06:05 -!- koshii [~0@50.151.108.101] has joined #bitcoin-wizards
06:06 -!- koshii [~0@50.151.108.101] has quit [Client Quit]
06:08 -!- luny [~luny@unaffiliated/luny] has joined #bitcoin-wizards
06:19 -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards
06:21 -!- folksngo1ts [~gues@se5x.mullvad.net] has quit [Quit: leaving]
06:23 -!- Qfwfq [~WashIrvin@unaffiliated/washirving] has quit [Ping timeout: 264 seconds]
06:29 -!- Qfwfq [~WashIrvin@unaffiliated/washirving] has joined #bitcoin-wizards
06:33 -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards
06:37 -!- fanquake [~anonymous@unaffiliated/fanquake] has left #bitcoin-wizards []
06:38 -!- koshii [~0@50.151.108.101] has joined #bitcoin-wizards
06:38 -!- koshii [~0@50.151.108.101] has quit [Client Quit]
06:43 -!- koshii [~0@50.151.108.101] has joined #bitcoin-wizards
06:47 -!- koshii [~0@50.151.108.101] has quit [Client Quit]
06:48 -!- koshii [~0@50.151.108.101] has joined #bitcoin-wizards
06:53 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:8c3a:e13b:e5ac:9702] has joined #bitcoin-wizards
06:55 -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
06:57 -!- OX3 [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 255 seconds]
06:59 -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards
07:00 -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards
07:01 -!- AaronvanW [~ewout@255pc208.sshunet.nl] has joined #bitcoin-wizards
07:03 -!- paulpaschos [~paul@206.223.168.190] has quit [Client Quit]
07:06 -!- bit2017 [~linker@113.161.87.238] has quit [Ping timeout: 258 seconds]
07:08 < andytoshi> in case anyone is curious there are 15103496 utxos right now. i don't know what the total that ever existed is (it would be easy but my rust toolchain is not working right now so i can't change my code..)
07:09 -!- OX3___ [~OX3@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards
07:09 -!- nullbyte [~WW@unaffiliated/loteriety] has joined #bitcoin-wizards
07:11 -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards
07:11 -!- OX3_ [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Ping timeout: 250 seconds]
07:12 -!- paulpaschos [~paul@206.223.168.190] has quit [Remote host closed the connection]
07:13 -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards
07:16 < sipa> i have 15097494
07:16 < kanzure> huh i am not even 0.006%
07:17 < sipa> ?
07:17 < kanzure> thought i had proportionally more outputs than that
07:17 < sipa> haha
07:18 < kanzure> nope nevermind i am just bad at math
07:21 -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
07:22 -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards
07:27 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
07:28 -!- wallet42 [~wallet42@f052161246.adsl.alicedsl.de] has quit [Quit: Leaving.]
07:29 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
07:36 -!- Quanttek [~quassel@ip1f12eb0d.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
07:37 -!- Quanttek [~quassel@ip1f12eb0d.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
07:40 -!- Cory [~Cory@unaffiliated/cory] has quit [Read error: Connection reset by peer]
07:43 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-wizards
07:46 -!- coiner [~linker@118.69.162.103] has joined #bitcoin-wizards
07:55 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
07:55 -!- Quanttek [~quassel@ip1f12ef56.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
07:58 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!]
08:01 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards
08:01 -!- Quanttek [~quassel@ip1f12ef56.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds]
08:11 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has quit [Quit: Leaving.]
08:12 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards
08:20 -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
08:25 -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards
08:26 -!- Quanttek [~quassel@ip1f12e8e8.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
08:26 -!- paulpaschos [~paul@206.223.168.190] has quit [Client Quit]
08:27 -!- Quanttek [~quassel@ip1f12e8e8.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
08:28 -!- Qfwfq [~WashIrvin@unaffiliated/washirving] has quit [Ping timeout: 250 seconds]
08:31 -!- Quanttek [~quassel@2a02:8108:d00:870:993a:1c88:3499:1380] has joined #bitcoin-wizards
08:32 -!- Quanttek [~quassel@2a02:8108:d00:870:993a:1c88:3499:1380] has quit [Read error: Connection reset by peer]
08:33 -!- Qfwfq [~WashIrvin@unaffiliated/washirving] has joined #bitcoin-wizards
08:34 -!- Quanttek [~quassel@ip1f12ed6c.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
08:35 -!- Quanttek_ [~quassel@ip1f11245c.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
08:39 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:350e:1093:a0ee:57ed] has quit [Ping timeout: 258 seconds]
08:39 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!]
08:39 -!- Quanttek [~quassel@ip1f12ed6c.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds]
08:40 -!- Quanttek_ [~quassel@ip1f11245c.dynamic.kabel-deutschland.de] has quit [Ping timeout: 272 seconds]
08:41 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards
08:47 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has quit [Ping timeout: 256 seconds]
08:47 -!- paulpaschos [~paul@206.223.168.190] has joined #bitcoin-wizards
08:47 -!- profreid [~profreid@a88-115-210-162.elisa-laajakaista.fi] has joined #bitcoin-wizards
08:52 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!]
08:53 -!- ryanxcharles [~ryanxchar@162.245.22.162] has joined #bitcoin-wizards
08:57 < andytoshi> sipa: i'd expect you are right
08:57 < andytoshi> iirc my counts do not go down during reorgs
08:58 < andytoshi> (which is a bug, not deliberate)
09:01 -!- nullbyte [~WW@unaffiliated/loteriety] has quit [Ping timeout: 256 seconds]
09:02 -!- profreid [~profreid@a88-115-210-162.elisa-laajakaista.fi] has quit [Read error: Connection reset by peer]
09:03 -!- nullbyte_ [~WW@unaffiliated/loteriety] has joined #bitcoin-wizards
09:04 -!- nullbyte_ is now known as Guest27678
09:05 -!- nuke1989 [~nuke@ppp-2-87-143-28.home.otenet.gr] has quit [Ping timeout: 244 seconds]
09:05 -!- llllllllll [~lllllllll@37-251-2-42.FTTH.ispfabriek.nl] has quit []
09:06 -!- Quanttek [~quassel@ip1f11245c.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
09:07 -!- Quanttek [~quassel@ip1f11245c.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
09:07 < sipa> andytoshi: and it doesn't exclude pruned outputs
09:08 -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
09:09 -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has joined #bitcoin-wizards
09:10 -!- bitstein [~bitstein@198.144.158.13] has joined #bitcoin-wizards
09:12 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has quit [Read error: Connection reset by peer]
09:13 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards
09:20 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
09:31 < NewLiberty> Still, it might be a useful bug.
09:32 < andytoshi> iirc mine doesn't exclude pruned outs either, i could be misremembering
09:32 < NewLiberty> So long as you also have the pruned set.
09:33 < NewLiberty> the diff would be interesting
09:34 < andytoshi> why would i keep the pruned set around? the diff is not super interesting, almost all the pruned outs are op_returns
09:34 < andytoshi> i spent a ton of time writing an unspendability prover and it turned out to be really not useful :)
09:35 -!- OX3___ [~OX3@gateway-nat.fmrib.ox.ac.uk] has quit [Remote host closed the connection]
09:36 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
09:38 -!- Quanttek [~quassel@2a02:8108:d00:870:993a:1c88:3499:1380] has joined #bitcoin-wizards
09:41 -!- paulpaschos [~paul@206.223.168.190] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
09:42 -!- op_null [~op_null@178.62.133.216] has joined #bitcoin-wizards
09:43 -!- Dizzle [~diesel@70.114.207.41] has joined #bitcoin-wizards
09:45 < op_null> gmaxwell: I quite like parts of the "Deanonymisation of clients in Bitcoin P2P network" paper, particularly abusing addr messages to estimate the number of connections to a node.
09:47 -!- bitstein [~bitstein@198.144.158.13] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:50 < op_null> I think there's quite a good justification for people doing more interesting setups of their nodes just to mess with this sort of analysis. they'd probably struggle with any node that also used bluematt's fast transaction relay for example, as it can usually outrace the P2P network on most transactions.
09:50 < amiller> op_null, if you liked that, you'll like my upcoming paper too
09:51 < op_null> similar sort of stuff, or just equally interesting?
09:51 < amiller> similar stuff
09:51 < op_null> I've long been interested in the number of sniffer peers that roam the network.
09:52 < op_null> (to define that, peers which are not normal nodes, pretend to be /Satoshi/, download all inventory but send nothing back)
09:53 < op_null> but yes, I'll be more than interested to read it
09:53 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has quit [Read error: Connection reset by peer]
09:53 -!- lclc is now known as lclc_bnc
09:53 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards
09:54 < amiller> there are a handful of nodes that appear to connect to absolutely everyone, markets.blockchain.info is one
09:56 < op_null> blockchain.info's nodes are quite funny actually. they're terribly modified 0.7.x branches of the Satoshi client, the connection limit raised, mempool disabled, and all of the timings in the reconnection section removed.
09:57 < amiller> op_null, how do you know that? i didn't look for source for their actual node
09:59 < op_null> amiller: it's not published, you can just see from their network behaviour what it is. if you don't filter their servers you almost always end up being connected to by them. if you want their IP addresses you just look at https://blockchain.info/connected-nodes until you appear on them.
09:59 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has quit [Read error: Connection reset by peer]
09:59 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards
10:00 < amiller> yeah
10:01 -!- licnep [uid4387@gateway/web/irccloud.com/x-qnnyvzavenwylxbe] has joined #bitcoin-wizards
10:02 < op_null> for a while they had all the transaction validity checks disabled in order for Mt Gox's invalid transactions to show up in their block explorer. https://people.xiph.org/~greg/21mbtc.png
10:03 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 256 seconds]
10:04 -!- JeremieDeNoob [~jeremiede@modemcable026.213-130-66.mc.videotron.ca] has joined #bitcoin-wizards
10:04 < JeremieDeNoob> how does the address system work? is an ip address encoded in the address data or is the address registered on the network by the user who creates it?
10:04 -!- adam3us1 [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards
10:04 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has quit [Read error: No route to host]
10:06 < op_null> JeremieDeNoob: addresses are discovered in 3 ways depending how the node is operating. they attempt to use their own rumoured lsit of peers from previous runs, if that fails they use DNS to connect to a seed to find more valid IP addresses, and if that fails they attempt to connect to hardcoded peers.
10:07 < op_null> with the rumouring system peers choose to announce themselves to their peers, or not, depending how the node is configured.
10:09 -!- woah [~woah@75.101.111.82] has joined #bitcoin-wizards
10:10 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
10:11 < JeremieDeNoob> hmmm
10:11 < JeremieDeNoob> and what happens if you send coins to a non existant address?
10:11 < op_null> this is probably more a question for #bitcoin.
10:12 < andytoshi> JeremieDeNoob: #bitcoin please
10:12 < andytoshi> this is a research channel
10:12 -!- nuke1989 [~nuke@ppp-2-87-136-239.home.otenet.gr] has joined #bitcoin-wizards
10:22 -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has quit [Ping timeout: 240 seconds]
10:23 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards
10:24 -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection]
10:24 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards
10:27 -!- Guest48334 is now known as artifexd
10:27 -!- artifexd [sid28611@gateway/web/irccloud.com/x-bfhigtkjnzpisipb] has quit [Changing host]
10:27 -!- artifexd [sid28611@unaffiliated/artifexd] has joined #bitcoin-wizards
10:27 -!- artifexd [sid28611@unaffiliated/artifexd] has quit [Changing host]
10:27 -!- artifexd [sid28611@gateway/web/irccloud.com/x-bfhigtkjnzpisipb] has joined #bitcoin-wizards
10:28 -!- dansmith_btc2 [dansmith3@knows.the.cops.are.investigat.in] has quit [Remote host closed the connection]
10:34 -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has joined #bitcoin-wizards
10:34 -!- Sub|zzz is now known as SubCreative
10:41 -!- cbeams_ is now known as cbeams
10:41 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]
10:41 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
10:46 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
10:46 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
10:48 -!- maraoz [~maraoz@186.137.72.181] has joined #bitcoin-wizards
10:58 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
11:11 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
11:14 -!- hashtag_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards
11:17 -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 255 seconds]
11:20 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
11:22 -!- Dizzle__ [~diesel@70.114.207.41] has joined #bitcoin-wizards
11:23 < sl01_> G
11:25 -!- Dizzle [~diesel@70.114.207.41] has quit [Ping timeout: 264 seconds]
11:27 -!- Starduster_ [~Guest1@unaffiliated/starduster] has joined #bitcoin-wizards
11:30 -!- Starduster [~Guest1@unaffiliated/starduster] has quit [Ping timeout: 240 seconds]
11:31 -!- maraoz [~maraoz@186.137.72.181] has quit [Ping timeout: 255 seconds]
11:32 -!- maraoz [~maraoz@186.137.72.181] has joined #bitcoin-wizards
11:34 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
11:38 -!- MoALTz_ [~no@user-164-126-106-206.play-internet.pl] has quit [Quit: Leaving]
11:45 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
11:50 -!- AaronvanW [~ewout@255pc208.sshunet.nl] has quit [Remote host closed the connection]
11:54 -!- adam3us1 [~Adium@host-92-19-90-29.as13285.net] has quit [Quit: Leaving.]
11:55 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards
12:03 -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has joined #bitcoin-wizards
12:12 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:8c3a:e13b:e5ac:9702] has quit [Ping timeout: 258 seconds]
12:15 -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
12:18 -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has joined #bitcoin-wizards
12:23 -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has joined #bitcoin-wizards
12:30 -!- orik [~orik@remote.snococpa.com] has joined #bitcoin-wizards
12:34 -!- mkarrer [~mkarrer@193.Red-79-155-137.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer]
12:35 -!- mkarrer [~mkarrer@193.Red-79-155-137.dynamicIP.rima-tde.net] has joined #bitcoin-wizards
12:38 -!- xmk3 [~xmk3@unaffiliated/xmk3] has quit [Quit: foo]
12:40 -!- sl01_ [~sl01@li431-44.members.linode.com] has quit [Ping timeout: 256 seconds]
12:42 -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Remote host closed the connection]
12:47 -!- sl01 [~sl01@li431-44.members.linode.com] has joined #bitcoin-wizards
12:48 < pigeons> another proof of stake blog post from vitalik
12:49 -!- OX3_ [~OX3@host86-147-77-244.range86-147.btcentralplus.com] has joined #bitcoin-wizards
12:50 < op_null> "..particularly with regard to the supposedly fundamental “nothing at stake” problem. As it turns out, however, the problems are solvable.."
12:52 < pigeons> the solution for new nodes appearing on the network that don't know the current state is to ask blockchain.info ;P
12:53 < pigeons> really says that
12:54 < gmaxwell> yes, indeed many systems work just fine if you invoke centeralization. Of course you can also dispense with the blockchain, mining, etc, entirely under that model.... and in doing so get something much more scalable.
12:54 < andytoshi> does pos.pdf say this? "obviously you can evade this by changing the security model"
12:55 < andytoshi> actually w/e, if that needs to be said the reader is hopeless
12:55 < andytoshi> or shilling
12:55 < op_null> pigeons: oh hell it does say to trust blockchain.info.
12:56 < kanzure> andytoshi: i think saying that is quite relevant
12:57 < gmaxwell> andytoshi: I thought it was clear enough; but perhaps that point deserves to be made more clear... not because the real audience of the paper needs to hear it, but because it's used by confused or dishonest people to be overly dismissive.
12:57 < sl01> "This security assumption, the idea of “getting a block hash from a friend”, may seem unrigorous to many; Bitcoin developers often make the point that if the solution to long-range attacks is some alternative deciding mechanism X, then the security of the blockchain ultimately depends on X, and so the algorithm is in reality no more secure than using X directly"
12:57 < kanzure> andytoshi: to someone trying to think about distributed consensus, it may not be obvious to them that the solution is to not use distributed consensus
12:57 < sl01> "However, this logic ignores why consensus algorithms exist in the first place. Consensus is a social process, "
12:58 < kanzure> whether or not it is a social process will not violate relativity
12:58 < andytoshi> gmaxwell: i'll think about it. kanzure made a point to me last night that my documents are not really structured for the target audience we currently have for them
12:59 -!- OX3_ [~OX3@host86-147-77-244.range86-147.btcentralplus.com] has quit [Ping timeout: 244 seconds]
12:59 < kanzure> right, something like "your readers hate you"
12:59 < andytoshi> that is, they were written for people who wanted to be wizards, not laypeople dealing with well-funded charlatons..
12:59 < gmaxwell> to some extent this is making the same mistake that the patent office makes in thinking that an algorithim running in the mind of a man is fundimentally different than running in semiconductors.
12:59 -!- OX3_ [~OX3@host86-144-45-255.range86-144.btcentralplus.com] has joined #bitcoin-wizards
12:59 < kanzure> yes, people do not have magical relativity violating powers
12:59 < gmaxwell> andytoshi: well tis not our remit to save everyone from charlatons.
13:00 < kanzure> certainly
13:00 < op_null> andytoshi: your documents do well arguing to say, a hacker news reader.
13:01 < gmaxwell> andytoshi: Surely we'd like to do some of that as a side effect; but at least what I've thought much of the goal was being able to sync up people like e.g. kanzure with basic premises we understand.
13:01 < kanzure> instead of writing "You are wrong because X" it may be more helpful to write "Here are some things that are important, and here is what Bitcoin does, and here is why some related proposals are totally broken and not worth your attention. Sorry if it wasn't apparent that this was contested, but I can't be held responsible for the levels of junk out there."
13:01 < moa> well the algorithm running in a semiconductor can be objectively measured and has different physical constraints
13:01 -!- AaronvanW [~ewout@255pc208.sshunet.nl] has joined #bitcoin-wizards
13:02 < kanzure> (the apology is not necessary of course)
13:02 < gmaxwell> moa: this isn't really making the case though... I mean, it makes the case for more "Computational security against review", perhaps, but I doubt security against review should be anyone's goal. :)
13:02 < pigeons> usaully the repsonse i get to andy's papers are "he didn't talk about ~my~ PoS algorithm or ~my~ twist on making an asic resistant system"
13:02 < op_null> andytoshi: I'm not sure how much contact you have with altcoins, but there's an interesting behaviour that's developed around pos.pdf now. it's seen as the "FUDers post this but they're wrong" easy way out of the argument, because of course NXT has solved all of those problems but the author is too dumb to realise it.
13:03 < kanzure> andytoshi: arguably bram doesn't want to be a layperson, and he was extremely put off by the "Is ASIC resistance desirable? No." format to the point of not even reading past that.
13:03 < andytoshi> op_null: i've seen responses on reddit which dismiss it, but never ever a coherent argument
13:03 < andytoshi> about a single sentence
13:04 < kanzure> "NXT exists and works because centralization" might have to be made more obvious
13:04 < andytoshi> which makes me suspect that none of them have actually read it, because i have and found some typos, and there is no way i was totally correct in a document i one-shotted in an 8 hour "i should finally teach myself what pos is about" session
13:04 < gmaxwell> well again, the point of the document as it stands is not to argue that case against every carnie; ... it's sadly infeasable to do that because they're adaptive and unbounded in number.
13:04 -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has left #bitcoin-wizards []
13:04 < op_null> andytoshi: I don't think you'll get one out of NXT supporters in particular. they can't even describe their security decisions let alone how your document doesn't apply to them. their misgivings hinge on the fact that NXT now doesn't allow reorgs, which is the basis of their security assumptions now to some degree.
13:04 < kanzure> (of course, you don't have to say NXT explicitly. just "you can use centralization if you want, but the other parts become irrelevant and pointless")
13:04 < helo> carnie >.>
13:04 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection]
13:05 -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has quit [Ping timeout: 256 seconds]
13:05 < kanzure> gmaxwell: how would you explain bram's eyebrow dismissal then?
13:05 < gmaxwell> helo: "get your popcoin, peanuts! altcoins gets your altcoins! hot salted altcoins! come see the bearded lady! hot salted altcoins"
13:05 < andytoshi> op_null: so, my response to that is simply "what the actual fuck", i unfortunately have developed an emotional allergy to trying to parse such confusion, so i don't
13:05 < helo> haha
13:05 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
13:05 < kanzure> arguably bram is someone that matches the target demographic
13:05 < op_null> andytoshi: it's of course all well and good that people have to do manual reorganisations, but like vitaliks post it means that new people joining the network still have to "phone a friend" to get consensus.
13:06 < andytoshi> bram is, and i think we were pretty successful with him once we convinced him we were not morons and he should maybe read our stuff
13:06 < kanzure> yes but it involved one-on-one hand holding
13:06 < kanzure> and he did look at the paper, but then dismissed it immediately because it disagreed with him blatantly ("Is asic resistance desirable? No.")
13:06 -!- OX3_ [~OX3@host86-144-45-255.range86-144.btcentralplus.com] has quit [Read error: Connection reset by peer]
13:06 < gmaxwell> kanzure: he dismiseed it out of hand with a really powerfully bad bit of reasoning. Not sure there is much to do about that.
13:06 < andytoshi> well, he is uniquely qualified to be dismissive..
13:07 < kanzure> i think that if the first word was not "no" he may have read on :)
13:07 < andytoshi> so some hand-holding does not worry me
13:07 < op_null> gmaxwell: expecting a lady and getting a drunken, shaved bear pretty well sums up altcoins.
13:07 < gmaxwell> I'd agree that he's in the target audience, but to some extent on the fringe of it.
13:07 < moa> vanguard maybe
13:08 < gmaxwell> op_null: "You can do this one out of every 30 times and still have 97% positive feedback."
13:08 < op_null> gmaxwell: wait that was pig faced woman, not bearded ladies that were shaven bears.
13:09 < gmaxwell> kanzure: (wrt fringe) I mean to the extent that his interest in patience in learning what is already known is demonstratively low.
13:09 < gmaxwell> maybe improving now that he's (maybe) less dismissing everyone involved in bitcoin as idiots.
13:10 < kanzure> sure maybe he thought all of the altcoin-motivated-stuff was bitcoin
13:11 < kanzure> maybe making an outline of things that are already known would be helpful
13:11 < kanzure> and then references/links to irc logs (or whatever else) can be added later as they turn up
13:11 -!- OX3_ [~OX3@host109-153-169-240.range109-153.btcentralplus.com] has joined #bitcoin-wizards
13:12 < op_null> why is vitalik still going on about ASIC resistance too?
13:12 < kanzure> i wonder if someone can replace nxt (and related) with thin clients connecting to a central server, and convince users to switch somehow
13:12 < moa> like an O'Reilly's for bitcoin maybe?
13:12 < tromp_> Is ASIC resistance desirable? One kind of resistance is, the other is not.
13:13 < op_null> tromp_: I'm pretty sure you have that term set as a ping in your client :)
13:13 < Luke-Jr> tromp_: it's undesirable and impossible in theory
13:13 < Luke-Jr> s/in theory/by definition/
13:13 < tromp_> my client only pings for tromp:(
13:13 < gmaxwell> tromp_: when you also considering botnets and amazon, it's not clear to me that any kind is. But I full agree thats debatable.
13:13 < gmaxwell> Luke-Jr: impossibility doesn't imply undesirablity. :)
13:14 < Luke-Jr> gmaxwell: I know, but it's both :p
13:14 < helo> paypal is not centralized nxt?
13:14 < gmaxwell> kanzure: how do you know they haven't already?
13:14 < op_null> kanzure: there's at least one altcoin that is pretty much that.
13:14 < Luke-Jr> helo: only if owning PP currency meant you had PayPal stock?
13:14 < tromp_> the kind thats not desirable is having a complex compute intensive pow requiring a very elaborate asic design
13:15 < kanzure> gmaxwell: because then they would be less intersecting the bitcoin world, i would hope
13:15 < helo> hmmm
13:15 < tromp_> that's the kind inviting the No response
13:15 < op_null> kanzure: there's one which is like 100k lines of obfsucated javascript with hardcoded passwords. for all we know it's totally centralised, and yes it's a traded thing that people use as a real altcoin.
13:15 < Taek> Paypal has a federated 2 way peg with the US dollar
13:15 < gmaxwell> tromp_: you can seperate that further, complex design (NRE frontloading) is undesirable and potentially quite harmful, because it eliminates competition for hardware.
13:16 < gmaxwell> Taek: except as a federation it's particularly sucky, as it's a single party.
13:16 < gmaxwell> and it's unauditable.
13:16 < gmaxwell> And even if you can prove they've violated the protocol, it has no effect.
13:17 -!- OX3_ [~OX3@host109-153-169-240.range109-153.btcentralplus.com] has quit [Remote host closed the connection]
13:17 < tromp_> the other kind is that any conceivable (in familiar process technology) ASIC design won't have a huge performance gap with commodity hardware
13:17 < tromp_> i would say that kind is desirable
13:17 < Taek> gmaxwell: if PayPal acts sufficiently dishonestly the FBI will get involved, so it's not exclusively 1 party
13:17 < Luke-Jr> tromp_: now explain what stops me from taking the commodity hardware and removing the parts I don't need to make an ASIC that performs better
13:18 < helo> heh, it would be interesting if centralized-nxt had a split between "everyone else" and the central point
13:18 < Luke-Jr> tromp_: the only way to do that is to make the commodity hardware *be* the ASIC itself - but that's not ASIC resistence, it's ASIC-is-already-deployed
13:18 < tromp_> ok, Luke, imagine a cheap octa-core arm that has siphash as a native instruction
13:18 < tromp_> you could hook that up to some dram chips and run cuckoo well.
13:18 < Luke-Jr> tromp_: then you've got the rest of the ARM core eating electricity, producing heat, and slowing it down
13:19 < gmaxwell> tromp_: maybe there should be a flowchart. I think that if/once you get down to gap reduction it's still not a closed argument, because botnets and commidity hardware; more considerations show up.
13:19 < tromp_> or run the cuckoo logic on an fpga
13:20 < tromp_> the mining cost may still be dominated by dram cost
13:20 < op_null> FPGA have an annoyingly high cost for their speed
13:20 < tromp_> but cuckoo doesn't need much speed! only enough to saturate the dram
13:20 < Luke-Jr> IIRC some FPGA patents are expiring soon? ;)
13:20 < gmaxwell> Luke-Jr: yea... hopefully the fpga market should heat up.
13:21 < tromp_> any exotic ram, even if faster, will not be cost competitive
13:21 -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has quit [Quit: leaving]
13:22 < tromp_> Luke, that arm core could produce less heat than the dram it's keeping busy
13:22 < op_null> isn't the power consumption of dram almost nothing?
13:23 -!- licnep [uid4387@gateway/web/irccloud.com/x-qnnyvzavenwylxbe] has quit [Quit: Connection closed for inactivity]
13:23 < tromp_> my claim is that $100 worth of custom hardware will not be orders of magnitude more efficient than $100 of commodity hardware
13:23 < tromp_> which will keep many people mining on their existing hardware, even at a loss
13:24 -!- Dizzle [~diesel@70.114.207.41] has joined #bitcoin-wizards
13:24 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
13:24 < gmaxwell> tromp_: I have bitmain S1 miners here, underclocked as they are they're less than half as power efficient as my spoondooles S10... but they are turned off.
13:25 < gmaxwell> er not less than half.
13:25 < gmaxwell> (they're about 75% as power efficient)
13:25 < tromp_> yes, gmaxwell, but they're just obsolete custom hardware
13:25 < tromp_> people don't turn off their desktop just because it's 2 years old
13:26 < tromp_> it still works fine for them
13:26 < gmaxwell> They stopped cpu mining with bitcoin while it was still power-profitable to do so, even at $0.3/kwh.
13:26 -!- Dizzle__ [~diesel@70.114.207.41] has quit [Ping timeout: 258 seconds]
13:27 < tromp_> the commodity-custom gap is just way too big for bitcoin, and for scrypt as well
13:27 < gmaxwell> Pretty sure I was the last guy left still cpu mining (with my gobbs of opteron cores), meanwhile people were all actively telling each other that cpu mining was stupid and pointless. We don't need to speculate about this.
13:27 < moa> how can a computer authenticate that it is interfacing/communicating with a human?
13:28 < helo> moa: an oracle
13:28 -!- AnoAnon [~AnoAnon@197.37.73.249] has joined #bitcoin-wizards
13:28 < kanzure> (you have to cheat)
13:28 -!- AnoAnon [~AnoAnon@197.37.73.249] has quit [Read error: Connection reset by peer]
13:28 < moa> like a reverse turing test?
13:28 < op_null> tromp_: I think you are overestimating memory power usage somewhat. a random chip I picked off mouser screams along at 1.6GHz and draws 0.4W while doing it. 1.6W/GB or something like that.
13:29 < tromp_> yes, it's on the order of 1W per  memory chip
13:30 < kanzure> moa: no
13:30 < tromp_> but an arm core won't have to do many siphashes to saturate that memory chip and could easily use less than 1W
13:31 < tromp_> an fpgu would do it with milliwatts
13:31 < tromp_> fpga
13:32 < op_null> that's still a lot better than my PC hardware. it draws something like 75W at idle.
13:32 < Eliel> gmaxwell: Well, it's probably not worth the time to keep checking that the miner is still running fine if you don't make at least some minimum amount per day.
13:34 < gmaxwell> Eliel: turns out that general desktop users get really unhappy if their computer is busy, and they do actually turn them off, don't like the noise they make when not suspended, etc. (The reason the ltcscrypt has such a small size is because larger thrashed caches so bad that it hurt interactivity, even running as an idle background task, apparently; or so said art)
13:34 < moa> so anybody wondered about working an oracle into a mining algorithm?
13:35 -!- NewLiberty [~NewLibert@2602:30a:c0a9:c3e9:7cc4:b642:6b45:6967] has joined #bitcoin-wizards
13:38 < BlueMatt> amiller: yea, theres also that guy on the forum who seems to have a passion for connecting to everyone just because he can
13:38 < amiller> BlueMatt, who?
13:38 < BlueMatt> amiller: also, IIRC, (s)he doesnt do any procesing of data before relaying
13:38 < op_null> amiller: /Snoopy0.1/
13:38 < amiller> oh yeah snoopy
13:38 < BlueMatt> no, not snoopy
13:38 < BlueMatt> gangnam style
13:39 < BlueMatt>  /nogleg
13:39 < kanzure> andytoshi: check out page 2 second to last paragraph http://www.chroem.net/VAPUR.pdf (not sure if this is novel)
13:39 < op_null> there's at least 4 of them. one badly pretends to be Satoshi but mucked up the version name.
13:39 < BlueMatt> snoopy is the eth guys, no?
13:39 < kanzure> "use this hash of the request to determine which nodes will be responsible for arbitration"
13:39 < helo> moa: the oracle is a centralized point of trust by definition
13:39 < kanzure> oh that's not repeatable, hm
13:39 < helo> so it kinda depeats the purpose :)
13:40 < moa> not the oracle we are looking for
13:40 < op_null> BlueMatt: no, I don't think it's Ethereum related at all.
13:40 < BlueMatt> op_null: huh? nooooo, eth zurick
13:40 < BlueMatt> zurich, that is
13:40 < gmaxwell> BlueMatt: well it's easy to make noleg vanish off the network, just relay a transaction with a bad signature to it and everyone bans it.
13:41 < BlueMatt> gmaxwell: yes
13:41 -!- maraoz [~maraoz@186.137.72.181] has quit [Ping timeout: 264 seconds]
13:41 < BlueMatt> op_null: tell me ethereum isnt trying to use the eth symbol :(
13:41 < BlueMatt> ever heard of googleing before selecting a name?
13:42 < op_null> BlueMatt: oh no, sorry I extended eth to ethereum.
13:42 -!- maraoz [~maraoz@186.137.72.181] has joined #bitcoin-wizards
13:42 < op_null> BlueMatt: but yes, they do use ETH as their shorter name for Ethereum
13:42 < BlueMatt> gmaxwell: someone should run a node behind some regular-changing-ip that relays invalid signatures to all nodes with strange version messages
13:43 < BlueMatt> gmaxwell: ie someone in .de behind deutsche telekom who gets a new ip every 24 hours whether they like it or not (not sure if they still do that...they used to)
13:43 < op_null> BlueMatt: people might have tried that already :>
13:44 < op_null> not on a wide scale, just to see if a particular node relays them (it didn't)
13:47 < kanzure> this section of http://www.chroem.net/VAPUR.pdf seems very likely to be broken or wrong: "In other blockchain implementations, nodes creating new blocks are free to put whatever content"
13:47 < kanzure> something about not allowing new peers unless existing peers agree?
13:49 < kanzure> *existing peers agree to allow the new peer
13:49 -!- Dizzle__ [~diesel@70.114.207.41] has joined #bitcoin-wizards
13:50 < kanzure> i don't think "reverse sybil attack" is quite the right name for "an arbitrary compatible history"
13:52 < gmaxwell> kanzure: so hard to not just completely ignore things that can't bother to get even the most simple details right.
13:52 -!- Dizzle [~diesel@70.114.207.41] has quit [Ping timeout: 258 seconds]
13:53 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
13:53 < op_null> gmaxwell: doesn't stop that sort of thing from getting funding though, nobody else can see the red flags :(
13:53 -!- bramm [~bram@38.99.42.130] has joined #bitcoin-wizards
13:54 < bramm> Hey everybody
13:54 < tromp_> hi, Bram
13:54 < kanzure> oh had i known that they received funding i wouldn't have bothered looking
13:54 -!- nuke1989 [~nuke@ppp-2-87-136-239.home.otenet.gr] has quit [Ping timeout: 244 seconds]
13:54 < BlueMatt> we need a pre-funding #bitcoin-wizards arbitration system
13:54 < bramm> Oh hey Tromp, I wanted to ask you some questions about cuckoo
13:54 < tromp_> please do
13:54 < bramm> First, why is the graph bipartite? How does that matter?
13:55 < tromp_> to simplify the algorithm
13:55 < moa> BlueMatt: you could contract the out even
13:55 < op_null> kanzure: careful, I don't know anything about that project and didn't say they'd got funding for it. just in general things with technical red flags aren't picked up by the people who might fund them.
13:55 -!- Dizzle__ is now known as Dizzle
13:55 < bramm> But it could work fine on a non-bipartite?
13:55 < tromp_> otherwise i have to deal with self-loops
13:56 < bramm> Oh right, that makes sense
13:56 -!- nuke1989 [~nuke@ppp-2-87-136-239.home.otenet.gr] has joined #bitcoin-wizards
13:56 < tromp_> but it also simplifies the trimming
13:56 < tromp_> which can alternate between the two sides
13:56 < tromp_> finally, the tmto algorithms that use a breadth first search would get significantly more complex
13:57 < bramm> So the overall view is that it requires N memory, and basically one pass over the whole thing with O(1) random lookups for each element?
13:57 < tromp_> no, there's many passes (rounds of trimming)
13:58 < tromp_> the basic algorithm is single pass though
13:58 < tromp_> and #passes is still constant
13:58 < bramm> I think I understand the basic algorithm, I don't understand the multiple passes thing, it doesn't seem to be in the white paper
13:58 < tromp_> yes, it's the edge trimmming section
13:59 < tromp_> although it doesn't say much on number of rounds, i think
14:00 < tromp_> the trimming just has to get the fraction of edges down to like 2%
14:00 < bramm> Oh I see, I assumed that that was just as single pass, I'll have to process it
14:01 < tromp_> no, trimming is in fact the majority of runtime (>98%)
14:01 < bramm> So when you're done trimming everything remaining is in loops and it's a matter of finding a loop of the right length?
14:01 < tromp_> no, many paths remain
14:02 < tromp_> trimming just cuts of edges near leaves
14:02 -!- hashtag_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 265 seconds]
14:02 < tromp_> cuts off
14:02 < tromp_> which happens to be the vast majority of edges
14:02 < bramm> How can there be any nodes which aren't part of a loop if all terminal nodes have been removed?
14:02 < tromp_> there's like a dozen rounds of trimming
14:03 < tromp_> it doesn't remove all leaf edges
14:03 -!- OX3 [~OX3@host109-153-169-240.range109-153.btcentralplus.com] has joined #bitcoin-wizards
14:03 < tromp_> doing that would require thousands of trimming rounds
14:03 -!- NewLiberty [~NewLibert@2602:30a:c0a9:c3e9:7cc4:b642:6b45:6967] has quit [Ping timeout: 258 seconds]
14:03 < tromp_> since you can have such long paths
14:03 < bramm> Oh right
14:04 -!- Dizzle__ [~diesel@70.114.207.41] has joined #bitcoin-wizards
14:04 < tromp_> you just switch to the basic algorithm when you can afford to (memory wise)
14:04 < tromp_> since the basic alg is very efficient at identifying loops)
14:05 < tromp_> did you run the code?
14:05 < bramm> No I've just read the paper and am absorbing it
14:05 < bramm> I'm struck by how special having an average fanout of 1 is
14:06 < tromp_> just git clone and make test, it may be instructive to see it in action
14:07 < tromp_> yes, it's on the threshold between having no and having tons of cycles
14:07 -!- Dizzle [~diesel@70.114.207.41] has quit [Ping timeout: 264 seconds]
14:07 < bramm> Less than that and there are no loops, more than that and they're easy to find
14:08 < tromp_> classic S curve
14:08 -!- Dizzle__ is now known as Dizzle
14:08 -!- OX3 [~OX3@host109-153-169-240.range109-153.btcentralplus.com] has quit [Ping timeout: 244 seconds]
14:09 -!- OX3 [~OX3@host109-150-169-60.range109-150.btcentralplus.com] has joined #bitcoin-wizards
14:09 < bramm> Also all the potential crypto issues people were talking about yesterday are a non-issue. If you secure hash the input before using it to generate nonces then all you're relying on is that hashing for security
14:10 < bramm> I'm much more concerned about the possibility that there might be some clever algorithm which might get rid of all the random lookups
14:11 < tromp_> yes, i find it puzzling that zooko thinks there's anything to be attacked in the internal hash
14:12 < tromp_> algorthmic improvements are the only likely problem
14:12 < bramm> I need to get lunch, be back in a minute with more questions
14:13 < tromp_> in the worst case cuckoo just reduces to having to compute a few billion siphashes
14:20 -!- rdponticelli [~quassel@gateway/tor-sasl/rdponticelli] has quit [Ping timeout: 250 seconds]
14:21 < bramm> Yes but what's really interesting is the random memory accesses
14:21 -!- OX3 [~OX3@host109-150-169-60.range109-150.btcentralplus.com] has quit [Ping timeout: 265 seconds]
14:22 < tromp_> yes, those are hard to avoid
14:22 < bramm> We can get the memory usage with a simpler scheme which has a smaller size of proof
14:22 < tromp_> what do yo mean?
14:23 < bramm> Just using 4sum like I suggested will have a proof of work which is less than 200 bits instead of more than 1000
14:24 < bramm> So, here's my thought as to an algorithm for trying to do cuckoo faster, primarily worrying about avoiding random memory accesses:
14:25 < tromp_> why wld you want to avoid rnd accesses?
14:25 -!- OX3_ [~OX3@host86-181-187-243.range86-181.btcentralplus.com] has joined #bitcoin-wizards
14:25 < bramm> As an attacker, trying to do the proofs as quickly as possible, assuming that the random accesses are the expensive thing
14:26 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 265 seconds]
14:26 < bramm> I mean, on the implementation side we want to do as few random accesses as possible to make things fast. I mentioned that shorter proofs thing because *if* it's possible to completely avoid the random accesses in implementation then there are some other proofs of work which might be preferable
14:26 < tromp_> cuckoo aims to make rnd access unavoidable
14:27 < tromp_> and thus makes the pow more power-friendly
14:27 < bramm> Right, we're in agreement on this
14:27 < bramm> So here's my thought about a way of finding the loops which might avoid a lot of the random accesses:
14:28 < bramm> First we make a list of all nodes which it's possible to reach after exactly one hop, and a back pointer for each from where it came from
14:28 < bramm> Then we sort these
14:28 < tromp_> bramm., did you read the sections on TMTO algorithms?
14:29 < tromp_> you're proposing a variation on those. but they're not memory competitive with the trimming algorithm
14:30 -!- OX3_ [~OX3@host86-181-187-243.range86-181.btcentralplus.com] has quit [Remote host closed the connection]
14:30 < bramm> Then we make a new list of all the nodes which can be reached after two hops, again including back pointers, and not allowing backtracking to get here, and we again sort that
14:30 < bramm> repeat a certain number of times until the number of nodes left in the list is fairly small, then run the general algorithm
14:31 < bramm> Most of the paper's words have passed before my eyes, that doesn't mean I've understood them all :-)
14:32 < tromp_> you're proposing to speed up the TMTO algorithms by sorting
14:32 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has quit [Remote host closed the connection]
14:32 < bramm> Yes, because sorting avoids random accesses
14:32 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has joined #bitcoin-wizards
14:33 < tromp_> note that those algorithms are over 20x slower to begin with
14:33 < bramm> Well that could kill it right there
14:33 < tromp_> because they dont use memory as efficiently
14:34 < tromp_> you can try modify the source code that i provide
14:34 < tromp_> you can even win a bounty if you speed up the tmto's substantially
14:35 < tromp_> btw, note that my trimming algorithm also does some bucket sorting of accesses
14:36 < tromp_> but the acccesses are still many cache lines apart
14:36 < bramm> Yeah it might be a very similar thing, I'll have to spend more time thinking about it
14:37 < bramm> You can speed up bucket sorting by having separate near and far groupings, so you wait until there are multiple things to put into a far bucket before actually putting stuff there
14:37 < tromp_> so it's not like you're gonna get nice consecutive accesses
14:38 -!- op_null [~op_null@178.62.133.216] has quit [Quit: leaving]
14:40 < bramm> Do you have any idea how to get a closed form formula, or even non-monte-carlo approximation, for the chances of there being a loop of a given length?
14:41 < tromp_> no, i don't
14:41 < tromp_> except for length 2
14:43 < tromp_> but the expected # of such loops should be easy to derive
14:44 < tromp_> just using linearity of expectation
14:44 -!- Dizzle__ [~diesel@70.114.207.41] has joined #bitcoin-wizards
14:45 -!- Dizzle [~diesel@70.114.207.41] has quit [Disconnected by services]
14:45 -!- Dizzle__ is now known as Dizzle
14:45 -!- Quanttek [~quassel@2a02:8108:d00:870:993a:1c88:3499:1380] has quit [Ping timeout: 258 seconds]
14:48 < tromp_> well, good news: cuckoo cycle was accepted for BITCOIN 2015
14:51 < bramm> Good to hear
14:51 -!- orik [~orik@remote.snococpa.com] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
14:57 -!- OX3_ [~OX3@host86-181-187-243.range86-181.btcentralplus.com] has joined #bitcoin-wizards
15:00 < zooko> Yay!
15:00 < bramm> Okay I understand the trimming now but don't follow why it speeds things up. Doesn't it still have to do a random lookup per edge?
15:00 < bramm> zooko, if the input to cuckoo is run though a secure hash before being used your concerns about cryptographic security within the core don't matter
15:01 < bramm> I mean, it's trivial to generate strings which end in a bunch of zeros, we can still use those for proofs of work.
15:01 < tromp_> the trimming is not a speedup but a big memory savings
15:01 < tromp_> the basic algorithm takes 32 or 64 bits per edge
15:01 < tromp_> the trimming only takes 1 bit
15:01 < bramm> Oh right, because the limiting factor on cost is memory?
15:01 < tromp_> yes
15:01 < bramm> I see
15:03 < zooko> If we could figure out how to generate 4 edges from a single blake2s invocation, that would be about twice as efficient as generating 4 edges from 4 siphash-2-4 invocations...
15:03 < bramm> zooko, It doesn't matter, blake2 wins you no security over sip hash
15:04 -!- phantomcircuit [~phantomci@smartcontracts.us] has quit [Ping timeout: 256 seconds]
15:04 < tromp_> zooko, just make a narrow blake2 of width 64 bits
15:04 < zooko> I don't understand why you say that.
15:04 < zooko> tromp: Yeah, that would be fine, and it would be about half as efficient as SipHash-2-4.
15:04 < bramm> zooko, because the existence or not of a cycle is entirely dependent on the security properties of the secure hash which you ran your input though before generating the nonces
15:05 -!- phantomcircuit [~phantomci@smartcontracts.us] has joined #bitcoin-wizards
15:06  * zooko casts Summon lmgoodman
15:06 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has joined #bitcoin-wizards
15:06 -!- orik [~orik@remote.snococpa.com] has joined #bitcoin-wizards
15:07 -!- OX3_ [~OX3@host86-181-187-243.range86-181.btcentralplus.com] has quit [Ping timeout: 258 seconds]
15:07 -!- licnep [uid4387@gateway/web/irccloud.com/x-bxsgacpuydvpnkim] has joined #bitcoin-wizards
15:08 < tromp_> i think these discussions are going nowhere and we just have to agree to disagree on whether attacking cuckoo through lack of security of siphash is at all conceivable
15:09 < tromp_> i dont even understand what bramm just said:(
15:10 < gmaxwell> if it's security irrelevant, replace it with the identity function or x*2862933555777941757+3037000493 mod 2^64
15:10 < gmaxwell> thats much faster than siphash.
15:10 < zooko> I would be happy to try generating a more precise argument, but not right now.
15:10 < zooko> gmaxwell: ;-)
15:10 < gmaxwell> (and less code too)
15:11 -!- coke0 [~coke0@2607:fb90:1f06:f791:2afb:bafc:1ad4:2578] has joined #bitcoin-wizards
15:12 < bramm> gmaxwell, There's a later step of finding the loop, if the function is *too* simple, there may be shortcuts to finding the loop. In particular for a modular function like you propose it would probably have very long chains for trivial mathematical reasons
15:12 < bramm> That said, sip hash is probably overkill - each step of loop finding is analogous to a single feistel round, and sip hash is much stronger than that
15:13 < bramm> tromp_, My point is, if an attacker can put any random stuff directly into the keying of the sip hash which forms the challenge then I'm a bit worried about attacks. If you sha256 it first there's nothing left.
15:13 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection]
15:14 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
15:15 < tromp_> i alrd told zooko he should not hesitate to replace that sha256 step by blake2 :)
15:15 < bramm> Any attacks which are on *finding* the loop have very limited use of cryptography, because the cryptographic attack would have to outperform the alternative, which is to just do the cuckoo algorithm, which is by design fairly easy
15:15 < gmaxwell> "analogous to a single feistel round" is bordering on technobabble.  The point I was making was that the function has security considerations but they're being swept under the rug here.  (and the function I gave intentionally has a period of ~2^62 ... which you may perhaps find to be suboptimal. :P it wasn't a serious proposal)
15:16 < gmaxwell> again, if any attack is a non-consideration, then a trivial function is sufficient.
15:16 < tromp_> gmaxwell: the period is of no interest in cuckoo since there're no repeated hasing
15:18 < tromp_> just a mapping to take a nonce to an edge endpoint
15:18 < bramm> gmaxwell, The only relevant question is whether you can find a 42nd pre image in less than 10 seconds
15:18 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 240 seconds]
15:19 < bramm> That's basically what an attack would boil down to. Anything where you're confident in that and you're fine. Which sip hash is.
15:20 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Read error: Connection reset by peer]
15:20 < gmaxwell> According to what research? ... and why do you assume that this is the only interesting attack?  What happens if an attacker is able to implement the function 100x more power efficiently?
15:21 < bramm> gmaxwell, Power efficiency doesn't matter because the CPU is sitting around bored
15:21 < Luke-Jr> lol
15:22 < bramm> gmaxwell, and 'a single round of feistel' isn't technobabble, the fact that you think that shows that you're unfamiliar with the design of block ciphers
15:22 < Luke-Jr> CPUs have sat around bored for like a decade
15:22 < Luke-Jr> haven't*
15:22 < gmaxwell> I'm familar with the design of block ciphers;  It's technobabble because it says absolutely nothing about security. I know what the words mean, I don't believe that you do, however.
15:23 < bramm> There are common expectations for what a single round of a feistel cipher does, and it's less than siphash
15:24 < bramm> Honestly I can't justify something which has symmetric cipher properties if you dismiss terminology from symmetric ciphers as technobabble
15:24 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
15:25 < gmaxwell> Sure and a modern block cipher is analyized for its properies overall and in reduced round constructions. An arbritary function stuck into a set of lifting steps does not magically make for a block cipher that meets any particular security requirement... nor to I have any reason to think that block cipher security behavior is at all relevant for a POW.
15:25 < gmaxwell> I'm just seeing a lot of irresponsible design work in here today. It's disappointing.
15:25 < moa> probably need a tighter definition of technobabble here
15:26 < bramm> gmaxwell, Have you read through how cuckoo works? The vast majority of crypto concerns one might have simply don't apply
15:26 < bramm> starting with that doing a crypto attack when there's a perfectly normal proof of work as the intentionally designed immediate alternative is ridiculous. This isn't a block cipher.
15:27 < gmaxwell> I read an earlier version of Trom's paper on it. I have a general understanding of it.
15:27 -!- OX3_ [~OX3@host86-181-187-243.range86-181.btcentralplus.com] has joined #bitcoin-wizards
15:27 -!- go1111111 [~go1111111@c-174-61-204-17.hsd1.wa.comcast.net] has joined #bitcoin-wizards
15:27 < gmaxwell> bramm: Glad that you've realized that it isn't a block cipher.
15:29 < gmaxwell> The security concerns are different from a block cipher.  Internal structure in a work function has many times in the past lead to surprising optimizations.  One of the special challenges of work functions is that small optimization factors (like <10x) can still have a huge effect, which is unlike most cryptographic questions where we mostly care about asymptotic differences.
15:29 < bramm> I really don't understand your point. Would you have more confidence in my proposal to use 4sum? That has a much stronger mathematical backing.
15:30 < bramm> gmaxwell, we were just discussing the possible optimizations of implementation of cuckoo, none of them have to do with the prng, that isn't the weak point
15:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
15:31 < gmaxwell> I think it's very concerning that in one breath it's argued that the structure of the internal hash function is irrelevant to security; and then in the next, replacing it with truly trivial (e.g. linear or identity) function is not.  So whats the security criteria one function passes that the other does not?
15:31 < gmaxwell> bramm: someone optimizaing doesn't care what you think is weak they'll use any and all options, and to be secure a function must resist all of them; especially the ones you didn't think of.
15:31 < bramm> It's lacking trivial modular mathematical properties. The sort of things which sip hash is designed specifically to not have
15:32 < bramm> sip hash is meant to be suitable as a keying algorithm in a hash table when an attacker is controlling the inputs, to continue to have even distribution regardless of what the attacker does. That is exactly the property which cuckoo is relying on
15:33 < bramm> You also haven't answered my question about using 4sum
15:33 < gmaxwell> Which properties, specifically, are required?   So you're saying uniformity given attacker controlled but distinct inputs? even though the attacker knows the function?
15:34 < gmaxwell> bramm: the underlying problem is more or less irrelevant to the specifics of optimization; assuming it's well studied in general.
15:34 < gmaxwell> Zooko made the argume above that blake2's uniformity properties had a ton of peer review and this was previously dismissed as inconsequential.
15:35 < bramm> gmaxwell, 4sum is extremely well studied. And the number of inputs into it is small enough that using a cryptographically secure hash for it wouldn't cost a significant amount of cpu
15:35 < bramm> not inconsequential, overkill
15:36 < bramm> And I mean seriously, are you even aware of how many layers of stuff you'd have to break through to attack cuckoo based on the crypto, and how easy the same computations are to do just by doing them?
15:36 < gmaxwell> (I'm mostly just continuing zooko's argument. My own concern are higher level; and more meta. E.g. concern about the wisdom of the specific goals, which reasonable people can disagree on,  and concern with what sounds like a very sloppy and dismissive attitude around security)
15:37 < bramm> gmaxwell, this isn't sloppy. Cuckoo is a coherently thought out and specified primitive. It's being published to be studied. It's based on well known primitives and problems
15:37 < gmaxwell> bramm: I think you are showing a remarkable lack of awareness at how easy it is to screw up a part of a cryptosystem.  Again I repeat, you fundimental advance is needed in any particular area to turn out to have a design which can be substantially optimized.
15:38 < gmaxwell> bramm: yes, the work here I introduced you to less than 24 hours ago, if you might recall.
15:38 < bramm> gmaxwell, You're making a highly general statement where I'm making a very specific statement about a very specific thing
15:39 < adam3us> tromp: your restatement of andytoshi's claim that asic resistance is not desirable seems fair to me.  (that there exists negligible perf difference between general purpose hardware that could be interesting).  however it seems generically impossible.  "hardware wins"?
15:39 < gmaxwell> Becuase I haven't gone out and broken it yet.  An example is scrypt that has some nice security proofs even, ... and then in litecoin when the rubber met the road the gpu implemenations were able to get big TMTO gains and produce high performance implementations that were previously claimed to be impossible.
15:41 -!- OX3_ [~OX3@host86-181-187-243.range86-181.btcentralplus.com] has quit [Ping timeout: 264 seconds]
15:41 < adam3us> tromp: and it seems desirable to have cheap hardware not expensive hardware so that we get closer to the objective of having the proof of cost be predominantly electrical cost (not amortised equipment cost)
15:41 < gmaxwell> bramm: so what I'm saying is that the dismissve approach of "construct X is well studied, and Y is well studied, and Z is widely used, all in areas unrelated to POW"  doesn't mean that a particular composition of them is secure.  I recommended talking to tromp because he's basically the only person in this space even trying to do a good job. (and AFAICT doing so, within the confines of the goal he's adopted and the limitations of a ...
15:41 < gmaxwell> ... single person for a fairly short amount of itme)
15:41 < bramm> gmaxwell, I'm very concerned about such things for cuckoo, but like I said before the problems aren't in siphash
15:42 < bramm> ... I am talking to tromp
15:42 < gmaxwell> bramm: perhaps it's not the weakest link sure. That I can buy. I wouldn't have brought it up myself, other than the fact that I expirenced some horror at zooko expressing concern and being dismissed.
15:42 -!- RoboTeddy [~roboteddy@173.247.202.131] has joined #bitcoin-wizards
15:43 < gmaxwell> I know you are.  I pointed that out because the prior sentence sounded like I was dismissing his efforts, which wasn't my intention.
15:43 < bramm> gmaxwell, My dismissiveness of what zooko is saying is over his contention that it may be possible to manipulate and insert loops or something like that, which it clearly isn't, because of the cryptographic properties of the hash function used at the beginning
15:44 < bramm> I mean, there are possible attacks, but not there
15:46 < coke0> What is the best case scenario with ASIC resistant PoW? So for a while you have more de facto decentralization due to many people having low marginal cost in CPU cycles. The minute mining becomes a bit big, people will be happy to rent their CPU power to a pool. In general, cheap CPU cycles are an anomaly bound to be arbitraged away in the future
15:46 < gmaxwell> bramm: How are you getting to that reduction? e.g. if I grind the initial hash, if the interior portion is sufficiently weak I may be able to very rapidly produce solutions.  Keeping in mind that there is something like a 20,000:1 difference is hashes/$ for sha256 between a general cpu and dedicated hardware (and considerably more in terms of H/joule).
15:47 < bramm> tromp_, My thought is that there may be some tricks which can reduce random access lookups in the trimming phase: First bucket sort as many edges as you can fit in near cache, then update those in memory in order, then maybe you've done fewer far random accesses
15:47 < tromp_> bramm: that's what the current implementation does
15:47 < gmaxwell> coke0: right that is related to the botnet/ec2 concerns; e.g. million node botnets.  It's hard to reason about what the implications are. They've been used to blow away some altcoins in te past.
15:47 < tromp_> using L2/L3 cache for the buckets
15:48 < gmaxwell> coke0: but thats a space thats hard to reason about.
15:48 < bramm> gmaxwell, If the inputs are secure hashed first, then there's nothing an attacker can do to increases or decrease the chances than any particular input they try actually contains a cycle, because cryptographically secure
15:48 < coke0> less cryptography, more game theory
15:49 < bramm> The borg is coming to get us!
15:50 < bramm> gmaxwell, Now determining whether there is a cycle and finding it, that's another story
15:50 < tromp_> adam3us,coke0: i don't know what all the implications are of shifting power costs to equipment costs. but i feel that narrowing the custom/commodity performance gap is desirable
15:51 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:51 < tromp_> and beneficial for decentralization
15:51 < Taek> I also don't fully understand why high ongoing costs (electricty) would be desirable vs. high equipment costs
15:52 < bramm> tromp_, How do you know the size of the near cache?
15:52 < adam3us> tromp:  this (narrowing range of equipment advantage) was the original motivation of the memory bound functions (memory bandwidth limited) that memory latency was less varying than cpu power.
15:52 < gmaxwell> Taek: because equipment costs are amortized.   E.g. you can see them as a centeralization effect. Now, I'm not trying to argue that this consideration breaks anything in particular.
15:53 < tromp_> bramm: you'd recompile for different platforms on which you run cuckoo
15:53 < gmaxwell> It's just a consideration which I don't well understand at this point.
15:53 < tromp_> bramm there's a few #define's for setting bucket sizes
15:53 < moa> Taek: electricity is already widely available, expensive hardware not
15:53 < bramm> Ah, gotcha
15:54 < coke0> tromp_: I tend to agree, it buys a few years, but it feels like a bandaid
15:54 < gmaxwell> tromp_: an argument Luke-Jr was trying to make earlier was that sha256 grinding asics are are already a commodity. Not as much as standard dram, but people are doing 20 million dollar mfgr runs of them, you can buy them by the reel fabricated on state of the art process.  Just something to think about.
15:54 < tromp_> adam3us: also latency is a lot less varying than memory bandwidth
15:54 < zooko> Okay, I have another thing to offer on the "hash function in cuckoo" topic.
15:54 < zooko> I hope it is not unwelcome.
15:54 < zooko> ☺
15:55 < zooko> It would be possible to naively assume that a successful attack on cuckoo would have to take one of two forms:
15:55 < Taek> hmm. moa: shipping is pretty cheap, but centralization of manufacturing facilities could be an issue
15:55 < zooko> a) get a random graph, find a better optimization for finding a cycle in it
15:55 < adam3us> tromp: if costs are shifted to equipment, do we know that the cost is linear in performance.  an old example is the people doing the memory bound pow stuff back in 2002 would probably be surprised by CPU cache sizes these days.
15:55 < zooko> (including heuristically, i.e. your better optimization can choose to give up and go to a new random graph, if that helps)
15:55 < tromp_> gmaxwell: but they're not a commodity that hold value well over a f ew years, unlike DRAM
15:55 < gmaxwell> If it does turn out to be the case that specalized CRAM or on-chip-via something another is several times more cost effective for cuckoo then I'd worry that even if the gap was small expirence says all the non-specialized hardware is out of business, and that new hardware may be less commodity than sha256 grinding asics. But this is somewhat in the realm of speculation.
15:55 < kanzure> if there are truly no particular manufacturing optimizations to make for DRAM then would homebrew DRAM manufacturing work
15:56 < zooko> b) find a way to trick cuckoo into generating a random graph that has a cycle sitting there for you on a silver platter.
15:56 < tromp_> and they're totally single purpose
15:56 < adam3us> tromp: or hardware hackers are more creative than software give them credit for.
15:56 < zooko> But, this simplistic dichotomy would overlook possible attacks on cuckoo which involve biasing the graph in some way so that a (heuristic) cycle-finder can be more efficient.
15:56 < tromp_> adam3us: cuckoo can scale memory use dynamically
15:56 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
15:57 < zooko> Including the possibility of parallel approaches, i.e. the thing I suggested yesterday where you generate many biased graphs with some relation to one another, in order
15:57 < zooko> to make your cycle-finder able to achieve superlinear cycle-finding in linear RAM.
15:57 < zooko> (And of course superlinear computation.)
15:57 < gmaxwell> zooko: it's not clear to me how such an approach actually fits into the application, since each run of this is initilized with its starting conditions.
15:58 < zooko> So, if you argue that there's no plausible way that a weakness in cuckoo's internal hash function could lead to a cycle sitting there for you on a silver platter, that's not a proof that there isn't some other successful attack.
15:59 < zooko> gmaxwell: my understanding of cuckoo may be incomplete... I think that "the attacker", i.e. the miner, has to build on top of a given input (e.g. the hash of the current block), and then gets to choose arbitrary nonces to mix in.
16:00 < tromp_> no zooko, you get to choose the macro nonce and nothing else
16:00 < tromp_> that fixes the graph
16:00 < zooko> Ah.
16:01 < Taek> gmaxwell: amortization of equipment costs is less of a centralization thing and more of needing to be in it for the long haul. As I understand, it's only a centralization problem if the entry costs are high (e.g. needing a $150 miner to be competitive vs. needing a $15,000 miner to be competitive).
16:01 -!- orik [~orik@remote.snococpa.com] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
16:01 < coke0> entry
16:02 < coke0> cost is dominated by variance
16:02 < adam3us> tromp: "the size of this array is chosen to be significantly larger than the largest cache available; at present, the size of hte array could be 16MB, say" :)  (2002 first paper on memory bound PoW.)
16:02 < coke0> not the cost of the equipment per se, but the economic opportunity cost
16:02 < zooko> I think this is the Fiat-Shamir transform: instead of me giving you a random graph and you solving a challenge in it (e.g. find a cycle in it), you can give
16:02 < zooko> me a random graph along with a solution to the challenge, but you have to prove that the graph was generated in a way that it would be hard for you to have picked an easy one.
16:03 -!- JeremieDeNoob [~jeremiede@modemcable026.213-130-66.mc.videotron.ca] has quit [Remote host closed the connection]
16:03 < zooko> I.e., by generating the graph using (in the old style, at least) a Random Oracle from something else that you are committed to,.
16:03 < zooko> Am I understanding "Fiat-Shamir transform" right?
16:03 < bramm> zooko, You can't make the graphs biased
16:03 < tromp_> coke0: one scenario is: big mining operators will fill warehouses with fpgas and dram clusters but will be less centralized because cooling and power costs are less of an issue
16:04 < bramm> Sorry, accidentally missed the last few minutes of discussion before sending my last message
16:04 < coke0> the cooling argument works at massive scales
16:04 < tromp_> the scale will be limited by dram costs
16:05 < gmaxwell> Taek: I don't quite follow that argument. Lets assume the operating costs are ~0. Say today mining is very profitable and so I go out and buy huge amounts of ram based hardware, enough to the point where I'm moving the market price and disrupting my profit plans or changing the network difficulty.  Okay. great. now time goes on and difficulty rises (from me and others doing that).  New entrants are locked out because they cannot ...
16:05 < adam3us> zooko: fiat-shamir transform is using a hash output as a fair challenge.
16:05 < coke0> so cooling won't be a limiting factor
16:05 < gmaxwell> ... expect a positive investment (e.g. relative to x% apy or whatever they'd expect in boring market investments).
16:05 < gmaxwell> yea, thanks coke0 economic opportunity cost is what I should have said there, as thats more complete.
16:05 < coke0> gmaxwell: exactly, mining has to offer a better sharpe ratio than the S&P
16:06 < bramm> I still haven't seen *any* discussion on what sorts of operations other than memory lookups might require the same power on ASICs as on CPUs
16:06 < tromp_> many people will be happy to mine at a loss
16:06 < bramm> People do mine at a a loss. There are a lot of stupid VCs out there.
16:06 < gmaxwell> tromp_: Expirence in bitcoin suggests this is untrue.
16:06 -!- AaronvanW [~ewout@255pc208.sshunet.nl] has quit [Ping timeout: 265 seconds]
16:06 < tromp_> either with a lottery mindset, or as a buy to obtain coins anonymously
16:06 < zooko> adam3us: yes, that's what I'm claiming is implicity a part of cuckoo's design.
16:07 < gmaxwell> bramm: they do, but not small scale miners intentionally.
16:07 < zooko> And currently the hash spec'ed in cuckoo is SipHash.
16:07 < tromp_> gmaxwell: that's partly because the performance gap is so huge
16:07 < gmaxwell> As I mentioned before there was not a CPU miner to be found back when cpu mining was still objectively profitable (but not very) over power costs for everyone.
16:08 < gmaxwell> And even ignoring cpu miners; people turn off and lay dormant their old bitcoin mining asics that have half the power efficiency, even though there isn't a huge gap in performance.
16:08 < tromp_> if you can install an app on your phone to mine overnight during charging, then you dont care about the cost
16:08 < kanzure> that motivation seems backwards
16:09 -!- Dizzle [~diesel@70.114.207.41] has quit [Quit: Leaving...]
16:09 -!- maraoz [~maraoz@186.137.72.181] has quit [Ping timeout: 256 seconds]
16:09 < coke0> if you run on your phone, your mobile phone operator is a threat
16:09 < kanzure> whehter or not they care about cost is independent of er.... the thing we were talking about, i think.
16:09 < kanzure> *whether
16:10 < sipa> tromp_: you may care about the decreased lifetime of the phone (overheating risks, ...)
16:10 < tromp_> let's just wait and see when cuckoo cycle is adopted, how the mining scene develops
16:10 < kanzure> so your goal seems to be something about arbitrarily low performance hardware
16:10 < gmaxwell> tromp_: I thought that too, but people seemed to care.   also wrt costs. My initial gpu mining setup was probably about $30k in hardware at peak. Right now that buys as much memory as about 4000 cell phones. I don't know why you think that someone's cell phone mining isn't going to be insignificant compared to people mining industrially.
16:11 < kanzure> *arbitrarily-low-performance
16:11 < tromp_> it will be insignificant, but ppl will be happy  to run it anyway
16:12 < tromp_> if the effort is really limited
16:12 < tromp_> and they can dream of "winning the lottery"
16:12 < Eliel> as long as they think there's a point, some people will do it.
16:12 < Eliel> if it's not too difficult
16:13 < tromp_> botnets will also help decentralize cuckoo (runs and hides:-)
16:13 < kanzure> i can't tell if this would satisfy your goals or not, but it sounds like you might be happy if pool shares paid out for significantly smaller amounts than they are presently configured? this would not require anything about particularly low performance hardware, either.
16:13 < gmaxwell> tromp_: this, again, hasn't been our expirence. I expected these things too, and they haven't happened. Even with cpus. Keep in mind we didn't go from cpus to 20,000 times more efficient asics over night.
16:13 < gmaxwell> tromp_: expirence in some of the altcoins is that the botnets have frequently been used for attacks. :(
16:15 < gmaxwell> kanzure: people don't usually seem to be unhappy about funny money numbers moving in pool accounting systems. The issue is that they're small.  I'm sure if my grep my logs I can find some quote along the lines of "You're a moron for cpu mining, it'll cost you $10 a month in power and it'll take you three weeks just to get a single bitcoin!"  from around a time when bitcoin was $10 the first time around. :)
16:15 < zooko> Bye for now, folks...
16:15 < tromp_> bye, zooko
16:15 -!- roidster [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has joined #bitcoin-wizards
16:15 < kanzure> oh that's interesting
16:15 -!- roidster is now known as Guest17201
16:16 < kanzure> but this does seem like it's related to pool accounting numbers
16:16 < kanzure> like, any hardware can be used for mining, as long as you're okay with not being profitable or something
16:16 < kanzure> including certain cell phones (well, it might require some clever forethought)
16:16 < tromp_> gmaxwell: back when bitcoin mining moved off cpus, i think smartcoin wallets were very much a rare thing
16:17 < gmaxwell> hehe: people arguing htat botnet operators won't mine. (looking at logs)
16:17 -!- op_null [~op_null@178.62.133.216] has joined #bitcoin-wizards
16:17 < gmaxwell> todaystomorrow: what do you mean by smartcoin wallets?
16:17 < gmaxwell> er damn complete, sorry todaystomorrow,  that was directed at tromp_
16:18 < tromp_> i mean you need the convenience of a one -click install of a sandboxed app to entice a large number of ppl to take up cpu mining
16:18 < Taek> If operating costs (deprication included) are 0, the ROI is unbounded and gets better with time. New entrants can expect a great ROI but only if they stick around for many years. The question becomes "Should I sit on this $1m pile of hardware and make $X or should I sell it for $1m and invest the $1m somewhere else", which effects the incumbants equally to the newcomers.
16:18 < op_null> gmaxwell: botnet mining is interesting because we can assume are rational but also do anything over morality to get the biggest profit. you can say Eligius probably won’t mine forks to get fees other pools already mined, but a botnet owner has a clear motive and opportunity. they probably won’t due to lack of skill, though, the people running them never seem to be the brightest bunch.
16:18 < Taek> if that makes sense
16:19 < phantomcircuit> gmaxwell, people seriously arguing that?
16:19 < sipa> tromp_: in the CPU mining days, it *was* a one click install (the bitcoin GUI program did mining internally)
16:19 < sipa> well, the very early cpu mining days
16:20 < gmaxwell> We actually disabled the default mining in the refernce client because of people who were _very_ angry that their cpu had been pegged for weeks without a result.
16:20 < gmaxwell> phantomcircuit: well tux was, so take that for what its worth.
16:20 < sipa> the magical one?
16:20 < op_null> phantomcircuit: hard to argue that point. people like the Skynet botnet's owner did an AMA and posted a screenshot of their "cloud hashing" console, complete with ponies.
16:20 < tromp_> maybe you should have made it to only run overnight:)
16:21 < sipa> op_null: wait, Skynet?
16:21 < op_null> Le Tor Botnet
16:21 < sipa> i thought it was from a movie
16:22 < op_null> here's their screenshot, they mined at BTCGuild by the looks of things. https://i.imgur.com/Z2eB9GY.png
16:22 < gmaxwell> op_null: 'rantional' is pretty bounded, my expirence with the botnet folks is that like other criminals many of them are morons (non-morons can find better ways to make a living).  E.g. the most halarious ones where the ones who would show up in #bitcoin-dev and demand to be taught to setup a pool for their botnet or they'd dos attack you (And then actually send a large dos attack when you punted them). ... thats probably the only ...
16:22 < gmaxwell> ... reason I've been happy about all those altcoins with their altpows .... drew off the sleezy botnet people completely.
16:22 < phantomcircuit> gmaxwell, that's weird since there are literally people admitting to doing it as op_null says
16:22 < gmaxwell> phantomcircuit: sure sure, this was back in early 2011 before it was really conspicious. Was looking at old logs.
16:23 < op_null> what was the hashrate in April 2014?
16:23 < phantomcircuit> oh
16:23 < op_null> er 2012.
16:23 < kanzure> not just non-morons able to find better ways to earn money, but something about opportunity cost of continuing to look for job opportunities
16:23 -!- zooko [~user@174-16-237-135.hlrn.qwest.net] has quit [Ping timeout: 245 seconds]
16:23 < kanzure> (this is partly how you end up with lots of bizarre-good talent in ukraine or something)
16:23 < sipa> op_null: http://bitcoin.sipa.be/speed-ever-large.png
16:23 < phantomcircuit> gmaxwell, there was an argument to be made that it would be too obvious
16:23 < sipa> op_null: wait, remove the '-large'; that one is busted
16:24 < sipa> around 10 TH/s
16:24 < op_null> phantomcircuit: the Skynet guy talked about that. he rigged up the miners so that only the people with the best GPUs mined, and not very hard, and only when the computer was inactive for his timezone. he was very very chatty about it, probably not so much now that he's in jail.
16:24 < phantomcircuit> is he in jail?
16:25 < op_null> yeah, got busted ages ago
16:25 < op_null> December 9 2013
16:25 < gmaxwell> what blockheight do you want to know the hashrate for?
16:26 < op_null> 24th APril 2012, same day as the skynet botnet screenshot
16:26 < gmaxwell> itcoin-cli  getnetworkhashps 288 177046
16:26 < gmaxwell> 10698891022134
16:27 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has left #bitcoin-wizards []
16:27 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has joined #bitcoin-wizards
16:27 < sipa> heh, i forgot about that RPC
16:28 < op_null> so he was 0.1% of the network with a Botnet. not as big as I was expecting, but 2012 was pretty late for that sort of activity I guess.
16:28 < sipa> in march 2011 there was a fun one
16:29 < sipa> a botnet with probably close to half the hashrate
16:29 < sipa> overnight the hashrate doubled
16:29 < gmaxwell> 'mystery miner'
16:29 < sipa> yup
16:29 < sipa> the MM
16:29 < op_null> gmaxwell: yes, there's several comments in the Monero threads about how good it is for botnets. phantomcircuit commented the same about X11. and the whole Dogecoin network storage botnet backs that up too.
16:31 < gmaxwell> network storage botnet?
16:31 < op_null> yeah. somebody made a Dogecoin mining botnet that used an exploit on some brand of NAS. got found out because it slowed them all down.
16:31 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
16:32 < op_null> http://www.secureworks.com/resources/blog/hacker-hijacks-synology-nas-boxes-for-dogecoin-mining-operation-reaping-half-million-dollars-in-two-months/
16:32 < sipa> oh
16:32 < sipa> i was hoping dogecoin had switched to proof-of-storage
16:32 -!- happycamper [~textual@64.147.222.97] has joined #bitcoin-wizards
16:33 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 265 seconds]
16:34 < op_null> if anybody was interested in the Skynet botnet AMA, it's quite interesting just how frank he is about using peoples computers to mine for him. the user is "throwaway236236" http://redd.it/sq7cy
16:35 < op_null> the numbers surprised me the most, $15/1000 infections is quoted. I wouldn't ever have pegged it to be so low.
16:36 -!- woah [~woah@75.101.111.82] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
16:36 < kanzure> that page does not mention skynet
16:38 -!- rasengan [rasengan@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has joined #bitcoin-wizards
16:38 < op_null> it's the same person though. they also had a very public twitter account where they made the same sort of comments. oddly enough, the last tweet they made is a dead mans switch. https://twitter.com/skynetbnet
16:38 -!- happycamper [~textual@64.147.222.97] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
16:38 -!- rasengan [rasengan@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has left #bitcoin-wizards []
16:44 < op_null> that's neat. he screwed up and used a "vest" instead of "west" in a comment, forward a year he is arrested in germany.
16:45 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
16:46 < gmaxwell> "if it weren't for those damn kids"
16:50 < kanzure> so er, should i assume that "better pool share payouts" do not solve the concerns regarding "low performance hardware should still be useful"?
16:50 < gmaxwell> kanzure: I don't think the payouts were ever the limiting factor. I think people have a non-linear utility function for money.
16:51 < gmaxwell> And one which goes negative for small amounts.
16:51 < kanzure> so for someone such as tromp_ (or anyone else bringing up similar concerns, not specifically tromp_), the concern is not only that the hardware has to be cheap, but also the payouts have to be large per chunk of commodity hardware?
16:51 < op_null> for bitcoin in particular the fees aren't related to the value, so small ammounts are less than worthless in a way. you have money but you can't spend it.
16:52 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
16:52 < kanzure> "i have money, but you've never heard of it" i call it hipstercash
16:52 -!- bramm [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep]
16:52 < gmaxwell> tromp_ believes otherwise, I did too previously but could never understand people's behavior. Perhaps what we expierenced in bitcoin previously was a fluke... and people would continue to mine even if the returns were negligible.
16:52 < kanzure> ("and also i can't spend it anyway")
16:53 < op_null> well, what amount of bitcoin is work something after the fee?
16:53 < gmaxwell> well any amount if it adds up for long enough in your pool account.
16:54 < kanzure> well, i could see a good argument for "the returns have to be at least enough such that you can withdraw something from the pool", which can be solved y lowering minimum withdrawal fees or polluting the blockchain with sub-satoshi outputs.
16:54 < kanzure> *by
16:54 < kanzure> s/minimum withdrawal fees/minimum withdrawal amounts
16:54 < op_null> sub satoshi sort of doesn't work :P
16:55 < gmaxwell> 1e-8 btc is a really small amount.
16:55 < kanzure> well presumably these pools are paying out even smaller, per share, right?
16:55 < op_null> oh yeah, it's been under 1 satoshi a share for ages.
16:56 < gmaxwell> well for diff 1 share, but not like they're accepting diff 1 shares normally anymore either.
16:56 < op_null> BTC Guild pays 0.00000000023361 per diff1 share.
16:56 < op_null> that varies though, like gmaxwell says they're not doing PPS
16:56 < kanzure> so why isn't that the solution instead of trying to find a memory hard solution
16:57 < op_null> even with more granularity it's still not worth my time to mine with old hardware.
16:57 < kanzure> the claim wasn't that it would be worth your time
16:58 < kanzure> (with minimum wage laws especially, hehe)
16:59 < kanzure> oh wait, maybe that was the claim
16:59 < kanzure> regarding the overnight-cellphone-charging-and-mining example?
17:00 < gmaxwell> I made the point that even a small performance gap (tromp believes he can get it under 'orders of magnitude' and I'll buy that) means that anything but the most efficient industral miners will be operating at a loss rapidly.
17:01 < gmaxwell> tromp argued than that people would continue to mine at a loss. I pointed out that this is observably untrue in bitcoin; it was untrue when gpu mining was new and displacing cpu mining, it's untrue now relative to different generations of asic hardware.  He believes otherwise.  I can't argue further because I the behavior in bitcoin surprised me.
17:02 < gmaxwell> And I don't know why people stopped cpu mining even before it was operating at a loss to continue to do so.
17:02 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
17:03 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards
17:03 < op_null> it's "profitable" for me to mine Monero. but I don't because the profit doesn't cover the cost of me opening the miner application.
17:03 < gmaxwell> early gpu miners were only about 10x faster than cpus on a 1:1 device count ratio. Though it was more like 25:1 as they got in full swing.
17:04 < gmaxwell> op_null: heh. well w/ monero you have the other issue that the software seems to have been originally written by malicious parties; who think nothing of exploiting the forks.. :(
17:04 -!- c0rw1n is now known as c0rw|sleep
17:05 < op_null> I've always run it in a virtual machine and I don't own any particular amount of it. it's unfortunate that the Bytecoin people came up with such a neat idea and tried to scam with it over and over.
17:05 < gmaxwell> but interesting point; we have other 'memory hard' functions even if they're crappy in other respects (slow to verify) ... so you can't just say that the failure of expectations for ltc-scrypt is because ltc-scrypt wasn't memory hard enough.
17:05 < op_null> did you know that most people concluded that all of the forks beside monero are the Bytecoin people's as well?
17:06 < gmaxwell> op_null: I'd heard that.
17:06 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
17:06 < op_null> all of them randomised a key inside the app, except for monero. nobody even knew the key existed, so it's weird that so many forks did.
17:07 < op_null> for Monero pools the hash function is a pretty big hit for them too. most of the pools handle it by not verifying all of the users shares and just assuming they are correct.
17:08 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 256 seconds]
17:09 < op_null> admittedly it does seem to run pretty terribly on GPUs no matter what people do with it. so it seems to be the most "GPU hard", but as a result their network is almost certainly a large portion Botnet miners.
17:11 -!- Guest100 [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]
17:12 -!- jb55_ [~jb55@208.98.200.98] has joined #bitcoin-wizards
17:16 -!- jb55 [~jb55@208.98.200.98] has quit [Ping timeout: 256 seconds]
17:16 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
17:16 -!- maaku is now known as Guest36612
17:17 -!- jb55_ [~jb55@208.98.200.98] has quit [Ping timeout: 272 seconds]
17:17 -!- Guest36612 is now known as maaku
17:29 -!- bramm [~bram@38.99.42.130] has joined #bitcoin-wizards
17:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds]
17:34 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds]
17:38 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
17:43 -!- roidster [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has joined #bitcoin-wizards
17:43 -!- roidster is now known as Guest4502
17:43 < bramm> tromp_, How well can cuckoo be parallelized on a single machine? I mean, how many memory lookups can you have going at once?
17:44 < op_null> I think you end up memory bandwidth limited
17:44 -!- Guest17201 [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 240 seconds]
17:44 < bramm> Yeah I wonder if custom hardware could have more memory bandwidth
17:45 < bramm> And whether, say, you have separate memory bandwidth for each CPU or if it's a single aggregate thing. I don't know hardware.
17:45 < phantomcircuit> bramm, memory bandwidth is typically per cpu
17:46 < op_null> for off the shelf CPUs they usually have a limit on your memory bus
17:46 < phantomcircuit> and yes custom hardware could have substantially more memory bandwidth
17:46 < phantomcircuit> since you could balance cpu speed and memory bus bandwidth
17:47 < op_null> for some reason GPUs are actually getting thinner memory busses now, the newer nvidia ones do some sort of compression to try and get around the lack of raw bandwidth.
17:48 < phantomcircuit> op_null, wide memory buses are difficult to get right
17:50 < op_null> yeah. you're not doing that in a breadboard i'm sure.
17:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
17:51 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
17:52 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards
17:53 -!- licnep [uid4387@gateway/web/irccloud.com/x-bxsgacpuydvpnkim] has quit [Quit: Connection closed for inactivity]
17:54 < tromp> bramm, i tried with up to 32 threads. i think there's a plot in the paper with speedups
17:55 < tromp> 32 threads on opteron was more than enough to saturate the memory subsystem, but on Xeon dual core it's not maxed yet at 43
17:55 < tromp> sorry, at 32
17:56 < op_null> tromp: how fast is cuckoo cycle on a 8 core xeon?
17:56 < op_null> I assume you meant 16 threads on an 8 core xeon.
17:56 < tromp> i measured 1min/GB for 20 threads.
17:57 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards
17:57 < tromp> so to use 1GB you prolly need a pretty long block interval alrd
17:58 < op_null> everything else aside, I love the term "tomato" for TMTO
17:58 < tromp> i think that was David Anderson's idea
17:59 < tromp> there are now Xeon's with 18 cores, so dual hyperthreaded cld give 72 threads; wld love to bench those
17:59 < op_null> I'd probably ened to live on the street to buy one of those.
17:59 < tromp> i expect those will max the memory system
18:00 < tromp> wld be nice if siphash was a native instruction...
18:00 < op_null> think you missed out on that one. some of the SHA family will be soon though.
18:00 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
18:01 < tromp> but it seems to be more a matter of supporting dozens of pending memory accesses
18:03 < tromp> i think with native siphash the cpu wld only spend a few % of runtime doing computation, and the rest waiting for mem
18:03 < tromp> now it's 33% computation and 67% waiting
18:04 < phantomcircuit> tromp, is memory access linear or random with cuckoo cycle?
18:04 < tromp> access to the live nonces bits is linear; access to the degree counters is random
18:04 -!- bramm [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep]
18:05 < tromp> also access to the latter should be atomic
18:05 < tromp> in case of running multiple threads
18:06 < tromp> if not, then you risk missing some cycle
18:06 < tromp> (which might be ok as long as risk is small)
18:13 -!- go1111111 [~go1111111@c-174-61-204-17.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
18:28 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Remote host closed the connection]
18:29 -!- go1111111 [~go1111111@2601:8:9d00:4300:b4e8:1eab:9f9f:acb5] has joined #bitcoin-wizards
18:39 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards
18:42 -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds]
18:44 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has quit [Ping timeout: 264 seconds]
18:52 -!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has joined #bitcoin-wizards
19:00 -!- zooko [~user@c-75-70-204-46.hsd1.co.comcast.net] has joined #bitcoin-wizards
19:02 < rusty> gmaxwell: I wish I had discovered https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs earlier.  It basically describes pettycoin, with a few differences.
19:02 < rusty> gmaxwell: I use a lottery system for Proof of false inflation .  Pick random tx, take fee, multiply by number of txs, that's the reward.
19:03 < rusty> gmaxwell: your solution is more elegant.
19:12 -!- coke0_ [~coke0@pool-108-21-231-34.nycmny.fios.verizon.net] has joined #bitcoin-wizards
19:16 -!- coke0 [~coke0@2607:fb90:1f06:f791:2afb:bafc:1ad4:2578] has quit [Ping timeout: 258 seconds]
19:22 -!- zooko [~user@c-75-70-204-46.hsd1.co.comcast.net] has quit [Ping timeout: 250 seconds]
19:29 -!- todaystomorrow [~me@d122-111-39-14.bla803.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds]
19:35 -!- samson2 [~samson_@183.89.21.125] has joined #bitcoin-wizards
19:35 -!- Guest4502 [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.22.1/20131113180422]]
19:35 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
19:36 -!- samson_ [~samson_@183.89.172.189] has quit [Ping timeout: 245 seconds]
19:39 -!- go1111111 [~go1111111@2601:8:9d00:4300:b4e8:1eab:9f9f:acb5] has quit [Ping timeout: 258 seconds]
19:40 -!- samson2 [~samson_@183.89.21.125] has quit [Ping timeout: 265 seconds]
19:40 -!- go1111111 [~go1111111@2601:8:9d00:4300:b4e8:1eab:9f9f:acb5] has joined #bitcoin-wizards
19:41 -!- samson_ [~samson_@180.183.83.162] has joined #bitcoin-wizards
19:43 < Taek> gmaxwell, wrt using libsecp256k1, I thought of a solution which might allow you to use multiple paths without sacrificing a factor of N slowdown.
19:44 < Taek> you verify each signature with randomly selected blocks of code, but only once
19:45 < Taek> if your conclusion matches the conclusion followed by the heaviest fork, you don't verify again and just accept it
19:46 < Taek> if you get a confliction solution (meaning something didn't verify but the heaviest fork suggests that it was verified), you check using multiple paths or perhaps a completely different library
19:46 < Taek> your slowdown is only when you don't verify something that should be verified
19:46 < Taek> the risk is that you verify something that shouldn't be verified
19:47 < Taek> but since everyone is using random code paths, only some people (with enough potential paths, very very few people) will accept the transaction
19:47 < Taek> and so some people will fork unintentionally because they confirm something that shouldn't be confirmed, the majority of mining power will not accept the invalid signature, and the heaviest fork will remain pure
19:48 < Taek> I would argue that having multiple implementations to switch between randomly when verification is a lot stronger for the network than just having one.
19:49 < Taek> because when most everyone uses the same library, a single mistake can cause a big fork. But if everyone is using dozens of implementations, to get a fork you have to find a signature that causes errors in the majority of the implementations
19:50 < Taek> s/when verification/when verifying
19:50 -!- coiner [~linker@118.69.162.103] has quit [Ping timeout: 264 seconds]
20:08 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has quit [Remote host closed the connection]
20:10 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has joined #bitcoin-wizards
20:19 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
20:20 -!- coiner [~linker@113.161.87.238] has joined #bitcoin-wizards
20:26 -!- ryanxcharles [~ryanxchar@162.245.22.162] has quit [Ping timeout: 240 seconds]
20:37 -!- adam3us [~Adium@host-92-19-90-29.as13285.net] has quit [Ping timeout: 264 seconds]
20:41 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 272 seconds]
20:42 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:44 -!- nubbins` [~leel@stjhnf0157w-047055221135.dhcp-dynamic.FibreOp.nl.bellaliant.net] has joined #bitcoin-wizards
20:44 -!- nubbins` [~leel@stjhnf0157w-047055221135.dhcp-dynamic.FibreOp.nl.bellaliant.net] has quit [Changing host]
20:44 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
20:45 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds]
20:46 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 255 seconds]
20:48 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards
20:53 -!- go1111111 [~go1111111@2601:8:9d00:4300:b4e8:1eab:9f9f:acb5] has quit [Ping timeout: 258 seconds]
20:56 < kanzure> is there a better lamport paper than http://diyhpl.us/~bryan/papers2/bitcoin/Time,%20clocks,%20and%20the%20ordering%20of%20events%20in%20a%20distributed%20system%20-%20Lamport.pdf to be using
21:00 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
21:03 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
21:08 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
21:09 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards
21:11 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Client Quit]
21:12 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards
21:13 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Client Quit]
21:31 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards
21:43 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has quit [Ping timeout: 240 seconds]
21:51 -!- RoboTeddy [~roboteddy@173.247.202.131] has quit [Ping timeout: 272 seconds]
21:51 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection]
21:51 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
22:07 -!- tdlfbx [~bsm117532@64.253.217.244] has quit [Ping timeout: 255 seconds]
22:07 -!- tdlfbx [~bsm117532@64.253.217.244] has joined #bitcoin-wizards
22:07 -!- gues_ [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
22:11 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
22:12 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
22:12 -!- RoboTedd_ [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
22:20 -!- JohanTitor [~superobse@unaffiliated/superobserver] has quit [Ping timeout: 272 seconds]
22:28 -!- lclc_bnc is now known as lclc
22:44 -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has joined #bitcoin-wizards
22:45 -!- llllllllll [~lllllllll@53-109.bbned.dsl.internl.net] has joined #bitcoin-wizards
22:45 -!- bramm [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
22:46 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards
22:48 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:44ab:e55:4997:b865] has joined #bitcoin-wizards
22:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
23:07 -!- bramm [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Leaving]
23:24 -!- Guest27678 [~WW@unaffiliated/loteriety] has quit [Ping timeout: 240 seconds]
23:28 -!- JonTitor [~superobse@unaffiliated/superobserver] has joined #bitcoin-wizards
23:35 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit []
23:44 -!- iambernie [~bernie@82-169-230-87.ip.telfort.nl] has quit [Remote host closed the connection]
23:46 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
23:47 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards
--- Log closed Wed Nov 26 00:00:02 2014