--- 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