2015-09-18.log

--- Log opened Fri Sep 18 00:00:31 2015
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer]00:06
-!- execut3 [~shesek@77.125.99.86] has quit [Ping timeout: 265 seconds]00:07
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]00:12
-!- Dr-G [~Dr-G@x4d08a1dd.dyn.telefonica.de] has joined #bitcoin-wizards00: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-wizards00:12
-!- execut3 [~shesek@77.125.99.86] has joined #bitcoin-wizards00:23
-!- zooko_ [~Android@75.111.103.164] has joined #bitcoin-wizards00:29
-!- Ylbam [uid99779@gateway/web/irccloud.com/x-sddcogyfxenrtztb] has joined #bitcoin-wizards00:29
-!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards00:32
-!- zooko [~Android@172.56.30.227] has quit [Ping timeout: 256 seconds]00:33
-!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep]00:40
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer]00:43
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards00:51
-!- fkhan [weechat@gateway/vpn/mullvad/x-uivaeolcbgdoburu] has quit [Ping timeout: 246 seconds]01:00
-!- 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:01
-!- nullbyte [NSA@gateway/vpn/mullvad/x-omfvwtdkirfpvrcs] has joined #bitcoin-wizards01:02
-!- dc17523be3 [unknown@gateway/vpn/mullvad/x-yfizfcznklwidrcu] has joined #bitcoin-wizards01:03
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards01:03
-!- publius1788 [~publius17@104.200.154.10] has quit [Changing host]01:04
-!- publius1788 [~publius17@unaffiliated/publius1788] has joined #bitcoin-wizards01:04
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer]01:06
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]01:09
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards01:12
-!- fkhan [~weechat@193.138.219.233] has joined #bitcoin-wizards01:13
-!- fkhan [~weechat@193.138.219.233] has quit [Changing host]01:13
-!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-wizards01:13
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer]01:21
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards01:26
-!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards01:45
-!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Read error: Connection reset by peer]01:48
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer]01:52
-!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards01:55
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards02:09
-!- hdbuck [~hdbuck@unaffiliated/hdbuck] has joined #bitcoin-wizards02:18
-!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards02:25
-!- hdbuck [~hdbuck@unaffiliated/hdbuck] has quit [Quit: hdbuck]02:31
-!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has joined #bitcoin-wizards02:34
-!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]02:35
-!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards02:37
-!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has joined #bitcoin-wizards02:42
-!- rw|zZz is now known as c0rw1n02:50
-!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Read error: Connection reset by peer]02:57
-!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-wizards02:58
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]03:04
-!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has quit [Ping timeout: 244 seconds]03:07
-!- erasmospunk [~erasmospu@151.37.29.26] has joined #bitcoin-wizards03:09
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards03:10
-!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has joined #bitcoin-wizards03:15
-!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]03:18
-!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has quit [Ping timeout: 265 seconds]03:31
-!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection]03:38
-!- shredder_ [~marcinja@18.189.89.168] has joined #bitcoin-wizards03:41
-!- ttttemp [~ttttemp@pc-5305.ethz.ch] has quit [Remote host closed the connection]03:42
-!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards03: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:46
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Ping timeout: 264 seconds]03:49
-!- ttttemp [~ttttemp@nb-10350.ethz.ch] has joined #bitcoin-wizards03:54
-!- dabura667 [uid43070@gateway/web/irccloud.com/x-siccoivyejisixkp] has joined #bitcoin-wizards03:55
-!- Dr-G [~Dr-G@xd9bf7004.dyn.telefonica.de] has joined #bitcoin-wizards03: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-wizards03:56
-!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards04:04
-!- erasmosp_ [~erasmospu@179.43.156.130] has joined #bitcoin-wizards04:07
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds]04:07
da2ce7phantomcircuit, in fact these public private key 'stress test' are nothing more than an effective bounty for the rollout of full replace by fee.04:08
-!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has quit [Ping timeout: 265 seconds]04:09
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards04:20
-!- ttttemp [~ttttemp@nb-10350.ethz.ch] has quit [Remote host closed the connection]04:27
-!- gill3s [~gill3s@unaffiliated/gill3s] has joined #bitcoin-wizards04:35
-!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has quit [Ping timeout: 256 seconds]04:36
-!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards04:37
-!- flower [~user@202.44.241.187] has quit [Quit: -]04:38
-!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 272 seconds]04:42
-!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #bitcoin-wizards04:42
-!- gmaxwell is now known as Guest6988404:43
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer]04:49
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards04:54
-!- ttttemp [~ttttemp@nb-10350.ethz.ch] has joined #bitcoin-wizards05:04
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards05:25
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Client Quit]05:26
-!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has joined #bitcoin-wizards05:27
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards05:28
-!- 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-wizards05:43
-!- Guest69884 [greg@mf4-xiph.osuosl.org] has quit [Changing host]06:04
-!- Guest69884 [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-wizards06:04
-!- Guest69884 is now known as gmaxwell06:04
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.]06:06
-!- eudoxia [~eudoxia@r167-56-33-185.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards06:11
-!- jtimon [~quassel@172.56.6.239] has joined #bitcoin-wizards06:16
-!- jtimon [~quassel@172.56.6.239] has quit [Ping timeout: 260 seconds]06:22
-!- adam3us [~Adium@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.]06:24
-!- dabura667 [uid43070@gateway/web/irccloud.com/x-siccoivyejisixkp] has quit [Quit: Connection closed for inactivity]06:37
-!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards06:38
-!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has quit [Ping timeout: 265 seconds]06:40
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards06:42
-!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Ping timeout: 240 seconds]06:46
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Ping timeout: 250 seconds]06:47
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards06:48
-!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards06:50
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards06:50
-!- 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-wizards06:53
-!- jinglebellz [~jinglebel@149.130.222.229] has quit [Remote host closed the connection]07:00
-!- binaryFate [~binaryFat@93-47-253-162.ip115.fastwebnet.it] has joined #bitcoin-wizards07:06
-!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards07:07
-!- JackH [~Jack@host-80-43-143-151.as13285.net] has joined #bitcoin-wizards07:13
-!- jinglebellz [~jinglebel@149.130.142.147] has joined #bitcoin-wizards07:15
-!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer]07:16
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards07:24
-!- adam3us [~Adium@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards07:24
-!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards07:25
-!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards07:31
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards07:35
-!- bsm1175321 [~bsm117532@38.121.165.30] has joined #bitcoin-wizards07:37
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.]07:43
-!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 260 seconds]07:45
-!- helo is now known as helo_07:48
-!- helo_ is now known as heIo07:48
-!- heIo is now known as he1o07:48
-!- he1o is now known as helo07:48
-!- wizkid057 is now known as wk07:49
-!- wk is now known as wizkid07:50
-!- wizkid is now known as wizkidO5707:50
-!- wizkidO57 is now known as wizkid057_07:51
kanzure"accountable anonymous group communication" http://dedis.cs.yale.edu/dissent/  https://github.com/DeDiS/Dissent07:51
-!- wizkid057_ is now known as wizkid05707:51
-!- eudoxia_ [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards07:54
-!- eudoxia [~eudoxia@r167-56-33-185.dialup.adsl.anteldata.net.uy] has quit [Read error: Connection reset by peer]07:55
-!- eudoxia_ [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has quit [Client Quit]07:57
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards08:00
-!- adam3us [~Adium@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.]08:01
-!- jinglebellz [~jinglebel@149.130.142.147] has quit [Remote host closed the connection]08:12
-!- jinglebellz [~jinglebel@149.130.142.147] has joined #bitcoin-wizards08:13
-!- jinglebellz [~jinglebel@149.130.142.147] has quit [Ping timeout: 256 seconds]08:17
-!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards08:20
-!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards08:22
-!- 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:33
JackHare all these links/documents you paste somewhere else? like in one big repo?08:36
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards08:38
-!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]08:41
kanzureJackH: 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:43
JackHahh you are also the dude with the transcripts from the consensus08:45
-!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards08:45
kanzureJackH: http://diyhpl.us/wiki/transcripts/scalingbitcoin/08:45
JackHah yes that08:46
JackHhmm this should be indexed and stored better08:47
JackHyou have anything from DNA crypto to Bitcoin crypto08:48
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 255 seconds]08:53
-!- MrHodl [~fuc@185.22.183.196] has joined #bitcoin-wizards08:54
-!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]08:59
-!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards08:59
-!- zooko [~Android@2607:fb90:2c0c:a70c:4acb:d3c5:db70:4dfd] has joined #bitcoin-wizards09:00
kanzureJackH: true, in what way would you organize it?09:00
JackHhmm, well some tree structure, maybe search based09:00
JackHbut yeah, takes time09:01
JackHalot of manual work and sorting through it and defining everything09:01
JackHbut I think a relationship between the papers would be good to have09:01
JackHso that there is a clear way to introduce people to a certain subject09:01
JackHso you need to for instance to read the Bitcoin whitepaper before you move onto the Sidechain whitepaper09:02
-!- zooko__ [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has joined #bitcoin-wizards09:02
-!- zooko_ [~Android@75.111.103.164] has quit [Ping timeout: 246 seconds]09:03
-!- zooko [~Android@2607:fb90:2c0c:a70c:4acb:d3c5:db70:4dfd] has quit [Ping timeout: 268 seconds]09:04
kanzuresounds like you mean the citation graph09:07
TaekJackH were you at montreal? we talked about a few similar things09:08
JackHI was not unfortunately09:08
JackHwould have loved to e09:08
JackHbe09:08
kanzureJackH: he means http://diyhpl.us/wiki/transcripts/scalingbitcoin/systematizing-knowledge/09:09
JackHCommitted effort to improve the bitcoin wiki? <-- that one for certain is a big one09:11
TaekBlueMatt: we talked about making prs to bitcoin.ninja, what types of things would you be willing vs unwilling to merge?09:11
JackHwell from reading the link really quick09:13
JackHI see everyone agree's09:13
JackHwe all know alot and its nowhere to be found09:13
JackHI bet I am not the only one with 100's of links to things09:13
JackHwell....kanzure is a good candidate of link overload09:13
-!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards09:14
TaekJackH: 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 info09:14
JackHyeah09:14
JackHbut where?09:14
JackHI mean, sure, we can each do something09:14
JackHI could do something like this....09:14
TaekPR to bitcoin.ninja: https://github.com/TheBlueMatt/bitcoinninja09:15
Taekif he doesn't merge it, I'm happy to host an alternative website09:15
-!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards09:15
kanzureJackH: 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.yaml09:18
JackHwhat format would people be mostly interested in having? Wiki style? Website style? reddit style? something else?09:19
-!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]09:20
-!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards09:21
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards09:22
kanzureJackH: 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:23
JackHhmmm, yeah there is this as well09:24
-!- davec [~davec@cpe-24-243-239-16.hot.res.rr.com] has joined #bitcoin-wizards09:25
JackHare you constantly adding new material kanzure?09:26
kanzureusually09:28
-!- davec [~davec@cpe-24-243-239-16.hot.res.rr.com] has quit [Ping timeout: 244 seconds]09:33
-!- zwick [~zwick@fsf/member/zwick] has joined #bitcoin-wizards09:36
-!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep]09:37
JackHhmm, you know what, I think ill give this a go09:42
JackHstick around, I will show you when I got something that could maybe work09:42
-!- GAit [~GAit@208.54.86.233] has joined #bitcoin-wizards09:48
-!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards09:49
-!- PaulCape_ [~PaulCapes@199.19.94.16] has joined #bitcoin-wizards09:51
-!- 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-wizards09:53
-!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds]09:53
-!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards09:56
-!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards09:57
-!- PaulCape_ [~PaulCapes@199.19.94.16] has quit [Ping timeout: 240 seconds]09:59
-!- maraoz [~maraoz@50.247.108.204] has joined #bitcoin-wizards10: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-wizards10:01
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep]10:04
-!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards10:05
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards10:06
-!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has joined #bitcoin-wizards10:07
-!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Ping timeout: 250 seconds]10:07
-!- binaryFate [~binaryFat@93-47-253-162.ip115.fastwebnet.it] has quit [Ping timeout: 244 seconds]10:08
-!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards10:18
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep]10:25
-!- dEBRUYNE_ [~dEBRUYNE@vp0414.uvt.nl] has joined #bitcoin-wizards10:25
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte]10:26
-!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds]10:28
-!- davec_ [~davec@cpe-24-243-239-16.hot.res.rr.com] has joined #bitcoin-wizards10:29
-!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has quit [Quit: tbmit]10:29
-!- trippysalmon [rob@2001:984:6466:0:cca2:89cf:5e8d:9e38] has joined #bitcoin-wizards10:30
-!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds]10:30
-!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards10:32
-!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards10:38
-!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has quit [Quit: prom3th3us]10:38
-!- 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:40
-!- 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-wizards10:42
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards10:48
-!- c0rw1n is now known as c0rw|afk10:50
-!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds]10:50
maakuyay seL4 is on github: https://github.com/seL4/seL410:51
-!- zooko_ [~Android@172.56.32.38] has joined #bitcoin-wizards10:52
-!- 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:54
-!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has joined #bitcoin-wizards10:55
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards10:55
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards10:55
kanzurehuh, "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.pdf11:00
-!- nullbyte [NSA@gateway/vpn/mullvad/x-omfvwtdkirfpvrcs] has quit [Quit: leaving]11:03
-!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards11:04
maakuit's been open source for a little while, but I'm hoping being on github will get some visibility and use11:05
maaku(any hardware wallet authors here, this is what you should be using!)11:05
nsh(mathematics and computers don't work that way)11:11
-!- zooko_ [~Android@172.56.32.38] has quit [Ping timeout: 250 seconds]11:11
-!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards11:13
-!- 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:17
-!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards11:18
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards11:20
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection]11:20
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards11: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-wizards11:24
maakunsh: it's the closest we can get11:26
* nsh nods11:27
nshi 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 hardware11:28
nshso the notion of mathematical verification unintentionally connotes things it wouldn't want to11:28
maakuwell actually in the microcontroller case I find it plausible that you might be able to achieve real security that way11:29
-!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]11:29
maakuintel 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:29
maakubut 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 proof11:30
-!- zooko [~Android@172.56.32.193] has joined #bitcoin-wizards11:34
-!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has quit [Quit: prom3th3us]11:34
-!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has joined #bitcoin-wizards11:34
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.]11:34
-!- 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-wizards11:36
-!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards11:37
-!- maaku is now known as Guest8737811:37
-!- zooko [~Android@172.56.32.193] has quit [Ping timeout: 255 seconds]11:38
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards11:40
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Quit: bendavenport]11:44
-!- Iriez [wario@distribution.xbins.org] has quit [Ping timeout: 240 seconds]11:45
-!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards11:49
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has quit [Quit: Leaving.]11:50
-!- erasmosp_ [~erasmospu@179.43.156.130] has quit [Remote host closed the connection]11:51
-!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards11:52
-!- 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-wizards11:53
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]11:56
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep]12:00
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards12:03
BlueMattTaek: anything that people in this channel would generally consider smart/interesting12:04
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards12:04
-!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards12:05
-!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 255 seconds]12:08
-!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep]12:10
BlueMattalso @bitcoin.ninja emails12:10
-!- Guest87378 is now known as maaku12:11
nshmaaku ( Guest87378 ): you could, surely, *under the abstraction assumptions* between the specified physical operation of the hardware and the microarchitecture logic through to machine code12:11
nshand that would be a formidable achievement and make a lot of things a lot better12:11
nshbut 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 assurances12:12
maakuRight, well seL4 takes us as far as verifiably correct C code (assuming compiler + physical hardware conform to C standard)12:12
maakuthat's a remarkably far way along12:13
nshindeed12:13
-!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Max SendQ exceeded]12:14
nshso 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 toolchain12:14
nshand 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 basis12:14
-!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards12:15
maakuagreed. please go do it :)12:15
nshbut that would also require a cultural shift in the way people who make these things view networking12:15
nshit's on the TODO list :)12:15
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards12:15
-!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards12:23
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards12:24
-!- Madars_ is now known as Madars12:28
-!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev]12:30
-!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards12:30
-!- zooko [~Android@172.56.33.230] has joined #bitcoin-wizards12:30
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep]12:31
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards12:33
-!- jinglebellz [~jinglebel@149.130.224.111] has joined #bitcoin-wizards12:34
-!- zooko [~Android@172.56.33.230] has quit [Ping timeout: 260 seconds]12:35
-!- jinglebellz [~jinglebel@149.130.224.111] has quit [Remote host closed the connection]12:36
-!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has quit [Quit: tbmit]12:38
phantomcircuitruneks, are you Rune Kjær Svendsen  ?12:46
runeksphantomcircuit: Yes12:46
-!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has quit [Quit: ...sleep]12:47
phantomcircuitruneks, was my email to the list about full nodes using utxo set commitments clear?12:47
runeksphantomcircuit: 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:48
-!- erasmospunk [~erasmospu@179.43.174.66] has joined #bitcoin-wizards12:50
-!- veleiro [~veleiro@fsf/member/veleiro] has quit [Read error: Connection reset by peer]12:50
-!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards12:52
TD-Linuxmaaku, yeah the verifiably correct part is pretty neat. the functionality of seL4 is ultra minimal though13:00
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds]13:03
TD-Linuxit'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 thing13:04
-!- zooko [~Android@172.56.32.189] has joined #bitcoin-wizards13:06
-!- zooko [~Android@172.56.32.189] has quit [Ping timeout: 256 seconds]13:14
-!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards13:16
-!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards13:16
runeksphantomcircuit: I've responded :)13:18
-!- thesnark [~mgrube@unaffiliated/thesnark] has joined #bitcoin-wizards13:20
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer]13:22
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards13:24
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds]13:24
-!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]13:25
-!- 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
maakuanyone have a link to greg's original utxo commitment suggestion from way back when?13:31
-!- thesnark [~mgrube@unaffiliated/thesnark] has quit [Quit: bbl]13:33
CodeShark_can't we solve this attack scenario with sum trees? :)13:34
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards13:34
maakuTD-Linux: yes, but implement network stack, database, etc. as separate processes...13:35
-!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards13: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-wizards13:35
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Client Quit]13:36
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards13:36
CodeShark_committing to the utxo set alone is probably insufficient13:36
CodeShark_we need other partial checks to make this secure13:36
CodeSharkbah, wrong handle - committing to the utxo set alone is probably insufficient - we need other partial checks to make this secure13:38
CodeShark_inflation isn't too expensive to check against - but signature validation generally is quite expensive13:40
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer]13:40
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards13:41
maakuoh wait Rune == runeks? ok you do know prior work here i assume13:41
maakuruneks: I'm curious why you didn't mention using a balanced Merkle tree?13:41
-!- 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-wizards13:42
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Client Quit]13:43
runeksmaaku: 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 scriptsig13:44
CodeSharkit's a frustratingly old idea13:45
runeksAnd 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
maakuyou wouldn't want it in the scriptSig of the coinbase becuase coinbases are huge13:45
bramcSo 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 last13:45
maakubest place to put it, if soft-fork compatible, is in the last output of the last transaction13:45
maakubramc: I think you need to justify that complexity13:46
bramcAt 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 up13:46
MRL-Relay[tacotime] maaku: wouldn't the scriptsig of the coinbase be serialized to the same position in every serialized block?13:46
CodeSharkIdeally 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
maakutacotime: 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:47
maaku(put it at the end of the transaction for midstate compression hack)13:48
MRL-Relay[tacotime] Oh, I see.13:48
runeksCodeShark: 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
CodeSharkUgh13:49
CodeSharkSeriously, right?13:49
MRL-Relay[tacotime] runeks: make your own alt13:49
bramcThis 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 blocks13:49
bramcThe 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:50
maakubramc at the cost of making mining inherently stateful forever13:51
maakudelay the utxo commitment by one block so it is out of the validation loop. that's all you need imho...13:51
bramcmaaku Huh? It's no different from any other proposal for having utxo roots13:51
maakubramc: time to validate the root is on the same order of validation work that is already done.13:52
runeksCodeShark: 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
runekswhich 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
maakufurthermore, by delaying one block you don't have to do it in the tight validation loop before relay13:52
maakuso why have an incremental structure beyond that?13:52
bramcMaking the utxo root be one block behind is an interesting idea13:52
siparuneks: well bitcoin is not a monolith13:53
bramcIt's in line with my overall idea that you allow utxo root work to be done in the background13:53
maakubramc: to be honest I thought that was what you proposed to me at the workshop...13:53
runeksI mean, right now we don't even have a protocol. We have a program (Bitcoin Core).13:53
siparuneks: significant parts can be changed, or even have multiple parallel parts13:53
siparuneks: the consensus rules are an exception13:54
runekssipa: I'm not following. What can be changed?13:54
bramcmaaku, 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 ones13:54
-!- adam3us [~Adium@172.56.12.182] has joined #bitcoin-wizards13:54
CodeSharkruneks: https://github.com/bitcoin/bips/pull/19213:54
bramcLike, rebalancing the whole tree, or in the case of what I just suggested regenerating the whole tree.13:54
siparuneks: wallets, p2p protocol, implementations, optimization, specifalized block relay algorithms and protocols, ...13:54
CodeSharkComments appreciated :)13:55
runekssipa: My point is that it's not sufficient to change these. Bitcoin needs to evolve from program to protocol.13:55
runeksCodeShark: I will take a look!13:55
siparuneks: it is a protocol, with multiple implementations13:55
siparuneks: the consensus rules are defined by what people's node enforce13:56
CodeSharkMore direct: https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki13:56
siparuneks: you won't change that by using a different design13:56
CodeSharkunfortunately github is not ideal for commenting on prose13:56
bramcmaaku, 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 block13:57
maakubramc: for separate reasons it is desireable for each block to have it's own delta commitment, so delaying 1 block is actually cleaner13:57
siparuneks: 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 change13:57
kanzuremaaku: i have many links to utxo commitment proposals,13:57
kanzurefor gmaxwell's version,13:57
kanzurehttps://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less13:57
kanzurehttps://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log13:57
runekssipa: 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
kanzurehttps://bitcointalk.org/index.php?topic=314467.013:57
-!- urika [~sunflower@50.248.81.66] has joined #bitcoin-wizards13:58
siparuneks: i fundamentally disagree that we are at a point where we can do that13:58
maakukanzure: I was going to post them to 'that guy who was suggesting utxo set commitments on the mailing list', but turns out that guy == runeks13:58
kanzureas for utxo commitments in general:13:58
kanzurehttps://bitcointalk.org/index.php?topic=844944.013:58
kanzurehttps://bitcointalk.org/index.php?topic=1048021.013:58
kanzurehttps://bitcointalk.org/index.php?topic=1056866.013:58
siparuneks: software engineering does not have a means for proving the equivalence between two pieces of software13:58
runekssipa: When do you think, if ever, we will be able to do that? Is now not better than later?13:58
kanzurehttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/003921.html13:58
siparuneks: i think we should refactor bitcoin core's code to have the part that defines the consensus rules separately13:59
MRL-Relay[tacotime] runeks: alternative implementation adoption has always been seemingly against the collective interests of bitcoin core developers, for better or worse13:59
siparuneks: and then don't touch it anymore unless we want the consensus rules to change13:59
bramcmaaku, I think we both just said the exact same thing13:59
kanzurebramc: 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.13:59
maakubramc: I don't think we are in disagreement, except perhaps regarding longer window commitments14:00
-!- gmaxwell is now known as Guest2452514:00
siparuneks: then anyone can create a full node implementation, as long as they can use the consensus library14: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:00
MRL-Relay[tacotime] and so everyone else is, too.14:01
MRL-Relay[tacotime] s/stuff/stuck14:01
runekssipa: 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
runekswere 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
maakubramc: *regarding the utility, or necessity, or benefit of longer-window commitments14: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:01
kanzure... https://bitcointalk.org/index.php?topic=314467.014:02
siparuneks: so what do you do when the implementation differs from the intent?14:02
bramckanzure, 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
maakuimho we benefit from *not* doing commitments every 2016 blocks14:02
siparuneks: you still need a hard fork to fix it14:02
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards14:02
CodeSharkwe 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 pl14:03
maakukanzure: thanks for the links!14:03
bramckanzure, I *think* the merkle mountain range proposal has a different approach to rebalancing, but I'm not sure14:03
siparuneks: adding more different consensus implementations into the mix just increases the chance for randomly ending up with disagreements14:03
-!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 250 seconds]14:03
CodeShark3) we have no solid mechanism in place for consensus-critical changes14:03
runekssipa: 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
sipaCodeShark: 3) is called politics14:03
kanzuremaaku: 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
siparuneks: miners can't fix it14:03
siparuneks: what if two implementations are incompatible in a mutual way?14:04
runekssipa: We should never temporarily alter the protocol rules just to solve a hard fork. This creates uncertainty, and instability.14:04
Taekkanzure: 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 mining14:04
sipathe protocol rules are defined by what people run14:04
bramcThe 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
runekssipa: Unless we recognize that the protocol is faulty.14:04
kanzurejust 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.py14:04
CodeShark(2) is at least semi-tractable right now14:05
kanzureTaek: 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 here14:05
-!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-wizards []14:05
maakukanzure: 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 hash14:05
maakuyou need to do that before you relay the block, because maybe the commitment is wrong14:05
kanzureright, commitment needs to be checked even if it was for the last block though14:05
runekssipa: 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
CodeSharkruneks: you either do one or three :)14:06
CodeSharkNever two14:06
-!- zwick [~zwick@fsf/member/zwick] has quit [Quit: WeeChat 1.3]14:06
maakuright, 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 along14:06
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
kanzureokay but in both cases you are still doing utxo update verification/delta work stuff.14:07
maakuright, it's just not in the receive, validate, relay loop14:07
CodeSharkkanzure: is there any way I can help you in archiving good material and reorganizing it?14:08
bramckanzure, 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 that14:08
kanzureCodeShark: 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:08
bramckanzure, 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
kanzureCodeShark: 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.yaml14:09
maakutacotime: utxo growth isn't exponential in the limit14:09
bramcLike, it's much faster for the last block than the sorting operation is.14:09
maakubramc: the disadvantage is that you have to actually store and keep around those lists :P14:09
kanzuremaaku: it's still in the loop; if it's wrong, you can't relay the current block.14:09
CodeSharkwonderful! I look forward to that. If you need any help writing anything let me know. We need to do better than bitcointalk and botbot links14:09
kanzureyou shouldn't relay bad blocks14:09
kanzureCodeShark: 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
helodoes utxo growth scale with exchange value "in the limit"?14:10
kanzureCodeShark: (such a summary would in theory always mention private information retrieval stuff, too)14:10
bramcmaaku, 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 into14:10
maakukanzure: you'll already know the commitment that should be there because you calculated it from the last block14:10
-!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards14:11
kanzuremaaku: 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
maakuso receive a block, validate it, relay it, update utxo hash, <...wait..> receive new block, validate including checking <--- prior hash, relay , etc.14:11
maakuright14:11
kanzurei mean, it's still there in that loop, but can use some cached precomputation for superfast verificatio nkthx14:11
bramcOne 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:11
bramckanzure, Right, I'm proposing doing the same trick in the large for the utxo root as a whole14:12
maakubramc: btw you should look at mmr's for inseration-ordered full-txout commitments14:13
kanzureman 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
maakuit's not obvious (to me) which is better, utxo, txo, or stxo14:14
maakuwe really need competing proposals to test14:14
kanzurebramc was quite adamant about stxo being useless14:14
bramcmaaku, I'm thinking a flat merkle tree of fixed depth14:14
kanzurewait i'm not allowed to say that14:14
CodeSharkI still hold that fixing (2) and (3) are far more critical right now14:14
kanzureSOMEONE had good reasons for not doing stxo14:14
bramcWhat is stxo?14:14
kanzurespent transaction outputs14:14
maakubramc: that requires a full node to have the full UTXO set14:14
CodeSharkFixing (1) depends on (2) and (3)14:14
kanzure"insertion-STXO proofs might be more bandwidth-friendly"14:15
kanzurefrom page 22 http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-review.pdf14:15
bramcmaaku, How can a node be 'full' if it doesn't have the full utxo set?14:15
maakuit 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 provided14:15
bramcOh, stxo is spent transaction outputs. Yeah remembering those is pointless.14:15
maaku*proofs that are less than the size of the UTXO set14:16
kanzureyes, there's a few proposals about having a storageless full-node using various utxo commitments and update proofs or something14:16
kanzurenone of which are very fleshed out proposals14:16
maakubut in principle they work14:16
kanzureoops not storageless, just constant-storage-size and still fully-validating14:16
-!- xabbix [~xabbix@bzq-79-179-133-122.red.bezeqint.net] has joined #bitcoin-wizards14:16
-!- xabbix [~xabbix@bzq-79-179-133-122.red.bezeqint.net] has quit [Changing host]14:16
-!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-wizards14:16
bramcI don't see how stxo is every smaller than utxo. The number of stxos is several times as much.14:17
maakuif 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 set14:17
kanzurewasn't this the flip-the-chain idea14:17
maakukanzure: yes14:17
kanzurehttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001550.html14:17
kanzure"with txout+txid indexing (for the 'flip the chain' proposals)"14:18
maakukanzure: when your storage size (32-bytes) is less than your working space, I consider that storageless ;)14:18
kanzureflip 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.014:18
bramcI 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:18
maakubramc: imagine blocks and transactions come with proofs extracted from the merkle utxo tree14:19
maakuand 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:19
bramcmaaku, 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  fu14:20
kanzurethere might be a way to do that without snarks14:20
maakubramc: it works trivially with patricia tries (one of the proposals), so that might be a place to start14:20
bramcmaaku, 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
maakukanzure: snarks aren't necessary. the merklized patricia trie of utxos indexed by txid:n works for this14:21
kanzuremaaku: with update proofs?14:22
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Remote host closed the connection]14:22
maakukanzure: snarks let you get a constant storage, constant workspace, constant time validator though, which is friggin awesome14:22
maakukanzure: yes14:22
maakuhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/003921.html14:22
maakuwhich you posted earlier14:22
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards14:22
maakuactually the email is out of date, here is better: https://gist.github.com/maaku/2aed2cb628024800044d14:23
maakustill out of date, but i'll fix that soon14:23
kanzurehow is out of date?14:23
kanzurei mean the gist14:23
maakubetter 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 document14:24
-!- CodeShark is now known as CodeShark__14:24
maakumostly 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
maakuin large the proposal is the same14:24
-!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards14:25
kanzureso verification can be done without a full utxo set constructed from the blockchain?14:25
bramcYou can straightforwardly do a proof of the validity of a block based off the utxo commitment in the previous block14:25
-!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards14:26
CodeSharkI'd rather see some of these bips less focused on implementation and more focused on architecture ;)14:26
bramcThe proof is larger than the block though.14:26
kanzurei believe bip1 asks for implementation details in bips14:26
maakuthe 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 block14:26
-!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards14:26
maakubramc: proof is smaller than the utxo though14:26
maaku*utxo set14:26
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Ping timeout: 246 seconds]14:27
CodeSharkI'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... :p14:27
bramcmaaku, I think this property holds for all utxo commitment proposals14:27
kanzurei am also confused about what sort of attributes we're missing without snarks with this sort of proposal14:27
kanzureor which attributes we're preserving that i might be accidentally attributing to snarks already14:27
TaekCodeShark: 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
bramcCodeShark sometimes the most concise way to specify something is with an implementation.14:27
CodeSharkI'm not opposed to also requiring implementations - don't get me wrong14:28
kanzurebramc: 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 far14:28
-!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has joined #bitcoin-wizards14:28
-!- orik [~orik@50.125.71.245] has quit [Client Quit]14:28
maakuCodeShark: we would all like to do that for everything except the consensus code14:28
CodeSharkI 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 platform14:28
maakue.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 fixed14:29
maakunot so for consensus code14:29
kanzuremaaku: 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
bramcConsensus behaviors you're basically stuck with, unfortunately.14:29
maakukanzure: yes14:30
CodeSharkmaaku: 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
maakuthe 'storageless' part of a utxo-proof-streeming validator is the utxo storage. it has non-constant RAM requirements to validate a block14:30
kanzure(streaming?)14:31
maakuit's storage is just the last utxo commitment plus a few other misc things like block height14:31
CodeSharkBIPs like 70 depend FAR more on widespread adoption to become "official" than on being a BIP14:31
-!- Guest24525 is now known as gmaxwell14:31
CodeSharkmoreover, there's room for several different competing approaches without breaking the network14:32
maakukanzure: 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:32
-!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep]14:33
maakuthis is the idea of a constant-storage streaming validator14:33
maakuyou can even have mining nodes that behave this way: prefix transactions with their own utxo delta showing inputs and location for outputs14:34
maakuand rebase each proof using the delta of the block after it is found14:35
kanzureah 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.pdf14:35
kanzureah i like the rebase terminology, is easy to grok14:36
maakudoes 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 properties14:36
bramcmaaku, Why do you want to include the proofs inline in the block chain? They can just as easily be supplied 'on the side'14:36
bramcmaaku, 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-wizards14:37
kanzuremaaku: 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 ideas14:37
maakukanzure: 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:37
maakubramc: 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 protocol14:39
maakuif you broadcast a transaction or a block, it needs to come with a delta proof in this future hypothetical bitcoin p2p network14:39
-!- orik [~orik@50.125.71.245] has quit [Client Quit]14:39
bramcmaaku, I don't follow why this can't be done with any utxo commitment scheme14:39
CodeSharkthink git...except enforce rules regarding how files can change...and require a PoW timestamp for each commitment :)14:40
CodeSharkthen optimize the crap out of it14:41
-!- Starduster [~guest@unaffiliated/starduster] has quit []14:41
-!- adam3us [~Adium@172.56.12.182] has quit [Quit: Leaving.]14:42
CodeSharkonce we completely decouple the commitment structure from the transport layer, then we can talk about using ssh vs. https vs. sftp vs. blah14:43
CodeSharkeventually some routable protocol, hopefully14:43
maakubramc: 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 only14:44
maakubramc: take a 4-leaf balanced binary tree, for example, and remove the lestmost leaf14:44
maakuthe other leafs "shift over" if you are doing a straight bitcoin-like merkle tree14:45
maakuand you need to know the leaf nodes in order to calculate the new structure14:45
-!- adam3us [~Adium@172.56.12.182] has joined #bitcoin-wizards14:45
bramcmaaku, Oh I see now. I'll have to think about that.14:46
maakukanzure: in particular the gist uses 28-byte hashes with the intent of combining two hashes in a single compression round14:48
-!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards14:48
-!- orik [~orik@50.125.71.245] has quit [Client Quit]14:48
maakuturns out SHA2 padding is fucking stupid and that doesn't work, despite being the whole point of SHA224 existing as far as I can tell14:48
maakuyay standards that were never actually used for their intended purpose before becoming standards14:49
-!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection]14:50
prom3th3usPardon 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
bramcmaaku, 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 care14:52
kanzureprom3th3us: useful for experimentation for risky things that might destroy bitcoin mainnet blockchain14:53
maakubramc: well, a patricia tree does that for utxo commitments14:53
maaku(see the linked gist above)14:53
maakubut if you do go down this route of prefixed proofs, then txo / stxo may result in smaller proofs... hence the interest in them14:54
bramcmaaku, 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
prom3th3uskanzure: 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-wizards14:54
-!- orik [~orik@50.125.71.245] has quit [Client Quit]14:54
bramcmaaku, The downside of a patricia tree is that it's a big mess to maintain14:54
-!- Guest68337 [~audioishi@blackmain.media.mit.edu] has joined #bitcoin-wizards14:57
-!- Starduster [~sd@unaffiliated/starduster] has joined #bitcoin-wizards14:58
bramcCome to think of it, my deltas idea could be done with patricia trees just fine14: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:58
bramcOr at least something which has the property you describe, not 100% sure if my understanding of patricia trees is correct.14:59
-!- cholbrow [~cholbrow@blackmain.media.mit.edu] has joined #bitcoin-wizards15:00
-!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards15:01
-!- 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:02
CodeSharkwhy is a patricia tree a big mess to maintain?15:03
bramcCodeShark if you're maintaining it incrementally it frags memory like nobody's business15:03
CodeSharkcan't you reallocate every once in a while to reclaim memory?15:04
-!- adam3us [~Adium@172.56.12.182] has joined #bitcoin-wizards15:04
-!- bsm1175321 [~bsm117532@38.121.165.30] has quit [Ping timeout: 268 seconds]15:05
bramcthe effectiveness of that is heavily dependent on how much updating you're doing15:05
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]15:05
bramcI assume by 'reallocate' you mean re-sweep and consolidate15:05
CodeSharkyes15:05
-!- kang_ [67efe97d@gateway/web/freenode/ip.103.239.233.125] has joined #bitcoin-wizards15:06
CodeSharkas opposed to?15:07
bramcWhat 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 complicated15:07
CodeSharkgood implementations that are efficient with resources are clearly nontrivial...but seem doable and seem to be something that could be well encapsulated15:08
bramcSo 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 tree15:08
bramcthe log(n) multiplier on doing everything kind of sucks15:09
bramchaving to walk the tree for each transaction is a nontrivial expense15:09
bramcBut we're all in agreement about having the big tree be a block behind15:10
-!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards15:10
CodeSharkyeah, nothing is free..but I think the tradeoffs can be made acceptable15:10
-!- 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-wizards15:11
CodeSharkin any case we're trading something off - right now, we're basically sacrificing thin client security ;)15:11
CodeSharkI'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 devices15:12
CodeSharkright now I don't really even have that option - I basically have to run a full node15:13
CodeSharkit sucks...but in principle it seems to be amenable to division of labor and economies of scale15:14
-!- JackH [~Jack@host-80-43-143-151.as13285.net] has quit [Ping timeout: 240 seconds]15:14
-!- zooko_ [~Android@2607:fb90:21cf:f2fb:acf6:4194:1dc7:ca7f] has joined #bitcoin-wizards15:16
-!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has quit [Ping timeout: 268 seconds]15:16
CodeSharkand I also think that such incentives could be offered in ways that promote decentralization15:17
-!- zooko [~Android@75.111.103.164] has joined #bitcoin-wizards15:17
-!- shen_noe [~shen_noe@104.156.228.98] has joined #bitcoin-wizards15:18
-!- shen_noe [~shen_noe@104.156.228.98] has quit [Client Quit]15:19
-!- zooko_ [~Android@2607:fb90:21cf:f2fb:acf6:4194:1dc7:ca7f] has quit [Ping timeout: 252 seconds]15:20
CodeSharkalthough the decentralization/economy of scale thing can be a bit of a tradeoff in some instances, perhaps15:22
CodeSharkASICs are an obvious example15:22
-!- zooko [~Android@75.111.103.164] has quit [Ping timeout: 268 seconds]15:22
-!- zooko [~Android@75.111.103.164] has joined #bitcoin-wizards15:23
bramcCodeShark 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 hot15:24
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards15:24
bramcIt'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 work15:25
bramcBasically they have 3x the work because they're updating 3 deltas instead of a single root15:27
-!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards15:28
CodeSharkRight - 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 it15:29
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards15:29
CodeSharkI'm actually more concerned about implementation difficulty and long-term source code maintenance than I am about log(n) or constant factor costs15:30
MRL-Relay[tacotime] implementation difficulty generally sucks15:30
bramcVerification for patricia trees is fairly brainless.15:31
CodeSharkyes, so that's a big plus15: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 mainchain15:31
bramcThey're basically the same as flat fixed-depth in terms of complexity15:31
bramctacotime, I'm perfectly happy to dump complexity of fixed-size storage onto later implementers, because that's an inherently complicated thing to do15:32
MRL-Relay[tacotime] in terms of the actual tree structure and algorithms defining it, yes, that's well characterized already15:32
bramcHaving to do it multiple times won't substantially change its complexity from doing it once15:32
CodeSharkright - 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 needed15:33
CodeSharkwe don't need to dictate top down how everything is implemented15:33
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Ping timeout: 250 seconds]15:34
bramcIf the utxo commitment is based on deltas then the checkpoints of them need to be set in advance15:34
CodeSharkif 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:34
CodeSharkand if the incentives are there people will look for further optimizations15:35
bramcDoing 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 implement15:36
-!- kmels [~kmels@186.64.110.122] has quit [Ping timeout: 246 seconds]15:36
MRL-Relay[tacotime] if the delta is long enough in the past (hours), you probably don't have to worry about reorganizations at all15:38
MRL-Relay[tacotime] if you're using delta to refer to committing to past utxo roots15:39
MRL-Relay[tacotime] (or whole set hashes, whatever)15:39
CodeSharkyou set a cutoff for the committed delta to be 100 blocks in the past or something15:39
CodeSharkand maintain a delta for all recent activity, right15:39
CodeShark?15:39
MRL-Relay[tacotime] oh, i see15:39
MRL-Relay[tacotime] well, i think the first step would just be the including the utxo set from a past perspective then15:40
MRL-Relay[tacotime] worry about hashes of the deltas (updates to it) later15: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 correctly15:40
-!- Starduster [~sd@unaffiliated/starduster] has quit []15:42
CodeSharkI'm still not totally clear on why consolidating in batch is more efficient than doing it continuously15: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 deltas15:42
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards15:43
CodeSharkI sorta do get why...but I have to think about this a little more15:43
MRL-Relay[tacotime] but other than that i don't see an advantage15:43
-!- eudoxia [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards15:45
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards15:49
-!- zooko [~Android@75.111.103.164] has quit [Ping timeout: 255 seconds]15:53
-!- memymo [~textual@c-24-4-69-49.hsd1.ca.comcast.net] has joined #bitcoin-wizards15:54
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards15:58
-!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has joined #bitcoin-wizards15:58
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards16:04
-!- maraoz [~maraoz@50.247.108.204] has quit [Ping timeout: 256 seconds]16:05
-!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 260 seconds]16:09
bramcsorry 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 blocks16:11
bramcIt'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:12
bramcThis particularly matters on a device which has to hold the utxo set on disk16:13
bramcThe 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:16
bramccodeshark, did that make sense?16:17
-!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards16:17
CodeSharkI think so16:17
CodeSharkso you're sacrificing short-term prunability for local memory operations?16:20
-!- maraoz [~maraoz@2601:647:4b02:94f1:fcbf:3b81:c02b:4303] has joined #bitcoin-wizards16:21
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection]16:22
bramcThat'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:23
-!- eudoxia [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving]16:24
bramcCome to think of it, you can always do better on the batch operation, because you can share the walking down work across the whole batch16:25
bramcYou don't *have* to do a linear pass, it's just the most brainless approach.16:25
CodeSharkah!16:26
CodeSharkof course...in batch you only need to traverse each branch once!16:26
-!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds]16:27
maakuand you don't have to recalculate the inner node hashes between updates16:28
CodeSharkyep16:28
maakui don't dispute that it is an efficiency gain to commit less frequently than every block16:28
maakubut i don't think it is worth it16:28
maakuhowever, I don't see the need to have larger deltas16:28
maakuif you are committing every 8 blocks, the 64 or 4096 block deltas seem pointless to me16:29
bramcmaaku, The idea is to make the brainless linear approach be fairly efficient16:29
bramcBecause it's amortized over a longer time period16:29
maakubramc: 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 again16:30
bramcThe 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 409616:32
-!- zooko_ [~Android@2607:fb90:2192:df4c:18ff:788c:43c9:c773] has joined #bitcoin-wizards16:32
bramcSo 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:33
-!- zooko [~Android@71-89-249-159.dhcp.aldl.mi.charter.com] has quit [Ping timeout: 240 seconds]16:34
maakuso what is the commitment in a block?16:34
maakuare you committing to the utxo root hash? only committing every 8th block?16:34
maakukanzure bramc: acutally you may need to delay 2 blocks so you can start mining immediately too16:37
bramcYou'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 one16:37
bramcI 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:37
bramcI 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-wizards16:38
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]16:42
CodeSharkwhat does the brainless linear approach really buy you? don't you have to do more complex tree operations at some point anyhow?16:43
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection]16:44
CodeSharkI understand why you want to merge trees of equal size in batch - not entirely clear why the linear approach simplifies implementation as a whole16:45
-!- jinglebellz [~jinglebel@149.130.222.229] has joined #bitcoin-wizards16:45
-!- memymo [~textual@c-24-4-69-49.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]16:47
bramcNo more complex operations necessary - A patricia tree can be hashed left to right no problem.16:50
-!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards16:51
bramcSo there's no memory management to speak of, it's just running straight through16:51
-!- bliljerk_ [~bliljerk1@pool-74-109-193-20.pitbpa.fios.verizon.net] has quit [Read error: Connection reset by peer]16:51
-!- 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:54
-!- adam3us [~Adium@172.56.12.182] has quit [Quit: Leaving.]16:58
-!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards17:02
-!- rando1 [126f4f55@gateway/web/freenode/ip.18.111.79.85] has joined #bitcoin-wizards17:02
CodeSharkbut eventually you need to merge a tree into a much larger tree that could be gigabytes in size, no?17:04
CodeSharkso you're saying that this entire structure would be stored contiguously in RAM?17:04
-!- _2drewlee [~textual@104.220.67.131] has joined #bitcoin-wizards17:05
-!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]17:11
-!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Ping timeout: 240 seconds]17:12
-!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards17:13
-!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards17:15
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards17:17
-!- _2drewlee [~textual@104.220.67.131] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]17:19
-!- zooko_ [~Android@2607:fb90:2192:df4c:18ff:788c:43c9:c773] has quit [Ping timeout: 246 seconds]17:20
-!- Guest10 [~textual@104.220.67.131] has joined #bitcoin-wizards17:25
-!- rando1 [126f4f55@gateway/web/freenode/ip.18.111.79.85] has quit [Ping timeout: 246 seconds]17:25
-!- lnovy [~lnovy@2002:4d57:f055::1] has quit [Quit: Got root?]17:32
-!- lnovy [~lnovy@2002:4d57:f055::1] has joined #bitcoin-wizards17:32
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]17:36
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards17:38
-!- Guest10 [~textual@104.220.67.131] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]17:40
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards17:44
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Ping timeout: 256 seconds]17:49
-!- maraoz [~maraoz@2601:647:4b02:94f1:fcbf:3b81:c02b:4303] has quit [Ping timeout: 240 seconds]17:52
-!- 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 c0rw1n17:53
kang_Bitcoin over Tor isn't a good idea (http://arxiv.org/abs/1410.6079)17:54
-!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-zmgjkdbnjacdovzo] has quit [Quit: Connection closed for inactivity]17:55
-!- zooko [~Android@172.56.38.127] has joined #bitcoin-wizards17:56
-!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep]17:59
-!- CodeShark__ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds]18:07
-!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has quit [Quit: prom3th3us]18:08
-!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]18:19
-!- Guest10 [~textual@104.220.67.131] has joined #bitcoin-wizards18:21
-!- Guest10 [~textual@104.220.67.131] has quit [Client Quit]18:22
ryan-ca long time ago, i ran a tor exit node and found that people were using it to connect to mining pools18:33
ryan-ci could have hijacked their work units because it wasn't ssl18:33
-!- adlai [~adlai@unaffiliated/adlai] has joined #bitcoin-wizards18:40
-!- zooko [~Android@172.56.38.127] has quit [Ping timeout: 272 seconds]18:53
-!- Ylbam [uid99779@gateway/web/irccloud.com/x-sddcogyfxenrtztb] has quit [Quit: Connection closed for inactivity]18:54
-!- adam3us [~Adium@172.56.6.44] has joined #bitcoin-wizards18:55
-!- Guest10 [~textual@104.220.67.131] has joined #bitcoin-wizards18:56
-!- tkiel [~tkiel@ip68-231-91-194.ph.ph.cox.net] has joined #bitcoin-wizards19:00
-!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has joined #bitcoin-wizards19:00
-!- bigreddmachine [~bigreddma@c-67-176-94-89.hsd1.co.comcast.net] has joined #bitcoin-wizards19:00
-!- Guest10 [~textual@104.220.67.131] has quit [Ping timeout: 240 seconds]19:01
-!- adam3us [~Adium@172.56.6.44] has quit [Quit: Leaving.]19:05
-!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards19:05
bramccodeshark, 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:07
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]19:10
-!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_]19:14
-!- adam3us [~Adium@172.56.12.164] has joined #bitcoin-wizards19:15
-!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep]19:18
-!- adam3us [~Adium@172.56.12.164] has quit [Ping timeout: 260 seconds]19:27
-!- adam3us [~Adium@172.56.12.164] has joined #bitcoin-wizards19:28
-!- adam3us [~Adium@172.56.12.164] has quit [Ping timeout: 264 seconds]19:33
-!- agorecki [~agorecki@unaffiliated/agorecki] has joined #bitcoin-wizards19:42
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards19:44
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has quit [Ping timeout: 250 seconds]19:49
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards19:51
-!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 240 seconds]19:51
-!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards19:53
-!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards19:54
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Ping timeout: 240 seconds]19:55
-!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards19:58
-!- bliljerk101 [~bliljerk1@pool-74-109-193-20.pitbpa.fios.verizon.net] has joined #bitcoin-wizards19:59
-!- agorecki [~agorecki@unaffiliated/agorecki] has quit [Remote host closed the connection]20:00
-!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]20:01
-!- prom3th3us [~prom3th3u@unaffiliated/prom3th3us] has quit [Quit: prom3th3us]20:03
-!- agorecki [~agorecki@unaffiliated/agorecki] has joined #bitcoin-wizards20:07
-!- 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:14
-!- 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-wizards20:26
-!- 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-wizards20:28
-!- kang_ [67efe97d@gateway/web/freenode/ip.103.239.233.125] has quit [Quit: Page closed]20:43
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]20:50
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards20:53
-!- mrbd [~bd@50.40.201.237] has joined #bitcoin-wizards20:55
-!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services]20:57
-!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards20:58
-!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards21:03
-!- MrHodl [~fuc@185.22.183.196] has quit []21:05
-!- shredder_ [~marcinja@18.189.89.168] has joined #bitcoin-wizards21:06
-!- shredder_ [~marcinja@18.189.89.168] has quit [Ping timeout: 272 seconds]21:11
-!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards21:17
-!- orik [~orik@c-71-227-207-191.hsd1.wa.comcast.net] has joined #bitcoin-wizards21:17
-!- orik [~orik@c-71-227-207-191.hsd1.wa.comcast.net] has quit [Client Quit]21:19
-!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving]21:20
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Quit: bendavenport]21:41
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards21:44
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit]21:44
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards21:45
-!- ak_ [~ak@65.78.54.2] has joined #bitcoin-wizards21:48
-!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards21:48
-!- davispuh [~quassel@212.93.100.223] has quit [Remote host closed the connection]21:48
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit]21:50
-!- ak_ is now known as akstunt60021:51
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards21:53
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit]21:54
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards21:56
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit]21:56
-!- mrbd [~bd@50.40.201.237] has quit []21:58
-!- harrow [~harrow@105.ip-167-114-152.net] has quit [Quit: Leaving]22:03
-!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]22:07
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer]22:08
-!- harrow [~harrow@105.ip-167-114-152.net] has joined #bitcoin-wizards22:12
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards22:13
-!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards22:22
-!- akstunt600 [~ak@65.78.54.2] has quit [Ping timeout: 252 seconds]22:35
-!- 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:36
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards22:37
-!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 244 seconds]22:54
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards22:56
-!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards23:04
-!- certee7 [~textual@124-149-119-223.dyn.iinet.net.au] has joined #bitcoin-wizards23:05
-!- certee7 [~textual@124-149-119-223.dyn.iinet.net.au] has quit [Client Quit]23:10
-!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit []23:12
-!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards23:15
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards23:18
-!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Ping timeout: 240 seconds]23:22
-!- 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:32
-!- a5m0 [~a5m0@unaffiliated/a5m0] has joined #bitcoin-wizards23:37
-!- Starduster [~sd@unaffiliated/starduster] has joined #bitcoin-wizards23:42
-!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep]23:56
-!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]23:57
-!- Ylbam [uid99779@gateway/web/irccloud.com/x-nmnentqwhdfkmvov] has joined #bitcoin-wizards23:58
--- Log closed Sat Sep 19 00:00:32 2015

Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!