--- Log opened Mon Nov 09 00:00:20 2015 00:04 -!- digitalmagus [~digitalma@unaffiliated/digitalmagus] has quit [Ping timeout: 255 seconds] 00:07 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 00:11 -!- kyuupichan [~Neil@ae053102.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards 00:12 -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards 00:19 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 00:23 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 00:26 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards 00:27 -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds] 00:31 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds] 00:34 -!- JackH [~Jack@host-80-43-141-3.as13285.net] has joined #bitcoin-wizards 00:40 -!- 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 01:06 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards 01:11 -!- c0rw1n [~c0rw1n@108.193-241-81.adsl-dyn.isp.belgacom.be] has quit [] 01:13 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 01:17 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving] 01:25 -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards 01:28 -!- c0rw1n [~c0rw1n@108.193-241-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 01:33 -!- nivah [~linker@115.79.55.177] has joined #bitcoin-wizards 01:45 -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds] 01:58 -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 02:03 -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [Remote host closed the connection] 02:05 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] 02:07 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] 02:09 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards 02:12 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 272 seconds] 02:13 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards 02:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 02:24 -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards 02:25 -!- 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] 03:41 -!- 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:43 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 03:44 -!- 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:45 -!- 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:48 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] 03:50 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 03:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] 03:52 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 03:53 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] 03:55 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] 04:02 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 04:05 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] 04:07 -!- kyuupichan [~Neil@ae053102.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards 04:13 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] 04:20 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards 04:22 -!- 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:27 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards 04:46 -!- eudoxia [~eudoxia@r167-57-115-19.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 04:51 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards 04:53 -!- 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:58 -!- rht___ [uid86914@gateway/web/irccloud.com/x-zmifygqekouhxqal] has quit [Quit: Connection closed for inactivity] 04:59 -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has quit [Ping timeout: 240 seconds] 05:03 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Remote host closed the connection] 05:13 -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards 05:13 -!- rustyn [~rustyn@unaffiliated/rustyn] has quit [] 05:22 -!- Giszmo [~leo@pc-36-133-241-201.cm.vtr.net] has joined #bitcoin-wizards 05:33 -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has quit [Ping timeout: 265 seconds] 05:45 -!- damethos [~damethos@unaffiliated/damethos] has quit [Remote host closed the connection] 05:49 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] 05:53 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards 05:55 -!- p15 [~p15@93.186.169.213] has quit [Ping timeout: 265 seconds] 05:58 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] 06:00 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 06:02 -!- 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:03 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards 06:05 -!- 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:07 -!- 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:08 -!- 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:09 -!- pozitron [~nu@94.242.243.250] has quit [Ping timeout: 264 seconds] 06:13 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-wizards 06:13 -!- pigeons is now known as Guest51134 06:32 -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:cd2b:fb11:150b:fff3] has joined #bitcoin-wizards 06:38 -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:cd2b:fb11:150b:fff3] has quit [Read error: Connection reset by peer] 06:39 -!- ratbanebo [~ratbanebo@78-23-10-185.access.telenet.be] has joined #bitcoin-wizards 06:40 -!- atgreen [~green@38.104.156.250] has joined #bitcoin-wizards 06:45 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 272 seconds] 06:49 -!- Meeh [~meeeeeeh@meeh.sigterm.no] has quit [Ping timeout: 260 seconds] 06:51 -!- Meeh [~meeeeeeh@meeh.sigterm.no] has joined #bitcoin-wizards 06:53 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards 06:55 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards 06:57 -!- 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:59 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 07:01 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-wizards 07:06 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.] 07:08 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 07:10 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards 07:14 -!- 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:18 < 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:19 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards 07:20 < nsh> oh, byzantine fault tolerance 07:21 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards 07:23 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 07:27 -!- foobar_ [41ce5f92@gateway/web/freenode/ip.65.206.95.146] has joined #bitcoin-wizards 07:28 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds] 07:29 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards 07:35 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards 07:39 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Ping timeout: 240 seconds] 07:48 -!- kyuupichan [~Neil@ae053102.dynamic.ppp.asahi-net.or.jp] has quit [Read error: Connection reset by peer] 07:51 -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 07:52 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards 07:56 -!- 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:57 -!- nwilcox [~nwilcox@74-95-207-205-SFBA.hfc.comcastbusiness.net] has joined #bitcoin-wizards 07:59 -!- 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 08:01 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds] 08:07 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 08:10 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 08:14 -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has joined #bitcoin-wizards 08:14 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards 08:19 -!- MoALTz [~no@78-11-179-104.static.ip.netia.com.pl] has joined #bitcoin-wizards 08:33 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 08:38 -!- StephenM347 [~stephenm3@static-64-223-246-218.port.east.myfairpoint.net] has joined #bitcoin-wizards 08:41 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.] 08:43 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards 08:51 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards 08:54 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.] 08:58 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 09:00 -!- hazirafel [~hazirafel@space.telavivmakers.org] has joined #bitcoin-wizards 09:09 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards 09:18 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Remote host closed the connection] 09:48 -!- 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:50 -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards 09:52 -!- bobke [~bobke@94-226-145-186.access.telenet.be] has quit [Remote host closed the connection] 09:54 -!- nwilcox [~nwilcox@74-95-207-205-SFBA.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] 09:56 -!- bobke [~bobke@94-226-145-186.access.telenet.be] has joined #bitcoin-wizards 09:57 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards 10:00 -!- spinza [~spin@197.89.46.41] has quit [Excess Flood] 10:02 -!- 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:04 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards 10:06 -!- 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:07 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] 10:09 -!- 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:11 -!- 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:13 < el33th4x0r> hi Brian 10:14 < 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:18 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards 10:20 -!- 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:21 -!- zooko [~user@72.42.70.227] has quit [Read error: Connection reset by peer] 10:22 -!- zooko [~user@72.42.70.227] has joined #bitcoin-wizards 10:23 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has quit [Ping timeout: 255 seconds] 10:25 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 10:45 -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Ping timeout: 240 seconds] 10:48 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 10:51 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 244 seconds] 10:52 -!- iddo [~idddo@csm.cs.technion.ac.il] has joined #bitcoin-wizards 10:55 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 10:59 -!- 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 11:00 -!- matsjj [~matsjj@p20030089EA2EE217E8E5D131E784351E.dip0.t-ipconnect.de] has joined #bitcoin-wizards 11:02 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:03 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] 11:04 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] 11:04 -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has joined #bitcoin-wizards 11:06 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:07 -!- atgreen [~green@38.104.156.250] has quit [Ping timeout: 250 seconds] 11:08 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:10 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 276 seconds] 11:11 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 11:12 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 244 seconds] 11:12 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:15 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 244 seconds] 11:17 -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Ping timeout: 240 seconds] 11:19 -!- iddo [~idddo@csm.cs.technion.ac.il] has joined #bitcoin-wizards 11:20 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:22 -!- Yoghur114 [~jorn@80.57.227.14] has joined #bitcoin-wizards 11:23 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards 11:24 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] 11:25 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:28 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] 11:30 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:31 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 11:31 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:33 -!- 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:34 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 265 seconds] 11:37 -!- skyraider [uid41097@gateway/web/irccloud.com/x-vvtfgzrqhllfkbge] has joined #bitcoin-wizards 11:40 -!- Doge_Funnie [~Doge_Funn@unaffiliated/doge-funnie/x-0003093] has quit [Quit: Leaving] 11:42 -!- matsjj [~matsjj@p20030089EA2EE217E8E5D131E784351E.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 11:50 -!- jojva [~joris@cha92-12-88-162-171-45.fbx.proxad.net] has quit [Ping timeout: 255 seconds] 11:52 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection] 11:55 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 11:58 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] 11:59 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards 12:03 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 12:07 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 12:07 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 12:10 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 255 seconds] 12:11 < 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:12 < 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:13 < 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:14 -!- smk [9e557647@gateway/web/freenode/ip.158.85.118.71] has quit [Quit: Page closed] 12:18 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 12:18 -!- tulip [~tulip@46.101.245.204] has joined #bitcoin-wizards 12:19 < 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:21 < 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:22 < 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:23 < 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:25 < 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:26 < 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:27 < 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:28 -!- 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:29 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 12:32 -!- 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:37 -!- dEBRUYNE_ [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 12:40 -!- dEBRUYNE [~dEBRUYNE@vp0475.uvt.nl] has joined #bitcoin-wizards 12:40 -!- dEBRUYNE__ [~dEBRUYNE@vp0475.uvt.nl] has quit [Ping timeout: 240 seconds] 12:41 -!- Jeremy_Rand [~jeremy@ip68-97-34-37.ok.ok.cox.net] has quit [Ping timeout: 272 seconds] 12:43 -!- 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:47 -!- matsjj [~matsjj@p20030089EA2EE217E8E5D131E784351E.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 12:48 -!- 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:49 -!- Eliel_ is now known as Eliel 12:50 -!- ratbanebo [~ratbanebo@78-23-10-185.access.telenet.be] has quit [Ping timeout: 255 seconds] 12:55 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards 12:56 < 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:58 -!- derpderp [~derpderp@c-174-61-236-141.hsd1.wa.comcast.net] has joined #bitcoin-wizards 12:59 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 13:01 -!- derpderp_ [~derpderp@c-174-61-236-141.hsd1.wa.comcast.net] has quit [Ping timeout: 272 seconds] 13:07 -!- 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:08 -!- 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:09 -!- roxtrongo [~roxtrongo@190-22-210-57.baf.movistar.cl] has joined #bitcoin-wizards 13:10 < 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:11 < 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:12 < 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:13 -!- 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:14 < 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:15 < 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:17 -!- 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:18 < 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:19 < el33th4x0r> gmaxwell: agreed on the main benefit. 13:20 -!- 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:21 -!- 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:22 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 13:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 < 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:29 < gmaxwell> This has nothing to do with merchants. 13:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 13:30 < 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:31 -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Ping timeout: 272 seconds] 13:32 -!- 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:33 < 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:34 < 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:35 < 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:36 < 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:38 < 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:39 -!- 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:42 -!- 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:43 -!- 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:44 -!- 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:45 -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards 13:48 -!- Jeremy_Rand [~jeremy@172.56.15.98] has joined #bitcoin-wizards 13:53 < 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:54 < el33th4x0r> gmaxwell: and if you're not suggesting trusting weak blocks in some way, they don't help with latency. 13:58 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: hotel-ward] 14:00 -!- snthsnth [~snthsnth@206.110.20.18] has quit [Ping timeout: 252 seconds] 14:01 -!- 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:05 -!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards 14:06 -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has joined #bitcoin-wizards 14:08 -!- 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:11 -!- malte- is now known as malte 14:13 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 14:14 < 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:20 -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has joined #bitcoin-wizards 14:22 -!- 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:26 < 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:27 < 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:28 < 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:30 < 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:31 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards 14:32 -!- 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:35 -!- zooko` [~user@172.56.8.239] has joined #bitcoin-wizards 14:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] 14:37 -!- zooko [~user@70.96.9.174] has quit [Ping timeout: 260 seconds] 14:38 -!- StephenM347 [~stephenm3@static-64-223-246-218.port.east.myfairpoint.net] has quit [] 14:40 < 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:41 < 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:42 < 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:43 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-wizards 14:43 -!- zooko` is now known as zooko 14:45 < 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:46 < 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:47 < 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:48 < 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:49 < 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:50 < 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:51 < 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:52 < 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:53 < 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:54 < 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:55 < 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:56 < 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:57 < 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:58 -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards 14:58 < el33th4x0r> bramc, "number of strong blocks"? 14:59 < 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 15:00 < el33th4x0r> bramc: thanks, indeed, weak blocks require such measures to deter spam. 15:01 < 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:02 < bramc> How are smaller miners at a disadvantage for mining weak blocks effectively? 15:03 < 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:04 < nanashi> whats a weak block 15:05 < 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:06 < gwillen> gmaxwell: I missed the explanation of what you gain by separating the two transaction sets -- is there a quick summary? 15:07 < 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:08 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 15:09 < 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:10 -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Ping timeout: 276 seconds] 15:11 < 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:12 < 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:14 < 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:16 < 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:17 < 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:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] 15:20 < 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:22 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] 15:24 < 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:27 < 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:28 < 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:29 -!- 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:30 < 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:31 < 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:32 < 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:33 < 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:34 < 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:35 < 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:37 < 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:38 < 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:39 < 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:40 < 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:41 -!- 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:42 < gmaxwell> bsm1175321: NO 15:43 -!- 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:44 < 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:45 < 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:46 < 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:47 < 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:49 < 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:50 < bramc> bsm117532 Right, that's a different problem 15:50 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 15:51 -!- 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:52 -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 15:53 -!- nanashi [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has quit [Quit: Leaving] 15:54 -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:d971:6ff5:3ba6:24db] has quit [Read error: Connection reset by peer] 15:55 < 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:56 < 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:57 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 15:57 < bsm1175321> sipa: Good point. Not sure how to address that. 16:03 -!- archobserver [~archobser@unaffiliated/superobserver] has joined #bitcoin-wizards 16:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 16:10 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 16:11 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 16:14 -!- zooko` [~user@70.96.9.174] has joined #bitcoin-wizards 16:15 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] 16:16 -!- zooko [~user@172.56.8.239] has quit [Ping timeout: 276 seconds] 16:17 -!- zooko` is now known as zooko 16:20 -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards 16:21 -!- 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:26 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 276 seconds] 16:28 -!- 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:29 -!- zooko` [~user@70.96.9.174] has joined #bitcoin-wizards 16:30 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 276 seconds] 16:31 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards 16:33 -!- 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:37 -!- Jeremy_Rand [~jeremy@172.56.7.208] has joined #bitcoin-wizards 16:40 < 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:41 < bramc> And standalone functions confirm_included(root, val, proof) and confirm_not_included(root, val, proof) 16:43 -!- ghostedcitizen [~dookieboo@hashbangs.com] has joined #bitcoin-wizards 16:45 < 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:47 -!- _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:48 < 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:51 < 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:53 -!- Guest51134 is now known as pigeons 17:02 < 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:05 < 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:06 < 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:07 < kanzure> you can instantiate a transaction without those parameters, without sending to network 17:08 < 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:09 < 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:10 < 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:16 -!- 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:17 < bramc> ebfull, There wouldn't be any way to pay for it 17:18 < ebfull> bramc: nwilcox: that's a good point, thanks. in our situation paying for it should be covered by other means 17:22 < 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:23 < zooko> ☺ 17:23 < sipa> ebfull: having no inputs would mean the transaction hash cannot be guaranteed to be unique 17:24 < 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:26 < jcorgan> zooko: is there an updated whitepaper on the details of the new ZC implementation? 17:27 < nwilcox> jcorgan: Not yet. 17:28 < jcorgan> is it an entirely new thing from the original ZC concept or a variation 17:29 < zooko> jcorgan: no, the most current document is still http://zerocash-project.org/ 17:30 < 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:31 < 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:32 -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] 17:33 -!- 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:34 -!- 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:35 < gmaxwell> sipa: There is nothing 'bogus' about it except its useless. It could be an op_return. 17:36 < 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:42 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 17:46 -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards 17:50 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has quit [Ping timeout: 240 seconds] 17:51 -!- adlai [~adlai@unaffiliated/adlai] has quit [Remote host closed the connection] 17:57 -!- Lightsword [~Lightswor@104.194.117.23] has joined #bitcoin-wizards 17:58 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] 18:00 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards 18:01 -!- CodeShark is now known as Guest30488 18:02 -!- 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:05 -!- nanashi [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has joined #bitcoin-wizards 18:08 -!- Guest30488 [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] 18:09 -!- 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:15 -!- 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:16 -!- p15_ [~p15@93.186.169.206] has joined #bitcoin-wizards 18:18 -!- p15 [~p15@93.186.169.205] has quit [Ping timeout: 264 seconds] 18:20 -!- zooko [~user@70.96.9.174] has joined #bitcoin-wizards 18:21 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 18:31 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards 18:33 -!- darmou [~darmou@c-73-241-146-77.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 18:34 -!- 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:35 -!- 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:40 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #bitcoin-wizards 18:48 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 18:51 -!- p15_ [~p15@93.186.169.206] has quit [Ping timeout: 255 seconds] 18:55 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 18:56 -!- 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] 19:01 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards 19:02 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 19:09 -!- zooko` [~user@172.56.9.100] has joined #bitcoin-wizards 19:12 -!- zooko`` [~user@70.96.9.174] has joined #bitcoin-wizards 19:13 -!- zooko [~user@70.96.9.174] has quit [Ping timeout: 276 seconds] 19:15 -!- orik [~orik@50-46-139-225.evrt.wa.frontiernet.net] has joined #bitcoin-wizards 19:16 -!- zooko` [~user@172.56.9.100] has quit [Ping timeout: 255 seconds] 19:18 -!- mrkent [~textual@unaffiliated/mrkent] has quit [] 19:21 -!- zooko`` [~user@70.96.9.174] has quit [Ping timeout: 255 seconds] 19:22 -!- 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:25 -!- p15 [~p15@93.186.169.199] has joined #bitcoin-wizards 19:26 -!- c0rw1n is now known as c0rw|zZz 19:33 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Quit: Leaving...] 19:36 -!- 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:38 -!- ratbanebo [~ratbanebo@2a02:1812:1515:2400:d971:6ff5:3ba6:24db] has quit [] 19:42 -!- snthsnth_ [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 19:43 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds] 19:49 -!- 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:50 -!- 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:53 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 19:55 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit] 19:56 -!- zooko [~user@2601:281:8001:26aa:3c89:60d9:cbe:edd1] has quit [Ping timeout: 240 seconds] 20:06 -!- zooko` [~user@2601:281:8001:26aa:3c89:60d9:cbe:edd1] has joined #bitcoin-wizards 20:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] 20:07 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 20:11 -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has joined #bitcoin-wizards 20:12 -!- gwency [~gwency__@120.20.189.53] has joined #bitcoin-wizards 20:15 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 246 seconds] 20:18 -!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Remote host closed the connection] 20:22 -!- matsjj [~matsjj@p5B209AC3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20:23 -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] 20:24 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards 20:26 -!- tulip [~tulip@46.101.245.204] has quit [Remote host closed the connection] 20:32 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards 20:40 -!- metric [~metric@199.127.226.246] has joined #bitcoin-wizards 20:42 -!- jtoomim [~jtoomim@63.135.62.197] has joined #bitcoin-wizards 20:46 -!- kgk [~kgk@173-167-115-138-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards 20:49 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 20:49 -!- mrkent [~textual@unaffiliated/mrkent] has quit [] 20:52 -!- 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:53 < 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:54 < 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:55 < 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:56 < Taek> *by making expensive-to-validate blocks 20:58 < Taek> maybe I am overly concerned about the potential impact though 20:59 < Taek> I want to make sure that, in all realisitic worst-case scenarios, we limit the pressure towards miner centralization 21:02 -!- 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:03 < Taek> and you end up with a race that is equivalent to the races we see today 21:04 < 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:07 < 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:08 -!- 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:12 -!- tulip [~tulip@46.101.245.204] has joined #bitcoin-wizards 21:13 < 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:14 < 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:19 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Read error: Connection reset by peer] 21:22 < 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:23 < Taek> (where the incentive is used to create opportunity cost for adversarial behavior) 21:30 < aj> Taek: any strong block is also a weak block though -- weak blocks just have a lower minimum difficulty 21:31 < 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:32 < 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:39 -!- 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:40 < 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:41 < 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:42 < 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:44 < 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:45 < 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:46 < 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:47 < 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:48 < 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:49 < el33th4x0r> Taek: ok, if they ignore the weak blocks that contain private transactions, which weak blocks do they build on? 21:50 < 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:52 < 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:53 < 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:54 < el33th4x0r> take the first one, the most benign, straightforward case. weak blocks pose centralization problems even in that case. 21:54 < Taek> explain 21:55 < 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:56 < el33th4x0r> the large miners have a persistent advantage. 21:57 < 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:58 < 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. 22:00 < 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:01 < 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:02 < 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:03 < 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:07 -!- Giszmo [~leo@pc-36-133-241-201.cm.vtr.net] has quit [Quit: Leaving.] 22:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 22:20 -!- snthsnth_ [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 22:21 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] 22:23 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wtmiirdfedouefgi] has joined #bitcoin-wizards 22:29 -!- 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:41 -!- grandmaster [dansmith3@gateway/shell/bnc4free/x-cnkazmrkwbaixgmv] has quit [Ping timeout: 244 seconds] 22:42 -!- 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:46 -!- fkhan [weechat@gateway/vpn/mullvad/x-urggymssigpspxaw] has quit [Ping timeout: 260 seconds] 22:51 -!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 265 seconds] 22:53 -!- CodeShark [~androirc@100.9.177.117] has joined #bitcoin-wizards 23:02 -!- gwency [~gwency__@120.20.189.53] has quit [Quit: This computer has gone to sleep] 23:09 -!- tulip [~tulip@46.101.245.204] has quit [] 23:13 -!- 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:14 -!- CodeShark [~androirc@100.9.177.117] has quit [Read error: Connection reset by peer] 23:15 -!- CodeShark [~androirc@100.9.177.117] has joined #bitcoin-wizards 23:17 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds] 23:18 -!- erasmospunk [~erasmospu@151.68.30.255] has joined #bitcoin-wizards 23:20 < Luke-Jr> hm, contracthashtool doesn't quite do what I thought it did 23:21 < Luke-Jr> is it possible to commit to a hash in the signature instead of the key? 23:22 -!- 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:29 -!- ll_ [8984fa09@gateway/web/freenode/ip.137.132.250.9] has joined #bitcoin-wizards 23:30 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 23:33 -!- CodeShark [~androirc@100.9.177.117] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] 23:35 -!- erasmospunk [~erasmospu@46.166.190.176] has quit [Ping timeout: 264 seconds] 23:37 < gmaxwell> Yes, via sign to contract. I think pieter was working on an implementation for libsecp256k1. 23:45 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 264 seconds] 23:47 -!- 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:52 -!- 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:53 -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has joined #bitcoin-wizards 23:58 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] 23:59 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards --- Log closed Tue Nov 10 00:00:21 2015