--- Log opened Sat Sep 05 00:00:01 2015 00:01 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 00:21 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 00:24 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 246 seconds] 00:51 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 00:59 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds] 01:03 -!- AlphaTech [AlphaTech@unaffiliated/alphatech] has joined #bitcoin-wizards 01:05 < wumpus> Luke-Jr: xpra does a pretty good job as a better network transparency layer for X, and sessions are re-attachable too 01:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nyydjfoklttsjwvt] has joined #bitcoin-wizards 01:14 -!- p15 [~p15@209.234.248.5] has quit [Max SendQ exceeded] 01:16 -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards 01:17 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards 01:17 -!- p15 [~p15@209.234.248.8] has joined #bitcoin-wizards 01:17 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 01:23 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 255 seconds] 01:29 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 01:29 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 01:37 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Read error: Connection reset by peer] 01:40 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 01:46 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards 02:03 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 02:13 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 244 seconds] 02:15 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards 02:16 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] 02:25 < heretolearn> mosh has issues with scrolling .. otherwise its nice 02:42 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 02:53 -!- binaryFate [~jeremie@joule.ulb.ac.be] has quit [Quit: Konversation terminated!] 02:55 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 265 seconds] 03:01 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #bitcoin-wizards 03:14 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 03:14 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 03:30 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards 03:32 -!- gielbier [~giel@a149043.upc-a.chello.nl] has quit [Read error: Connection reset by peer] 03:32 -!- gielbier [~giel@a149043.upc-a.chello.nl] has joined #bitcoin-wizards 03:42 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards 03:44 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] 03:45 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards 03:46 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Ping timeout: 250 seconds] 03:50 -!- GGuyZ_ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards 03:52 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Ping timeout: 260 seconds] 03:52 -!- GGuyZ_ is now known as GGuyZ 04:08 -!- PRab_ [~chatzilla@2601:40a:8000:8f9b:49d8:b6f:46db:e64d] has joined #bitcoin-wizards 04:09 -!- kaptah [kaptah@hilla.kapsi.fi] has quit [Ping timeout: 246 seconds] 04:09 -!- kaptah [kaptah@hilla.kapsi.fi] has joined #bitcoin-wizards 04:11 -!- PRab [~chatzilla@2601:40a:8000:8f9b:99a5:26ec:a97e:cce5] has quit [Ping timeout: 244 seconds] 04:11 -!- PRab_ is now known as PRab 04:11 -!- p15 [~p15@209.234.248.8] has quit [Ping timeout: 255 seconds] 04:18 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Ping timeout: 244 seconds] 04:21 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards 04:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 04:35 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Quit: Leaving] 04:45 -!- kang_ [67efe917@gateway/web/freenode/ip.103.239.233.23] has quit [Ping timeout: 246 seconds] 04:48 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 250 seconds] 04:49 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev] 04:49 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards 04:54 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 04:54 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 04:59 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 05:01 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards 05:08 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] 05:12 -!- AaronvanW [~ewout@178pc208.sshunet.nl] has joined #bitcoin-wizards 05:12 -!- AaronvanW [~ewout@178pc208.sshunet.nl] has quit [Changing host] 05:12 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 05:14 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards 05:26 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 264 seconds] 05:33 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards 05:35 -!- trippysalmon [~rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #bitcoin-wizards 05:36 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 05:40 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 05:43 -!- trippysalmon [~rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Read error: Connection reset by peer] 05:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] 05:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 05:55 -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has joined #bitcoin-wizards 06:00 -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has quit [Client Quit] 06:03 -!- eudoxia [~eudoxia@r167-56-99-88.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 06:06 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 06:06 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] 06:20 -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has joined #bitcoin-wizards 06:21 -!- kang_ [67efe936@gateway/web/freenode/ip.103.239.233.54] has joined #bitcoin-wizards 06:23 < kanzure> .title http://samvartaka.github.io/backdoors/2015/09/03/rsa-curve25519-backdoor/ 06:23 < yoleaux> Detecting an asymmetric Curve25519 backdoor in RSA key generation algorithms - samvartaka 06:29 -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has quit [Quit: Leaving] 06:31 < nsh> -- 06:31 < nsh> While it does guarantee confidentiality it does not, however, guarantee indistinguishability and as such can be discovered by a third party with blackbox access to a key generation algorithm suspected to be backdoored in this fashion. The reason why it does not guarantee indistinguishability (noted as well by De Gregorio) is because the ephemeral Curve25519 public key embedded in the public modulus of the backdoored RSA public key can be distinguished fr 06:31 < nsh> om a uniform random string. As noted elsewhere Curve25519 points can be distinguished from uniform random strings by virtue of the fact that they lie on the curve. Given a Curve25519 public key, which consists of the 256-bit x-coordinate of an (x,y) point on the curve, the probability that it is an x-coordinate corresponding to a valid curve-point is 1 while for a uniform random string this probability is 0.5. This thus allows for a distinguishing attack 06:31 < nsh> on part of a third party collecting n public keys generated by a blackbox key generation algorithm. 06:31 < nsh> -- i'm pretty sure you could overcome this with some kind of blinding 06:31 < nsh> or using djb-ish point-repre uniformisation technique 06:32 < nsh> .t https://www.imperialviolet.org/2013/12/25/elligator.html 06:32 < yoleaux> nsh: Sorry, I don't know a timezone by that name. 06:32 < nsh> .title https://www.imperialviolet.org/2013/12/25/elligator.html 06:32 < yoleaux> ImperialViolet - Implementing Elligator for Curve25519 06:32 < nsh> there we go 06:33 < nsh> sneakiness reestablished 06:35 -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has joined #bitcoin-wizards 06:36 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 272 seconds] 06:36 -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has quit [Client Quit] 06:37 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards 06:40 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards 06:42 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] 06:59 -!- eudoxia [~eudoxia@r167-56-99-88.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 07:02 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 07:02 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 07:05 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 07:15 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards 07:32 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards 07:33 -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has joined #bitcoin-wizards 07:37 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-pocaeshsqhpwydxp] has joined #bitcoin-wizards 07:46 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards 07:51 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 252 seconds] 07:53 < kang_> Why is a two-way peg better than atomic swap? 07:54 < Taek> kang_: with an atomic swap you have 2 different currencies 07:54 < Taek> with a two-way peg, it's the same currency on both blockchains 07:56 < kang_> That is because you are imagining atomic swap which is usually 2-party with side-peg which is done by an individual 07:56 < kang_> Try drawing both on paper, except the origin of coins, they both look same 07:59 < Taek> the origin of coins is what makes a two-way peg interesting 07:59 < Taek> after you've set up the two way peg, most transfers are typically going to be atomic swaps: atomic swaps are a lot cheaper to perform 07:59 < Taek> but a two way peg grants you a new power: you can move coins either direction between blockchains 08:00 < Taek> and so if you ever need a net flow in a direction, you can use a 2wp to achieve that 08:04 < kang_> Yes, theoretically I get that. But practically for a merchant accepting coins on a sidechain, swapped or pegged coins make no difference because they won't do so for miners either to retain their value. Wouldn't a btc bearing sidechain require equal subsidy for the coins to esentially be equally secure? 08:07 < Taek> depends on how the sidechain is set up, but generally speaking the btc on the sidechain are only as secure as the hashpower protecting the sidechain 08:07 < Taek> merge mining helps mitigate the security risk to some degree 08:07 -!- frankenmint [~frankenmi@71-222-57-192.ptld.qwest.net] has quit [] 08:10 < kanzure> "retain their value" well i think there's various weird arbitrage things you can do if for whatever reason the market seems to disagree about the physical equivalency 08:10 < kang_> Case 1: Sidechain has less network hashrate -> my coins are not secure, so i won't peg to it. Case 2: Sidechain has equal hashrate to btc -> sidechain scavenges btc's hashrate which is overall not less secure 'only if' that sidechain is 'exclusive' to btc 08:10 < kanzure> "i won't peg to it" what does this mean? you can't just wish the peg didn't exist. 08:10 < kang_> No I mean I won't use it 08:11 < kanzure> you should not be forced to use anything 08:11 < Taek> The only reason you'd use it in the first place is if it did something that you couldn't already do on the Bitcoin blockchain, e.g. Confidential Transactions 08:12 < kang_> I meant since it is a less secure chain, I'd better off using something with hasrate in between the two, like say litecoin 08:12 < Taek> you might be willing to accept the decreased security for the increased functionality 08:12 < kang_> Taek: I was considering the scalability use case 08:13 < kang_> Devs can see the scalability functionality but to a user, they won't compromise security for a good cause 08:13 < Taek> "I'd better off using... say litecoin" -> yes but then you aren't using the Bitcoin currency 08:14 < Taek> which means you are making a different set of tradeoffs 08:14 < kanzure> Taek: no there are other reasons, such as lower or different fees 08:14 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds] 08:14 < kanzure> kang_: i suspect that fee pressure might encourage users to choose different utxos on different chains http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html 08:15 < kang_> Taek: I think I am not able to explain, please bear. BTC has hashrate x, sidechain has y (yz>y) even if that means exchainging my coins cause it is no difference to value I am holding 08:16 -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has joined #bitcoin-wizards 08:16 < Taek> "no there are other reasons, such as lower or different fees" this is just semantics, but if you are using a sidechain for lower fees, it means that the bitcoin blockchain can't do transactions at the desired fee 08:17 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards 08:17 < kanzure> Taek: i was just commenting on "The only reason is... couldn't already do on the ... " phrase. 08:18 < kang_> kanzure: So we are saying people would prefer less fees over less security? 08:18 < kanzure> chains/ledgers with lower fees will probably have less security (although this is not guaranteed) 08:19 < Taek> kang_: some people will make that tradeoff, others won't 08:19 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards 08:19 < kanzure> i think you meant to ask "people would prefer less fees over more security?" 08:19 < kang_> yes, sorry 08:20 < kanzure> you could have also meant "people would prefer less fees even if it meant a lower-security consensus history?" 08:21 < kang_> Taek: what happens if most won't? Then sidechains would fail as a scalability solution? Or any scalability offered is good. 08:21 < kanzure> well, first, most fees are cleverly hidden from most users- by putting the fees on the merchants instead 08:22 < kanzure> but that's a pull system, not a push. dunno how the same trick works in a push system- maybe child-pays-for-parent-counts, but i sorta doubt it. 08:22 < kang_> That only changes the question to "would most merchants prefer cheaper transactions over secure ones?" 08:24 < kanzure> it's not really about transactions- it's about the cost of utxos once you want to create utxos 08:24 < kanzure> because channels can be kept open almost indefinitely 08:26 < kang_> Channels between? Addresses? IPs? Idefinitely open channels only make sense in case of recurring payment requirements like say sandglass type flowing microtransactions 08:26 < kanzure> "recurring payment requirements" sounds a lot like sending and receiving payments 08:27 < kang_> General trade is not repetitive. In real life I seldom deal with a person twice. 08:28 < kanzure> kang_: are you familiar with the lightning network? the proposal is a multi-hop hub-and-spoke network where you only need at least one channel connected to the broader network to do insta-payments to anyone on the network. 08:28 < kanzure> (using payment channels) 08:29 < kang_> Yes, but doesn't that require the network to be between something? Some unique identifier? 08:30 < kanzure> i don't understand 08:32 < kang_> Any network, to retain its topology would need a track of its members, no? If I understand correctly payment channels are between bitcoin addresses. If so, I am saying that I seldom pay someone that might be connected to my payment channel history 08:33 < kanzure> payment channels use many different bitcoin addresses during their operation 08:34 < kanzure> for an elaborate on-the-ground walkthrough of how payment channels work, see https://github.com/ElementsProject/lightning/blob/master/test-cli/scripts/test.sh 08:34 < kanzure> also https://lightning.network/lightning-network-paper.pdf 08:35 < kang_> Basically, every payment I make would always need a new hub everytime if it is a disconnected set of the network & that defeats the scalability 08:35 < kanzure> payment channels can be used for multiple payments 08:36 < kang_> I understand LN but haven't memorised the technical terms so am unclear. Sorry, I'll read and come back. 08:36 < kanzure> cool 08:41 < nsh> i understand nothing 08:49 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 08:50 < kanzure> nsh: trying to impress the monks? 08:50 * nsh smiles 09:13 -!- Mably [~Mably@unaffiliated/mably] has quit [Read error: Connection reset by peer] 09:21 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 09:23 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards 09:37 -!- adam3us [~Adium@88-105-23-239.dynamic.dsl.as9105.com] has joined #bitcoin-wizards 09:37 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 09:42 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 09:45 -!- adam3us [~Adium@88-105-23-239.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] 09:55 -!- davispuh [~quassel@212.93.100.199] has joined #bitcoin-wizards 09:59 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 10:03 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] 10:09 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 252 seconds] 10:13 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards 10:13 -!- AnoAnon [~AnoAnon@197.39.230.138] has joined #bitcoin-wizards 10:14 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards 10:15 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 10:18 -!- AnoAnon [~AnoAnon@197.39.230.138] has quit [Read error: Connection reset by peer] 10:33 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] 10:38 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards 10:40 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 252 seconds] 10:41 < kang_> So I revised LN and have the statement from the paper which I have a problem with, "By chaining together multiple micropayment channels, it is possible to create a network of transaction paths" 10:42 < CodeShark> what's your issue with it? 10:42 < kang_> If Alice needs to send coins to Dave, are we sure she would be able to find a path through a channel between Bob & Carol such that Alice->Bob->Carol->Dave 10:43 < kang_> I say that it would not always be able to find a path through the network of hubs 10:43 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] 10:44 < kang_> Is there any data that proves a pth would always exist? 10:44 < CodeShark> that depends on the routing protocol and the way channels are initally set up - which is not specified in the paper 10:45 < CodeShark> consider how bitcoin always finds paths between two nodes - but instead of a flood network, it's a routable protocol. nodes can create small channels with random peers as part of their initial setup 10:46 < CodeShark> it's certainly not a trivial problem - but I think the LN paper focuses more on the consensus layer 10:48 < kang_> Drawing a similarity with the network that is the internet, we are always able to find paths between ip addresses because of how ISP act as hubs for routing. For nodes to do the same 1. they would have to be somewhat permanent 2. Require extra work hence would need an incentive 3. Even then mostly would require a new last-mile channel setup 10:49 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 10:50 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 10:50 < CodeShark> yes, all good points 10:50 < CodeShark> there is an incentive, though 10:51 < CodeShark> 3. seems trickiest 10:51 < kang_> Yes, 1 and 2 are problems but seem solvable. My real problem is 3 10:51 < kang_> yes, that 10:51 < CodeShark> how can someone who has no coins join the network? 10:52 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-pocaeshsqhpwydxp] has quit [Quit: Connection closed for inactivity] 10:52 < CodeShark> there's always risk in taking on any unknown new node 10:52 < CodeShark> so new nodes might expect to pay most of the anchor transaction fees 10:52 < CodeShark> but they are also in the worst position to actually pay that 10:53 < kang_> Exactly such a someone is the last-mile that would need to setup a new channel with someone in the network, thereby defeating the cause 10:53 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 10:54 -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards 10:55 < CodeShark> heh - we might need extraprotocol creditors :p 10:55 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Remote host closed the connection] 10:56 < kang_> Sorry, didn't get you 10:57 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards 10:57 < CodeShark> I mean, it might be necessary to do risk assessment outside the protocol and front the newcomers something so they can join the network 10:58 < kanzure> yes there was discussion about fronting utxos for lightning network onboarding 10:58 < kanzure> i believe it was discussed in here between myself and rusty but maybe some other user 10:59 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 11:00 < kang_> Since i always use new addresses, (and almost always pay to a fresh address) it would always require setting up new last mile channels, hence of no-use 11:00 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] 11:01 < kang_> Infact, if both are new, rather 2 channels are required, which is actually worse 11:02 < kanzure> i don't think that the protocol requires address reuse 11:03 < kanzure> additionally, the final payments- however they hit the network- are not necessarily going to be using your utxos anyway. if you are worried about intermediate identification when doing payment routing, then use onion routing. 11:05 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards 11:05 < kang_> Can you direct me somewhere achieving path finding and channel chain setup 'without' address reuse, please? Cause i can't imagine how it can be done 11:05 < Taek> when you set up a set of payment channels,the public information is: 1. between who (at least, at the address level), and 2. which direction the money flows when the channel closes 11:06 < Taek> but if you combine them with CT, you can eliminate the information revealed about how full the channel is 11:06 < Taek> (sorry that was a separate thought not answering a question) 11:07 < kang_> Exactly, 'bitcoin address' is the token that identifies the nodes in an LN. If the token changes, a new channel with the existing network would be required 11:10 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 11:11 < kanzure> i don't think that node identification needs to use bitcoin addresses 11:12 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Quit: Konversation terminated!] 11:12 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards 11:13 < kang_> In any kind of a network, there has to be some identifier identifying every node as part of it 11:14 -!- adam3us [~Adium@88-105-23-239.dynamic.dsl.as9105.com] has joined #bitcoin-wizards 11:18 < CodeShark> it would be terribly unwise to couple transaction authorization too strongly with identity 11:18 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] 11:19 < CodeShark> identity could be managed via another crypto layer 11:19 < CodeShark> i.e. cryptographically generated routable addresses a la cjdns 11:20 < CodeShark> the keys used to sign contracts should be an entirely separate layer 11:21 < CodeShark> giving you the ability to easily rotate them, revoke them, etc... 11:21 < CodeShark> without having to touch the identity layer 11:23 < kang_> Even then, for every new party, we need a new connection in the identity layer. And I always want to be a new party 11:23 -!- hazirafel [~ufoinc@31.154.91.221] has quit [Ping timeout: 264 seconds] 11:24 < CodeShark> perhaps the onramp will have to involve paying fiat - or getting paid in bitcoin 11:25 < CodeShark> if someone wants to pay you in bitcoin, part of that payment could be put towards setting up a new channel 11:26 < CodeShark> or if you buy bitcoin for fiat, the seller could create a new channel with you 11:27 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 11:28 < CodeShark> you'd probably need to set up at least two channels if you want to be able to replenish your channels 11:28 < CodeShark> without closing them out 11:28 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards 11:29 -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has quit [Remote host closed the connection] 11:29 < CodeShark> best might be to create several channels with completely random peers as part of the initial setup 11:29 < kang_> Doesn't sound like utopian to you? 11:29 < CodeShark> where I draw the line is when it becomes economically unrealistic 11:30 < CodeShark> what I've said so far seems very economically realistic because the incentives are therre 11:30 < CodeShark> if we have to rely purely on people doing good favors and acting altruistically, then yes, it's unrealistic 11:31 -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has joined #bitcoin-wizards 11:33 < CodeShark> properly aligned incentives are key 11:34 < kang_> No even without it. For simplicity imagine there have been only 100 addresses on the blockchain yet with a LN mesh network among themselves & assume people using it stagnates. Now a new address asking for a payment needs a new connection. After a long time all the initial 100 will be replaced by n new addresses with amesh among themselves. Forever needing a new channel setup! 11:35 < kang_> Simply stating, each new address requires a new channel setup, forever! unless someone wants to reuse identity 11:35 < CodeShark> first of all, "addresses on the blockchain" don't really exist 11:36 < CodeShark> addresses are an application-level abstraction in bitcoin 11:36 < kang_> Yes, technically. But you get what i mean 11:37 < kang_> In the LN paper, Alice, Bob etc are addresses 11:37 < CodeShark> the use of the term "address" as in "Bitcoin address" is an unfortunate misnomer that causes a lot of confusion 11:38 < kang_> replace it with public keys 11:38 < CodeShark> because it really has little to do with things like IP addresses or email addresses (other than wallets making valiant efforts to equate the two when in fact they are very different) 11:38 < kang_> for simplicty 11:38 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 244 seconds] 11:39 < kanzure> huh it's not clear to me that in the lightning paper whether alice/bob are literal p2pkh addresses- i sort of doubt it 11:39 < CodeShark> most proposals I've seen don't even assume the signing keys used for contracts will ever be reused at all 11:39 < CodeShark> in fact, they might only be used once 11:40 < CodeShark> furthermore, they have nothing to do with message routing 11:41 < kang_> A "channel" is defined between two addresses. Can you confirm I am wrong about this? 11:42 < CodeShark> where "address" in this sense means something like an IP address? 11:42 < kang_> It means the bitcoin address exactly 11:42 < kanzure> hmm i guess it would be prudent to go look at what the protobuf definition of channel actually is 11:43 < kanzure> here is open_channel https://github.com/ElementsProject/lightning/blob/17471d0788ba14b83a88c8ef0d4e6b5944f3ae87/lightning.proto#L47 11:43 < CodeShark> hmm...I guess in rusty's implementation, a channel is identified by a pubkey used in the anchor transaction 11:44 < CodeShark> or not exactly... 11:44 -!- hazirafel [~ufoinc@31.154.91.2] has joined #bitcoin-wizards 11:45 < CodeShark> I think if we're going to associate channels with specific objects in the blockchain, they should be associated with the output of an anchor transaction 11:45 -!- hazirafel [~ufoinc@31.154.91.2] has quit [Read error: Connection reset by peer] 11:45 -!- adam3us [~Adium@88-105-23-239.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] 11:46 < CodeShark> the actual contract underlying that output is opaque to this layer 11:47 < CodeShark> the way the parties are able to spend the output is an entirely separate layer 11:50 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 11:52 < CodeShark> kang_: in the 5.9 version of the paper I don't see any mention of "address" referring to Alice and Bob 11:53 < CodeShark> in fact, it recommends the use of HD keys for transaction signing 11:53 < CodeShark> and as I said earlier, the paper does not specify the actual routing protocol at all 11:53 < CodeShark> just the commitment structures 11:55 < CodeShark> the use of the term "address" in the paper pertains to encoding of either p2pkh or p2sh 11:55 < CodeShark> and the p2sh addresses typically involve pubkeys from both parties 11:57 < kang_> Yes, the paper uses the term parties 12:00 < kang_> A party could be an address, a wallet, pubkeys whichever else identifier you want to use. 12:01 < kang_> Do you understand my concern? Or have been unable to show you the problem I see, yet? 12:02 < CodeShark> not really... 12:03 < CodeShark> I replaced the term "address" with "party" in your "For simplicity imagine" paragraph 12:03 < CodeShark> and I still am not sure I get your concern 12:03 < CodeShark> are you talking about having to close and reopen channels? 12:04 < kang_> A new 'party' entering the system, requires new 'channel' to be setup. Right? 12:04 < CodeShark> yes 12:04 < CodeShark> at least one - preferably more :) 12:05 < gmaxwell> kang_: privacy model in channels network is different (and usually much better) than bitcoin proper. As your key has primarly local significance (between you and the channel endpoint). 12:05 < gmaxwell> The system rusty has been working on is onion routed. 12:05 < kang_> Privacy I understand, but not scalability 12:06 -!- hazirafel [~ufoinc@31.154.91.2] has joined #bitcoin-wizards 12:07 < gmaxwell> I think you are drowning yourself in complexity. :) First you should go understand channel-less cut through transactions: https://bitcointalk.org/index.php?topic=281848.0 12:07 < kang_> I do understand 12:07 < gmaxwell> I am doubtful that you loaded that link and read it in under 10 seconds. :) 12:08 * kanzure lowers his raised hand 12:08 < kang_> No I read it yesterday through your reddit comment 12:08 < gmaxwell> OK 12:09 -!- hazirafel [~ufoinc@31.154.91.2] has quit [Read error: Connection reset by peer] 12:09 < gmaxwell> So then I do not see the point of your objection. 12:09 < kang_> My concern is that since each new party needs new channel setups, it is optimistic to assume that each new bitcoin user would need to set this up 12:09 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 12:10 < kanzure> one possible objection is somtehing like "intermediate history will never be cuttable, because outputs are never merged" or something.. 12:10 < kanzure> it's a weak objection, because outputs do get merged.. intermediate history can be cut. 12:11 < gmaxwell> kang_: to be a user of bitcoin at all, in any situation, requires a 'channel' of a kind in that you need to be paid bitcoin to begin with. It does not seem 'optimistic' to me to say that the same process instead can be establishing a channel. 12:11 < kang_> kanzure: About that gmaxwell wrote that he counted them earlier and there weren't many but now expects them to be significant. 12:11 < CodeShark> kang_: first of all, software would take care of this initial setup automatically for new users. secondly, the main concern surrounds the cost of opening up the new channel and who will cover it 12:12 < gmaxwell> kang_: that was because there were not many unconfirmed respends at all (bitcoin core won't make them except as a last resort and only of its own change). 12:12 < kanzure> if payments flow in a circle in a network, you can just cut out the entire circle. 12:13 < CodeShark> the main scalability optimizations are what kanzure just said...and the use of the blockchain ultimately as a last-resort settlement mechanism 12:14 < gmaxwell> The word settlement confuses people. 12:14 < gmaxwell> I've seen this happen over and over again. 12:14 < CodeShark> the blockchain is there to protect you in the event of an uncooperative counterparty 12:15 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Read error: Connection reset by peer] 12:15 < gmaxwell> A more useful mental model for the system is that the network is a trustworthy AI Judge that makes sure you complied with the contracts specified in your contracts. Now, it's possible to transact by taking every contract to the judge, but this is inefficient. 12:15 < kanzure> you also don't need a literal circle; i believe cut-through is achieved when you have alice pay 1000 bobs and all 1000 bobs pay carl. you don't need to put the bobs into the blockchain if everything is working. 12:15 < CodeShark> right, the blockchain is like a court 12:15 < CodeShark> you don't go to court over every contract you enter 12:15 < CodeShark> only the ones where there's a breach 12:16 < gmaxwell> So what protocols like channels, and coinswap do is set up their contracts so that you can go to court only in the event of a dispute or only for infrequent setup/shutdown. 12:16 < CodeShark> you'd much rather pry the counterparty into cooperation 12:17 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] 12:17 < CodeShark> if they continue to refuse to cooperate, then you go to the blockchain 12:17 < gmaxwell> And this is a forseen use of bitcoin since day 0, which is why, for example, we have serial numbers on txins and smart contracts instead of plain digital signatures. 12:17 < kang_> Every new user needs to sign up with the court, thats the problem 12:17 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 12:17 < kang_> But I get your point 12:17 < kanzure> yes it's true that there's a rate limit on the number of new (confirmed) utxos that can be created 12:18 < gmaxwell> kang_: Why is it a problem? Yes there is still capacity used... but then its proportional to new users rather than economic activity, and so it is enormously lower in volume. 12:19 < kang_> Because new users are indistinguishable. I prefer to appear a new user everytime 12:19 < gmaxwell> (there are way to actually even prevent enrollment, as kanzure notes about circles, but thats an edge case) 12:20 < kanzure> oh that prevents enrollment? 12:20 < gmaxwell> kang_: Thats where I commented on privacy above. With LN privacy and fungibility is achieved a different way, using onion routing and local significance. It's looks like it will be much more effective than pseudonymous addresses. 12:21 < gmaxwell> kanzure: it could, if you had an unenrolled user and can determine the funds would only move in a circle, you could avoid enrolling. 12:21 < gmaxwell> (or even not in a circule, if you determine the funds would just go enrolled->unenrolled->enrolled you can just cut out the unentrolled hop) 12:22 < gmaxwell> but I think it's not really an interesting case. 12:22 < kanzure> i was assuming enrolled intermediates- i mean just normal use of lightning causes these intermediates to not require confirmation in the blockchain. unenrolled case prolly loses some trustless properties or something- unless you're just asking them where they want to spend their money on their behalf or something. 12:23 < kanzure> yeah ok 12:24 < kanzure> i think cost of channel liquidity naturally causes each node to attempt abbreviation of transaction history through net re-balancing, it would be interesting to find whether such a local search method could find optimal rebalancing (e.g. be conservative and assume at some point everything will be dumped to blockchain; in the mean time you can rebalance and try to make the dump minimally painful, but can local nodes do that, or could ... 12:24 < gmaxwell> kanzure: any unentrolled party in that example is always dealing with unconfirmed txn. Like someone wants to pay you and they give you a transaction that would create a channel to do so (because you're unenrolled); but you hold onto it a bit instead (unconfirmed) and see if perhaps you're going to pay the whole value out to enrolled parties. And if so and if the penultimate hop is still online, 12:24 < kanzure> ... only something with access to the full graph/payments data for the whole lightning network?) 12:24 < gmaxwell> you can go cut out the enrollment. 12:24 < gmaxwell> But I think this is not so interesting, I'm just being pedantic. 12:25 < kang_> LN is then a mesh network between all parties using bitcoin ever 12:25 < CodeShark> gmaxwell: what's a better term to use rather than "settlement"? 12:26 < kanzure> "breach remedy" 12:26 < CodeShark> it's the term used both in finance and in law...but I guess breach remedy is more specific 12:26 -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has quit [Ping timeout: 268 seconds] 12:26 < CodeShark> or less ambiguous, at any rate 12:26 -!- ielo [~ielo@2601:643:8001:d531:48:48d5:a078:dd39] has joined #bitcoin-wizards 12:27 < CodeShark> but it sounds awkward :p 12:27 < kang_> My original concern was this, "Case 1: Sidechain has less network hashrate -> my coins are not secure, so i won't peg to it. Case 2: Sidechain has equal hashrate to btc -> sidechain scavenges btc's hashrate which is overall not less secure 'only if' that sidechain is 'exclusive' to btc" 12:27 < gmaxwell> kang_: and continuing my comment above, even with that you're still free to open many new channels... with the obvious cost of doing so, though there should be little to no need to even for good privacy/fungibility. But you could. Would people? Well in bitcoin not reusing addresses is free and reusing addresses is utterly destructive to privacy, and yet most txn are involved in address reuse. 12:27 < CodeShark> "the blockchain provides well-defined breach remedy guarantees" :) 12:28 < CodeShark> what about Case 3: Sidechain is merge-mined with btc :) 12:28 < kanzure> hashrate is not enough to know whether a chain is "secure" 12:28 < kang_> kanzure: total history of hashrates 12:29 < jtimon> kanzure any hasrate is "secure enough" if you are willing to wait enough blocks for confirmations, no? 12:29 < CodeShark> gmaxwell: that is not 100% true although close - not reusing addresses involves slightly greater overhead in key management 12:30 < CodeShark> and a more-than-insignificant complication in implementation 12:30 < kanzure> jtimon: security is a much broader perspective; you can have insanely high hashrates, but also have a mining cartel that commits fraud... now what? 12:30 < jtimon> and by any hashrate I mean any reward (subsidy + fees) 12:30 < kang_> CodeShark: Case 3 is same as 2 because merged mining means being exclusive to a blockchain 12:30 -!- ielo [~ielo@2601:643:8001:d531:48:48d5:a078:dd39] has left #bitcoin-wizards [] 12:30 < jtimon> kanzure: sure, I mean, for any definition of "secure enough" 12:31 < jtimon> kanzure: the attack costs grow exponentially with the number of block confirmations, don't they? 12:32 < jtimon> that's what I got from the whitepaper 12:32 < kang_> gmaxwell: My LN scalability doubts are resolved thanks. But they arose from me being redirected to LN from a doubt I asked about sidechains, mentioned above. 12:33 < kanzure> jtimon: yes yes, that's all accurate, but i think kang_ is asking about something else 12:33 < gmaxwell> Case 1: does that mean you stoped using bitcoin entirely the first moment the hashrate went down? :) 12:33 < kanzure> "i won't peg to it"- it's not up to you; you can choose whether you want to receive utxos on that sidechain, but the peg exists independent of your decision 12:34 < kang_> gmaxwell: If it goes below say litecoin, people would definitely switch over 12:34 < CodeShark> sometimes I wish we had something like BIP30 for scriptPubKeys :) 12:34 < dgenr8> kang_: so to your question of how to receive N payments without handing out the same identifier N times, you are satisfied with the answer "not that many people will see your identifier"? 12:34 < kanzure> kang_: what exactly are you comparing with litecoin? 12:35 < kang_> kanzure: "BTC has hashrate x, sidechain has y (yz>y) even if that means exchainging my coins cause it is no difference to value I am holding" 12:35 < gmaxwell> kang_: these things are completely incompariable. 12:36 < jtimon> kang_: not necesarily if all the merchants in my neighbourhood accept btc (but not ltc) but they switch from 6 to 10 confirmations, I will probably keep using btc or eur instead of ltc 12:36 < gmaxwell> Right now btc mining might even be using less power than ltc mining, and yet no one cares. 12:36 < gmaxwell> (there was a period before ltc mining moved to all asics where it probably was using more power than bitcoin mining) 12:36 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 12:37 < kang_> Surprising news to me! If so my questions are settled. 12:37 < jtimon> gmaxwell: the gpu-ltc times (supossedly imporssible accoring to LTC's initial announcement) 12:37 < gmaxwell> lol 12:37 < gmaxwell> Indeed. 12:38 < kanzure> concern about hashrate should be trumped by concerns about difficulty adjustments- if there's a difficulty gap, it might take a while to trigger the difficulty adjustment sufficiently downward. 12:38 < CodeShark> the irony is that the supposed strengths of scrypt over sha256 can't even be used in this context 12:38 < CodeShark> so they are entirely irrelevant 12:38 < kanzure> and your utxos wont be movable during that readjustment period 12:38 < kanzure> well, probably wont be movable 12:38 < gmaxwell> anyone know if there is a git setting to change the date format string? 12:38 < kanzure> GIT_COMMIT_DATE 12:39 < kang_> dgenr8: I am satisfied with the answer that a new user recieving btc needs a transaction on the blockchain which can be replaced by a channel setup transaction instead 12:39 < kanzure> oops 12:39 < kanzure> GIT_COMMITTER_DATE GIT_AUTHOR_DATE 12:39 < kanzure> nope i was right the first time. damn. 12:39 < jcorgan> i think those can be set in the environment 12:40 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 12:40 < kang_> Many people would be surprised! Is this calculated somewhere? BTC power used vs LTC power consumption? 12:40 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 12:40 < CodeShark> you can estimate the hash rates and then grab a napkin :) 12:40 < gmaxwell> kang_: I'm not aware of anywhere that does that! (and the paces that of charted BTC have done stupid stuff like assuming GPU usage long after thta was gone) 12:40 < CodeShark> each scrypt hash consumes more energy than each sha256 hash - so you need to account for that factor 12:41 < gmaxwell> kang_: which is part of why I was saying that no one cares. :( 12:41 < jtimon> unrelated: I'm thinking about writing a chain ID BIP: am I too crazy when I say "who cares about FTC for not having their own unique genesis block, they will have to use their second block as the genesis block, no big deal" Luke-Jr seems to disagree 12:41 < dgenr8> kang_: a new channel does require a blockchain tx. otherwise the whole thing can be double spent 12:42 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-wizards [] 12:42 < kang_> dgenr8: Yes , but the net broadcasted count is better over time so .. 12:42 * jtimon thows the rock and hides the hand: afk 12:45 < kang_> Is Peter Todd's calculation of >30% the counterargument to IBLT? 12:46 < kang_> Are there any other counterarguments to IBLT? 12:52 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards 12:57 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Ping timeout: 260 seconds] 12:58 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 12:59 < kang_> gmaxwell: I had independently thought of transaction cut-through. You rember I asked here a few weeks ago whether there exists a non-blockchain algo to assign ownership of a private key to another party? 13:00 < kang_> I have a proposal to actually reduce the blocksize, butit could be faulty hence asking about problems with IBLT proposal 13:03 -!- nwilcox [~nwilcox@24.130.26.146] has joined #bitcoin-wizards 13:14 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 255 seconds] 13:23 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 13:25 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 13:30 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards 13:31 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] 13:35 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 13:37 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 13:38 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards 13:39 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 255 seconds] 13:40 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] 13:40 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds] 13:45 -!- zooko [~user@2601:281:8301:e87f:c1ad:cbbb:a9a5:854e] has joined #bitcoin-wizards 13:47 -!- zooko [~user@2601:281:8301:e87f:c1ad:cbbb:a9a5:854e] has quit [Remote host closed the connection] 13:50 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds] 13:53 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 14:03 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-tdrnnewhwhlfisnc] has joined #bitcoin-wizards 14:04 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] 14:09 -!- GGuyZ [~GGuyZ@50.247.238.161] has joined #bitcoin-wizards 14:26 -!- ebfull [~ebfull@73.34.119.0] has quit [Quit: cya] 14:26 -!- ebfull [~ebfull@73.34.119.0] has joined #bitcoin-wizards 14:31 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 14:37 -!- GGuyZ [~GGuyZ@50.247.238.161] has quit [Quit: GGuyZ] 14:38 -!- kang_ [67efe936@gateway/web/freenode/ip.103.239.233.54] has quit [Quit: Page closed] 14:39 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:41 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards 14:44 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards 14:51 -!- nwilcox [~nwilcox@24.130.26.146] has quit [Ping timeout: 255 seconds] 14:55 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] 14:55 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 14:56 -!- samson_ [~samson_@unaffiliated/samson-/x-7479750] has joined #bitcoin-wizards 15:00 -!- twoone [~twoone@99-48-172-67.lightspeed.brhmmi.sbcglobal.net] has joined #bitcoin-wizards 15:18 -!- warptangent [~warptan@unaffiliated/warptangent] has quit [Read error: Connection reset by peer] 15:20 -!- warptangent [~warptan@unaffiliated/warptangent] has joined #bitcoin-wizards 15:20 -!- sausage_factory [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 15:21 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] 15:32 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards 15:34 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards 15:35 -!- nwilcox_ [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards 15:35 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Ping timeout: 244 seconds] 15:39 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 15:41 -!- nwilcox_ [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] 15:41 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] 15:42 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards 15:45 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards 15:45 -!- maaku is now known as Guest16294 15:45 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards 15:48 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 15:59 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards 16:05 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards 16:12 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 16:15 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 246 seconds] 16:15 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] 16:20 -!- samson_ [~samson_@unaffiliated/samson-/x-7479750] has quit [Ping timeout: 244 seconds] 16:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 16:32 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards 16:32 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 16:34 -!- sausage_factory [~priidu@unaffiliated/priidu] has quit [Ping timeout: 256 seconds] 16:37 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 16:42 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards 16:49 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 244 seconds] 16:51 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds] 16:55 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 17:04 -!- JayDugger1 [~jwdugger@108.19.186.58] has joined #bitcoin-wizards 17:06 -!- JayDugger [~jwdugger@108.19.186.58] has quit [Ping timeout: 250 seconds] 17:25 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 264 seconds] 17:28 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards 17:30 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 255 seconds] 17:32 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 17:33 -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] 17:35 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 17:36 -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [] 17:40 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds] 17:41 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 260 seconds] 17:43 -!- ne1l [~dnv@ip1f126621.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 17:45 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards 17:48 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 18:01 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 260 seconds] 18:03 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 18:03 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 18:06 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] 18:14 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 18:30 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 244 seconds] 18:30 -!- twoone [~twoone@99-48-172-67.lightspeed.brhmmi.sbcglobal.net] has quit [] 18:35 -!- ne1l [~dnv@ip1f126621.dynamic.kabel-deutschland.de] has quit [Quit: Ex-Chat] 18:35 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] 18:36 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 18:40 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nyydjfoklttsjwvt] has quit [Quit: Connection closed for inactivity] 18:41 -!- not_underground [~chatzilla@node-af9.pool-101-51.dynamic.totbb.net] has joined #bitcoin-wizards 18:50 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] 18:52 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards 19:02 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards 19:05 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [] 19:07 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards 19:30 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 19:30 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] 19:42 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-tdrnnewhwhlfisnc] has quit [Quit: Connection closed for inactivity] 19:53 -!- kang_ [67efe936@gateway/web/freenode/ip.103.239.233.54] has joined #bitcoin-wizards 20:05 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 20:11 -!- JayDugger1 [~jwdugger@108.19.186.58] has left #bitcoin-wizards [] 20:12 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] 20:12 -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards 20:15 -!- Guest16294 [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 20:24 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:26 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards 20:26 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 20:27 -!- maaku is now known as Guest82907 20:41 -!- davispuh [~quassel@212.93.100.199] has quit [Read error: Connection reset by peer] 20:43 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards 20:46 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 20:48 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards 21:01 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 21:16 -!- realcr [~real@bzq-79-178-30-92.red.bezeqint.net] has quit [Quit: WeeChat 0.4.2] 21:20 -!- GGuyZ_ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards 21:21 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Ping timeout: 250 seconds] 21:21 -!- GGuyZ_ is now known as GGuyZ 21:30 -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards 21:39 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] 21:43 -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds] 21:43 -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has quit [Quit: Leaving.] 21:47 -!- GGuyZ [~GGuyZ@216.15.123.91] has joined #bitcoin-wizards 21:56 -!- cryptowest [~cryptowes@2604:a880:800:10::81f:3001] has quit [K-Lined] 21:57 -!- cryptowest [~cryptowes@2604:a880:800:10::81f:3001] has joined #bitcoin-wizards 22:03 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 22:11 -!- c0rw1n is now known as greenBat 22:13 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] 22:13 -!- greenBat is now known as c0rw1n 22:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 244 seconds] 22:14 -!- c0rw1n is now known as c0rw|zZz 22:15 -!- drwin [~drwin@out-nat-33.jes.cz] has quit [Read error: No route to host] 22:15 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has quit [Quit: b_lumenkraft] 22:16 -!- drwin [~drwin@out-nat-33.jes.cz] has joined #bitcoin-wizards 22:25 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 22:27 < phantomcircuit> kang_, IBLT requires synchronized mempools 22:27 < phantomcircuit> which is generally a bad thing 22:37 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards 22:44 -!- GGuyZ [~GGuyZ@216.15.123.91] has quit [Ping timeout: 272 seconds] 22:55 -!- roxtrongo [~roxtrongo@190.22.139.129] has joined #bitcoin-wizards 22:57 -!- go1111111 [~go1111111@104.200.154.15] has quit [Ping timeout: 265 seconds] 23:00 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 23:03 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has quit [Quit: b_lumenkraft] 23:22 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-wizards 23:25 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 23:30 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards --- Log closed Sun Sep 06 00:00:02 2015