--- Log opened Thu Sep 24 00:00:37 2015 00:14 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 00:18 -!- Transisto2 [~Trans@modemcable082.143-161-184.mc.videotron.ca] has quit [Ping timeout: 264 seconds] 00:25 -!- p15 [~p15@120.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards 00:29 -!- chris____ [~chris@208.185.52.110] has quit [Ping timeout: 244 seconds] 00:55 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 00:59 -!- matsjj [~matsjj@89.197.31.78] has joined #bitcoin-wizards 01:10 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Remote host closed the connection] 01:11 -!- Transisto2 [~Trans@modemcable082.143-161-184.mc.videotron.ca] has joined #bitcoin-wizards 01:13 -!- poutine [~freepouti@173.255.218.246] has quit [K-Lined] 01:14 -!- freepoutine [freepoutin@2600:3c01::f03c:91ff:fe93:f9f1] has joined #bitcoin-wizards 01:14 -!- csggggg8 [~xypher@static-108-45-93-90.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds] 01:14 -!- freepoutine [freepoutin@2600:3c01::f03c:91ff:fe93:f9f1] has quit [K-Lined] 01:26 -!- Crowley2k [~Crowley2k@93.113.62.93] has joined #bitcoin-wizards 01:30 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 01:42 -!- catlasshrugged_ [~catlasshr@ec2-54-149-141-214.us-west-2.compute.amazonaws.com] has joined #bitcoin-wizards 01:45 -!- catlasshrugged [~catlasshr@ec2-54-149-141-214.us-west-2.compute.amazonaws.com] has quit [Ping timeout: 256 seconds] 01:56 -!- JackH [~Jack@host86-152-149-54.range86-152.btcentralplus.com] has joined #bitcoin-wizards 01:57 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-wizards 01:59 -!- jtimon [~quassel@160.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 02:00 -!- ishahnaz [~null@unaffiliated/ishahnaz] has joined #bitcoin-wizards 02:01 -!- roconnor_ [~roconnor@host-45-58-252-176.dyn.295.ca] has joined #bitcoin-wizards 02:01 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 244 seconds] 02:02 -!- sausage_factory [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 02:04 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] 02:04 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 256 seconds] 02:04 -!- roconnor [~roconnor@host-45-58-252-192.dyn.295.ca] has quit [Ping timeout: 264 seconds] 02:11 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards 02:14 -!- chris____ [~chris@208.185.52.110] has joined #bitcoin-wizards 02:14 < btcdrak> is there a backup of the old -wizard logs? The link on bitcoin.ninja is a 404 (pointing to https://www.wpsoftware.net/bitcoin/wizards/) 02:19 -!- chris____ [~chris@208.185.52.110] has quit [Ping timeout: 255 seconds] 02:20 < fluffypony> what about botbot.me's archive? 02:22 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 02:28 < btcdrak> fluffypony: doesnt go back very far 02:36 -!- Crowley2k [~Crowley2k@93.113.62.93] has quit [Quit: Leaving] 02:39 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 246 seconds] 02:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds] 02:43 < rabidus> btcdrak: how far would you like to go? 02:43 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 240 seconds] 02:44 < btcdrak> rabidus: to the beginning 02:45 < rabidus> k 02:48 -!- agorecki [~agorecki@unaffiliated/agorecki] has joined #bitcoin-wizards 02:53 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards 03:19 -!- ishahnaz [~null@unaffiliated/ishahnaz] has quit [] 03:20 < kanzure> btcdrak: there's a backup here http://diyhpl.us/~bryan/papers2/bitcoin/wizards/ and http://gnusha.org/bitcoin-wizards/ 03:21 < btcdrak> kanzure to the rescue again... +1 03:41 -!- antiatom [~antiatom@91.214.169.69] has quit [Remote host closed the connection] 03:48 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 264 seconds] 03:49 -!- sausage_factory [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 03:49 -!- antiatom [~antiatom@91.214.169.69] has joined #bitcoin-wizards 03:51 -!- sausage_factory [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 03:56 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 04:00 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards 04:00 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards 04:03 -!- chris____ [~chris@208.185.52.110] has joined #bitcoin-wizards 04:04 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards 04:04 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 04:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards 04:07 -!- chris____ [~chris@208.185.52.110] has quit [Ping timeout: 255 seconds] 04:19 -!- ishahnaz [~null@unaffiliated/ishahnaz] has joined #bitcoin-wizards 04:33 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has quit [Ping timeout: 250 seconds] 04:46 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-wizards 04:50 -!- ishahnaz [~null@unaffiliated/ishahnaz] has quit [] 04:57 -!- Naphex [~naphex@unaffiliated/naphex] has quit [Quit: bbl] 05:07 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards 05:22 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards 05:29 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards 05:30 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-krzpvquzczowcpiu] has joined #bitcoin-wizards 05:34 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 246 seconds] 05:39 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has quit [Quit: tbmit] 05:42 -!- eudoxia [~eudoxia@r167-56-2-174.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 05:47 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards 05:53 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards 05:59 -!- antgreen [~user@38.104.156.251] has joined #bitcoin-wizards 06:06 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 06:07 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards 06:08 -!- King_Rex [~King_Rex@220.sub-70-193-104.myvzw.com] has joined #bitcoin-wizards 06:20 -!- AnoAnon [~AnoAnon@197.39.224.120] has joined #bitcoin-wizards 06:20 -!- AnoAnon [~AnoAnon@197.39.224.120] has quit [Max SendQ exceeded] 06:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 06:31 -!- gill3s [~gill3s@unaffiliated/gill3s] has joined #bitcoin-wizards 06:42 -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has joined #bitcoin-wizards 06:47 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 06:47 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 06:49 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 06:50 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 06:53 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Ping timeout: 246 seconds] 06:57 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards 06:57 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit] 06:58 -!- King_Rex [~King_Rex@220.sub-70-193-104.myvzw.com] has quit [Ping timeout: 250 seconds] 06:59 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has quit [Quit: tbmit] 07:01 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 07:02 -!- King_Rex [~King_Rex@gateway/vpn/privateinternetaccess/kingrex/x-95663076] has joined #bitcoin-wizards 07:06 -!- King_Rex [~King_Rex@gateway/vpn/privateinternetaccess/kingrex/x-95663076] has quit [Changing host] 07:06 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards 07:06 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Changing host] 07:06 -!- King_Rex [~King_Rex@gateway/vpn/privateinternetaccess/kingrex/x-95663076] has joined #bitcoin-wizards 07:06 < andytoshi> btcdrak: oops, that should be download.wpsoftware.net not www.wpsoftware.net 07:07 < andytoshi> ah, i see, my server is redirecting 07:09 -!- neha_ [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 07:09 < andytoshi> btcdrak: sorry, i had a permanent redirect to force SSL but it went to the wrong place. you'll have to clear your browser cache but the link should work now 07:09 < btcdrak> andytoshi: great! Thanks! 07:10 -!- neha_ [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Client Quit] 07:10 -!- neha_ [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 07:16 -!- K1NGREX [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards 07:18 -!- King_Rex [~King_Rex@gateway/vpn/privateinternetaccess/kingrex/x-95663076] has quit [Ping timeout: 246 seconds] 07:21 -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has quit [Quit: hdbuck] 07:22 -!- hdbuck [~hdbuck@ATuileries-153-1-41-15.w83-202.abo.wanadoo.fr] has joined #bitcoin-wizards 07:22 -!- hdbuck [~hdbuck@ATuileries-153-1-41-15.w83-202.abo.wanadoo.fr] has quit [Changing host] 07:22 -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has joined #bitcoin-wizards 07:25 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 07:29 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 07:31 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 07:38 -!- eudoxia [~eudoxia@r167-56-2-174.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 07:40 -!- chris____ [~chris@208.185.52.110] has joined #bitcoin-wizards 07:44 -!- chris____ [~chris@208.185.52.110] has quit [Ping timeout: 252 seconds] 07:49 -!- shen_noe [~shen_noe@104.156.228.131] has quit [Ping timeout: 265 seconds] 08:00 -!- matsjj_ [~matsjj@79.173.166.74] has joined #bitcoin-wizards 08:03 -!- matsjj [~matsjj@89.197.31.78] has quit [Ping timeout: 256 seconds] 08:05 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 250 seconds] 08:06 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 08:06 -!- roconnor_ [~roconnor@host-45-58-252-176.dyn.295.ca] has quit [Quit: Konversation terminated!] 08:07 -!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards 08:13 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 08:14 -!- matsjj [~matsjj@89.197.31.78] has joined #bitcoin-wizards 08:16 -!- matsjj_ [~matsjj@79.173.166.74] has quit [Ping timeout: 240 seconds] 08:17 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards 08:18 -!- bsm1175321 [~bsm117532@38.121.165.30] has joined #bitcoin-wizards 08:19 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: Leaving.] 08:29 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 08:29 -!- livegnik [~livegnik@bnw.7c0.nl] has quit [Read error: Connection reset by peer] 08:30 -!- livegnik [~livegnik@bnw.7c0.nl] has joined #bitcoin-wizards 08:30 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 08:31 -!- qawap [~quassel@unaffiliated/qawap] has quit [Read error: Connection reset by peer] 08:32 -!- qawap [~quassel@80.240.137.113] has joined #bitcoin-wizards 08:32 -!- qawap [~quassel@80.240.137.113] has quit [Changing host] 08:32 -!- qawap [~quassel@unaffiliated/qawap] has joined #bitcoin-wizards 08:33 -!- MrHodl [~fuc@185.22.183.202] has joined #bitcoin-wizards 08:39 -!- tbmit [~Bair@dhcp-18-111-3-22.dyn.mit.edu] has joined #bitcoin-wizards 08:42 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards 08:43 -!- maraoz [~maraoz@2602:304:cdc1:910:204e:29f3:aad3:5b26] has joined #bitcoin-wizards 08:43 -!- earthrise [~earthrise@S01065404a6902716.cg.shawcable.net] has joined #bitcoin-wizards 08:49 -!- hashtag_ [~hashtagg_@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards 08:50 -!- hashtag [~hashtagg_@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 255 seconds] 08:52 -!- Dr-G2 [~Dr-G@xd9bf7262.dyn.telefonica.de] has quit [Ping timeout: 240 seconds] 08:54 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-wizards 08:58 -!- joesmoe [~joesmoe@76.73.18.156] has quit [Ping timeout: 246 seconds] 08:59 -!- neha_ [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] 09:00 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 244 seconds] 09:01 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 09:02 -!- hashtag_ [~hashtagg_@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 240 seconds] 09:04 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 246 seconds] 09:04 -!- Dr-G [~Dr-G@x4d08a20a.dyn.telefonica.de] has joined #bitcoin-wizards 09:04 -!- Dr-G [~Dr-G@x4d08a20a.dyn.telefonica.de] has quit [Changing host] 09:04 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 09:05 -!- joesmoe [~joesmoe@76.73.18.156] has joined #bitcoin-wizards 09:07 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-wizards 09:14 -!- hashtag [~hashtagg_@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards 09:16 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards 09:16 -!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-wizards 09:20 -!- cypher__ [~cypher@97.95.172.50] has joined #bitcoin-wizards 09:20 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Disconnected by services] 09:20 -!- Dr-G2 [~Dr-G@x4d08a20a.dyn.telefonica.de] has joined #bitcoin-wizards 09:20 -!- Londe2 [~Londe@cpe-104-32-148-17.socal.res.rr.com] has joined #bitcoin-wizards 09:21 -!- rustyn_ [~rustyn@unaffiliated/rustyn] has joined #bitcoin-wizards 09:22 -!- hdbuck_ [~hdbuck@ATuileries-153-1-41-15.w83-202.abo.wanadoo.fr] has joined #bitcoin-wizards 09:22 -!- leakypat_ [~sid9@tor-exit.echelon.nsa.network] has joined #bitcoin-wizards 09:23 -!- jouke_ [~jouke@a83-163-42-163.adsl.xs4all.nl] has joined #bitcoin-wizards 09:23 -!- hashtag [~hashtagg_@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 265 seconds] 09:23 -!- snthsnth [~snthsnth@206.110.20.18] has joined #bitcoin-wizards 09:23 -!- qawap_ [~quassel@80.240.137.113] has joined #bitcoin-wizards 09:23 -!- qawap_ [~quassel@80.240.137.113] has quit [Changing host] 09:23 -!- qawap_ [~quassel@unaffiliated/qawap] has joined #bitcoin-wizards 09:24 -!- sneak [~sneak@unaffiliated/sneak] has quit [Ping timeout: 240 seconds] 09:24 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has quit [Ping timeout: 244 seconds] 09:24 -!- wiz [~sid1@tor-exit.echelon.nsa.network] has quit [Ping timeout: 244 seconds] 09:24 -!- jouke [~jouke@unaffiliated/komkommer] has quit [Ping timeout: 244 seconds] 09:24 -!- qawap [~quassel@unaffiliated/qawap] has quit [Ping timeout: 244 seconds] 09:24 -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has quit [Ping timeout: 244 seconds] 09:24 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Ping timeout: 244 seconds] 09:24 -!- agorist000 [~cypher@unaffiliated/agorist000] has quit [Ping timeout: 244 seconds] 09:24 -!- rustyn [~rustyn@unaffiliated/rustyn] has quit [Ping timeout: 244 seconds] 09:24 -!- leakypat [~sid9@tor-exit.echelon.nsa.network] has quit [Ping timeout: 244 seconds] 09:24 -!- bsm117532 [~bsm117532@static-108-21-236-13.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds] 09:24 -!- Londe [~Londe@cpe-104-32-148-17.socal.res.rr.com] has quit [Ping timeout: 244 seconds] 09:24 -!- STRML [~STRML@unaffiliated/strml] has quit [Ping timeout: 244 seconds] 09:24 -!- wiz_ [~sid1@tor-exit.echelon.nsa.network] has joined #bitcoin-wizards 09:24 -!- wiz_ is now known as wiz 09:24 -!- leakypat_ is now known as leakypat 09:24 -!- hdbuck_ is now known as hdbuck 09:24 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #bitcoin-wizards 09:24 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards 09:25 -!- hashtag [~hashtagg_@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards 09:25 -!- sneak [~sneak@unaffiliated/sneak] has joined #bitcoin-wizards 09:25 -!- STRML [~STRML@unaffiliated/strml] has joined #bitcoin-wizards 09:25 -!- bsm117532 [~bsm117532@static-108-21-236-13.nycmny.fios.verizon.net] has joined #bitcoin-wizards 09:28 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards 09:29 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 09:30 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 09:33 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Remote host closed the connection] 09:33 < nsh> nobody has applied to ICANN for the .btc derpTLD yet, then? 09:34 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 250 seconds] 09:35 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] 09:37 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards 09:39 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 265 seconds] 09:40 < fluffypony> nsh: doesn't it cost like $500k ? 09:41 -!- hashtag_ [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has joined #bitcoin-wizards 09:42 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 09:42 < MRL-Relay> [othe] no only 185k from what i know 09:43 -!- JackH [~Jack@host86-152-149-54.range86-152.btcentralplus.com] has quit [Ping timeout: 255 seconds] 09:44 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-wizards 09:44 -!- hashtag [~hashtagg_@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 244 seconds] 09:44 -!- jtimon [~quassel@160.28.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards 09:44 -!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 09:49 < wumpus> I don't think that's a particular -wizards topic :) 09:51 * nsh nodsmiles 09:52 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 265 seconds] 09:55 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Read error: Connection reset by peer] 09:55 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards 09:56 -!- tbmit [~Bair@dhcp-18-111-3-22.dyn.mit.edu] has quit [Quit: tbmit] 09:56 -!- maaku is now known as Guest34729 09:57 -!- gielbier [~giel@unaffiliated/gielbier] has quit [Read error: Connection reset by peer] 09:57 -!- Guest34729 is now known as maaku 09:58 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-wizards 10:00 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 10:02 -!- sausage_factory [~priidu@unaffiliated/priidu] has quit [Ping timeout: 265 seconds] 10:03 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] 10:04 < ghtdak> hmmmm 10:04 -!- snthsnth [~snthsnth@206.110.20.18] has quit [Ping timeout: 272 seconds] 10:05 -!- c0rw1n is now known as c0rw|away 10:06 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards 10:06 -!- maaku is now known as Guest14942 10:06 -!- Guest14942 is now known as maaku 10:09 < nsh> yasss, it works now 10:09 -!- trippysalmon [rob@2001:984:6466:0:f4b2:3e72:a91b:4c08] has joined #bitcoin-wizards 10:09 < nsh> (wrongchannel, sorry) 10:09 -!- urika [~sunflower@50.248.81.66] has quit [Quit: Leaving] 10:13 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 10:14 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: Leaving.] 10:14 -!- gielbier [~giel@a149043.upc-a.chello.nl] has joined #bitcoin-wizards 10:14 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 10:16 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards 10:17 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 10:17 -!- gielbier [~giel@a149043.upc-a.chello.nl] has quit [Changing host] 10:17 -!- gielbier [~giel@unaffiliated/gielbier] has joined #bitcoin-wizards 10:19 -!- tbmit [~Bair@dhcp-18-111-42-64.dyn.mit.edu] has joined #bitcoin-wizards 10:21 -!- eudoxia [~eudoxia@r167-57-40-28.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 10:21 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 10:22 -!- gill3s [~gill3s@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 10:23 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 265 seconds] 10:24 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: Leaving.] 10:28 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 10:29 -!- chris____ [~chris@208.185.52.110] has joined #bitcoin-wizards 10:32 -!- jorn [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards 10:33 -!- jorn is now known as Guest57151 10:34 -!- chris____ [~chris@208.185.52.110] has quit [Ping timeout: 250 seconds] 10:35 -!- trippysalmon [rob@2001:984:6466:0:f4b2:3e72:a91b:4c08] has quit [Ping timeout: 250 seconds] 10:36 -!- trippysalmon [rob@2001:984:6466:0:9c8f:dfb2:8b0a:dd51] has joined #bitcoin-wizards 10:41 -!- hashtag_ [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has quit [Ping timeout: 255 seconds] 10:49 -!- dEBRUYNE_ [~dEBRUYNE@vp0455.uvt.nl] has joined #bitcoin-wizards 10:51 -!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-wizards 10:53 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 265 seconds] 10:55 -!- kmels [~kmels@186.64.110.122] has quit [Ping timeout: 252 seconds] 11:00 -!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 11:01 -!- hashtag [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has joined #bitcoin-wizards 11:03 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Quit: Leaving...] 11:07 -!- qawap_ is now known as qawap 11:07 -!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards 11:11 -!- sausage_factory [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 11:12 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection] 11:19 -!- hazirafel [~ufoinc@31.154.91.142] has joined #bitcoin-wizards 11:20 -!- tbmit [~Bair@dhcp-18-111-42-64.dyn.mit.edu] has quit [Quit: tbmit] 11:26 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has quit [Remote host closed the connection] 11:31 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] 11:39 -!- chris____ [~chris@208.185.52.110] has joined #bitcoin-wizards 11:43 -!- roybadami [~roy@darla.gnomon.org.uk] has quit [Read error: Connection reset by peer] 11:44 -!- neha [~textual@pool-71-184-176-22.bstnma.east.verizon.net] has joined #bitcoin-wizards 11:45 -!- kmels [~kmels@186.64.110.122] has quit [Ping timeout: 260 seconds] 11:45 -!- hashtag [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has quit [Ping timeout: 244 seconds] 11:45 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-mwuericarmnaqtdi] has joined #bitcoin-wizards 11:49 -!- zooko [~user@71-215-119-184.hlrn.qwest.net] has joined #bitcoin-wizards 11:52 -!- neha [~textual@pool-71-184-176-22.bstnma.east.verizon.net] has quit [Ping timeout: 264 seconds] 11:53 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 11:53 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards 11:58 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards 11:59 -!- maider [~maider@172.56.31.175] has joined #bitcoin-wizards 12:00 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 12:00 -!- ruby32 [~ruby32@75.133.112.155] has joined #bitcoin-wizards 12:01 -!- sausage_factory [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds] 12:04 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] 12:04 -!- Guest57151 [~jorn@g227014.upc-g.chello.nl] has quit [Quit: Konversation terminated!] 12:04 -!- jorn [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards 12:05 -!- hashtag [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has joined #bitcoin-wizards 12:05 -!- jorn is now known as Guest24663 12:05 -!- Guest24663 [~jorn@g227014.upc-g.chello.nl] has quit [Client Quit] 12:05 -!- Guest24663 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards 12:06 -!- gill3s [~gill3s@unaffiliated/gill3s] has joined #bitcoin-wizards 12:08 -!- hashtag_ [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has joined #bitcoin-wizards 12:13 -!- JackH [~Jack@93.158.36.30] has joined #bitcoin-wizards 12:20 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 12:21 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 12:26 -!- shen_noe [~shen_noe@104.156.228.145] has joined #bitcoin-wizards 12:27 -!- roxtrong_ [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 12:30 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has quit [Ping timeout: 246 seconds] 12:33 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 12:38 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Ping timeout: 252 seconds] 12:38 -!- maider is now known as dstadulis 12:39 -!- hashtag_ [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has quit [Quit: Leaving] 12:39 -!- hashtag_ [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has joined #bitcoin-wizards 12:39 -!- matsjj [~matsjj@89.197.31.78] has quit [Remote host closed the connection] 12:51 -!- gill3s [~gill3s@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 12:52 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 12:54 -!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards 12:58 -!- ratbanebo [~ratbanebo@78-23-10-185.access.telenet.be] has joined #bitcoin-wizards 13:01 -!- antgreen [~user@38.104.156.251] has quit [Ping timeout: 240 seconds] 13:02 -!- zooko [~user@71-215-119-184.hlrn.qwest.net] has quit [Ping timeout: 240 seconds] 13:06 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Remote host closed the connection] 13:10 -!- trippysalmon [rob@2001:984:6466:0:9c8f:dfb2:8b0a:dd51] has quit [Ping timeout: 250 seconds] 13:13 -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 13:13 -!- dEBRUYNE_ [~dEBRUYNE@vp0455.uvt.nl] has quit [Read error: Connection reset by peer] 13:14 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards 13:14 -!- roxtrong_ [~roxtrongo@190-22-190-148.baf.movistar.cl] has quit [Remote host closed the connection] 13:19 -!- trippysalmon [rob@2001:984:6466:0:fdf9:2c10:cc98:db66] has joined #bitcoin-wizards 13:22 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards 13:22 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 13:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 13:24 -!- snthsnth [~snthsnth@206.110.20.18] has joined #bitcoin-wizards 13:25 -!- trippysalmon [rob@2001:984:6466:0:fdf9:2c10:cc98:db66] has quit [Ping timeout: 250 seconds] 13:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds] 13:30 -!- chris____ [~chris@208.185.52.110] has quit [Remote host closed the connection] 13:32 -!- dstadulis [~maider@172.56.31.175] has quit [Ping timeout: 240 seconds] 13:33 -!- chris____ [~chris@208.185.52.110] has joined #bitcoin-wizards 13:36 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer] 13:36 -!- trippysalmon [rob@2001:984:6466:0:7838:badd:53f3:71ac] has joined #bitcoin-wizards 13:38 -!- chris____ [~chris@208.185.52.110] has quit [Ping timeout: 260 seconds] 13:38 -!- Transisto2 [~Trans@modemcable082.143-161-184.mc.videotron.ca] has quit [Ping timeout: 255 seconds] 13:38 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 13:42 -!- trippysalmon [rob@2001:984:6466:0:7838:badd:53f3:71ac] has quit [Ping timeout: 250 seconds] 13:42 -!- moa [~kiwigb@opentransactions/dev/moa] has left #bitcoin-wizards [] 13:47 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 13:53 -!- trippysalmon [rob@2001:984:6466:0:9d80:de57:42da:d695] has joined #bitcoin-wizards 13:54 -!- RH311ish [~RH311ish@c-68-81-81-66.hsd1.pa.comcast.net] has joined #bitcoin-wizards 13:57 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 13:58 -!- trippysalmon [rob@2001:984:6466:0:9d80:de57:42da:d695] has quit [Ping timeout: 250 seconds] 13:59 -!- hashtag [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has quit [Read error: Connection reset by peer] 13:59 -!- hashtag_ [cjmedia@cpe-98-157-196-22.ma.res.rr.com] has quit [Read error: Connection reset by peer] 13:59 -!- snthsnth [~snthsnth@206.110.20.18] has quit [Ping timeout: 264 seconds] 14:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 14:05 -!- rabidus [~lauri.j@uhiainen.com] has quit [Ping timeout: 240 seconds] 14:07 -!- rabidus [~lauri.j@uhiainen.com] has joined #bitcoin-wizards 14:09 -!- trippysalmon [rob@2001:984:6466:0:81bb:1337:a790:15c7] has joined #bitcoin-wizards 14:09 -!- snthsnth [~snthsnth@206.110.20.18] has joined #bitcoin-wizards 14:10 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] 14:13 -!- rabidus [~lauri.j@uhiainen.com] has quit [Ping timeout: 246 seconds] 14:14 -!- rabidus [~lauri.j@uhiainen.com] has joined #bitcoin-wizards 14:15 -!- trippysalmon [rob@2001:984:6466:0:81bb:1337:a790:15c7] has quit [Ping timeout: 250 seconds] 14:16 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 14:16 -!- hod0r [~h0d0r@50.248.81.66] has joined #bitcoin-wizards 14:17 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-mwuericarmnaqtdi] has quit [Quit: Connection closed for inactivity] 14:18 -!- shen_noe [~shen_noe@104.156.228.145] has quit [Quit: Leaving] 14:18 -!- eudoxia [~eudoxia@r167-57-40-28.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 14:26 -!- trippysalmon [rob@2001:984:6466:0:f106:beb8:476b:f08d] has joined #bitcoin-wizards 14:30 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 14:30 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 14:32 -!- trippysalmon [rob@2001:984:6466:0:f106:beb8:476b:f08d] has quit [Ping timeout: 250 seconds] 14:33 -!- snthsnth [~snthsnth@206.110.20.18] has quit [Ping timeout: 240 seconds] 14:34 -!- chris____ [~chris@208.185.52.110] has joined #bitcoin-wizards 14:36 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 14:36 -!- akkked [~RH311ish@c-68-81-81-66.hsd1.pa.comcast.net] has joined #bitcoin-wizards 14:37 -!- rabidus [~lauri.j@uhiainen.com] has quit [Ping timeout: 240 seconds] 14:40 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has quit [Ping timeout: 244 seconds] 14:40 -!- RH311ish [~RH311ish@c-68-81-81-66.hsd1.pa.comcast.net] has quit [Ping timeout: 244 seconds] 14:40 -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 244 seconds] 14:41 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 14:41 -!- mr_burdell_ [~mr_burdel@hop.cryptolabs.net] has joined #bitcoin-wizards 14:41 -!- mr_burdell_ is now known as mr_burdell 14:42 -!- mr_burdell is now known as Guest85880 14:42 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 264 seconds] 14:42 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 14:43 -!- trippysalmon [rob@2001:984:6466:0:646a:f9a2:9321:8ac6] has joined #bitcoin-wizards 14:45 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] 14:47 -!- Guest85880 [~mr_burdel@hop.cryptolabs.net] has quit [Quit: :)] 14:47 -!- mr_burdell_ [~mr_burdel@hop.cryptolabs.net] has joined #bitcoin-wizards 14:49 -!- trippysalmon [rob@2001:984:6466:0:646a:f9a2:9321:8ac6] has quit [Ping timeout: 250 seconds] 14:50 -!- mr_burdell_ [~mr_burdel@hop.cryptolabs.net] has quit [Client Quit] 14:50 -!- mr_burdell_ [~mr_burdel@hop.cryptolabs.net] has joined #bitcoin-wizards 14:50 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards 14:53 -!- chris____ [~chris@208.185.52.110] has quit [Read error: Connection reset by peer] 14:58 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 14:59 -!- trippysalmon [rob@2001:984:6466:0:2dc6:41a:e621:2fca] has joined #bitcoin-wizards 15:00 -!- akkked [~RH311ish@c-68-81-81-66.hsd1.pa.comcast.net] has quit [Ping timeout: 240 seconds] 15:01 -!- ratbanebo [~ratbanebo@78-23-10-185.access.telenet.be] has quit [] 15:03 -!- hashtag [~hashtagg_@cpe-98-157-211-2.ma.res.rr.com] has joined #bitcoin-wizards 15:05 -!- bsm1175321 [~bsm117532@38.121.165.30] has quit [Ping timeout: 255 seconds] 15:05 -!- trippysalmon [rob@2001:984:6466:0:2dc6:41a:e621:2fca] has quit [Ping timeout: 250 seconds] 15:12 -!- matsjj [~matsjj@cpc73684-dals20-2-0-cust891.20-2.cable.virginm.net] has joined #bitcoin-wizards 15:16 -!- trippysalmon [rob@2001:984:6466:0:9c06:7433:c625:6da7] has joined #bitcoin-wizards 15:21 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards 15:22 -!- trippysalmon [rob@2001:984:6466:0:9c06:7433:c625:6da7] has quit [Ping timeout: 250 seconds] 15:27 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds] 15:28 -!- MrHodl [~fuc@185.22.183.202] has quit [] 15:29 -!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-wizards 15:33 -!- trippysalmon [rob@2001:984:6466:0:49f9:1b34:dece:9259] has joined #bitcoin-wizards 15:33 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 15:35 -!- mr_burdell_ is now known as mr_burdell 15:35 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 15:36 -!- mr_burdell is now known as Guest3928 15:39 -!- trippysalmon [rob@2001:984:6466:0:49f9:1b34:dece:9259] has quit [Ping timeout: 250 seconds] 15:42 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds] 15:44 -!- hdbuck [~hdbuck@ATuileries-153-1-41-15.w83-202.abo.wanadoo.fr] has quit [Quit: hdbuck] 15:45 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: Leaving.] 15:45 -!- orik [~orik@50.125.71.245] has quit [Ping timeout: 265 seconds] 15:50 -!- trippysalmon [rob@2001:984:6466:0:a97a:6d0b:e2ec:af67] has joined #bitcoin-wizards 15:51 -!- Dr-G2 [~Dr-G@x4d08a20a.dyn.telefonica.de] has quit [Read error: Connection reset by peer] 15:53 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] 15:55 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-krzpvquzczowcpiu] has quit [Quit: Connection closed for inactivity] 15:56 -!- trippysalmon [rob@2001:984:6466:0:a97a:6d0b:e2ec:af67] has quit [Ping timeout: 250 seconds] 15:58 -!- Dr-G [~Dr-G@x4d08a20a.dyn.telefonica.de] has joined #bitcoin-wizards 15:58 -!- Dr-G [~Dr-G@x4d08a20a.dyn.telefonica.de] has quit [Changing host] 15:58 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 16:03 -!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 16:03 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 16:06 -!- roxtrong_ [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 16:06 -!- trippysalmon [rob@2001:984:6466:0:60ad:b7ed:669d:b60f] has joined #bitcoin-wizards 16:09 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has quit [Ping timeout: 246 seconds] 16:09 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 16:12 -!- trippysalmon [rob@2001:984:6466:0:60ad:b7ed:669d:b60f] has quit [Ping timeout: 250 seconds] 16:15 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 16:20 -!- c0rw|away [~c0rw1n@91.176.79.56] has quit [Read error: Connection reset by peer] 16:20 -!- c0rw|awa_ [~c0rw1n@91.176.79.56] has joined #bitcoin-wizards 16:23 -!- matsjj [~matsjj@cpc73684-dals20-2-0-cust891.20-2.cable.virginm.net] has quit [Remote host closed the connection] 16:23 -!- roxtrong_ [~roxtrongo@190-22-190-148.baf.movistar.cl] has quit [Remote host closed the connection] 16:23 -!- trippysalmon [rob@2001:984:6466:0:ed6f:4f40:b301:4f82] has joined #bitcoin-wizards 16:25 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 16:28 -!- kmels [~kmels@186.64.110.122] has quit [Ping timeout: 265 seconds] 16:29 -!- trippysalmon [rob@2001:984:6466:0:ed6f:4f40:b301:4f82] has quit [Ping timeout: 250 seconds] 16:30 -!- Guest24663 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 16:31 -!- orik [~orik@50.125.71.245] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 16:33 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 16:40 -!- trippysalmon [rob@2001:984:6466:0:2401:7271:296a:20da] has joined #bitcoin-wizards 16:42 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 16:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nkyfdvjduxlhbxvd] has quit [Quit: Connection closed for inactivity] 16:46 -!- trippysalmon [rob@2001:984:6466:0:2401:7271:296a:20da] has quit [Ping timeout: 250 seconds] 16:49 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 16:52 -!- joesmoe [~joesmoe@76.73.18.156] has quit [Ping timeout: 255 seconds] 16:53 -!- joesmoe [~joesmoe@76.73.18.156] has joined #bitcoin-wizards 16:54 -!- PRab_ [~chatzilla@2601:40a:8000:8f9b::3416:dab0] has joined #bitcoin-wizards 16:55 -!- PRab [~chatzilla@2601:40a:8000:8f9b::3416:dab0] has quit [Ping timeout: 240 seconds] 16:55 -!- PRab_ is now known as PRab 16:55 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 240 seconds] 16:55 -!- prosodyC [sid32673@gateway/web/irccloud.com/x-plhwlaukmucmnpfd] has quit [Ping timeout: 240 seconds] 16:56 -!- x3066b896 [~xd91a4a34@2601:147:4103:66f3:c40d:64e2:92e6:1cba] has joined #bitcoin-wizards 16:56 -!- maraoz [~maraoz@2602:304:cdc1:910:204e:29f3:aad3:5b26] has quit [Ping timeout: 240 seconds] 16:56 -!- trippysalmon [rob@2001:984:6466:0:952a:b7d3:2cac:1558] has joined #bitcoin-wizards 16:58 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-wizards 17:00 -!- maraoz [~maraoz@2602:304:cdc1:910:204e:29f3:aad3:5b26] has joined #bitcoin-wizards 17:02 -!- trippysalmon [rob@2001:984:6466:0:952a:b7d3:2cac:1558] has quit [Ping timeout: 250 seconds] 17:03 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-ewklkeczwwjokgut] has joined #bitcoin-wizards 17:05 -!- c0rw|awa_ is now known as c0rw1n 17:05 -!- prosodyC [sid32673@gateway/web/irccloud.com/x-tlfkhfbkgcukgupj] has joined #bitcoin-wizards 17:07 -!- joesmoe [~joesmoe@76.73.18.156] has quit [Ping timeout: 244 seconds] 17:10 -!- c0rw1n is now known as c0rw|zZz 17:11 -!- joesmoe [~joesmoe@76.73.18.156] has joined #bitcoin-wizards 17:13 -!- trippysalmon [rob@2001:984:6466:0:f5a6:3d10:2f0:6b29] has joined #bitcoin-wizards 17:19 -!- trippysalmon [rob@2001:984:6466:0:f5a6:3d10:2f0:6b29] has quit [Ping timeout: 250 seconds] 17:20 -!- orik [~orik@50.125.71.245] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 17:22 -!- x3066b896 [~xd91a4a34@2601:147:4103:66f3:c40d:64e2:92e6:1cba] has quit [Ping timeout: 240 seconds] 17:23 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards 17:23 < bramc> Hey everybody 17:23 < bramc> maaku, are you online? 17:23 < maaku> yes? 17:25 < bramc> Hey maaku, I've spent some more time thinking about patricia trees, and have some implementation questions/suggestions 17:26 < phantomcircuit> bramc, please brain dump :P 17:27 < bramc> The first is, how about leaving some extra space allocated in the leaves of the tree? That way when new stuff is added you don't have to do much reallocation, and you can in principle make the whole thing one flat sorted chunk of memory, which should be quite efficient compared to doing lots of memory allocation 17:28 < maaku> bramc: sure but there's no need to hash that data, or transmit empty bytes over the network, so it's an implementation issue 17:28 < maaku> (although I wonder why a leaf would grow, most applications e.g. UTXO shrink over time) 17:28 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds] 17:29 < bramc> The second one is more vague. Your implementation seems to be base-256. Why not do binary, and cluster depth 8, thus making it an implementation issue rather than changing the format? There's also some interactions between that and the implementation suggestion I just made which I need to spend more time thinking about. 17:29 < bramc> the utxo set grows and shrinks over time, if it remains about stable you never need to sweep through doing a realloc, so all the better. 17:30 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 17:30 -!- trippysalmon [rob@2001:984:6466:0:ac56:a82e:456d:175c] has joined #bitcoin-wizards 17:30 < bramc> clumping together layers of the tree seems like a good idea because it reduces memory lookups, which are likely to dominate performance 17:31 < bramc> That gets into the question of what the size of near cache is on modern CPUs, which I don't actually know. It may be that base 256 is smaller than ideal. 17:32 < bramc> All of these things are implementation questions. For the moment I'm assuming that the canonical data structure is a patricia root of the utxo set at the last block plus a patricia root of the delta made by just the current block. 17:32 -!- antgreen [~user@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards 17:33 < bramc> The further batching of updates I brought up the other day I'm feeling lukewarm on, mostly because it's possible that most of the benefits to be had from it can be achieved via implementation tricks. 17:36 -!- trippysalmon [rob@2001:984:6466:0:ac56:a82e:456d:175c] has quit [Ping timeout: 250 seconds] 17:36 < bramc> maaku, hopefully that isn't too much dump at once. I can discuss things one at a time 17:37 < maaku> bramc: my implementation is binary 17:37 < maaku> there are other base-256 implementations out there, are you looking at the righ tone? 17:38 < bramc> maaku, I probably just misunderstood something you said about radix 256. Are you clumping things together to lower the number of memory lookups to walk the tree? 17:38 < maaku> bramc: no, leveldb is handling that (although the current implementation is memory only) 17:38 < maaku> but the insertion keys are ordered on disk (property of leveldb) 17:39 < bramc> maaku, Oh it's my strong suspicion that a custom data structure could thrash leveldb's performance 17:39 < bramc> Is leveldb's setup documented somewhere? I wouldn't want to reinvent its internal data structures if it's already doing it 'right' 17:40 < maaku> In what way? The suggested implementation right now (again, the only existing one is memory-only) would be to have a separate leveldb entry for each node (leaf or inner), and the 'key' is the path to the node 17:41 < maaku> so each node update is is one key/value update, plus O(log N) key/value updates as you propogate upwards 17:41 < maaku> key/value update == database operation 17:41 < bramc> I'm assuming that leveldb doesn't have maintenance of a patricia root integrated into its functionality. There could be a significant constant factor improvement by doing that right 17:42 < maaku> I'm open to suggestions on how that can be done better. 17:44 < bramc> Frequently time is dominated by memory lookups. Obviously the number of hashes to maintain the patricia root can't be changed, but if things are laid out properly then the number of memory lookups will be log(n)/8 instead of log(n) 17:45 < bramc> Does leveldb provide key/value functionality, and you hack a tree on top of that? 17:46 < bramc> leveldb also isn't using the fact that hashes are fixed length 17:47 -!- trippysalmon [rob@2001:984:6466:0:2801:ae4f:f0dd:e20e] has joined #bitcoin-wizards 17:47 < bramc> And it doesn't have support for batch inserts and reads either 17:52 -!- trippysalmon [rob@2001:984:6466:0:2801:ae4f:f0dd:e20e] has quit [Ping timeout: 250 seconds] 17:53 < bramc> Maybe the thing for me to do is finish my thoughts and hack together a protoype. If I do it will be in Python and slow but easy to port to C. 17:55 < CodeShark> why do people like to use python so much for prototyping? I mean, I understand it's a fairly regular language with pretty clear syntax...but anything you build will have to be eventually ported if you want to build anything decent :p 17:56 < CodeShark> I guess it's ok for apps that don't require much performance nor tight systems integration 17:56 < bramc> maaku, Does your implementation store intermediate nodes of the patricia tree as truncated bitfields? 17:57 < belcher> CodeShark eventually the prototype becomes the main program 17:57 < belcher> before you know it you're stuck with python 17:57 < bramc> CodeShark It's great when you're trying to get something up and running and are still experimenting. If you write in a simple style it's easy to port later, and you'll get to that point much quicker for not having had to deal with C in the interim. 17:58 < gmaxwell> see also p2pool. :( 18:00 < CodeShark> bramc: regarding leveldb, it is probably a good idea to not depend on any particular storage engine 18:00 < bramc> At my day job we've ported a decent size codebase from python to C. It isn't any different than the sorts of software engineering discipline you need to keep a legacy codebase from looking like bloated spaghetti 18:02 < CodeShark> wasn't part of the reason C++ was created to avoid having to do this kind of thing? :) 18:03 -!- JackH [~Jack@93.158.36.30] has quit [Ping timeout: 256 seconds] 18:03 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 18:03 -!- trippysalmon [rob@2001:984:6466:0:3528:f3dc:57e3:fb7] has joined #bitcoin-wizards 18:04 < bramc> CodeShark True about the code dependency. Thankfully patricia trees are a very well defined format with hardly any weird edge cases unless there are bugs. 18:04 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Ping timeout: 256 seconds] 18:05 -!- Tiraspol [~Tiraspol3@c-73-168-30-130.hsd1.il.comcast.net] has joined #bitcoin-wizards 18:05 -!- Tiraspol [~Tiraspol3@c-73-168-30-130.hsd1.il.comcast.net] has quit [Changing host] 18:05 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards 18:06 < bramc> Anything I write will be structured as a somewhat general purpose key/value store with the added features of maintained patricia root, batch updates and reads, defense against an attacker shoving everything into one section of the tree, and background maintenance 18:06 < bramc> That's actually a fairly long list of features. Yes I have ideas for all of them. 18:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 18:07 < bramc> Hey rusty, I was just babbling about the stuff we were discussing via email 18:07 < rusty> bramc: I better grab more coffee then :) 18:08 < bramc> Actually it won't be a key/value store, it will be a secure hash store 18:08 < bramc> aka a set :-) 18:08 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Ping timeout: 272 seconds] 18:08 < CodeShark> bramc: are you looking to write a storage engine optimized for this? 18:09 < bramc> CodeShark Yes that's the idea 18:10 -!- trippysalmon [rob@2001:984:6466:0:3528:f3dc:57e3:fb7] has quit [Ping timeout: 250 seconds] 18:11 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 18:13 < CodeShark> it sounds like it could be a pretty useful thing to have generally :) 18:13 < CodeShark> UTXO stuff just being one application 18:15 < bramc> Yeah I'll need to keep the feature set under control to avoid going down the rabbit hole with it though. It's a more-that-a-weekend project to begin with. 18:19 < bramc> Basic API should include batch insert, batch read, and get patricia root. Later there should be batch get paths to patricia root. 18:19 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 265 seconds] 18:19 < bramc> And, uh, whatever else is involved in fixed storage size nodes 18:20 < bramc> I'll probably break semantic boundaries a bit and make it not support items above a megabyte or so, because those can't be in the blockchain. 18:20 -!- trippysalmon [rob@2001:984:6466:0:cc85:753:9bf8:bb9a] has joined #bitcoin-wizards 18:21 < bramc> Maybe that restriction will be my contribution to the implicit semantics of bitcoin :-) 18:21 < CodeShark> hah 18:22 < CodeShark> what about support for pruning? 18:22 < bramc> Oh, right, there's batch delete as well 18:23 < CodeShark> I'm thinking also partial trees 18:23 < bramc> And calls for 'do background maintenance stuff now' 18:23 < bramc> Not sure what you mean by that 18:24 < CodeShark> nodes that don't necessarily store the entire utxo 18:24 < CodeShark> updates would require specifying the complete branch 18:24 < bramc> That falls under the general category of 'Not part of MVP' 18:24 < CodeShark> heh, ok :) 18:26 -!- trippysalmon [rob@2001:984:6466:0:cc85:753:9bf8:bb9a] has quit [Ping timeout: 250 seconds] 18:26 < bramc> I'm coming up with lots of implementation details, some of which I alluded to earlier, all of which it's probably a lot easier for me to explain by way of implementation. 18:27 -!- Guest3928 [~mr_burdel@hop.cryptolabs.net] has quit [Quit: :)] 18:27 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #bitcoin-wizards 18:27 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-wizards 18:29 < bramc> But the basics of the API are: 'do batch insert/delete', 'batch read', 'get root', and 'do background maintenance stuff' 18:29 < CodeShark> merging trees could be treated as a batch insert, I suppose 18:30 < bramc> Yes I'm assuming that merging trees is just merging in a small tree and is a regular batch insert 18:31 < bramc> Or a bunch of smaller batch inserts. Should work fine as long as the items being inserted are all grouped into sorted order 18:31 < CodeShark> right 18:32 -!- licnep [uid4387@gateway/web/irccloud.com/x-pwceuwjnisrzwkpo] has joined #bitcoin-wizards 18:32 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 18:32 < bramc> I'll be a little lazy about defense against an attacker intentionally clustering inserts in the first version. That can be done well, but I'll just do it okay, the amount which comes with letting maintenance operations be done in the background. 18:33 < CodeShark> you mean stuff like using HMAC(key, nonce) instead of just key? 18:33 < gmaxwell> Other concerns are that you must be able to efficiently undo state ... and also efficiently support fetching against an old version if you are to support hotstarting off a copy of this data fetched over the network. 18:34 < gmaxwell> bramc: if the data is keyed on transaction hashes, then clustering is protected by the difficulty of partial preimage attacks on the hash. 18:35 < CodeShark> partial preimage attacks can be made even more difficult :) 18:35 < CodeShark> but perhaps it's not necessary 18:36 < bramc> gmaxwell, That offers some degree of protection, but annoying attacks are still possible 18:37 -!- trippysalmon [rob@2001:984:6466:0:e85b:7f1:7bac:e54] has joined #bitcoin-wizards 18:37 < bramc> gmaxwell, Interesting point about rolling back. The obvious approach is to allow indefinite rollbacks, and make it so that roll forwards of pre-stored things don't waste. That doesn't prune though 18:37 < gmaxwell> bramc: not sure about that. at least when we anaylized this before we found the amount of unbalancing you could cause was basically negligible. 18:38 < bramc> gmaxwell, I'm happy to pretend the attacks don't work for now :-) 18:38 < CodeShark> as long as all attackers unbalance in uniformly distributed random directions we're totally fine ;) 18:39 < bramc> gmaxwell, My inclination for rolling back is to assume that it will be handled as forward operations - to switch what branch you're on you remove the blocks you're rolling back and insert the new ones, all as forwards operations 18:40 < gmaxwell> yea, the reorg cases isn't that big a deal as it can be handled basically as bitcoin core currently does, and thats okay. 18:40 < gmaxwell> Though the download case seems much harder to handle efficiently. 18:40 -!- roconnor [~roconnor@host-45-58-252-176.dyn.295.ca] has joined #bitcoin-wizards 18:40 -!- deego [~user@unaffiliated/deego] has left #bitcoin-wizards ["ty"] 18:41 < CodeShark> not sure I follow, gmaxwell - are you talking about receiving the stuff out of order? 18:42 < bramc> gmaxwell, The hope is that the data structure is so efficient that verifying the patricia tree root for every block on download is no big deal 18:43 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 18:43 -!- trippysalmon [rob@2001:984:6466:0:e85b:7f1:7bac:e54] has quit [Ping timeout: 250 seconds] 18:43 < CodeShark> oh, you mean being able to validate the deltas 18:43 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:44 < gmaxwell> I mean, you've not got this verified root thing, and you'd like to startup some kind of client using only 'SPV history security'. So that would involve you downloading the current state, checking it against the root, and continuing forward. (probably not quite current, actually, but say 300 blocks back) 18:44 < gmaxwell> Great. now ... you're downloading this multiple gigabyte dataset, you'd probably like to fetch it concurrently from multiple peers.. and it's likely going to take you more than 10 minutes to download. 18:45 < gmaxwell> So the network is going to keep moving. 18:45 < CodeShark> how big is the UTXO right now? 18:45 < gmaxwell> so what, you expect your peers to do an enormously expensive reorg back to where you want to fetch from... and then stay stuck there until you're done? Or ... well what? there are lots of ways to address this, but all seem to be awful expensive for the servers. 18:46 < gmaxwell> CodeShark: roughly a gigabyte on disk. About 4 when 'uncompressed' into the in memory data structures. 18:46 < rusty> CodeShark 33.5M txs. statoshi.info/dashboard/db/unspaent-transaction-output-set 18:46 < gmaxwell> (encoding on disk is way over optimized. :) ) 18:46 < CodeShark> hmm, yeah...it's quite likely a new block is mined before you're done downloading that :) 18:47 < rusty> s/txs/txouts/ 18:47 < CodeShark> could we perhaps have separate subbranches for each of block mod some number? 18:47 -!- orik [~orik@50.125.71.245] has quit [Ping timeout: 272 seconds] 18:48 < gmaxwell> CodeShark: perhaps, but to just copy is awful resource costly. 18:50 < CodeShark> if you go back just a few blocks on initial download you can make it highly unlikely that it gets reorged out...and then it's just a matter of applying the remaining deltas. And after sync you can always go backwards into the history to validate it to increase your security 18:52 -!- Giszmo [~leo@pc-100-214-164-190.cm.vtr.net] has joined #bitcoin-wizards 18:53 < gmaxwell> CodeShark: in terms of security model, it's much better to take a pretty good leap back there. The reason is that doing a day or two of sync is no big deal. (if you're so slow that this is a problem you have no hope of keeping up).. and it really changes the security assumptions. 18:54 -!- trippysalmon [rob@2001:984:6466:0:1c4f:77aa:8517:32c] has joined #bitcoin-wizards 18:54 < gmaxwell> Since at 100 block reorgs or so is where all bitcoin's incentive/security properties start falling apart. (basically the gap between SPV and full security closes for 'sufficiently large' reorgs) 18:54 < CodeShark> 100 because of maturity? 18:54 < CodeShark> or some other reason? 18:55 < bramc> gmaxwell, I'm not sure what your complaint is. The utxo commitment is just a new field in blocks. It adds nothing to the load of nodes serving data to a new node. 18:56 < gmaxwell> bramc: I'm talking about a specific way of using the commitment. 18:56 < CodeShark> bramc: I think we're talking about a different sync model 18:56 < gmaxwell> CodeShark: yea, because of maturity. 18:56 < CodeShark> where we sync to utxo directly 18:57 < bramc> gmaxwell, I understand your point about massive reorgs. For now I'm gonna punt. 18:57 < CodeShark> in this sync model, you just download block headers and utxo 18:58 < bramc> Oh right. hmm 18:58 < bramc> If you wish to start a new download which is pruned to a particular point, then you do need to download the utxo tree of a particular node in the past 18:59 -!- trippysalmon [rob@2001:984:6466:0:1c4f:77aa:8517:32c] has quit [Ping timeout: 250 seconds] 19:00 < bramc> There's an inherent tradeoff of whether you want to actually keep around all the old utxo roots or not. 19:00 < CodeShark> you go k blocks in the past, download the utxo from that point and ignore more recent stuff until you've got it, then you apply a delta for each block since, then you can optionally go backwards from that block to increase security 19:01 < CodeShark> gmaxwell suggests k should be >= 100 19:01 < bramc> It helps to have standardized points people work off of, like every 1000 blocks or so there's one which you're willing to serve utxo tree info for directly, and it's the same intervals for all peers. 19:02 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 19:03 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 256 seconds] 19:08 < CodeShark> yes, that could even be efficiently sharded 19:10 -!- trippysalmon [rob@2001:984:6466:0:9d4b:9ece:d1ef:39d2] has joined #bitcoin-wizards 19:12 < gmaxwell> sure, Agreed, but ... gonna keep a full copy of the last one of those? high overhead! 19:13 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-wizards 19:14 < maaku> maaku, Does your implementation store intermediate nodes of the patricia tree as truncated bitfields? 19:14 < maaku> yes. 19:15 < bramc> maaku, Ah in that case memory lookups can be dramatically improved using a custom data structure 19:15 < bramc> It's a little silly having a tree on top of a key/value store on top of a tree 19:16 -!- trippysalmon [rob@2001:984:6466:0:9d4b:9ece:d1ef:39d2] has quit [Ping timeout: 250 seconds] 19:18 < gmaxwell> ideally avoiding the (n log(n)) log (n log(n)) overheads. 19:20 < maaku> bramc: I'm not sure what you mean by "tree on top of a key/value store on top of a tree" 19:20 < maaku> it's the same tree 19:20 -!- csggggg8 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has quit [Ping timeout: 256 seconds] 19:21 < bramc> maaku, Sort of. If you're optimizing for memory lookups you lay things out a bit differently. 19:21 < maaku> I don't want to rain on anyone's parade, but it's not obvious to me that anything more than a small constaint is gained by a custom db / custom data structure 19:21 < CodeShark> he's talking about what happens if you use something like leveldb as your storage engine 19:22 < gmaxwell> maaku: small constants like ... 2? 19:22 < maaku> gmaxwell: or smaller 19:22 < gmaxwell> IMO halving costs in a normative datastructure is not insignificant. In particular you don't want to flub the normative part so that an efficient representation isn't possible. 19:22 < maaku> indexed key/value stores like leveldb are balanced trees internally 19:23 < maaku> and leveldb does have the batch update & snapshotting modes required 19:23 < CodeShark> I'd also rather let someone else handle the low-level storage optimization stuff...but if bramc wants to do it, I'm all for it ;) 19:24 < maaku> gmaxwell: the patricia trie spec I coded up is independent of data store. it's just the specificaiton for hashing nodes, and the ultraprune-like efficient network/disk format 19:24 < maaku> but how the tree is actually stored and indexed is not constrained 19:25 < CodeShark> maaku: I'm also a fan of using abstract models for this...but I think bramc actually enjoys this kind of work ;) 19:26 < gmaxwell> maaku: and leveldb's performance is already seemingly problematic for bitcoin core. (and drove ripple to go create its own thing) 19:27 < maaku> CodeShark: sure, but at the end of the day a significant performance boost would be required to justify maintaining a new db + the review work that would be required (this is consensus code!) 19:27 -!- trippysalmon [rob@2001:984:6466:0:a8e0:3ece:eb26:dec2] has joined #bitcoin-wizards 19:27 < maaku> vs. using leveldb (alredy part of consensus, and externally maintained) 19:27 < gmaxwell> maaku: yes sure and maybe it's not initially deployed that way. But see my comment above about normative data structures. 19:28 < gmaxwell> maaku: and already problematic without additional overheads. 19:28 < maaku> gmaxwell: I'm not sure I understand your above statement 19:29 < maaku> I think we are talking about the name normative data structure, just different storage methodologies 19:30 < maaku> this was, for example, the primary reason why I went from radix-256 (Alan's proposal) to radix-2 -- you can store a radix-2 as radix-256 by serializing 8 levels together on disk, but not vice versa 19:33 < maaku> anyway bramc I hope we can work together on defining a patricia trie spec for root calculation / hash structure and network relay format irregardless of storage methodology 19:33 < maaku> there's no reason the canonical representation for hashing purposes, or the compact encoding for p2p purposes need to be complicated by storage concerns 19:33 -!- trippysalmon [rob@2001:984:6466:0:a8e0:3ece:eb26:dec2] has quit [Ping timeout: 250 seconds] 19:33 < bramc> maaku, My intention right now is to make a set data structure which can spit out patricia tree roots. I can easily make the output conform to whatever your spec uses 19:34 < maaku> ok cool. 19:34 < bramc> maaku, Yes that radix-2 vs. radix-256 thing is one of the things I was babbling about before. 19:35 < maaku> my primary concern is seeing if there are further optimizations of the patricia trie structure (reducing hash compressions rounds, reducing proof sizes, etc.) 19:35 < bramc> You can batch up operations. That saves you some calculation. 19:36 < bramc> I don't think there's much of anything you can do to the patricia format though. It's pretty basic. We both like the idea of making the big root be a block behind, but that doesn't change it's format any 19:36 < bramc> For a delta you need a way to represent deletion, of course. 19:36 < gmaxwell> maaku: "there's no reason" -- ... if the hashing structure is one that inhibits an efficient storage implimentation that would be a very good reason. Perhaps in reality no such concern exists, but I don't think we know that without at least trying to design efficient storage... even if we don't use it. 19:38 -!- dstadulis [~maider@c-73-15-166-219.hsd1.ca.comcast.net] has joined #bitcoin-wizards 19:39 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 19:40 -!- roxtrong_ [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 19:40 < maaku> sure ok. well the first place to start is requirements. my own assumptions are that the two metrics to minimize are: (1) network serialization size of proofs, (2) number of compression rounds for validation of a proof 19:41 < maaku> and in a somewhat more distant third (doesn't take precidence over the other two), (3) fewest constraints on implementation 19:42 < bramc> maaku, That's totally dominated by it being radix-2. There isn't much to be added short of making things be deltas off periodic checkpoints, which I'll want to revisit later but first things first. 19:42 < gmaxwell> Hm. I don't understand the rational for (2). One off proof checking would be pretty rare, and the cost of the proof will be dominated by network bandwidth. 19:43 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has quit [Ping timeout: 264 seconds] 19:44 -!- trippysalmon [rob@2001:984:6466:0:e4c6:9580:c612:e79e] has joined #bitcoin-wizards 19:44 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] 19:45 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 19:45 < bramc> When you're sending paths to root in bulk a nontrivial amount of bandwidth can be saved by trimming duplicates. 19:45 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] 19:45 < CodeShark> just send a partial tree 19:47 < gmaxwell> bramc: sure, the filtered block stuff in bitcoin core does this. 19:47 < gmaxwell> (for block membership proofs) 19:48 < maaku> gmaxwell: SPV mode 19:48 < maaku> hardware wallets 19:48 < maaku> etc. 19:49 < gmaxwell> maaku: right, but consider! you're talking about multiple kilobytes of proof per txin. 2x the hashing will be negligible to dealing with all that extra data in almost all applications. 19:49 -!- adam3us1 [~Adium@195.138.228.20] has quit [Quit: Leaving.] 19:49 < rusty> bramc: the only interesting case is where you have to provide two neighbor nodes for purposes of non-existence proof. 19:49 < maaku> gmaxwell: yeah sure, for an actual computer. I don't want to overconstraint hardware or power requirements though 19:50 -!- trippysalmon [rob@2001:984:6466:0:e4c6:9580:c612:e79e] has quit [Ping timeout: 250 seconds] 19:50 < maaku> oh, also I've only considered solutions that have the possibility for stateless updates (not the best term... being able to calculate the new root using only the delta) 19:52 < gmaxwell> rusty: depending on the commitment structure a prefix tree may not need to adjcent branches to show non-existance. 19:52 < gmaxwell> e.g. if the immediate node above shows the span internally. 19:53 < CodeShark> that would almost always be the case 19:53 < gmaxwell> CodeShark: not sure? I vaguely recall that property was not very compatible with stateless updates. 19:54 < gmaxwell> but I could be wrong. 19:54 < maaku> CodeShark: it's not the case for the structure I developed 19:54 < CodeShark> ok 19:54 < gmaxwell> but if you really did expect to be mostly doing non-existance proofs, there are commitment structures that are more efficient on average, at least. 19:54 < maaku> so yeah, that's an area of research I would appreciate work on -- what's the minimal tradeoffs for adding that capability? 19:55 < rusty> gmaxwell: true, I was thinking simple bit-based patricia trie. But yes, proving a different leaf with same prefix as node N proves that N isn't there. 19:56 < rusty> gmaxwell: with a delta scheme, you may end up frequently proving "it was in base, but not in any delta", right? 19:56 < maaku> gmaxwell: what you're suggesting could be summarized as min-max commitments in the inerior nodes, correct? 19:56 < gmaxwell> maaku: Yes. 19:57 < gmaxwell> It might be useful to make a directory of query types, tie them to applications.. and then we can speak about how efficient different structures are for different offered query loads. 19:57 < maaku> i think that could be stateless so long as the min-max hashes aren't themselves pruned, but you're trading off compression rounds 19:57 < CodeShark> good idea, gmaxwell 19:57 < maaku> yeah it really depends on applications. e.g. for UTXO committments I would expect mostly existence proofs. non-existence proofs are chiefly for fraud proofs (I think?), which you need to support but are presumably rare 19:57 < maaku> but there are other applications... 19:58 < maaku> for an address [sic] index you'd expect more frequent non-existence proofs 19:59 < maaku> Also on the topic of commitments, if anyone wants to contribute something Really Usefull, we definately are in need of an infinite-regress merkle mountain range C library 19:59 < CodeShark> I started working on one in C++ 19:59 < CodeShark> what do you mean by infinite-regress? 20:00 < maaku> In MMR as defined by petertodd, you use a regular merkle tree for bagging the peaks. In infinite-regress you use an MMR for the peaks 20:01 -!- trippysalmon [rob@2001:984:6466:0:80a:a308:b275:597f] has joined #bitcoin-wizards 20:01 < maaku> (and then MMR for the peaks of the peaks, MMR again for the peaks of the peaks of the peaks, ... until you have just one hash left) 20:01 < CodeShark> ah, so a nested MMR 20:01 < maaku> yeah 20:01 < maaku> only really provides benefit when log N is large, but for things like STXO sets or block headers that grow forever, that minor optimization gives noticable benefit 20:01 < CodeShark> why is that really useful? 20:02 < maaku> rusty did some compact SPV proof analysis last year, and infinite/nested MMR was *much* better than the competition (something like 2x? I'd have to grep the logs) 20:03 < CodeShark> so only a constant factor? 20:04 < CodeShark> I guess it does make a difference when log N is large...but presumably log N still grows more slowly than moore's law and nielsen's law (hopefully) :) 20:04 < maaku> no that was sloppy of me; with the data sets we were using (meant to be representative of the bitcoin block chain circa 12mo ago) it was of that order 20:04 -!- bedeho_ [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 20:05 < CodeShark> I'm also concerned about complexity of implementations 20:06 < maaku> CodeShark: as am I; rusty had some other designs that were (imho) hacky e.g. fixed size batching with parameters determined by experiment 20:07 < maaku> nested MMR has the benefit of beating them *and* being a relatively straight forward algorithm 20:07 -!- trippysalmon [rob@2001:984:6466:0:80a:a308:b275:597f] has quit [Ping timeout: 250 seconds] 20:07 < maaku> hence the need for a write-once, use-everywhere C library 20:07 -!- K1NGREX [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection] 20:07 < CodeShark> if I understand correctly, the main benefit to MMR is shorter proofs for more recent txos...or is there something else to it? 20:09 < maaku> shorter proofs to the right-side of the tree 20:09 < CodeShark> yes...but don't you lose key indexing? 20:09 < maaku> it's a purposefully unbalanced data structure, for use cases where access patterns are typically unbalanced 20:10 < CodeShark> or do you need to re "unbalance" it on insertions? 20:12 < CodeShark> i.e. if you have to perform a lot of insertions in the middle of the structure it doesn't seem particularly efficient 20:12 < CodeShark> it's efficient when inserting always on the right 20:12 < maaku> CodeShark: it is only easy to add to the right 20:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 255 seconds] 20:12 < CodeShark> right - but then the leaves are always sorted by order of insertion 20:12 < gmaxwell> very efficient. but updating elsewhere isn't worse than updating in a search tree. 20:12 < CodeShark> and you need a separate index 20:13 < gmaxwell> but indeed you do, though that can be a non-normative datastructure for many purposes. 20:13 -!- hod0r [~h0d0r@50.248.81.66] has quit [Read error: Connection reset by peer] 20:14 < maaku> gmaxwell: hrm. I think you might need access to the full dataset to insert elsewhere than the right-side 20:14 -!- hod0r [~rubber@50.248.81.66] has joined #bitcoin-wizards 20:14 < gmaxwell> insert requires rebalacing but _update_ is as cheap as lookup. 20:14 < CodeShark> only if you have the full structure 20:14 < CodeShark> or? 20:14 < gmaxwell> No. 20:14 < maaku> gmaxwell: right, correct 20:15 < gmaxwell> so e.g. when PT is talking about STXO he assumes you show membership and use the same proof also to update to mark the output spent. 20:15 < CodeShark> ok, right 20:15 < maaku> insert/delete requires N/2, update is log N (avg) 20:15 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 20:16 < gmaxwell> I suspect there is a way to without much cost support a 'lumpy' mmr that can be cheaply insert/remove but with an unbalancing cost. 20:17 < CodeShark> perhaps I'm missing something but I'm not entirely convinced of the benefits...and it seems to be substantially more complex than patricia trees 20:17 < gmaxwell> it's just you cannot use incrementally optimal self-balancing structures without having to have random access to all the data. :( 20:17 < gmaxwell> CodeShark: its substantially less complex in fact. 20:17 < CodeShark> howso? 20:17 -!- trippysalmon [rob@2001:984:6466:0:59b7:7ed3:275c:3222] has joined #bitcoin-wizards 20:17 < CodeShark> you mean for the verifier? or the prover? 20:18 < gmaxwell> it's just an insertion ordered tree. whoppie. .. with a little bit of special handling on insertion to deal with the unbalanced leading edge. For everyone. 20:18 < gmaxwell> but it makes for different cost tradeoffs. 20:19 < CodeShark> insertions on the right are less complex - I'll give you that :p 20:20 < CodeShark> just about all other operations are more complex 20:21 < gmaxwell> someone shows membership to you.. thats simpler. certantly not more complex.. it's exactly like checking membership of a transaction in a block. 20:22 < gmaxwell> fradulent spends, you have blocks commit to the indexes their inputs are at, and then you just show whats actually at that index. 20:22 < CodeShark> for very specific use cases I can see it having some benefits...but it seems extremely limiting in that once you go outside those narrow use cases it seems ugly. patricia trees seem to be decent for all cases 20:23 < gmaxwell> CodeShark: I am skeptical. I initially thought that and then found when I went through it I was wrong on every count. 20:23 -!- trippysalmon [rob@2001:984:6466:0:59b7:7ed3:275c:3222] has quit [Ping timeout: 250 seconds] 20:24 < gmaxwell> All the cases I came up with the proofs ended up smaller, almost half the size. The software not more complex to describe. And the one thing I really thought it would do poorly is handle pruning and then sipa simulated it on the bitcoin history and found it pruned about as well. 20:24 < maaku> CodeShark: MMR to me seems strictly more useful on average that patricia tries ... but there are some cases (e.g. utxo) where patricia tries work better 20:25 < CodeShark> so you maintain a separate index of the leaves? 20:26 < maaku> CodeShark: can you expand on the use case you are imagining, for which you would require the index? 20:26 < CodeShark> query for a specific txo 20:27 < gmaxwell> [OT] is there some metapackage in debian for "no really, I actually want to write software on this host"? having to install automake / libtool etc one at a time is obnoxious, I'm surprised they're not in build-essential 20:31 < maaku> CodeShark: the assumption with the MMR based proposals is that is pushed off onto the wallet 20:32 < CodeShark> gmaxwell: echo 'alias iwanttowritesoftware="apt-get build-essential automake libtool"' >> ~/.bash_profile; source ~/.bash_profile; iwanttowritesoftware :p 20:33 < CodeShark> maaku: yes, understood...but that assumption (while not necessarily a bad idea) seems limiting 20:34 < CodeShark> i.e. you might want to outsource proving 20:34 < gmaxwell> it doesn't need to be pushed off to the wallet, but it can be. Or to a third party index provider. 20:34 -!- trippysalmon [rob@2001:984:6466:0:1c62:7e05:1ea4:3d51] has joined #bitcoin-wizards 20:36 < CodeShark> it also seems like it would complicate sharding or other such things 20:36 < CodeShark> dunno - a factor of 2 doesn't fully convince me 20:37 < CodeShark> longer individual proofs - but seems more complex for full synching 20:37 < CodeShark> err, less complex 20:37 < CodeShark> using patricia trees 20:39 < CodeShark> gives us far more flexibility architecturally 20:39 < gmaxwell> I think thats mistaken. 20:39 < bramc> Don't proofs of not there in patricia just boil down to showing two neighboring leaves? 20:39 < CodeShark> yes, bramc 20:40 -!- trippysalmon [rob@2001:984:6466:0:1c62:7e05:1ea4:3d51] has quit [Ping timeout: 250 seconds] 20:40 < gmaxwell> CodeShark: in working through this before, I started in your position and then came to the conclusion that for each of the query classes I could enumerate the STXO style approach was more flexable. And it allowed some very powerful offloading that I couldn't see how to do otherwise. 20:40 < gmaxwell> e.g. designs where no host in the world had the full state and it worked fine. 20:41 -!- roxtrong_ [~roxtrongo@190-22-190-148.baf.movistar.cl] has quit [Remote host closed the connection] 20:41 < gmaxwell> I'm not asking you to take my word for it, just have an open mind. 20:41 < CodeShark> I need to see it to believe it 20:42 < gmaxwell> Uncertanty around pruning was the main concern I had with it after working it all through. 20:42 < bramc> gmaxwell, What use case are you thinking of for mmr? 20:42 < CodeShark> can you elaborate on that, gmaxwell? 20:43 < gmaxwell> Also, careful that you don't confuse goals with mechenisms. Like... _why_ do you want a non-existance proof? To show a block is fradulent? But that doesn't actually need a non-existance proof, the block can just instead specify which indexes its spending. 20:44 < gmaxwell> CodeShark: STXO design doesn't ever 'remove' entries, it just updates them to mark them as spent (e.g. replaces them with a constant value spent token.) So you can prune the tree. This sounds inherently less efficient, but it turns out that "log X" is essential no worse than some constant, in the physical universe... so the fact that the tree is a bit bigger hardly matters. 20:45 < CodeShark> STXO vs UTXO seems like a separate issue of patricia tree vs. MMR tree 20:46 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] 20:46 < gmaxwell> MMR doesn't make sense with utxo because the common operations there are random insertions and removals which are not efficient for MMR. 20:47 < CodeShark> yes, I get that - in fact, I've even implemented it 20:47 < CodeShark> but you could still have STXO with a patricia tree 20:47 < gmaxwell> STXO the common operations are appending (ultra efficient, works proofless) and a lookup+update. 20:47 < gmaxwell> you could. but the operations STXO does are exactly those which are ultraefficient for MMR. 20:49 < CodeShark> and you need a separate index for arbitrary structure queries 20:49 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] 20:49 < gmaxwell> But who is you? 20:49 < gmaxwell> A full node needs no such index. 20:49 -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards 20:49 < gmaxwell> A miner needs no such index. 20:49 < CodeShark> a prover needs the index 20:49 < CodeShark> unless it's the sender 20:49 < gmaxwell> A wallet does, but only for the coins that it can spend. 20:49 < CodeShark> the only use case where the prover doesn't need the index is when the prover is the sender - but that seems rather restrictive 20:50 < gmaxwell> and then you can relay the offsets along with the transactions. 20:50 < CodeShark> I'm thinking about, i.e., synching two instances of the same wallet 20:50 < gmaxwell> and you can even ask a third party to provide them. So you have many options: have a index yourself. Okay. Then you can relay along the offsets on any tx you see so indexless nodes can find them. 20:51 < gmaxwell> Or you can have a partial index, with an arbritary sharding of your choice.. including "coins I can spend" 20:51 -!- trippysalmon [rob@2001:984:6466:0:d54d:e3f4:35d2:1268] has joined #bitcoin-wizards 20:51 < bramc> I still don't understand what stxo/mmr is being considered for 20:51 < CodeShark> also, what happens when the recipient is not online at the time the transaction is sent? does the sender outsource delivery? 20:52 < gmaxwell> CodeShark: no different than bitcoin? 20:52 < CodeShark> so all these proofs would be relayed continuously all the time? 20:52 < gmaxwell> (I mean if there is no one storing recent blocks at all then you have an issue there-- but the point is that you can choose any degree in between what bitcoin has not and everyone is stateless) 20:52 < CodeShark> I suppose with something like lightning we can really begin to talk about outsourcing delivery 20:53 < CodeShark> but with the current flood model it doesn't seem to make much sense 20:54 < gmaxwell> CodeShark: I don't agree? I mean you can keep recent blocks (like with pruning we won't go below 288 in bitcoin core) and then after that if you've been offline a wallet has to go find an archive node to tell them about transactions of theirs. 20:57 < gmaxwell> and by archive I don't mean complete,... I mean perhaps it just needs one with 2016 blocks back.. or it knows it gave out keys hashing to X,Y,Z lately so needs archives specializing in those keyspaces. 20:57 < gmaxwell> Or it's a foobar-script wallet and talks to an archive that indexes only scriptpubkeys of that particular kind, and so on. 20:57 < gmaxwell> the indexing is non-normative with STXO+MMR so you're not fixed on a single commited way of making indexes. 20:58 < gmaxwell> maybe you have shared nodes that index every Nth block and you go gather from them when you sync back up. ::shrugs:: 21:00 < CodeShark> dunno - introducing substantial asymmetry for the sake of at most a halving of proof sizes that can be delivered directly to recipients (i.e. via lightning) doesn't sound very appealing...but I'll continue to keep an open mind :) 21:00 < gmaxwell> well it's not just halving the proof size, it also renders it independant of the indexing structure. 21:01 -!- smk [9e557647@gateway/web/freenode/ip.158.85.118.71] has quit [Quit: Page closed] 21:02 < CodeShark> where would that be beneficial? 21:02 < bramc> oh, stxo = spent transaction outputs 21:02 < CodeShark> yes 21:03 < gmaxwell> well I just described. you can have every system in the world be almost completely stateless. (just a small near constant amount of state, plus recent history for reorgs) ... plus then whatever information that is 'interesting' to them via whatever scheme you'd like to dream up, now or in the future. 21:03 < bramc> what's the benefit of mmr over patricia for stxo? 21:04 < CodeShark> that's what we're discussing, bramc 21:04 -!- rabidus [~lauri.j@uhiainen.com] has joined #bitcoin-wizards 21:04 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] 21:04 < bramc> Yeah I'm not following. Is it that the mmr has less update costs? 21:04 < gmaxwell> 20:47 < gmaxwell> STXO the common operations are appending (ultra efficient, works proofless) and a lookup+update. 21:04 < gmaxwell> 20:47 < gmaxwell> you could. but the operations STXO does are exactly those which are ultraefficient for MMR. 21:05 < CodeShark> the main benefit seems to be that as long as we're only performing append operations we only need to store the root hash 21:05 < CodeShark> and each object appended requires only a short proof 21:05 < gmaxwell> if you have the leading edge of the mmr already then each append is proofless. 21:05 < bramc> Is there any way to prove something isn't there in mmr? 21:06 < gmaxwell> bramc: At least in the context of block fraud you can eliminate the need for non-membership proofs by requiring any claim of membership at least provide the offset (which is free). 21:07 < bramc> gmaxwell, I'm not sure what you just said 21:07 < bramc> I understand that patricia is taking on significant costs for the sake of keeping everything sorted 21:07 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Remote host closed the connection] 21:07 < gmaxwell> Sorting is overkill. Consider: you're sorting on meaningless hashes. "How doees this make sense" :P 21:07 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 21:08 < CodeShark> but then you need to sort anyhow for indexing 21:08 < bramc> Well there's a reason to keep the utxo set sorted 21:08 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Remote host closed the connection] 21:08 < gmaxwell> We'd like to show non-membership to prove a block or transaction is fradulent... right? so just have the block or transaction give the 32bit or 64bit or whatever index for the position of the thing they claim is a member in the insertion ordered comitted list. 21:09 < gmaxwell> Proof of non-membership is simply showing whats actually at that offset. 21:09 < bramc> define 'fraudulent'. Double-spent? meaningless? 21:09 < gmaxwell> Doublespent, meaningless, never have existed in the first place. 21:10 < gmaxwell> You make every input claim what offset it consumes. The thing its consuming is either there .. or it's not (because it was spent, or because it was never there in the first place) 21:10 < bramc> Ah, now I understand what the requirement is 21:11 < MRL-Relay> [tacotime] well... but you do need the data structure to be stable on insertion/deletion 21:11 < bramc> Yes for stxo mmr makes a lot more sense because of the lack of sorting requirement because you don't need to prove stuff isn't there. 21:11 < gmaxwell> You never delete. And you only append not insert. 21:11 < gmaxwell> To spend a coin you update it and replace it with a fixed constant spent flag. 21:12 < MRL-Relay> [tacotime] What about reorganizations? 21:12 < gmaxwell> [tacotime]: for any of these schemes reorgs are handled by external magic (rollback logs) 21:12 < MRL-Relay> [tacotime] oh, i see. 21:12 < gmaxwell> e.g. what bitcoin does for the UTXO set. 21:14 < MRL-Relay> [tacotime] yeah, that's how btcd always handled reorgs too. but i figured that for something like that you'd have to the reverse of all changes, so you'd have to keep a log of all altered paths in the tree for each block i guess. 21:15 < gmaxwell> really it's just a log of any destroyed data, plus the updates themselves is sufficient. 21:17 < CodeShark> how would you do initial sync of a full validator node using mmr+stxo? 21:17 < CodeShark> (without having to download the entire blockchain) 21:18 < gmaxwell> with full security? well the only option for that is downloading all the blocks so you mean with SPV security? 21:18 < CodeShark> let's not call it SPV security :p 21:18 < CodeShark> let's say recent history security - i.e. the last 1000 blocks 21:18 < CodeShark> + PoW 21:19 < gmaxwell> Sure. you get the root for t-1000 and then start fetching blocks along with their update proofs from nodes that have those full blocks. 21:21 < CodeShark> ok, so then the key insight is that we're actually committing to the position of each output in each block 21:21 < CodeShark> explicitly 21:21 < gmaxwell> yes. 21:21 < CodeShark> why didn't you start off with that? :) 21:22 < gmaxwell> Assumed background knoweldge. Sorry. 21:23 < gmaxwell> now to be fair, I'm somewhat selling you a sweet song here. There are complications. Stateless nodes like I described are dependant on needing membership proofs for all inputs. Thats less bandwidth efficient than sending a whole utxo set at some point. 21:24 < gmaxwell> you could instead just fetch the whole pruned state too, however. 21:24 < gmaxwell> though since the number of entries is all history instead of utxo it will be somewhat larger. (not as much as you think, because of pruning) 21:24 < gmaxwell> but in the worst case it's much larger. 21:25 < gmaxwell> e.g. if the network manages to spend every other output though all the history just to screw with you. 21:28 < gmaxwell> I CAN FINALLY GO HOME! 21:28 * gmaxwell vanishes 21:28 < CodeShark> lol 21:29 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 21:32 < bramc> I think for my MVP I'm going to make it a set of hashes and not store the things they're hashes of 21:35 -!- dstadulis [~maider@c-73-15-166-219.hsd1.ca.comcast.net] has quit [Quit: ZZZzzz…] 21:42 < gmaxwell> anyways, once you work through the overheads enough to see how what I was just describing is not all roses, the next set of ideas is the dual structure where you have a fixed size utxo of recent history and then evict things from it into an STXO history.. and indeed, at that point you end up with something that is more complex than a plain huge patrticia tree. 21:43 < CodeShark> we could also commit to backreferences using a patricia tree to allow for stateless validation...but specifying paths requires a bit more than just an offset 21:43 < gmaxwell> but you get savings in two ways-- you keep short lifetime outputs out of the STXO logN ... and you get really small proofs for them too. 21:47 < bramc> gmaxwell, That's similar to my proposal to having big patricia trees which only get updated at set times and working off a delta from it 21:48 < gmaxwell> bramc: I hadn't made that connection before you'd mentioned your thing just because the motivations were different. 21:48 < gmaxwell> (e.g. I just never considered the IO cost implications of the split scheme) 21:49 < gmaxwell> since stxo is insertion ordered it doesn't have any huge mandatory IO cost implications by itself. One of the selling points of that class of schemes. 21:56 < gmaxwell> [OT] latest pictures of pluto are awesome: http://www.nasa.gov/sites/default/files/thumbnails/image/crop_p_color2_enhanced_release.png ... the things you can do with 2000 bits per second. :P 21:59 < CodeShark> thinking about these commitment schemes hurt my brain too much...let's talk about...BIGGER BLOCKS! (ducks) 22:03 -!- ruby32 [~ruby32@75.133.112.155] has quit [Ping timeout: 240 seconds] 22:05 -!- ruby32 [~ruby32@75.133.112.155] has joined #bitcoin-wizards 22:07 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] 22:08 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] 22:09 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 22:13 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Ping timeout: 268 seconds] 22:24 -!- licnep [uid4387@gateway/web/irccloud.com/x-pwceuwjnisrzwkpo] has quit [Quit: Connection closed for inactivity] 22:26 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards 22:27 -!- maaku is now known as Guest16568 22:30 -!- bigreddmachine [~bigreddma@c-67-176-94-89.hsd1.co.comcast.net] has joined #bitcoin-wizards 22:32 -!- bigreddmachine [~bigreddma@c-67-176-94-89.hsd1.co.comcast.net] has quit [Client Quit] 22:35 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 22:35 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-ewklkeczwwjokgut] has quit [Quit: Connection closed for inactivity] 22:37 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 22:46 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 244 seconds] 22:49 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has quit [Remote host closed the connection] 22:56 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-wizards 22:56 -!- matsjj [~matsjj@cpc73684-dals20-2-0-cust891.20-2.cable.virginm.net] has joined #bitcoin-wizards 22:59 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rpgtluhqgcfxqsvk] has joined #bitcoin-wizards 22:59 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 246 seconds] 23:06 -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has joined #bitcoin-wizards 23:11 -!- roxtrongo [~roxtrongo@190-22-190-148.baf.movistar.cl] has joined #bitcoin-wizards 23:14 -!- MoALTz__ [~no@78.11.179.104] has joined #bitcoin-wizards 23:17 -!- MoALTz_ [~no@78.11.179.104] has quit [Ping timeout: 246 seconds] 23:26 -!- matsjj [~matsjj@cpc73684-dals20-2-0-cust891.20-2.cable.virginm.net] has quit [Remote host closed the connection] 23:32 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 240 seconds] 23:37 -!- trippysalmon [rob@2001:984:6466:0:d54d:e3f4:35d2:1268] has quit [Ping timeout: 250 seconds] 23:37 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 23:38 -!- trippysalmon [rob@2001:984:6466:0:3c38:297f:9b0a:b029] has joined #bitcoin-wizards 23:40 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 23:43 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-wizards 23:44 -!- trippysalmon [rob@2001:984:6466:0:3c38:297f:9b0a:b029] has quit [Ping timeout: 250 seconds] 23:52 -!- matsjj [~matsjj@cpc73684-dals20-2-0-cust891.20-2.cable.virginm.net] has joined #bitcoin-wizards 23:54 -!- trippysalmon [rob@2001:984:6466:0:f9eb:da6:97e4:ed49] has joined #bitcoin-wizards 23:56 -!- matsjj [~matsjj@cpc73684-dals20-2-0-cust891.20-2.cable.virginm.net] has quit [Remote host closed the connection] 23:57 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 23:58 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 265 seconds] --- Log closed Fri Sep 25 00:00:06 2015