| --- Log opened Mon Nov 09 00:00:20 2015 | ||
| -!- digitalmagus [~digitalma@unaffiliated/digitalmagus] has quit [Ping timeout: 255 seconds] | 00:04 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 00:07 | |
| -!- kyuupichan [~Neil@ae053102.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards | 00:11 | |
| -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 00:12 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 00:19 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 00:23 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 00:26 | |
| -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds] | 00:27 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds] | 00:31 | |
| -!- JackH [~Jack@host-80-43-141-3.as13285.net] has joined #bitcoin-wizards | 00:34 | |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [Remote host closed the connection] | 00:40 | |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-wizards | 00:40 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 01:06 | |
| -!- c0rw1n [~c0rw1n@108.193-241-81.adsl-dyn.isp.belgacom.be] has quit [] | 01:11 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 01:13 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving] | 01:17 | |
| -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 01:25 | |
| -!- c0rw1n [~c0rw1n@108.193-241-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 01:28 | |
| -!- nivah [~linker@115.79.55.177] has joined #bitcoin-wizards | 01:33 | |
| -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds] | 01:45 | |
| -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 01:58 | |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [Remote host closed the connection] | 02:03 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] | 02:05 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] | 02:07 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 02:09 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 272 seconds] | 02:12 | |
| -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards | 02:13 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 02:13 | |
| -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 02:24 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 02:25 | |
| -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] | 02:25 | |
| -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has joined #bitcoin-wizards | 03:41 | |
| -!- 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 | 03:41 | |
| -!- Topic set by sipa [~pw@unaffiliated/sipa1024] [Thu Oct 29 17:53:34 2015] | 03:41 | |
| [Users #bitcoin-wizards] | 03:41 | |
| [@ChanServ ] [ catlasshrugged ] [ gnusha ] [ kaptah ] [ neha ] [ sparetire ] | 03:41 | |
| [ [7] ] [ cfields ] [ go1111111 ] [ katu ] [ nephyrin ] [ sparetire_ ] | 03:41 | |
| [ [ace]_ ] [ chmod755 ] [ Graet ] [ Keefe ] [ nickler ] [ spinza ] | 03:41 | |
| [ [d__d] ] [ cluckj ] [ grandmaster ] [ keus ] [ nivah ] [ Starduster ] | 03:41 | |
| [ [Derek] ] [ CodeArtix ] [ grantsmith ] [ kinlo ] [ nsh ] [ starsoccer ] | 03:41 | |
| [ _alp_ ] [ CodeShark ] [ GreenIsMyPepper_] [ kisspunch ] [ null_radix ] [ stevenroose ] | 03:41 | |
| [ _whitelogger ] [ CoinMuncher ] [ gribble ] [ koshii ] [ OneFixt ] [ stonecoldpat] | 03:41 | |
| [ a5m0 ] [ comboy ] [ grubles ] [ Krellan ] [ optimator ] [ STRML ] | 03:41 | |
| [ AaronvanW ] [ copumpkin ] [ Guest1235 ] [ kumavis ] [ otoburb ] [ SwedFTP ] | 03:41 | |
| [ adam3us ] [ Cory ] [ Guest91590 ] [ kyuupichan ] [ OxADADA ] [ Taek ] | 03:41 | |
| [ adams__ ] [ coryfields ] [ guruvan ] [ larraboj ] [ p15 ] [ TBI_ ] | 03:41 | |
| [ adlai ] [ crescendo ] [ gwillen ] [ lclc ] [ paci ] [ TD-Linux ] | 03:41 | |
| [ AdrianG ] [ cryptowest ] [ harding ] [ lecusemble ] [ PaulCapestany ] [ Tenhi ] | 03:41 | |
| [ aem ] [ d9b4bef9 ] [ harrow` ] [ LeMiner ] [ paveljanik ] [ ThomasV ] | 03:41 | |
| [ afdudley ] [ damethos ] [ hashtag_ ] [ lmatteis ] [ penjenayah ] [ thrasher` ] | 03:41 | |
| [ aj ] [ dansmith_btc ] [ heath ] [ lnovy ] [ petertodd ] [ Tiraspol ] | 03:41 | |
| [ Alanius ] [ davec ] [ helo ] [ Logicwax ] [ phantomcircuit ] [ tripleslash ] | 03:41 | |
| [ alexkuck ] [ davout ] [ hsmiths ] [ lomax_ ] [ Piper-Off ] [ tromp ] | 03:41 | |
| [ amiller_ ] [ dEBRUYNE_ ] [ humd1ng3r ] [ Londe2 ] [ poggy_ ] [ tromp_ ] | 03:41 | |
| [ Anduck ] [ dEBRUYNE__ ] [ huseby ] [ Luke-Jr ] [ PRab ] [ ttttemp_ ] | 03:41 | |
| [ andytoshi ] [ derpderp_ ] [ ibrightly ] [ luny ] [ prosodyvVerreabC] [ tucenaber ] | 03:41 | |
| [ apep ] [ devrandom ] [ iddo ] [ maaku ] [ PsychoticBoy ] [ uniken510 ] | 03:41 | |
| [ Apocalyptic ] [ dgenr8 ] [ indolering ] [ Madars ] [ publius1788 ] [ vonzipper ] | 03:41 | |
| [ arowser ] [ dignork ] [ instagibbs ] [ MagikSquirrel] [ Pugg ] [ warptangent ] | 03:41 | |
| [ artifexd ] [ Doge_Funnie ] [ Iriez ] [ malte- ] [ qawap ] [ warren ] | 03:41 | |
| [ arubi ] [ ebfull ] [ isis ] [ mappum ] [ rasengan ] [ waxwing ] | 03:41 | |
| [ azariah ] [ Eliel_ ] [ Jaamg ] [ mariorz ] [ rht___ ] [ weex ] | 03:41 | |
| [ badmofo ] [ Emcy ] [ JackH ] [ matsjj ] [ roasbeef ] [ wilbns ] | 03:41 | |
| [ BananaLotus ] [ ens ] [ jaromil ] [ Meeh ] [ robmyers ] [ wizkid057 ] | 03:41 | |
| [ bassguitarman ] [ epscy ] [ jbenet ] [ melvster ] [ roxtrongo ] [ wpalczynski ] | 03:41 | |
| [ berndj ] [ eric ] [ jcorgan ] [ merlincorey ] [ rubensayshi ] [ wumpus ] | 03:41 | |
| [ bildramer ] [ espes ] [ jeremias ] [ metamarc ] [ runeks ] [ xeon-enouf ] | 03:41 | |
| [ binaryFateCloud] [ execute ] [ Jeremy_Rand ] [ midnightmagic] [ rusty ] [ Xzibit17 ] | 03:41 | |
| [ bliljerk101 ] [ face ] [ jeremyrubin ] [ mikolalysenko] [ rustyn ] [ yang ] | 03:41 | |
| [ BlueMatt ] [ Fistful_of_Coins] [ jessepollak ] [ mjerr ] [ ryan-c ] [ Ylbam ] | 03:41 | |
| [ bobke ] [ fkhan ] [ jlrubin_ ] [ mkarrer ] [ s1w ] [ yoleaux ] | 03:41 | |
| [ BrainOverfl0w ] [ fluffypony ] [ jlyndon ] [ mm_1 ] [ sdaftuar ] [ yorick ] | 03:41 | |
| [ brand0 ] [ forrestv ] [ joesmoe ] [ morcos ] [ seg ] [ zmachine ] | 03:41 | |
| [ bsm117532 ] [ GAit ] [ jojva ] [ mountaingoat ] [ SheffieldCrypto ] [ zmanian_ ] | 03:41 | |
| [ bsm1175321 ] [ gavinandresen ] [ jonasschnelli ] [ mr_burdell ] [ shesek ] [ zxzzt ] | 03:41 | |
| [ btcdrak ] [ ggreer ] [ jouke ] [ MRL-Relay ] [ sipa ] | 03:41 | |
| [ Burrito ] [ ghtdak ] [ jrayhawk ] [ Myagui ] [ smk ] | 03:41 | |
| [ c-cex-yuriy ] [ gielbier ] [ justanotheruser ] [ nabu ] [ smooth ] | 03:41 | |
| [ c0rw1n ] [ gill3s ] [ K1773R ] [ nanotube ] [ sneak_ ] | 03:41 | |
| [ catcow ] [ gmaxwell ] [ kanzure ] [ nba_btchip ] [ so ] | 03:41 | |
| -!- Irssi: #bitcoin-wizards: Total of 265 nicks [1 ops, 0 halfops, 0 voices, 264 normal] | 03:41 | |
| -!- Channel #bitcoin-wizards created Mon Feb 25 23:24:47 2013 | 03:41 | |
| -!- Irssi: Join to #bitcoin-wizards was synced in 14 secs | 03:41 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 03:43 | |
| -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 03:44 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] | 03:44 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 03:44 | |
| -!- kyuupichan [~Neil@ae053102.dynamic.ppp.asahi-net.or.jp] has quit [Read error: Connection reset by peer] | 03:45 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 244 seconds] | 03:45 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] | 03:48 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 03:50 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] | 03:51 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 03:52 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] | 03:53 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] | 03:55 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 04:02 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] | 04:05 | |
| -!- kyuupichan [~Neil@ae053102.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards | 04:07 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] | 04:13 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 04:20 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.] | 04:22 | |
| -!- pozitron [~nu@94.242.243.250] has joined #bitcoin-wizards | 04:22 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 04:27 | |
| -!- eudoxia [~eudoxia@r167-57-115-19.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 04:46 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards | 04:51 | |
| -!- dfdfdfdfd [4f6807bc@gateway/web/freenode/ip.79.104.7.188] has joined #bitcoin-wizards | 04:53 | |
| -!- dfdfdfdfd [4f6807bc@gateway/web/freenode/ip.79.104.7.188] has quit [Client Quit] | 04:53 | |
| -!- rht___ [uid86914@gateway/web/irccloud.com/x-zmifygqekouhxqal] has quit [Quit: Connection closed for inactivity] | 04:58 | |
| -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has quit [Ping timeout: 240 seconds] | 04:59 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Remote host closed the connection] | 05:03 | |
| -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 05:13 | |
| -!- rustyn [~rustyn@unaffiliated/rustyn] has quit [] | 05:13 | |
| -!- Giszmo [~leo@pc-36-133-241-201.cm.vtr.net] has joined #bitcoin-wizards | 05:22 | |
| -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has quit [Ping timeout: 265 seconds] | 05:33 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Remote host closed the connection] | 05:45 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 05:49 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 05:53 | |
| -!- p15 [~p15@93.186.169.213] has quit [Ping timeout: 265 seconds] | 05:55 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] | 05:58 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 06:00 | |
| -!- bit2017 [~linker@115.79.55.177] has joined #bitcoin-wizards | 06:02 | |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards | 06:02 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards | 06:03 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.] | 06:05 | |
| -!- nivah [~linker@115.79.55.177] has quit [Ping timeout: 264 seconds] | 06:05 | |
| -!- Guest91590 [~pigeons@94.242.209.214] has quit [Ping timeout: 255 seconds] | 06:07 | |
| -!- bit2017 [~linker@115.79.55.177] has quit [Ping timeout: 250 seconds] | 06:07 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards | 06:08 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Ping timeout: 244 seconds] | 06:08 | |
| -!- pozitron [~nu@94.242.243.250] has quit [Ping timeout: 264 seconds] | 06:09 | |
| -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-wizards | 06:13 | |
| -!- pigeons is now known as Guest51134 | 06:13 | |
| -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:cd2b:fb11:150b:fff3] has joined #bitcoin-wizards | 06:32 | |
| -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:cd2b:fb11:150b:fff3] has quit [Read error: Connection reset by peer] | 06:38 | |
| -!- ratbanebo [~ratbanebo@78-23-10-185.access.telenet.be] has joined #bitcoin-wizards | 06:39 | |
| -!- atgreen [~green@38.104.156.250] has joined #bitcoin-wizards | 06:40 | |
| -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 272 seconds] | 06:45 | |
| -!- Meeh [~meeeeeeh@meeh.sigterm.no] has quit [Ping timeout: 260 seconds] | 06:49 | |
| -!- Meeh [~meeeeeeh@meeh.sigterm.no] has joined #bitcoin-wizards | 06:51 | |
| -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards | 06:53 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 06:55 | |
| -!- waxwing [~waxwing@62.205.214.125] has quit [Read error: Connection reset by peer] | 06:57 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 06:57 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] | 06:59 | |
| -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-wizards | 07:01 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.] | 07:06 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 07:08 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards | 07:10 | |
| -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds] | 07:14 | |
| -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Ping timeout: 240 seconds] | 07:14 | |
| amiller_ | whooo, asynchronous BFT experiments | 07:14 |
|---|---|---|
| amiller_ | im running BFT experiments across 64 ec2 nodes in eight regions, with maximum fault tolerance n=3f+1.... and achieving thousands of transactions committed per second | 07:18 |
| -!- eudoxia [~eudoxia@r167-57-115-19.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 07:18 | |
| nsh | BFT? | 07:18 |
| -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards | 07:19 | |
| nsh | oh, byzantine fault tolerance | 07:20 |
| -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards | 07:21 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 07:23 | |
| -!- foobar_ [41ce5f92@gateway/web/freenode/ip.65.206.95.146] has joined #bitcoin-wizards | 07:27 | |
| -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds] | 07:28 | |
| -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards | 07:29 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards | 07:35 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Ping timeout: 240 seconds] | 07:39 | |
| -!- kyuupichan [~Neil@ae053102.dynamic.ppp.asahi-net.or.jp] has quit [Read error: Connection reset by peer] | 07:48 | |
| -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] | 07:51 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards | 07:52 | |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection] | 07:56 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 07:56 | |
| -!- nwilcox [~nwilcox@74-95-207-205-SFBA.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 07:57 | |
| -!- foobar_ [41ce5f92@gateway/web/freenode/ip.65.206.95.146] has quit [Ping timeout: 246 seconds] | 07:59 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 07:59 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds] | 08:01 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] | 08:07 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 08:10 | |
| -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 08:14 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards | 08:14 | |
| -!- MoALTz [~no@78-11-179-104.static.ip.netia.com.pl] has joined #bitcoin-wizards | 08:19 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 08:33 | |
| -!- StephenM347 [~stephenm3@static-64-223-246-218.port.east.myfairpoint.net] has joined #bitcoin-wizards | 08:38 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.] | 08:41 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards | 08:43 | |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards | 08:51 | |
| -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.] | 08:54 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] | 08:58 | |
| -!- hazirafel [~hazirafel@space.telavivmakers.org] has joined #bitcoin-wizards | 09:00 | |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 09:09 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Remote host closed the connection] | 09:18 | |
| -!- zooko [~user@72.42.70.227] has joined #bitcoin-wizards | 09:48 | |
| -!- kyuupichan [~Neil@ae053102.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards | 09:48 | |
| -!- jgarzik [~jgarzik@172.85.35.242] has joined #bitcoin-wizards | 09:48 | |
| -!- jgarzik [~jgarzik@172.85.35.242] has quit [Changing host] | 09:48 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 09:48 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 09:50 | |
| -!- bobke [~bobke@94-226-145-186.access.telenet.be] has quit [Remote host closed the connection] | 09:52 | |
| -!- nwilcox [~nwilcox@74-95-207-205-SFBA.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] | 09:54 | |
| -!- bobke [~bobke@94-226-145-186.access.telenet.be] has joined #bitcoin-wizards | 09:56 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 09:57 | |
| -!- spinza [~spin@197.89.46.41] has quit [Excess Flood] | 10:00 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] | 10:02 | |
| -!- hazirafel [~hazirafel@space.telavivmakers.org] has quit [Ping timeout: 264 seconds] | 10:02 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 10:04 | |
| -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] | 10:06 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has joined #bitcoin-wizards | 10:06 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] | 10:07 | |
| -!- mjerr [~mjerr@p5B209AC3.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] | 10:09 | |
| -!- spinza [~spin@197.89.46.41] has joined #bitcoin-wizards | 10:09 | |
| -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection] | 10:11 | |
| kanzure | well at least they admit that you still have to wait for actual confirmations? http://hackingdistributed.com/2015/11/09/bitcoin-ng-followup/ | 10:11 |
| el33th4x0r | hi Brian | 10:13 |
| el33th4x0r | a merchant's transaction acceptance policy depends on their risk profile. this is true for any protocol, NG included. | 10:14 |
| el33th4x0r | but 1-confirmations in NG offer strictly stronger guarantees than 0-confs in Core, and come much faster than 1-confirmations in Core. | 10:14 |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards | 10:18 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] | 10:20 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 10:20 | |
| -!- zooko [~user@72.42.70.227] has quit [Read error: Connection reset by peer] | 10:21 | |
| -!- zooko [~user@72.42.70.227] has joined #bitcoin-wizards | 10:22 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Ping timeout: 255 seconds] | 10:23 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 10:25 | |
| -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Ping timeout: 240 seconds] | 10:45 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 10:48 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 244 seconds] | 10:51 | |
| -!- iddo [~idddo@csm.cs.technion.ac.il] has joined #bitcoin-wizards | 10:52 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 10:55 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] | 10:59 | |
| -!- zooko [~user@72.42.70.227] has quit [Ping timeout: 240 seconds] | 10:59 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 10:59 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 10:59 | |
| -!- matsjj [~matsjj@p20030089EA2EE217E8E5D131E784351E.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 11:00 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:02 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] | 11:03 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] | 11:04 | |
| -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has joined #bitcoin-wizards | 11:04 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:06 | |
| -!- atgreen [~green@38.104.156.250] has quit [Ping timeout: 250 seconds] | 11:07 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:08 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 276 seconds] | 11:10 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] | 11:11 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 244 seconds] | 11:12 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:12 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 244 seconds] | 11:15 | |
| -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Ping timeout: 240 seconds] | 11:17 | |
| -!- iddo [~idddo@csm.cs.technion.ac.il] has joined #bitcoin-wizards | 11:19 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:20 | |
| -!- Yoghur114 [~jorn@80.57.227.14] has joined #bitcoin-wizards | 11:22 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards | 11:23 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] | 11:24 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:25 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] | 11:28 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:30 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 11:31 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:31 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] | 11:33 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 11:33 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] | 11:34 | |
| -!- skyraider [uid41097@gateway/web/irccloud.com/x-vvtfgzrqhllfkbge] has joined #bitcoin-wizards | 11:37 | |
| -!- Doge_Funnie [~Doge_Funn@unaffiliated/doge-funnie/x-0003093] has quit [Quit: Leaving] | 11:40 | |
| -!- matsjj [~matsjj@p20030089EA2EE217E8E5D131E784351E.dip0.t-ipconnect.de] has quit [Remote host closed the connection] | 11:42 | |
| -!- jojva [~joris@cha92-12-88-162-171-45.fbx.proxad.net] has quit [Ping timeout: 255 seconds] | 11:50 | |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection] | 11:52 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 11:55 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] | 11:58 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 11:59 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] | 12:03 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] | 12:07 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 12:07 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] | 12:10 | |
| Taek | the idea is only half-baked at this point, but could you achieve similar goals to bitcoin-ng by using near-blocks instead of assigning a leader? | 12:11 |
| Taek | set a rule that transactions in a particular block must have been seen in near-blocks building off of one of the previous N blocks | 12:11 |
| gwillen | Taek: if you're talking about blocks that nearly have enough work, but not quite, people talk about that under the name "weak blocks" I believe | 12:12 |
| -!- zooko [~user@208.54.38.140] has joined #bitcoin-wizards | 12:12 | |
| Taek | I thought we settled on the term 'near blocks', I know there's been some back-and-forth on the term. I'm content with either, but though we chose 'near blocks' | 12:12 |
| gwillen | ahhh okay | 12:12 |
| Taek | *thought | 12:13 |
| gwillen | I have been wrong before :-) | 12:13 |
| gwillen | I've definitely heard these kinds of schemes talked about as an alternative to NG-like stuff though | 12:13 |
| gmaxwell | Taek: I am of the belief that block preforwarding and efficient transmission can give the same benefits, yes. Though I've not yet convinced myself it's precisely the same benefits. | 12:13 |
| -!- smk [9e557647@gateway/web/freenode/ip.158.85.118.71] has quit [Quit: Page closed] | 12:14 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 12:18 | |
| -!- tulip [~tulip@46.101.245.204] has joined #bitcoin-wizards | 12:18 | |
| Taek | a proposal with similar goals that I've not seen discussed here is the 'Helix blockchain' | 12:19 |
| Taek | https://bitcointalk.org/index.php?topic=1067534.0 | 12:19 |
| gavinandresen | I agree with gmaxwell. I’ve had a little back-and-forth email conversation with Ittay and Gun about weak blocks versus NG. | 12:19 |
| gavinandresen | Taek : re: helix: fragmenting a user’s wallet’s UTXOs into multiple pieces that can’t be spent all at once is a terrible, horrible, no-good idea. Extra complexity for illusory benefit. | 12:21 |
| Taek | gavinandresen: I believe a user would want to set up their wallet so that all utxos inside of it are on a single part of the helix | 12:22 |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 276 seconds] | 12:22 | |
| gavinandresen | Taek : fragmenting the user base is an even worse idea. | 12:22 |
| gavinandresen | “oh, you’re on helix.3 ? I use helix.2 ….” | 12:23 |
| Taek | it would need to fragment the user base. You can send an output from any helix segment to any helix segment, it's just that you can only spend from 1 at a time | 12:23 |
| Taek | You can send from helix2 to helix3, it's just that you can't send from helix1 AND helix2 to helix3 in the same txn | 12:23 |
| Taek | the major advantage is that miners can mine without needing to have validated the most recent block | 12:25 |
| gavinandresen | and if I’ve got a fully-validating wallet on helix.3 how do I know transactions from helix.2 are valid, unless I’m watching the chain? Might as well run with SPV security…. | 12:25 |
| Taek | you still have to validate the whole chain | 12:25 |
| Taek | the construction is to improve the orphan rate, which means bigger or more frequent blocks are possible | 12:26 |
| gavinandresen | weak/near blocks can give the same benefit | 12:26 |
| Taek | I haven't spent too much time looking at it, but I'm guessing that combining the two could produce a compounded benefit | 12:26 |
| Taek | (maybe not, haven't looked at it yet) | 12:26 |
| gavinandresen | e.g. miners announce a weak block along with a zero-POW “here’s the block I’ll build on top of that” | 12:27 |
| -!- jojva [~joris@cha92-12-88-162-171-45.fbx.proxad.net] has joined #bitcoin-wizards | 12:28 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 12:28 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 12:29 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 12:32 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 276 seconds] | 12:32 | |
| -!- zooko [~user@208.54.38.140] has quit [Ping timeout: 276 seconds] | 12:32 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 12:37 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 12:40 | |
| -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 240 seconds] | 12:40 | |
| -!- Jeremy_Rand [~jeremy@ip68-97-34-37.ok.ok.cox.net] has quit [Ping timeout: 272 seconds] | 12:41 | |
| -!- matsjj [~matsjj@p20030089EA2EE217E8E5D131E784351E.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 12:43 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 276 seconds] | 12:43 | |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] | 12:43 | |
| -!- matsjj [~matsjj@p20030089EA2EE217E8E5D131E784351E.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] | 12:47 | |
| -!- ratbaneb_ [~ratbanebo@78-23-10-185.access.telenet.be] has joined #bitcoin-wizards | 12:48 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: Textual IRC Client: www.textualapp.com] | 12:48 | |
| -!- Eliel_ is now known as Eliel | 12:49 | |
| -!- ratbanebo [~ratbanebo@78-23-10-185.access.telenet.be] has quit [Ping timeout: 255 seconds] | 12:50 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 12:55 | |
| bliljerk101 | https://forum.bitcoin.com/dev-tech-talk/unobtrusively-anonymizing-the-u-s-postal-service-with-smart-contracts-t2003.html#p6048 - I proposed a way to anonymously assimilate, decentralize, and manage inventory without trust and physical interaction using smart contracts. I think this could work. Thoughts? | 12:56 |
| -!- derpderp [~derpderp@c-174-61-236-141.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 12:58 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 12:59 | |
| -!- derpderp_ [~derpderp@c-174-61-236-141.hsd1.wa.comcast.net] has quit [Ping timeout: 272 seconds] | 13:01 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] | 13:07 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards | 13:07 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 13:08 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Remote host closed the connection] | 13:08 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards | 13:09 | |
| amiller_ | bliljerk101, i dunno, i think that post is full of fallacies (or at least unsatisfactorily resolved problems) that aren't that much different in the different scenarios (whether it's about inventory, postal service or whatever) | 13:10 |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards | 13:10 | |
| bliljerk101 | amiller_ could you elaborate? i'm happy to examine | 13:11 |
| amiller_ | the main one i'm picking at there is the idea that if both a buyer and seller both put in a bunch of collateral, | 13:11 |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] | 13:11 | |
| amiller_ | that it's now incentive compatible for both of them to be honest | 13:11 |
| amiller_ | i don't think that's the case because of coercion (there's some other better name for this scenario but i forget) | 13:11 |
| el33th4x0r | I can see how block preforwarding and efficient transmission are complementary to NG. For them to provide the same benefits, you need a lot more mechanism around them. | 13:11 |
| amiller_ | if the seller says "hey i'm absoluetly not sending you an item, and if you want any of your collateral back at all, you should just liie and say the transaction went ok" | 13:12 |
| -!- snthsnth [~snthsnth@206.110.20.18] has joined #bitcoin-wizards | 13:12 | |
| bliljerk101 | amiller_ collusion? what coercion? | 13:12 |
| amiller_ | then it's in the buyer's personal best interest to comply with the seller | 13:12 |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Read error: Connection reset by peer] | 13:12 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards | 13:13 | |
| bliljerk101 | amiller_ so in the case you propose, it would cost the sender money and the peer would gain the commission | 13:13 |
| gmaxwell | el33th4x0r: the primary benefit of NG is that none of the intensive work of verifying things happens at the time of the mastership race. | 13:13 |
| bliljerk101 | this would be enforced in the contact | 13:13 |
| bliljerk101 | contract* | 13:13 |
| bliljerk101 | so the incentive here seems correct to me. thoughts? | 13:14 |
| gmaxwell | el33th4x0r: the efficient transfer and perforward schemes have the same benefit, at least in the absense of adversarial authorship. | 13:14 |
| amiller_ | bliljerk101, my point with this example is that once the malicious seller has revealed that he's malicious and won't send the package, it's in the buyer's best interest to release their collateral anyway.. this is a bad outcome for the victim buyer | 13:15 |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 13:17 | |
| bliljerk101 | amiller_ correct me if i'm wrong, but i think you're confusing my algo with the marketplace itself. because there would not be a reason to even establish a DNIS chain if the seller was not going to send the package. there would be absolutely no point to that. the seller would lose commission for at least 1 peer, so he'd only be putting himself at additonal loss | 13:17 |
| bliljerk101 | the buying/selling isn't a part of my algo | 13:18 |
| bliljerk101 | my algo is the trustl-less transference of real world assets through a chain | 13:18 |
| el33th4x0r | gmaxwell: agreed on the main benefit. | 13:19 |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 13:20 | |
| el33th4x0r | gmaxwell: but for weak blocks to serve the same purpose, miners would have to agree prior to mining. and that seems difficult. esp without a punishment mechanism for misbehavior. | 13:20 |
| -!- zooko [~user@c-71-237-69-190.hsd1.co.comcast.net] has joined #bitcoin-wizards | 13:21 | |
| el33th4x0r | gmaxwell: so a fully worked out solution that gets close to the same benefits may or may not be possible. if possible, it might be very complicated. | 13:21 |
| el33th4x0r | gmaxwell: nevertheless, i'd be thrilled to see such a solution worked out. is this something you are planning to work on? | 13:21 |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 13:22 | |
| bliljerk101 | amiller_ also the buyer can't release any collateral. in the case that DNIS chain was used to transfer an asset that was purchased in a marketplace. only the seller would be able to release the last (i.e. recipient's) contract. and again, he'd be foolish to do this as he would lose all the collateral tied up in all previous peers' contracts' transactions | 13:23 |
| bsm1175321 | The NG guys didn't address my concerns that the current master is discoverable, and therefore DDoSable... :-( | 13:23 |
| gwillen | bsm1175321: what's the procedure for discovering the master's IP? Just watch blocks and see where they're coming from? | 13:24 |
| bliljerk101 | i realize this is intricate system (it's hard, even for me as the designer to have fast conversation about it), but i think that's all the more reason we should review it seriously. i really tried to design this carefully, taking into account every possible incentive i could conceive | 13:24 |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 13:24 | |
| bsm1175321 | gwillen: yes. | 13:24 |
| gwillen | that seems like it would also lead to possible DDoS against current mining pools, if that were a simple procedure to follow. | 13:25 |
| bsm1175321 | ex-post-facto block publication adds significant byzantine protection. | 13:25 |
| bsm1175321 | gwillen: It does, and it is. | 13:25 |
| gmaxwell | el33th4x0r: they do not have to agree prior to mining, in fact, thats where the efficient transmission comes in. | 13:25 |
| gmaxwell | el33th4x0r: I've been working on efficient transmission on and off for a long time. | 13:26 |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards | 13:26 | |
| gmaxwell | el33th4x0r: it's weird that you seem to regard something that requires _no_ changes in the bitcoin consensus rules as a long shot relative to bitcoin-ng! | 13:27 |
| el33th4x0r | gmaxwell: i know all about the efficient xansmission work, had a hand in initiating that discussion and pointing towards some of the early strategies | 13:27 |
| el33th4x0r | gmaxwell: so if there are multiple weak blocks, which ones can i as a merchant believe to look like the next block, given that i cannot know who will get the block? | 13:28 |
| gmaxwell | This has nothing to do with merchants. | 13:29 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] | 13:29 | |
| el33th4x0r | ok how would weak blocks work? is there a spec i should read? | 13:30 |
| -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 276 seconds] | 13:30 | |
| -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Ping timeout: 272 seconds] | 13:31 | |
| -!- zooko [~user@c-71-237-69-190.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds] | 13:32 | |
| -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Read error: Connection reset by peer] | 13:32 | |
| gmaxwell | el33th4x0r: There are posts but it is not complex. miners announce candidate blocks, using POW 'weak blocks' to rate limit the process. Efficient differential transmission (including referencing earlier weak blocks) is used, so the amount of data transfer is small. Blocks commit to two sets of transactions, one for use as a weak block, and a subset for use if it is an actual block. | 13:32 |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 13:32 | |
| gmaxwell | When an actual block is found, it is transmitted using a prior weak block (decided on a per hop basis, whatever shared context is most efficient) as a differential starting point. | 13:33 |
| el33th4x0r | ok, that's what i thought. do you think this can achieve xput comparable to ng? | 13:34 |
| gmaxwell | If blocks are selected to look like prior weak blocks, the amount sent at the latency critial time is just a constant (a weak block reference, nonce, etc.) | 13:34 |
| gmaxwell | I believe it can. | 13:34 |
| gmaxwell | It has some nice deployment benefits, including even blocks produced by non-participants benefit from it. (to the extent their blocks are similar to participant blocks) | 13:35 |
| gmaxwell | It does not get you 'soft confirmations' (beyond perhaps being able to monitor weak blocks 'true' transaction sets, to gauge hashpower support); but I think that benefit in bitcoin-ng is mostly an illusion because the fee spliting scheme is not incentive compatible. (it's in everyone's interest to pay fees 'out of band' to bypass the split) | 13:36 |
| bliljerk101 | amiller_ are you the guy from zero cash? | 13:38 |
| instagibbs | Thinking of it the other way, it's in everyone's own interest to stick just enough fees in the split to incentivize someone to build on top of the microblock. I have no idea how much that is. | 13:38 |
| el33th4x0r | how does one reconcile and keep track of the N different weak block announcements from N different miners? | 13:38 |
| gmaxwell | instagibbs: well the users would leave all fees out, and then the miner themselves would pay into that. | 13:38 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] | 13:39 | |
| instagibbs | I had that thought too. :) | 13:39 |
| instagibbs | but yeah, the fee sharing seems like "suggested donation" to me | 13:39 |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-wizards | 13:42 | |
| gmaxwell | el33th4x0r: one can keep track of many, as they're relatively cheap (just a list of indexes for member transactions)-- but they do not have to be globally consistent, because the reference point chan change from hop to hop. (though with some efficieny loss if the reference isn't the one the miner used). So for example, one can keep the nearest block so far, and the N nearest misses more than N s | 13:42 |
| gmaxwell | econds old from your perspective. | 13:42 |
| -!- mpmcsweeney [~mpmcsween@2601:192:4402:4d9e:c07c:7712:229d:162b] has joined #bitcoin-wizards | 13:43 | |
| gmaxwell | And you communicate to your peers which reference points you know, so they can use an acceptable one. | 13:43 |
| -!- mpmcsweeney [~mpmcsween@2601:192:4402:4d9e:c07c:7712:229d:162b] has quit [Client Quit] | 13:44 | |
| * gmaxwell steps out for a bit | 13:44 | |
| kanzure | oh some of this deprecates previous weak-block talk | 13:44 |
| -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards | 13:45 | |
| -!- Jeremy_Rand [~jeremy@172.56.15.98] has joined #bitcoin-wizards | 13:48 | |
| el33th4x0r | gmaxwell: so every miner must send an updated weak block for every new xaction that modifies their block. this would scale as T*M with the number of miners (M) and transactions (T). | 13:53 |
| el33th4x0r | gmaxwell: so the throughput benefit isn't comparable to NG. | 13:53 |
| el33th4x0r | gmaxwell: and if you're not suggesting trusting weak blocks in some way, they don't help with latency. | 13:54 |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: hotel-ward] | 13:58 | |
| -!- snthsnth [~snthsnth@206.110.20.18] has quit [Ping timeout: 252 seconds] | 14:00 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 14:01 | |
| -!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards | 14:05 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has joined #bitcoin-wizards | 14:06 | |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Quit: Leaving...] | 14:08 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 14:08 | |
| -!- malte- is now known as malte | 14:11 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 14:13 | |
| instagibbs | I am under the impression you'd set some diff thresshold and discriminate based on that. Not based on number of peers mining. So T will be there, but instead of M it's relative to that threshhold you pick. | 14:14 |
| -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has joined #bitcoin-wizards | 14:20 | |
| -!- Jeremy_Rand [~jeremy@172.56.15.98] has quit [Ping timeout: 250 seconds] | 14:22 | |
| -!- nabu [~nabu@179.43.174.162] has quit [Ping timeout: 260 seconds] | 14:22 | |
| gmaxwell | el33th4x0r: I disagree. There is no need for an updated week block for each additional transaction. New transactions can simply wait until the next block. | 14:26 |
| gmaxwell | el33th4x0r: I think two distinct benefits are being conflated. The improvement in network convergence and fairness, which I believe weak blocks plus efficient transmission provide. | 14:27 |
| -!- zooko [~user@70.96.9.174] has joined #bitcoin-wizards | 14:27 | |
| gmaxwell | And "soft confirmations", which bitcoin-ng claims to provide but I believe could not provide in practice, because the soft confirmation depends on the fee sharing scheme which is not incentive compatible and I believe would be bypassed in normal operation. | 14:28 |
| gmaxwell | (weak blocks could provide for a different kind of 'soft confirmation', e.g. letting people measure the share of hashrate that would immediately commit to their transaction) | 14:30 |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards | 14:31 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 14:32 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 14:32 | |
| -!- zooko` [~user@172.56.8.239] has joined #bitcoin-wizards | 14:35 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] | 14:36 | |
| -!- zooko [~user@70.96.9.174] has quit [Ping timeout: 260 seconds] | 14:37 | |
| -!- StephenM347 [~stephenm3@static-64-223-246-218.port.east.myfairpoint.net] has quit [] | 14:38 | |
| el33th4x0r | gmaxwell: i see. you're suggesting a 2x increase in xaction latency. 20 min for 1 conf. | 14:40 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 14:40 | |
| el33th4x0r | gmaxwell: on the fee sharing scheme,there's a lot of misunderstanding -- NG does not depend on that particular fee splitting for correctness. Described here: http://hackingdistributed.com/2015/11/09/bitcoin-ng-followup/ | 14:41 |
| el33th4x0r | gmaxwell: the soft confirmation from weak blocks is better than nothing but not as strong as NG. | 14:42 |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] | 14:42 | |
| -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 250 seconds] | 14:42 | |
| -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-wizards | 14:43 | |
| -!- zooko` is now known as zooko | 14:43 | |
| bramc | What are 'weak' blocks? | 14:45 |
| gmaxwell | el33th4x0r: I'll read! I realize the fee sharing is not fundimental, but I think it is strictly necessary for the weak confirmation to have force. E.g. you mine a weak block and then you can produce an unbounded amount of fradulent single confirmations during that window, and later too if you have a partitioned victim. | 14:45 |
| gmaxwell | e.g. it was the threat of losing the fees if you got caught that prevents you from signing multple blocks but if there are no 'fees' visible to the system, that threat does not exist. | 14:46 |
| gmaxwell | (at least not in the long term with zero subsidy) | 14:46 |
| bramc | My guess as to what weak blocks are is that they're blocks which almost but not quite passed muster to form a new block, so they're deemed worthy of propagating and a real successful new block can shorthand what transactions it's accepting by referring to a chain of weak blocks to reduce propagation latency | 14:47 |
| gmaxwell | bramc: yes. | 14:47 |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 14:47 | |
| bramc | Sounds like a decent idea but doesn't change anything fundamental | 14:48 |
| gmaxwell | bramc: in particular, start with the observation that if you have a consensus system in advance of mining, you can reduce mining latency to nothing, and so fairness impacts from latency go away. Then (maybe) observe that consensus is actually stronger than you need for that effect. | 14:48 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 14:48 | |
| gmaxwell | bramc: I think it renders orphan rate largely independant from transaction load, which is pretty substantial. | 14:49 |
| bramc | gmaxwell, Sort of depends on how weak you let the weak blocks be | 14:49 |
| el33th4x0r | gmaxwell: you lose the block subsidy as well as the fees. | 14:49 |
| -!- nanashi [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has joined #bitcoin-wizards | 14:49 | |
| gmaxwell | you can adapt what you'll accept based on how many you are seeing. | 14:49 |
| bramc | Also, do you propagate all weak blocks or only the longest chain? | 14:50 |
| gmaxwell | el33th4x0r: if you are assuming subsidy, then you are assuming an inflationary currency-- as bitcoin subsidy is only temporary. | 14:50 |
| el33th4x0r | gmaxwell: the premise that there will be no fees is flawed here, or at least, "remains to be shown" | 14:50 |
| bramc | If you have utxo commitments you probably want the rule that they don't have to be validated for weak blocks, otherwise that's a lot of computation for a whole lot of nothing. | 14:50 |
| gmaxwell | el33th4x0r: in the ng scheme as I understand it a miner should _always_ accept a lower fee from a transaction that bypasses the fee system and pays them directly, because they get 100% of it. So users should always be willing to pay fees that way (and get half off on their fees). | 14:51 |
| gwillen | gmaxwell: that's only true if users value cheaper transactions over earlier weak confirmations | 14:52 |
| gmaxwell | (I'm not arguing that there won't be fees; I'm arguing that no rational party would participate in the 'official' fee scheme in bitcoin-ng, that instead they'd pay fees via additional outputs; and we've already had miners in bitcoin that accept fees that way in hte past) | 14:52 |
| el33th4x0r | gmaxwell: no. as a user, you can always partition the fee F any which way you like, including 100 to 0, for the two miners surrounding the microblock. But 100-0 would be a bad idea, as it undermines the incentive to build on top. | 14:52 |
| bramc | Come to think of it, weak blocks can be built into the peer protocol without touching the blockchain format at all | 14:52 |
| el33th4x0r | gmaxwell: so a user would be hurting himself by going that route. | 14:52 |
| gwillen | I think you have to make an argument about some kind of attackers doing that, not ordinary users -- their incentive to pay directly comes from wanting to get the earlier confirms from the microblocks | 14:52 |
| bramc | It's just a form of compression of a block: "This block is that other weak block plus this delta" | 14:53 |
| gmaxwell | el33th4x0r: Why would a user not pay 100%/0%, and leave it to the miner to decide to pay some fees forward? | 14:53 |
| gmaxwell | gwillen: not earlier, but stronger weak confirmation, no? I would accept that argument. | 14:54 |
| el33th4x0r | bramc: in a truly decentralized world where there are N miners, where N is large, there are N weak blocks. Not the most bandwidth efficient idea. | 14:54 |
| el33th4x0r | gmaxwell: they would not, that's my point. | 14:54 |
| gwillen | gmaxwell: well if the payor bypasses the fee split and pays directly to the miner who's working on the next keyblock, then there's no incentive for them to get any weak confirmation | 14:54 |
| gwillen | the current keyblock holder will have no reason to mine them at all | 14:55 |
| gmaxwell | el33th4x0r: There do not need to be N weak blocks, and the bandwidth costs of the weak blocks are only proportional to the difference between state. | 14:55 |
| bramc | el33th4x0r, No the number of weak blocks is stochastic and a multiplier of the number of strong blocks depending on where you set your threshold | 14:56 |
| nanashi | interesting to the testnet3 flip over to BIP101 | 14:57 |
| bramc | As long as the number of weak blocks is substantially smaller than the number of transactions accepted the overhead of them is no big deal | 14:57 |
| nanashi | any idea what will happen next? is this good or bad? | 14:57 |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:58 | |
| el33th4x0r | bramc, "number of strong blocks"? | 14:58 |
| bramc | el33th4x0r, If you set the threshold for 'accepting' weak blocks at six bits less than the threshold for a new block being minted (a 'strong' block) then you'll have about 64 times as many weak blocks as strong blocks | 14:59 |
| el33th4x0r | for N outstanding transactions, and T transactions per block, there are N choose T possible weak blocks | 14:59 |
| el33th4x0r | bramc: thanks, indeed, weak blocks require such measures to deter spam. | 15:00 |
| el33th4x0r | here's another problem with weak blocks: smaller miners will not be able to mine them effectively, so they will be at a disadvantage when they discover a real block. | 15:01 |
| bramc | It's also a good sanity measure to only propagate the longest chain of weak blocks you've seen | 15:01 |
| bramc | How are smaller miners at a disadvantage for mining weak blocks effectively? | 15:02 |
| bramc | Weak blocks should help everyone by making latencies be reliably lower | 15:03 |
| el33th4x0r | when weak blocks require a PoW (which they would, to deter spam), small miners are likely to experience high variance when discovering a valid PoW. | 15:03 |
| nanashi | whats a weak block | 15:04 |
| gmaxwell | el33th4x0r: I'm not sure if you followed my earlier point that we've been talking about a system where the weak block commits to two transaction sets: one which is used if it is a weakblock, and another which is used if its is a block. This means that even if you have not produced a weak block, if your 'If I am a block set' matches a weak block then you get the perfect speedup, even though you d | 15:05 |
| gmaxwell | id not create it. | 15:05 |
| gwillen | gmaxwell: I missed the explanation of what you gain by separating the two transaction sets -- is there a quick summary? | 15:06 |
| gmaxwell | gwillen: you do not suffere a disavantage if you find a real block before a weak block which reflects your preferences exists. | 15:07 |
| gmaxwell | el33th4x0r: N choost T is not a useful model. As there is a logical selection criteria: highest fee-per-limit, so on average (and in the absense of adversarial behavior) the discrepencies will be small. | 15:07 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 15:08 | |
| el33th4x0r | gmaxwell: how do you protect the network from miners spamming weak-block-preferences. (and thx, btw, I hadn't quite caught on to prefs!) | 15:09 |
| -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Ping timeout: 276 seconds] | 15:10 | |
| el33th4x0r | gmaxwell: N choose T is indeed the number of possible weak blocks. one might prune them down, but that requires additional assumptions about which weak blocks are important. | 15:11 |
| el33th4x0r | gmaxwell: that is to say, i agree that you could argue that we would not encounter as many in practice, iff you make some assumptions. | 15:12 |
| -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has joined #bitcoin-wizards | 15:12 | |
| gmaxwell | el33th4x0r: the spamming is prevented via the same POW mechenism. (in theory you could use any other functional mechenism -- but using POW has the property of sharing influence there equal to the actual finding of blocks) | 15:14 |
| rusty | bramc: indeed, this is what I'm working on now for HK. Simulations seem to make it work quite well. | 15:14 |
| rusty | gmaxwell: I have been using a 20x ratio for weak block threshold (ie. 30 seconds avg) but a 16x extra boost for the first weak block seen. This helps in the "full blocks" case. | 15:16 |
| rusty | gmaxwell: of course, the "first weak block" heuristic is imperfect in a distributed system. | 15:17 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] | 15:17 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] | 15:19 | |
| bramc | rusty, I don't understand what you're saying about first weak block. Also, are you judging the quality of weak blocks by the length of their chain and only accepting the longest one? | 15:20 |
| gmaxwell | bramc: one _could_ use weak blocks to perform a pre-consensus; but I think it is not actually needed for the fairness benefits (though it may help soft confirmations) | 15:20 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] | 15:22 | |
| bsm1175321 | If weak blocks were allowed to contain the same transaction in different weak blocks, and have multiple parent weak blocks, then I think this proposal is identical to my proposal of using a DAG instead of linked list (/chain) | 15:24 |
| bramc | gmaxwell, What are the fairness benefits other than pre-consensus? | 15:27 |
| bramc | It looks like a great trick for consistently reducing latency, not sure what else it buys. | 15:27 |
| bsm1175321 | While the chain can be removed in favor of a DAG, there's an intermediate state required for Bitcoin where the DAG results are checkpointed back to the chain. | 15:27 |
| bramc | bsm117532 It's possible to use weak blocks without changing the blockchain format at all. You just 'compress' a block by saying 'apply this delta to that weak block' | 15:28 |
| -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:d971:6ff5:3ba6:24db] has joined #bitcoin-wizards | 15:28 | |
| -!- ratbaneb_ [~ratbanebo@78-23-10-185.access.telenet.be] has quit [Ping timeout: 240 seconds] | 15:29 | |
| bsm1175321 | bramc: true. However then you can have weak block orphans, no? | 15:29 |
| gmaxwell | bramc: the more latency there is in block transmission the less fair the bitcoin network is (larger miners get excess profits). When latency goes up with block size this is bad news for increased throughput. | 15:30 |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection] | 15:30 | |
| bramc | Yes you can have weak block orphans, but so what? In some sense they're all orphaned when a new real block comes out. | 15:30 |
| bramc | gmaxwell, Right. I don't understand what you mean about pre-consensus and fairness though. | 15:31 |
| gmaxwell | by preconsensus above I mean that a weak block scheme could be 'very strong' in the sense that later weakblocks and blocks are required to agree with prior weakblocks. And I was just saying that I don't believe a system this strong is actually needed to gain most of the fairness benefit. | 15:31 |
| bsm1175321 | bramc: I want to additionally divide the block reward among weak block publishers. | 15:31 |
| bsm1175321 | Doing that decreases miner centralization by making more frequent, smaller block rewards. | 15:32 |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 15:32 | |
| bramc | gmaxwell, The reason for only using the longest chain is to encourage everybody to use older weak blocks when making newer weak blocks, because that reduces latency. | 15:33 |
| bramc | I'm assuming that weak blocks are themselves a chain | 15:33 |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 15:33 | |
| bramc | bsm117532 That's a bit hard with the current blockchain. This other stuff we're talking about requires no blockchain changes whatsoever. | 15:33 |
| gmaxwell | bramc: right and what I'm pointing out is that I think that making a weak block chain ("pre consensus") is actually more than is needed. | 15:34 |
| bramc | gmaxwell, Yes more than is needed, but is there any downside to it? | 15:35 |
| bsm1175321 | Well people are honing in on the idea of having a smaller, faster layer between 10m bitcoin blocks. (e.g. Bitcoin-NG does the same thing) One has the opportunity to make this new layer be anything we want, why duplicate the blockchain with its problems (orphans, centralization) in that layer? | 15:35 |
| gmaxwell | complexity/overhead, perhaps. Unclear. | 15:35 |
| bramc | gmaxwell, I think it's if anything simpler, because weak blocks 'want' to be a chain, because regular blocks are expressed as a diff off a weak block, so why not make weak blocks be diffs off of weak blocks? | 15:37 |
| bramc | bsm117532 There are deep issues with getting the time until a transaction is 'safe' down, regardless of blockchain format. Even when it's really working, it's going to be like 3 minutes instead of 30 minutes, which is still problematic. Micropayment channels are a much better approach. | 15:38 |
| bsm1175321 | A faster layer doesn't mean a transaction is "safe" faster. Just that it gets transmitted faster. | 15:39 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 15:39 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 15:39 | |
| sipa | transactions are transmitted instantly if you're not using the blockchain as a communication mechanism, but just send it directly to the receiver | 15:39 |
| mrkent | gmaxwell: based on the above convo, it sounds like weak blocks take work to produce, but also benefits those who do not put work in. If this is true, what is the incentive to produce weak blocks? | 15:40 |
| gmaxwell | bramc: you would make weak blocks diffs of weak blocks for sure, but the observation I made is that how you transmit and what you commit to can be completely orthorgonal. | 15:40 |
| gmaxwell | E.g. you can make a weak block X and then differentially transmit it relative to X, or Y, or Z and do so all at once to different peers. | 15:40 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit] | 15:41 | |
| bramc | gmaxwell, Having peers use the longest weak chain maximizes the chances that they'll all be working off the same thing | 15:41 |
| bsm1175321 | gmaxwell: would X, Y, Z have independent proofs of work? | 15:41 |
| bramc | It has the same benefits as it does for the regular blockchain | 15:41 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 15:41 | |
| gmaxwell | bsm1175321: NO | 15:42 |
| -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 15:43 | |
| bsm1175321 | gmaxwell: then they share the same PoW but you're sending different sets of transactions to different peers? | 15:43 |
| gmaxwell | bsm1175321: again, the commitment and the transmission have no reason to be at all connected that I'm aware of. When you transmit something to a peer you should do so with the most efficient means available for doing so. | 15:43 |
| bramc | My guess for the best time between weak blocks is about 30 seconds, same as rusty's | 15:43 |
| bsm1175321 | I see. | 15:43 |
| gmaxwell | bsm1175321: no, its the same transactions, but you can use different basises for them. | 15:44 |
| bramc | Oh duh, when you're making a new block it doesn't have to explicitly reference a particular previous weak block, you can express any of them as diffs off any others. Took me a bit to realize that. | 15:44 |
| gmaxwell | Say you know peer Y knows weak block Z which happens to be exactly the same as Z2, so you'd use Z to Y as the reference for Z2. But peer Q does not know Z, it knows M and N and M is closer, so you use that. | 15:44 |
| gmaxwell | now sure, it's best if everyone is using a common thing to go off of, you get more efficiency; but it is not strictly required. | 15:45 |
| bsm1175321 | Now I'm confused. I thought the weak block *was* a delta (and that was it's point) and contained a PoW. But now you're saying you're going to transmit deltas relative to weak blocks and they don't require a new PoW? | 15:46 |
| bramc | You can also potentially do a diff off a combo of two weak blocks. Take block A, then everything in block B which is still allowed, then do this diff | 15:46 |
| gmaxwell | and it may be good to not strictly require it so that you punish different policies less. E.g. big miners are censoring some transaction, a small miner is not, you don't want to punish the small miner by requiring he work only be differentially referenced to the big miners, rather than other non-censoring miners and himself. | 15:46 |
| bramc | bsm117532 A weak block is a partial - it's a regular block which didn't make the PoW cut | 15:47 |
| sipa | bsm1175321: a weak block is an almost-valid block, it's not different from a real block (except not meeting the PoW)... but you can use the same differential transfer mechanism for them | 15:47 |
| bsm1175321 | Gotcha. | 15:47 |
| gmaxwell | bsm1175321: all weak blocks are commits to sets of transactions above and beyond the blockchain. And you use differential transmission to efficiently transmit weak blocks between peers (as normally the weak blocks are almost all the same) | 15:47 |
| bsm1175321 | And unfortunately that scheme isn't going to allow partial block rewards very easily. :-/ | 15:49 |
| bramc | Since transaction removals can be expressed with a very compressed bitfield, it should never be all that inefficient to transmit a bunch of weak blocks to a peer compared to transmitting just the biggest weak block to them. | 15:49 |
| bramc | bsm117532 Right, that's a different problem | 15:50 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 15:50 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 15:51 | |
| gmaxwell | In any case, there are hidden costs to worry about; it's not all puppies and unicorns. :) | 15:51 |
| bsm1175321 | This is an excellent opportunity to address it -- at the point we're adding a smaller faster mining-based communicatoin layer. | 15:51 |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 15:52 | |
| -!- nanashi [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has quit [Quit: Leaving] | 15:53 | |
| -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:d971:6ff5:3ba6:24db] has quit [Read error: Connection reset by peer] | 15:54 | |
| bsm1175321 | e.g. the block reward could be divided among the weak block publishers, weighted by the hash they generate relative to the difficulty. | 15:55 |
| sipa | how so? there is no strong consensus about weak blocks | 15:55 |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-svizuorjkqyjumop] has quit [Quit: Connection closed for inactivity] | 15:55 | |
| bramc | bsm117532 That makes orphaning be a serious issue and opens up the whole can of worms which the blockchain is designed to solve in the first place. | 15:55 |
| sipa | you can't prove that a weak block existed | 15:55 |
| -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:d971:6ff5:3ba6:24db] has joined #bitcoin-wizards | 15:55 | |
| sipa | exactly, if you do that, you could just as well turn the weak blocks into full ones | 15:56 |
| bsm1175321 | bramc: That's the reason to use a DAG and get rid of the orphaning issue. | 15:56 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 15:57 | |
| bsm1175321 | sipa: Good point. Not sure how to address that. | 15:57 |
| -!- archobserver [~archobser@unaffiliated/superobserver] has joined #bitcoin-wizards | 16:03 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 16:04 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 16:10 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 16:11 | |
| -!- zooko` [~user@70.96.9.174] has joined #bitcoin-wizards | 16:14 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 16:15 | |
| -!- zooko [~user@172.56.8.239] has quit [Ping timeout: 276 seconds] | 16:16 | |
| -!- zooko` is now known as zooko | 16:17 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 16:20 | |
| -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:d971:6ff5:3ba6:24db] has quit [Read error: Connection reset by peer] | 16:21 | |
| -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:d971:6ff5:3ba6:24db] has joined #bitcoin-wizards | 16:21 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 276 seconds] | 16:26 | |
| -!- Yoghur114 [~jorn@80.57.227.14] has quit [Remote host closed the connection] | 16:28 | |
| -!- zooko [~user@70.96.9.174] has quit [Read error: Connection reset by peer] | 16:28 | |
| -!- zooko` [~user@70.96.9.174] has joined #bitcoin-wizards | 16:29 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 276 seconds] | 16:30 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 16:31 | |
| -!- zooko` is now known as zokoo | 16:33 | |
| -!- zokoo is now known as zooko | 16:33 | |
| bramc | At the moment I'm considering making blocks have a size limit of 16k for encoding reasons. Sound reasonable? | 16:33 |
| bramc | A 'block' should be a bit less than the amount of stuff which gets retrieved from a single memory access | 16:33 |
| -!- Jeremy_Rand [~jeremy@172.56.7.208] has joined #bitcoin-wizards | 16:37 | |
| bramc | In addition to is_included() which returns a boolean I'm going to have get_proof() which returns a boolean and a proof | 16:40 |
| bramc | And standalone functions confirm_included(root, val, proof) and confirm_not_included(root, val, proof) | 16:41 |
| -!- ghostedcitizen [~dookieboo@hashbangs.com] has joined #bitcoin-wizards | 16:43 | |
| ghostedcitizen | question in regards to mining blocks through bitcoin. Is the algorithm to mint coins separate from confirming transactions or is it the same thing? | 16:45 |
| sipa | #bitcoin please | 16:45 |
| ghostedcitizen | ten four | 16:45 |
| -!- _alp_ is now known as alpalp | 16:47 | |
| bramc | One thing my Python Merkle set is *not* going to do is parallel hashing. That will have to be done in the C port. It will do lazy hashing though, so 'in principle' adding such parallelism is 'easy' | 16:47 |
| kanzure | was this source code public linked yet | 16:48 |
| kanzure | haven't been paying close attention | 16:48 |
| bramc | kanzure, I haven't written the first line yet, so no. I'm finishing up working out the byte format of it | 16:48 |
| bramc | As in, I have notes on an exact byte format sitting here on my desk, and if I don't change them tomorrow I might actually start coding it. | 16:51 |
| -!- Guest51134 is now known as pigeons | 16:53 | |
| gmaxwell | 17:02 < pindarhk> ScalingBitcoin.org: Please note that we've extended the deadline for proposals to Nov 11, 2015 at 23:59 UTC. Please see https://scalingbitcoin.org/hongkong2015/#cfp | 17:02 |
| ebfull | other than the fact that a transaction is meaningless with empty vin/vout vectors, are there any assumptions made elsewhere in bitcoin that would be adversely affected by the presense of such a transaction? | 17:05 |
| ebfull | right now it's explicitly prohibited, but are there any reasons aside from "there's no point to a transaction with no inputs and outputs" | 17:06 |
| kanzure | you can instantiate a transaction without those parameters, without sending to network | 17:07 |
| ebfull | if they were allowed, what invariants might it violate? | 17:08 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 17:08 | |
| ebfull | one thing might be the expectation of the end user that the vectors are populated | 17:08 |
| nwilcox | If there are txns with 0 ins but some outs, or vice-versa, the graph of transactions would be partitioned, so any graph-crawling algorithms may stick in a subgraph. | 17:09 |
| nwilcox | If there any containers that index by outpoint, for example, and then code iterates over the container's values assuming all txns are covered, such code would fail. | 17:10 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 17:16 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit] | 17:16 | |
| bramc | ebfull, There wouldn't be any way to pay for it | 17:17 |
| ebfull | bramc: nwilcox: that's a good point, thanks. in our situation paying for it should be covered by other means | 17:18 |
| zooko | Folks: ebfull and nwilcox are part of the Zerocoin Electric Coin Company team, and we're trying to understand this in order to understand how best to fit in zk-SNARK Zerocash transactions with current Bitcoin transactions. | 17:22 |
| zooko | ☺ | 17:23 |
| sipa | ebfull: having no inputs would mean the transaction hash cannot be guaranteed to be unique | 17:23 |
| sipa | ebfull: which it is in bitcoin, because coinbases have the height in their input, and other transactions have the hashes of other transactions | 17:24 |
| ebfull | sipa: niiice, we'll have to preserve that invariant | 17:24 |
| jcorgan | zooko: is there an updated whitepaper on the details of the new ZC implementation? | 17:26 |
| nwilcox | jcorgan: Not yet. | 17:27 |
| jcorgan | is it an entirely new thing from the original ZC concept or a variation | 17:28 |
| zooko | jcorgan: no, the most current document is still http://zerocash-project.org/ | 17:29 |
| jcorgan | great, i understood that paper, at least at one time :-) | 17:30 |
| zooko | jcorgan: it's very close to that, still. | 17:30 |
| zooko | What we're working on right now is some nuts-and-bolts that aren't really spec'ed out in the paper. | 17:30 |
| zooko | (http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf) | 17:30 |
| zooko | sipa: thanks for pointing that out. | 17:31 |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 17:31 | |
| -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] | 17:32 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Read error: Connection reset by peer] | 17:33 | |
| sipa | ebfull: no outputs has afaik no reason - and in a post-subsidy world, a block with no fees would need a bogus 0-value output as a result of it | 17:33 |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 17:34 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-macuigubwwfjmatj] has quit [Quit: Connection closed for inactivity] | 17:34 | |
| gmaxwell | sipa: There is nothing 'bogus' about it except its useless. It could be an op_return. | 17:35 |
| ebfull | certainly the transaction would be financed fee-wise, but our mechanism shouldn't require a value transfer to a txout in all cases | 17:36 |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 17:42 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 17:46 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Ping timeout: 240 seconds] | 17:50 | |
| -!- adlai [~adlai@unaffiliated/adlai] has quit [Remote host closed the connection] | 17:51 | |
| -!- Lightsword [~Lightswor@104.194.117.23] has joined #bitcoin-wizards | 17:57 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] | 17:58 | |
| -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 18:00 | |
| -!- CodeShark is now known as Guest30488 | 18:01 | |
| -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit] | 18:02 | |
| -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 18:02 | |
| -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit] | 18:02 | |
| -!- nanashi [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has joined #bitcoin-wizards | 18:05 | |
| -!- Guest30488 [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] | 18:08 | |
| -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 18:09 | |
| -!- p15 [~p15@93.186.169.205] has joined #bitcoin-wizards | 18:09 | |
| -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit] | 18:09 | |
| -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 18:09 | |
| -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Remote host closed the connection] | 18:15 | |
| -!- zooko [~user@70.96.9.174] has quit [Remote host closed the connection] | 18:15 | |
| -!- p15_ [~p15@93.186.169.206] has joined #bitcoin-wizards | 18:16 | |
| -!- p15 [~p15@93.186.169.205] has quit [Ping timeout: 264 seconds] | 18:18 | |
| -!- zooko [~user@70.96.9.174] has joined #bitcoin-wizards | 18:20 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 18:21 | |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards | 18:31 | |
| -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 18:33 | |
| -!- nanashi [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has quit [Quit: Leaving] | 18:34 | |
| -!- nanashi [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has joined #bitcoin-wizards | 18:34 | |
| -!- nanashi [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has quit [Client Quit] | 18:35 | |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Ping timeout: 240 seconds] | 18:35 | |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards | 18:40 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] | 18:48 | |
| -!- p15_ [~p15@93.186.169.206] has quit [Ping timeout: 255 seconds] | 18:51 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 18:55 | |
| -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds] | 18:56 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] | 18:56 | |
| -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 19:01 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 19:02 | |
| -!- zooko` [~user@172.56.9.100] has joined #bitcoin-wizards | 19:09 | |
| -!- zooko`` [~user@70.96.9.174] has joined #bitcoin-wizards | 19:12 | |
| -!- zooko [~user@70.96.9.174] has quit [Ping timeout: 276 seconds] | 19:13 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 19:15 | |
| -!- zooko` [~user@172.56.9.100] has quit [Ping timeout: 255 seconds] | 19:16 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [] | 19:18 | |
| -!- zooko`` [~user@70.96.9.174] has quit [Ping timeout: 255 seconds] | 19:21 | |
| -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Quit: Textual IRC Client: www.textualapp.com] | 19:22 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-lmehohmmjivexuyf] has joined #bitcoin-wizards | 19:22 | |
| -!- p15 [~p15@93.186.169.199] has joined #bitcoin-wizards | 19:25 | |
| -!- c0rw1n is now known as c0rw|zZz | 19:26 | |
| -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Quit: Leaving...] | 19:33 | |
| -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Remote host closed the connection] | 19:36 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 19:36 | |
| -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:d971:6ff5:3ba6:24db] has quit [] | 19:38 | |
| -!- snthsnth_ [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 19:42 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds] | 19:43 | |
| -!- zooko [~user@2601:281:8001:26aa:3c89:60d9:cbe:edd1] has joined #bitcoin-wizards | 19:49 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 19:49 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 19:50 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 19:50 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 19:53 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit] | 19:55 | |
| -!- zooko [~user@2601:281:8001:26aa:3c89:60d9:cbe:edd1] has quit [Ping timeout: 240 seconds] | 19:56 | |
| -!- zooko` [~user@2601:281:8001:26aa:3c89:60d9:cbe:edd1] has joined #bitcoin-wizards | 20:06 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] | 20:07 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 20:07 | |
| -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 20:11 | |
| -!- gwency [~gwency__@120.20.189.53] has joined #bitcoin-wizards | 20:12 | |
| -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 246 seconds] | 20:15 | |
| -!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Remote host closed the connection] | 20:18 | |
| -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] | 20:22 | |
| -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] | 20:23 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:24 | |
| -!- tulip [~tulip@46.101.245.204] has quit [Remote host closed the connection] | 20:26 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 20:32 | |
| -!- metric [~metric@199.127.226.246] has joined #bitcoin-wizards | 20:40 | |
| -!- jtoomim [~jtoomim@63.135.62.197] has joined #bitcoin-wizards | 20:42 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 20:46 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 20:49 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [] | 20:49 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] | 20:52 | |
| Taek | two questions about weak blocks | 20:52 |
| Taek | 1. what is incentivizing someone to create weak blocks? | 20:53 |
| -!- gwency [~gwency__@120.20.189.53] has quit [Quit: This computer has gone to sleep] | 20:53 | |
| Taek | 2. what is stopping an attacker from ignoring the weak blocks and creating difficult-to-validate blocks anyway? | 20:53 |
| bramc | Taek, 1. If you make a weak block and then introduce it to the network your own subsequent blocks are more likely to propagate quickly | 20:54 |
| bramc | 2. All such an attacker would succeed in doing is making it more likely for their own block to get orphaned | 20:55 |
| Taek | not strictly true. There are network configurations where an attacker with sufficient mining power can drive the revenue of smaller miners down | 20:55 |
| aj | Taek: 1: you make weak blocks automatically while trying to make a real block, the only extra work is publishing it | 20:55 |
| Taek | *by making expensive-to-validate blocks | 20:56 |
| Taek | maybe I am overly concerned about the potential impact though | 20:58 |
| Taek | I want to make sure that, in all realisitic worst-case scenarios, we limit the pressure towards miner centralization | 20:59 |
| -!- skyraider [uid41097@gateway/web/irccloud.com/x-vvtfgzrqhllfkbge] has quit [Quit: Connection closed for inactivity] | 21:02 | |
| Taek | if we assume that there is a substantial transaction backlog, occasionally there will be two strong blocks found back-to-back, with no weak blocks to use as support | 21:02 |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 21:02 | |
| Taek | and you end up with a race that is equivalent to the races we see today | 21:03 |
| Taek | but if you require that a full block be within X bytes of the nearest weak block, you put a limit on the worst-case race | 21:04 |
| Taek | (you'd probably also need to require that weak blocks be within X bytes of eachother, and stack) | 21:04 |
| Taek | then, if we assume an adversary miner that is trying to make slow-validating blocks, the adversary is limited in effectiveness unless it is creating and hiding weak blocks | 21:07 |
| -!- zooko` [~user@2601:281:8001:26aa:3c89:60d9:cbe:edd1] has quit [Ping timeout: 246 seconds] | 21:08 | |
| Taek | and, if there is a financial incentive for sharing weak blocks, that introduces an opportunity cost to the adversary for hiding weak blocks | 21:08 |
| -!- tulip [~tulip@46.101.245.204] has joined #bitcoin-wizards | 21:12 | |
| Taek | I think, there is another advantage to this scheme - right now in Bitcoin validating nodes can occasionally get slammed with a ton of blocks in a tight window | 21:13 |
| Taek | but, if you are requiring that each block be built out of weak blocks, each of which can only add so many bytes, then it's much less likely that you'll get to such high throughputs in a tight window | 21:13 |
| Taek | and, it's safer to have longer blocks be larger, because they will likely be composed of many weak blocks. | 21:14 |
| Taek | essentially, you get a transaction throughput that is more correlated with the amount of time that has passed between blocks compared to today's scheme | 21:14 |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [Read error: Connection reset by peer] | 21:19 | |
| Taek | I don't really know how one might financially incentivize sharing weak blocks, other than sharing the subsidy, which is a temporary solution for Bitcoin | 21:22 |
| Taek | (where the incentive is used to create opportunity cost for adversarial behavior) | 21:23 |
| aj | Taek: any strong block is also a weak block though -- weak blocks just have a lower minimum difficulty | 21:30 |
| aj | Taek: the odds of finding a strong block as your first weak block are exponentially low depending on the difference in difficulty between strong and weak | 21:31 |
| bramc | Requiring strong blocks be made of weak blocks and that weak blocks have their own maximum size would lower the overall transaction limit | 21:32 |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-lmehohmmjivexuyf] has quit [Quit: Connection closed for inactivity] | 21:39 | |
| Taek | aj: it's only linearly low. If weak blocks are 1/64 the difficulty, then 1/64 of the time you are going to find two strong blocks in a row | 21:39 |
| Taek | bramc: not if you remove the maximum size requirement for a strong block | 21:40 |
| el33th4x0r | Taek: weak blocks would make centralization worse. small miners are unlikely to come up with a weak block candidate, and when they find a real block, the propagation of that real block will be slow | 21:40 |
| el33th4x0r | large miners are unaffected, and that creates pressure towards centralization. | 21:41 |
| Taek | el33th4x0r: not at all. small miners will build their strong blocks on top of the weak blocks that other miners have found | 21:41 |
| Taek | they still get the benefits of fast propagation | 21:41 |
| el33th4x0r | Take: that takes away their power to select what transactions go into a block. | 21:42 |
| Taek | It reduces censorship. They can still add X bytes of their own transactions, but they are limited in what they are allowed to exclude | 21:42 |
| el33th4x0r | Taek: also, it's easy for large miners to keep small ones out: just include a private transaction that is never broadcast to small miners | 21:42 |
| Taek | el33th4x0r: I don't see what you mean by that? How can you have a private transaction? It's a public blockchain. Unless you mean a private weak block? | 21:44 |
| Taek | the biggest potential problem that I see here is that by forcing strong blocks to be built out of weak blocks, you essentially make things non-progress-free. But it's not the POW itself that isn't progress-free, it's just the block composition | 21:45 |
| bramc | Taek, No the problem is the maximum size for a weak block. If a strong block comes up quickly and it's required to be made of weak blocks it will only have so many weak blocks worth of transactions to cobble together | 21:45 |
| Taek | bramc: that's the point. You make throughput time-based | 21:45 |
| Taek | the expected throughput stays the same, to use a concrete example: | 21:46 |
| bramc | Taek, It's already time-based, just more granular | 21:46 |
| Taek | right, you get a better granularity | 21:46 |
| el33th4x0r | Taek: a large miner can create a weak block that includes a set of private transactions. the large miner never transmits the private transactions to the small miners. the small miners are now either "SPV mining" or else, if they want to validate all xactions, they need to create their own weak block by finding a weak solution, but their hash power | 21:46 |
| el33th4x0r | might be too small to find it in time. | 21:46 |
| Taek | bramc: the expected throughput stays the same unless you put a cap on the max strong block size in addition to capping the max weak block size. | 21:47 |
| Taek | which might be a sane thing to do | 21:47 |
| Taek | el33th4x0r: the small miners would respond to the 'secret' weak block the same way they'd respond to a 'secret' block on the current blockchain: they'd ignore it | 21:48 |
| el33th4x0r | Taek: ok, if they ignore the weak blocks that contain private transactions, which weak blocks do they build on? | 21:49 |
| Taek | el33th4x0r: what you are suggesting is equivalent to a 51% attack. | 21:50 |
| Taek | Instead of building on the weak blocks that they can't parse, the build on the weak blocks that they can parse | 21:50 |
| Taek | but this is why I was saying it would be nice to have a financial reward for sharing a weak block | 21:52 |
| el33th4x0r | Disagree, not at all equivalent to a 51% attack. It can happen without a 51%er. And it can happen naturally, without coordination. | 21:52 |
| el33th4x0r | Taek: all it requires is for the large miners to possess and want to include some transactions that the small miners have not seen. | 21:52 |
| el33th4x0r | Taek: can happen consistently if the small miners have a slow connection | 21:53 |
| Taek | either a miner is broadcasting the weak blocks they are finding, or the miner is hiding the weak blocks they are finding, or the miner is only sharing the weak blocks they are finding with a subset of other miners. Which scenario are you talking about? | 21:53 |
| el33th4x0r | take the first one, the most benign, straightforward case. weak blocks pose centralization problems even in that case. | 21:54 |
| Taek | explain | 21:54 |
| el33th4x0r | large miners see a set of xactions and include them in their weak weak blocks. | 21:55 |
| el33th4x0r | small miners do not see those transactions yet. | 21:55 |
| el33th4x0r | they now have to discover their own weak block, but their hash power is too small to do this effectively. | 21:55 |
| el33th4x0r | the large miners have a persistent advantage. | 21:56 |
| el33th4x0r | if the small miner gets lucky and finds a real (strong) block, he will have difficulty propagating it, because it is not based on a weak block. | 21:57 |
| el33th4x0r | large miners do not suffer from this problem. weak blocks exacerbate centralization. | 21:57 |
| Taek | there will be no difficulty propagating it if it is not based on a weak block; it will be small | 21:57 |
| Taek | perhaps you mean to suggest that small miners will on average find smaller blocks than large miners? This would put them at a disadvantage because it means less income from fees. | 21:58 |
| Taek | I believe you could show that, despite this, it's still a strictly-superior construction to the way things work today | 22:00 |
| el33th4x0r | that too, but this discussion was prompted by limiting "the pressure towards miner centralization." | 22:00 |
| el33th4x0r | disagree. weak blocks do not appear strictly superior. they provide an advantage to large miners | 22:01 |
| Taek | (I say that, and then gmaxwell points out several critical problems with my suggestion) | 22:01 |
| el33th4x0r | (yeah he does that! :-) | 22:01 |
| Taek | I need to go to bed, but I will leave a final remark that you have definitely not convinced me that my weak block scheme provides an increased advantage to large miners compared to the way things work today | 22:02 |
| Taek | I will sleep on it and see if anything useful happens | 22:02 |
| el33th4x0r | same here. and nor have you convinced me that the difference is small. if weak blocks are worth implementing at all, then the difference ought to be substantial. | 22:03 |
| -!- Giszmo [~leo@pc-36-133-241-201.cm.vtr.net] has quit [Quit: Leaving.] | 22:07 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 22:14 | |
| -!- snthsnth_ [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 22:20 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 22:21 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wtmiirdfedouefgi] has joined #bitcoin-wizards | 22:23 | |
| -!- gwency [~gwency__@120.20.189.53] has joined #bitcoin-wizards | 22:29 | |
| -!- bitkarma [uid124593@gateway/web/irccloud.com/x-ekmsvclefgskssqv] has joined #bitcoin-wizards | 22:29 | |
| -!- grandmaster [dansmith3@gateway/shell/bnc4free/x-cnkazmrkwbaixgmv] has quit [Ping timeout: 244 seconds] | 22:41 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 22:42 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-urggymssigpspxaw] has quit [Ping timeout: 260 seconds] | 22:46 | |
| -!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 265 seconds] | 22:51 | |
| -!- CodeShark [~androirc@100.9.177.117] has joined #bitcoin-wizards | 22:53 | |
| -!- gwency [~gwency__@120.20.189.53] has quit [Quit: This computer has gone to sleep] | 23:02 | |
| -!- tulip [~tulip@46.101.245.204] has quit [] | 23:09 | |
| -!- fkhan [weechat@unaffiliated/loteriety] has joined #bitcoin-wizards | 23:13 | |
| -!- fkhan [weechat@unaffiliated/loteriety] has quit [Changing host] | 23:13 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-aopqxjyqxklngfzi] has joined #bitcoin-wizards | 23:13 | |
| -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 23:13 | |
| -!- CodeShark [~androirc@100.9.177.117] has quit [Read error: Connection reset by peer] | 23:14 | |
| -!- CodeShark [~androirc@100.9.177.117] has joined #bitcoin-wizards | 23:15 | |
| -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds] | 23:17 | |
| -!- erasmospunk [~erasmospu@151.68.30.255] has joined #bitcoin-wizards | 23:18 | |
| Luke-Jr | hm, contracthashtool doesn't quite do what I thought it did | 23:20 |
| Luke-Jr | is it possible to commit to a hash in the signature instead of the key? | 23:21 |
| -!- erasmospunk [~erasmospu@151.68.30.255] has quit [Ping timeout: 250 seconds] | 23:22 | |
| -!- erasmospunk [~erasmospu@46.166.190.176] has joined #bitcoin-wizards | 23:22 | |
| -!- ll_ [8984fa09@gateway/web/freenode/ip.137.132.250.9] has joined #bitcoin-wizards | 23:29 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 23:30 | |
| -!- CodeShark [~androirc@100.9.177.117] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] | 23:33 | |
| -!- erasmospunk [~erasmospu@46.166.190.176] has quit [Ping timeout: 264 seconds] | 23:35 | |
| gmaxwell | Yes, via sign to contract. I think pieter was working on an implementation for libsecp256k1. | 23:37 |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 264 seconds] | 23:45 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 23:47 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 23:47 | |
| -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds] | 23:52 | |
| -!- nivah [~linker@115.79.55.177] has joined #bitcoin-wizards | 23:52 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has joined #bitcoin-wizards | 23:53 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] | 23:58 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 23:59 | |
| --- Log closed Tue Nov 10 00:00:21 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!