--- Day changed Tue Jul 04 2017 00:02 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 00:09 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 00:28 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] 00:39 -!- JackH [~laptop@46.231.18.66] has joined #lightning-dev 00:46 -!- cbits [~cbits@c-217-115-42-58.cust.bredband2.com] has joined #lightning-dev 01:15 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 01:44 -!- Ruben [~RubenSoms@1.217.138.142] has quit [Ping timeout: 255 seconds] 01:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-gcdietbnhcbyprsi] has quit [Quit: Connection closed for inactivity] 02:02 -!- Ruben [~RubenSoms@1.217.138.142] has joined #lightning-dev 02:24 -!- jannes [~jannes@178.132.211.90] has joined #lightning-dev 02:25 -!- knocte_ is now known as knocte 02:38 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 03:01 -!- Ruben [~RubenSoms@1.217.138.142] has quit [Ping timeout: 255 seconds] 03:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 03:13 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #lightning-dev 03:22 -!- cbits [~cbits@c-217-115-42-58.cust.bredband2.com] has quit [Ping timeout: 258 seconds] 03:24 -!- marcoagner [~user@179.177.245.203] has quit [Ping timeout: 268 seconds] 03:36 -!- marcoagner [~user@179.177.240.114] has joined #lightning-dev 03:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 03:52 -!- Ruben [~RubenSoms@1.217.138.142] has joined #lightning-dev 04:20 -!- cbits [~cbits@c-217-115-42-58.cust.bredband2.com] has joined #lightning-dev 04:34 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] 05:06 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 05:53 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 05:57 -!- pm [~pm@11.46-14-84.ripe.coltfrance.com] has joined #lightning-dev 06:21 -!- afdudley [afdudleyma@gateway/shell/matrix.org/x-gqmosivrrolyrvfp] has quit [Ping timeout: 276 seconds] 06:53 -!- afdudley [afdudleyma@gateway/shell/matrix.org/x-rirqupsvhwolkkoa] has joined #lightning-dev 06:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 07:00 -!- afdudley [afdudleyma@gateway/shell/matrix.org/x-rirqupsvhwolkkoa] has quit [Remote host closed the connection] 07:08 -!- afdudley [afdudleyma@gateway/shell/matrix.org/x-kcjtcjxpmhvatgnz] has joined #lightning-dev 07:29 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection] 07:30 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #lightning-dev 07:37 -!- Ruben [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds] 08:15 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 08:22 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Quit: .] 08:22 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Read error: Connection timed out] 08:23 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 08:23 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #lightning-dev 08:23 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 258 seconds] 08:36 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-plslwsjtqswytpri] has joined #lightning-dev 09:55 -!- cbits [~cbits@c-217-115-42-58.cust.bredband2.com] has quit [Ping timeout: 248 seconds] 10:36 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 10:38 -!- pm [~pm@11.46-14-84.ripe.coltfrance.com] has quit [Quit: Leaving] 11:03 -!- ajd_ [~Anthony@91.239.96.138] has joined #lightning-dev 11:44 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 11:44 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 11:52 < afdudley> In a payment channel, it's possible to have the payee just be any address, right? So, the only thing the payee needs to do is a publish the transaction? That doesn't make much sense... 11:55 < afdudley> I'm trying to figure out different ways of having a payments that are (A -> C) (B -> C) result in (A ->B) and B -> A) The only thing that makes sense to me is to create more payment channels with the (A -> B) (B ->) precommits that are prepared by C. 11:55 < afdudley> and conditional on channels with C failing. 11:55 < afdudley> Does that make any sense at all? 11:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-plslwsjtqswytpri] has quit [Quit: Connection closed for inactivity] 11:58 < afdudley> I guess if they were UTXOs on both sides this would be easier, but I'm trying to make this work between ethereum and bitcoin. 11:59 < afdudley> The precommits prepared by C would require some form of shared secrets AC and BC 12:07 < afdudley> The issue that I'm running into is C (or the first counter-party) can DoS at any time. 12:10 < afdudley> I guess if the exchange is for 100, C could put up 1 as collateral on both sides and then do multiple swaps for 1. 12:14 < afdudley> I guess lightning already solves this. 12:15 < afdudley> But with a bunch of stuff fixed that I think needs to be variable. 12:20 < cdecker> Sorry afdudley I don't follow what you're trying to achieve 12:20 < cdecker> Are you trying to use Lightning Channels to to cross chain swaps? 12:20 < afdudley> Sorry for thinking out loud. 12:20 < afdudley> Yes. 12:20 < cdecker> Ok, are the start and endpoint the same? 12:20 < afdudley> it's a sort of hub spoke thing. 12:21 < afdudley> I don't think so. 12:21 < cdecker> Ok 12:21 < afdudley> A -> C <- B 12:21 < afdudley> A has ETH, B has Bitcoin. 12:21 < afdudley> C has neither. 12:21 < cdecker> So you have A<->C (coin1) and C<->B (coin2)? 12:22 < cdecker> That won't work, C actually needs to have funds in one of the chains 12:22 < cdecker> (otherwise C cannot forward anything) 12:22 < afdudley> Okay, so C has 1/10th of both. 12:22 < afdudley> on each chain. 12:22 < afdudley> That's just normal lightning then, right? 12:22 < cdecker> Right 12:23 < cdecker> With 1/10th the maximum imbalance is just 1/10th 12:23 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection] 12:24 < afdudley> can everyone on the network see all the open channels? They need to for routing, right? 12:24 < cdecker> A could open a BTC channel directly to B and B could open an ETH with A and then they can do the atomic swap 12:24 < afdudley> so A can see the channel between C and B? 12:24 < cdecker> Yep, topology is currently assumed to be public 12:25 < afdudley> Can i adjust the exchange rate in an existing channel? 12:26 < cdecker> There is no concept of exchange rate on channels 12:26 < cdecker> It's C making up what it takes in on one side and sends out on the other 12:26 < cdecker> That's the closest we get to an exchange rate 12:29 < afdudley> oh, so A and B talk to C saying what exchange rates they want, then C tells B and A to connect with each and with what ratio. But there is no way to pre-define the route, right? 12:30 < afdudley> And C can't provide any guarantee that B or A will actually fill the order. 12:30 < afdudley> So, that won't work. 12:30 < cdecker> Right, C is totally useless in the scenario :-) 12:31 < cdecker> Just have a website where people can find each other ^^ 12:31 < afdudley> Well, the value C should provide is a guarantee of execution 12:31 < afdudley> That's what I was getting at with the conditional third channel. 12:32 < afdudley> basically the AC channel and the BC channel are collateral for the AB channel. 12:32 < cdecker> C can only guarantee an exchange rate if C is the one doing the conversion 12:32 < cdecker> That also requires that C has a sufficient balance on the destination currency 12:33 < cdecker> Then again that is also desirable 12:34 < afdudley> Do see what I'm getting at though? 12:35 < cdecker> If A is looking to exchange coin1 for coin2 and B the opposite then A routes coin1 to B and coin2 back to itself, if B complies and forwards the route back to A, then A has the guarantee of the exchange rate and the exchange is atomic 12:35 < afdudley> The problem is there is no reason for A to trust B will do that. 12:36 < afdudley> with no evidence that B has the funds. 12:36 < afdudley> (in ethereum this is all fairly trivial.) 12:36 < afdudley> (or Omni for that matter) 12:37 < afdudley> if C signed AC with C' and BC with C'' if C could trade those safely via some other construction, that would work too. 12:37 < afdudley> So that A ended up with C'' and B with C' 12:38 < afdudley> The problem is that's not atomic, but I feel like there must be a way to do that atomically. 12:42 < cdecker> The atomicity/security is given by having a single HTLC secret for both hops, I initiate an exchange routing through my counterparty and either I like what I get back (and activate it) or I don't, e.g., because exchange rate doesn't match, then I just fail the HTLC 12:43 < afdudley> yeah, thse aren't exchanges. Part of the issue is Lightning isn't for exchange... 12:44 < afdudley> Both sides should be able to pre-commit to an exchange with an unknown counterparty, find a counterparty, then execute the exchange they precommitted to. 12:45 < afdudley> given the constraints of existing bitcoin, both comitting to a bonded third-party works well enough for me. 12:45 < cdecker> Why? There is absolutely no trust involved in this 12:45 < afdudley> we are talking about two different types of trust. 12:46 < afdudley> You're saying the swap is atomic, but I want a stronger gurantee than that, as explained above. 12:47 < afdudley> when I say exchange above, i mean the verb, not the noun. 12:48 < afdudley> When A prepares the circuit in your example, that costs them time and assets, which B can just ignore, DoSing A. That's not acceptable. 12:50 < afdudley> The problem i'm trying to solve is the pre-commitment to executing the swap, not how to do the swap atomically. 12:54 < afdudley> Logically, C must be in the system, as a proxy for the pre-commit. Via some other method, C is committing to completing the crosses. C shouldn't need to hold significant assets to do this. as mentioned above. 12:58 < cdecker> Well at this point we have C that has to be trusted 12:59 < cdecker> DoSing is only a problem if B can waste A's resources repeatedly 12:59 < cdecker> The first time A may use B, and fail 12:59 < cdecker> It then looks for someone else to trade with 13:00 < cdecker> It would indeed be a problem if B could create sybils, repeatedly wasting A's attempts 13:00 < cdecker> But an entity in Lightning needs to open a channel before we even announce its existence to the rest of the world 13:00 < cdecker> And creating a channel is not free 13:02 < afdudley> The interesting part for me is that we are trust C to provide a very particular service that isn't really payments related but vital for exchange to work. I think it's fine that C is trusted, the point is to use cryptography to minimize that trust. 13:02 < afdudley> and to use the existance of payment channels as collateral, since I can't think of a better way. 13:04 < cdecker> I see that C has a reason to exist for price-finding, which is one of the services provided by today's exchanges, and indeed I don't know how one would implement that functionality with a p2p exchange using atomic swaps 13:06 < afdudley> Yeah, I think C needs to intermediate, but they can't be fully funding both sides of every exchange, for logical reasons. 13:07 < afdudley> So they just have to be trusted, but they put the bond into payment channel. and counterparties can negotiate that bond price. 13:08 < cdecker> I don't see how such an exchange (C) could possibly work, it has all the classic problems that hubs have, exacerbated by the fact that we're now handling multiple currencies 13:09 < afdudley> Can you expand on the classic problems bit, or at least link to them? 13:09 < cdecker> The exchange would have to allocate the maximum value that an endpoint might want to acquire for all currencies it trades 13:10 < afdudley> Yes, i'm saying instead of that they share a bond. 13:10 < afdudley> I've written a paper about it. but I'm not quite ready to share it completely :D 13:10 < cdecker> Ok, looking forward to reading it 13:10 < cdecker> :-D 13:11 < afdudley> The whole system works just fine with Ethereum based networks, but this issue that you're bringing up with Bitcoin has been bothering me. There are some answers, but they aren't pretty. 13:12 < afdudley> I take that back, I actually think they are quite pretty, they just aren't for crypto people :D 13:13 < cdecker> Lucky I'm a distributed systems guy then ^^ 13:17 < afdudley> :D 13:18 < afdudley> TL;DR is C is a federated PoS Blockchain and traders to Cross chain swap of BTC for BTC Vouchers. which sounds completely nuts, but then all the pre-committed atomic swap stuff works just fine. 13:19 < afdudley> The reason you trust C won't run away with your BTC, is you have a banking relationship with one of the validators in your jurisdiciton. 13:32 < afdudley> Obviously in that model, there can be a non-custodial BTC taker, but there would need to be some extra fees to offset the validator's intermediation risks. 13:41 -!- ajd_ [~Anthony@91.239.96.138] has quit [Read error: Connection reset by peer] 13:41 -!- ajd__ [~Anthony@91.239.96.138] has joined #lightning-dev 13:43 -!- ajd__ [~Anthony@91.239.96.138] has quit [Remote host closed the connection] 13:43 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 13:43 -!- ajd__ [~Anthony@91.239.96.138] has joined #lightning-dev 14:02 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 15:06 < renlord> afdudley: what even is the point then? its no different to a central hub with a trusted relationship. 15:14 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #lightning-dev 15:14 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection] 15:27 < afdudley> There are degrees of trust, it's not binary. 15:29 < afdudley> And it's not always completely transitive 15:32 < afdudley> So, there is value in minimizing the trust Bitcoin traders need to have with the exchange. Again worth mentioning, Ethereum-style networks don't have this problem and entity that is a validator on two ETH-nets could easily build the proofs across chains for this. 15:33 < afdudley> I'm pretty sure there is a way to get the correct precommits with little additional effort on BTC, but it's a real crypto problem. 15:34 < afdudley> Sorry, that was phrased poorly. The computational and engineering effort would be low, but the cryptographic engineering knowledge is beyond what I have. 16:24 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 248 seconds] 16:34 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #lightning-dev 17:01 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Max SendQ exceeded] 17:02 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #lightning-dev 17:07 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 17:09 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #lightning-dev 17:14 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 240 seconds] 17:19 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #lightning-dev 17:24 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 17:26 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #lightning-dev 18:07 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #lightning-dev 18:54 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 19:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 19:55 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #lightning-dev 19:56 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Remote host closed the connection] 19:57 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #lightning-dev 21:14 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has joined #lightning-dev 21:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 248 seconds] 22:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 23:33 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] 23:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tlnghsuuuvwhxnvn] has joined #lightning-dev 23:47 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds]