--- Log opened Fri Sep 18 00:00:31 2015 00:06 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] 00:07 -!- execut3 [~shesek@77.125.99.86] has quit [Ping timeout: 265 seconds] 00:12 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 00:12 -!- Dr-G [~Dr-G@x4d08a1dd.dyn.telefonica.de] has joined #bitcoin-wizards 00:12 -!- Dr-G [~Dr-G@x4d08a1dd.dyn.telefonica.de] has quit [Changing host] 00:12 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 00:23 -!- execut3 [~shesek@77.125.99.86] has joined #bitcoin-wizards 00:29 -!- zooko_ [~Android@75.111.103.164] has joined #bitcoin-wizards 00:29 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-sddcogyfxenrtztb] has joined #bitcoin-wizards 00:32 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards 00:33 -!- zooko [~Android@172.56.30.227] has quit [Ping timeout: 256 seconds] 00:40 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] 00:43 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] 00:51 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 01:00 -!- fkhan [weechat@gateway/vpn/mullvad/x-uivaeolcbgdoburu] has quit [Ping timeout: 246 seconds] 01:01 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-vceqlmyhmvcqexsh] has quit [Ping timeout: 250 seconds] 01:01 -!- nullbyte [NSA@gateway/vpn/mullvad/x-cxsebwrsaitdketd] has quit [Ping timeout: 260 seconds] 01:02 -!- nullbyte [NSA@gateway/vpn/mullvad/x-omfvwtdkirfpvrcs] has joined #bitcoin-wizards 01:03 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-yfizfcznklwidrcu] has joined #bitcoin-wizards 01:03 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 01:04 -!- publius1788 [~publius17@104.200.154.10] has quit [Changing host] 01:04 -!- publius1788 [~publius17@unaffiliated/publius1788] has joined #bitcoin-wizards 01:06 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] 01:09 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds] 01:12 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 01:13 -!- fkhan [~weechat@193.138.219.233] has joined #bitcoin-wizards 01:13 -!- fkhan [~weechat@193.138.219.233] has quit [Changing host] 01:13 -!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-wizards 01:21 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] 01:26 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 01:45 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards 01:48 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Read error: Connection reset by peer] 01:52 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] 01:55 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards 02:09 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 02:18 -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has joined #bitcoin-wizards 02:25 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards 02:31 -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has quit [Quit: hdbuck] 02:34 -!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has joined #bitcoin-wizards 02:35 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] 02:37 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards 02:42 -!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has joined #bitcoin-wizards 02:50 -!- rw|zZz is now known as c0rw1n 02:57 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Read error: Connection reset by peer] 02:58 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-wizards 03:04 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 03:07 -!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has quit [Ping timeout: 244 seconds] 03:09 -!- erasmospunk [~erasmospu@151.37.29.26] has joined #bitcoin-wizards 03:10 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 03:15 -!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has joined #bitcoin-wizards 03:18 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 03:31 -!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has quit [Ping timeout: 265 seconds] 03:38 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection] 03:41 -!- shredder_ [~marcinja@18.189.89.168] has joined #bitcoin-wizards 03:42 -!- ttttemp [~ttttemp@pc-5305.ethz.ch] has quit [Remote host closed the connection] 03:46 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards 03:46 -!- erasmospunk [~erasmospu@151.37.29.26] has quit [Ping timeout: 250 seconds] 03:46 -!- shredder_ [~marcinja@18.189.89.168] has quit [Ping timeout: 272 seconds] 03:49 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Ping timeout: 264 seconds] 03:54 -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has joined #bitcoin-wizards 03:55 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-siccoivyejisixkp] has joined #bitcoin-wizards 03:56 -!- Dr-G [~Dr-G@xd9bf7004.dyn.telefonica.de] has joined #bitcoin-wizards 03:56 -!- Dr-G [~Dr-G@xd9bf7004.dyn.telefonica.de] has quit [Changing host] 03:56 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 04:04 -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards 04:07 -!- erasmosp_ [~erasmospu@179.43.156.130] has joined #bitcoin-wizards 04:07 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 04:08 < da2ce7> phantomcircuit, in fact these public private key 'stress test' are nothing more than an effective bounty for the rollout of full replace by fee. 04:09 -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has quit [Ping timeout: 265 seconds] 04:20 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 04:27 -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has quit [Remote host closed the connection] 04:35 -!- gill3s [~gill3s@unaffiliated/gill3s] has joined #bitcoin-wizards 04:36 -!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has quit [Ping timeout: 256 seconds] 04:37 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 04:38 -!- flower [~user@202.44.241.187] has quit [Quit: -] 04:42 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 272 seconds] 04:42 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #bitcoin-wizards 04:43 -!- gmaxwell is now known as Guest69884 04:49 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] 04:54 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 05:04 -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has joined #bitcoin-wizards 05:25 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards 05:26 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Client Quit] 05:27 -!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has joined #bitcoin-wizards 05:28 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards 05:43 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Quit: Leaving] 05:43 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards 06:04 -!- Guest69884 [greg@mf4-xiph.osuosl.org] has quit [Changing host] 06:04 -!- Guest69884 [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-wizards 06:04 -!- Guest69884 is now known as gmaxwell 06:06 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.] 06:11 -!- eudoxia [~eudoxia@r167-56-33-185.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 06:16 -!- jtimon [~quassel@172.56.6.239] has joined #bitcoin-wizards 06:22 -!- jtimon [~quassel@172.56.6.239] has quit [Ping timeout: 260 seconds] 06:24 -!- adam3us [~Adium@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.] 06:37 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-siccoivyejisixkp] has quit [Quit: Connection closed for inactivity] 06:38 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 06:40 -!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has quit [Ping timeout: 265 seconds] 06:42 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards 06:46 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Ping timeout: 240 seconds] 06:47 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Ping timeout: 250 seconds] 06:48 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards 06:50 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards 06:50 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 06:53 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Ping timeout: 240 seconds] 06:53 -!- davispuh [~quassel@212.93.100.223] has joined #bitcoin-wizards 07:00 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Remote host closed the connection] 07:06 -!- binaryFate [~binaryFat@93-47-253-162.ip115.fastwebnet.it] has joined #bitcoin-wizards 07:07 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 07:13 -!- JackH [~Jack@host-80-43-143-151.as13285.net] has joined #bitcoin-wizards 07:15 -!- jinglebellz [~jinglebel@149.130.142.147] has joined #bitcoin-wizards 07:16 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 07:24 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards 07:24 -!- adam3us [~Adium@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards 07:25 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 07:31 -!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards 07:35 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 07:37 -!- bsm1175321 [~bsm117532@38.121.165.30] has joined #bitcoin-wizards 07:43 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.] 07:45 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 260 seconds] 07:48 -!- helo is now known as helo_ 07:48 -!- helo_ is now known as heIo 07:48 -!- heIo is now known as he1o 07:48 -!- he1o is now known as helo 07:49 -!- wizkid057 is now known as wk 07:50 -!- wk is now known as wizkid 07:50 -!- wizkid is now known as wizkidO57 07:51 -!- wizkidO57 is now known as wizkid057_ 07:51 < kanzure> "accountable anonymous group communication" http://dedis.cs.yale.edu/dissent/ https://github.com/DeDiS/Dissent 07:51 -!- wizkid057_ is now known as wizkid057 07:54 -!- eudoxia_ [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 07:55 -!- eudoxia [~eudoxia@r167-56-33-185.dialup.adsl.anteldata.net.uy] has quit [Read error: Connection reset by peer] 07:57 -!- eudoxia_ [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has quit [Client Quit] 08:00 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 08:01 -!- adam3us [~Adium@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.] 08:12 -!- jinglebellz [~jinglebel@149.130.142.147] has quit [Remote host closed the connection] 08:13 -!- jinglebellz [~jinglebel@149.130.142.147] has joined #bitcoin-wizards 08:17 -!- jinglebellz [~jinglebel@149.130.142.147] has quit [Ping timeout: 256 seconds] 08:20 -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards 08:22 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 08:33 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds] 08:33 -!- trippysalmon [~Rob@ip4da81ded.direct-adsl.nl] has quit [Read error: Connection reset by peer] 08:36 < JackH> are all these links/documents you paste somewhere else? like in one big repo? 08:38 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 08:41 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .] 08:43 < kanzure> JackH: not entirely; but i keep papers here: http://diyhpl.us/~bryan/papers2/bitcoin/ http://diyhpl.us/~bryan/papers2/bitcoin/snarks/ http://diyhpl.us/~bryan/papers2/security/ etc. 08:45 < JackH> ahh you are also the dude with the transcripts from the consensus 08:45 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 08:45 < kanzure> JackH: http://diyhpl.us/wiki/transcripts/scalingbitcoin/ 08:46 < JackH> ah yes that 08:47 < JackH> hmm this should be indexed and stored better 08:48 < JackH> you have anything from DNA crypto to Bitcoin crypto 08:53 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 255 seconds] 08:54 -!- MrHodl [~fuc@185.22.183.196] has joined #bitcoin-wizards 08:59 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .] 08:59 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 09:00 -!- zooko [~Android@2607:fb90:2c0c:a70c:4acb:d3c5:db70:4dfd] has joined #bitcoin-wizards 09:00 < kanzure> JackH: true, in what way would you organize it? 09:00 < JackH> hmm, well some tree structure, maybe search based 09:01 < JackH> but yeah, takes time 09:01 < JackH> alot of manual work and sorting through it and defining everything 09:01 < JackH> but I think a relationship between the papers would be good to have 09:01 < JackH> so that there is a clear way to introduce people to a certain subject 09:02 < JackH> so you need to for instance to read the Bitcoin whitepaper before you move onto the Sidechain whitepaper 09:02 -!- zooko__ [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has joined #bitcoin-wizards 09:03 -!- zooko_ [~Android@75.111.103.164] has quit [Ping timeout: 246 seconds] 09:04 -!- zooko [~Android@2607:fb90:2c0c:a70c:4acb:d3c5:db70:4dfd] has quit [Ping timeout: 268 seconds] 09:07 < kanzure> sounds like you mean the citation graph 09:08 < Taek> JackH were you at montreal? we talked about a few similar things 09:08 < JackH> I was not unfortunately 09:08 < JackH> would have loved to e 09:08 < JackH> be 09:09 < kanzure> JackH: he means http://diyhpl.us/wiki/transcripts/scalingbitcoin/systematizing-knowledge/ 09:11 < JackH> Committed effort to improve the bitcoin wiki? <-- that one for certain is a big one 09:11 < Taek> BlueMatt: we talked about making prs to bitcoin.ninja, what types of things would you be willing vs unwilling to merge? 09:13 < JackH> well from reading the link really quick 09:13 < JackH> I see everyone agree's 09:13 < JackH> we all know alot and its nowhere to be found 09:13 < JackH> I bet I am not the only one with 100's of links to things 09:13 < JackH> well....kanzure is a good candidate of link overload 09:14 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards 09:14 < Taek> JackH: best place to start is by collecting a few of them into a specific topic, and then perhaps providing a commentary on the topic, maybe with prereqs and related info 09:14 < JackH> yeah 09:14 < JackH> but where? 09:14 < JackH> I mean, sure, we can each do something 09:14 < JackH> I could do something like this.... 09:15 < Taek> PR to bitcoin.ninja: https://github.com/TheBlueMatt/bitcoinninja 09:15 < Taek> if he doesn't merge it, I'm happy to host an alternative website 09:15 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards 09:18 < kanzure> JackH: links are here, http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-selected-bookmarks.2015-09-09.txt or in yaml format http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-selected-bookmarks.2015-09-09.yaml 09:19 < JackH> what format would people be mostly interested in having? Wiki style? Website style? reddit style? something else? 09:20 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 09:21 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 09:22 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 09:23 < kanzure> JackH: a wiki page with summaries of #bitcoin-wizards logs per day would be nice. maybe 3-4 sentences per day. http://gnusha.org/bitcoin-wizards/ has irc logs. 09:24 < JackH> hmmm, yeah there is this as well 09:25 -!- davec [~davec@cpe-24-243-239-16.hot.res.rr.com] has joined #bitcoin-wizards 09:26 < JackH> are you constantly adding new material kanzure? 09:28 < kanzure> usually 09:33 -!- davec [~davec@cpe-24-243-239-16.hot.res.rr.com] has quit [Ping timeout: 244 seconds] 09:36 -!- zwick [~zwick@fsf/member/zwick] has joined #bitcoin-wizards 09:37 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] 09:42 < JackH> hmm, you know what, I think ill give this a go 09:42 < JackH> stick around, I will show you when I got something that could maybe work 09:48 -!- GAit [~GAit@208.54.86.233] has joined #bitcoin-wizards 09:49 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards 09:51 -!- PaulCape_ [~PaulCapes@199.19.94.16] has joined #bitcoin-wizards 09:53 -!- zooko__ [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has quit [Ping timeout: 248 seconds] 09:53 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards 09:53 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds] 09:56 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards 09:57 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 09:59 -!- PaulCape_ [~PaulCapes@199.19.94.16] has quit [Ping timeout: 240 seconds] 10:01 -!- maraoz [~maraoz@50.247.108.204] has joined #bitcoin-wizards 10:01 -!- GAit [~GAit@208.54.86.233] has quit [Read error: Connection reset by peer] 10:01 -!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has joined #bitcoin-wizards 10:04 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep] 10:05 -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards 10:06 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards 10:07 -!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has joined #bitcoin-wizards 10:07 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Ping timeout: 250 seconds] 10:08 -!- binaryFate [~binaryFat@93-47-253-162.ip115.fastwebnet.it] has quit [Ping timeout: 244 seconds] 10:18 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards 10:25 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep] 10:25 -!- dEBRUYNE_ [~dEBRUYNE@vp0414.uvt.nl] has joined #bitcoin-wizards 10:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] 10:28 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds] 10:29 -!- davec_ [~davec@cpe-24-243-239-16.hot.res.rr.com] has joined #bitcoin-wizards 10:29 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has quit [Quit: tbmit] 10:30 -!- trippysalmon [rob@2001:984:6466:0:cca2:89cf:5e8d:9e38] has joined #bitcoin-wizards 10:30 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds] 10:32 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards 10:38 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards 10:38 -!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has quit [Quit: prom3th3us] 10:40 -!- davec_ [~davec@cpe-24-243-239-16.hot.res.rr.com] has quit [Ping timeout: 272 seconds] 10:40 -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] 10:42 -!- dEBRUYNE_ [~dEBRUYNE@vp0414.uvt.nl] has quit [Read error: Connection reset by peer] 10:42 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 10:48 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 10:50 -!- c0rw1n is now known as c0rw|afk 10:50 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds] 10:51 < maaku> yay seL4 is on github: https://github.com/seL4/seL4 10:52 -!- zooko_ [~Android@172.56.32.38] has joined #bitcoin-wizards 10:54 -!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has quit [Ping timeout: 256 seconds] 10:54 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] 10:55 -!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has joined #bitcoin-wizards 10:55 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards 10:55 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards 11:00 < kanzure> huh, "The world's first operating-system kernel with an end-to-end proof of implementation correctness and security enforcement is available as open source" 11:00 < kanzure> "Mathematically verified software kernels" http://sel4.systems/Info/Docs/GD-NICTA-whitepaper.pdf 11:03 -!- nullbyte [NSA@gateway/vpn/mullvad/x-omfvwtdkirfpvrcs] has quit [Quit: leaving] 11:04 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards 11:05 < maaku> it's been open source for a little while, but I'm hoping being on github will get some visibility and use 11:05 < maaku> (any hardware wallet authors here, this is what you should be using!) 11:11 < nsh> (mathematics and computers don't work that way) 11:11 -!- zooko_ [~Android@172.56.32.38] has quit [Ping timeout: 250 seconds] 11:13 -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards 11:17 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 11:17 -!- kmels [~kmels@186.64.110.122] has quit [Ping timeout: 256 seconds] 11:18 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards 11:20 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards 11:20 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection] 11:24 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 11:24 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep] 11:24 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards 11:26 < maaku> nsh: it's the closest we can get 11:27 * nsh nods 11:28 < nsh> i don't deride the efforts; it's all grist to the mill. the problem is that people are magnetically drawn to absolutes, in a world where layered and layered and layered imperfect and leaky abstractions underpin any notion of proven absolute mathematical correctness and its projection over actual physical hardware 11:28 < nsh> so the notion of mathematical verification unintentionally connotes things it wouldn't want to 11:29 < maaku> well actually in the microcontroller case I find it plausible that you might be able to achieve real security that way 11:29 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 11:29 < maaku> intel microcode is almost certainly backdoored by TLAs, and undiscovered bugs exist, and the assumptions underlying the proof probably don't match perfectly the ISA... 11:30 < maaku> but with a small, mips microcontroller there's actually a good chance you can get the hardware to work exactly as specified, and as assumed in the security proof 11:34 -!- zooko [~Android@172.56.32.193] has joined #bitcoin-wizards 11:34 -!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has quit [Quit: prom3th3us] 11:34 -!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has joined #bitcoin-wizards 11:34 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.] 11:36 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] 11:36 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards 11:37 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards 11:37 -!- maaku is now known as Guest87378 11:38 -!- zooko [~Android@172.56.32.193] has quit [Ping timeout: 255 seconds] 11:40 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards 11:44 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Quit: bendavenport] 11:45 -!- Iriez [wario@distribution.xbins.org] has quit [Ping timeout: 240 seconds] 11:49 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards 11:50 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.] 11:51 -!- erasmosp_ [~erasmospu@179.43.156.130] has quit [Remote host closed the connection] 11:52 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards 11:53 -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Client Quit] 11:53 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards 11:56 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 12:00 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep] 12:03 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards 12:04 < BlueMatt> Taek: anything that people in this channel would generally consider smart/interesting 12:04 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 12:05 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 12:08 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 255 seconds] 12:10 -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] 12:10 < BlueMatt> also @bitcoin.ninja emails 12:11 -!- Guest87378 is now known as maaku 12:11 < nsh> maaku ( Guest87378 ): you could, surely, *under the abstraction assumptions* between the specified physical operation of the hardware and the microarchitecture logic through to machine code 12:11 < nsh> and that would be a formidable achievement and make a lot of things a lot better 12:12 < nsh> but ultimate, mathematics has precious little to say about the physics, and side-channels and physical subversions exist, manifest, become understood, become applicable to undermine security assurances 12:12 < maaku> Right, well seL4 takes us as far as verifiably correct C code (assuming compiler + physical hardware conform to C standard) 12:13 < maaku> that's a remarkably far way along 12:13 < nsh> indeed 12:14 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Max SendQ exceeded] 12:14 < nsh> so i think a great initative would be to get a foundation for this, some open-hardware where everything can be formalized, proven, audited, right up to the compiler toolchain 12:14 < nsh> and then demonstrate the extent to which a great many of these currently-security-apocalypse-inducing internet-of-toaster devices could be redesigned on a secure basis 12:15 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 12:15 < maaku> agreed. please go do it :) 12:15 < nsh> but that would also require a cultural shift in the way people who make these things view networking 12:15 < nsh> it's on the TODO list :) 12:15 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 12:23 -!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards 12:24 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards 12:28 -!- Madars_ is now known as Madars 12:30 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev] 12:30 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards 12:30 -!- zooko [~Android@172.56.33.230] has joined #bitcoin-wizards 12:31 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep] 12:33 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards 12:34 -!- jinglebellz [~jinglebel@149.130.224.111] has joined #bitcoin-wizards 12:35 -!- zooko [~Android@172.56.33.230] has quit [Ping timeout: 260 seconds] 12:36 -!- jinglebellz [~jinglebel@149.130.224.111] has quit [Remote host closed the connection] 12:38 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has quit [Quit: tbmit] 12:46 < phantomcircuit> runeks, are you Rune Kjær Svendsen ? 12:46 < runeks> phantomcircuit: Yes 12:47 -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep] 12:47 < phantomcircuit> runeks, was my email to the list about full nodes using utxo set commitments clear? 12:48 < runeks> phantomcircuit: I just saw it now. Will read and respond. 12:48 -!- trippysalmon [rob@2001:984:6466:0:cca2:89cf:5e8d:9e38] has quit [Ping timeout: 250 seconds] 12:50 -!- erasmospunk [~erasmospu@179.43.174.66] has joined #bitcoin-wizards 12:50 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Read error: Connection reset by peer] 12:52 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards 13:00 < TD-Linux> maaku, yeah the verifiably correct part is pretty neat. the functionality of seL4 is ultra minimal though 13:03 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] 13:04 < TD-Linux> it's a way to isolate processes, but in a bitcoin wallet there's really not much to isolate, and compromising any of the parts breaks the security of the whole thing 13:06 -!- zooko [~Android@172.56.32.189] has joined #bitcoin-wizards 13:14 -!- zooko [~Android@172.56.32.189] has quit [Ping timeout: 256 seconds] 13:16 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards 13:16 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 13:18 < runeks> phantomcircuit: I've responded :) 13:20 -!- thesnark [~mgrube@unaffiliated/thesnark] has joined #bitcoin-wizards 13:22 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer] 13:24 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 13:24 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 13:25 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 13:31 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer] 13:31 -!- gill3s [~gill3s@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 13:31 < maaku> anyone have a link to greg's original utxo commitment suggestion from way back when? 13:33 -!- thesnark [~mgrube@unaffiliated/thesnark] has quit [Quit: bbl] 13:34 < CodeShark_> can't we solve this attack scenario with sum trees? :) 13:34 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 13:35 < maaku> TD-Linux: yes, but implement network stack, database, etc. as separate processes... 13:35 -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards 13:35 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 13:35 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 13:36 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Client Quit] 13:36 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 13:36 < CodeShark_> committing to the utxo set alone is probably insufficient 13:36 < CodeShark_> we need other partial checks to make this secure 13:38 < CodeShark> bah, wrong handle - committing to the utxo set alone is probably insufficient - we need other partial checks to make this secure 13:40 < CodeShark_> inflation isn't too expensive to check against - but signature validation generally is quite expensive 13:40 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer] 13:41 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 13:41 < maaku> oh wait Rune == runeks? ok you do know prior work here i assume 13:41 < maaku> runeks: I'm curious why you didn't mention using a balanced Merkle tree? 13:42 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection] 13:42 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards 13:43 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Client Quit] 13:44 < runeks> maaku: It's entirely possible that there's a data structure that's superior to a simple UTXO set hash. As long as the added computational requirements are reasonable, a different data structure might be better. I'm really just interested in having *some* fingerprint of the UTXO set be consensus-critical. 13:44 < MRL-Relay> [tacotime] that's quite an old idea, and a softfork if you want to put it in scriptsig 13:45 < CodeShark> it's a frustratingly old idea 13:45 < runeks> And I say consensus-critical because I don't think adding a feature to Bitcoin Core is sufficient. It needs to be a protocol feature in order to be useful. 13:45 < maaku> you wouldn't want it in the scriptSig of the coinbase becuase coinbases are huge 13:45 < bramc> So here's my idea: Instead of a single utxo root, there's a utxo root and a series of deltas off of it, each smaller than the last 13:45 < maaku> best place to put it, if soft-fork compatible, is in the last output of the last transaction 13:46 < maaku> bramc: I think you need to justify that complexity 13:46 < bramc> At scheduled times the utxo root is replaced with the combination of everything which was in the utxo root plus the delta right after it, and the other things move up 13:46 < MRL-Relay> [tacotime] maaku: wouldn't the scriptsig of the coinbase be serialized to the same position in every serialized block? 13:47 < CodeShark> Ideally we'd have a PoW layer that is agnostic to the committed structures to give us great flexibility in designing these structures without relying on stuff like coinbase hacks...but it seems the will and political climate for it just isn't there :( 13:47 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] 13:47 < maaku> tacotime: not the point. proof size is what should be optimized, and coinbases are huge, and path to coinbase (left branches) is on average 2x as long as path-to-last-tx (right branches) 13:47 -!- erasmospunk [~erasmospu@179.43.174.66] has quit [Ping timeout: 240 seconds] 13:47 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 13:48 < maaku> (put it at the end of the transaction for midstate compression hack) 13:48 < MRL-Relay> [tacotime] Oh, I see. 13:49 < runeks> CodeShark: I really wish we could get together and do a complete revision of Bitcoin. We can't keep piling hacks on top of old code on top of proof-of-concepts. 13:49 < CodeShark> Ugh 13:49 < CodeShark> Seriously, right? 13:49 < MRL-Relay> [tacotime] runeks: make your own alt 13:49 < bramc> This gets you a massive boost in performance, because the merging only has to be done quite infrequently and has a long time to do it and is a single linear pass. It's also very easy to specify, because the utxo root and deltas cover very well specified ranges of blocks 13:50 < bramc> The SPV implementation is slightly more complicated because it has to look at deltas, but that comes with benefits as well because those aren't as deep as the full root. 13:51 < maaku> bramc at the cost of making mining inherently stateful forever 13:51 < maaku> delay the utxo commitment by one block so it is out of the validation loop. that's all you need imho... 13:51 < bramc> maaku Huh? It's no different from any other proposal for having utxo roots 13:52 < maaku> bramc: time to validate the root is on the same order of validation work that is already done. 13:52 < runeks> CodeShark: Indeed. I think we have a choice to make. We can either choose to favor the guy who downloaded bitcoin-qt 4 years ago, ran it for a couple of hours, and make sure that if he were ever to start up bitcoin-qt again, it would just work. The other choice is to build a proper protocol, using all the knowledge we've gained in the past half a decade, 13:52 < runeks> which can actually serve as a working payment system. This would break compatibility, yes, but it would actually be a system that we can build on top of. I don't think we can have both infinite backwards compatibility and a proper protocol. 13:52 < maaku> furthermore, by delaying one block you don't have to do it in the tight validation loop before relay 13:52 < maaku> so why have an incremental structure beyond that? 13:52 < bramc> Making the utxo root be one block behind is an interesting idea 13:53 < sipa> runeks: well bitcoin is not a monolith 13:53 < bramc> It's in line with my overall idea that you allow utxo root work to be done in the background 13:53 < maaku> bramc: to be honest I thought that was what you proposed to me at the workshop... 13:53 < runeks> I mean, right now we don't even have a protocol. We have a program (Bitcoin Core). 13:53 < sipa> runeks: significant parts can be changed, or even have multiple parallel parts 13:54 < sipa> runeks: the consensus rules are an exception 13:54 < runeks> sipa: I'm not following. What can be changed? 13:54 < bramc> maaku, It's in line with 'allow the work to be done later', which is what I proposed, although I was thinking more about the bigger updates than the smaller ones 13:54 -!- adam3us [~Adium@172.56.12.182] has joined #bitcoin-wizards 13:54 < CodeShark> runeks: https://github.com/bitcoin/bips/pull/192 13:54 < bramc> Like, rebalancing the whole tree, or in the case of what I just suggested regenerating the whole tree. 13:54 < sipa> runeks: wallets, p2p protocol, implementations, optimization, specifalized block relay algorithms and protocols, ... 13:55 < CodeShark> Comments appreciated :) 13:55 < runeks> sipa: My point is that it's not sufficient to change these. Bitcoin needs to evolve from program to protocol. 13:55 < runeks> CodeShark: I will take a look! 13:55 < sipa> runeks: it is a protocol, with multiple implementations 13:56 < sipa> runeks: the consensus rules are defined by what people's node enforce 13:56 < CodeShark> More direct: https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki 13:56 < sipa> runeks: you won't change that by using a different design 13:56 < CodeShark> unfortunately github is not ideal for commenting on prose 13:57 < bramc> maaku, If you're doing multiple deltas then I *think* that making a last delta just for the current block would be so computationally trivial that it might as well be done, although glomming it into a bigger delta should be put off until the next block 13:57 < maaku> bramc: for separate reasons it is desireable for each block to have it's own delta commitment, so delaying 1 block is actually cleaner 13:57 < sipa> runeks: bitcoin's consensus rules are descriptive, not prescriptive. we can create a document that states what the rules should be, but in the end of the day, if we find a difference between what's on paper and what the network actually runs, it's the paper that will have to change 13:57 < kanzure> maaku: i have many links to utxo commitment proposals, 13:57 < kanzure> for gmaxwell's version, 13:57 < kanzure> https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less 13:57 < kanzure> https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log 13:57 < runeks> sipa: When a bug in Bitcoin Core appears, and we accept this bug as correct behavior (as we did with the database commit failure), Bitcoin Core becomes the protocol, and all alternative implementations become useless. This practice needs to change, in order for alternative implementations to actually be useful. 13:57 < kanzure> https://bitcointalk.org/index.php?topic=314467.0 13:58 -!- urika [~sunflower@50.248.81.66] has joined #bitcoin-wizards 13:58 < sipa> runeks: i fundamentally disagree that we are at a point where we can do that 13:58 < maaku> kanzure: I was going to post them to 'that guy who was suggesting utxo set commitments on the mailing list', but turns out that guy == runeks 13:58 < kanzure> as for utxo commitments in general: 13:58 < kanzure> https://bitcointalk.org/index.php?topic=844944.0 13:58 < kanzure> https://bitcointalk.org/index.php?topic=1048021.0 13:58 < kanzure> https://bitcointalk.org/index.php?topic=1056866.0 13:58 < sipa> runeks: software engineering does not have a means for proving the equivalence between two pieces of software 13:58 < runeks> sipa: When do you think, if ever, we will be able to do that? Is now not better than later? 13:58 < kanzure> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/003921.html 13:59 < sipa> runeks: i think we should refactor bitcoin core's code to have the part that defines the consensus rules separately 13:59 < MRL-Relay> [tacotime] runeks: alternative implementation adoption has always been seemingly against the collective interests of bitcoin core developers, for better or worse 13:59 < sipa> runeks: and then don't touch it anymore unless we want the consensus rules to change 13:59 < bramc> maaku, I think we both just said the exact same thing 13:59 < kanzure> bramc: what sorta utxo commitment update deltas are you thinking of? there has to be some way to verify that the partial-utxo-update is valid and commit to that update i think. 14:00 < maaku> bramc: I don't think we are in disagreement, except perhaps regarding longer window commitments 14:00 -!- gmaxwell is now known as Guest24525 14:00 < sipa> runeks: then anyone can create a full node implementation, as long as they can use the consensus library 14:00 < MRL-Relay> [tacotime] runeks: there's a lot of halfbakery in core from p2p to RPC down to consensus rules, and unfortunately a lot of the latter bitcoin is stuff with. 14:01 < MRL-Relay> [tacotime] and so everyone else is, too. 14:01 < MRL-Relay> [tacotime] s/stuff/stuck 14:01 < runeks> sipa: I think it's possible to define a protocol not after the C++ in Bitcoin Core, but after *intent*. We all know that the Bitcoin Core database commit failure that rejected a block was not intentional. This was clearly not a protocol feature, but a bug in Bitcoin Core. Yet the bug was accepted as correct, and the *correct* implementations (btcd, Haskoin) 14:01 < runeks> were rejected as wrong. We may not be able to define the protocol exactly in code, but we can stop accepting unintentional behavior as correct. 14:01 < maaku> bramc: *regarding the utility, or necessity, or benefit of longer-window commitments 14:01 < kanzure> "Merkle mountain ranges support efficient appends and updates; when a txout is spent the tree is updated, and the updated root is what is committed in the block. Same idea as UTXO commitments, except with a merkle mountain range not only can you can do secure updates, but because it's insertion ordered you can also add new txouts without actually having any of the data in the set. (other than the tips of the trees)" from ... 14:02 < kanzure> ... https://bitcointalk.org/index.php?topic=314467.0 14:02 < sipa> runeks: so what do you do when the implementation differs from the intent? 14:02 < bramc> kanzure, I'm thinking of intervals which go up by squares, starting at 8, so there's one delta of just the last block (per discussion above), followed by one from the last block which was a multiple of 8, followed by one which goes back to the last multiple of 64, followed by one for the previous 64, then one which goes back to the last multiple of 4096, etc. 14:02 < maaku> imho we benefit from *not* doing commitments every 2016 blocks 14:02 < sipa> runeks: you still need a hard fork to fix it 14:02 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 14:03 < CodeShark> we have three serious issues: 1) our current consensus structures are far from optimal for many things we'd like to do, 2) our reference implementation mixes consensus-critical stuff with everythung else, making concerns about difficulty of making changes that can be easily reviewed and tested against the current codebase trump concerns regarding fundamental structural/architectural issues, 3) we have no solid mechanism in pl 14:03 < maaku> kanzure: thanks for the links! 14:03 < bramc> kanzure, I *think* the merkle mountain range proposal has a different approach to rebalancing, but I'm not sure 14:03 < sipa> runeks: adding more different consensus implementations into the mix just increases the chance for randomly ending up with disagreements 14:03 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 250 seconds] 14:03 < CodeShark> 3) we have no solid mechanism in place for consensus-critical changes 14:03 < runeks> sipa: We don't need to fix hard forks. Hard forks are a disagreement in the network. Miners need to fix it, because they lose money if they don't. 14:03 < sipa> CodeShark: 3) is called politics 14:03 < kanzure> maaku: can you elaborate on delaying one block for utxo commitments? why does it matter that it's a commitment of the state as of the previous block and not the current block? 14:03 < CodeShark> (2) and (3) are far more serious problems than (1) 14:03 < sipa> runeks: miners can't fix it 14:04 < sipa> runeks: what if two implementations are incompatible in a mutual way? 14:04 < runeks> sipa: We should never temporarily alter the protocol rules just to solve a hard fork. This creates uncertainty, and instability. 14:04 < Taek> kanzure: if you are committing to the current block, you have to rebuild the the commitment every time you change which set of transactions you are mining 14:04 < sipa> the protocol rules are defined by what people run 14:04 < bramc> The thing I'm proposing has no rebalancing ever, except for when it redoes everything from scratch. The benefit of this is that it's brainless and reliable to implement and highly efficient in terms of storage space used. 14:04 < runeks> sipa: Unless we recognize that the protocol is faulty. 14:04 < kanzure> just as random reminder, merkle mountain range stuff is https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md and https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py 14:05 < CodeShark> (2) is at least semi-tractable right now 14:05 < kanzure> Taek: i don't think you have to always rebuild the entire utxo tree if you are doing the partial updates via deltas, so building it for previous/current block shouldn't matter here 14:05 -!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-wizards [] 14:05 < maaku> kanzure: you've just received a full block. you've now validated its transactions. now before doing the relay you need to check the commitment -- which involves committing the changes to the utxo and rebuilding the root hash 14:05 < maaku> you need to do that before you relay the block, because maybe the commitment is wrong 14:05 < kanzure> right, commitment needs to be checked even if it was for the last block though 14:06 < runeks> sipa: Two incompatible implementations means that either *one* of them is wrong or both are wrong. The wrong implementation(s) need fixing, that's all. 14:06 < CodeShark> runeks: you either do one or three :) 14:06 < CodeShark> Never two 14:06 -!- zwick [~zwick@fsf/member/zwick] has quit [Quit: WeeChat 1.3] 14:06 < maaku> right, so if on the other hand block 101 has a commitment to the utxo state after validating the previous block, #100, then the utxo tree update can happen after the block 100 is validated and relayed along 14:07 < MRL-Relay> [tacotime] kanzure: for mmr i'm interested in seeing what insertion/delete actually costs when you have the whole exponentially rising bitcoin utxo set. it may end up prohibitively expensive, even at log(n) insertion/deletion. 14:07 < kanzure> okay but in both cases you are still doing utxo update verification/delta work stuff. 14:07 < maaku> right, it's just not in the receive, validate, relay loop 14:08 < CodeShark> kanzure: is there any way I can help you in archiving good material and reorganizing it? 14:08 < bramc> kanzure, Yeah merkle mountain ranges do stuff where they make a new tree point to a branch of an old tree. What I'm proposing doesn't do that 14:08 < kanzure> CodeShark: writing summaries of certain broad ranges of ideas; will be giant wiki page with 20-30 different topics that are summarized with links to historical work and current work. 14:09 < bramc> kanzure, maaku One big benefit of using deltas and merging them together is that the actual merge operation between two sorted lists is extremely efficient, so long as you don't have to do it too often. 14:09 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Quit: Leaving.] 14:09 < kanzure> CodeShark: starting from k-means best categories of http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-selected-bookmarks.2015-09-09.txt or http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-selected-bookmarks.2015-09-09.yaml 14:09 < maaku> tacotime: utxo growth isn't exponential in the limit 14:09 < bramc> Like, it's much faster for the last block than the sorting operation is. 14:09 < maaku> bramc: the disadvantage is that you have to actually store and keep around those lists :P 14:09 < kanzure> maaku: it's still in the loop; if it's wrong, you can't relay the current block. 14:09 < CodeShark> wonderful! I look forward to that. If you need any help writing anything let me know. We need to do better than bitcointalk and botbot links 14:09 < kanzure> you shouldn't relay bad blocks 14:10 < kanzure> CodeShark: yes, making up some summaries would be extremely helpful... like doing a short summary of coinjoin/coinshuffle/privacy/mixing stuff would be a good place to start. 14:10 < helo> does utxo growth scale with exchange value "in the limit"? 14:10 < kanzure> CodeShark: (such a summary would in theory always mention private information retrieval stuff, too) 14:10 < bramc> maaku, They aren't very big, it's mostly the one huge list of everything back to the last multiple of 4096, everything else is tiny by comparison, and that big one is stored in a completely non-fragmented compact data structure which can be easily looked into 14:10 < maaku> kanzure: you'll already know the commitment that should be there because you calculated it from the last block 14:11 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards 14:11 < kanzure> maaku: ok, so it's still there in that block, it's just using some precomputation since the last block was received and validated. 14:11 < maaku> so receive a block, validate it, relay it, update utxo hash, <...wait..> receive new block, validate including checking <--- prior hash, relay , etc. 14:11 < maaku> right 14:11 < kanzure> i mean, it's still there in that loop, but can use some cached precomputation for superfast verificatio nkthx 14:11 < bramc> One advantage of using the squaring base of 8 is that the block size after 4096 is 16777216, which corresponds to about 300 years, so for all practical purposes it's a fixed number of deltas. 14:12 < bramc> kanzure, Right, I'm proposing doing the same trick in the large for the utxo root as a whole 14:13 < maaku> bramc: btw you should look at mmr's for inseration-ordered full-txout commitments 14:14 < kanzure> man i'd really like to skip straight to "wallets carry utxos and utxo proofs, miners just make giant merkle roots and proofs for updating the authorized data structure (merkle tree of some special kind), undisclosed unknown set of transactions aren't tracked by blocks" 14:14 < maaku> it's not obvious (to me) which is better, utxo, txo, or stxo 14:14 < maaku> we really need competing proposals to test 14:14 < kanzure> bramc was quite adamant about stxo being useless 14:14 < bramc> maaku, I'm thinking a flat merkle tree of fixed depth 14:14 < kanzure> wait i'm not allowed to say that 14:14 < CodeShark> I still hold that fixing (2) and (3) are far more critical right now 14:14 < kanzure> SOMEONE had good reasons for not doing stxo 14:14 < bramc> What is stxo? 14:14 < kanzure> spent transaction outputs 14:14 < maaku> bramc: that requires a full node to have the full UTXO set 14:14 < CodeShark> Fixing (1) depends on (2) and (3) 14:15 < kanzure> "insertion-STXO proofs might be more bandwidth-friendly" 14:15 < kanzure> from page 22 http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-review.pdf 14:15 < bramc> maaku, How can a node be 'full' if it doesn't have the full utxo set? 14:15 < maaku> it is a very cool property of bitcoin that (with utxo, txo, or stxo commitments) that you can run a full node _without any state_ so long as proofs are provided 14:15 < bramc> Oh, stxo is spent transaction outputs. Yeah remembering those is pointless. 14:16 < maaku> *proofs that are less than the size of the UTXO set 14:16 < kanzure> yes, there's a few proposals about having a storageless full-node using various utxo commitments and update proofs or something 14:16 < kanzure> none of which are very fleshed out proposals 14:16 < maaku> but in principle they work 14:16 < kanzure> oops not storageless, just constant-storage-size and still fully-validating 14:16 -!- xabbix [~xabbix@bzq-79-179-133-122.red.bezeqint.net] has joined #bitcoin-wizards 14:16 -!- xabbix [~xabbix@bzq-79-179-133-122.red.bezeqint.net] has quit [Changing host] 14:16 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-wizards 14:17 < bramc> I don't see how stxo is every smaller than utxo. The number of stxos is several times as much. 14:17 < maaku> if you do something like flat merkle trees, or runeks's straight serialize the utxoset, or an infinite set of deltas, then in principle you can never get away from holding the utxo set 14:17 < kanzure> wasn't this the flip-the-chain idea 14:17 < maaku> kanzure: yes 14:17 < kanzure> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001550.html 14:18 < kanzure> "with txout+txid indexing (for the 'flip the chain' proposals)" 14:18 < maaku> kanzure: when your storage size (32-bytes) is less than your working space, I consider that storageless ;) 14:18 < kanzure> flip the chain: https://bitcointalk.org/index.php?topic=505.0 https://bitcointalk.org/index.php?topic=21995.0 https://en.bitcoin.it/wiki/User:DiThi/MTUT#PROPOSAL:_Merkle_tree_of_unspent_transactions_.28MTUT.29.2C_for_serverless_thin_clients_and_self-verifiable_prunned_blockchain. https://bitcointalk.org/index.php?topic=88208.0 14:18 < bramc> I don't understand what the counterfactual is. To answer the question of whether something is in the utxo set you need to have the utxo set. 14:19 < maaku> bramc: imagine blocks and transactions come with proofs extracted from the merkle utxo tree 14:19 < maaku> and that a structure is chosen such that the proof itself is the update to the tree, and that these deltas can be combined together without information in that tree, etc... 14:20 < bramc> maaku, Oh I see. Or I mostly see. I don't follow about the proof itself being the update to the tree. That sounds like complicated data structur fu 14:20 < kanzure> there might be a way to do that without snarks 14:20 < maaku> bramc: it works trivially with patricia tries (one of the proposals), so that might be a place to start 14:21 < bramc> maaku, A proof of validity of block can be included with it, but it seems more flexible for that to be included along side it in the network protocol rather than being embedded within it. 14:21 < maaku> kanzure: snarks aren't necessary. the merklized patricia trie of utxos indexed by txid:n works for this 14:22 < kanzure> maaku: with update proofs? 14:22 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Remote host closed the connection] 14:22 < maaku> kanzure: snarks let you get a constant storage, constant workspace, constant time validator though, which is friggin awesome 14:22 < maaku> kanzure: yes 14:22 < maaku> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/003921.html 14:22 < maaku> which you posted earlier 14:22 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards 14:23 < maaku> actually the email is out of date, here is better: https://gist.github.com/maaku/2aed2cb628024800044d 14:23 < maaku> still out of date, but i'll fix that soon 14:23 < kanzure> how is out of date? 14:23 < kanzure> i mean the gist 14:24 < maaku> better efficiencies & optimizations, simplifications of the data structure, etc. have been developed since the draft bip was last updated, just haven't had time to go back and update the document 14:24 -!- CodeShark is now known as CodeShark__ 14:24 < maaku> mostly just tricks to reduce the number of compression rounds, make the structure easier to parse within a snark prover, etc. 14:24 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 14:24 < maaku> in large the proposal is the same 14:25 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards 14:25 < kanzure> so verification can be done without a full utxo set constructed from the blockchain? 14:25 < bramc> You can straightforwardly do a proof of the validity of a block based off the utxo commitment in the previous block 14:26 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards 14:26 < CodeShark> I'd rather see some of these bips less focused on implementation and more focused on architecture ;) 14:26 < bramc> The proof is larger than the block though. 14:26 < kanzure> i believe bip1 asks for implementation details in bips 14:26 < maaku> the verifier doesn't need a full utxo set. they just need a merkle proof of all the inputs spent in the block, whose root matches the commitment in the last block, and a delta of all the outputs added in the block 14:26 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 14:26 < maaku> bramc: proof is smaller than the utxo though 14:26 < maaku> *utxo set 14:27 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Ping timeout: 246 seconds] 14:27 < CodeShark> I'd like to move away from a culture where everything is always specified in implementations and instead focus on other formal specification mechanisms and ways to demonstrate that a particular implementation satisfies correct behavior...but meh... :p 14:27 < bramc> maaku, I think this property holds for all utxo commitment proposals 14:27 < kanzure> i am also confused about what sort of attributes we're missing without snarks with this sort of proposal 14:27 < kanzure> or which attributes we're preserving that i might be accidentally attributing to snarks already 14:27 < Taek> CodeShark: by the time it's a bip, it's supposed to be an implementation. If you're just talking architecture it's probably not ready to be a bip. (my interpretation anyway) 14:27 < bramc> CodeShark sometimes the most concise way to specify something is with an implementation. 14:28 < CodeShark> I'm not opposed to also requiring implementations - don't get me wrong 14:28 < kanzure> bramc: case in point, the amount of time to explain lightning network has been more than the time necessary to do all of the existing implementation so far 14:28 -!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has joined #bitcoin-wizards 14:28 -!- orik [~orik@50.125.71.245] has quit [Client Quit] 14:28 < maaku> CodeShark: we would all like to do that for everything except the consensus code 14:28 < CodeShark> I just feel like the focus is too much on how to make modifications that require the fewest changes to source code rather than modifications that better serve the platform 14:29 < maaku> e.g. payment protocol is specified by bips 70-72. if the qt wallet differes in behavior, it is a bug and the qt wallet should be fixed 14:29 < maaku> not so for consensus code 14:29 < kanzure> maaku: so i think the deltas have non-constant size, and verification or proof might also be non-constant-time, and theoretically if we snarkify everything then we can get back to very-nearly-constant runtimes and memory costs. ya? 14:29 < bramc> Consensus behaviors you're basically stuck with, unfortunately. 14:30 < maaku> kanzure: yes 14:30 < CodeShark> maaku: IMHO, if a particular wallet differs from BIP70-72 who cares as long as it works...and if it turns out to be a better behavior than BIP70-72, let that one be the standard :) 14:30 < maaku> the 'storageless' part of a utxo-proof-streeming validator is the utxo storage. it has non-constant RAM requirements to validate a block 14:31 < kanzure> (streaming?) 14:31 < maaku> it's storage is just the last utxo commitment plus a few other misc things like block height 14:31 < CodeShark> BIPs like 70 depend FAR more on widespread adoption to become "official" than on being a BIP 14:31 -!- Guest24525 is now known as gmaxwell 14:32 < CodeShark> moreover, there's room for several different competing approaches without breaking the network 14:32 < maaku> kanzure: you could build a machine that took as input blocks prefixed with their utxo delta proofs (showing all the inputs, and paths to where the outputs need to go), and it only internally carries forward the utxo set root (+ block height, hash of last block, timestamps of last 11 blocks, current difficulty, etc.) 14:33 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] 14:33 < maaku> this is the idea of a constant-storage streaming validator 14:34 < maaku> you can even have mining nodes that behave this way: prefix transactions with their own utxo delta showing inputs and location for outputs 14:35 < maaku> and rebase each proof using the delta of the block after it is found 14:35 < kanzure> ah okay, then i am somewhat thinking of ways of getting rid of transactions with this scheme- which either requires at least zero knowledge proofs, or snarks, like the "zero knowledge proof of authorized utxo modification" proposal on page 46 http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-review.pdf 14:36 < kanzure> ah i like the rebase terminology, is easy to grok 14:36 < maaku> does this make sense to do? ... maybe ... not with current utxo sizes. but it would be kinda nice to not block off entirely this possibility by adopting a utxo commitment scheme that doesn't have these properties 14:36 < bramc> maaku, Why do you want to include the proofs inline in the block chain? They can just as easily be supplied 'on the side' 14:37 < bramc> maaku, And how could anything block off these properties? Utxo commitments by their nature make it possible to prove whether transactions are valid or not. 14:37 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 14:37 < kanzure> maaku: yes it would be good to check future ideas and make sure we don't shoot ourselves in the foot, although not bend over completely backwards for somewhat-impossible-at-the-moment ideas 14:37 < maaku> kanzure: right, snarks then removes the need for the validator to handle the proofs at all. but the miner would still need them (as input into the snark prover) 14:39 < maaku> bramc: not inline in the block chain, they're not part of the block merkle structure. rather I was meaning that they would be part of the network protocol 14:39 < maaku> if you broadcast a transaction or a block, it needs to come with a delta proof in this future hypothetical bitcoin p2p network 14:39 -!- orik [~orik@50.125.71.245] has quit [Client Quit] 14:39 < bramc> maaku, I don't follow why this can't be done with any utxo commitment scheme 14:40 < CodeShark> think git...except enforce rules regarding how files can change...and require a PoW timestamp for each commitment :) 14:41 < CodeShark> then optimize the crap out of it 14:41 -!- Starduster [~guest@unaffiliated/starduster] has quit [] 14:42 -!- adam3us [~Adium@172.56.12.182] has quit [Quit: Leaving.] 14:43 < CodeShark> once we completely decouple the commitment structure from the transport layer, then we can talk about using ssh vs. https vs. sftp vs. blah 14:43 < CodeShark> eventually some routable protocol, hopefully 14:44 < maaku> bramc: it can so long as the proofs carry enough information to ensure that a rebuild of the root value of the tree can occur from the information in the proof only 14:44 < maaku> bramc: take a 4-leaf balanced binary tree, for example, and remove the lestmost leaf 14:45 < maaku> the other leafs "shift over" if you are doing a straight bitcoin-like merkle tree 14:45 < maaku> and you need to know the leaf nodes in order to calculate the new structure 14:45 -!- adam3us [~Adium@172.56.12.182] has joined #bitcoin-wizards 14:46 < bramc> maaku, Oh I see now. I'll have to think about that. 14:48 < maaku> kanzure: in particular the gist uses 28-byte hashes with the intent of combining two hashes in a single compression round 14:48 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 14:48 -!- orik [~orik@50.125.71.245] has quit [Client Quit] 14:48 < maaku> turns out SHA2 padding is fucking stupid and that doesn't work, despite being the whole point of SHA224 existing as far as I can tell 14:49 < maaku> yay standards that were never actually used for their intended purpose before becoming standards 14:50 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 14:52 < prom3th3us> Pardon me if this has been asked here before, but is there a particular consensus here on sidechains? I’m reading up on them and they sound like they have some neat use cases that extend the blockchain. 14:52 < bramc> maaku, I think I see the point about stxo commitments being more convenient now. It should be possible to do that type of tree for utxo commitments too though, it just requires a lot more care 14:53 < kanzure> prom3th3us: useful for experimentation for risky things that might destroy bitcoin mainnet blockchain 14:53 < maaku> bramc: well, a patricia tree does that for utxo commitments 14:53 < maaku> (see the linked gist above) 14:54 < maaku> but if you do go down this route of prefixed proofs, then txo / stxo may result in smaller proofs... hence the interest in them 14:54 < bramc> maaku, I think with my proposed series of deltas approach the same constant space thing can be done but the utxo updating has to be demonstrated in an amortized way, same as how it's calculated. Does require going through the whole utxo set every 4096 blocks though. 14:54 < prom3th3us> kanzure: Can you expand on that a bit? I haven’t heard that perspective before. 14:54 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 14:54 -!- orik [~orik@50.125.71.245] has quit [Client Quit] 14:54 < bramc> maaku, The downside of a patricia tree is that it's a big mess to maintain 14:57 -!- Guest68337 [~audioishi@blackmain.media.mit.edu] has joined #bitcoin-wizards 14:58 -!- Starduster [~sd@unaffiliated/starduster] has joined #bitcoin-wizards 14:58 < bramc> Come to think of it, my deltas idea could be done with patricia trees just fine 14:58 -!- Guest68337 [~audioishi@blackmain.media.mit.edu] has quit [Client Quit] 14:58 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 14:58 -!- adam3us [~Adium@172.56.12.182] has quit [Read error: Connection reset by peer] 14:59 < bramc> Or at least something which has the property you describe, not 100% sure if my understanding of patricia trees is correct. 15:00 -!- cholbrow [~cholbrow@blackmain.media.mit.edu] has joined #bitcoin-wizards 15:01 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 15:02 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 15:02 -!- orik [~orik@50.125.71.245] has quit [Client Quit] 15:03 < CodeShark> why is a patricia tree a big mess to maintain? 15:03 < bramc> CodeShark if you're maintaining it incrementally it frags memory like nobody's business 15:04 < CodeShark> can't you reallocate every once in a while to reclaim memory? 15:04 -!- adam3us [~Adium@172.56.12.182] has joined #bitcoin-wizards 15:05 -!- bsm1175321 [~bsm117532@38.121.165.30] has quit [Ping timeout: 268 seconds] 15:05 < bramc> the effectiveness of that is heavily dependent on how much updating you're doing 15:05 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:05 < bramc> I assume by 'reallocate' you mean re-sweep and consolidate 15:05 < CodeShark> yes 15:06 -!- kang_ [67efe97d@gateway/web/freenode/ip.103.239.233.125] has joined #bitcoin-wizards 15:07 < CodeShark> as opposed to? 15:07 < bramc> What I proposed involves doing the consolidating and re-sweeping at fixed times. No reason a constant size only thing couldn't keep the ongoing roots as well, although it's having to do several of them which makes things a little more complicated 15:08 < CodeShark> good implementations that are efficient with resources are clearly nontrivial...but seem doable and seem to be something that could be well encapsulated 15:08 < bramc> So I'm sold on patricia trees, because they make zero difference in time to do consolidations, but I'm not sure about all that walking the tree 15:09 < bramc> the log(n) multiplier on doing everything kind of sucks 15:09 < bramc> having to walk the tree for each transaction is a nontrivial expense 15:10 < bramc> But we're all in agreement about having the big tree be a block behind 15:10 -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards 15:10 < CodeShark> yeah, nothing is free..but I think the tradeoffs can be made acceptable 15:11 -!- orik [~orik@50.125.71.245] has quit [Client Quit] 15:11 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-zmgjkdbnjacdovzo] has joined #bitcoin-wizards 15:11 < CodeShark> in any case we're trading something off - right now, we're basically sacrificing thin client security ;) 15:12 < CodeShark> I'd be more than happy to pay someone a small amount for that log(n) overhead if it means I can validate with a high level of privacy and security from my mobile devices 15:13 < CodeShark> right now I don't really even have that option - I basically have to run a full node 15:14 < CodeShark> it sucks...but in principle it seems to be amenable to division of labor and economies of scale 15:14 -!- JackH [~Jack@host-80-43-143-151.as13285.net] has quit [Ping timeout: 240 seconds] 15:16 -!- zooko_ [~Android@2607:fb90:21cf:f2fb:acf6:4194:1dc7:ca7f] has joined #bitcoin-wizards 15:16 -!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has quit [Ping timeout: 268 seconds] 15:17 < CodeShark> and I also think that such incentives could be offered in ways that promote decentralization 15:17 -!- zooko [~Android@75.111.103.164] has joined #bitcoin-wizards 15:18 -!- shen_noe [~shen_noe@104.156.228.98] has joined #bitcoin-wizards 15:19 -!- shen_noe [~shen_noe@104.156.228.98] has quit [Client Quit] 15:20 -!- zooko_ [~Android@2607:fb90:21cf:f2fb:acf6:4194:1dc7:ca7f] has quit [Ping timeout: 252 seconds] 15:22 < CodeShark> although the decentralization/economy of scale thing can be a bit of a tradeoff in some instances, perhaps 15:22 < CodeShark> ASICs are an obvious example 15:22 -!- zooko [~Android@75.111.103.164] has quit [Ping timeout: 268 seconds] 15:23 -!- zooko [~Android@75.111.103.164] has joined #bitcoin-wizards 15:24 < bramc> CodeShark in my proposal the log(n) to thin clients is hardly any computation because it's almost always pulled out of stuff which is kept hot 15:24 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 15:25 < bramc> It's a tradeoff with patricia trees which are updated every time in that the total I/O and maybe cpu is a lot less with the tradeoff that future verification-only clients have to do more work 15:27 < bramc> Basically they have 3x the work because they're updating 3 deltas instead of a single root 15:28 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards 15:29 < CodeShark> Right - then there's the implementation difficulty for thin clients, which ideally should be low. This means either making the verification algorithms inherently simple...or publishing good libraries for it 15:29 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards 15:30 < CodeShark> I'm actually more concerned about implementation difficulty and long-term source code maintenance than I am about log(n) or constant factor costs 15:30 < MRL-Relay> [tacotime] implementation difficulty generally sucks 15:31 < bramc> Verification for patricia trees is fairly brainless. 15:31 < CodeShark> yes, so that's a big plus 15:31 < MRL-Relay> [tacotime] because you need to create a patch structure for the tree if you're going to evaluate any blocks that are forking the mainchain 15:31 < bramc> They're basically the same as flat fixed-depth in terms of complexity 15:32 < bramc> tacotime, I'm perfectly happy to dump complexity of fixed-size storage onto later implementers, because that's an inherently complicated thing to do 15:32 < MRL-Relay> [tacotime] in terms of the actual tree structure and algorithms defining it, yes, that's well characterized already 15:32 < bramc> Having to do it multiple times won't substantially change its complexity from doing it once 15:33 < CodeShark> right - the other important thing to consider is that as long as in theory there are significant optimizations in the implementation and there are incentives for people to look for optimizing them, these things will tend to occur as needed 15:33 < CodeShark> we don't need to dictate top down how everything is implemented 15:34 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Ping timeout: 250 seconds] 15:34 < bramc> If the utxo commitment is based on deltas then the checkpoints of them need to be set in advance 15:34 < CodeShark> if we start to reach a scalability wall with a log(n) factor it means either the network is being attacked...or the network is succeeding :) 15:35 < CodeShark> and if the incentives are there people will look for further optimizations 15:36 < bramc> Doing an update of a delta has the appealing property that you can run a brainless linear scan instead of walking the tree per transaction. If the update is large enough it can be vastly faster even in the asymptotic, on top of being brainless to implement 15:36 -!- kmels [~kmels@186.64.110.122] has quit [Ping timeout: 246 seconds] 15:38 < MRL-Relay> [tacotime] if the delta is long enough in the past (hours), you probably don't have to worry about reorganizations at all 15:39 < MRL-Relay> [tacotime] if you're using delta to refer to committing to past utxo roots 15:39 < MRL-Relay> [tacotime] (or whole set hashes, whatever) 15:39 < CodeShark> you set a cutoff for the committed delta to be 100 blocks in the past or something 15:39 < CodeShark> and maintain a delta for all recent activity, right 15:39 < CodeShark> ? 15:39 < MRL-Relay> [tacotime] oh, i see 15:40 < MRL-Relay> [tacotime] well, i think the first step would just be the including the utxo set from a past perspective then 15:40 < MRL-Relay> [tacotime] worry about hashes of the deltas (updates to it) later 15:40 < MRL-Relay> [tacotime] and by that i mean, other people can implement that later if they thinks it's useful, if i'm following the logic here correctly 15:42 -!- Starduster [~sd@unaffiliated/starduster] has quit [] 15:42 < CodeShark> I'm still not totally clear on why consolidating in batch is more efficient than doing it continuously 15:42 < MRL-Relay> [tacotime] doing that is a lot less of a commitment (har) in terms of implementing a new consensus rule than say, rolling utxo sets per block or this scheme with deltas 15:43 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 15:43 < CodeShark> I sorta do get why...but I have to think about this a little more 15:43 < MRL-Relay> [tacotime] but other than that i don't see an advantage 15:45 -!- eudoxia [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 15:49 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 15:53 -!- zooko [~Android@75.111.103.164] has quit [Ping timeout: 255 seconds] 15:54 -!- memymo [~textual@c-24-4-69-49.hsd1.ca.comcast.net] has joined #bitcoin-wizards 15:58 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards 15:58 -!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has joined #bitcoin-wizards 16:04 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 16:05 -!- maraoz [~maraoz@50.247.108.204] has quit [Ping timeout: 256 seconds] 16:09 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 260 seconds] 16:11 < bramc> sorry was afk. The idea with deltas is that there are deltas of size 8 blocks, which get consolidated into deltas of size 64 blocks, which get consolidated into deltas of size 4096 blocks 16:12 < bramc> It's faster to do an operation on a delta because it's a linear pass merging two sorted sets, which can be done extremely quickly. 16:13 < bramc> This particularly matters on a device which has to hold the utxo set on disk 16:16 < bramc> The downside, of course, is that you need to do a whole linear pass. The crossover is when the size of the update is 1/log(n) times some constant factor. The constant factor is rather favorable to the batch operation though because of the highly localized memory accesses. 16:17 < bramc> codeshark, did that make sense? 16:17 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards 16:17 < CodeShark> I think so 16:20 < CodeShark> so you're sacrificing short-term prunability for local memory operations? 16:21 -!- maraoz [~maraoz@2601:647:4b02:94f1:fcbf:3b81:c02b:4303] has joined #bitcoin-wizards 16:22 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection] 16:23 < bramc> That's part of the tradeoff. You're keeping more stuff around (not a lot more data, but organized in a way which under *some* usage requires bandwidth, in others less) and you're getting performance which is less operations if the updates are big enough but more operations if the number of updates is small. 16:24 -!- eudoxia [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 16:25 < bramc> Come to think of it, you can always do better on the batch operation, because you can share the walking down work across the whole batch 16:25 < bramc> You don't *have* to do a linear pass, it's just the most brainless approach. 16:26 < CodeShark> ah! 16:26 < CodeShark> of course...in batch you only need to traverse each branch once! 16:27 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds] 16:28 < maaku> and you don't have to recalculate the inner node hashes between updates 16:28 < CodeShark> yep 16:28 < maaku> i don't dispute that it is an efficiency gain to commit less frequently than every block 16:28 < maaku> but i don't think it is worth it 16:28 < maaku> however, I don't see the need to have larger deltas 16:29 < maaku> if you are committing every 8 blocks, the 64 or 4096 block deltas seem pointless to me 16:29 < bramc> maaku, The idea is to make the brainless linear approach be fairly efficient 16:29 < bramc> Because it's amortized over a longer time period 16:30 < maaku> bramc: but if you are committing every 8th block, then it's not amortized at all. you're doing updates every 8th block, and then every 64th block you do those updates again 16:32 < bramc> The batching is done at each level - you aren't updating the whole tree every 8th block, you're only batching up the last 8 things every 8th, and the 8ths are batched until you hit the 64th, and the 64ths are batched until you hit 4096 16:32 -!- zooko_ [~Android@2607:fb90:2192:df4c:18ff:788c:43c9:c773] has joined #bitcoin-wizards 16:33 < bramc> So you're always merging together things of roughly similar size in your batch operations. It could be done at a factor of 2 and be a clear win in terms of computational efficiency, but that's a whole lot of deltas. 16:34 -!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has quit [Ping timeout: 240 seconds] 16:34 < maaku> so what is the commitment in a block? 16:34 < maaku> are you committing to the utxo root hash? only committing every 8th block? 16:37 < maaku> kanzure bramc: acutally you may need to delay 2 blocks so you can start mining immediately too 16:37 < bramc> You're committing to a list of things (possibly merkleized as well for efficiency, but let's say it's a list): A root of everything at the last utxo which was a multiple of 4096, a root of the delta from that at the last multiple of 64, a root of the delta from that at the last multiple of 8, a root of the delta from that to the last one 16:37 < bramc> I think I have an off by one in a few places there to allow things to get calculated after the fact, but that's the general idea. 16:38 < bramc> I woke up too early this morning to get the fenceposts correct. 16:38 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards 16:42 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 16:43 < CodeShark> what does the brainless linear approach really buy you? don't you have to do more complex tree operations at some point anyhow? 16:44 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection] 16:45 < CodeShark> I understand why you want to merge trees of equal size in batch - not entirely clear why the linear approach simplifies implementation as a whole 16:45 -!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards 16:47 -!- memymo [~textual@c-24-4-69-49.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 16:50 < bramc> No more complex operations necessary - A patricia tree can be hashed left to right no problem. 16:51 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards 16:51 < bramc> So there's no memory management to speak of, it's just running straight through 16:51 -!- bliljerk_ [~bliljerk1@pool-74-109-193-20.pitbpa.fios.verizon.net] has quit [Read error: Connection reset by peer] 16:54 -!- jinglebellz [~jinglebel@149.130.222.229] has quit [Remote host closed the connection] 16:54 -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] 16:58 -!- adam3us [~Adium@172.56.12.182] has quit [Quit: Leaving.] 17:02 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 17:02 -!- rando1 [126f4f55@gateway/web/freenode/ip.18.111.79.85] has joined #bitcoin-wizards 17:04 < CodeShark> but eventually you need to merge a tree into a much larger tree that could be gigabytes in size, no? 17:04 < CodeShark> so you're saying that this entire structure would be stored contiguously in RAM? 17:05 -!- _2drewlee [~textual@104.220.67.131] has joined #bitcoin-wizards 17:11 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:12 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Ping timeout: 240 seconds] 17:13 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards 17:15 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 17:17 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 17:19 -!- _2drewlee [~textual@104.220.67.131] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 17:20 -!- zooko_ [~Android@2607:fb90:2192:df4c:18ff:788c:43c9:c773] has quit [Ping timeout: 246 seconds] 17:25 -!- Guest10 [~textual@104.220.67.131] has joined #bitcoin-wizards 17:25 -!- rando1 [126f4f55@gateway/web/freenode/ip.18.111.79.85] has quit [Ping timeout: 246 seconds] 17:32 -!- lnovy [~lnovy@2002:4d57:f055::1] has quit [Quit: Got root?] 17:32 -!- lnovy [~lnovy@2002:4d57:f055::1] has joined #bitcoin-wizards 17:36 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] 17:38 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 17:40 -!- Guest10 [~textual@104.220.67.131] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 17:44 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards 17:49 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Ping timeout: 256 seconds] 17:52 -!- maraoz [~maraoz@2601:647:4b02:94f1:fcbf:3b81:c02b:4303] has quit [Ping timeout: 240 seconds] 17:53 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds] 17:53 -!- c0rw|afk is now known as c0rw1n 17:54 < kang_> Bitcoin over Tor isn't a good idea (http://arxiv.org/abs/1410.6079) 17:55 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-zmgjkdbnjacdovzo] has quit [Quit: Connection closed for inactivity] 17:56 -!- zooko [~Android@172.56.38.127] has joined #bitcoin-wizards 17:59 -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] 18:07 -!- CodeShark__ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds] 18:08 -!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has quit [Quit: prom3th3us] 18:19 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 18:21 -!- Guest10 [~textual@104.220.67.131] has joined #bitcoin-wizards 18:22 -!- Guest10 [~textual@104.220.67.131] has quit [Client Quit] 18:33 < ryan-c> a long time ago, i ran a tor exit node and found that people were using it to connect to mining pools 18:33 < ryan-c> i could have hijacked their work units because it wasn't ssl 18:40 -!- adlai [~adlai@unaffiliated/adlai] has joined #bitcoin-wizards 18:53 -!- zooko [~Android@172.56.38.127] has quit [Ping timeout: 272 seconds] 18:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-sddcogyfxenrtztb] has quit [Quit: Connection closed for inactivity] 18:55 -!- adam3us [~Adium@172.56.6.44] has joined #bitcoin-wizards 18:56 -!- Guest10 [~textual@104.220.67.131] has joined #bitcoin-wizards 19:00 -!- tkiel [~tkiel@ip68-231-91-194.ph.ph.cox.net] has joined #bitcoin-wizards 19:00 -!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has joined #bitcoin-wizards 19:00 -!- bigreddmachine [~bigreddma@c-67-176-94-89.hsd1.co.comcast.net] has joined #bitcoin-wizards 19:01 -!- Guest10 [~textual@104.220.67.131] has quit [Ping timeout: 240 seconds] 19:05 -!- adam3us [~Adium@172.56.6.44] has quit [Quit: Leaving.] 19:05 -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards 19:07 < bramc> codeshark, the whole thing is the size of the utxo set stored compactly, so it should be possible to keep it in ram, and even on a device which needs to keep it on disk, it's well set up for efficient lookups and the pass through can be done with a straightforward linear access pattern. 19:10 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 19:14 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] 19:15 -!- adam3us [~Adium@172.56.12.164] has joined #bitcoin-wizards 19:18 -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] 19:27 -!- adam3us [~Adium@172.56.12.164] has quit [Ping timeout: 260 seconds] 19:28 -!- adam3us [~Adium@172.56.12.164] has joined #bitcoin-wizards 19:33 -!- adam3us [~Adium@172.56.12.164] has quit [Ping timeout: 264 seconds] 19:42 -!- agorecki [~agorecki@unaffiliated/agorecki] has joined #bitcoin-wizards 19:44 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards 19:49 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Ping timeout: 250 seconds] 19:51 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards 19:51 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 240 seconds] 19:53 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards 19:54 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards 19:55 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Ping timeout: 240 seconds] 19:58 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards 19:59 -!- bliljerk101 [~bliljerk1@pool-74-109-193-20.pitbpa.fios.verizon.net] has joined #bitcoin-wizards 20:00 -!- agorecki [~agorecki@unaffiliated/agorecki] has quit [Remote host closed the connection] 20:01 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 20:03 -!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has quit [Quit: prom3th3us] 20:07 -!- agorecki [~agorecki@unaffiliated/agorecki] has joined #bitcoin-wizards 20:14 -!- Giszmo [~leo@pc-103-124-45-190.cm.vtr.net] has quit [Quit: Leaving.] 20:14 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 265 seconds] 20:26 -!- coryfields_ [~quassel@2001:4802:7800:1:6fc4:c486:ff20:1fa] has quit [Quit: No Ping reply in 180 seconds.] 20:26 -!- coryfields [~quassel@2001:4802:7800:1:6fc4:c486:ff20:1fa] has joined #bitcoin-wizards 20:28 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 20:28 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 20:43 -!- kang_ [67efe97d@gateway/web/freenode/ip.103.239.233.125] has quit [Quit: Page closed] 20:50 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 20:53 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards 20:55 -!- mrbd [~bd@50.40.201.237] has joined #bitcoin-wizards 20:57 -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] 20:58 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards 21:03 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 21:05 -!- MrHodl [~fuc@185.22.183.196] has quit [] 21:06 -!- shredder_ [~marcinja@18.189.89.168] has joined #bitcoin-wizards 21:11 -!- shredder_ [~marcinja@18.189.89.168] has quit [Ping timeout: 272 seconds] 21:17 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards 21:17 -!- orik [~orik@c-71-227-207-191.hsd1.wa.comcast.net] has joined #bitcoin-wizards 21:19 -!- orik [~orik@c-71-227-207-191.hsd1.wa.comcast.net] has quit [Client Quit] 21:20 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] 21:41 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Quit: bendavenport] 21:44 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards 21:44 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit] 21:45 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards 21:48 -!- ak_ [~ak@65.78.54.2] has joined #bitcoin-wizards 21:48 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 21:48 -!- davispuh [~quassel@212.93.100.223] has quit [Remote host closed the connection] 21:50 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit] 21:51 -!- ak_ is now known as akstunt600 21:53 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards 21:54 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit] 21:56 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards 21:56 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit] 21:58 -!- mrbd [~bd@50.40.201.237] has quit [] 22:03 -!- harrow [~harrow@105.ip-167-114-152.net] has quit [Quit: Leaving] 22:07 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 22:08 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] 22:12 -!- harrow [~harrow@105.ip-167-114-152.net] has joined #bitcoin-wizards 22:13 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 22:22 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards 22:35 -!- akstunt600 [~ak@65.78.54.2] has quit [Ping timeout: 252 seconds] 22:36 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Quit: Leaving] 22:36 -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has quit [Quit: tbmit] 22:37 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 22:54 -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 244 seconds] 22:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 23:04 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards 23:05 -!- certee7 [~textual@124-149-119-223.dyn.iinet.net.au] has joined #bitcoin-wizards 23:10 -!- certee7 [~textual@124-149-119-223.dyn.iinet.net.au] has quit [Client Quit] 23:12 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [] 23:15 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards 23:18 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards 23:22 -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Ping timeout: 240 seconds] 23:32 -!- a5m0 [~a5m0@unaffiliated/a5m0] has quit [Remote host closed the connection] 23:32 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 23:37 -!- a5m0 [~a5m0@unaffiliated/a5m0] has joined #bitcoin-wizards 23:42 -!- Starduster [~sd@unaffiliated/starduster] has joined #bitcoin-wizards 23:56 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] 23:57 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 23:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nmnentqwhdfkmvov] has joined #bitcoin-wizards --- Log closed Sat Sep 19 00:00:32 2015