| --- 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-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:12 | |
| -!- execut3 [~shesek@77.125.99.86] has joined #bitcoin-wizards | 00:23 | |
| -!- 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:29 | |
| -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards | 00: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-wizards | 00: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-wizards | 01:02 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-yfizfcznklwidrcu] has joined #bitcoin-wizards | 01:03 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 01:03 | |
| -!- publius1788 [~publius17@104.200.154.10] has quit [Changing host] | 01:04 | |
| -!- publius1788 [~publius17@unaffiliated/publius1788] has joined #bitcoin-wizards | 01: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-wizards | 01:12 | |
| -!- 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: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-wizards | 01:26 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 01: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-wizards | 01:55 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards | 02:09 | |
| -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has joined #bitcoin-wizards | 02:18 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 02:25 | |
| -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has quit [Quit: hdbuck] | 02:31 | |
| -!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has joined #bitcoin-wizards | 02:34 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] | 02:35 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 02:37 | |
| -!- bedeho [~bedeho@client-7-154.visitor-network.oxuni.org.uk] has joined #bitcoin-wizards | 02:42 | |
| -!- rw|zZz is now known as c0rw1n | 02:50 | |
| -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Read error: Connection reset by peer] | 02:57 | |
| -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-wizards | 02: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-wizards | 03:09 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 03:10 | |
| -!- dEBRUYNE [~dEBRUYNE@ww010655.uvt.nl] has joined #bitcoin-wizards | 03: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-wizards | 03: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-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: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-wizards | 03:54 | |
| -!- dabura667 [uid43070@gateway/web/irccloud.com/x-siccoivyejisixkp] has joined #bitcoin-wizards | 03:55 | |
| -!- 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 | 03:56 | |
| -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards | 04:04 | |
| -!- erasmosp_ [~erasmospu@179.43.156.130] has joined #bitcoin-wizards | 04:07 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 04:07 | |
| 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: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-wizards | 04:20 | |
| -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has quit [Remote host closed the connection] | 04:27 | |
| -!- gill3s [~gill3s@unaffiliated/gill3s] has joined #bitcoin-wizards | 04: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-wizards | 04: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-wizards | 04:42 | |
| -!- gmaxwell is now known as Guest69884 | 04: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-wizards | 04:54 | |
| -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has joined #bitcoin-wizards | 05:04 | |
| -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards | 05: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-wizards | 05:27 | |
| -!- GAit [~GAit@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards | 05: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-wizards | 05:43 | |
| -!- 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: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-wizards | 06:11 | |
| -!- jtimon [~quassel@172.56.6.239] has joined #bitcoin-wizards | 06: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-wizards | 06: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-wizards | 06: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-wizards | 06:48 | |
| -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards | 06:50 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 06: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-wizards | 06: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-wizards | 07:06 | |
| -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards | 07:07 | |
| -!- JackH [~Jack@host-80-43-143-151.as13285.net] has joined #bitcoin-wizards | 07:13 | |
| -!- jinglebellz [~jinglebel@149.130.142.147] has joined #bitcoin-wizards | 07: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-wizards | 07:24 | |
| -!- adam3us [~Adium@modemcable160.86-162-184.mc.videotron.ca] has joined #bitcoin-wizards | 07:24 | |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 07:25 | |
| -!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards | 07:31 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 07:35 | |
| -!- bsm1175321 [~bsm117532@38.121.165.30] has joined #bitcoin-wizards | 07: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 heIo | 07:48 | |
| -!- heIo is now known as he1o | 07:48 | |
| -!- he1o is now known as helo | 07:48 | |
| -!- wizkid057 is now known as wk | 07:49 | |
| -!- wk is now known as wizkid | 07:50 | |
| -!- wizkid is now known as wizkidO57 | 07:50 | |
| -!- 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:51 | |
| -!- eudoxia_ [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 07: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-wizards | 08: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-wizards | 08: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-wizards | 08:20 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 08: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 | |
| JackH | are 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-wizards | 08:38 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .] | 08:41 | |
| 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:43 |
| 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:45 |
| JackH | ah yes that | 08:46 |
| JackH | hmm this should be indexed and stored better | 08:47 |
| JackH | you have anything from DNA crypto to Bitcoin crypto | 08:48 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 255 seconds] | 08:53 | |
| -!- MrHodl [~fuc@185.22.183.196] has joined #bitcoin-wizards | 08:54 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .] | 08:59 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 08:59 | |
| -!- 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:00 |
| 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:01 |
| 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: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 | |
| kanzure | sounds like you mean the citation graph | 09:07 |
| 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:08 |
| kanzure | JackH: he means http://diyhpl.us/wiki/transcripts/scalingbitcoin/systematizing-knowledge/ | 09:09 |
| 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:11 |
| 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:13 |
| -!- 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:14 |
| 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:15 | |
| 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:18 |
| JackH | what 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-wizards | 09:21 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 09:22 | |
| 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:23 |
| JackH | hmmm, yeah there is this as well | 09:24 |
| -!- davec [~davec@cpe-24-243-239-16.hot.res.rr.com] has joined #bitcoin-wizards | 09:25 | |
| JackH | are you constantly adding new material kanzure? | 09:26 |
| kanzure | usually | 09: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-wizards | 09:36 | |
| -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has quit [Quit: ...sleep] | 09:37 | |
| 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:42 |
| -!- GAit [~GAit@208.54.86.233] has joined #bitcoin-wizards | 09:48 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 09:49 | |
| -!- PaulCape_ [~PaulCapes@199.19.94.16] has joined #bitcoin-wizards | 09: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-wizards | 09:53 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds] | 09:53 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards | 09:56 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 09:57 | |
| -!- PaulCape_ [~PaulCapes@199.19.94.16] has quit [Ping timeout: 240 seconds] | 09:59 | |
| -!- 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: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-wizards | 10:05 | |
| -!- neha [~textual@dhcp-18-111-16-16.dyn.mit.edu] has joined #bitcoin-wizards | 10:06 | |
| -!- 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: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-wizards | 10: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-wizards | 10: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-wizards | 10: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-wizards | 10: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-wizards | 10:32 | |
| -!- 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: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-wizards | 10:42 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 10:48 | |
| -!- 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:50 | |
| maaku | yay seL4 is on github: https://github.com/seL4/seL4 | 10:51 |
| -!- zooko_ [~Android@172.56.32.38] has joined #bitcoin-wizards | 10: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-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 | 10:55 | |
| 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: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-wizards | 11:04 | |
| 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: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-wizards | 11: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-wizards | 11:18 | |
| -!- 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:20 | |
| -!- 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:24 | |
| maaku | nsh: it's the closest we can get | 11:26 |
| * nsh nods | 11:27 | |
| 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:28 |
| 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:29 |
| 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:30 |
| -!- 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: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-wizards | 11:36 | |
| -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 11:37 | |
| -!- maaku is now known as Guest87378 | 11: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-wizards | 11: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-wizards | 11: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-wizards | 11: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-wizards | 11: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-wizards | 12:03 | |
| BlueMatt | Taek: anything that people in this channel would generally consider smart/interesting | 12:04 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 12:04 | |
| -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 12: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 | |
| BlueMatt | also @bitcoin.ninja emails | 12:10 |
| -!- 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:11 |
| 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:12 |
| maaku | that's a remarkably far way along | 12:13 |
| nsh | indeed | 12:13 |
| -!- 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:14 |
| -!- 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:15 | |
| -!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards | 12:23 | |
| -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards | 12:24 | |
| -!- Madars_ is now known as Madars | 12:28 | |
| -!- 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: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-wizards | 12:33 | |
| -!- jinglebellz [~jinglebel@149.130.224.111] has joined #bitcoin-wizards | 12: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 | |
| phantomcircuit | runeks, are you Rune Kjær Svendsen ? | 12:46 |
| runeks | phantomcircuit: Yes | 12:46 |
| -!- 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:47 |
| 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:48 | |
| -!- 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:50 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards | 12:52 | |
| TD-Linux | maaku, yeah the verifiably correct part is pretty neat. the functionality of seL4 is ultra minimal though | 13:00 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] | 13:03 | |
| 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:04 |
| -!- zooko [~Android@172.56.32.189] has joined #bitcoin-wizards | 13: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-wizards | 13:16 | |
| -!- neha [~textual@c-73-17-151-171.hsd1.ma.comcast.net] has joined #bitcoin-wizards | 13:16 | |
| runeks | phantomcircuit: I've responded :) | 13:18 |
| -!- thesnark [~mgrube@unaffiliated/thesnark] has joined #bitcoin-wizards | 13:20 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer] | 13:22 | |
| -!- 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: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 | |
| maaku | anyone 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-wizards | 13:34 | |
| 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:35 | |
| -!- 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:36 |
| CodeShark | bah, wrong handle - committing to the utxo set alone is probably insufficient - we need other partial checks to make this secure | 13:38 |
| 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:40 | |
| -!- 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: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-wizards | 13:42 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Client Quit] | 13:43 | |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 | |
| maaku | (put it at the end of the transaction for midstate compression hack) | 13:48 |
| MRL-Relay | [tacotime] Oh, I see. | 13:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| -!- 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:58 |
| 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. | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 | |
| 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:03 |
| 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:04 |
| 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:05 |
| 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: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 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| -!- 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:11 |
| bramc | kanzure, Right, I'm proposing doing the same trick in the large for the utxo root as a whole | 14:12 |
| maaku | bramc: btw you should look at mmr's for inseration-ordered full-txout commitments | 14:13 |
| 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:14 |
| 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:15 |
| 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:16 | |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 | |
| 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:23 |
| 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:24 |
| -!- 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:25 |
| -!- 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:26 |
| -!- 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 | |
| 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:32 |
| -!- 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:39 |
| CodeShark | think git...except enforce rules regarding how files can change...and require a PoW timestamp for each commitment :) | 14:40 |
| CodeShark | then optimize the crap out of it | 14:41 |
| -!- Starduster [~guest@unaffiliated/starduster] has quit [] | 14:41 | |
| -!- adam3us [~Adium@172.56.12.182] has quit [Quit: Leaving.] | 14:42 | |
| 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:43 |
| 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:44 |
| 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:45 | |
| bramc | maaku, Oh I see now. I'll have to think about that. | 14:46 |
| 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:48 |
| maaku | yay standards that were never actually used for their intended purpose before becoming standards | 14:49 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] | 14:50 | |
| 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:52 |
| 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:53 |
| 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:54 |
| -!- Guest68337 [~audioishi@blackmain.media.mit.edu] has joined #bitcoin-wizards | 14:57 | |
| -!- 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:58 | |
| bramc | Or 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-wizards | 15:00 | |
| -!- orik [~orik@50.125.71.245] has joined #bitcoin-wizards | 15: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 | |
| 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:03 |
| 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:04 | |
| -!- 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:05 |
| -!- kang_ [67efe97d@gateway/web/freenode/ip.103.239.233.125] has joined #bitcoin-wizards | 15:06 | |
| 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:07 |
| 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:08 |
| 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:09 |
| 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: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-wizards | 15:11 | |
| CodeShark | in any case we're trading something off - right now, we're basically sacrificing thin client security ;) | 15:11 |
| 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:12 |
| CodeShark | right now I don't really even have that option - I basically have to run a full node | 15:13 |
| 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:14 | |
| -!- 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:16 | |
| 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:17 | |
| -!- shen_noe [~shen_noe@104.156.228.98] has joined #bitcoin-wizards | 15: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 | |
| 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:22 | |
| -!- zooko [~Android@75.111.103.164] has joined #bitcoin-wizards | 15:23 | |
| 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:24 | |
| 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:25 |
| bramc | Basically they have 3x the work because they're updating 3 deltas instead of a single root | 15:27 |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 15:28 | |
| 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:29 | |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| -!- 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:34 |
| CodeShark | and if the incentives are there people will look for further optimizations | 15:35 |
| 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:36 | |
| 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:38 |
| 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:39 |
| 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:40 |
| -!- 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:42 |
| -!- 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:43 |
| -!- eudoxia [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 15:45 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 15: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-wizards | 15:54 | |
| -!- 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 | 15:58 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 16: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 | |
| 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:11 |
| 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:12 |
| bramc | This particularly matters on a device which has to hold the utxo set on disk | 16:13 |
| 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:16 |
| 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:17 |
| CodeShark | so 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-wizards | 16:21 | |
| -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection] | 16:22 | |
| 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:23 |
| -!- eudoxia [~eudoxia@r167-56-135-26.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 16:24 | |
| 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:25 |
| CodeShark | ah! | 16:26 |
| CodeShark | of 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 | |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:32 | |
| 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:33 |
| -!- 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:34 |
| 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:37 |
| 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:38 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 16:42 | |
| 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:43 |
| -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has quit [Remote host closed the connection] | 16:44 | |
| 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:45 | |
| -!- memymo [~textual@c-24-4-69-49.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 16:47 | |
| bramc | No 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-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: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-wizards | 17:02 | |
| -!- rando1 [126f4f55@gateway/web/freenode/ip.18.111.79.85] has joined #bitcoin-wizards | 17:02 | |
| 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:04 |
| -!- _2drewlee [~textual@104.220.67.131] has joined #bitcoin-wizards | 17: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-wizards | 17:13 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 17:15 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 17: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-wizards | 17: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-wizards | 17: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-wizards | 17: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-wizards | 17: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 c0rw1n | 17: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-wizards | 17: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-wizards | 18:21 | |
| -!- Guest10 [~textual@104.220.67.131] has quit [Client Quit] | 18:22 | |
| 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:33 |
| -!- adlai [~adlai@unaffiliated/adlai] has joined #bitcoin-wizards | 18: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-wizards | 18:55 | |
| -!- Guest10 [~textual@104.220.67.131] has joined #bitcoin-wizards | 18:56 | |
| -!- 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: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-wizards | 19:05 | |
| 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: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-wizards | 19: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-wizards | 19:28 | |
| -!- adam3us [~Adium@172.56.12.164] has quit [Ping timeout: 264 seconds] | 19:33 | |
| -!- agorecki [~agorecki@unaffiliated/agorecki] has joined #bitcoin-wizards | 19:42 | |
| -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.MIT.EDU] has joined #bitcoin-wizards | 19: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-wizards | 19: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-wizards | 19:53 | |
| -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards | 19: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-wizards | 19:58 | |
| -!- bliljerk101 [~bliljerk1@pool-74-109-193-20.pitbpa.fios.verizon.net] has joined #bitcoin-wizards | 19: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-wizards | 20: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-wizards | 20: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-wizards | 20: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-wizards | 20:53 | |
| -!- mrbd [~bd@50.40.201.237] has joined #bitcoin-wizards | 20:55 | |
| -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] | 20:57 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:58 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 21:03 | |
| -!- MrHodl [~fuc@185.22.183.196] has quit [] | 21:05 | |
| -!- shredder_ [~marcinja@18.189.89.168] has joined #bitcoin-wizards | 21: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-wizards | 21:17 | |
| -!- orik [~orik@c-71-227-207-191.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 21: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-wizards | 21: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-wizards | 21:45 | |
| -!- 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:48 | |
| -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has quit [Client Quit] | 21:50 | |
| -!- ak_ is now known as akstunt600 | 21:51 | |
| -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 21: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-wizards | 21: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-wizards | 22:12 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards | 22:13 | |
| -!- tbmit [~Bair@c-66-30-12-236.hsd1.ma.comcast.net] has joined #bitcoin-wizards | 22: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-wizards | 22: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-wizards | 22:56 | |
| -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 23:04 | |
| -!- certee7 [~textual@124-149-119-223.dyn.iinet.net.au] has joined #bitcoin-wizards | 23: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-wizards | 23:15 | |
| -!- shredder_ [~marcinja@dhcp-18-189-89-168.dyn.mit.edu] has joined #bitcoin-wizards | 23: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-wizards | 23:37 | |
| -!- Starduster [~sd@unaffiliated/starduster] has joined #bitcoin-wizards | 23: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-wizards | 23: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!