--- Log opened Wed Jan 14 00:00:23 2015 00:01 -!- delll_ [~chatzilla@yh97.internetdsl.tpnet.pl] has quit [Ping timeout: 244 seconds] 00:06 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards 00:06 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 00:09 -!- MoALTz [~no@user-109-243-165-112.play-internet.pl] has quit [Quit: Leaving] 00:09 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has joined #bitcoin-wizards 00:13 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has quit [Ping timeout: 244 seconds] 00:14 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has joined #bitcoin-wizards 00:15 -!- aburan28 [~ubuntu@static-108-45-93-86.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds] 00:20 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has quit [Ping timeout: 264 seconds] 00:22 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 00:22 -!- nsh [~lol@wikipedia/nsh] has quit [Excess Flood] 00:22 -!- nsh [~lol@2001:41d0:8:c2da::1337] has joined #bitcoin-wizards 00:24 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has joined #bitcoin-wizards 00:25 -!- freewil [~freewil@unaffiliated/freewil] has quit [Ping timeout: 244 seconds] 00:26 -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] 00:31 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has quit [Ping timeout: 245 seconds] 00:32 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has joined #bitcoin-wizards 00:34 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 00:36 -!- freewil [~freewil@unaffiliated/freewil] has joined #bitcoin-wizards 00:37 -!- freewil [~freewil@unaffiliated/freewil] has quit [Client Quit] 00:38 -!- Trugnor [Trugnor@203-219-144-75.static.tpgi.com.au] has joined #bitcoin-wizards 00:38 -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has joined #bitcoin-wizards 00:39 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 252 seconds] 00:43 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has quit [Ping timeout: 240 seconds] 00:46 -!- Trugnor [Trugnor@203-219-144-75.static.tpgi.com.au] has quit [] 00:47 -!- shesek [~shesek@IGLD-84-228-192-195.inter.net.il] has quit [Ping timeout: 240 seconds] 00:55 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 00:56 -!- lnovy [~lnovy@2002:4d57:f055::1] has quit [Quit: Got root?] 00:57 -!- zz_lnovy [~lnovy@2002:4d57:f055::1] has joined #bitcoin-wizards 00:57 -!- zz_lnovy is now known as lnovy 00:58 -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards 00:59 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 245 seconds] 00:59 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has joined #bitcoin-wizards 01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection] 01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards 01:05 * andy-logbot is logging 01:12 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-atykvmajjkoroctl] has quit [Ping timeout: 244 seconds] 01:13 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-uafhzcfxftakpoku] has joined #bitcoin-wizards 01:19 -!- delll [~chatzilla@yh97.internetdsl.tpnet.pl] has joined #bitcoin-wizards 01:20 -!- stonecoldpat [~Paddy@janus-nat-128-240-225-56.ncl.ac.uk] has quit [Ping timeout: 256 seconds] 01:26 -!- go1111111 [~go1111111@gateway/vpn/privateinternetaccess/go1111111] has joined #bitcoin-wizards 01:32 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer] 01:34 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 01:39 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 244 seconds] 01:41 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 01:46 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has joined #bitcoin-wizards 01:49 -!- shesek [~shesek@109.67.170.98] has joined #bitcoin-wizards 01:49 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 01:54 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 244 seconds] 02:03 -!- roconnor [~roconnor@e120-pool-d89a6740.brdbnd.voicenetwork.ca] has quit [Ping timeout: 245 seconds] 02:08 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards 02:13 -!- koshii [~0@ppp-110-168-218-128.revip5.asianet.co.th] has quit [Ping timeout: 264 seconds] 02:18 -!- delll [~chatzilla@yh97.internetdsl.tpnet.pl] has quit [Read error: Connection reset by peer] 02:20 -!- delll [~chatzilla@yh97.internetdsl.tpnet.pl] has joined #bitcoin-wizards 02:22 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards 02:22 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-uafhzcfxftakpoku] has quit [Ping timeout: 255 seconds] 02:24 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-aygptwxecfpvdwbm] has joined #bitcoin-wizards 02:24 -!- weex [~weex@fsf/member/weex] has quit [Quit: Lost terminal] 02:27 -!- jtimon [~quassel@185.pool85-53-136.dynamic.orange.es] has joined #bitcoin-wizards 02:29 -!- siraj [~siraj@1.187.222.143] has quit [Read error: Connection reset by peer] 02:29 -!- lnovy [~lnovy@2002:4d57:f055::1] has quit [Ping timeout: 244 seconds] 02:29 -!- vmatekole [~vmatekole@f052090179.adsl.alicedsl.de] has joined #bitcoin-wizards 02:30 -!- benten [~benten@unaffiliated/benten] has quit [Quit: ....] 02:31 -!- vmatekole [~vmatekole@f052090179.adsl.alicedsl.de] has quit [Remote host closed the connection] 02:33 -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Ping timeout: 244 seconds] 02:33 -!- zz_lnovy [~lnovy@2002:4d57:f055::1] has joined #bitcoin-wizards 02:33 -!- zz_lnovy is now known as lnovy 02:34 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 02:38 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 240 seconds] 02:39 -!- siraj [~siraj@106.76.138.174] has joined #bitcoin-wizards 02:41 -!- forrestv [forrestv@unaffiliated/forrestv] has joined #bitcoin-wizards 02:43 -!- NLNicoo [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards 02:46 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 255 seconds] 03:31 -!- eudoxia [~eudoxia@r179-25-177-125.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 03:34 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 03:39 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 264 seconds] 03:45 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 03:47 -!- bencxr [~Benedict@c-50-161-21-167.hsd1.ca.comcast.net] has joined #bitcoin-wizards 03:47 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 03:49 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 03:50 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 264 seconds] 03:54 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 244 seconds] 04:01 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 04:01 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-aygptwxecfpvdwbm] has quit [Ping timeout: 252 seconds] 04:02 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-wulndztoshsiqolb] has joined #bitcoin-wizards 04:03 -!- bit2017 [~linker@112.109.91.6] has joined #bitcoin-wizards 04:04 -!- vmatekole [~vmatekole@p5DC4623E.dip0.t-ipconnect.de] has joined #bitcoin-wizards 04:06 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 245 seconds] 04:06 -!- coiner [~linker@115.79.55.177] has quit [Ping timeout: 252 seconds] 04:07 -!- bit2017 [~linker@112.109.91.6] has quit [Max SendQ exceeded] 04:10 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 04:11 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 04:18 -!- HarusameNyanko [~HarusameN@pl2125.nas815.n-hiroshima.nttpc.ne.jp] has joined #bitcoin-wizards 04:18 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 04:18 -!- HarusameNyanko [~HarusameN@pl2125.nas815.n-hiroshima.nttpc.ne.jp] has quit [Excess Flood] 04:19 -!- HarusameNyanko [~HarusameN@pl2125.nas815.n-hiroshima.nttpc.ne.jp] has joined #bitcoin-wizards 04:19 -!- HarusameNyanko [~HarusameN@pl2125.nas815.n-hiroshima.nttpc.ne.jp] has quit [Excess Flood] 04:19 -!- HarusameNyanko [~HarusameN@pl2125.nas815.n-hiroshima.nttpc.ne.jp] has joined #bitcoin-wizards 04:19 -!- HarusameNyanko [~HarusameN@pl2125.nas815.n-hiroshima.nttpc.ne.jp] has quit [Excess Flood] 04:19 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 04:20 -!- HarusameNyanko [~HarusameN@pl2125.nas815.n-hiroshima.nttpc.ne.jp] has joined #bitcoin-wizards 04:33 -!- Quanttek [~quassel@2a02:8108:d00:870:e23f:49ff:fe47:9364] has joined #bitcoin-wizards 04:34 -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 245 seconds] 04:34 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 04:38 -!- op_mul [~op_mul@178.62.78.122] has quit [Quit: Lost terminal] 04:39 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 04:39 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 245 seconds] 04:39 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 04:41 -!- op_mul [~op_mul@178.62.78.122] has joined #bitcoin-wizards 04:50 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 04:51 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 04:54 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 04:55 -!- bencxr [~Benedict@c-50-161-21-167.hsd1.ca.comcast.net] has quit [Quit: bencxr] 04:56 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 04:57 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Read error: Connection reset by peer] 05:04 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 05:04 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 05:04 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 05:18 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards 05:22 -!- NomosOne [~NomosOne@pool-71-178-107-61.washdc.east.verizon.net] has joined #bitcoin-wizards 05:22 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 05:24 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 05:24 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 05:25 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 05:26 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 05:27 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 05:28 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 05:36 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 05:38 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 05:38 -!- hearn_ [~mike@185.25.95.132] has joined #bitcoin-wizards 05:39 -!- hearn_ is now known as Guest66524 05:41 -!- koshii [~0@node-bgh.pool-101-108.dynamic.totbb.net] has joined #bitcoin-wizards 05:48 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:6df8:6fcd:db2b:985d] has joined #bitcoin-wizards 05:50 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 05:56 -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has joined #bitcoin-wizards 05:58 -!- Kloeey [~Kloeey@31.7.61.152] has joined #bitcoin-wizards 05:58 < Kloeey> Bitcoin to 100$ look at this graph from China,Russia omg.. 100$ coming... http://www.bitcoinwisdomapp.com/#BitcoinGraphToday 05:59 -!- hearn [~mike@46-253-188-152.dynamic.monzoon.net] has joined #bitcoin-wizards 05:59 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 05:59 < fluffypony> Kloeey: no. 06:02 -!- Guest66524 [~mike@185.25.95.132] has quit [Ping timeout: 265 seconds] 06:02 < op_mul> that's malware, if nobody guessed. don't click. 06:04 -!- coiner [~linker@115.79.55.177] has quit [Ping timeout: 252 seconds] 06:18 -!- hashtagg [~hashtagg_@69.23.213.3] has joined #bitcoin-wizards 06:20 -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 255 seconds] 06:29 -!- siraj [~siraj@106.76.138.174] has quit [Read error: Connection reset by peer] 06:29 -!- maraoz [~maraoz@43-161-16-190.fibertel.com.ar] has joined #bitcoin-wizards 06:30 -!- bencxr [~Benedict@50.161.21.167] has joined #bitcoin-wizards 06:36 -!- narwh4l [8dd611e8@gateway/web/freenode/ip.141.214.17.232] has joined #bitcoin-wizards 06:38 -!- BigBitz [~BigBitz@unaffiliated/bigbitz] has quit [Ping timeout: 250 seconds] 06:38 < kanzure> is it interesting malware at least? 06:40 -!- Kloeey [~Kloeey@31.7.61.152] has quit [Ping timeout: 272 seconds] 06:40 -!- EasyAt [~EasyAt@unaffiliated/easyat] has quit [Ping timeout: 272 seconds] 06:40 -!- siraj [~siraj@27.97.240.15] has joined #bitcoin-wizards 06:41 * narwh4l opens vm, clicks link 06:41 -!- hearn [~mike@46-253-188-152.dynamic.monzoon.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 06:43 < op_mul> I doubt it 06:43 < op_mul> a rarball I can't be bothered getting the VM out for. it'll be some off the shelf RAT trojan. 06:44 -!- BigBitz [~BigBitz@unaffiliated/bigbitz] has joined #bitcoin-wizards 06:45 -!- shea256 [~hightorqu@65.209.72.194] has joined #bitcoin-wizards 06:47 -!- EasyAt [~EasyAt@46.19.139.88] has joined #bitcoin-wizards 06:47 -!- EasyAt [~EasyAt@46.19.139.88] has quit [Changing host] 06:47 -!- EasyAt [~EasyAt@unaffiliated/easyat] has joined #bitcoin-wizards 06:48 -!- jps [~Jud@cpe-74-72-116-143.nyc.res.rr.com] has joined #bitcoin-wizards 06:49 < jtimon> http://bitcoin.stackexchange.com/questions/35461/ripple-only-a-sub-network-reaching-a-consensus-is-largely-enough-to-be-decentra#comment40350_35461 06:49 < jtimon> maybe someone else wants to give a more detailed answer... 06:51 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds] 06:54 -!- wallet42 [~wallet42@nat-0-15.lam.cz] has joined #bitcoin-wizards 06:54 -!- wallet42 [~wallet42@nat-0-15.lam.cz] has quit [Changing host] 06:54 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 07:09 -!- hearn [~mike@46-253-188-152.dynamic.monzoon.net] has joined #bitcoin-wizards 07:27 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 07:29 -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has quit [Quit: Profreid] 07:30 -!- hearn [~mike@46-253-188-152.dynamic.monzoon.net] has quit [Ping timeout: 265 seconds] 07:32 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 07:32 -!- shesek [~shesek@109.67.170.98] has quit [Ping timeout: 240 seconds] 07:36 -!- Greed [~Greed@unaffiliated/greed] has quit [Read error: Connection reset by peer] 07:36 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 07:36 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 07:37 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 07:38 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 07:41 -!- adam3us [~Adium@88-105-6-39.dynamic.dsl.as9105.com] has joined #bitcoin-wizards 07:42 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 07:42 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 244 seconds] 07:43 -!- shea256 [~hightorqu@65.209.72.194] has quit [Remote host closed the connection] 07:43 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 07:48 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 272 seconds] 07:50 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 07:51 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 07:51 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards 07:52 -!- hearn [~mike@185.25.95.132] has quit [Read error: Connection reset by peer] 07:53 -!- hearn [~mike@46.140.0.233] has joined #bitcoin-wizards 07:55 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 07:56 -!- shea256 [~hightorqu@65.209.72.194] has joined #bitcoin-wizards 07:59 -!- narwh4l [8dd611e8@gateway/web/freenode/ip.141.214.17.232] has quit [Quit: Page closed] 07:59 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 240 seconds] 08:00 -!- shesek [~shesek@109.67.170.98] has joined #bitcoin-wizards 08:02 -!- shesek [~shesek@109.67.170.98] has quit [Max SendQ exceeded] 08:03 -!- shesek [~shesek@109.67.170.98] has joined #bitcoin-wizards 08:06 -!- shesek [~shesek@109.67.170.98] has quit [Max SendQ exceeded] 08:07 -!- shesek [~shesek@109.67.170.98] has joined #bitcoin-wizards 08:07 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 08:09 -!- adam3us [~Adium@88-105-6-39.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] 08:10 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 08:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Read error: Connection reset by peer] 08:10 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Read error: Connection reset by peer] 08:10 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Read error: Connection reset by peer] 08:11 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 08:11 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 08:11 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 08:11 -!- wallet421 [~wallet42@nat-0-15.lam.cz] has joined #bitcoin-wizards 08:11 -!- wallet421 [~wallet42@nat-0-15.lam.cz] has quit [Changing host] 08:11 -!- wallet421 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 08:11 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Killed (barjavel.freenode.net (Nickname regained by services))] 08:11 -!- wallet421 is now known as wallet42 08:16 -!- hearn [~mike@46.140.0.233] has quit [Ping timeout: 246 seconds] 08:17 -!- hearn [~mike@46.140.0.233] has joined #bitcoin-wizards 08:18 -!- adam3us [~Adium@88-105-6-39.dynamic.dsl.as9105.com] has joined #bitcoin-wizards 08:21 -!- eudoxia [~eudoxia@r179-25-177-125.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 08:24 -!- treehug88 [~treehug88@34-254.as32345.tumblrhq.com] has joined #bitcoin-wizards 08:26 -!- bencxr [~Benedict@50.161.21.167] has quit [Quit: bencxr] 08:28 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has quit [Read error: Connection reset by peer] 08:29 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has joined #bitcoin-wizards 08:31 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:f0f5:811c:a42f:8e50] has joined #bitcoin-wizards 08:38 -!- siraj [~siraj@27.97.240.15] has quit [Remote host closed the connection] 08:46 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has joined #bitcoin-wizards 08:47 -!- belcher [~belcher-s@5ec397f4.skybroadband.com] has joined #bitcoin-wizards 08:47 -!- belcher [~belcher-s@5ec397f4.skybroadband.com] has quit [Changing host] 08:47 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards 08:48 -!- shesek [~shesek@109.67.170.98] has quit [Ping timeout: 246 seconds] 08:50 -!- jtimon [~quassel@185.pool85-53-136.dynamic.orange.es] has quit [Ping timeout: 245 seconds] 08:51 -!- jtimon [~quassel@wilkins2.static.monkeybrains.net] has joined #bitcoin-wizards 09:02 -!- adam3us [~Adium@88-105-6-39.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] 09:06 -!- treehug88 [~treehug88@34-254.as32345.tumblrhq.com] has quit [Ping timeout: 276 seconds] 09:07 -!- Dizzle [~diesel@70.114.207.41] has joined #bitcoin-wizards 09:07 -!- shea256 [~hightorqu@65.209.72.194] has quit [Remote host closed the connection] 09:07 -!- d1ggy__ is now known as d1ggy 09:09 -!- shea256 [~hightorqu@65.209.72.194] has joined #bitcoin-wizards 09:14 -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has joined #bitcoin-wizards 09:15 -!- hearn [~mike@46.140.0.233] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 09:16 -!- NLNicoo [~NLNico@unaffiliated/nlnico] has quit [Read error: Connection reset by peer] 09:19 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:f0f5:811c:a42f:8e50] has quit [Ping timeout: 245 seconds] 09:20 -!- jps [~Jud@cpe-74-72-116-143.nyc.res.rr.com] has quit [Ping timeout: 244 seconds] 09:22 -!- jps [~Jud@172.56.34.62] has joined #bitcoin-wizards 09:34 -!- mbelshe_ [~mike@64.124.157.148] has joined #bitcoin-wizards 09:34 -!- mbelshe [~mike@64.124.157.148] has quit [Read error: Connection reset by peer] 09:34 -!- mbelshe_ is now known as mbelshe 09:36 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] 09:37 -!- treehug88 [~treehug88@static-96-239-100-47.nycmny.fios.verizon.net] has joined #bitcoin-wizards 09:42 -!- nessence [~alexl@166.175.56.255] has joined #bitcoin-wizards 09:48 -!- ryanxcharles [~ryanxchar@162-245-22-162.v250d.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards 09:49 -!- MoALTz [~no@user-109-243-165-112.play-internet.pl] has joined #bitcoin-wizards 09:50 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 09:53 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards 09:57 -!- jps [~Jud@172.56.34.62] has quit [Quit: jps] 10:00 -!- Starduster [~guest@unaffiliated/starduster] has quit [Read error: Connection reset by peer] 10:00 -!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards 10:04 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 10:09 -!- shea256 [~hightorqu@65.209.72.194] has quit [Remote host closed the connection] 10:11 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has quit [Remote host closed the connection] 10:14 -!- bendavenport [~bpd@64.124.157.148] has joined #bitcoin-wizards 10:20 -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has joined #bitcoin-wizards 10:22 -!- NomosOne [~NomosOne@pool-71-178-107-61.washdc.east.verizon.net] has quit [Remote host closed the connection] 10:22 -!- adam3us [~Adium@88-105-6-39.dynamic.dsl.as9105.com] has joined #bitcoin-wizards 10:35 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Remote host closed the connection] 10:35 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards 10:48 -!- nessence [~alexl@166.175.56.255] has quit [Remote host closed the connection] 10:49 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 10:51 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds] 10:52 -!- skyraider [uid41097@gateway/web/irccloud.com/x-vuguviaemctnjemk] has joined #bitcoin-wizards 10:53 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards 10:54 -!- shea256 [~hightorqu@65.209.72.194] has joined #bitcoin-wizards 10:55 -!- jps [~Jud@172.56.34.62] has joined #bitcoin-wizards 11:00 -!- shea256 [~hightorqu@65.209.72.194] has quit [Remote host closed the connection] 11:04 -!- shea256 [~hightorqu@65.209.72.194] has joined #bitcoin-wizards 11:04 -!- zooko` [~user@c-67-190-86-140.hsd1.co.comcast.net] has joined #bitcoin-wizards 11:05 -!- shesek [~shesek@IGLD-84-228-192-195.inter.net.il] has joined #bitcoin-wizards 11:06 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds] 11:09 -!- zooko` is now known as zooko 11:13 -!- NomosOne [~NomosOne@pool-71-178-107-61.washdc.east.verizon.net] has joined #bitcoin-wizards 11:18 -!- jps [~Jud@172.56.34.62] has quit [Ping timeout: 246 seconds] 11:28 -!- lclc_bnc [~lclc@bothniafur.com] has joined #bitcoin-wizards 11:28 -!- lclc_bnc is now known as lclc 11:29 -!- zooko [~user@c-67-190-86-140.hsd1.co.comcast.net] has quit [Remote host closed the connection] 11:32 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 11:34 -!- jps [~Jud@172.56.34.62] has joined #bitcoin-wizards 11:36 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 11:41 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 244 seconds] 11:55 -!- hashtag [~hashtag@63.134.140.173] has joined #bitcoin-wizards 11:55 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards 11:58 -!- vmatekole [~vmatekole@p5DC4623E.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 12:01 -!- hashtag [~hashtag@63.134.140.173] has quit [Ping timeout: 252 seconds] 12:07 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 12:16 -!- maraoz [~maraoz@43-161-16-190.fibertel.com.ar] has quit [Ping timeout: 264 seconds] 12:50 -!- bepo|here [~bepo@fer68-1-78-229-8-151.fbx.proxad.net] has joined #bitcoin-wizards 12:58 -!- earlz [~earlz@earlz.net] has joined #bitcoin-wizards 13:00 < Luke-Jr> earlz: having miners vote on max block size doesn't seem like the best idea - they can easily put other miners out of business that way (or prevent entry from new guys easier) 13:00 < Luke-Jr> proof-of-stake might make sense for this, but I'm not sure if it's feasable 13:01 <@gmaxwell> "John Dillion" had a genreal idea that I thought was interesting. Along the PoS lines. 13:03 < earlz> yea, that's what I was thinking as well 13:04 < earlz> (re: miners voting) 13:04 <@gmaxwell> Then there was one that that I had that I don't think has seen much discussion. Where basically you can increase the size over some median up to a hard limit (there to make sure non-miners aren't left out), but only by mining at a higher difficulty... the parameters can be set such that there is no incentive to include low fee transactions just to jump ahead of other miners. 13:05 <@gmaxwell> (this idea was used in bytecoin, but the based it on fee burning which triviall doesn't work; using difficulty adjustment seems like it would) 13:05 < earlz> yea, having block size similar to difficulty could be interesting 13:06 < earlz> I imagine like if average block size over retarget period is >75% of current max, increase max block size 13:06 < earlz> I can't imagine that being very gameable 13:07 <@gmaxwell> earlz: hm? thats trivially gamable. you just pad your blocks with crap transactions. 13:07 < earlz> but why would a miner do that? It makes their blocks more expensive ot broadcast 13:08 <@gmaxwell> infinitesmally so; and improved block propagation tools more or less eliminate even that small cost. 13:08 < earlz> plus bigger blocks with less actual transactions means less fees for miners (since priority isn't as imporant) 13:08 <@gmaxwell> earlz: you take all the fees, then pad out the rest to maximum; doing to pushes other miners out of business. 13:09 < earlz> why would it push other miners out? 13:10 <@gmaxwell> Because the cost of operating a node become macroscopic which favors single big entities because they only have to do it once. 13:10 < earlz> I mean miners could do that now if they wanted, since I don't think most blocks are close to full 13:10 <@gmaxwell> doesn't have an effect now, because blocks cannot be big enough to make the costs macroscopic. 13:11 <@gmaxwell> (though even with as low as the costs are we have seen huge consolidation) 13:11 < earlz> running a node isn't cheap because of diskspace, but other than that are there any other concerns? 13:11 < gavinandresen> bandwidth will be the bottleneck 13:12 < earlz> I imagine miners stuffing blocks not with just crap transactions, but expensive to process transactions 13:12 <@gmaxwell> earlz: perhaps but as gavin points out; bandwidth is the main concern. 13:13 < earlz> yea 13:13 < gavinandresen> earlz: what problem are you trying to solve with a dynamic maximum block size? 13:13 < earlz> I can't see any reason we'd need >20Mb blocks in the foreseeable future 13:13 <@gmaxwell> Really the long term histor shows that of all of storage/bandwidth/cpu bandwidth seems to grow the slowest (no surprises: there is serious infrastructure costs) and right now if you take your own capacities you'll likely find your transaction throughput limits are mostly bandwidth related. 13:14 < phantomcircuit> gavinandresen, iirc cpu time currently exceeds download time for my systems 13:14 < phantomcircuit> maybe that will change with faster validation 13:14 < gavinandresen> phantomcircuit: that’ll change with libsecp256k1.... 13:15 < earlz> I'm not trying to solve a problem with dynamic block size, I just saw it's a proposal and was wondering how that'd work 13:15 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards 13:15 -!- skyraider [uid41097@gateway/web/irccloud.com/x-vuguviaemctnjemk] has quit [Quit: Connection closed for inactivity] 13:16 < phantomcircuit> gavinandresen, possibly (i also have more bandwidth than most) 13:16 < gavinandresen> earlz: all the proposals for dynamic max block size I’ve seen don’t address the problems that a max block size is meant to solve 13:16 < gavinandresen> There are only two reasons I can see to limit the block size: 1) limit transaction spam 13:16 <@gmaxwell> phantomcircuit: I assume "my systems" are e.g. gigabit connected; If you were paying 1% of your three year bandwidth costs for a CPU that wouldn't be the case. 13:16 < earlz> max block size is there for propogation time and node cost limits right? 13:16 < gavinandresen> and 2) prevent possible over-centralization 13:17 < gavinandresen> Satoshi slapped on the 1MB limit to limit transaction spam. We’ve got that under control with the dust rule, transaction fees, free transaction rate limiter. 13:17 < earlz> it'd be nice if dust rules were a concensus rule 13:17 < gavinandresen> … so the only reason I see to limit the max size is the centralization concern. Which depends on real-world resource constraints, which can’t be determined by on-blockchain navel-gazing 13:18 <@gmaxwell> gavinandresen: You seem to be omitting, "preserving fee income as a mechenism to pay for ongoing security"; 13:19 < gavinandresen> gmaxwell: did you read my ‘blocksize economics’ blog post? I think fee income is, and will be, unrelated to block size 13:19 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] 13:19 <@gmaxwell> Which is something the perhaps dynamic sizing could help with, though I'm unsure. "security" is something outside the system, just as the centeralization concern. 13:20 < gavinandresen> gmaxwell: I’m curious why you think limiting block size will increase overall fees. 13:21 < earlz> I assumed it would because priority would be more pressured, so more people would want their transactions faster, so they'd pay higher fees 13:21 -!- jps [~Jud@172.56.34.62] has quit [Ping timeout: 246 seconds] 13:21 < gavinandresen> Fewer transactions with higher fees does not mean more fees overall… more transactions with lower fees might be better. 13:21 <@gmaxwell> gavinandresen: because it creates a reason to pay non-trivial amounts for fees; which is actually behavior we've seen in the network today. I believe that it's likely that there is some optimal blocksize limit where fee income is maximized; too large and there is no reason to pay anything. Too small and there isn't enough room to gather the fees available (and perhaps adoption of the system goes 13:21 -!- jps [~Jud@cpe-74-72-116-143.nyc.res.rr.com] has joined #bitcoin-wizards 13:21 <@gmaxwell> down) 13:22 <@gmaxwell> (and that curve might have multiple local maximums, sure) 13:22 < phantomcircuit> gmaxwell, well lets see 13:22 < gavinandresen> gmaxwell: my objection is your trying to reason about two fundamentally different things. There are lots of ways to secure transactions against double-spends that dont’ involve paying fees or relying on fast confirmation 13:23 < gavinandresen> e.g. we could end up in a world of very few high-value transactions that pay zero or minimal fees, because the banks involved all have contracts with each other and don’t have to pay miners to secure those transactions. 13:23 < phantomcircuit> 5253 seconds to reindex on a system with a Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz and the entire blockchain in fs cache 13:23 <@gmaxwell> gavinandresen: sure; but we're talking about the blockchain; whos purpose is to provide independant long term security against double spends. If you're happy to use some other mechenism than the behavior of the blockchain doesn't matter to you at all, perhaps. 13:23 -!- NomosOne [~NomosOne@pool-71-178-107-61.washdc.east.verizon.net] has quit [Remote host closed the connection] 13:23 < gavinandresen> … or we could end up in a world of gazillions of very-low-fee transactions that are secured by a third-party “I promise never to doublespend” instant confirmation service. 13:24 -!- shea256 [~hightorqu@65.209.72.194] has quit [Remote host closed the connection] 13:24 < phantomcircuit> blockchain is ~35GB currently 13:24 < phantomcircuit> which is 280000 megabits 13:24 < phantomcircuit> which is ~53mbps 13:24 <@gmaxwell> gavinandresen: yes yes all these things are true. And if those are successful it just may be uneconomical to have a blockchain at all. If so, that'll be pretty sad-- because it does give a very different kind of security than the alternatives. 13:24 < gavinandresen> My point is that we can’t reason about fees and block sizes. So the engineer in me says “make them as large as is safe, becase more is better" 13:25 < morcos> my fraction of a bit cent of input here is that we dont' really know how a free market for fees would work, and it might make sense to let blocks fill up so we can figure that out sooner rather than later 13:25 < phantomcircuit> and i cheated and added a checkpoint at like block height 330000 13:25 <@gmaxwell> phantomcircuit: a lot of the reindex time is not signature validation, alas. 13:25 < gavinandresen> morcos: blocks won’t fill up— what happens is low-value transactions just stop happening. 13:26 < phantomcircuit> gmaxwell, doesn't that effectively just clear the utxo and then read the raw block files? 13:26 -!- jps [~Jud@cpe-74-72-116-143.nyc.res.rr.com] has quit [Ping timeout: 252 seconds] 13:26 < phantomcircuit> ie time spent muching about with weird block files is likely going to be just as bad as or worse than getting them from peers 13:26 < phantomcircuit> mucking* 13:27 -!- jps [~Jud@198.199.83.156] has joined #bitcoin-wizards 13:28 < morcos> gavinandresen: well thats what i mean, right now no transactions are discouraged except literally by the hard coded dust or fee relay limits. those are so close to zero, that it might make sense to see what happens when market forces cause slightly higher value tx's to be discouraged (but still low value) 13:29 < morcos> i suppose though that this could be through default miner policy instead of hard coded consensus limit, so that its easier to increase capacity if that min economical tx value starts getting too rich 13:29 < gavinandresen> some people already think the min economic value is too rich… I get asked by people who want to bring Bitcoin to India or Africa to please support lower-value transactions 13:31 < phantomcircuit> im not sure you can actually do that without completely destroying the transaction fee incentives 13:31 <@gmaxwell> phantomcircuit: right now if you assume sig 72+ pub 32+ vin 40 + 2 bytes push overhead. then libsecp256k1 on a quadcore i7 does about 81mbit/sec of verification. OpenSSL is about 10mbit/sec. 13:31 < phantomcircuit> gmaxwell, right but there's a certain amount of overhead to that 13:32 < phantomcircuit> remember this is with a cheater checkpoint at 330000 13:32 < phantomcircuit> so i was doing almost no signature validation 13:32 < phantomcircuit> 50mbps is almost entirely just overhead 13:33 <@gmaxwell> phantomcircuit: I'm just pointing out that if you have less than 80mbit/sec bandwidth and a basic quad core cpu, then verification should not be your bottleneck. Other cpu bound parts contribute though, so cpu might be though that can be optimized out. 13:33 < gavinandresen> phantomcircuit: a 1MB block full of 1-cent-per-kilobyte transactions is about the same as a 10MB block full of 0.1-cent-per-kilobyte transactions … both pay miners the same. For users, the 10MB block is better. Better for users means more BItcoin utility, which should mean more valuable coin.... 13:33 < gavinandresen> … which drives my intuition on why the block size should be as large as possible. 13:33 < phantomcircuit> gmaxwell, right ok 13:33 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [] 13:34 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 13:34 < phantomcircuit> gavinandresen, that's only going to work if there's size pressure at 10MB though 13:34 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 13:34 -!- Oizopower [sid19103@gateway/web/irccloud.com/x-gwpqsrkppeqczerr] has joined #bitcoin-wizards 13:34 < gavinandresen> phantomcircuit: we have no size pressure at 1MB right now, why is anybody paying a fee? 13:34 < phantomcircuit> gmaxwell, oh you know what, i had txindex=1 13:34 < phantomcircuit> i'll run again with that disabled 13:35 < gavinandresen> actually, let me disagree: we DO have size pressure, because some miners produce smaller-than-1MB blocks. 13:36 < gavinandresen> I think we’ll always have size pressure, because some miners will choose to produce smaller-than-whatever-the-max-is blocks. 13:36 < gavinandresen> For either philosophical or practical reasons 13:36 < jcorgan> isn't there size pressure at any time just from the increased possibility of orphans? might only be a small contributor. 13:37 <@gmaxwell> jcorgan: not really; it's small and can be made basically zero with more intelligent transport. 13:37 <@gmaxwell> Maybe at the moment there is; but it's not fundimental. 13:37 < jcorgan> got it 13:37 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Client Quit] 13:38 < gavinandresen> I have a sneaking suspicion that we should try to establish a social convention that large-value transactions pay a 0.01% ‘health of the network’ fee…. 13:38 <@gmaxwell> gavinandresen: I am not sure that some small number of participants producing small er blocks actually counts as pressure in a system which is otherwise unlimited. It's basically the same as if those miners weren't mining at all, and you just had an unlimited system with blocks slightly less frequently. 13:38 < phantomcircuit> jcorgan, interestingly the underlying structures strongly discourage mining blocks with unbroadcast transactions 13:38 < phantomcircuit> which seems like a happy coincidence 13:40 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 13:40 < gavinandresen> gmaxwell: if it is in the best interest of miners to produce smaller blocks then it shouldn’t be too hard for them to band together and agree to produce smaller blocks.... 13:40 < morcos> gavinandresen: large unmoving balances also benefit from the 'health of the network' 13:40 <@gmaxwell> gavinandresen: social conventions seem to be remarkable unrelialbe for systems where relationships aren't persistent. I wish I knew how to encourage that sort of thing in a convincing way... there are also some variance issues with it; e.g. 10000 btc transaction happens and the returns just go to a single miner, not exactly ideal for hashrate stability. 13:41 < morcos> i know this question is blasphemy, but do people ever think it would have been better if the system were designed with a small but permanent inflation rate in the steady state 13:42 <@gmaxwell> gavinandresen: Yes, it might also be in their best interest to agree that they want a 10% cut of each transaction. "We'll conspire over and above the rules" has its negative uses too. Ideally we should have a system which doesn't instutionalize that kind of behavior. Especially because making such an agreement "only mine fees of x" stick requires things like non-anonymous mining and/or soft-fork 13:42 <@gmaxwell> ing out / punishing blocks that don't agree with the cabal. 13:42 <@gmaxwell> morcos: it might have been, but it seems impossible to calibrate. 13:42 < gavinandresen> morcos: if I was Satoshi I would have done the Milton Friedman thing and had a steady 2%-per-year inflation ..... 13:43 <@gmaxwell> morcos: say that the rate was was 1% of 21e6 per year.. but then varrious computer disasters happen (as they have happened) and over time only 1 million doins remain unlost. Now your inflation rate is more like 20%! 13:43 < gavinandresen> gmaxwell: I’m tempted to pull out that famous Hayek quote about the curious task of economics..... 13:44 < morcos> gmaxwell: interesting.. but only temporarily right... not sure that makes that disaster that much worse does it 13:44 < gavinandresen> gmaxwell: we can go around and around arguing about angels dancing… I mean theoretical fee market dynamics. 13:45 < gavinandresen> I don’t want to make policy… which is why I want the block size to be as large as feasible, engineering-wise. 13:45 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [] 13:45 < gavinandresen> Then let the economics fall out however they fall out. 13:45 <@gmaxwell> gavinandresen: thats also policy too. 13:46 < gavinandresen> That is “as simple as feasible” policy. 13:46 < gavinandresen> The only policy that would be simpler would be NO max block size, which is actually my preference, but which I won’t propose. 13:47 <@gmaxwell> But it's not simple; it completely undermines the "what will pay for security" fold of the system; or at least replaces it with an even more complex set of armwaving which we already had. 13:47 -!- shea256 [~hightorqu@65.209.72.194] has joined #bitcoin-wizards 13:47 <@gmaxwell> gavinandresen: thats just incompetent engineering-- no block size. We can't even make software that could accomidate that without falling over. 13:47 < gavinandresen> The “what will pay for security” when the block subsidy goes to zero has NEVER been determined, though! 13:47 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Read error: Connection reset by peer] 13:48 <@gmaxwell> "oh sorry, your mission criticial infrastructure is just going to stop at some unspecified time in the future because third parties-- who might gain economically from your failure-- have done something which cost them nothing. 13:48 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards 13:48 <@gmaxwell> gavinandresen: That is _explicitly_ what transaction fees are for. 13:48 < gavinandresen> gmaxwell: no hard-coded consensus-rule max block size… of COURSE there would be a soft maximum block size that nodes would refuse to process 13:48 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 13:48 < gavinandresen> gmaxwell: … sigh … 13:49 < phantomcircuit> something something video of you saying sigh 13:49 <@gmaxwell> gavinandresen: Yes, different potentially on every system. Which is not acceptable. 13:49 < fluffypony> I remain unconvinced that tx fees will be enough to sustain it 13:49 < gavinandresen> Satoshi did not impose the 1MB limit because he was worried that transaction fees would be zero if blocksize was unliminted. 13:49 <@gmaxwell> morcos: well coins are always being lost and the system has no real way to know. If you say that you'll have unmoved coins expire in order to know they're lost; then there is an incentive to suppress transactions to reduce supply then. :( 13:50 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Client Quit] 13:50 <@gmaxwell> gavinandresen: Perhaps not (or the 32MByte limit befor that 1MB one). But it doesn't change that the expectation has always been that transaction fees would pay for decenteralized security; and absent some scarcity in block size I really have no argument as to how thats possible. 13:52 < gavinandresen> gmaxwell: but the argument that the 1MB block size will be sufficient to force fees to pay for security is… well, not an argument 13:52 < justanotheruser> gmaxwell: what about increasing odds of stale with more transactions, isn't that a pretty good incentive? 13:52 <@gmaxwell> I agree that 1MB forever is brain damaged and also unlikely to work out great in the long run; so I haven't been responding in public disagreeing with your approach much. 13:52 <@gmaxwell> justanotheruser: its not a fundimental effect. 13:52 < morcos> @gmaxwell: my point was only that if you add 21e4 coins per year, then your supply is growing so your inflation rate becomes less until loss rate = inflation rate. then you temporarily bump to high inflation on loss shocks. 13:52 < gavinandresen> gmaxwell: I don’t know what the answer will be to secure the blockchain in the future. I expect it will be something like assurance contracts.... 13:52 < morcos> @gmaxwell: i agree expiring coins is risky. anyway, wishful thinking at this point, it is what it is 13:53 < gavinandresen> … unless some ‘send money to transaction fees to establish identity / create a bond’ becomes popular 13:53 <@gmaxwell> gavinandresen: The assurance contract stuff mike has written about don't really make any sense. I mean, they equally pay for people to create malicious forks. So, I think thats not so helpful. 13:53 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 13:54 < gavinandresen> gmaxwell: My basic economic reasoning is that we should do everything we can to maximize the value of the Bitcoin system, for all applications / uses / etc. 13:54 <@gmaxwell> gavinandresen: sadly "burn coins" seems to be more attractive than "pay fees" because it eliminates the 'risk' that the miner themselves creates the bonds for free without a complex protocol. :( 13:54 < gavinandresen> gmaxwell: If we do that, I am convinced that some way will be found to keep the chain secure enough for those uses 13:55 < kanzure> convinced by what? 13:55 <@gmaxwell> gavinandresen: I don't disagree with you there, but I believe the all of the value of the Bitcoin system (as opposed to the many vastly more efficient alternatives) is owed to its decenteralization. And part of that means we must have a security mechenism which doesn't depend on a clique of signers that can do whatever they want. 13:55 < gavinandresen> I don’t claim to know HOW people will do that. Maybe BitPay will run a huge mining operation to limit double-spend risk. 13:56 < kanzure> (isn't that a clique of signers?) 13:56 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has joined #bitcoin-wizards 13:56 < gavinandresen> gmaxwell: I agree with keeping things decentralized, and that’s the reason I agree that limiting the max block size is a reasonable thing to do 13:56 <@gmaxwell> kanzure: thanks. 13:56 < kanzure> i seem to have stumbled into the wrong alternate reality 13:56 < kanzure> you see, sometimes my irc client messes up like this 13:57 <@gmaxwell> gavinandresen: the decenteralization losses can come from multiple angles; one is being able to run at node at all. Another is having mining actually be a security mechenism. I mean, you can let the diff fall to one and use signed blocks and have "security", but at the loss of decenteralization. 13:57 < gavinandresen> gmaxwell: … maybe the chain will be secured by “voluntary” $10 transaction fee on every greater-than-$100,000 transaction… who knows? 13:58 < kanzure> well, arguably we know, by reasoning 13:58 < jcorgan> why would you put "voluntary" in quotes? 13:58 <@gmaxwell> jcorgan: certantly thats one of the things that concerns me. "let the market figure it out" ... well sure it will, you might not like the answer. 13:58 < gavinandresen> gmaxwell: let me ask a different way: if we didn’t have the 1MB max block size, what max block size would you choose right now? How would you decide? 13:59 < kanzure> yeah, isn't the market-friendly solution something like completely centralized? 13:59 -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection] 13:59 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:6df8:6fcd:db2b:985d] has quit [Read error: Connection reset by peer] 13:59 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards 13:59 < justanotheruser> if the market friendly solution was centralized, would bitcoin have any chance of success? 14:00 < kanzure> yeah i phrased that poorly, sorry 14:00 <@gmaxwell> kanzure: yes, I think so. But markets are not simple, and people aren't perfect economic maximaxers; and such. 14:00 < kanzure> miners have no particular reason to prefer decentralized designs in the long-term, as long as the centralized options tend to favor them 14:01 < gavinandresen> For reference: https://blog.bitcoinfoundation.org/blocksize-economics/ 14:02 < justanotheruser> Short term miners may favor centralized solutions, but since centralization causes them to not be needed/paid, longterm miners should favor a decentralized solution. 14:02 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!] 14:02 < kanzure> you can be paid even in centralized solutions 14:02 <@gmaxwell> gavinandresen: If I knew for sure I would be saying "We need to do X now" whatever that X is. Absent knowing I'd probably set it as low as possible where the system could still be widely used. A some number of years ago I might well have picked 1MB since thats 14kbit/sec. 14:02 < justanotheruser> but why would anyone pay for miners in a centralized solution 14:02 -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection] 14:03 < kanzure> justanotheruser: they wouldn't, they pay some bank or whatever, who cares, that's not my specialty 14:03 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards 14:03 < gavinandresen> gmaxwell: I think we’re in violent agreement, then. I’m proposing to set it low enough to ensure it can be widely used 14:03 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [] 14:04 -!- prodatalab [~prodatala@2601:3:9281:5280:6d28:7045:2fc:1598] has joined #bitcoin-wizards 14:04 < gavinandresen> (and growing it a little slower than technology is growing) 14:05 -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection] 14:05 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards 14:05 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 14:07 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Client Quit] 14:07 <@gmaxwell> Something like 40x larger than the current offered load seems a little shocking to me. Especially in that I think we have strong evidence that we're failing to maintain good decenteralization with the levels we have right now. (though I'm hesitant to pound on that point because 0.10 and 0.11 will improve things a lot) 14:07 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 14:08 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Client Quit] 14:09 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 14:09 < gavinandresen> gmaxwell: okey dokey. Not sure what I can do to convince you that 20MB blocks are not insane besides what I’m already doing.... 14:10 -!- jb55 [~jb55@208.98.200.98] has quit [Ping timeout: 252 seconds] 14:10 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Client Quit] 14:10 < gavinandresen> All of the transaction fee pressure arguments seem like red-herrings to me: same arguments apply to 10K blocks as 1MB blocks as 20MB blocks, unless you have some way to compute the optimal size there’s not much to talk about there. 14:11 -!- shea256 [~hightorqu@65.209.72.194] has quit [Remote host closed the connection] 14:11 < morcos> decentralization is 2 issues to me, full nodes and mining. to the extent they are both problems i think 20MB blocks is a bit of a jump for the full node issue. 14:11 < gavinandresen> morcos: why? 14:11 <@gmaxwell> I don't yet know if its insane or not; you just started doing these tests recently; though we'd talked about it a long time back. As I said right now, I've been too concerned with just the current level, and I think right now we have very strong evidence that the current scale is not sustainable, but I think the evidence is no good because it can be resolved with straight forward software improve 14:11 < gavinandresen> morcos: you don’t expect block sizes to jump to 20MB immediately just because MAX_BLOCKSIZE changes, do you? 14:11 <@gmaxwell> ments. 14:11 < morcos> but i don't see as to how it matters for mining. speaking of someone who has never mined, there are far greater overheads in mining than worrying about bandwidth and other capacity constraints of a full node 14:12 < kanzure> gmaxwell: right, absent some of the recent bitcoind changes, i would agree that increasing block sizes would be particularly dangerous 14:12 <@gmaxwell> morcos: actually it's horrible; because already miners hand over their mining to centeralized pools (and miner rental services) blindly very easily. The friction there is bad. 14:12 < kanzure> *some of the other recent bitcoind changes 14:13 < morcos> gavinandresen: just a "bit" maybe, i mean until we have autoprune and other things, the blockchain is already unwieldy in size 14:13 < earlz> is there any ideas out there for replacements to PoW or ways to decrease centralization? 14:13 < earlz> other than the obvious one, PoS 14:13 < kanzure> although i'm not sure if i should consider headers-first to be recent or not, now. what year is this? 14:13 < kanzure> earlz: that's not really an option 14:14 < morcos> gmaxwell: maybe i'm just not in tune with what miners do, but seems to me that the hard part is getting competitive hashing hardware and hosting facilities.. 14:14 < gavinandresen> morcos: I assume autoprune and optimizing initial block download will happen in any case— it HAS to if we want the number of full nodes to start going back up. 14:14 < earlz> I mean modifications to PoW even 14:14 <@gmaxwell> gavinandresen: and as I talk businesses in the bitcoin space and engineers, I am being told that people do not want the costs of running their own nodes; and that they had problems and turned them off. (even in my case; I stop all my nodes one a week for a conference call, because the bandwidth spikes make VoIP unusable for me) 14:14 < earlz> idk.. I know it's all crazy talk, but eh 14:14 <@gmaxwell> But I don't think this is fundimental; I think we can fix it. So I can't hold that against 20MBytes. 14:15 < morcos> hooking up to a pool is for variance reduction, not because running a full node is hard. if i was going to make the jump to do mining, i can't imagine i'd think anything of runnign a full node 14:15 < gavinandresen> gmaxwell: right, that needs fixing in any case. 14:15 -!- NomosOne [~NomosOne@pool-71-178-107-61.washdc.east.verizon.net] has joined #bitcoin-wizards 14:15 < kanzure> gmaxwell: isn't there an rpc bandwidth limiting parameter thing? 14:15 * kanzure looks 14:15 <@gmaxwell> kanzure: there isn't yet, without headers first it really screws up nodes behavior if their peer during IBD is throttled. 14:15 < gavinandresen> I don’t think either of our current centralization issues (mining and number of full nodes) are tied to block size. 14:15 <@gmaxwell> Next version. 14:16 < gavinandresen> gmaxwell: are there concrete proposals yet for how to tackle mining centralization? Besides hope pools use getblocktemplate more.... 14:17 <@gmaxwell> gavinandresen: I know with absolute certanty that the are; I am not sure how much. But I watch constantly as miners _try_ to run full nodes and give up after 2 days of syncing and switch to using conman's 1% fee "solopool". 14:18 <@gmaxwell> gavinandresen: luke's been working on protoocol enhancements that split coinbase and work selection, I'm soon hiring someone to help on that; which might help... but still requires someone to run a node. 14:18 < gavinandresen> gmaxwell: so we need to get consensus on UTXO commitments in the chain, so syncing up a full node takes less than 11 minutes. 14:19 < gavinandresen> … err, syncing up a “fully validating but not all historical txns” node 14:19 < morcos> and we need to hope top of the line mining hardware becomes more of a commodity 14:19 < gavinandresen> That plus pruning solves the problem, no matter the block size, yes? 14:20 <@gmaxwell> gavinandresen: We're down to 2.5 hours synctime in 0.10 on fast hardware without libsecp256k1. 14:20 < kanzure> cool 14:20 < gavinandresen> gmaxwell: yes, but 11 is my favorite number. SO eleven minutes..... 14:20 < kanzure> full blockchain sync? 14:20 <@gmaxwell> kanzure: yes 14:21 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 14:22 -!- rasengan [rasengan@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has quit [Ping timeout: 244 seconds] 14:22 <@gmaxwell> gavinandresen: Having you just sign all the blocks "solves" things too. "Just ignore the history" isn't a free trade-off, and the utxo commitments greatly increase the runtime costs for full nodes (though we don't know how much; they probably double the utxo set size at a minimum). We need to address the non-security impacting improvements (pruning; bandwidth shaping; secp256k1 library) first. 14:22 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-wizards 14:22 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host] 14:22 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 14:24 < earlz> why is it so expensive to run a full node? I'd assume for running a pool, the node would be the cheapest thing 14:24 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Client Quit] 14:24 -!- rasengan [rasengan@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has joined #bitcoin-wizards 14:24 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 14:25 <@gmaxwell> earlz: it's a constant cost regardless of how much hashpower you have, so it amortizes well (favors centeralization) 14:26 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Client Quit] 14:26 -!- c0rw1n__ [~c0rw1n@99.181-243-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 14:26 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 14:26 < ajweiss> but minimum viable hashpower is orders of magnitude more expensive, no? 14:26 <@gmaxwell> Stupidly implemented a comitted utxo takes N hash operations per txout created or deleted, and N additional disk IO, and 2*N storage (assuming a txout is the same size as a hash). As opposed to 1, 1, N. (where N=ceil(log2(txouts)) == 23, right now) 14:27 <@gmaxwell> ajweiss: huh, there is no such thing as "minimum viable hashpower", mining is linear. I mean if you account for the cost of your time, then there is some threshold there; but if you're talking about running a node and mining the running a node part probably takes more of your time and attention than the rest. 14:28 < gavinandresen> gmaxwell: mmm… well, if the problem is “get fully-validating nodes up and running quickly” then O 14:28 < gavinandresen> … I’d be OK with compromising on utter decentralization 14:28 < kanzure> would you be okay with a central authority validating transactions 14:28 < ajweiss> fair, unless there's a mining "distribution" 14:29 < ajweiss> plug in p2pool or something 14:29 -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 246 seconds] 14:29 -!- c0rw1n___ [~c0rw1n@67.163-243-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 14:29 -!- HarusameNyanko [~HarusameN@pl2125.nas815.n-hiroshima.nttpc.ne.jp] has quit [Ping timeout: 245 seconds] 14:30 -!- c0rw1n [~c0rw1n@133.173-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds] 14:30 <@gmaxwell> We do in an number of ways already; so I agree but being intelligent about that requires facing the tradeoffs. We're obviously not better off in a situation where there are very full full nodes because we didn't have a good halfstep. 14:30 -!- c0rw1n___ is now known as c0rw1n 14:30 <@gmaxwell> ajweiss: a distribution though increases your cost to a whole extra computer; which is actually fine for some; and ought to be more widely done/supported. 14:31 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:5448:93dd:cfe0:ff7a] has joined #bitcoin-wizards 14:32 -!- c0rw1n__ [~c0rw1n@99.181-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 14:33 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:5448:93dd:cfe0:ff7a] has quit [Client Quit] 14:34 -!- Xzibit17 [uid50165@gateway/web/irccloud.com/x-ylehmamnpfoekrax] has joined #bitcoin-wizards 14:34 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards 14:34 < ajweiss> yeah true, i suppose i keep forgetting that miner margins can be pretty thin 14:35 < ajweiss> although, i dunno, i'd argue if they're sufficiently thin that that would be a problem, you've probably got bigger problems 14:35 -!- Quanttek [~quassel@2a02:8108:d00:870:e23f:49ff:fe47:9364] has quit [Ping timeout: 272 seconds] 14:36 <@gmaxwell> people don't know what their margins actuall are, even at industrial scale; it results in some really weird behavior. 14:36 <@gmaxwell> E.g. microoptimizing on costs you feel you can control, while being pound foolish on the others. 14:37 <@gmaxwell> A modern miner is super trivial to setup if using a centeralized pool. I think I had my SP20 I just go running in 10 minutes after the package showed up (against my local p2pool, which is just as easy if it's already running; but only if its already running). 14:43 -!- orik [~orik@75.149.169.53] has joined #bitcoin-wizards 14:44 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: apple apple glibc] 14:45 -!- mortale [~mortale@gateway/tor-sasl/mortale] has quit [Remote host closed the connection] 14:45 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:9185:2828:fe2f:1b5b] has joined #bitcoin-wizards 14:47 -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards 14:48 -!- dasource [uid48409@gateway/web/irccloud.com/x-hdchncqwznwzknpv] has joined #bitcoin-wizards 14:55 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [] 14:56 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards 15:00 -!- PRab_ [~chatzilla@66.184.180.94] has joined #bitcoin-wizards 15:01 -!- treehug88 [~treehug88@static-96-239-100-47.nycmny.fios.verizon.net] has quit [] 15:01 -!- PRab [~chatzilla@98.209.175.213] has quit [Ping timeout: 264 seconds] 15:01 -!- PRab_ is now known as PRab 15:05 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-wizards 15:05 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host] 15:05 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 15:05 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 15:11 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 15:12 < phantomcircuit> so removing txindex=1 dropped the reindex time (with my cheater checkpoint) 15:12 < phantomcircuit> down to 4836 seconds 15:12 < phantomcircuit> which is ~57mbps 15:12 < phantomcircuit> gmaxwell, ^ does that seem reasonable for overhead not including 99% of signature validation? 15:13 -!- weex [~weex@fsf/member/weex] has joined #bitcoin-wizards 15:16 <@gmaxwell> pretty darn slow, really. though you've still got a bunch of signing. it would be good to just turn off all signature validation (bool fScriptChecks = false;) and benchmark a reindex. 15:17 -!- hktud0 [wq@unaffiliated/fluffybunny] has joined #bitcoin-wizards 15:18 -!- PRab_ [~chatzilla@c-98-209-175-213.hsd1.mi.comcast.net] has joined #bitcoin-wizards 15:21 -!- PRab [~chatzilla@66.184.180.94] has quit [Ping timeout: 240 seconds] 15:21 -!- PRab_ is now known as PRab 15:22 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards 15:22 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 15:22 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards 15:22 < phantomcircuit> gmaxwell, can do 15:23 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Remote host closed the connection] 15:25 < phantomcircuit> actually checkpoint was at + (338856, uint256("0x00000000000000000deb14265ff457fe242adaf83c11f2785dc70b1643834be4")) 15:26 <@gmaxwell> oh... thats almost at the tip. 15:26 <@gmaxwell> well thats just as good then. 15:26 <@gmaxwell> yea, so thats ... slow. 15:26 < phantomcircuit> yup 15:26 <@gmaxwell> phantomcircuit: what dbcache are you running with? 15:26 < phantomcircuit> 4096 15:26 < phantomcircuit> system has 80GB of ram 15:27 <@gmaxwell> yea, so even leveldb should not possibly be at fault for that, since basically the whole sync should be in ram then. 15:27 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Client Quit] 15:27 < phantomcircuit> actually even has 6.3GB of entirely free ram 15:27 <@gmaxwell> Know how to use oprofile? :P 15:27 < phantomcircuit> nope, usually run perf 15:27 < phantomcircuit> unless 15:28 < phantomcircuit> same interface? 15:28 <@gmaxwell> perf works too. 15:31 -!- shea256 [~hightorqu@cpe-72-225-237-141.nyc.res.rr.com] has joined #bitcoin-wizards 15:34 < phantomcircuit> gmaxwell, oh and this is built with --disable-wallet also 15:34 < phantomcircuit> so this is likely very close to optimal performance 15:34 < phantomcircuit> at least with current systems 15:36 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [] 15:39 -!- wallet42 [~wallet42@2a00:1028:8380:95e2:f5eb:cc5c:3467:a91a] has joined #bitcoin-wizards 15:39 -!- wallet42 [~wallet42@2a00:1028:8380:95e2:f5eb:cc5c:3467:a91a] has quit [Changing host] 15:39 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 15:39 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 15:45 -!- huseby [~huseby@unaffiliated/huseby] has quit [Ping timeout: 256 seconds] 15:45 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 15:46 -!- cryptowest [~cryptowes@191.101.1.104] has joined #bitcoin-wizards 15:50 -!- huseby [~huseby@unaffiliated/huseby] has joined #bitcoin-wizards 15:50 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 15:55 -!- waxwing [waxwing@gateway/vpn/mullvad/x-nqbderayjezcfvxv] has quit [Ping timeout: 264 seconds] 15:55 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 15:55 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards 15:56 < phantomcircuit> hmm 15:56 < phantomcircuit> well that's vaguely annoying 15:56 < phantomcircuit> perf doesn't seem to be updating the record until i exit 15:57 < phantomcircuit> no that's not right... 16:00 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards 16:08 -!- orik [~orik@75.149.169.53] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 16:09 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 16:10 -!- waxwing [waxwing@gateway/vpn/mullvad/x-helrvbpgexyadvuf] has joined #bitcoin-wizards 16:11 -!- pgokeeffe [~pgokeeffe@101.165.93.194] has quit [Ping timeout: 240 seconds] 16:15 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards 16:15 < bramc> Hey everybody 16:16 -!- NomosOne [~NomosOne@pool-71-178-107-61.washdc.east.verizon.net] has quit [Remote host closed the connection] 16:16 -!- Dizzle [~diesel@70.114.207.41] has quit [Quit: Leaving...] 16:16 < bramc> Last time I was in here, I forgot to explain how to make sequential proofs of work deterministic, and how this fixes a huge number of problems 16:18 -!- shea256 [~hightorqu@cpe-72-225-237-141.nyc.res.rr.com] has quit [Remote host closed the connection] 16:18 < bramc> It turns out they can be made very compact in a way which is either lame trick or an elegant solution, depending on how you look at it. 16:21 < bramc> It's quiet in here 16:21 < kanzure> not many people in here respond to leading statements 16:22 < kanzure> speak your mind and then answers will be typed eventually (no quality of service guarantees, yo) 16:22 < bramc> Oh good, there's at least one person here 16:24 < ajweiss> what is a sequential proof of work? 16:24 < bramc> So there are three things I would like to discuss - (1) the spow stuff (2) possibilities for squeezing more performance when proof of storage, and (3) possibilities for gaming in my mixed pos/spow system 16:24 -!- Tjopper [~Jop@dhcp-077-249-237-229.chello.nl] has quit [Ping timeout: 255 seconds] 16:24 < bramc> A sequential proof of work is a proof of work which requires a certain amount of time to do, basically a proof that time passed between two events 16:25 < bramc> most pow is heavily parallelizable of course 16:26 < bramc> for the protocol I was talking about, it's very important that the spow be canonical on what it's operating on, because its hash is used as the beginning of the next generation 16:27 < bramc> So anyway, my idea for a spow goes like this: 16:27 < bramc> You start with a thing you want to do a spow on, and a work factor K. 16:27 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 16:28 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards 16:28 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Client Quit] 16:28 -!- Tjopper [~Jop@dhcp-077-249-237-229.chello.nl] has joined #bitcoin-wizards 16:29 < op_mul> gmaxwell: I'd like to think that for most cases, a SPV stepping stone is enough to cover up the initial sync time for wallet users. 16:29 < bramc> You then repeatedly hash your start thing K times, then take a single bit of the final value and append it to your initial string 16:29 < kanzure> sequential proof of work is http://diyhpl.us/~bryan/papers2/bitcoin/Publicly%20verifiable%20proofs%20of%20sequential%20work.pdf 16:29 < phantomcircuit> bramc, time lock puzzle 16:30 <@gmaxwell> op_mul: I'd like that too, but it's not implemented anywhere yet. 16:30 < bramc> (hash functions don't generally operate on strings which aren't a bit length which isn't a multiple of 8, but that can easily be papered over) 16:30 < op_mul> gmaxwell: interestingly, an altcoin has it. 16:31 < phantomcircuit> bramc, give me a time lock puzzle in which a solver can cheaply prove that they solved the puzzle and the setup is non trusted (ie there is definitely a solution) and i will be your bestest friend 16:31 < op_mul> it's on a 0.6 branch or something, so I doubt portable upstream, but interesting it exists to begin with. 16:31 < bramc> phantomcircuit, no time lock puzzles are different. Those have a challenger set something up to be unlocked later. A spow is more like a slow hash which operates on something which was set up non-interactively 16:31 < phantomcircuit> maybe you have done that 16:31 < bramc> phantomcircuit, I have one but I'm 'cheating' a bit, bear with me 16:32 <@gmaxwell> op_mul: one of the advantages of headers first is that it makes that 'easy'. 16:33 < phantomcircuit> if you can construct something as i've described above i suspect you can achieve a certain degree of censorship resistance which isn't vulnerable to witholding attacks at low cost by utilizing the ordering provided byt he bitcoin chain 16:33 < bramc> So you've now appended a single bit which took some amount of time to calculate to your initial string. You then hash that and repeat, adding one bit at a time until you've put together, let's say, 1k of bits. That's your spow 16:33 < op_mul> gmaxwell: of course. 16:35 < bramc> So this spow has the benefit of being nice and small, and can be spot checked quickly, but fully checking it requires as much CPU as doing the initial work did. But the checking can be done in parallel where the generation can't 16:37 < bramc> phantomcircuit, There's a subtly different thing which is a spow which isn't completely canonical but where the proofs can be checked quickly. I figured out some improvements to the paper kanzure linked to and have gotten the proof sizes down to around 100k. I probably won't be using that myself, but am happy if someone else can get some use out of it. 16:37 < bramc> Even have it implemented, in fact. 16:39 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-wulndztoshsiqolb] has quit [Quit: leaving] 16:39 < bramc> Anyway, for my more compact spow the idea is that everybody when they get one spot checks it, then redistributes if it passes spot check. Peers can tell you if it failed their spot check, and if so you double-check the spot which they claim failed and then notify everybody you know about it. That way wrong proofs of work can't get far, and the fixes will inevitably converge on a truly fixed one. Also if you get two diffe 16:39 < bramc> rent alleged spows, comparing them is very easy: Take the first divergence between the two and check it. 16:40 < kanzure> are these trusted peers or what 16:41 < bramc> If you make the spow 1k long, that's around 8000 bits, so if it's a proof of, say, 200 seconds, checking a single bit only takes 50 milliseconds 16:41 < bramc> kanzure, untrusted peers, although sending out an invalid spow is considered a bit rude. 16:42 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] 16:42 < phantomcircuit> 2015-01-15 00:41:58 UpdateTip: new best=00000000000000000cddde53e529a27518f219772827330232b52135ace13a31 height=328820 log2_work=81.362307 tx=50725654 date=2014-11-06 14:41:40 progress=0.837653 cache=4104599 16:42 < phantomcircuit> 2015-01-14 23:57:37 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 log2_work=33.000022 tx=2 date=2009-01-09 02:54:25 progress=0.000000 cache=1 16:42 < bramc> And checking bits can be done in parallel 16:43 < bramc> phantomcircuit, what? 16:43 <@gmaxwell> bramc: context is before you joined. 16:43 < kanzure> http://gnusha.org/logs/2015-01-14.log 16:43 <@gmaxwell> phantomcircuit: what did you fix? 16:43 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-wrcledlimmzbrnke] has joined #bitcoin-wizards 16:43 < phantomcircuit> gmaxwell, i forced fCheckScript = false 16:43 < phantomcircuit> and have perf records 16:44 < sipa> phantomcircuit: that'd be interesting 16:44 <@gmaxwell> hm. So really the last chunk there was actually scriptsl but in the small span at the end? hm. an hour of them? 16:44 <@gmaxwell> your prior run was 4836 seconds, right? 16:44 < phantomcircuit> gmaxwell, the day wrapped around 16:45 <@gmaxwell> I know, I can date math, it was about 45 minutes this run. vs 80. 16:45 < phantomcircuit> no you're right 16:45 < phantomcircuit> 2661 seconds 16:45 <@gmaxwell> 35 minutes of signature checking is surprising. 16:46 < phantomcircuit> the only thing i changed was fScriptchck=false 16:46 <@gmaxwell> I believe you. 16:46 < phantomcircuit> well that and perf 16:46 < sipa> how many cores? 16:46 <@gmaxwell> infinity 16:46 < phantomcircuit> i cant imagine perf made it faster... 16:46 < phantomcircuit> sipa, on this system 8 cores 16:46 <@gmaxwell> oh this isn't one of the 40 core hosts or whatever? okay. 16:46 < sipa> probably... around 100us for a validation? 16:46 < phantomcircuit> the run before had a checkpoint at 338856 16:46 <@gmaxwell> in any case the prior run had a checkpoint at 338856. 16:47 < sipa> 100 wall-us, that is not 100 cpu-us 16:47 <@gmaxwell> so it would have only verified about 120 blocks worth of signatures. 16:47 <@gmaxwell> we should probably move to #bitcoin-dev 16:47 < sipa> 35 minutes of sigchecks at 100us per check: 10M transactions 16:48 < kanzure> whoops my last link was wrong, i meant http://gnusha.org/bitcoin-wizards/2015-01-14.log 16:48 < bramc> gmaxwell, I looked into the possible types of attacks you asked about, it turns out that there's some pooling advantage to be had but not much, and there's a neat trick which can effectively double storage proof size but it may be impractical 16:49 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 16:49 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 16:50 < bramc> The doubling is a neat trick. Let's say you have a trillion locations to store keys in and doing a million key generations is fast. 16:52 -!- bendavenport [~bpd@64.124.157.148] has quit [Ping timeout: 252 seconds] 16:53 -!- Adlai [~Adlai@unaffiliated/adlai] has quit [Quit: WeeChat 1.0.1] 16:55 < bramc> When evaluating a single salt you can instead of deriving one key from it derive two. and view the buckets of places you would like to be closest to as being arranged in a square. For a given salt, let's say that the locations it generates keys for are (x, y) and (z, w). You put that salt in either (x, w) or (y, z) 16:55 < bramc> Whichever one happens to not already be filled. 16:59 < bramc> Then when you need to find a nearest match for a particular hash root, check everything in its row and column. That's 2 million things to check, which should be fast, and it merely double the amount of cpu necessary to fill all of storage. This comes with some headaches of course. Everything has to be bucket sorted very precisely, instead of merely sorted. And the real killer is all the seeks it has to do, that's likely 16:59 < bramc> to make it utterly impractical on physical hard drives. 17:03 < bramc> You can mitigate all the seeking by pooling things up a bit. For each salt derive a thousand keys from it. If we subdivide the terabyte into a million separate pools, each two of those keys will probably be of the same pool. We then apply the same trick within each pool, organizing into a thousand by thousand square and positioning the found key appropriately. 17:05 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Remote host closed the connection] 17:05 < bramc> The total number of operations to check keys will still be two million, and if the number of high level pools is set high enough then you should be able to pull the whole pool into memory and not have to deal with all those seeks. It still requires more accessing though, and dramatically increases the setup time of everything (a factor of a thousand in the example I gave) still it might be worthwile for some setups 17:06 -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection] 17:06 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds] 17:06 < bramc> The good news is that this all stops working above a factor of two, or if not there then at some small constant factor. 17:06 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards 17:06 < bramc> phantomcircuit, I'm happy to help you out with the improvements in that paper if you're interested. 17:07 -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection] 17:07 -!- jb55_ [~jb55@208.98.200.98] has joined #bitcoin-wizards 17:07 < phantomcircuit> bramc, interested but otherwise occupied :) 17:10 < bramc> Okay. It's hard to gauge what reaction people are having when I'm monologing 17:12 -!- jb55_ [~jb55@208.98.200.98] has quit [Ping timeout: 256 seconds] 17:12 -!- Adlai [~Adlai@gateway/tor-sasl/adlai] has joined #bitcoin-wizards 17:19 -!- Grishnakh [~grishnakh@dsl-espbrasgw1-50dfb6-218.dhcp.inet.fi] has quit [Read error: Connection reset by peer] 17:22 < amiller> im looking into cryptonote a bit today, i have two observations 17:23 < amiller> first, when selecting 'fake' transactions, it seems to choose uniformly at random throughout history (among txouts with the right denomination) 17:23 < amiller> seems like /join #cryptonote 17:23 < amiller> asdlfkjlsdkfj 17:24 < amiller> seems like that's suboptimal because, there is probably some natural distribution of how long someone waits before moving their coins, and i imagine it's in general pretty short 17:24 < amiller> so i think it would be better to sample from some distribution where more recent coins are more likely to be chosen 17:25 < MRL-Relay> [othe] yeah we are working on that, its indeed "suboptimal" 17:25 < amiller> oh yeah, monero research labs, hi 17:25 < smooth> exactly, we have a paper on that literally in progress 17:25 < smooth> and some other such issues 17:25 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 17:26 < amiller> the second is, you can probably use authenticated data structures to have a light client 17:26 < amiller> regardless of what sampling policy you choose 17:26 -!- ryanxcharles [~ryanxchar@162-245-22-162.v250d.PUBLIC.monkeybrains.net] has quit [Ping timeout: 276 seconds] 17:28 < smooth> btw for bitcoin, the average move time (weighted by quantity, which isn't exactly the same thing) is about 7 days 17:28 < smooth> so yes entire history is way off 17:29 < amiller> this means that in general it's pretty likely that for most transactions, the *most recent* among the mixins is the 'real' one and older ones are fake. 17:29 < smooth> correct 17:29 < amiller> if you have real data, it seems like fitting a distribution to that and sampling from it is optimal 17:29 < smooth> there are some ways of doing that but there is a risk of poisoning 17:29 < amiller> poisoning? 17:30 < smooth> if you are sampling from the blockchain, someone could put in a lot of transations that spend at a certainly rate, encouring you to change your distribution 17:30 < smooth> *certain rate 17:31 < amiller> oh, yeah that counts as 'not real data' in what i meant, i guess i wouldn't recommend actually doing that based on real time data 17:31 < smooth> then its hard to have 'read data' 17:31 < smooth> *real 17:35 -!- jtimon [~quassel@wilkins2.static.monkeybrains.net] has quit [Ping timeout: 276 seconds] 17:35 < amiller> ok well, the basic idea for a light client would be to have an authenticated data structure for the txos 17:35 < amiller> where you can query the number of outputs for a given amount, 17:36 < amiller> then, the client picks random indices of fake outputs (and adds in the index of its own coin, which it should know already), and queries the public key associated with those outputs 17:37 -!- butters [~butters@95.90.241.127] has quit [Ping timeout: 252 seconds] 17:38 < amiller> a pure/functional data structure that does that would be a search tree (or trie, i dont care!!) for amounts, and each of those leaves would be the root of a tree in index order, where each node also stores the number of elements in its child 17:38 -!- Adlai [~Adlai@gateway/tor-sasl/adlai] has quit [Quit: WeeChat 1.0.1] 17:41 < amiller> so the merkleized version of that would let the client check that any results returned match the root hash committed in the block or coinbase signed by a trusted person or whatever 17:53 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has quit [Remote host closed the connection] 18:08 -!- Dizzle [~Dizzle@cpe-72-182-36-12.austin.res.rr.com] has joined #bitcoin-wizards 18:08 -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has quit [Quit: Leaving] 18:22 -!- Dizzle [~Dizzle@cpe-72-182-36-12.austin.res.rr.com] has quit [Remote host closed the connection] 18:28 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 18:29 -!- shea256 [~hightorqu@172.56.18.167] has joined #bitcoin-wizards 18:29 -!- Dizzle [~Dizzle@2605:6000:1018:c04a:e419:2935:d8bd:fa1e] has joined #bitcoin-wizards 18:29 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 18:30 -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards 18:33 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds] 18:38 -!- shea256 [~hightorqu@172.56.18.167] has quit [] 18:38 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:9185:2828:fe2f:1b5b] has joined #bitcoin-wizards 18:38 -!- qwopqwop [~hi@209.141.33.28] has joined #bitcoin-wizards 18:42 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:9185:2828:fe2f:1b5b] has quit [Ping timeout: 245 seconds] 18:42 -!- siraj [~siraj@106.78.107.129] has joined #bitcoin-wizards 18:43 -!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 264 seconds] 18:53 -!- d1ggy_ [~d1ggy@dslc-082-082-153-097.pools.arcor-ip.net] has joined #bitcoin-wizards 18:56 -!- bepo|here [~bepo@fer68-1-78-229-8-151.fbx.proxad.net] has quit [] 18:57 -!- d1ggy [~d1ggy@dslb-092-076-028-003.092.076.pools.vodafone-ip.de] has quit [Ping timeout: 244 seconds] 19:00 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards 19:03 -!- Guest96271 [~Pan0ram1x@095-096-084-122.static.chello.nl] has quit [Ping timeout: 252 seconds] 19:06 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 19:07 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has joined #bitcoin-wizards 19:08 -!- koshii [~0@node-bgh.pool-101-108.dynamic.totbb.net] has quit [Ping timeout: 264 seconds] 19:09 -!- Pan0ram1x [~Pan0ram1x@095-096-084-122.static.chello.nl] has joined #bitcoin-wizards 19:10 -!- Pan0ram1x is now known as Guest18727 19:11 -!- nessence [~alexl@c-68-51-194-2.hsd1.ga.comcast.net] has quit [Ping timeout: 264 seconds] 19:24 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-wrcledlimmzbrnke] has quit [Ping timeout: 272 seconds] 19:26 < bramc> Nobody wants to talk about the squeezing more out of storage tricks? They're so much fun. 19:28 <@gmaxwell> Sorry! busy week for me, I've only had a few moments to glance in. (Actually I came up with some very neat optimizations in this space; which you might have thought of or come up with too.. but no time to talk now) 19:33 < bramc> gmaxwell, Happy to talk when you can. The short of it is that cstos (CPU space tradeoffs) are possible but they get you maybe a factor of 2 of space, and there's a cheesy but serviceable way of doing spows which makes them canonical which blunts most of the attacks based on doing multiple spows. 19:46 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Remote host closed the connection] 19:50 -!- siraj [~siraj@106.78.107.129] has quit [Read error: Connection reset by peer] 19:55 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 252 seconds] 20:02 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] 20:02 -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards 20:04 < maaku> gmaxwell is such a tease 20:10 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:9185:2828:fe2f:1b5b] has quit [Ping timeout: 245 seconds] 20:11 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards 20:12 -!- kgk_ [~kgk@76.14.85.43] has joined #bitcoin-wizards 20:15 -!- jps [~Jud@198.199.83.156] has quit [Ping timeout: 255 seconds] 20:16 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 244 seconds] 20:42 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 20:43 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 20:43 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 20:45 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 20:45 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 20:46 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 20:46 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 20:47 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 20:47 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds] 20:47 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 20:48 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 20:48 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 20:49 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 20:49 -!- coiner [~linker@115.79.55.177] has quit [Max SendQ exceeded] 20:51 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards 21:10 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has joined #bitcoin-wizards 21:16 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has quit [] 21:19 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has joined #bitcoin-wizards 21:30 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has quit [Remote host closed the connection] 21:36 -!- cletus11 [~cletus11@99-172-47-87.lightspeed.tblltx.sbcglobal.net] has joined #bitcoin-wizards 21:57 -!- zwischenzug [~zwischenz@207.Red-88-8-247.dynamicIP.rima-tde.net] has quit [Ping timeout: 244 seconds] 22:09 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 22:13 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Quit: Something is wrong...] 22:15 -!- NewLiberty_ [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards 22:19 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-wizards 22:23 -!- tlrobinson [~tlrobinso@204.14.159.136] has joined #bitcoin-wizards 22:33 -!- iddo [~idddo@unaffiliated/iddo] has quit [Ping timeout: 244 seconds] 22:33 -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards 22:35 -!- iddo [~idddo@csm.cs.technion.ac.il] has joined #bitcoin-wizards 22:40 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 22:48 -!- delll [~chatzilla@yh97.internetdsl.tpnet.pl] has quit [Ping timeout: 245 seconds] 22:53 -!- nullbyte [WW@gateway/vpn/mullvad/x-ywcozkjqcfhycdee] has quit [Ping timeout: 244 seconds] 22:56 -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Ping timeout: 245 seconds] 22:57 -!- e1782d11df4c9914 [~e1782d11d@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards 22:58 -!- iddo [~idddo@csm.cs.technion.ac.il] has joined #bitcoin-wizards 22:58 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 22:59 < fluffypony> amiller: do you mean, then, that the only thing the hypothetical lightweight client needs to retain is a list of output denominations for which there are available utxo's it can mix with? 22:59 < amiller> fluffypony, even that could probably be dispensed with, but yes 23:00 < fluffypony> doesn't that mean it still has to trust nodes it connects to to provide it with valid utxo's? 23:01 < amiller> no, that's the point of utxo commitments 23:01 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 264 seconds] 23:02 < amiller> imagine that each block header contains the merkle root of a tree containing all the txos (in cryptonote there's no way to tell apart a utxo from a spent txo so just txos) 23:03 -!- e1782d11df4c9914 [~e1782d11d@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 245 seconds] 23:03 -!- delll [~chatzilla@yh97.internetdsl.tpnet.pl] has joined #bitcoin-wizards 23:04 -!- e1782d11df4c9914 [~e1782d11d@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards 23:04 < fluffypony> (although tangentially to that we have discussed a scenario where we may want to blacklist certain utxos from being used for mixing in future, for whatever reason) 23:05 < amiller> yeah, merkle data structures are pretty flexible so that's probably doable 23:06 -!- waxwing [waxwing@gateway/vpn/mullvad/x-helrvbpgexyadvuf] has quit [Ping timeout: 276 seconds] 23:19 -!- waxwing [waxwing@gateway/vpn/mullvad/x-kqnhsrpybxdalcwg] has joined #bitcoin-wizards 23:21 -!- e1782d11df4c9914 [~e1782d11d@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 244 seconds] 23:31 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards 23:40 -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has joined #bitcoin-wizards 23:43 -!- DougieBot5000_ is now known as DougieBot5000 23:50 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Quit: bendavenport] 23:57 -!- go1111111 [~go1111111@gateway/vpn/privateinternetaccess/go1111111] has quit [Ping timeout: 244 seconds] 23:59 -!- MoALTz [~no@user-109-243-165-112.play-internet.pl] has quit [Quit: Leaving] --- Log closed Thu Jan 15 00:00:24 2015