--- Log opened Tue Sep 25 00:00:19 2018 05:50 -!- CheckDavid [uid14990@gateway/web/irccloud.com/x-lzevnyflqfbxxfsu] has joined #bitcoin-wizards 05:51 -!- thrmo_ is now known as thrmo 05:51 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-wizards 05:55 < Varunram> "Fraud Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities": https://arxiv.org/pdf/1809.09044.pdf? 07:29 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-wizards 07:31 -!- sfhi [~sfhi@91-152-137-90.elisa-laajakaista.fi] has joined #bitcoin-wizards 07:38 -!- Giszmo [~leo@ip-4-233.219.201.nextelmovil.cl] has joined #bitcoin-wizards 07:49 < gmaxwell> wow I think it's really unfortunately that they failed to credit the origin of the sampling based anti-censorship-- which I had previously explained directly to one of the authors, even the term fraud proof is one I intoduced, yet the paper seems to make no mention of any of the bitcoin discussion on the subject. 07:50 < gmaxwell> maybe the eth huffers will market it to the point of it sounding interesting to others, finally. 07:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 08:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 08:05 < gmaxwell> Particularly sad in that I've explained the sampling approach specifically in response to their past publication on 'fraud proofs' that failed to acknoweldge other work in this space. 08:05 < gmaxwell> E.g. https://download.wpsoftware.net/bitcoin/wizards/2015-04-18.html 08:06 < gmaxwell> "This is also sad because unawareness of other work means that they weren't aware that the community actually has an interesting and powerful improvment to fraud censorship" ... "The improvement we have is this, a party offering a block to the network can be required to code it using a locally decodable rateless error correcting code" ... "Now, when people fetch, they pick random parts to fetch, 08:06 < gmaxwell> and check those parts.. but if the sever transmits more than the total block size in aggregate, the other nodes can colaborate to recover any censored parts" 08:07 < gmaxwell> (or described again more recently, https://botbot.me/freenode/bitcoin-wizards/2017-02-01/?msg=80297226&page=2 ) 08:10 -!- vtnerd_ [~Lee@173-23-103-30.client.mchsi.com] has quit [Quit: ZNC 1.7.1 - https://znc.in] 08:11 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has joined #bitcoin-wizards 08:11 < RubenSomsen> Does the process described in the paper actually manage to make fraud proofs viable? My comprehension reached its limit when the paper started talking about fraud proofs for the validity of extended data... 08:13 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 08:13 < gmaxwell> I don't think it makes it any more viable than they were in 2015: The coding based anticensorship isn't that strong an improvement: you end up having to send a lot of data to only get a moderately high confidence that the block is actually recoverable. 08:14 < gmaxwell> if its viable depends on if you consider the resulting parameters useful. 08:15 -!- p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] has quit [Ping timeout: 244 seconds] 08:17 < RubenSomsen> I see, I have no idea how much data it is, but it seemed problematic to me that light clients need to fetch more data just to make sure the extended data is in order 08:18 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #bitcoin-wizards 08:19 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving] 08:23 -!- rmwb [~rmwb@199.178.233.220.static.exetel.com.au] has joined #bitcoin-wizards 08:27 -!- p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] has joined #bitcoin-wizards 08:40 -!- _tin [~tyn@c-73-222-144-23.hsd1.ca.comcast.net] has joined #bitcoin-wizards 08:40 -!- rmwb [~rmwb@199.178.233.220.static.exetel.com.au] has quit [Ping timeout: 252 seconds] 08:40 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards 08:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 08:45 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 08:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 09:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 09:03 -!- enemabandit [~enemaband@188.37.227.185] has quit [Ping timeout: 245 seconds] 09:03 -!- enemabandit [~enemaband@188.37.227.185] has quit [Ping timeout: 245 seconds] 09:03 -!- enemabandit [~enemaband@188.37.227.185] has quit [Ping timeout: 245 seconds] 09:06 < musalbas> gmaxwell, we do mention some of the bitcoin discussions in the related work section. the paper however is a preprint and thus comments are welcome. thanks for your feedback, and pointers to related discussions. i will see if i can cite lines of irc chat logs in the bibliography; i was not aware of them. 09:12 < musalbas> >you end up having to send a lot of data to only get a moderately high confidence that the block is actually recoverable. 09:12 < musalbas> In section 5.6 and 6, we discuss the amount of data that needs to be sent, and the confidence that you have 09:13 < musalbas> "Figure 6 shows how this probability varies with s samples for k = 32 and k = 256; each light client samples at least one unavailable share with about 60% probability after 3 samplings (i.e., after querying respectively 0.07% of the block shares for k = 32 and 0.001% of the block shares for k = 256), and with more than 99% probability after 15 samplings (i.e., after querying respectively 0.4% of the block shares for k = 16 and 0.005% of 09:13 < musalbas> the block shares for k = 256). Figure 7 shows that light clients would have to download about 3.6 KB of shares to be able to detect incomplete blocks with more than 99% probability for k = 32, and about 57 bytes of shares for k = 256." 09:13 < musalbas> Some may consider 99% to be too low -- if you want 99.99% you need 30 samples 09:13 < gmaxwell> That sounds right. 09:16 < musalbas> (you can also increase the probability significantly by reducing the message/error-bits ratio; but then you need more light clients in the network to do the sampling.) 09:17 < gmaxwell> One concept we'd talked about before was having a designated source, e.g. a partcular origin that guarentees to make the data available. If your sampling fails, you tell friends about it (rate limited by coin ownership or POW) and they can attempt the same same sampling. The result was that the dishonest origin could never serve more than O(blocksize) worth of data to all clients before having 09:17 < gmaxwell> to stop serving entirely, or have the bad data be detectable. But that particular guarentee required, AFAICT, a designated origin. 09:18 < gmaxwell> musalbas: I think it's important to distinguish the confidence you get from your sampling alone, vs the confidence a network of honest nodes get assuming you aren't partitioned from it. The latter is obviously a lot more powerful, but it requires a stronger assumption that you're able to communicate with these honest peers. 09:19 < gmaxwell> any kind of fraud proof idea needs _some_ anti-partitioning assumption, but it's better if its the weakest assuption we can get. 09:21 < musalbas> Re designated source: this seems vulnerable to the fisherman's dilemma (see: https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding), unless that source is trusted, which kind of defeats the purpose 09:21 < musalbas> gmaxwell, indeed - we assume that light clients are connected to at least one honest node; and each honest node is connected to at least one other honest node 09:29 < gmaxwell> musalbas: the argument there seems to be without the erasure coding. We had suggested designated source (e.g. the miner) with erasure coding, as an extra step so that instead of a probablistic fault, either the block could be recovered or everyone doesn't accept that block. 09:31 < gmaxwell> musalbas: re: "we assume that light clients are connected to at least one honest node" I'm referring to things like the statement in your must recent link "you need ~1140 light clients to make up for overlap" -- that there needs to be some large number of lite clients which you are honestly connected to, to achieve a given probablity. 09:32 < musalbas> gmaxwell, what prevents me from Sybil attacking the network to tell everyone that all the samples are unavailable, but when they check them they actually are available, thus forcing people to download the whole block for no reason? 09:32 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds] 09:33 < musalbas> gmaxwell, re: overlap, that's correct - Table 1 in the paper analyses how many light clients you need for this overlap for various block sizes and sample sizes. 09:33 < musalbas> oh, you mean you think you have to be connected yourself to all those 1140 light clients? 09:34 < musalbas> not necessarily - those light clients can gossip shares to all the full nodes that they are connected to if the full nodes ask for them, and those full nodes can further gossip the shares with each other 09:35 < musalbas> (hence the assumption of the honest full nodes of the network not being partitioned) 09:35 < gmaxwell> musalbas: in that model, because the requests are rate limited (by pos or pow). Sorry if I've sent us on a tangent: I wasn't saying we thought it was an acceptable tradeoff, quite the opposite. We also encountered the really strong anti-partitioning assumption, and the best we could do to improve it was designated source, but it wasn't attractive because you could dos attack it. 09:36 < gmaxwell> musalbas: by honestly connected, I mean that there must be a graph of node connections with a connected component of all honest nodes containing them. 09:37 < musalbas> why do you think anti-partitioning is an overly strong assumption? 09:39 < musalbas> re: rate limiting, that seems antithetical to the security of the scheme - you want as many as light clients as possible to sample for requests ideally so that they can all get some assurance 09:40 < nsh> (rate limiting is essential because resource exhaustion is one of the many things that enable partitioning attacks, which are the scourge of distributed systems in adversarial settings generally) 09:40 < nsh> minimising assumptions about network topology is standard best practice 09:40 < musalbas> nsh: that doesn't seem to be a problem specific to fraud proofs then; might want to rate limit how much light clients can ask for transactions from full nodes etc 09:41 < gmaxwell> To be clear: any kind of fraud proof requires SOME kind of anti-partitioning assumption, so I'm not saying all anti-partitioning is too strong. E.g. the basic assumption needed is that there is a connected honest graph between you and some honest full node. But partitioning attacks are real and easy. Especially in a decenteralized network: See, e.g. the lit on eclipse attacks. For all systems 09:41 < gmaxwell> your ISP has the ability to pretty freely control who you connect to, etc. 09:41 * nsh nods 09:42 < treyzania> ^ that's why having multiple ISPs is nice 09:42 < musalbas> that is the assumption that we make (i.e. your node isn't under an eclipse attack, which even full nodes rely on this assumption) 09:43 < gmaxwell> so what nsh was saying, minimizing assumptions and making the assumptions that exist super clear is important. I haven't read the entire paper carefully enough to know if you did that yet, sorry! :) at least glacing at your graphs and such it wasn't clear to me what percentage detections depended on what assumptions about connections to how many honest nodes. 09:43 < gmaxwell> musalbas: EEEEE.. be really careful with "which even full nodes rely on this assumption". To the extent thats true, a full node will NEVER accept a rules violation. 09:43 < musalbas> yes, but i mean the full node could be on the wrong chain 09:43 < musalbas> if under an eclipse attack 09:44 < gmaxwell> Yes, but that changes the costs and incentives, potentially dramatically. 09:45 < musalbas> yeah. so if you eclipse attack a light client under this model, they wouldn't be able to receive fraud proofs ofc 09:45 < musalbas> the assumption we make is basically that all nodes aren't under an eclipse attack 09:46 < musalbas> or the 'honest' nodes aren't, that is 09:46 < musalbas> (ofc some of them will be; and they can't benefit from fraud proofs) 09:49 < gmaxwell> Right, and so assuming an attacker can mine an invalid block and eclipse attack users, what is the probablity of them tricking any one of many targets which they are also able temporarily partition from some of the honest network? 09:51 < gmaxwell> Really where we failed to advance the idea was just that... if an attacker just served up to the pooint they would have gotten caught, they'd be able to satisify a large number of clients before anyone could tell there was fraud. Far fewer than without the erasure coding, but still probably enough to hit every interesting victim with pretty high probablity. 09:51 < musalbas> if by 'temporarily partition' you mean you're partitioning entire subgraphs of the network, rather than individual nodes, then that would depend on how many light clients there are in the network and if there are enough of them to sample all the chunks 09:51 < musalbas> how many light clients there are in the partitioned network* 09:53 < gmaxwell> Yes. a point on terminology, when you say that a node isn't eclipsed to me 'eclipse attack' means that it connects entirely to attacker nodes. But what you actually require is stronger than 'not eclipsed' you require that it be connected to a subgraph of honest nodes of at least some sufficient size. 09:53 < musalbas> gmaxwell, ah, so you should also check out section 5.4; we also describe a potential but optional 'enhanced network model' that gives improved guarantees: basically you send the sample requests through a mix net, and assuming that the requests are received in a uniformly random manner, then the adversary cannot fool the first 1129 clients; they have to fool all or none 09:54 < musalbas> (it doesn't really have to be a mix net; you can just introduce an implicit delay on the client-side) 09:55 < gmaxwell> That sounds interesting! 09:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 09:56 < musalbas> (hmm actually you need to need a mix net, or onion routing at least, so that the requests are anonymous) 09:58 < gmaxwell> I think there were three things the limited out excitement about error-coded-sampled-anti-withholding: (1) it had really strong anti-partitioning assumptions (stronger than 'you are honestly connected to one honest node'), (2) that a trickle attacker could still fool a very large number of hosts (even though they'd have to stop after that number, rather than it being unbounded like the uncoded 09:58 < gmaxwell> case), (3) actually implementing it far enough to get concrete numbers was a lot of work for unclear benefits. 09:58 < gmaxwell> You clearly solved (3). :) sounds like you might have an improvement for (2). 10:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 10:00 < gmaxwell> re correlating peers, I just assumed that the code was rateless. (uh, the great things you can do when not actually talking in terms of a concrete construction) 10:00 < musalbas> the main performance bottleneck we found was doing the Reed-Solomon encoding; however using libs that take advantage of SIMD instruction set, we were able to get in the in milliseconds, but it could be even lower by 10:02 < gmaxwell> musalbas: re: FFT, https://github.com/catid/leopard/ uses the 'additive fft' to get state of the art performance even for very small problems. 10:02 < musalbas> yeah, i was trying to create a Go wrapper for that library to use in our implementation which is in Go (https://github.com/musalbas/rsmt2d) 10:02 < musalbas> but didn't finish 10:03 < gmaxwell> I assume you don't have to deal with errors, only erasures, because the miner commits to the shares, and if any set of shares is inconsistent that just means the block is invalid. 10:04 < musalbas> yeah that's right; if the any shares are inconsistent, they don't match the merkle root for that row/column 10:04 < musalbas> in which case a fraud proof of that will be generated 10:04 < musalbas> (section 5.5) 10:06 < gmaxwell> (I only ask just because it means you don't need to use a code where error decoding is computationally tractable, but you were using one where it is) 10:06 -!- shesek [~shesek@5.102.198.243] has joined #bitcoin-wizards 10:06 -!- shesek [~shesek@5.102.198.243] has quit [Changing host] 10:06 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-wizards 10:07 < musalbas> yeah, we could probably generalise it a bit more and say we don't have to use Reed-Solomon coding but any similar code 10:07 < musalbas> that supports erasures 10:09 < gmaxwell> You don't need an MDS code either. 10:10 -!- dougsland [~douglas@c-24-34-137-83.hsd1.nh.comcast.net] has quit [Ping timeout: 240 seconds] 10:10 < gmaxwell> It only matters because RS codes have traditionally been far from the state of the art in erasure code computational performance on actual hardware, because field arith is slow. ( leopard maybe signaling a bit of a counter example for a useful code size, but thats somewhat dicy ) 10:10 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-wizards 10:11 < gmaxwell> in any case, not actually important. 10:14 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 10:23 -!- _tin [~tyn@c-73-222-144-23.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] 10:27 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has joined #bitcoin-wizards 10:39 -!- rmwb [~rmwb@199.178.233.220.static.exetel.com.au] has joined #bitcoin-wizards 10:44 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Remote host closed the connection] 10:44 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-wizards 10:47 < gmaxwell> musalbas: ah your fix for (2) can just be stated as if the users anonymously interleave their sampling, then it isn't likely that the attacker could satisify many users without giving themselves away. This works better if there are more samples. If there are only a few samples per user, there could still be decent odds that some fraction get satisfied. 18:21 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has joined #bitcoin-wizards 18:21 -!- 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 18:21 -!- Topic set by sipa [~pw@unaffiliated/sipa1024] [Thu Oct 29 17:53:34 2015] 18:21 [Users #bitcoin-wizards] 18:21 [@ChanServ ] [ ChristopherA_ ] [ Giszmo ] [ jrayhawk ] [ nejon ] [ skeees ] 18:21 [ [d__d] ] [ CodeShark ] [ gmaxwell ] [ kallewoof ] [ nephyrin ] [ sn0wmonster ] 18:21 [ _Iriez ] [ comboy ] [ gnusha ] [ kanzure ] [ newbie-- ] [ so ] 18:21 [ _tin ] [ copumpkin ] [ go1111111 ] [ kenshi84 ] [ nickler ] [ spinza ] 18:21 [ _whitelogger ] [ Cory ] [ gribble ] [ kewde[m] ] [ NicolasDorier_] [ starsoccer ] 18:21 [ a5m0 ] [ CubicEarth ] [ Guest77842 ] [ keymone ] [ niftynei ] [ stevenroose ] 18:21 [ achow101 ] [ da2ce7 ] [ Guest78471 ] [ kinlo ] [ nikuhodai ] [ stiell ] 18:21 [ adam3us ] [ dabura667 ] [ Guest79090 ] [ kisspunch ] [ nsh ] [ suraeNoether] 18:21 [ adiabat ] [ davec ] [ Gurgulor ] [ koshii ] [ nuncanada ] [ Taek ] 18:21 [ adlai ] [ dbarrett ] [ gwillen ] [ Lightsword ] [ OhGodAGirl ] [ takinbo ] 18:21 [ AdrianG ] [ dcousens ] [ hardforkthis ] [ Logicwax ] [ opdenkamp ] [ TheoStorm ] 18:21 [ aguycalled ] [ dEBRUYNE ] [ harding ] [ luke-jr ] [ osue ] [ ThisAsYou ] 18:21 [ aj ] [ detoo ] [ harrigan ] [ luny ] [ othe_ ] [ thom ] 18:21 [ Alanius ] [ deusexbeer ] [ harrow ] [ maaku ] [ otoburb ] [ tombusby ] 18:21 [ Anduck ] [ devrandom ] [ havik ] [ maluk ] [ p0nziph0ne ] [ treyzania ] 18:21 [ andytoshi ] [ dgenr8 ] [ helo ] [ MarcoFalke ] [ petertodd ] [ triazo ] 18:21 [ antanst ] [ djhoulihan ] [ Herka ] [ mariorz ] [ phantomcircuit] [ tromp ] 18:21 [ Apocalyptic ] [ dlb76 ] [ herzmeister[m] ] [ markus-k ] [ pigeons ] [ trotski2000 ] 18:21 [ arubi ] [ DougieBot5000 ] [ hkjn0 ] [ mdrollette ] [ prod_ ] [ tuxcanfly ] 18:21 [ asoltys ] [ Dyaheon ] [ HSF_Prince_Loaf] [ meeh ] [ PsychoticBoy_ ] [ uiuc-slack ] 18:21 [ aspect_ ] [ e4xit ] [ Hunger- ] [ meshcollider ] [ qawap ] [ Varunram ] 18:21 [ azdrianz[m] ] [ echonaut11 ] [ huseby ] [ midnightmagic] [ real_or_random] [ vdo ] 18:21 [ BCBot ] [ Eliel ] [ ibrightly ] [ misalias ] [ rh0nj ] [ victorSN ] 18:21 [ Belkaar ] [ Emcy ] [ IGHOR ] [ mn3monic ] [ rmwb ] [ vtnerd ] 18:21 [ berndj ] [ emzy ] [ instagibbs ] [ mol ] [ roasbeef ] [ warren_ ] 18:21 [ betawaffle ] [ endogenic ] [ intcat ] [ moneyball ] [ robogoat ] [ waxwing ] 18:21 [ bildramer ] [ ensign ] [ Intensity ] [ Monthrect ] [ rockhouse ] [ wbnns_ ] 18:21 [ bitconner ] [ epscy ] [ isis ] [ morcos ] [ roconnor ] [ windsok ] 18:21 [ bitjedi ] [ eragmus ] [ Jaamg_ ] [ mr_burdell ] [ rodarmor ] [ wizkid057 ] 18:21 [ BlueMatt ] [ esotericnonsense] [ jamesob ] [ mrd0ll4r ] [ rotarydialer ] [ worstadmin ] 18:21 [ brianhoffman ] [ espes__ ] [ jaromil ] [ mryandao ] [ runeks ] [ wpaulino ] 18:21 [ bsm117532 ] [ fkinglag ] [ Jbaczuk ] [ mthiel ] [ ryanofsky ] [ wraithm ] 18:21 [ cannedprimates ] [ fletom ] [ jbenet ] [ murchandamus1] [ s0ph1a ] [ x-warrior_ ] 18:21 [ cdecker ] [ fluffypony ] [ jcorgan ] [ musalbas ] [ sarang ] [ yokwe__ ] 18:21 [ cfields ] [ fronti ] [ Jeremy_Rand[m] ] [ nanotube ] [ scoobybejesus ] [ yoleaux ] 18:21 [ CheckDavid ] [ GAit ] [ jimpo ] [ napo1eon ] [ sdaftuar ] [ yongu ] 18:21 [ Chex ] [ gazab1 ] [ jl2012 ] [ Nebraskka ] [ selsta ] [ Zenton ] 18:21 [ chjj ] [ gertjaap ] [ jnewbery ] [ neha___ ] [ shesek ] [ zmanian ] 18:21 [ Chris_Stewart_5] [ ghost43 ] [ jonasschnelli ] [ nehan ] [ sipa ] 18:21 -!- Irssi: #bitcoin-wizards: Total of 233 nicks [1 ops, 0 halfops, 0 voices, 232 normal] 18:21 -!- Channel #bitcoin-wizards created Mon Feb 25 23:24:47 2013 18:21 -!- Irssi: Join to #bitcoin-wizards was synced in 37 secs 18:29 -!- rmwb [~rmwb@199.178.233.220.static.exetel.com.au] has quit [Remote host closed the connection] 18:30 -!- rmwb [~rmwb@199.178.233.220.static.exetel.com.au] has joined #bitcoin-wizards 18:38 -!- TheoStorm [~dnaleor@host-lzquwqj.cbn1.zeelandnet.nl] has quit [Ping timeout: 244 seconds] 18:46 -!- mn3monic [jsz@unaffiliated/mn3monic] has quit [Excess Flood] 18:46 -!- mn3monic [jsz@unaffiliated/mn3monic] has joined #bitcoin-wizards 18:49 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 240 seconds] 18:50 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-wizards 18:51 -!- TheoStorm [~dnaleor@host-lzquwqj.cbn1.zeelandnet.nl] has joined #bitcoin-wizards 19:05 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has quit [Ping timeout: 240 seconds] 19:07 -!- Belkaar [~Belkaar@xdsl-78-35-86-46.netcologne.de] has joined #bitcoin-wizards 19:07 -!- Belkaar [~Belkaar@xdsl-78-35-86-46.netcologne.de] has quit [Changing host] 19:07 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards 19:09 -!- TheoStorm [~dnaleor@host-lzquwqj.cbn1.zeelandnet.nl] has quit [Ping timeout: 260 seconds] 19:13 -!- TheoStorm [~dnaleor@host-lzquwqj.cbn1.zeelandnet.nl] has joined #bitcoin-wizards 19:23 -!- TheoStorm [~dnaleor@host-lzquwqj.cbn1.zeelandnet.nl] has quit [Ping timeout: 240 seconds] 19:24 -!- rmwb [~rmwb@199.178.233.220.static.exetel.com.au] has quit [Remote host closed the connection] 19:32 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Read error: Connection reset by peer] 19:32 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-wizards 19:33 -!- CheckDavid [uid14990@gateway/web/irccloud.com/x-lzevnyflqfbxxfsu] has quit [Quit: Connection closed for inactivity] 19:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 19:37 -!- TheoStorm [~dnaleor@host-lzquwqj.cbn1.zeelandnet.nl] has joined #bitcoin-wizards 19:46 -!- RubenSomsen [uid301948@gateway/web/irccloud.com/x-kwawyqdpwqajoohx] has joined #bitcoin-wizards 19:53 -!- TheoStorm [~dnaleor@host-lzquwqj.cbn1.zeelandnet.nl] has quit [Ping timeout: 252 seconds] 19:58 -!- _tin [~tyn@104-56-112-203.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds] 20:04 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 245 seconds] 20:06 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 245 seconds] 20:07 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-wizards 20:18 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has joined #bitcoin-wizards 20:18 -!- 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 20:18 -!- Topic set by sipa [~pw@unaffiliated/sipa1024] [Thu Oct 29 17:53:34 2015] 20:18 [Users #bitcoin-wizards] 20:18 [@ChanServ ] [ comboy ] [ gnusha ] [ kallewoof ] [ nejon ] [ sipa ] 20:18 [ [d__d] ] [ copumpkin ] [ go1111111 ] [ kanzure ] [ nephyrin ] [ skeees ] 20:18 [ _Iriez ] [ Cory ] [ gribble ] [ kenshi84 ] [ newbie-- ] [ sn0wmonster ] 20:18 [ _whitelogger ] [ CubicEarth ] [ Guest77842 ] [ kewde[m] ] [ nickler ] [ so ] 20:18 [ a5m0 ] [ da2ce7 ] [ Guest78471 ] [ keymone ] [ NicolasDorier_] [ spinza ] 20:18 [ achow101 ] [ dabura667 ] [ Guest79090 ] [ kinlo ] [ niftynei ] [ starsoccer ] 20:18 [ adam3us ] [ davec ] [ Gurgulor ] [ kisspunch ] [ nikuhodai ] [ stevenroose ] 20:18 [ adiabat ] [ dbarrett ] [ gwillen ] [ koshii ] [ nsh ] [ stiell ] 20:18 [ adlai ] [ dcousens ] [ hardforkthis ] [ Lightsword ] [ nuncanada ] [ suraeNoether] 20:18 [ AdrianG ] [ dEBRUYNE ] [ harding ] [ Logicwax ] [ OhGodAGirl ] [ Taek ] 20:18 [ aguycalled ] [ detoo ] [ harrigan ] [ luke-jr ] [ opdenkamp ] [ takinbo ] 20:18 [ aj ] [ deusexbeer ] [ harrow ] [ luny ] [ osue ] [ ThisAsYou ] 20:18 [ Alanius ] [ devrandom ] [ havik ] [ maaku ] [ othe_ ] [ thom ] 20:18 [ Anduck ] [ dgenr8 ] [ helo ] [ maluk ] [ otoburb ] [ tombusby ] 20:18 [ andytoshi ] [ djhoulihan ] [ Herka ] [ MarcoFalke ] [ p0nziph0ne ] [ treyzania ] 20:18 [ antanst ] [ dlb76 ] [ herzmeister[m] ] [ mariorz ] [ petertodd ] [ triazo ] 20:18 [ Apocalyptic ] [ DougieBot5000 ] [ hkjn0 ] [ markus-k ] [ phantomcircuit] [ tromp ] 20:18 [ arubi ] [ Dyaheon ] [ HSF_Prince_Loaf] [ mdrollette ] [ pigeons ] [ trotski2000 ] 20:18 [ asoltys ] [ e4xit ] [ Hunger- ] [ meeh ] [ prod_ ] [ tuxcanfly ] 20:18 [ aspect_ ] [ echonaut11 ] [ huseby ] [ meshcollider ] [ PsychoticBoy_ ] [ uiuc-slack ] 20:18 [ azdrianz[m] ] [ Eliel ] [ ibrightly ] [ midnightmagic] [ qawap ] [ Varunram ] 20:18 [ BCBot ] [ emzy ] [ IGHOR ] [ misalias ] [ real_or_random] [ vdo ] 20:18 [ Belkaar ] [ endogenic ] [ instagibbs ] [ mn3monic ] [ rh0nj ] [ victorSN ] 20:18 [ berndj ] [ ensign ] [ intcat ] [ mol ] [ roasbeef ] [ vtnerd ] 20:18 [ betawaffle ] [ epscy ] [ Intensity ] [ moneyball ] [ robogoat ] [ warren_ ] 20:18 [ bildramer ] [ eragmus ] [ isis ] [ Monthrect ] [ rockhouse ] [ waxwing ] 20:18 [ bitconner ] [ esotericnonsense] [ Jaamg_ ] [ morcos ] [ roconnor ] [ wbnns_ ] 20:18 [ bitjedi ] [ espes__ ] [ jamesob ] [ mr_burdell ] [ rodarmor ] [ windsok ] 20:18 [ BlueMatt ] [ fkinglag ] [ jaromil ] [ mrd0ll4r ] [ rotarydialer ] [ wizkid057 ] 20:18 [ brianhoffman ] [ fletom ] [ Jbaczuk ] [ mryandao ] [ RubenSomsen ] [ worstadmin ] 20:18 [ bsm117532 ] [ fluffypony ] [ jbenet ] [ mthiel ] [ runeks ] [ wpaulino ] 20:18 [ cannedprimates] [ fronti ] [ jcorgan ] [ murchandamus1] [ ryanofsky ] [ wraithm ] 20:18 [ cdecker ] [ GAit ] [ Jeremy_Rand[m] ] [ musalbas ] [ s0ph1a ] [ x-warrior_ ] 20:18 [ cfields ] [ gazab1 ] [ jimpo ] [ nanotube ] [ sarang ] [ yokwe__ ] 20:18 [ Chex ] [ gertjaap ] [ jl2012 ] [ napo1eon ] [ scoobybejesus ] [ yoleaux ] 20:18 [ chjj ] [ ghost43 ] [ jnewbery ] [ Nebraskka ] [ sdaftuar ] [ yongu ] 20:18 [ ChristopherA_ ] [ Giszmo ] [ jonasschnelli ] [ neha___ ] [ selsta ] [ Zenton ] 20:18 [ CodeShark ] [ gmaxwell ] [ jrayhawk ] [ nehan ] [ shesek ] [ zmanian ] 20:18 -!- Irssi: #bitcoin-wizards: Total of 228 nicks [1 ops, 0 halfops, 0 voices, 227 normal] 20:18 -!- Channel #bitcoin-wizards created Mon Feb 25 23:24:47 2013 20:19 -!- Irssi: Join to #bitcoin-wizards was synced in 35 secs 20:19 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has left #bitcoin-wizards []