--- Log opened Mon Dec 07 00:00:30 2015 00:01 -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards 00:01 -!- wallet42 [~wallet42@202.83.241.187] has quit [Quit: Leaving.] 00:04 -!- memymo [~textual@202.171.211.253] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 00:06 -!- dstadulis [~dstadulis@202.83.241.187] has joined #bitcoin-wizards 00:07 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 00:08 -!- nivah [~linker@115.79.55.177] has joined #bitcoin-wizards 00:09 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:09 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:10 -!- adam3us [~Adium@202.83.241.113] has joined #bitcoin-wizards 00:10 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:10 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:10 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Ping timeout: 260 seconds] 00:11 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 00:11 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:11 -!- wallet42 [~wallet42@202.83.241.187] has quit [Remote host closed the connection] 00:14 -!- taek42- [~david@202.83.241.187] has joined #bitcoin-wizards 00:14 -!- AaronvanW [~ewout@202.83.241.187] has joined #bitcoin-wizards 00:14 -!- AaronvanW [~ewout@202.83.241.187] has quit [Changing host] 00:14 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 00:15 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:15 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:17 -!- adam3us [~Adium@202.83.241.113] has quit [Quit: Leaving.] 00:19 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:19 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:22 -!- adam3us [~Adium@202.83.241.113] has joined #bitcoin-wizards 00:22 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:22 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 00:22 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:22 -!- adam3us [~Adium@202.83.241.113] has quit [Client Quit] 00:27 -!- p15 [~p15@68.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards 00:27 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:27 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:30 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:30 -!- wallet42 [~wallet42@202.83.241.187] has quit [Remote host closed the connection] 00:34 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 00:34 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:34 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:37 -!- dstadulis [~dstadulis@202.83.241.187] has quit [Quit: ZZZzzz…] 00:37 -!- adam3us [~Adium@202.83.241.113] has joined #bitcoin-wizards 00:38 -!- adam3us [~Adium@202.83.241.113] has quit [Client Quit] 00:41 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 00:42 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:42 -!- wallet42 [~wallet42@202.83.241.187] has quit [Remote host closed the connection] 00:44 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 00:44 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 00:45 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer] 00:47 -!- tulip [~tulip@unaffiliated/tulip] has quit [Ping timeout: 264 seconds] 00:47 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards 00:48 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:48 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:48 -!- adam3us [~Adium@202.83.241.113] has joined #bitcoin-wizards 00:48 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 245 seconds] 00:50 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:50 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:51 -!- dstadulis [~dstadulis@202.83.241.187] has joined #bitcoin-wizards 00:52 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:52 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:53 -!- memymo [~textual@202.171.211.253] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 00:53 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:53 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:55 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:55 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:56 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] 00:56 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] 00:56 -!- adam3us [~Adium@202.83.241.113] has quit [Quit: Leaving.] 00:56 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds] 00:57 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 00:57 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 00:58 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards 00:58 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards 00:58 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards 00:59 -!- dstadulis [~dstadulis@202.83.241.187] has quit [Quit: ZZZzzz…] 01:00 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 01:00 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 01:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] 01:08 -!- dstadulis [~dstadulis@202.83.241.187] has joined #bitcoin-wizards 01:09 -!- rgrant [~user@14.0.209.109] has quit [Ping timeout: 245 seconds] 01:11 -!- pozitron [~nu@109.201.143.40] has quit [Ping timeout: 260 seconds] 01:12 -!- rustyn [~rustyn@unaffiliated/rustyn] has joined #bitcoin-wizards 01:14 -!- Lightsword [~Lightswor@104.194.125.34] has quit [Quit: Lightsword] 01:14 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] 01:15 -!- dEBRUYNE [~dEBRUYNE@88.159.197.56] has joined #bitcoin-wizards 01:17 -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards 01:18 -!- p15_ [~p15@119.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards 01:19 -!- p15 [~p15@68.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 260 seconds] 01:22 -!- Alanius_ is now known as Alanius 01:23 -!- rgrant [~user@14.0.209.109] has quit [Ping timeout: 246 seconds] 01:25 -!- tulip [~tulip@unaffiliated/tulip] has quit [Ping timeout: 264 seconds] 01:27 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 01:28 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards 01:28 -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-wizards 01:30 -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] 01:31 -!- pozitrono [nu@gateway/vpn/mullvad/x-udidrjlzdcuoidtq] has joined #bitcoin-wizards 01:33 -!- gielbier [~giel____@unaffiliated/gielbier] has quit [Quit: Leaving] 01:35 -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards 01:36 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 01:46 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 01:46 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 01:49 -!- p15 [~p15@30.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards 01:49 -!- p15_ [~p15@119.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 246 seconds] 01:50 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 260 seconds] 01:51 -!- dstadulis [~dstadulis@202.83.241.187] has quit [Quit: ZZZzzz…] 01:51 -!- rgrant [~user@14.0.209.109] has quit [Ping timeout: 260 seconds] 01:52 -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards 01:53 -!- taek42- [~david@202.83.241.187] has quit [Ping timeout: 246 seconds] 01:55 -!- matsjj [~matsjj@89.197.31.78] has joined #bitcoin-wizards 01:55 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] 02:04 -!- roconnor__ [~roconnor@45.58.251.219] has joined #bitcoin-wizards 02:04 -!- roconnor_ [~roconnor@host-45-58-248-193.dyn.295.ca] has quit [Ping timeout: 245 seconds] 02:04 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards 02:12 < tulip> frankenmint: they're TCP packet types really. 02:12 < tulip> we need a reason to RESET pull requests. 02:13 -!- GGuyZ [~GGuyZ@202.83.241.113] has quit [Quit: GGuyZ] 02:24 -!- GGuyZ [~GGuyZ@202.83.241.113] has joined #bitcoin-wizards 02:28 -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Ping timeout: 264 seconds] 02:33 -!- rgrant [~user@14.0.209.109] has quit [Ping timeout: 260 seconds] 02:34 -!- GGuyZ [~GGuyZ@202.83.241.113] has quit [Ping timeout: 260 seconds] 02:36 -!- dEBRUYNE [~dEBRUYNE@88.159.197.56] has quit [Ping timeout: 260 seconds] 02:38 -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards 02:40 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 02:40 -!- GGuyZ [~GGuyZ@202.83.241.113] has joined #bitcoin-wizards 02:42 -!- forrestv [forrestv@unaffiliated/forrestv] has joined #bitcoin-wizards 02:43 -!- dEBRUYNE [~dEBRUYNE@88.159.197.56] has joined #bitcoin-wizards 02:43 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 02:47 -!- zooko [~zooko@202.83.241.113] has joined #bitcoin-wizards 02:48 -!- shesek [~shesek@bzq-84-110-36-12.cablep.bezeqint.net] has quit [Ping timeout: 245 seconds] 02:49 -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Ping timeout: 264 seconds] 02:56 -!- dstadulis [~dstadulis@202.83.241.187] has joined #bitcoin-wizards 02:56 -!- dstadulis [~dstadulis@202.83.241.187] has quit [Client Quit] 02:57 -!- forrestv [forrestv@unaffiliated/forrestv] has joined #bitcoin-wizards 02:58 -!- p15 [~p15@30.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 260 seconds] 02:59 -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Excess Flood] 02:59 -!- dEBRUYNE [~dEBRUYNE@88.159.197.56] has quit [Quit: Leaving] 03:00 -!- forrestv [forrestv@unaffiliated/forrestv] has joined #bitcoin-wizards 03:00 -!- rgrant [~user@14.0.209.109] has quit [Quit: leaving] 03:02 -!- GGuyZ [~GGuyZ@202.83.241.113] has quit [Quit: GGuyZ] 03:05 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 03:06 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 03:08 -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [Remote host closed the connection] 03:09 -!- zooko [~zooko@202.83.241.113] has quit [Read error: Connection reset by peer] 03:09 -!- zooko [~zooko@202.83.241.113] has joined #bitcoin-wizards 03:12 -!- tulip [~tulip@unaffiliated/tulip] has quit [Ping timeout: 264 seconds] 03:12 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards 03:15 -!- zooko [~zooko@202.83.241.113] has quit [Ping timeout: 260 seconds] 03:27 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] 03:32 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] 03:33 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] 03:33 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds] 03:34 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards 03:35 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards 03:35 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards 03:38 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-anjolmhqcjsrzgmb] has joined #bitcoin-wizards 03:46 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 03:51 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 246 seconds] 03:57 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 245 seconds] 04:04 -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards 04:05 -!- nivah [~linker@115.79.55.177] has quit [Ping timeout: 260 seconds] 04:08 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] 04:11 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 04:19 < maaku> pigeons: (re: freinames) eventually. freiname's real utility is for things like capabilities -- e.g. an asset reissuance key 04:19 < maaku> it was just a bit too much complexity to include in v1 04:19 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ycoquifyrwpgdjew] has quit [Ping timeout: 264 seconds] 04:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-recrkoozibopkqsc] has joined #bitcoin-wizards 04:23 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] 04:26 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 04:26 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-odassgozvtrvazur] has joined #bitcoin-wizards 04:27 -!- hashtag_ [~hashtag@174.97.254.80] has quit [Ping timeout: 260 seconds] 04:33 -!- hashtag_ [~hashtag@174.97.254.80] has joined #bitcoin-wizards 04:33 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 04:41 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 04:43 -!- Casper- [~Casper@garza.riseup.net] has quit [Ping timeout: 260 seconds] 04:45 -!- c0rw|zZz_ [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 04:48 -!- c0rw|zZz [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 246 seconds] 04:49 -!- Casper- [~Casper@garza.riseup.net] has joined #bitcoin-wizards 04:49 -!- aem [AEM@gateway/shell/elitebnc/x-nbggsjfuwlsaarhp] has quit [Remote host closed the connection] 04:51 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 04:52 -!- c0rw|zZz [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 04:55 -!- c0rw|zZz_ [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds] 04:56 -!- AEM [AEM@gateway/shell/elitebnc/x-dprxesqlyuschtkh] has joined #bitcoin-wizards 05:02 -!- kyluke [~fnb@41.147.46.100] has joined #bitcoin-wizards 05:11 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 05:15 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards 05:39 -!- markus-k [~markus-k@designnet.work.de] has joined #bitcoin-wizards 05:39 -!- markus-k [~markus-k@designnet.work.de] has quit [Client Quit] 05:39 -!- shesek [~shesek@bzq-84-110-212-71.cablep.bezeqint.net] has joined #bitcoin-wizards 05:39 -!- markus-k [~markus-k@designnet.work.de] has joined #bitcoin-wizards 05:39 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 05:39 -!- paci [~paci@host41-233-static.58-79-b.business.telecomitalia.it] has quit [Quit: Leaving] 05:46 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 245 seconds] 05:55 -!- AEM is now known as aem 05:57 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 06:08 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] 06:16 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 265 seconds] 06:16 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 06:17 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 06:17 -!- joesmoe [~joesmoe@76.73.18.156] has quit [Ping timeout: 265 seconds] 06:17 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Ping timeout: 265 seconds] 06:21 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-anjolmhqcjsrzgmb] has quit [Quit: Connection closed for inactivity] 06:21 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 250 seconds] 06:22 -!- Starduster_ [~guest@unaffiliated/starduster] has joined #bitcoin-wizards 06:23 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-wizards 06:23 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 246 seconds] 06:23 -!- K1773R [~K1773R@unaffiliated/k1773r] has quit [Ping timeout: 246 seconds] 06:23 -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has quit [Ping timeout: 246 seconds] 06:23 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-wizards 06:23 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Changing host] 06:23 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-wizards 06:24 -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has joined #bitcoin-wizards 06:24 -!- joesmoe [~joesmoe@76.73.18.156] has joined #bitcoin-wizards 06:25 -!- K1773R [~K1773R@unaffiliated/k1773r] has joined #bitcoin-wizards 06:25 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-odassgozvtrvazur] has quit [Ping timeout: 245 seconds] 06:25 -!- runeks [sid21167@gateway/web/irccloud.com/x-czfbyiqjzfuosxkj] has quit [Ping timeout: 245 seconds] 06:26 -!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 260 seconds] 06:26 -!- bassguitarman [sid40024@gateway/web/irccloud.com/x-xadyoeerqfqlcuea] has quit [Ping timeout: 260 seconds] 06:27 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 260 seconds] 06:27 -!- wpalczynski [sid55851@gateway/web/irccloud.com/x-mqevlmwthsmpzcfq] has quit [Ping timeout: 260 seconds] 06:27 -!- kumavis [sid13576@gateway/web/irccloud.com/x-mzudkxmvzwllasly] has quit [Ping timeout: 245 seconds] 06:30 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-yrkdqwrxgcfytrlf] has joined #bitcoin-wizards 06:32 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 06:32 -!- kumavis [sid13576@gateway/web/irccloud.com/x-pnbijhxgrwgwqipi] has joined #bitcoin-wizards 06:34 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-wizards 06:34 -!- maaku is now known as Guest35069 06:35 -!- runeks [sid21167@gateway/web/irccloud.com/x-zgsgralqsgcbwxzt] has joined #bitcoin-wizards 06:35 -!- wpalczynski [sid55851@gateway/web/irccloud.com/x-ytpoicftbcchyyha] has joined #bitcoin-wizards 06:37 -!- c0rw|zZz_ [~c0rw1n@48.129-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 06:37 -!- c0rw|zZz [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds] 06:40 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards 06:40 -!- pozitrono [nu@gateway/vpn/mullvad/x-udidrjlzdcuoidtq] has quit [Ping timeout: 260 seconds] 06:40 -!- c0rw|zZz [~c0rw1n@91.176.115.20] has joined #bitcoin-wizards 06:43 -!- c0rw|zZz_ [~c0rw1n@48.129-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds] 06:46 -!- Casper- [~Casper@garza.riseup.net] has quit [Ping timeout: 246 seconds] 06:46 -!- TBI [~TBI@20.84-48-195.nextgentel.com] has quit [Ping timeout: 246 seconds] 06:49 -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 06:50 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 06:52 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 06:53 -!- bassguitarman [sid40024@gateway/web/irccloud.com/x-univssspdrqzwjzu] has joined #bitcoin-wizards 06:53 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 06:54 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] 06:55 -!- memymo [~textual@202.171.211.253] has quit [Client Quit] 06:55 -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 06:55 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 06:59 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 06:59 -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 07:00 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 07:01 -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has joined #bitcoin-wizards 07:02 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 07:02 -!- Casper- [~Casper@garza.riseup.net] has joined #bitcoin-wizards 07:02 -!- wallet42 [~wallet42@pcd535135.netvigator.com] has joined #bitcoin-wizards 07:02 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 07:03 -!- memymo [~textual@202.171.211.253] has quit [Client Quit] 07:04 -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 07:05 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 07:07 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 07:09 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 07:12 -!- roconnor__ [~roconnor@45.58.251.219] has quit [Quit: Konversation terminated!] 07:12 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 07:12 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-imkciojtlmbbmjjp] has quit [Read error: Connection reset by peer] 07:12 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-vqyqhnvddknqgsyy] has joined #bitcoin-wizards 07:13 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 256 seconds] 07:14 -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 07:15 -!- memymo [~textual@202.171.211.253] has quit [Client Quit] 07:17 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 07:18 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 07:21 -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 07:24 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 07:24 < kanzure> lightning scalability matrix table from the slides http://web.archive.org/web/20151207152438/https://pbs.twimg.com/media/CVlmXyqUwAAlYfS.jpg:large 07:25 -!- markus-k [~markus-k@designnet.work.de] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 07:25 < kanzure> with OP_CLTV and with/without OP_CSV etc. 07:26 -!- GGuyZ [~GGuyZ@202.171.211.253] has joined #bitcoin-wizards 07:27 -!- dstadulis [~dstadulis@202.171.211.253] has joined #bitcoin-wizards 07:28 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 07:28 -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 07:29 < oldbrew> so much for ROI 07:31 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 07:35 < oldbrew> too many cooks spoil the broth 07:36 < oldbrew> might be better if they acted like a team at least 07:37 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 07:37 -!- memymo [~textual@202.171.211.253] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 07:38 -!- TBI [~TBI@20.84-48-195.nextgentel.com] has joined #bitcoin-wizards 07:43 -!- dstadulis [~dstadulis@202.171.211.253] has quit [Quit: Textual IRC Client: www.textualapp.com] 07:48 -!- kyluke [~fnb@41.147.46.100] has quit [Read error: Connection reset by peer] 08:05 -!- eudoxia [~eudoxia@r186-49-241-192.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 08:05 -!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has quit [Ping timeout: 276 seconds] 08:07 -!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards 08:13 -!- adam3us [~Adium@45.64.240.161] has joined #bitcoin-wizards 08:20 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Quit: Leaving] 08:22 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] 08:25 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards 08:35 < kanzure> 08:32 < jl2012> by the way, as the witness data is only about 60% of the current tx size, a softfork would only allow 1/(1-0.6)=2.5MB at maximum. How could that be 4MB? 08:36 -!- jl2012 [~jl2012@119246245241.ctinets.com] has joined #bitcoin-wizards 08:40 < jl2012> sipa: as the witness data is only about 60% of the current tx size, a softfork would only allow 1/(1-0.6)=2.5MB at maximum. How could that be 4MB? Do you mean 4MB is the ceiling but it is impossible to reach (in a normal situation)? 08:41 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-wizards 08:43 < tromp__> is 75% the max fraction of sig size in a tx? 08:47 < jl2012> i think in theory it could approach 100%, as it is possible to include extra push in the scriptSig while the tx is still valid 08:48 -!- digitalmagus8 [~digitalma@unaffiliated/digitalmagus] has quit [] 08:49 < instagibbs> jl2012, right in the talk: "This is my proposal that we do right now. We implement segregated witness right now, soon. What we do is discount the witness data by 75% for block size. So this enables us to say we allow 4x as many signatures in the chain. What this normally corresponds to, with a difficult transaction load, this is around 75% capacity increase for transactions that choose to use it. Another way of looking at it, is that we 08:49 < instagibbs> raise the block size to 4 MB for the witness part, but the non-witness has same size. The reason for doing the discount, last slide, the reason for doing this discount is that it disincentivizes UTXO impact. A signature that doesn't go into the UTXO set, can be pruned." 08:49 -!- Casper- [~Casper@garza.riseup.net] has quit [Read error: Connection reset by peer] 08:51 < jl2012> this 75% figure contradicts with the graph in the slide 08:51 < tromp__> leaving out witness data is clear. not sure what "discount by 75%" means though 08:52 < jl2012> it shows the actual blockchain size is ~50GB, while blockchain without witness is ~20GB. That's why I say "witness" takes about 60% 08:54 < oldbrew> and with indexing ? 08:55 < instagibbs> jl2012, he's talking about a soft fork increase of blocksize, essentially. Not what is there now. 08:55 < instagibbs> I gtg but im assuming he'll pop in sometime 08:57 < jl2012> instagibbs: if I understand correctly, he means to have a new script lang. People will send to a new version of scriptPubKey, which looks like an "anyone-can-spend" script in current script lang. 08:58 < jl2012> old nodes will allow spending of such output with an empty scriptSig. upgraded will will require extra data (ie. witness) 08:59 < oldbrew> and the timestamp issue ? 08:59 < jl2012> old nodes will not see the winess. But it will still see the rest, including version, sequence, outputs, and locktime 09:00 < jl2012> and the total size of these components must not be bigger than 1MB or that will be a hardfork 09:01 < oldbrew> https://en.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time 09:02 < oldbrew> At 06:28:15 UTC on Sunday, 7 February 2106, the Unix time will reach FFFFFFFF16 or 4,294,967,295 seconds which, for systems that hold the time on 32 bit unsigned numbers, is the maximum attainable. For these systems, the next second will be incorrectly interpreted as 00:00:00 Thursday 1 January 1970 UTC. 09:03 < oldbrew> https://en.bitcoin.it/wiki/Protocol_documentation#cite_note-2 09:04 < kanzure> i have updated most of the hong kong transcripts to include links to supporting materials and slides etc https://github.com/kanzure/diyhpluswiki/commit/d5cd3df21a13aa3bb4aa7b4f7b21fc05e9d006e9 09:05 -!- Guest35069 is now known as maaku 09:09 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 09:12 -!- eudoxia [~eudoxia@r186-49-241-192.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 09:14 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 272 seconds] 09:15 < maaku> brg444: I disagree with Pieter's accounting methodology in his segwitness branch 09:16 < wallet42> so the witnesses will also be in a shadow block referenced via a merkle tree comitted to coinbase? 09:16 < maaku> wallet42: yes, essentially 09:16 < instagibbs> jl2012, Yes. You have to hard cap the segwit size too, which I'm assuming is where he comes up with 4MB 09:16 < maaku> my preference would be to not count the witness size at all -- except for some very high engineering limit, e.g. combined 32MB block+witness size 09:16 < wallet42> is there a datastructure for these witnesses? 09:17 < brg444> interesting 09:17 < instagibbs> merkle tree, like any good crypto system 09:17 < wallet42> i mean, it must reference a transaction id and stuff 09:17 < maaku> but impose a new cap which uses the validation-cost metric as described by jonas 09:17 -!- pozitron [~nu@89.248.174.14] has joined #bitcoin-wizards 09:17 < instagibbs> wallet42, 2 parallel merkle trees 09:18 < jl2012> maaku: so people may fill the block up to 32MB by putting ignorable pushes in the witness? 09:18 < maaku> and have that validation-cost limit scale over time ... a fixed schedule for the next few years 09:18 < wallet42> so whats the average transaction size then? 09:19 < maaku> then switch from fixed schedule to flexcap when the hard fork is finally instituted for >1MB old-block size 09:19 < maaku> (we'd be closer to fee market dominated by then) 09:20 < maaku> jl2012: jonas' work counts size as a cost, because of relay costs. you would not be able to fill 32MB at first 09:21 < brg444> what's your take on the suggested 4mb increase with regards to bandwidth? lukejr seemed not to be sold on the idea? 09:22 < wallet42> the blocksize w/o the whiness will be 1 mb afaiu 09:22 < wallet42> the witness data will be stored in 3 mb 09:23 < brg444> I understand that certainly makes it more efficient but witness data still has to be relayed by all full nodes..? 09:23 < maaku> brg444: I would prefer a smaller validation-cost metric, which would result in ~1MB blocks or smaller 09:23 < maaku> but with a growth schedule for that limit 09:25 < maaku> brg444: in other words I agree with Luke-Jr 09:25 < brg444> I see. I'll have to watch Jonas talk. It was getting late over here. 09:26 < maaku> i believe that sipa thinks 4MB is something on the very high end of what we could support, and that is probably right 09:26 < maaku> but IMHO we should keep more buffer room. so impose a separate, smaller limit that grows 09:27 < brg444> Right. From where I stand the ability to softfork the limit allows us some flexibility with regards to making the first increase more conservative 09:27 < brg444> +1 09:27 < instagibbs> Question: If/when hardfork happens, will thinks like softfork SW be re-drawn up using "obvious" hardfork design? 09:27 < instagibbs> or will this depend on how much PITA it is for wallets 09:27 < maaku> first on fixed schedule, because there is no fee market, then flexcap in a few years (when we have to do the hard fork) 09:28 < jl2012> I actually prefer a hardfork for segwit, as we may need a hardfork anyway (e.g. fix for timewarp) 09:28 < maaku> brg444: going the way I suggest also means that we could support witnesses larger than 3MB 09:29 < maaku> something like CT would h ave a very large witness, for example, so maybe we want the ability to have 20MB witness with a 1MB non-witness block 09:30 < maaku> we can't support that now (effectively a 21MB block), but we could leave the capability to grow in that way, rather than impose a new hard-limit at 4MB 09:31 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards 09:31 < jl2012> maaku: what is CT? 09:31 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards 09:31 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 09:31 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards 09:32 < wallet42> confidential transactions? 09:32 < maaku> yes, confidential transactions 09:34 -!- bendavenport [~bpd@96.90.231.161] has joined #bitcoin-wizards 09:35 < jl2012> instagibbs: I guess if we impletemented it as softfork at the begining, we will never change the design even if we have a hardfork in the future. As that invloves extra work and risk 09:36 -!- bhollan [~hollabr@177.237.169.171] has joined #bitcoin-wizards 09:36 -!- aem [AEM@gateway/shell/elitebnc/x-dprxesqlyuschtkh] has quit [Ping timeout: 260 seconds] 09:37 -!- bhollan [~hollabr@177.237.169.171] has left #bitcoin-wizards [] 09:39 < maaku> jl2012: the commitment location would almost certainly be moved in a hard fork the minimize and remove variance from hard fork size 09:41 < maaku> with some clever work you could still keep the commitment in the old location as well so it is less disruptive, but the benefit from moving the location is well worth it 09:42 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-wizards 09:47 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards 09:47 -!- AEM [AEM@gateway/shell/elitebnc/x-lhnzqmikxfwduvsg] has joined #bitcoin-wizards 09:48 -!- opitka [~0ptika@50.248.81.65] has quit [Quit: Leaving] 09:49 < morcos> maaku: Aren't you worried that very large witness sizes will make it hard to run a full node? 09:52 < oldbrew> or invalid der signature with leap second issue 09:59 -!- GfxdjGFhgF [~KHDXGFHGh@86.121.179.34] has joined #bitcoin-wizards 10:05 < tromp__> i thought full nodes would verify new SW blocks by reconstructing the witness merkle tree from their memory pool 10:06 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-vqyqhnvddknqgsyy] has quit [Quit: Connection closed for inactivity] 10:11 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds] 10:14 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Quit: leaving] 10:14 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-wizards 10:16 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Client Quit] 10:17 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-wizards 10:23 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] 10:25 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards 10:29 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] 10:32 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards 10:36 -!- AEM is now known as aem 10:38 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] 10:38 -!- CubicEar_ [~cubiceart@50.141.34.192] has joined #bitcoin-wizards 10:41 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards 10:45 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] 10:46 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] 10:48 -!- CubicEarth [~cubiceart@50.141.34.192] has joined #bitcoin-wizards 10:48 -!- CubicEar_ [~cubiceart@50.141.34.192] has quit [Ping timeout: 250 seconds] 10:49 -!- TBI_ [~TBI@84.48.195.20] has joined #bitcoin-wizards 10:49 -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards 10:51 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 246 seconds] 10:51 -!- TBI [~TBI@20.84-48-195.nextgentel.com] has quit [Ping timeout: 240 seconds] 10:54 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards 11:00 -!- matsjj [~matsjj@89.197.31.78] has quit [Remote host closed the connection] 11:00 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-znhkgnxspebohoix] has joined #bitcoin-wizards 11:04 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards 11:10 -!- CubicEarth [~cubiceart@50.141.34.192] has quit [Remote host closed the connection] 11:12 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 11:15 -!- mariorz__ is now known as mariorz 11:31 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-yrkdqwrxgcfytrlf] has quit [Quit: Connection closed for inactivity] 11:41 -!- CubicEarth [~cubiceart@50.141.34.213] has joined #bitcoin-wizards 11:41 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] 11:43 -!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Remote host closed the connection] 11:45 -!- GfxdjGFhgF [~KHDXGFHGh@86.121.179.34] has quit [Quit: Leaving] 11:51 -!- eudoxia [~eudoxia@r179-24-172-24.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 11:58 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards 12:06 -!- matsjj [~matsjj@31.75.115.90] has joined #bitcoin-wizards 12:12 -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] 12:15 -!- CubicEarth [~cubiceart@50.141.34.213] has quit [Remote host closed the connection] 12:19 -!- CubicEarth [~cubiceart@50.141.32.138] has joined #bitcoin-wizards 12:21 -!- ebfull [~sean@73.34.119.0] has quit [Remote host closed the connection] 12:24 -!- davec [~davec@24.243.251.52] has quit [Read error: Connection reset by peer] 12:25 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards 12:36 < sipa> tromp__: you can't rely on mempool consistency 12:39 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] 12:42 < kanzure> mempool should be renamed to anticonsistency-accumulator 12:44 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit] 12:45 -!- pozitron [~nu@89.248.174.14] has quit [Ping timeout: 240 seconds] 12:49 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 12:55 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] 13:02 < tromp__> my suggestion requires some method like IBLT to resolve tx discrepancies 13:03 < tromp__> the ultimate savings would be a single zero knowledge proof that the whole merkle tree of witnesses exists 13:04 -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Ping timeout: 245 seconds] 13:05 < sipa> jl2012, instagibbs, tromp__: i had to be brief in the talk at that time, but the proposal is to define the block and transaction size as 4*nonwitness + 1*witness, and constrain that value to 4MB. that is a softfork, is easy to optimize for (just a single metric), anf corresponds to around a 75% growth if the ratio witness/nonwitness remains the same while everyone upgrades to witness 13:06 < tromp__> sipa: how is redefininf block size a softfork? 13:06 -!- atgreen_ [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has quit [Ping timeout: 246 seconds] 13:07 < kanzure> tromp__: everyone else just sees ANYONECANSPEND stuff 13:07 < tromp__> when 4*nonwitness can exceed 1MB? 13:08 < tromp__> oh, i see 13:08 < kanzure> sipa: more than 50% of all the views of the transcripts have been (>6k) views of segwit. 13:08 < sipa> tromp__: yes, but nonwitness cannot exceed 1MB :) 13:09 < tromp__> segwit always reminds me of segway's 13:09 < sipa> kanzure: awesome job with those transacripts... i have to say it weird to barely feel you've gone back to your seat after the talk, and see someone on the other side of the world done a writeup already of what you spoke about :) 13:10 -!- bendavenport [~bpd@96.90.231.161] has quit [Quit: bendavenport] 13:12 < kanzure> sipa: thank you. yeah mostly i think it is useful to have written text that people can read at their leisure, compared to disruptions of trying to watch/play video. 13:13 < kanzure> sipa: next time i will endeavor to finish the writeup before you are half-way done with the talk. i think i know you well enough to guess what you are going to say anyway. 13:13 < kanzure> ((this is essentially a gmaxwell-patented method of transcribing talks)) 13:13 -!- Guest89112 [~quassel@69.85.87.117] has joined #bitcoin-wizards 13:14 < sipa> kanzure: i fully agree, i'm very reluctant myself to go watch videos... they require such a long exclusive lock on your attention span, and my english understanding isn't that good that i can speed things by a signigicant factor :) 13:14 -!- bendavenport [~bpd@96.90.231.161] has joined #bitcoin-wizards 13:14 -!- Guest89112 [~quassel@69.85.87.117] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] 13:14 -!- binaryatrocity [~quassel@unaffiliated/br4n] has joined #bitcoin-wizards 13:14 < sipa> kanzure: ha, i'll try to send you the slides beforehand then; i believe non-causality in transcripts is worth encouraging 13:16 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-wizards 13:19 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards 13:27 -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards 13:29 -!- myeagleflies [~myeaglefl@unaffiliated/myeagleflies] has joined #bitcoin-wizards 13:29 -!- matsjj [~matsjj@31.75.115.90] has quit [Remote host closed the connection] 13:29 < morcos> sipa: i was trying to understand yesterday what disadvantages the structure we arrive at via softforking in seg wit has over a from scratch design and maaku mentioned to me the merkle header being in the coinbase makes fraud proofs bigger 13:30 < morcos> i thought i understood that at the time, but now i don't think i do. in what case are you needing the merkle path to the witness and not already needing the merkle path to the tx 13:31 < morcos> oh, i suppose its a differnt merkle path to the coinbase.. but still how much extra data are we talkign about, and why does it matter how big fraud proofs are 13:32 < morcos> not that anyway was saying it was a problem i guess.. just trying to understand how much we should care about later hardforking it in more cleanly 13:32 < sipa> morcos: indeed, i actually don't think it matters much 13:32 < sipa> morcos: it's a factor 2 in the size of fee fraud proofs or invalid utxo spend proofs 13:33 < gmaxwell> It doesn't really matter all that much; though if you're doing fractional verification; where you check 1 in N witnesses at random; it's a little bloaty. 13:33 < sipa> or invalid script execution proof, i fuess 13:33 < gmaxwell> In general having to always have additional commitments in the coinbase is subpotimal; it's a really bad hit for sublinear cumulative proof of work proofs. 13:34 < gmaxwell> but for segwit it's no biggie. 13:34 < morcos> so is the idea that a lite client doesnt even get the witness data for the tx they are receiving? 13:34 < sipa> indeed 13:34 < gmaxwell> morcos: correct; today existing SPV clients don't verify signatures for tx paying them: they _can't_ without a lot of extra bandwidth, because they'd need the whole input transactions. 13:36 < morcos> ok i guess i was imagining fraud proofs for spending non-existing utxo's, when it seems like you had to deliver the entire merkle tree for the block with the input anyway right? 13:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 13:37 < gmaxwell> For a non-existing input, you show the witness for the spend; which commits to the block with the input and which transaction in it is being spent from-- and then show that transaction. 13:38 < morcos> oh commits to the block and the tx, how does it commit to the tx 13:39 < morcos> i'm imagining you have to show that tx doesn't exist in that block, so need to show all the txs that do exist in that blcok (their hashes at least) 13:39 < gmaxwell> e.g. block 12345 txindex 5. 13:39 < gmaxwell> So we'd need to add those indexes to the chainstate. 13:39 < gmaxwell> (height is already there) 13:40 < gmaxwell> and the index is just which tx in the block is involved, saving having to send the whole thing. 13:45 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 13:46 < morcos> ok so bear with me one sec. the attacker has created a block with valid PoW but a tx without a valid sig (back to the first case). who is going to be able to give you a fraud proof, won't no fully validating node even have the witness data for that block (or wouldn't the attacker never publish it). or am i analyzing the wrong thing? 13:50 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards 13:51 -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] 13:52 < sipa> morcos: they can show the data at the position/height claimed they are spending from 13:53 < sipa> and show that it either mismatches the txin:prevhash, or fails script evaluation 13:53 < morcos> sipa: but isnt that data in the seg wit associated with the bad blcok.. who has that data? 13:54 -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has joined #bitcoin-wizards 13:55 < arubi> sorry for barging, reading a bit back, why is "bad blocks" even a term? 13:55 < sipa> morcos: what exactly is invalid onnthe block? 13:55 < sipa> invalid in the blocl 13:55 < morcos> sipa: ha, you tell me. presumably something right. either the signature is invalid, it's a double spend, or it spends a non-existent utxo. 13:56 < morcos> to know which if any of those things it is, you need the sw data right? 13:56 < morcos> but why would the attacker ever publish the sw data? 13:56 < kanzure> http://diyhpl.us/~bryan/papers2/bitcoin/Incentive%20mechanisms%20for%20securing%20the%20Bitcoin%20blockchain%20-%20BitFury.pdf 13:56 < morcos> if any fully validating node is going to reject the block anyway 13:58 -!- CubicEar_ [~cubiceart@50.141.32.138] has joined #bitcoin-wizards 13:58 < morcos> arubi: i'm probably just having some basic misconception of the purpose of fraud proofs, as its never something i've sat down to try and understand. 13:58 < sipa> morcos: right, after the SW fork a block wothout witness data is invalid.(in the same way as a block whose merkle root mismatches transactions) 14:00 < morcos> sipa: so i coudl see how if a lite client accepted the whole block first, then it would be easy for a full node to present them a short proof of why something in that block is invalid 14:00 < arubi> morcos, then I'm guessing, for double spends at least, bad blocks are only valid if the block tries to replaces a current block (and it's children) 14:01 < sipa> morcos: so fraud proofs don't work for what we currently call light clients 14:01 < sipa> morcos: only for nodes who still download all block data, but perhaps only maintain a partial utxo set 14:01 -!- CubicEarth [~cubiceart@50.141.32.138] has quit [Ping timeout: 240 seconds] 14:02 < morcos> sipa: ok, that makes sense to me then. and it doesn't even have to be all block data right. they just need the blocks for txs they care about, and the fraud proof can deliver the other block if need be 14:03 < morcos> sorry, maybe thats what you meant by all block data. all of a block when they need soemthing from that block. 14:04 < gmaxwell> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html 14:04 < kanzure> .title 14:04 < yoleaux> [bitcoin-dev] Capacity increases for the Bitcoin system. 14:04 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Quit: Page closed] 14:05 < morcos> gmaxwell: you're welcome for my time 14:06 < morcos> wow, awesome didn't realize you had it coded up for bitcoin already, assumed it was just in elements 14:07 < gmaxwell> It doesn't have the fraud proofs yet; so not the more subtle parts; but indeed; the design needed implementation to validate it. 14:07 < kanzure> very characteristic of him to forget to finish the last sentence of an email 14:08 < kanzure> but end is least interesting part so doesn't matter :P 14:08 < gmaxwell> kanzure: the rest of the story is for you to write. 14:09 < CubicEar_> question about soft v hard forks -> can softforks be undone, or rolled-back with another soft fork? Or would a hard fork be required to do so? 14:09 < gmaxwell> CubicEar_: a succesfully deployed soft-fork requires a hardfork to undo. 14:10 < gmaxwell> (though many of them you can 'just not use' or soft-fork deactivate without actually undoing) 14:10 < gmaxwell> e.g. CLTV. People could just stop using it. Or soft-fork out any further use of it.. but it wouldn't be undone; e.g. even with soft-forking it out that opcode would become undoable. 14:13 < CubicEar_> gmaxwell: that is so interesting. That concept seems to have major implications for the power balance of the network, it's sort of a ratchet-mechanism, where the threshold for moving things in a soft-forkable direction is significantly lower than the threshold for moving the other way. 14:14 -!- bendavenport [~bpd@96.90.231.161] has quit [Quit: bendavenport] 14:14 < gmaxwell> I like to think of the network rules as a big block of marble. We can chip things out of the marble to make a beautiful system; but adding marble back is very hard. 14:14 < gmaxwell> If an error is made, we can chip out further to correct it; but it imposes limitations. 14:14 -!- bendavenport [~bpd@96.90.231.161] has joined #bitcoin-wizards 14:15 < gmaxwell> And this means that people can have high confidence that missing things will stay missing; but we're not unable to adapt and improve. 14:18 < CubicEar_> Excellent metaphor. In a sense it opens up a new attack vector, albeit a very high level one, if someone can make some soft-fork that alters the network functionality in a direction they find favorable, and unrecognized at the time is that it is detrimental to others, it can be hard to undo! (I just hadn't realized this before). Although a hard fork can fix anything, if I am understanding correctly. 14:18 < kanzure> a successful hard-fork, at least. depending on what success means. 14:21 < CubicEar_> Or if there are two mutually exclusive soft-fork routes to solve a problem, choosing one locks out the other, unless hard fork. 14:22 < gmaxwell> Yes... soft-forks are also a vulnerability; but we don't really know how to prohibit them. Some day I'd like to prohibit them. 14:22 < gmaxwell> Or constrain their nature, e.g. softforks can only effect transactions with a new version number. 14:23 < gmaxwell> After like.. years.. of thinking about it, I think I do finally have a method to strongly discourage them. 14:23 < gmaxwell> well "strongly". 14:23 < gmaxwell> By strongly I mean not very strongly. :) 14:24 < nsh> oh? 14:24 < gmaxwell> I'll be posting about something else based on it soon, but want to get that implemented. 14:24 < nsh> okay :) 14:24 < nsh> (is there a clippy that pops up and says "it looks like you're trying to fork the consensus...") 14:24 < coinoperated_rob> @gmaxwell: at the risk of overextending a metaphor, we also assume the marble block is large enough to start with, that it could contain within its initial dimensions sufficient material needed for the final masterpiece to be realized, and that unlike working with, say, wood, the material has no unexpected internal defects or knots that would force the matieral to be worked in a suboptimal way to navigate around 14:24 < coinoperated_rob> them. It's a good mental tool though, will add to my kit :) 14:25 < gmaxwell> But the basic idea is that full nodes, at least, can keep track of transactions which should be getting confirmed but aren't, e.g. higher feerate than the things actually getting confirmed. 14:26 < gmaxwell> And if there is too much of this, they enter a safe mode, where they stop counting confirmations. 14:26 < gmaxwell> This turns the suppression of transactions into a widescale denial of service attack; which would discourage it and position the network in a safe(er) place to work on changing the POW to fire the miners. 14:27 < CubicEar_> gmaxwell: "changing the POW to fire the miners" - another great quote 14:27 < nsh> ah so everyone gets a toys-out-of-the-pram button. got it 14:28 < tromp__> no need to change the pow, just phase in a second one:) 14:29 < gmaxwell> tromp__: yea, I meant change expansively. 14:30 -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-wizards 14:32 < coinoperated_rob> is it possible to fire miners? as i undertsand things, their entrenchment is based only in part on possesion of a lotta SHA256 ASICs. 14:32 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] 14:33 < CubicEar_> what else you think it is based on? 14:33 < coinoperated_rob> access to ideal cost basis for infrastructure 14:34 < CubicEar_> as in near cheap power, and decent bandwidth? 14:34 < coinoperated_rob> they have to cycle hardware every 12 months or so regardless, to stay ahead of diff 14:34 < coinoperated_rob> @CubicEar_ yes 14:35 < CubicEar_> If it moved to another PoW that was primarily energy constrained... you are probably right 14:35 < tromp__> i saw some discussion of the 21 miner chip on reddit where they ponder the goal of putting them in so many consumer devices that mining for profit becomes impossible 14:36 < CubicEar_> (and yes, I understand the "W" in PoW is largely about energy 14:36 < coinoperated_rob> i think all PoW is ultimtely energy constrained 14:37 < gmaxwell> coinoperated_rob: A fair number of miners now have effectively free power; they are using surplus hydro (or industrial peak load) power that is in excess of demand. 14:37 -!- Erik_dc [~erik@d54c620ed.access.telenet.be] has quit [Remote host closed the connection] 14:37 < coinoperated_rob> because it's all ultimately time constrained, and energy is time purchased in bulk. 14:37 -!- pandabearit [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has joined #bitcoin-wizards 14:37 < moa> gmaxwell: I like that you have broadly used the concept of capacity and eschewed the now-overloaded "scaling" term in your email 14:38 < gmaxwell> point being the credible threat is part of the incentive structure; and it doesn't have to be complete to have weight. 14:38 < gmaxwell> moa: Thank you. 14:38 < coinoperated_rob> @gmaxwell, indeed. I remember /r/bitcoinmarkets debates on this 2 years ago where that assumption was generally scoffed at. but how could it be otherwise 14:38 < moa> because we can then have a spectrum of different types of capcity ... low-trust TX capacity, high-trust TX capicity, private TX capacity, etc ... it makes for a more formal definition of the technical problems 14:39 < gmaxwell> coinoperated_rob: a lot of those miners are already on outdated hardware; .. the only reason to update is to get more hash for the available, very large amount of MWH available... and I expect those miners will almost always use hand-me-downs and cheaper, more mature tech. 14:39 < gmaxwell> moa: I would have liked to talk about that more; but I was already over long. 14:39 < coinoperated_rob> signal coherence capacity in general. what's the minimum bound on maintaining a coherent state among a planetwide grid of nodes 14:40 < coinoperated_rob> @gmaxwell, i see - so you are saying that many miners are not positioned to leap to another gen or algo of PoW without going underwater 14:41 < coinoperated_rob> they stay afloat solely by undercutting the energy-to-btc market price with shenanigans 14:41 < gmaxwell> My view of the bitcoin blockchain is that it's a court with a trustworthy AI judge and perfect enforcement power within its domain. You can transact safely without trusting third parties because you can transact in front of the judge... or because you can setup your contracts so that if there is a dispute you can later take them before the judge and get justice. 14:42 < gmaxwell> coinoperated_rob: there are free variables in your equation: how much resources will mankind spend on it? How long of a time till coherence can we tolerate? etc. 14:42 -!- vaalbara [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has joined #bitcoin-wizards 14:43 -!- pandabearit [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has quit [Quit: Leaving] 14:43 -!- vaalbara [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has quit [Client Quit] 14:43 -!- pandabearit [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has joined #bitcoin-wizards 14:45 < coinoperated_rob> @gmaxwell: mankind is bitcoin's sole patron. Thus Bitcoin's most fundamental boundaries are defined by human factors. Patience is a biggie. 14:47 < gmaxwell> Sure. and as a result physical limits aren't what we need to be concerned about; physically driven _trade-offs_ yes... But no one is going to fund the reactor based neutrino communication system to lower the latency of blocks between NYC and Japan by 50ms... so that it would be perhaps physically possible to do so, isn't so important. :) 14:49 < coinoperated_rob> @gmaxwell, but for the sake of a starting point, if mankind's quirks wrt spending resources and waiting for coherence were not considered relevant, and only physical limitations of propagation of global state were evaluated, how many times per second could the entire planet confirm a single state. assume everyone plays fair, no censorship attempted, but all nodes must agree (and know they agree) before a new 14:49 < coinoperated_rob> state change can be issued. Would this be an absolute upper limit on TPS? 14:50 < coinoperated_rob> apologies if this question has been done to death in here 14:52 < coinoperated_rob> @gmaxwell: I understand. We can only improve the Bitcoin we actually have right now. 14:52 < CubicEar_> coinoperated_rob: I think it would still be probabilistic 14:53 < gmaxwell> depends on the consensus model. for a plain paxos like consensus it's a small multiple of the broadcast communication time between all participants (and quadratic communications cost). For blockchain consensus there is really no such thing as settlement; at 'best' we get is exponentially increasing confidence that the past history won't change. 14:53 < gmaxwell> (even absent attackers) 14:53 < coinoperated_rob> @CubicEar_ even so the domain of prability has to be hard bound somewhere 14:54 < gmaxwell> no, there is actually no bound within the bitcoin consensus itself, though the probablities become negligible and at some point external processes would take over, to override the consensus if it reorged too deep; but thats a social quesiton. 14:54 < kanzure> .title http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011866.html 14:54 < coinoperated_rob> I'm never going to get used to this macbook kbd :p 14:54 < yoleaux> [bitcoin-dev] Capacity increases for the Bitcoin system. 14:55 < CubicEar_> coinoperated_rob: Speed of light? One way trip time. If you wanted to hear back.. double that. Or were you thinking of a way it could be less? 14:58 -!- smk [51111532@gateway/web/freenode/ip.81.17.21.50] has joined #bitcoin-wizards 14:58 < coinoperated_rob> @gmaxwell: where does probability start to definitively lose to external factors, or rather what moderates this change - confirmation depth? 14:59 < coinoperated_rob> @CubicEar_: No I basically agree that the speed of light is the one resource that can't be moore's law-ed away 15:00 < gmaxwell> well the speed of light can be centeralized away. 15:01 < coinoperated_rob> @gmaxwell: Right, VISA 15:01 < kanzure> visa is probably not best example, ultimate example is local dictionary updates per sec, no external io 15:01 < coinoperated_rob> @gmaxwell and probably others but i guess VISA's the target 15:02 < kanzure> visa is not necessarily the target- they have different goals and operating requirements, widely-deployed bitcoin might look different to meet so many conflicting goals and tradeoffs 15:06 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 15:07 < coinoperated_rob> @kanzure: sure, just picking it because it's the counterexample most often brought up in casual conversation 15:07 < coinoperated_rob> on the scalability issue 15:08 < docl> Will we be moving close to the surface of the sun to maximize energy expenditure while minimizing time delay? 15:09 < kanzure> time delay across surface of sun is significant 15:09 < kanzure> would require significant sharding in certain convex hulls over the surface, plus some global consensus mechanism which might be much more delayed for the whole surface 15:11 < docl> Seems like 1/300th of a second is a small enough fraction of 10 minutes to be handwaved away given a significant advantage in energy availability. 15:12 < coinoperated_rob> global consensus mechanisms subject to global consensus on using global consensus meechanism. is consensus all the way up 15:13 < kanzure> astronomical distances require more latency 15:14 < coinoperated_rob> @doc1 1/300th is diameter or 1/2 circumference? 15:16 < docl> Oops, it's more than that. 1 billion meters, so about 3 seconds. 15:17 < moa> consensus networks on a Dyson sphere would be how slow then? 15:18 < docl> coinoperated_rob: That was referring to the diameter of the sun. 15:19 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 246 seconds] 15:22 -!- memymo [~textual@202.171.211.253] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 15:22 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 250 seconds] 15:30 < docl> moa: depends on the size of the DS. The smallest possible kind would be on the surface of the sun, so they would transmit signals that reach all other nodes of the same distance in about 3 seconds (assuming neutrino beams that can slice through the Sun). That would not perceptibly slow the 10 minute algorithm used by bitcoin. One at 1.0 AU would take 16 minutes at a minimum to reach all nodes, so it 15:30 < docl> would be constantly forking. 15:32 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 15:34 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 15:37 -!- eudoxia [~eudoxia@r179-24-172-24.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 15:37 < kanzure> i posted some thoughts re: a "revenue share" model of (almost) open-source software development. bitcoin can definitely solve some of the payment pieces of the puzzle, but unfortunately there's still some issues around group negotiation around software costs- can't have 100k library authors negotiate with acme corp just for acme corp to get to use some ubuntu-equivalent system. https://news.ycombinator.com/item?id=10693598 15:40 -!- pandabearit [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has quit [Ping timeout: 272 seconds] 15:41 -!- phy1729 [~phy1729@unaffiliated/phy1729] has quit [Killed (c (*lightning bolts*))] 15:42 -!- phy1729 [~phy1729@unaffiliated/phy1729] has joined #bitcoin-wizards 15:49 -!- Jeremy_Rand [~jeremy@ip68-97-32-41.ok.ok.cox.net] has quit [Ping timeout: 245 seconds] 15:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 15:57 -!- adam3us [~Adium@45.64.240.161] has quit [Ping timeout: 240 seconds] 16:03 -!- wallet42 [~wallet42@pcd535135.netvigator.com] has quit [Quit: Leaving.] 16:06 -!- adam3us [~Adium@45.64.240.214] has joined #bitcoin-wizards 16:09 -!- pandabearit [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has joined #bitcoin-wizards 16:09 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-bptxirzavgbbvrzw] has joined #bitcoin-wizards 16:14 -!- oldbrew [~brew@24-212-254-57.cable.teksavvy.com] has left #bitcoin-wizards [] 16:14 -!- pandabearit [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has quit [Ping timeout: 272 seconds] 16:16 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 16:22 -!- GGuyZ [~GGuyZ@202.171.211.253] has quit [Quit: GGuyZ] 16:30 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-wizards 16:32 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] 16:32 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-recrkoozibopkqsc] has quit [Remote host closed the connection] 16:34 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 16:35 -!- Casper- [~Casper@garza.riseup.net] has joined #bitcoin-wizards 16:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 16:38 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] 16:41 -!- a5m0 [~a5m0@unaffiliated/a5m0] has quit [Remote host closed the connection] 16:44 -!- a5m0 [~a5m0@unaffiliated/a5m0] has joined #bitcoin-wizards 16:45 -!- Jeremy_Rand [~jeremy@172.56.7.164] has joined #bitcoin-wizards 16:48 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] 16:48 -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has joined #bitcoin-wizards 16:51 -!- gobiasindustries [60268e75@gateway/web/freenode/ip.96.38.142.117] has quit [Quit: Page closed] 16:51 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 16:54 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 16:58 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 16:58 -!- Jeremy_Rand [~jeremy@172.56.7.164] has quit [Ping timeout: 250 seconds] 17:06 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pzungfnbfyuwucae] has joined #bitcoin-wizards 17:06 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 17:08 -!- GGuyZ [~GGuyZ@202.171.211.253] has joined #bitcoin-wizards 17:11 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-wizards 17:14 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 17:17 -!- GGuyZ [~GGuyZ@202.171.211.253] has quit [Quit: GGuyZ] 17:18 -!- adam3us [~Adium@45.64.240.214] has quit [Quit: Leaving.] 17:18 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 17:25 -!- gnusha [~gnusha@bryan.fairlystable.org] has joined #bitcoin-wizards 17:25 -!- Topic for #bitcoin-wizards: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja 17:25 -!- Topic set by sipa [~pw@unaffiliated/sipa1024] [Thu Oct 29 17:53:34 2015] 17:25 [Users #bitcoin-wizards] 17:25 [@ChanServ ] [ c-cex-yuriy ] [ Giszmo ] [ kaptah ] [ N0S4A2 ] [ sparetire_ ] 17:25 [ [ace] ] [ c0rw|zZz ] [ gmaxwell ] [ katu ] [ nabu ] [ spinza ] 17:25 [ [d__d] ] [ Casper- ] [ gnusha ] [ Keefe ] [ nanotube ] [ Starduster_ ] 17:25 [ [Derek] ] [ catcow ] [ go1111111 ] [ keus ] [ nba_btchip ] [ starsoccer ] 17:25 [ _whitelogger_ ] [ catlasshrugged_ ] [ gocrazy ] [ kinlo ] [ neha ] [ stevenroose|BNC] 17:25 [ a5m0 ] [ cfields ] [ Graet ] [ kisspunch ] [ nephyrin` ] [ stonecoldpat ] 17:25 [ adams__ ] [ cluckj ] [ grandmaster2 ] [ koshii ] [ NewLiberty ] [ STRML ] 17:25 [ adlai ] [ CodeArtix ] [ grantsmith ] [ Krellan ] [ nickler ] [ SwedFTP ] 17:25 [ AdrianG ] [ CodeShark_ ] [ GreenIsMyPepper] [ kumavis ] [ nsh ] [ Taek42 ] 17:25 [ aem ] [ coinoperated_rob] [ gribble ] [ kyuupichan ] [ null_radix ] [ TBI_ ] 17:25 [ afdudley ] [ comboy ] [ grubles ] [ larraboj ] [ nwilcox ] [ TD-Linux ] 17:25 [ aj ] [ Cory ] [ Guest1234 ] [ lclc ] [ optimator ] [ teknic111 ] 17:25 [ Alanius ] [ coryfields ] [ guruvan ] [ lecusemble ] [ otoburb ] [ Tenhi ] 17:25 [ alexkuck_ ] [ crescendo ] [ gwillen ] [ LeMiner ] [ OxADADA ] [ Tenhi_ ] 17:25 [ amiller ] [ CubicEar_ ] [ harding ] [ Lightsword ] [ PaulCapestany ] [ thrasher` ] 17:25 [ Anduck ] [ d9b4bef9 ] [ harrow ] [ livegnik ] [ petertodd ] [ Tiraspol ] 17:25 [ andytoshi ] [ da2ce7_mobile ] [ hashtag ] [ lnovy ] [ phantomcircuit ] [ tromp ] 17:25 [ Apocalyptic ] [ dansmith_btc ] [ hashtag_ ] [ Logicwax ] [ phy1729 ] [ tromp__ ] 17:25 [ archobserver ] [ Darknes ] [ heath ] [ lomax__ ] [ pigeons ] [ ttttemp ] 17:25 [ arowser ] [ dave4925 ] [ helo ] [ Londe2 ] [ poggy ] [ ttttemp_ ] 17:25 [ artifexd ] [ davec ] [ humd1ng3r ] [ luigi1111w ] [ PRab ] [ tucenaber_ ] 17:25 [ arubi ] [ davout ] [ huseby ] [ Luke-Jr ] [ prosody ] [ tulip ] 17:25 [ asoltys ] [ devrandom ] [ ibrightly ] [ luny ] [ PsychoticBoy ] [ vdo ] 17:25 [ azariah ] [ dgenr8 ] [ iddo ] [ maaku ] [ Pugg ] [ wangchun ] 17:25 [ BananaLotus ] [ digitalmagus ] [ indolering ] [ Madars ] [ qawap_ ] [ warptangent ] 17:25 [ bassguitarman ] [ dignork ] [ instagibbs ] [ MagikSquirrel] [ roasbeef ] [ warren ] 17:25 [ bendavenport ] [ docl ] [ Iriez ] [ malte ] [ robmyers ] [ waxwing ] 17:25 [ berndj ] [ DougieBot5000 ] [ isis ] [ mappum ] [ runeks ] [ weex_ ] 17:25 [ bildramer ] [ earthris1 ] [ Jaamg ] [ mariorz ] [ rustyn ] [ wizkid057 ] 17:25 [ binaryatrocity ] [ ebfull ] [ jaromil ] [ Meeh ] [ ryan-c ] [ wpalczynski ] 17:25 [ binaryFateCloud] [ Eliel ] [ jbenet ] [ melvster ] [ s1w ] [ wumpus ] 17:25 [ bitdevsnyc ] [ epscy ] [ jcorgan ] [ midnightmagic] [ sdaftuar ] [ xeon-enouf ] 17:25 [ bitkarma ] [ eric ] [ jeremias ] [ mikolalysenko] [ SDr ] [ Xzibit17 ] 17:25 [ bliljerk101 ] [ espes ] [ jeremyrubin ] [ mm_1 ] [ se3000 ] [ yang ] 17:25 [ blkdb ] [ execute ] [ jessepollak ] [ moa ] [ seg ] [ Ylbam ] 17:25 [ BlueMatt ] [ Fistful_of_Coins] [ jl2012 ] [ MoALTz ] [ SgtStroopwafel ] [ yoleaux ] 17:25 [ bobke ] [ fkhan ] [ jlrubin ] [ Monthrecg ] [ SheffieldCrypto] [ yorick ] 17:25 [ BrainOverfl0w ] [ fluffypony ] [ jlyndon ] [ morcos ] [ shesek ] [ zmachine ] 17:25 [ bramc ] [ forrestv ] [ joesmoe ] [ mountaingoat ] [ sipa ] [ zmanian_ ] 17:25 [ brand0 ] [ frankenmint ] [ jojva_ ] [ mr_burdell ] [ smk ] [ zxzzt ] 17:25 [ brg444 ] [ GAit ] [ jonasschnelli ] [ mrkent ] [ smooth ] 17:25 [ bsm117532 ] [ gavinandresen ] [ jrayhawk ] [ MRL-Relay ] [ sneak ] 17:25 [ btcdrak ] [ ggreer ] [ K1773R ] [ Myagui ] [ so ] 17:25 [ Burrito ] [ ghtdak ] [ kanzure ] [ myeagleflies ] [ sparetire ] 17:25 -!- Irssi: #bitcoin-wizards: Total of 260 nicks [1 ops, 0 halfops, 0 voices, 259 normal] 17:25 -!- Channel #bitcoin-wizards created Mon Feb 25 23:24:47 2013 17:25 -!- Irssi: Join to #bitcoin-wizards was synced in 10 secs 17:31 -!- CubicEar_ [~cubiceart@50.141.32.138] has quit [Remote host closed the connection] 17:32 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 17:36 -!- memymo [~textual@202.171.211.253] has quit [Client Quit] 17:36 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 17:38 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards 17:40 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] 17:40 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has quit [Remote host closed the connection] 17:41 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-wizards 17:41 -!- CubicEarth [~cubiceart@50.141.34.246] has joined #bitcoin-wizards 17:44 -!- memymo [~textual@202.171.211.253] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 17:45 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 17:45 -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [] 17:48 -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards 17:51 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 17:52 < jl2012> as I understand, by the definition of "witness", it could include nVersion, nSequence, scriptSig, and nLockTime. With a softfork, however, only the scriptSig may be segregated. That's not very optimal 17:52 -!- memymo [~textual@202.171.211.253] has quit [Client Quit] 17:53 < gmaxwell> Locktime and sequence .. must be commited to by the signatures, which is kind of cyclic. nversion is actually a utxo property that could be used to change the interperation of txouts in the future. 17:54 < gmaxwell> jl2012: even adopting that position, they're also only 4 bytes each. moving them across would make them much more expensive to access for people who want the transaction plus those but otherwise without the witnesses. 17:55 < phantomcircuit> and would be a hardfork (unless they were simply null in which case why are you doing it) 17:57 < jl2012> i believe a hardfork is better here, as we will eventually need a hardfork. Are ASIC desingers complaining the lack of nonce space in header? 17:58 < jl2012> a carefully written hardfork could be compatiable with existing ASIC and even SPV nodes 18:00 < jl2012> e.g., using space of nVersion as nonce and move the real nVersion as part of Merkle root. And also the timewarp problem has to be fixed by hardfork 18:01 < jl2012> softfork is great for simple things like BIP65. Even for relative locktime it already looks too complicated 18:01 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards 18:01 < phantomcircuit> jl2012, moving nVersion into the merkle root is... no 18:02 < jl2012> phantomcircuit: just a different way to serialize the field and calculate the hash. I'll describe it in more details 18:03 < phantomcircuit> jl2012, there's no reason to increase the nonce space 18:03 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 250 seconds] 18:03 < phantomcircuit> (if anything it would cause more problems than it would solve) 18:04 < jl2012> phantomcircuit: as ASIC becomes faster, it may become a real problem. Too much overhead between the ASIC and the computer 18:05 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 18:06 < phantomcircuit> jl2012, no it really wont 18:06 < phantomcircuit> if it becomes an issue the work generation will be moved to an fpga 18:06 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards 18:06 < phantomcircuit> (which is trivial and is already done by avalon hardware) 18:07 < jl2012> how about the communication overhead between the FPGA and ASIC? 18:07 < Lightsword> I think most bitmain gear also uses an fpga 18:09 < jl2012> ok forget more nonce for ASIC. The lack of header space is also an issue. If satoshi left some free bytes in the header, sigwit could be a nicer softfork 18:09 < phantomcircuit> jl2012, the thing generating work can be upto 2^32-1/16 times slower than the asic and still keep up 18:09 < phantomcircuit> im entirely unconcerned about it 18:10 < GAit> FYI cfields created #bitcoin-hk-dev for those participating to the hackaton today and tomorrow 18:10 < kanzure> oh why 18:10 < Lightsword> yeah, I think workgeneration isn’t much of an issue, cpu usage from comms is higher AFAIK on the controllers 18:10 < kanzure> taking over #bitcoin-dev would be appropriate 18:13 < phantomcircuit> Lightsword, well yes the easiest way to implement the cpu<->asic comms is to simply infinite loop polling for updates 18:15 < Lightsword> phantomcircuit, I think they stick the FPGA in between mainly for io multiplexing or something like that 18:17 < gmaxwell> jl2012: I am pretty confident that moving things like version would be quite negative; also: an independant sampling on that: in elements alpha where it was a hardfork, we didn't move that. 18:18 < phantomcircuit> Lightsword, yes you have the asic switch a line high to signal to the fpga "there's something to do" then the cpu just polls the fpga in a circle 18:18 < phantomcircuit> this of course depends on whether you're chaining spi or not 18:18 < gmaxwell> jl2012: the hardfork we'd propose for SW would be to add another level to the hashtree which would be compatible with lite clients. I don't believe people demanding blocksize hardforks are actually okay with a _real_ hardfork. A few months back I tried proposing that we reclaim all the header bits that are forced to be zero due to difficulty (always at least 32 bits), and got a pretty chilly r 18:18 < gmaxwell> esponse. 18:19 < gmaxwell> I'm totally game for doing that however. But ... I'd leave it to you to sell to people. 18:19 < gmaxwell> It would be very good to get nonce space into the first compression run of the proof of work. 18:20 < Lightsword> would the soft fork break any miners that do work generation in the ASIC?? 18:20 < phantomcircuit> Lightsword, which one? 18:21 < Lightsword> avalon or 21 Inc would be the ones I’m familiar with 18:21 < gmaxwell> Nothing discusssed above would. The hardfork to move the SW commitment just makes it look like the block has 2x the number of transactions. 18:21 < Lightsword> although avalon may be somewhere else in the hardware 18:22 < phantomcircuit> Lightsword, no i mean which soft fork 18:23 < gmaxwell> Segwit soft fork, as currently implement basically just looks like namecoin merged mining, in terms of how it looks to a device like that. 18:23 < Lightsword> the one for segregated witness 18:29 -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards 18:31 < maaku> morcos: yes, I think the witness should be kept small for now, but grow slowly a la BIP 103's rate. the code pieter presented would have just introduced another hard cap at 4mb however 18:31 < morcos> maaku: oh i thought above you said it was fine for the witness to be 32MB or something 18:33 -!- bendavenport [~bpd@96.90.231.161] has quit [Quit: bendavenport] 18:35 < gmaxwell> If the witness is computed in the same limit as the block, then it needs a factor of 4 in order to realize the full capacity gain at the existing blocksize limit size. Luke was suggested to me previously that we just have (ironically for him) non-configurable soft-caps if we're worried about immediate bandwidth impact ahead of the advancements in block propagation performance. 18:36 -!- roconnor [~roconnor@host-45-58-251-219.dyn.295.ca] has joined #bitcoin-wizards 18:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 18:37 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 18:38 < amiller> i feel like i'm missing something about the explanation of rationale for SW and increasing to (effectively) 4mb, like the concern about increasing to 4mb is that it will be bad for some miners, but SW doesn't impact any miners 18:38 < amiller> so is it just that this is a way to increase to 4MB without having to do a hardfork? 18:39 < maaku> morcos: not all fraud proofs involve a transaction. utxo/stxo commitments are seeming less likely to be needed now but those would also go in the witness. 18:39 < maaku> header tree commitments for compact spv proofs, which are very sensitive to size, also in the witness. 18:40 < maaku> merged mining commitments aren't really witness, but would be there too. no need for a sidechain to have a path through the bitcoin transaction tree for its block headers 18:40 < maaku> morcos: sorry if it's repeat, still reading the backlog 18:40 < sipa> amiller: SW very certainly impacts miners 18:41 < sipa> amiller: but it's only 4 MB in pathological cases; for normal transactions right now, and only if they switch to using SW, it corresponds to some 1.75 MB 18:41 -!- smooth is now known as david1atapie 18:42 < amiller> sipa, ok, for somewhere in between 1.75MB to 4MB, sure..... still miners have to receive all the transactions + witnesses to validate them, right? 18:42 < kanzure> oh right there was also some claim about multisig as related to the 4 MB claim 18:42 -!- david1atapie is now known as smooth 18:42 < sipa> amiller: yes, as far as miners are concerned, it's just a block.size increase, period 18:42 -!- smooth is now known as david1atapie 18:42 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 18:42 < aj> kanzure: i get "2MB" for P2PKH with segwit and "3MB" for p2sh w/ 2-of-2 multisig with segwit fwiw 18:43 < morcos> maaku: so the use of the term fraud proof has mostly been just a simple way to prove that some type of witness data was in a block. what that data is and what it proves fraud of are unspecified? 18:43 < aj> sipa: i couldn't work out what your segwit branch does with sigop limits... 18:44 < sipa> amiller: it is pretty much everything else in the ecosystem to whom segwit is better than just a block size increase 18:44 < sipa> aj: probably nothing 18:45 -!- david1atapie is now known as smooth 18:45 < amiller> sipa, okay, understood. congrats on the great work + talk btw :) 18:45 < aj> sipa: it seemed like it didn't count sigops for segwit txns at all, which seems like a flaw? 18:45 < maaku> morcos: I suppose fraud proof should be constrained to mean a proof that a transaction is invalid e.g. by referencing witness or witness + transaction data, but loosly the same format proof is also done for header backlinks, merged mining commitments, etc. 18:46 < sipa> aj: fair point! 18:46 < maaku> so "fraud proof size" in discussions sometimes is a stand-in for "aux block header size" or "compact spv backlink size" and other things we also care about 18:46 < maaku> we need better terminology 18:47 < morcos> sipa: is there a reason not to count actual signatures verified, instead of just the number before the check_multisig 18:48 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .] 18:48 < maaku> morcos: what I was saying above is (1) with CT a block might have 1MB tx data and up to 40MB witness data; with other stuff in development the ratio of witness/non-witness may get even larger 18:48 < sipa> morcos: i am absolutely in favor of sane resource costs accounting instead of a dumb and confused sigops and bytes limit now 18:48 < sipa> morcos: but fixing that really needs a hard fork, not more tweaks 18:49 < maaku> but obviously we can't support a 41MB block anytime soon ... but it would be nice to scale up to that slowly over time 18:49 -!- TBI [~TBI@84.48.195.20] has joined #bitcoin-wizards 18:49 < aj> sipa: if there are only sigops in segwit data, it's a soft-fork to change how you account for them though :) 18:49 < sipa> aj: we should obviously count them 18:49 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 18:49 < maaku> also, a note that wasn't in the talk I think, the pathological block validation cases depend on non-witness size. so those are still constrained to 1MB... 18:49 < CubicEarth> maaku: I think you might be addressing a question I have.... what is the bound on the witness data? Why couldn't it be 40MB now? 18:50 < aj> sipa: ie old nodes count sigops in the original block as 0, so _any_ constraint on segwit sigops is an additional restriction, even if it's bazillions of sigops per block 18:50 < sipa> CubicEarth: miners right now are already worried about the centralization pressure of an increase to 4 MB 18:50 < morcos> sipa: hmm.. i should look at your code, but the pubkeyscripts are now a new kind of p2sh right? 18:50 < maaku> CubicEarth: it must be small now because as far as mining centralization concerns go, a 40 + 1 MB segwitness block is exactly the same as a hard-forked 41MB block 18:50 < morcos> so by default would count as no sig ops, and there is no input 18:51 < sipa> CubicEarth: 40 MB witness still means effectively relaying 40 MB of data for miners 18:51 < morcos> so can't we redefine teh counting however we want 18:51 -!- TBI_ [~TBI@84.48.195.20] has quit [Ping timeout: 240 seconds] 18:51 < morcos> of course we have to stay under the old limits, but for anything appearing in the old way, but that doesn't seem restrictive 18:51 < sipa> morcos: that's perhaps a reason to also put the version number in the witness 18:52 < sipa> so we know a particular witness's last stack item is in fact an executed script, and can be counted as such 18:52 < CubicEarth> sipa: I understand that aspect. Is there a cap at 4MB total? What about an attack where a miner does 1 MB + 40 MB of witness data? 18:52 < maaku> morcos: right we can redefine the accounting however we want, and my argument is simply that we should be smarter about it :) (see jonas' talk + something like BIP 103 scaling curve) 18:53 < maaku> (I do think that given the time available for the talk sipa did the right thing by not addressing this) 18:53 < sipa> CubicEarth: yes there is a hard limit 18:53 < CubicEarth> got it 18:53 < sipa> maaku: i think this doesn't make sense 18:53 < sipa> maaku: the cost of witness data vs non-witness data will not go down over time 18:53 < sipa> there is no reason why the accounting should go down 18:54 < sipa> except for the fact that we'd like a bigger limit at some point 18:54 < maaku> sipa: I'm not arguing that the cost of witness vs non-witness data will go down 18:54 < aj> maaku: scaling segwit data beyond 4MB without scaling the 'real' block data above 1MB doesn't make much sense though? 18:54 < maaku> sipa: right I'm just arguing for a bigger limit at some point 18:54 < sipa> aj: exactly 18:54 < sipa> maaku: i know that, but i can't justify that 18:54 < maaku> aj: it does with future enhancements e.g. CT 18:55 < sipa> right, if the purpose changes, sure 18:55 < maaku> sipa: you are okay with BIP 103, right? 18:55 < aj> maaku: CT doesn't require a hardfork to mess with txout values anyway? 18:56 < maaku> aj: no, it could be done as a soft-fork (we considered this for elements, might still do it that way as it has advantages regarding testing infrastructure) 18:56 < sipa> maaku: you're confusing things 18:56 < sipa> maaku: we can always add a second commitment for a level 2 witness for CT 18:56 < aj> maaku: 18:56 < sipa> in exactly the same softfork way 18:57 < maaku> sipa: hrm. this is true. 18:57 < sipa> maaku: if we expect that the amount of witness data changes dramatically compared to the effective transaction data 18:57 < maaku> sipa: I don't like getting stuck with many limits however... 18:58 < sipa> maaku: they're not extra limits 18:58 < sipa> it's just a cost function! 18:58 < sipa> the limit, technically, remains 1 MB; the witness part just gets a 75% discount towards that limit 18:59 < maaku> aj: it's not unlike an extension block / sidechains. you send coins into CT outputs by putting them in a separate anyone-can-spend-with-revelation-of-CT-amount output, kinda like a sidechain peg pool 18:59 -!- p15 [~p15@47.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards 18:59 < maaku> then the CT outputs themselves are 0-valued 19:00 < aj> maaku: huh. and i guess CT makes it impossible to check for dust anyway 19:02 < gmaxwell> aj: dust is not a concern if things are setup such that consuming utxo is profitable. 19:02 < maaku> sipa: all I'm saying is grow that by 17% per year ... 19:03 < maaku> then we won't have to consider another separate witness to grow when we want to add CT 19:03 < maaku> (if there is consensus for CT, etc. etc.) 19:03 < maaku> just using it as an example because of the giant witnesses it generates 19:04 < sipa> maaku: it makes no sense to grow a cost factor over time if we don't expect its cost to decrease over time 19:04 < CubicEarth> so what are typical transaction sizes when the witness has been removed? 19:04 < maaku> sipa: I do expect the cost of validation and relay to decrease over time. i believe you do as well? within sane amounts, e.g. BIP 103's numbers 19:05 < sipa> maaku: if those numbers decrease over time we should just allow the limit to grow, in a hard fork 19:05 < sipa> maaku: applying that growth via a fudge factor to apply to just one part just because we can seems insane to me 19:07 < morcos> sipa: so sorry if i missed this, but why is 75% the right discount factor now then? 19:07 < maaku> sipa: I am hopefull that we can get much more mileage out of this than a year or two delay. And to jgarzik's point, growing via a fixed schedule, even if super conservative, gives I actual experience with modifying infrastructure before the hardfork 19:07 < morcos> it seemed to me it was motivated by thats all the benefit we would get out of it 19:07 < morcos> but now you're saying more than that also happens to be risky if it turns out we could get even more benefit 19:09 < sipa> maaku: say we end up in a situation where the factor was 20. i fully expect a counterparty like system to emerge that just encodes everything in the super cheap witness space... and has higher transaction rate than bitcoin itself 19:10 -!- atgreen_ [~green@209.171.88.129] has joined #bitcoin-wizards 19:10 < sipa> the factor is a hack to avoid double limits for various resources, and chosen so that the worst case on either side is acceptable 19:11 < maaku> sipa: I don't see how that counterparty concern is any different between the scenarios 19:11 < aj> sipa: does the segwit have the same 1MB limit or a separate one? like, if you have 2MB of segwit data, discounted by 75% to 500kB, does that mean you can only fill up 500kB of the main block for a total of 2.5MB? 19:11 < sipa> aj: yes 19:12 < sipa> basesize + witnesssize/4 = 1 MB 19:12 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 19:12 < sipa> maaku: netween what scenarios? 19:13 < sipa> if this factor grows unboundedly, you are making one part of the system effectively free to use compared to the rest 19:15 < maaku> sipa: so you want the space of scriptSig data to be counted high specifically because it could be used to encode arbitrary data, correct? 19:16 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards 19:16 < aj> sipa: ah, so 800kB of block plus 800kB/4 of segwit = 1MB for a 1.6x improvement in P2SH effective blocksize, and 667kB+1.333kB/4=1MB for a 2MB effective blocksize for 2-of-2 P2SH then 19:16 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 19:17 < maaku> so if we had CT extensions, you would want that in a separate witness, which could be allowed to be much larger, but care must be taken that one is not able to encode parasitic systems? 19:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pzungfnbfyuwucae] has quit [Quit: Connection closed for inactivity] 19:17 < aj> bah, P2PKH was the first one, not P2SH 19:17 < sipa> maaku: i see your point, but at this point i think CT in bitcoin is completely unreasonable anyway... 19:18 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 19:18 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 19:18 < gmaxwell> the range proofs would be a seperate witness in any case. 19:18 < sipa> and i don't think we should let block space grow in a way that's not useful to bitcoin itself, just to accomodate a future case 19:19 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 19:19 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Client Quit] 19:19 < maaku> gmaxwell: that's what we're discussing -- I was considering a combined witness because that makes some aspects easier 19:20 -!- bobke [~bobke@94-226-145-186.access.telenet.be] has quit [Ping timeout: 246 seconds] 19:20 -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 256 seconds] 19:21 < gmaxwell> well in terms of commitment structure; you'd want the different data at different times; also it is potentially useful to have the signatures commit to the range proofs. 19:22 < gmaxwell> (the reason for this is so that if someone attempts an invalid range proof the result could be to destroy their coins, which would presumably get rid of rangeproof verification based DOS attacks.) 19:22 -!- Casper- [~Casper@garza.riseup.net] has quit [Quit: Casper-] 19:23 -!- adam3us [~Adium@m121-202-137-111.smartone.com] has joined #bitcoin-wizards 19:24 < maaku> but if I understand sipa correctly, it sounds like there is a desire to keep scriptSig witness 'small' (max <=3MB) for concerns over data-stuffing, but potentially something like CT with explicit data structure could be allowed larger (assuming future improvements that make combined data sizes safe) 19:24 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 19:26 < gmaxwell> maaku: without a constraint there strategic behavior by miners can be unboundly bad. 19:26 < gmaxwell> E.g. "my blocks have 1tx and 400MB of CSPRNG noise in their witnesses, good luck with that." 19:27 -!- Casper- [~Casper@garza.riseup.net] has joined #bitcoin-wizards 19:27 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 19:27 -!- bobke [~bobke@94-226-145-186.access.telenet.be] has joined #bitcoin-wizards 19:33 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 19:35 -!- p15 [~p15@47.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 272 seconds] 19:36 -!- pandabearit [~pandabear@rrcs-24-103-136-238.nys.biz.rr.com] has joined #bitcoin-wizards 19:37 -!- p15 [~p15@14.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards 19:48 -!- p15 [~p15@14.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 250 seconds] 19:49 -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has quit [Ping timeout: 252 seconds] 19:54 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit [] 19:59 -!- pandabearit [~pandabear@rrcs-24-103-136-238.nys.biz.rr.com] has quit [Ping timeout: 250 seconds] 20:02 -!- execute [~execute@ec2-52-68-0-151.ap-northeast-1.compute.amazonaws.com] has quit [Changing host] 20:02 -!- execute [~execute@unaffiliated/execute] has joined #bitcoin-wizards 20:05 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 20:09 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 20:14 -!- adam3us [~Adium@m121-202-137-111.smartone.com] has quit [Quit: Leaving.] 20:18 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds] 20:24 -!- CubicEarth [~cubiceart@50.141.34.246] has quit [Remote host closed the connection] 20:25 -!- CubicEarth [~cubiceart@50.141.34.246] has joined #bitcoin-wizards 20:29 -!- wallet42 [~wallet42@pcd535135.netvigator.com] has joined #bitcoin-wizards 20:31 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 20:31 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards 20:32 < jl2012> May I say that the rough consensus is to implement sigwit, while the size limit is still subject to debate (or testing etc)? 20:40 < gmaxwell> Thats what I'd like to be true and what I expect will become true, and the feedback I've gotten from one on one polling people. I think you can say its so 'until a chain with more work shows up'. :) 20:40 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has quit [Remote host closed the connection] 20:41 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-wizards 20:46 < jl2012> my impression yesterday was many people liked this. I was not aware of any strong objection 20:50 < gmaxwell> I've recieved some concern that the backdoor size increase is risky and likely harmful to the network; but I think the benefits are too attractive to ignore... basically it has something for everyone. 21:02 -!- CubicEarth [~cubiceart@50.141.34.246] has quit [Remote host closed the connection] 21:02 -!- CubicEarth [~cubiceart@50.141.34.246] has joined #bitcoin-wizards 21:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 21:07 -!- wallet42 [~wallet42@pcd535135.netvigator.com] has quit [Quit: Leaving.] 21:11 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] 21:11 -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 260 seconds] 21:11 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards 21:17 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 21:17 -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has quit [Quit: Leaving.] 21:23 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 21:29 -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-wizards 21:32 -!- mrkent [~textual@unaffiliated/mrkent] has quit [] 21:34 -!- pozitrono [~nu@94.102.63.16] has joined #bitcoin-wizards 21:38 < jl2012> we must have a limit for the backdoor size anyway but that's a seperate topic 21:38 < jl2012> in the most conservative case, just keep the overall limit as 1MB (which I don't agree) 21:39 < jl2012> my point is the backdoor size is not a problem of sigwit per se 21:39 < gmaxwell> Agreed. okay thats true. 21:41 < jl2012> for the backdoor size, it could be 100, 101, 103, 248, flexcap. still open to debate 21:45 -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [] 21:45 < gmaxwell> jl2012: those things don't make sense for the backdoor size; consider say there is a 100MB backdoor size. It can only be used for about 3MB of transactions due to the size ratio between body and witness... but it could be used for 100MB of abuse. 21:46 < gmaxwell> so the ratio between the blocksize and witness size limits is a segwit specific question. 21:48 < jl2012> We could still use an overall limit. Say BIP102, then total block size including witness is 2MB 21:49 < jl2012> instead, we may specify the backdoor limit is 2MB 21:51 < Luke-Jr> I rather like Sacco's 2-4-8 proposal combined with segwit, personally. 21:51 < jl2012> Luke-Jr: In a softfork way or hardfork way? 21:52 < gmaxwell> Sacco? 21:52 < Luke-Jr> jl2012: softfork of coure 21:52 < Luke-Jr> gmaxwell: he posted to the dev ML a while back 21:52 -!- gocrazy [~gocrazey@69.7.121.63] has quit [Remote host closed the connection] 21:52 < jl2012> In a softfork way, the non-witness parts must be <= 1MB forever 21:52 < Luke-Jr> gmaxwell: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011731.html 21:53 < Luke-Jr> gmaxwell: obviously I don't like or think the miner vote here is necessary 21:53 < Luke-Jr> jl2012: s/forever/until some future hardfork/ 21:54 < jl2012> Luke-Jr: maybe to have one BIP, which is softfork at the begining , and become a hardfork in a few years. So people will have enough time to migrate 21:54 < Luke-Jr> jl2012: sure, that would make sense 21:57 -!- AaronvanW [~ewout@202.83.241.187] has joined #bitcoin-wizards 21:57 -!- AaronvanW [~ewout@202.83.241.187] has quit [Changing host] 21:57 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 22:02 < CubicEarth> gmaxwell: bitcoin currently has an theoretical max of 7 tps. With SegWit that increases to 10.5 tps. This is a 50% increase under 'ideal conditions'. SegWit can offer more than a 50% bump under typical conditions, but under those 'less than ideal' conditions, the 10.5 tps would take a hit as well. If that is correct, I think its a helpful way to help people understand what SegWit does and doesn't do. 22:03 < tulip> CubicEarth: I struggle to see "transactions per second" as a meaningful metric. 22:03 < Luke-Jr> ^ +1 22:03 < Luke-Jr> Bitcoin has no tps limit, since you can always do things off-chain 22:03 < tulip> well, and people seem to conflate one transaction with one entity making it, which isn't true. 22:04 -!- nivah [~linker@115.79.55.177] has joined #bitcoin-wizards 22:04 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] 22:05 -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards 22:06 < CubicEarth> tulip: It absolutely is. I understand you may be making a point, and Luke is too. Yes you can do lots off chain, but on chain capacity matters. 22:07 < gmaxwell> CubicEarth: yes, though less than many assume. 22:07 < tulip> CubicEarth: 10.5 transactions though, what's a "typical" transaction? 22:08 < Luke-Jr> CubicEarth: it matters, but calling it "tps" is unnecessarily confusing 22:08 < gmaxwell> The "per-second" scale is also suspect, considering that the mean blocktime is 10 minutes, bitcoin does nothing "per second"; might as well also say that it does a half million transactions per day, but that doesn't sound so obviously small. 22:08 < Luke-Jr> and since blockchain-transactions vary significantly in side, measuring it in this way is probably not even useful 22:09 < Luke-Jr> what gmaxwell said too 22:09 < CubicEarth> gmaxwell: agreed. I would be happy to switch to per-day amounts. But it helps to have a common language for understanding the chains transaction clearing capacity. 22:10 < tulip> transactions per day is still meaningless until you can define what a transaction looks like. 22:10 < jl2012> in any sigwit scheme, do we allow reuse of witness in the same tx or even same block to save more space? e.g. one witness for the same scriptPubKey? 22:11 < jl2012> something like: "same as the witness x of tx y in this block" 22:11 < gmaxwell> jl2012: doing so would deeply break the layering used in bitcoin, and incentivize key reuse. I don't think it would be a fein. 22:11 < aj> jl2012: that would require a signature that didn't sign the transaction id to be useful too 22:11 < gmaxwell> Also if they're really the same, then that can be handed just with non-consensus storage and line encoding. 22:12 < jl2012> key reuse does have legitimate use like a charity accepting donation which is supposed to be open anyway 22:12 < CubicEarth> tulip: it's not like I am the first person to talk about a "typical tx". Typical... is not an exact thing. I think "mean tx size" for the last 10,000 blocks would suffice for what I am trying to say 22:12 < Luke-Jr> CubicEarth: the only thing it helps, IMO, is making invalid comparisons to VISA/etc tps 22:13 < gmaxwell> CubicEarth: an important thing to keep in mind is that kind of fancy smart contracts used to move load off the chain result in larger transactions when they do hit the chain. 22:13 < Luke-Jr> jl2012: no, it doesn't. 22:13 < tulip> CubicEarth: I realise, the point I'm making is that the "transactions per second" metric is predicated on knowing what the size of a normal transaction is, and the commonly quoted figure is completely out of touch with reality. 22:13 < Luke-Jr> jl2012: a charity can publish their watch-only HD seed if they want (but I don't know if I would advise it) 22:14 < CubicEarth> gmaxwell: absolutely. And I get that SegWit shines in this respect, that is where it offers the most 'throughput increase' vs what would otherwise be the case 22:14 < gmaxwell> jl2012: yes; it does, but thats fairly narrow and there are lot of really serious negative side effects. 22:15 < tulip> CubicEarth: at the time the quoted number was posted on the wiki for example, most transactions used uncompressed point EC keys which wastes 32 bytes per signature for absolutely no reason. 22:15 < gmaxwell> tulip: in theory they're very slightly faster to verify! 22:15 < jl2012> Luke-Jr: allowing witness reuse will save a lot of costs for recepients of micropayment. Also save all the CPU validation costs 22:15 < gmaxwell> (which is probably lost in hashing more data...) 22:16 < gmaxwell> jl2012: when checksig is updated verification costs for many signatures at a time will be halved again from when they are now. 22:17 < CubicEarth> tulip: Is the 7 tps figure what you are referring to? 22:17 < jl2012> gmaxwell: it's the difference of O(1) and O(n) 22:17 < Luke-Jr> jl2012: sounds like more reasons not to do it 22:17 < tulip> CubicEarth: yes. 22:17 < gmaxwell> jl2012: in any case, assuming that sighash flags are setup such that the same hashes can be used; then those savings can all be had in non-normative ways; without breaking the layering. 22:18 < tulip> gmaxwell: sorry, I'd forgotten Satoshi had optimisations like that and OP_RETURN for even faster EC validation. 22:18 < gmaxwell> jl2012: only when you think the amount of reuse is unbounded, in practice a transaction would consume 2-to a dozen inputs. 22:19 < gmaxwell> tulip: haha 22:19 < jl2012> ttyl 22:19 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 22:22 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 22:23 < CubicEarth> tulip: Luke-Jr: It sounds like the problem you have with the "TPS" metric is that people use it improperly, and/or that they use it to push silly arguments or arrive at incorrect conclusions. As your point about VISA. But I think it would be a shame to toss out a perfectly good metric just because it may be used inappropriately. Rest assured there are many Bitcoiners who will understand how to use the metric, and let it help 22:23 < CubicEarth> them. 22:24 < Luke-Jr> … I don't understand how to use it. 22:24 < tulip> CubicEarth: that's not the problem, I'm just asking you to describe what the size of a "normal" transaction is. I'm saying that there's a complete disconnect with "7" TPS, it's nothing like that with transactions today and has never been. 22:25 < CubicEarth> 500 bytes 22:25 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds] 22:26 < CubicEarth> And 802.11 G is not actually 54 Mbps.... 22:27 < tulip> 500 bytes only works with an assumption of 2 in 2 out. 22:27 -!- Jeremy_Rand_ [~jeremy@172.56.6.1] has joined #bitcoin-wizards 22:28 -!- Erik_dc [~erik@d54C620ED.access.telenet.be] has joined #bitcoin-wizards 22:29 < CubicEarth> so, what would say is typical ;) 22:29 < aj> CubicEarth: (500B is about 3.3 tx/s @ 1MB) 22:29 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 22:32 < tulip> lets work from the other way. 22:33 < CubicEarth> let 22:34 < tulip> 6MB/hour is 1.6KB/s. so there's no way we can make this work. 22:35 < CubicEarth> No way to make what work? 22:35 < gmaxwell> CubicEarth: he just proved bitcoin doesn't exist 22:35 < tulip> you could do "7 TPS" if each transaction was 238 bytes. 22:36 < aj> tulip: 1 in 2 out p2pkh takes about 224B/tx, so not totally impossible 22:36 < tulip> aj: yes, but those transactions have a change output which needs to be merged. if you never merge you grind the UTXO into dust. 22:36 < CubicEarth> gmaxwell: That what I though too, so I figured I ask again :) 22:37 < gmaxwell> One thing I haven't seen people notice/comment on in segwitness; is that we're also setting up to increase the p2sh hash to 256 bits. We made an error in continuing to use the 160 bit hash for p2sh. 22:38 < aj> gmaxwell: i did see that! didn't seem worth commenting on though... 22:38 < tulip> if you're promoting a metric which makes real world use impossible it's a pretty meaningless 22:38 < gmaxwell> aj: I'm surprised we don't get more complaints about p2sh. 22:38 < aj> gmaxwell: what's the error? 22:39 < gmaxwell> aj: you generate a 2 of 2 for you and I (or whatnot, some policy I care about for escrow/smart contract with you) 22:39 < gmaxwell> but you do 2^80 work with your fpga farm, and also construct a 1 of 1 with the same hash... 22:39 -!- Jeremy_Rand_ is now known as Jeremy_Rand 22:39 -!- Jeremy_Rand [~jeremy@172.56.6.1] has quit [Quit: Konversation terminated!] 22:39 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 22:39 < tulip> aj: well we can do like 50+ transactions a second or something if we just make every output everyone can spend, and just use trust. 22:40 < gmaxwell> aj: not critically weak, but not awesome either. 22:40 -!- Jeremy_Rand [~jeremy@172.56.6.1] has joined #bitcoin-wizards 22:40 < aj> gmaxwell: ah, true, especially given p2sh can be arbitrarily long term... 22:41 < aj> tulip: "make every output anyone can spend" is the segwit rollout plan :) 22:41 < gmaxwell> p2pkh didn't have this problem; since it's always 1 of 1, there is seldom room to make any use of a collision. 22:42 < gmaxwell> aj: tecnically but not so efficient since they still must have a pubkey. :P 22:42 < CubicEarth> tulip: TPS as a metric != 7, or any other number. You're some good points about 7 TPS being an unreasonable figure for comparisons, saying in essence "it doesn't really exist". But that's the '7' not the TPS-as-a-metric part. 22:42 < gmaxwell> quote from reddit: "Let's segwit it already!" 22:43 < tulip> CubicEarth: it's still completely meaningless, especially as transactions in Bitcoin can have multiple users and uses. 22:43 -!- taek42- [~david@202.83.241.187] has joined #bitcoin-wizards 22:45 < gmaxwell> how many transactions per second is a coinjoin or a cut-through? 22:45 < CubicEarth> tulip: there mere fact that you acknowledge that "transactions" exist is enough to show that TPS is meaningful, unless you don't consider time exist or matter. Ug! 22:45 < gmaxwell> hahah 22:45 < gmaxwell> concept of 'self' is overrated. 22:45 < gmaxwell> Where do you end and does the transaction begin? 22:46 < CubicEarth> AI singularity -- the merge is near 22:46 -!- nivah [~linker@115.79.55.177] has quit [Ping timeout: 240 seconds] 22:46 < gmaxwell> As long as it isn't the AI singularity of "friendship is optimal" 22:48 < tulip> CubicEarth: you can cooperate to make transactions, I can happily make a wallet which cooperates to make all transactions coinjoins between random people- which ruins the metric entirely. 22:50 -!- nivah [~linker@115.79.55.177] has joined #bitcoin-wizards 22:50 -!- N0S4A2 [~weechat@216-243-38-141.users.condointernet.net] has quit [Quit: WeeChat 1.3] 22:50 < CubicEarth> tulip: Happily, huh? 22:51 < gmaxwell> I do suspect this conversation has drifited into a boring domain of semantics. :) 22:51 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 22:51 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has quit [] 22:51 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-bptxirzavgbbvrzw] has quit [Quit: Connection closed for inactivity] 22:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yrwrqxukqqscrqad] has joined #bitcoin-wizards 22:52 -!- Jeremy_Rand [~jeremy@172.56.6.1] has quit [Ping timeout: 272 seconds] 22:52 < CubicEarth> It almost seems so. Sux. I came here to understand something better, and am about to leave with my metric seemingly in tatters. 22:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 22:57 -!- CubicEarth [~cubiceart@50.141.34.246] has quit [Remote host closed the connection] 22:58 -!- CubicEarth [~cubiceart@50.141.34.246] has joined #bitcoin-wizards 23:00 < CubicEarth> tulip: what do you suggest as a metric that would be more helpful than TPS? 23:02 -!- Erik_dc [~erik@d54C620ED.access.telenet.be] has quit [Remote host closed the connection] 23:03 < maaku> ' maaku: i see your point, but at this point i think CT in bitcoin is completely unreasonable anyway...' <-- what do you mean? unreasonable in what way? 23:04 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards 23:04 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 23:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards 23:06 < gmaxwell> maaku: well I could answer that; it's very resource expensive, ... maybe it's low enough but we haven't even qualified how low would be low enough. 23:07 < gmaxwell> it also has only computational soundness; which is a pretty big step from what bitcoin provides, at least theoretically. Same security assumption as the signatures, but invisible signature breaks aren't really possible. 23:07 < maaku> gmaxwell: if it's opt-in though... and has a cheap conversion out (reveal blinding key to spend an output explicitly) 23:08 < gmaxwell> yea, I don't think it's completely unreasonable; but nor is it completely reasonable! 23:08 < tulip> CubicEarth: I don't know. suggesting something is a bad idea often doesn't mean I'm aware of something better. I'd just be cautious making metrics like that and trying to satisfy them. 23:08 < gmaxwell> or at least I don't know if it or isn't! :) 23:10 < gmaxwell> maaku: I'd like to figure out what it would take though. 23:10 < maaku> gmaxwell: right I get that CT carries complicated cost tradeoffs which, if everyone used CT, would decrease bitcoin's capacity by a over an order of magnitude 23:11 < maaku> but keeping it opt-in nullifies that concern from my perspective. if you want it you pay for it. 23:11 < gmaxwell> there also may be better alternative models for 'occasional use'. E.g. a ZKP accumulator. 23:11 < maaku> gmaxwell: what would make me hesitate is if there was something on the horizon better than CT, or the same features with less cost 23:11 -!- supahot [~michael@weaver-e115-ResHalls.Mines.EDU] has joined #bitcoin-wizards 23:12 < maaku> but is there anything like that on the horizon? 23:12 < maaku> with math that actually exists I mean, not hypothicated efficient snarks that may never exist 23:13 < gmaxwell> Zerocash; whos weaknesses are also fit nicer with opt-in. In particular; the trusted setup could be obviated allowing user initated accumulators that had their own verifying keys. 23:14 < gmaxwell> As in you could burn bitcoins to pay to initate an accumulator with its own trusted setup key, dump coins in over time, pull coins out. 23:14 -!- supahot [~michael@weaver-e115-ResHalls.Mines.EDU] has quit [Quit: Leaving] 23:16 -!- N0S4A2 [~weechat@216-243-38-141.users.condointernet.net] has joined #bitcoin-wizards 23:16 < maaku> gmaxwell: I'm not sure CT and ZC significantly overlap in applications 23:17 < maaku> in particular ZKP of zerocash require significant computaitonal power to create. you couldn't practically have lightning network with zerocash payment channels 23:18 < maaku> whereas I'd be very interested in CT setup/settlement transactions 23:18 < gmaxwell> Thats true; (well the proving is almost embarassingly parallel and delegatable to anyone you don't mind not being private wrt to; but your point remains) 23:19 < gmaxwell> maaku: I'd given little/no thought to CT channels; it's an interesting thought. 23:20 -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards 23:21 < maaku> actually I'd very interested if someone were to study CT channels. I'm not certain what properties they would have, but it'd certainly limit leakage balance information into the historical record 23:22 < maaku> but maybe with combination of onion routing and zero-knowledge path finding it could do even better 23:23 < amiller> im trying to figure out snark + channels 23:24 -!- CubicEarth [~cubiceart@50.141.34.246] has quit [Remote host closed the connection] 23:24 < amiller> the snark there is mostly just so i can use saner notation, you could probably take whatever i come up with and approximate it with CT 23:24 < gmaxwell> maaku: well they'd 'just work' but I'm not sure what they'd provide; needs ZK pathfinding or the channel amounts are all public. 23:24 < maaku> right 23:25 < maaku> i was annoyed when I actually looked at the onion routing work and realized onion routing != ZK pathfinding 23:25 < maaku> is there anyone working on ZK pathfinding? 23:29 -!- p15 [~p15@11.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards 23:29 < amiller> maaku, yeah the way to do it would be to pass along something that isn't a snark 23:30 < amiller> you wouldn't make a snark proof each time you make an incremental payment 23:33 -!- markus-k [~markus-k@designnet.work.de] has joined #bitcoin-wizards 23:34 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 23:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 23:42 -!- p15 [~p15@11.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 256 seconds] 23:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 23:49 -!- JackH [~Jack@host-80-43-143-143.as13285.net] has joined #bitcoin-wizards 23:50 -!- CubicEarth [~cubiceart@50.141.34.241] has joined #bitcoin-wizards 23:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 23:54 -!- taek42- [~david@202.83.241.187] has quit [Quit: Leaving] 23:55 -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] 23:57 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 240 seconds] 23:58 -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Ping timeout: 256 seconds] 23:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] --- Log closed Tue Dec 08 00:00:31 2015