| --- Log opened Mon Dec 07 00:00:30 2015 | ||
| -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards | 00:01 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Quit: Leaving.] | 00:01 | |
| -!- memymo [~textual@202.171.211.253] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 00:04 | |
| -!- dstadulis [~dstadulis@202.83.241.187] has joined #bitcoin-wizards | 00:06 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 00:07 | |
| -!- nivah [~linker@115.79.55.177] has joined #bitcoin-wizards | 00:08 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 00:09 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 00:09 | |
| -!- 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:10 | |
| -!- 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:11 | |
| -!- 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:14 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 00:15 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 00:15 | |
| -!- adam3us [~Adium@202.83.241.113] has quit [Quit: Leaving.] | 00:17 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 00:19 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 00:19 | |
| -!- 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:22 | |
| -!- 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:27 | |
| -!- 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:30 | |
| -!- 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:34 | |
| -!- dstadulis [~dstadulis@202.83.241.187] has quit [Quit: ZZZzzz…] | 00:37 | |
| -!- adam3us [~Adium@202.83.241.113] has joined #bitcoin-wizards | 00:37 | |
| -!- adam3us [~Adium@202.83.241.113] has quit [Client Quit] | 00:38 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 00:41 | |
| -!- 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:42 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 00:44 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 00:44 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer] | 00:45 | |
| -!- tulip [~tulip@unaffiliated/tulip] has quit [Ping timeout: 264 seconds] | 00:47 | |
| -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards | 00:47 | |
| -!- 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:48 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 00:50 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 00:50 | |
| -!- dstadulis [~dstadulis@202.83.241.187] has joined #bitcoin-wizards | 00:51 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 00:52 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 00:52 | |
| -!- 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:53 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 00:55 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 00:55 | |
| -!- 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:56 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 00:57 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 00:57 | |
| -!- 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:58 | |
| -!- dstadulis [~dstadulis@202.83.241.187] has quit [Quit: ZZZzzz…] | 00:59 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 01:00 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 01:00 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] | 01:04 | |
| -!- dstadulis [~dstadulis@202.83.241.187] has joined #bitcoin-wizards | 01:08 | |
| -!- rgrant [~user@14.0.209.109] has quit [Ping timeout: 245 seconds] | 01:09 | |
| -!- pozitron [~nu@109.201.143.40] has quit [Ping timeout: 260 seconds] | 01:11 | |
| -!- rustyn [~rustyn@unaffiliated/rustyn] has joined #bitcoin-wizards | 01:12 | |
| -!- 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:14 | |
| -!- dEBRUYNE [~dEBRUYNE@88.159.197.56] has joined #bitcoin-wizards | 01:15 | |
| -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards | 01:17 | |
| -!- p15_ [~p15@119.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards | 01:18 | |
| -!- p15 [~p15@68.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 260 seconds] | 01:19 | |
| -!- Alanius_ is now known as Alanius | 01:22 | |
| -!- rgrant [~user@14.0.209.109] has quit [Ping timeout: 246 seconds] | 01:23 | |
| -!- tulip [~tulip@unaffiliated/tulip] has quit [Ping timeout: 264 seconds] | 01:25 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 01:27 | |
| -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards | 01:28 | |
| -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-wizards | 01:28 | |
| -!- wallet42 [~wallet42@202.83.241.187] has quit [Client Quit] | 01:30 | |
| -!- pozitrono [nu@gateway/vpn/mullvad/x-udidrjlzdcuoidtq] has joined #bitcoin-wizards | 01:31 | |
| -!- gielbier [~giel____@unaffiliated/gielbier] has quit [Quit: Leaving] | 01:33 | |
| -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards | 01:35 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 01:36 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 01:46 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 01:46 | |
| -!- 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:49 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 260 seconds] | 01:50 | |
| -!- 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:51 | |
| -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards | 01:52 | |
| -!- taek42- [~david@202.83.241.187] has quit [Ping timeout: 246 seconds] | 01:53 | |
| -!- matsjj [~matsjj@89.197.31.78] has joined #bitcoin-wizards | 01:55 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] | 01:55 | |
| -!- 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:04 | |
| tulip | frankenmint: they're TCP packet types really. | 02:12 |
|---|---|---|
| tulip | we need a reason to RESET pull requests. | 02:12 |
| -!- GGuyZ [~GGuyZ@202.83.241.113] has quit [Quit: GGuyZ] | 02:13 | |
| -!- GGuyZ [~GGuyZ@202.83.241.113] has joined #bitcoin-wizards | 02:24 | |
| -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Ping timeout: 264 seconds] | 02:28 | |
| -!- rgrant [~user@14.0.209.109] has quit [Ping timeout: 260 seconds] | 02:33 | |
| -!- GGuyZ [~GGuyZ@202.83.241.113] has quit [Ping timeout: 260 seconds] | 02:34 | |
| -!- dEBRUYNE [~dEBRUYNE@88.159.197.56] has quit [Ping timeout: 260 seconds] | 02:36 | |
| -!- rgrant [~user@14.0.209.109] has joined #bitcoin-wizards | 02:38 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 02:40 | |
| -!- GGuyZ [~GGuyZ@202.83.241.113] has joined #bitcoin-wizards | 02:40 | |
| -!- forrestv [forrestv@unaffiliated/forrestv] has joined #bitcoin-wizards | 02:42 | |
| -!- dEBRUYNE [~dEBRUYNE@88.159.197.56] has joined #bitcoin-wizards | 02:43 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 02:43 | |
| -!- zooko [~zooko@202.83.241.113] has joined #bitcoin-wizards | 02:47 | |
| -!- shesek [~shesek@bzq-84-110-36-12.cablep.bezeqint.net] has quit [Ping timeout: 245 seconds] | 02:48 | |
| -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Ping timeout: 264 seconds] | 02:49 | |
| -!- dstadulis [~dstadulis@202.83.241.187] has joined #bitcoin-wizards | 02:56 | |
| -!- dstadulis [~dstadulis@202.83.241.187] has quit [Client Quit] | 02:56 | |
| -!- forrestv [forrestv@unaffiliated/forrestv] has joined #bitcoin-wizards | 02:57 | |
| -!- p15 [~p15@30.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 260 seconds] | 02:58 | |
| -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Excess Flood] | 02:59 | |
| -!- dEBRUYNE [~dEBRUYNE@88.159.197.56] has quit [Quit: Leaving] | 02:59 | |
| -!- forrestv [forrestv@unaffiliated/forrestv] has joined #bitcoin-wizards | 03:00 | |
| -!- rgrant [~user@14.0.209.109] has quit [Quit: leaving] | 03:00 | |
| -!- GGuyZ [~GGuyZ@202.83.241.113] has quit [Quit: GGuyZ] | 03:02 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 03:05 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 03:06 | |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [Remote host closed the connection] | 03:08 | |
| -!- 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:09 | |
| -!- tulip [~tulip@unaffiliated/tulip] has quit [Ping timeout: 264 seconds] | 03:12 | |
| -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards | 03:12 | |
| -!- zooko [~zooko@202.83.241.113] has quit [Ping timeout: 260 seconds] | 03:15 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 03:27 | |
| -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] | 03:32 | |
| -!- 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:33 | |
| -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards | 03:34 | |
| -!- 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:35 | |
| -!- dabura667 [uid43070@gateway/web/irccloud.com/x-anjolmhqcjsrzgmb] has joined #bitcoin-wizards | 03:38 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 03:46 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 246 seconds] | 03:51 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 245 seconds] | 03:57 | |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards | 04:04 | |
| -!- nivah [~linker@115.79.55.177] has quit [Ping timeout: 260 seconds] | 04:05 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] | 04:08 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 04:11 | |
| 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:19 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-recrkoozibopkqsc] has joined #bitcoin-wizards | 04:22 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] | 04:23 | |
| -!- 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:26 | |
| -!- hashtag_ [~hashtag@174.97.254.80] has quit [Ping timeout: 260 seconds] | 04:27 | |
| -!- hashtag_ [~hashtag@174.97.254.80] has joined #bitcoin-wizards | 04:33 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 04:33 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 04:41 | |
| -!- Casper- [~Casper@garza.riseup.net] has quit [Ping timeout: 260 seconds] | 04:43 | |
| -!- c0rw|zZz_ [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 04:45 | |
| -!- c0rw|zZz [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 246 seconds] | 04:48 | |
| -!- 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:49 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 04:51 | |
| -!- c0rw|zZz [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 04:52 | |
| -!- c0rw|zZz_ [~c0rw1n@137.181-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds] | 04:55 | |
| -!- AEM [AEM@gateway/shell/elitebnc/x-dprxesqlyuschtkh] has joined #bitcoin-wizards | 04:56 | |
| -!- kyluke [~fnb@41.147.46.100] has joined #bitcoin-wizards | 05:02 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 05:11 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards | 05:15 | |
| -!- 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:39 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 245 seconds] | 05:46 | |
| -!- AEM is now known as aem | 05:55 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 05:57 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] | 06:08 | |
| -!- 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:16 | |
| -!- 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:17 | |
| -!- 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:21 | |
| -!- Starduster_ [~guest@unaffiliated/starduster] has joined #bitcoin-wizards | 06:22 | |
| -!- 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:23 | |
| -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has joined #bitcoin-wizards | 06:24 | |
| -!- joesmoe [~joesmoe@76.73.18.156] has joined #bitcoin-wizards | 06:24 | |
| -!- 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:25 | |
| -!- 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:26 | |
| -!- 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:27 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-yrkdqwrxgcfytrlf] has joined #bitcoin-wizards | 06:30 | |
| -!- 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:32 | |
| -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-wizards | 06:34 | |
| -!- maaku is now known as Guest35069 | 06:34 | |
| -!- 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:35 | |
| -!- 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:37 | |
| -!- 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:40 | |
| -!- c0rw|zZz_ [~c0rw1n@48.129-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds] | 06:43 | |
| -!- 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:46 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] | 06:49 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 06:50 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 06:52 | |
| -!- 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:53 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] | 06:54 | |
| -!- 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:55 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 06:59 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] | 06:59 | |
| -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards | 07:00 | |
| -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has joined #bitcoin-wizards | 07:01 | |
| -!- 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:02 | |
| -!- memymo [~textual@202.171.211.253] has quit [Client Quit] | 07:03 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] | 07:04 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 07:05 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 07:07 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 07:09 | |
| -!- 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:12 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 256 seconds] | 07:13 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] | 07:14 | |
| -!- memymo [~textual@202.171.211.253] has quit [Client Quit] | 07:15 | |
| -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards | 07:17 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 07:18 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] | 07:21 | |
| -!- 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:24 |
| -!- 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:25 |
| -!- GGuyZ [~GGuyZ@202.171.211.253] has joined #bitcoin-wizards | 07:26 | |
| -!- dstadulis [~dstadulis@202.171.211.253] has joined #bitcoin-wizards | 07:27 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 07:28 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] | 07:28 | |
| oldbrew | so much for ROI | 07:29 |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 07:31 | |
| oldbrew | too many cooks spoil the broth | 07:35 |
| oldbrew | might be better if they acted like a team at least | 07:36 |
| -!- 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:37 | |
| -!- TBI [~TBI@20.84-48-195.nextgentel.com] has joined #bitcoin-wizards | 07:38 | |
| -!- dstadulis [~dstadulis@202.171.211.253] has quit [Quit: Textual IRC Client: www.textualapp.com] | 07:43 | |
| -!- kyluke [~fnb@41.147.46.100] has quit [Read error: Connection reset by peer] | 07:48 | |
| -!- 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:05 | |
| -!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards | 08:07 | |
| -!- adam3us [~Adium@45.64.240.161] has joined #bitcoin-wizards | 08:13 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Quit: Leaving] | 08:20 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] | 08:22 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards | 08:25 | |
| 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:35 |
| -!- jl2012 [~jl2012@119246245241.ctinets.com] has joined #bitcoin-wizards | 08:36 | |
| 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:40 |
| -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-wizards | 08:41 | |
| tromp__ | is 75% the max fraction of sig size in a tx? | 08:43 |
| 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:47 |
| -!- digitalmagus8 [~digitalma@unaffiliated/digitalmagus] has quit [] | 08:48 | |
| 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:49 | |
| 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:51 |
| 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:52 |
| oldbrew | and with indexing ? | 08:54 |
| 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:55 |
| 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:57 |
| jl2012 | old nodes will allow spending of such output with an empty scriptSig. upgraded will will require extra data (ie. witness) | 08:58 |
| 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 | 08:59 |
| jl2012 | and the total size of these components must not be bigger than 1MB or that will be a hardfork | 09:00 |
| oldbrew | https://en.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time | 09:01 |
| 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:02 |
| oldbrew | https://en.bitcoin.it/wiki/Protocol_documentation#cite_note-2 | 09:03 |
| 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:04 |
| -!- Guest35069 is now known as maaku | 09:05 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 09:09 | |
| -!- eudoxia [~eudoxia@r186-49-241-192.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 09:12 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 272 seconds] | 09:14 | |
| maaku | brg444: I disagree with Pieter's accounting methodology in his segwitness branch | 09:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| maaku | jl2012: jonas' work counts size as a cost, because of relay costs. you would not be able to fill 32MB at first | 09:20 |
| brg444 | what's your take on the suggested 4mb increase with regards to bandwidth? lukejr seemed not to be sold on the idea? | 09:21 |
| 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:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| -!- 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:31 | |
| wallet42 | confidential transactions? | 09:32 |
| maaku | yes, confidential transactions | 09:32 |
| -!- bendavenport [~bpd@96.90.231.161] has joined #bitcoin-wizards | 09:34 | |
| 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:35 |
| -!- 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:36 | |
| -!- bhollan [~hollabr@177.237.169.171] has left #bitcoin-wizards [] | 09:37 | |
| maaku | jl2012: the commitment location would almost certainly be moved in a hard fork the minimize and remove variance from hard fork size | 09:39 |
| 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:41 |
| -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-wizards | 09:42 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 09:47 | |
| -!- AEM [AEM@gateway/shell/elitebnc/x-lhnzqmikxfwduvsg] has joined #bitcoin-wizards | 09:47 | |
| -!- opitka [~0ptika@50.248.81.65] has quit [Quit: Leaving] | 09:48 | |
| morcos | maaku: Aren't you worried that very large witness sizes will make it hard to run a full node? | 09:49 |
| oldbrew | or invalid der signature with leap second issue | 09:52 |
| -!- GfxdjGFhgF [~KHDXGFHGh@86.121.179.34] has joined #bitcoin-wizards | 09:59 | |
| tromp__ | i thought full nodes would verify new SW blocks by reconstructing the witness merkle tree from their memory pool | 10:05 |
| -!- btcdrak [uid115429@gateway/web/irccloud.com/x-vqyqhnvddknqgsyy] has quit [Quit: Connection closed for inactivity] | 10:06 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds] | 10:11 | |
| -!- 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:14 | |
| -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Client Quit] | 10:16 | |
| -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-wizards | 10:17 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] | 10:23 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards | 10:25 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] | 10:29 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards | 10:32 | |
| -!- AEM is now known as aem | 10:36 | |
| -!- 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:38 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards | 10:41 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] | 10:45 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Read error: Connection reset by peer] | 10:46 | |
| -!- 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:48 | |
| -!- TBI_ [~TBI@84.48.195.20] has joined #bitcoin-wizards | 10:49 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards | 10:49 | |
| -!- 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:51 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 10:54 | |
| -!- 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:00 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 11:04 | |
| -!- CubicEarth [~cubiceart@50.141.34.192] has quit [Remote host closed the connection] | 11:10 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 11:12 | |
| -!- mariorz__ is now known as mariorz | 11:15 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-yrkdqwrxgcfytrlf] has quit [Quit: Connection closed for inactivity] | 11:31 | |
| -!- CubicEarth [~cubiceart@50.141.34.213] has joined #bitcoin-wizards | 11:41 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] | 11:41 | |
| -!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Remote host closed the connection] | 11:43 | |
| -!- GfxdjGFhgF [~KHDXGFHGh@86.121.179.34] has quit [Quit: Leaving] | 11:45 | |
| -!- eudoxia [~eudoxia@r179-24-172-24.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 11:51 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 11:58 | |
| -!- matsjj [~matsjj@31.75.115.90] has joined #bitcoin-wizards | 12:06 | |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] | 12:12 | |
| -!- CubicEarth [~cubiceart@50.141.34.213] has quit [Remote host closed the connection] | 12:15 | |
| -!- CubicEarth [~cubiceart@50.141.32.138] has joined #bitcoin-wizards | 12:19 | |
| -!- ebfull [~sean@73.34.119.0] has quit [Remote host closed the connection] | 12:21 | |
| -!- davec [~davec@24.243.251.52] has quit [Read error: Connection reset by peer] | 12:24 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 12:25 | |
| sipa | tromp__: you can't rely on mempool consistency | 12:36 |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 12:39 | |
| kanzure | mempool should be renamed to anticonsistency-accumulator | 12:42 |
| -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit] | 12:44 | |
| -!- pozitron [~nu@89.248.174.14] has quit [Ping timeout: 240 seconds] | 12:45 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] | 12:49 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 12:55 | |
| tromp__ | my suggestion requires some method like IBLT to resolve tx discrepancies | 13:02 |
| tromp__ | the ultimate savings would be a single zero knowledge proof that the whole merkle tree of witnesses exists | 13:03 |
| -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Ping timeout: 245 seconds] | 13:04 | |
| 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:05 |
| 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:06 | |
| kanzure | tromp__: everyone else just sees ANYONECANSPEND stuff | 13:07 |
| tromp__ | when 4*nonwitness can exceed 1MB? | 13:07 |
| 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:08 |
| 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:09 |
| -!- bendavenport [~bpd@96.90.231.161] has quit [Quit: bendavenport] | 13:10 | |
| 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:12 |
| 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:13 | |
| 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:14 |
| -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-wizards | 13:16 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 13:19 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 13:27 | |
| -!- 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 | |
| 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:37 |
| morcos | oh commits to the block and the tx, how does it commit to the tx | 13:38 |
| 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:39 |
| gmaxwell | and the index is just which tx in the block is involved, saving having to send the whole thing. | 13:40 |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 13:45 | |
| 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:46 |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 13:50 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] | 13:51 | |
| sipa | morcos: they can show the data at the position/height claimed they are spending from | 13:52 |
| 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:53 |
| -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has joined #bitcoin-wizards | 13:54 | |
| 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:55 |
| 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:56 |
| -!- 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) | 13:58 |
| 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:00 |
| 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:01 | |
| 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:02 |
| morcos | sorry, maybe thats what you meant by all block data. all of a block when they need soemthing from that block. | 14:03 |
| 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:04 | |
| morcos | gmaxwell: you're welcome for my time | 14:05 |
| morcos | wow, awesome didn't realize you had it coded up for bitcoin already, assumed it was just in elements | 14:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:13 |
| -!- 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:14 | |
| 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:15 |
| 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:18 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| tromp__ | no need to change the pow, just phase in a second one:) | 14:28 |
| gmaxwell | tromp__: yea, I meant change expansively. | 14:29 |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-wizards | 14:30 | |
| 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:32 | |
| CubicEar_ | what else you think it is based on? | 14:33 |
| coinoperated_rob | access to ideal cost basis for infrastructure | 14:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 | |
| -!- 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:43 | |
| 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:45 |
| 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:47 |
| 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:49 |
| coinoperated_rob | apologies if this question has been done to death in here | 14:50 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| -!- 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:58 |
| 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 | 14:59 |
| gmaxwell | well the speed of light can be centeralized away. | 15:00 |
| 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:01 |
| 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:02 |
| -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards | 15:06 | |
| 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:07 |
| docl | Will we be moving close to the surface of the sun to maximize energy expenditure while minimizing time delay? | 15:08 |
| 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:09 |
| 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:11 |
| coinoperated_rob | global consensus mechanisms subject to global consensus on using global consensus meechanism. is consensus all the way up | 15:12 |
| kanzure | astronomical distances require more latency | 15:13 |
| coinoperated_rob | @doc1 1/300th is diameter or 1/2 circumference? | 15:14 |
| docl | Oops, it's more than that. 1 billion meters, so about 3 seconds. | 15:16 |
| moa | consensus networks on a Dyson sphere would be how slow then? | 15:17 |
| docl | coinoperated_rob: That was referring to the diameter of the sun. | 15:18 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 246 seconds] | 15:19 | |
| -!- 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:22 | |
| 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:30 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 15:32 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 15:34 | |
| -!- 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:37 |
| -!- pandabearit [~pandabear@pool-98-118-162-190.bflony.fios.verizon.net] has quit [Ping timeout: 272 seconds] | 15:40 | |
| -!- phy1729 [~phy1729@unaffiliated/phy1729] has quit [Killed (c (*lightning bolts*))] | 15:41 | |
| -!- phy1729 [~phy1729@unaffiliated/phy1729] has joined #bitcoin-wizards | 15:42 | |
| -!- Jeremy_Rand [~jeremy@ip68-97-32-41.ok.ok.cox.net] has quit [Ping timeout: 245 seconds] | 15:49 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 15:51 | |
| -!- adam3us [~Adium@45.64.240.161] has quit [Ping timeout: 240 seconds] | 15:57 | |
| -!- wallet42 [~wallet42@pcd535135.netvigator.com] has quit [Quit: Leaving.] | 16:03 | |
| -!- adam3us [~Adium@45.64.240.214] has joined #bitcoin-wizards | 16:06 | |
| -!- 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:09 | |
| -!- 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:14 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 16:16 | |
| -!- GGuyZ [~GGuyZ@202.171.211.253] has quit [Quit: GGuyZ] | 16:22 | |
| -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-wizards | 16:30 | |
| -!- 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:32 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 16:34 | |
| -!- Casper- [~Casper@garza.riseup.net] has joined #bitcoin-wizards | 16:35 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] | 16:36 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 16:38 | |
| -!- a5m0 [~a5m0@unaffiliated/a5m0] has quit [Remote host closed the connection] | 16:41 | |
| -!- a5m0 [~a5m0@unaffiliated/a5m0] has joined #bitcoin-wizards | 16:44 | |
| -!- Jeremy_Rand [~jeremy@172.56.7.164] has joined #bitcoin-wizards | 16:45 | |
| -!- 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:48 | |
| -!- 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:51 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards | 16:54 | |
| -!- 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] | 16:58 | |
| -!- 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:06 | |
| -!- GGuyZ [~GGuyZ@202.171.211.253] has joined #bitcoin-wizards | 17:08 | |
| -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-wizards | 17:11 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 17:14 | |
| -!- GGuyZ [~GGuyZ@202.171.211.253] has quit [Quit: GGuyZ] | 17:17 | |
| -!- 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:18 | |
| -!- 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:25 | |
| -!- CubicEar_ [~cubiceart@50.141.32.138] has quit [Remote host closed the connection] | 17:31 | |
| -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards | 17:32 | |
| -!- memymo [~textual@202.171.211.253] has quit [Client Quit] | 17:36 | |
| -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards | 17:36 | |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 17:38 | |
| -!- 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:40 | |
| -!- 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:41 | |
| -!- memymo [~textual@202.171.211.253] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 17:44 | |
| -!- 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:45 | |
| -!- memymo [~textual@202.171.211.253] has joined #bitcoin-wizards | 17:48 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards | 17:51 | |
| 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:52 | |
| 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:53 |
| 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:54 |
| phantomcircuit | and would be a hardfork (unless they were simply null in which case why are you doing it) | 17:55 |
| 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:57 |
| jl2012 | a carefully written hardfork could be compatiable with existing ASIC and even SPV nodes | 17:58 |
| 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:00 |
| 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:01 |
| jl2012 | phantomcircuit: just a different way to serialize the field and calculate the hash. I'll describe it in more details | 18:02 |
| 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:03 |
| jl2012 | phantomcircuit: as ASIC becomes faster, it may become a real problem. Too much overhead between the ASIC and the computer | 18:04 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 18:05 | |
| 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:06 |
| jl2012 | how about the communication overhead between the FPGA and ASIC? | 18:07 |
| Lightsword | I think most bitmain gear also uses an fpga | 18:07 |
| 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:09 |
| 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:10 |
| phantomcircuit | Lightsword, well yes the easiest way to implement the cpu<->asic comms is to simply infinite loop polling for updates | 18:13 |
| Lightsword | phantomcircuit, I think they stick the FPGA in between mainly for io multiplexing or something like that | 18:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| Lightsword | would the soft fork break any miners that do work generation in the ASIC?? | 18:20 |
| phantomcircuit | Lightsword, which one? | 18:20 |
| 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:21 |
| phantomcircuit | Lightsword, no i mean which soft fork | 18:22 |
| 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:23 |
| -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 18:29 | |
| 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:31 |
| -!- bendavenport [~bpd@96.90.231.161] has quit [Quit: bendavenport] | 18:33 | |
| 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:35 |
| -!- 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:36 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] | 18:37 | |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 | |
| 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:42 |
| 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:43 |
| 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:44 |
| -!- 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:45 |
| 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:46 |
| morcos | sipa: is there a reason not to count actual signatures verified, instead of just the number before the check_multisig | 18:47 |
| -!- 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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: <impressed swearing> | 18:56 |
| sipa | in exactly the same softfork way | 18:56 |
| 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:57 |
| 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:58 |
| 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 | 18:59 |
| aj | maaku: huh. and i guess CT makes it impossible to check for dust anyway | 19:00 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| 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:09 |
| -!- 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:10 |
| 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:11 |
| 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:12 |
| sipa | if this factor grows unboundedly, you are making one part of the system effectively free to use compared to the rest | 19:13 |
| 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:15 |
| -!- 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:16 | |
| 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:17 |
| -!- 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:18 |
| -!- 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:19 |
| -!- 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:20 | |
| 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:21 |
| 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:22 | |
| -!- adam3us [~Adium@m121-202-137-111.smartone.com] has joined #bitcoin-wizards | 19:23 | |
| 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:24 | |
| 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:26 |
| -!- 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:27 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards | 19:33 | |
| -!- p15 [~p15@47.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 272 seconds] | 19:35 | |
| -!- pandabearit [~pandabear@rrcs-24-103-136-238.nys.biz.rr.com] has joined #bitcoin-wizards | 19:36 | |
| -!- p15 [~p15@14.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards | 19:37 | |
| -!- p15 [~p15@14.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 250 seconds] | 19:48 | |
| -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has quit [Ping timeout: 252 seconds] | 19:49 | |
| -!- mrkent_ [~textual@unaffiliated/mrkent] has quit [] | 19:54 | |
| -!- pandabearit [~pandabear@rrcs-24-103-136-238.nys.biz.rr.com] has quit [Ping timeout: 250 seconds] | 19:59 | |
| -!- 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:02 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] | 20:05 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards | 20:09 | |
| -!- adam3us [~Adium@m121-202-137-111.smartone.com] has quit [Quit: Leaving.] | 20:14 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds] | 20:18 | |
| -!- CubicEarth [~cubiceart@50.141.34.246] has quit [Remote host closed the connection] | 20:24 | |
| -!- CubicEarth [~cubiceart@50.141.34.246] has joined #bitcoin-wizards | 20:25 | |
| -!- wallet42 [~wallet42@pcd535135.netvigator.com] has joined #bitcoin-wizards | 20:29 | |
| -!- 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:31 | |
| 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:32 |
| 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:40 | |
| -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-wizards | 20:41 | |
| jl2012 | my impression yesterday was many people liked this. I was not aware of any strong objection | 20:46 |
| 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. | 20:50 |
| -!- 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:02 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 21:07 | |
| -!- wallet42 [~wallet42@pcd535135.netvigator.com] has quit [Quit: Leaving.] | 21:07 | |
| -!- 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:11 | |
| -!- 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:17 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards | 21:23 | |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-wizards | 21:29 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [] | 21:32 | |
| -!- pozitrono [~nu@94.102.63.16] has joined #bitcoin-wizards | 21:34 | |
| 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:38 |
| jl2012 | my point is the backdoor size is not a problem of sigwit per se | 21:39 |
| gmaxwell | Agreed. okay thats true. | 21:39 |
| jl2012 | for the backdoor size, it could be 100, 101, 103, 248, flexcap. still open to debate | 21:41 |
| -!- 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:45 |
| gmaxwell | so the ratio between the blocksize and witness size limits is a segwit specific question. | 21:46 |
| jl2012 | We could still use an overall limit. Say BIP102, then total block size including witness is 2MB | 21:48 |
| jl2012 | instead, we may specify the backdoor limit is 2MB | 21:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| -!- 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 | 21:57 | |
| 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:02 |
| 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:03 |
| -!- nivah [~linker@115.79.55.177] has joined #bitcoin-wizards | 22:04 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 22:04 | |
| -!- wallet42 [~wallet42@202.83.241.187] has joined #bitcoin-wizards | 22:05 | |
| 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:06 |
| gmaxwell | CubicEarth: yes, though less than many assume. | 22:07 |
| tulip | CubicEarth: 10.5 transactions though, what's a "typical" transaction? | 22:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| gmaxwell | jl2012: when checksig is updated verification costs for many signatures at a time will be halved again from when they are now. | 22:16 |
| 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:17 |
| 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:18 |
| gmaxwell | tulip: haha | 22:19 |
| jl2012 | ttyl | 22:19 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 22:19 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] | 22:22 | |
| 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:23 |
| 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:24 |
| CubicEarth | 500 bytes | 22:25 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds] | 22:25 | |
| CubicEarth | And 802.11 G is not actually 54 Mbps.... | 22:26 |
| 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:27 | |
| -!- Erik_dc [~erik@d54C620ED.access.telenet.be] has joined #bitcoin-wizards | 22:28 | |
| 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:29 | |
| tulip | lets work from the other way. | 22:32 |
| CubicEarth | let | 22:33 |
| tulip | 6MB/hour is 1.6KB/s. so there's no way we can make this work. | 22:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 | |
| 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:45 |
| 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:46 |
| 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:48 |
| -!- 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:50 |
| 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:51 | |
| -!- 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:52 |
| -!- 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:57 | |
| -!- CubicEarth [~cubiceart@50.141.34.246] has joined #bitcoin-wizards | 22:58 | |
| CubicEarth | tulip: what do you suggest as a metric that would be more helpful than TPS? | 23:00 |
| -!- Erik_dc [~erik@d54C620ED.access.telenet.be] has quit [Remote host closed the connection] | 23:02 | |
| maaku | '<sipa> 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:03 |
| -!- 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:04 | |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:11 | |
| 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:12 |
| 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:13 |
| 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:14 | |
| -!- 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:16 |
| maaku | in particular ZKP of zerocash require significant computaitonal power to create. you couldn't practically have lightning network with zerocash payment channels | 23:17 |
| 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:18 |
| gmaxwell | maaku: I'd given little/no thought to CT channels; it's an interesting thought. | 23:19 |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has joined #bitcoin-wizards | 23:20 | |
| 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:21 |
| maaku | but maybe with combination of onion routing and zero-knowledge path finding it could do even better | 23:22 |
| amiller | im trying to figure out snark + channels | 23:23 |
| -!- 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:24 |
| 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:25 |
| -!- 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:29 |
| amiller | you wouldn't make a snark proof each time you make an incremental payment | 23:30 |
| -!- markus-k [~markus-k@designnet.work.de] has joined #bitcoin-wizards | 23:33 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 23:34 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 23:35 | |
| -!- p15 [~p15@11.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 256 seconds] | 23:42 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] | 23:44 | |
| -!- JackH [~Jack@host-80-43-143-143.as13285.net] has joined #bitcoin-wizards | 23:49 | |
| -!- CubicEarth [~cubiceart@50.141.34.241] has joined #bitcoin-wizards | 23:50 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 23:51 | |
| -!- taek42- [~david@202.83.241.187] has quit [Quit: Leaving] | 23:54 | |
| -!- GAit [~GAit@m121-202-137-194.smartone.com] has quit [Quit: Leaving.] | 23:55 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 240 seconds] | 23:57 | |
| -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Ping timeout: 256 seconds] | 23:58 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 23:59 | |
| --- Log closed Tue Dec 08 00:00:31 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!
