--- Day changed Thu May 18 2017 00:16 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 00:26 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] 01:09 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #lightning-dev 01:49 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 02:04 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 255 seconds] 02:51 -!- JackH [~laptop@85.219.170.195] has quit [Ping timeout: 240 seconds] 03:23 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 03:27 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 255 seconds] 03:40 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 03:44 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 04:18 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds] 04:19 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 04:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 04:31 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 04:48 -!- deusexbeer [~deusexbee@093-092-179-139-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev 05:09 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 05:16 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has joined #lightning-dev 06:04 -!- JackH [~laptop@85.219.170.195] has joined #lightning-dev 06:36 -lightningrfc:#lightning-dev- [lightning-rfc] EmelyanenkoK opened pull request #177: Delete obsolete reference to `padding` (master...patch-3) https://git.io/v9jfU 07:05 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:06 -!- moli_ [~molly@unaffiliated/molly] has joined #lightning-dev 08:31 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 08:35 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 08:46 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #lightning-dev 09:18 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds] 09:28 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 09:40 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 10:14 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 10:27 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:27 -!- Sprh [~Sprh@12.20.48.10] has joined #lightning-dev 11:53 -!- cbits [~cbits@2607:f380:a61:650:c501:b8be:44cd:f609] has joined #lightning-dev 12:18 -!- ajd_ [~Anthony@2001:470:daef:e1e1:27a3:b8c8:9db:79f6] has joined #lightning-dev 12:27 -!- deusexbeer [~deusexbee@093-092-179-139-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!] 13:16 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 272 seconds] 13:16 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has joined #lightning-dev 13:28 -!- cbits [~cbits@2607:f380:a61:650:c501:b8be:44cd:f609] has quit [Ping timeout: 245 seconds] 13:52 -!- cbits [~cbits@2607:f380:a61:650:b498:1928:6c6b:8ebb] has joined #lightning-dev 14:00 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 14:17 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 268 seconds] 14:19 -!- Sprh [~Sprh@12.20.48.10] has quit [Read error: Connection reset by peer] 15:11 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 15:29 -!- cbits [~cbits@2607:f380:a61:650:b498:1928:6c6b:8ebb] has quit [Ping timeout: 246 seconds] 16:19 -!- deusexbeer [~deusexbee@093-092-179-139-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev 16:27 -!- cbits [~cbits@74.111.203.68] has joined #lightning-dev 17:00 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:03 -!- deusexbeer [~deusexbee@093-092-179-139-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!] 17:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hsigmstpdaglfukl] has quit [Quit: Connection closed for inactivity] 17:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 17:52 -!- cbits [~cbits@74.111.203.68] has quit [Ping timeout: 260 seconds] 17:53 -!- cbits [~cbits@74.111.203.68] has joined #lightning-dev 18:14 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell closed pull request #177: Delete obsolete reference to `padding` (master...patch-3) https://git.io/v9jfU 18:17 -!- cbits [~cbits@74.111.203.68] has quit [Ping timeout: 260 seconds] 18:32 -!- cbits [~cbits@2607:f380:a61:650:5892:6331:9da1:dbaa] has joined #lightning-dev 18:43 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell pushed 4 new commits to master: https://git.io/vHvvU 18:43 -lightningrfc:#lightning-dev- lightning-rfc/master b7a90e7 pm47: added UPDATE flag to `temporary_channel_failure` 18:43 -lightningrfc:#lightning-dev- lightning-rfc/master c60e5e0 pm47: added a `channel_disabled` error message 18:43 -lightningrfc:#lightning-dev- lightning-rfc/master f7277ce sstone: BOLT 4: rationale for the last node's payload... 18:52 -!- JackH [~laptop@85.219.170.195] has quit [Ping timeout: 268 seconds] 18:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 19:14 -!- ThomasV_ [~ThomasV@x4db4c412.dyn.telefonica.de] has joined #lightning-dev 19:18 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 19:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 20:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 20:35 -!- cellvia [~ubuntu@ec2-13-58-66-215.us-east-2.compute.amazonaws.com] has joined #lightning-dev 20:39 -!- sh_smith [foobar@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev 21:01 < cellvia> is the lightning white paper the latest and greatest on the topic of lightning network? 21:01 < cellvia> https://lightning.network/lightning-network-paper.pdf 21:02 < ajd_> no 21:02 < cellvia> what should i be reading instead? 21:04 < rusty> cellvia: you could read the spec if you're feeling ambitious :) 21:04 < ajd_> I don't know, but what are you trying to do? 21:04 < rusty> https://github.com/lightningnetwork/lightning-rfc 21:04 < mryandao> lightning bolts. 21:05 < cellvia> understand it. the white paper, and videos ive seen leave me with more questions than answers 21:05 < cellvia> but im also very new to this field 21:06 < ajd_> https://medium.com/@rusty_lightning/the-bitcoin-lightning-spec-part-1-8-a7720fb1b4da was useful too; I'm not sure how out of date it is though 21:07 < cellvia> i think i get the basic idea, but im a little confused about how indefinitely deferring consensus wouldnt create a fragile consensus network 21:08 < rusty> cellvia: what level of detail are you after? 21:08 < cellvia> and i totally assume im missing something in that confusion. in the paper i read about timelocks, parent transaction, committment transaction, etc, but the way it was explained i just dont get how they all work together 21:09 < rusty> cellvia: there are two parts. The first is channels between peers, the second is routing between channels. 21:09 < cellvia> i guess i am frustrated that after watching a video and reading over the white paper i have barely a high level understanding, and the mid level is just totally blurry 21:09 < rusty> I think the best analogy for channels is the blockchain as a bank, and you open a dual-signatory account, then trade back and forth signed checks. 21:10 < cellvia> without cashing them , but keeping the balance? 21:10 < rusty> cellvia: knowing you can cash yours any time, with some hassle (visiting the bank/blockchain). 21:10 < cellvia> or cashing them but its really just allocating numbers, not actual cash-out 21:10 < cellvia> ok 21:10 < rusty> ie. sign the latest one, take to bank, done. 21:11 < rusty> Of course, you gotta make sure they don't use an old check! 21:11 < cellvia> so that part makes pretty easy sense 21:12 < cellvia> so isnt there some way that one of them could sign the latest check, then come to the blockchain and say heres this, the other person will present their older transaction... in this model they lose all their money to the newer transaction 21:12 < cellvia> essentially forge the "latest" transaction somehow 21:13 < cellvia> they are penalized for presenting the out of date transaction 21:13 < ajd_> https://rusty.ozlabs.org/?p=450 et. al. were good too. Again I'm not sure if it's out of date though. But understanding the historical development is useful too if you have enough time to study it. 21:13 < rusty> So the conditions are a bit more complex than "signature from you and signature from me". There's also a "revocation secret" for each check: if you have this, you can take the funds. I hand these over to you to "revoke" the old check and once you send me a new signed one. 21:14 < rusty> Of course, that's not quite enough either. The bank needs to call me and wait a day whenever a check gets spent, to give me time to use the revocation secret. 21:15 < rusty> So, I watch the blockchain, and steal all the money if you use an old "check". On channel setup I told you how long it has to wait for. 21:15 < cellvia> who is intended to do the revoking? the spender or receiver ? 21:15 < rusty> cellvia: it's symmetric. You send me checks, I send you checks. 21:15 < rusty> So we each hold a check signed by the other one, at all times. 21:16 < cellvia> ok 21:16 < cellvia> and revoking the old check is the way to say "yes, this is true" from each party 21:16 < cellvia> to the latest transaction 21:16 < rusty> And a revocation secret for every previous check. Though there's a clever way of generating them so I actually can calculate the whole sequence. 21:17 < rusty> Yeah, I send you a new check, if it's crap you can just spend the old one, otherwise you agree by sending the revocation secret for the old one, guaranteeing you won't spend it. 21:17 < rusty> cellvia: OK so far? 21:18 < cellvia> i think so, brain still processing ;-) 21:18 < cellvia> so for one transaction, there are 2 "checks" each with a revocation secret 21:18 < cellvia> the revocation secret is secret to the other party until the need arises to make a new transaction 21:18 < cellvia> and its how the 2 parties sign off on the new transaction 21:19 < cellvia> within the channell 21:19 < cellvia> right? 21:19 < rusty> Yep. 21:19 < cellvia> so one person initiatives the new transaction, and then what? there is a previously agreed upon "timeout" ? 21:19 < cellvia> initiates* 21:20 < cellvia> this timeout is the length of time the other party gets to decide "yes" or "no" 21:20 < rusty> cellvia: when we opened the channel, we negotiated that. eg. you said "I want a 1 day delay to catch you cheating" and I agreed. 21:20 < rusty> cellvia: no timeout, though,. 21:20 < rusty> cellvia: Turns out we don't need a way to "refuse" an offer. 21:21 < rusty> cellvia: You offer me money. I either collect it, or time it out, or fail it. 21:21 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:61d1:8f13:8837:549b] has quit [Quit: .] 21:21 < cellvia> wait, i thought you said there wasnt a timeout? 21:21 < rusty> cellvia: sorry, the "timeout" is how long the bank waits before honoring the check. 21:22 < rusty> cellvia: which doesn't matter for the normal case where one of us doesn't cheat or vanish. 21:22 < rusty> cellvia: ah, I see what you mean. OK, this is where we get into networking. 21:23 < rusty> cellvia: So, we could just hand money back and forth. eg. we start with a check that pays $0 to you and $10 to me. I send you a new (signed!) one, which pays $1 to you and $9 to me. 21:23 < cellvia> is the "bank timeout" the amount of time from the latest proposed transaction? or is it the amount of time from the opening of the channel ? 21:23 < rusty> cellvia: the time from when you try to spend the check. 21:23 < cellvia> ok got it, the time from when i "cash out" 21:24 < cellvia> and at the point of cashing out, the other party has 1 day (or however long) to "refuse" ? 21:24 < cellvia> though you are suggesting its not technically a refusal 21:25 < rusty> cellvia: not refuse, but steal funds. If this wasn't the latest, the other party has that revocation secret and has 1 day to take the money. 21:25 < cellvia> its basically just not revoking the old check in favor of the cash out one 21:26 < cellvia> ok 21:26 < cellvia> so lets say weve exchanged 10 times 21:26 < rusty> So, how we have a way to pay each other. Yep. 21:26 < cellvia> the 9th exchange was most favorable to me 21:26 < cellvia> so im like yeah, i think i'll cash THAT one 21:26 < cellvia> i take it to the bank 21:26 < cellvia> the other party has 1 day (or however) to present the revocation secret 21:26 < cellvia> of that check 21:26 < rusty> Yes, when you gave me the 10th, you gave me the revocation secret for #9. Yep... 21:27 < cellvia> and if they DO present it.... then i screwed up, and lose all the money 21:27 < cellvia> i got caught 21:27 < rusty> Even better, thanks to Tadge I can actually outsource this "presentation of revocation secret" to others. 21:28 < cellvia> how do you mean? 21:28 < rusty> So you better hope I am unreachable, and haven't got anyone else to do it who is honest. 21:28 < cellvia> ok 21:28 < cellvia> so lets say theres the 3rd party who has the revocation secret that you (?) gave him 21:28 < ajd_> (and others presumably can be some server you're running somewhere, I guess?) 21:28 < rusty> Yep. 21:28 < cellvia> what keeps me from being like hey i will split the money with you, dont provide that secret 21:29 < rusty> cellvia: Nothing. But how do you know who they are and how many there are? 21:29 < rusty> And how do *they* know that I'm not going to go online and catch them not doing their job? 21:29 < cellvia> dunno, cause im a leet hacker 21:30 < rusty> cellvia: Heh, then you've already got my coins :) 21:30 < cellvia> ok, so ostensibly you actually know all these people? 21:30 < cellvia> they are people you have opened your own independent channels with ? 21:34 < ajd_> thanks for this conversation, both of you; I really like the analogy 21:36 < cellvia> yeah, its helping a lot so far 21:37 < rusty> cellvia: Well, other people have to watch the bank anyway, right. So why not watch for me too? Helps everyone, and maybe you pay me some tiny amount for it. 21:37 < rusty> s/you pay me/I pay them/ 21:37 < rusty> OK, so now we have a pretty robust Rusty <-> cellvia payment method, right? 21:38 < rusty> Next step is networking... 21:38 < ajd_> oo here comes the magical part 21:38 < cellvia> well i am not 100% on the 3rd party piece 21:38 < cellvia> but i get everything stated so far 21:39 < cellvia> i get the idea that everyone is already keeping up w/ the bank (blockchain) anyways, so why not also help out here, but i mean, how in the world do 3rd parties get MY revocation secret 21:39 < rusty> cellvia: OK: extra third-party magic. It turns out I can actually hand pre-signed checks which use those revocation secrets WITHOUT the 3rd party being able to figure out who my counterparty is, or even how much is going through the chnnels. 21:40 < rusty> cellvia: *but* if they see a check from you, then they can match up the pre-signed check I gave them. 21:40 < rusty> So, why *wouldn't* I share those "revocation penalty checks" with everyone I can? 21:41 < cellvia> this part is twisting my brain a little 21:41 < cellvia> let me think on it 21:41 < rusty> Tadge invented this, because he's awesome :) 21:41 < cellvia> yeah i mean this must honestly be at a similar level as blockchain itself 21:41 < rusty> To figure out how, we kinda gotta go into technical details. How's your hashing and crypto knowledge? 21:41 < cellvia> i have an easier time understanding THAT 21:41 < cbits> Step 1 mitm 3rd party watchers and screw you over due to false sense of security :P 21:42 < cbits> I'd assume there'd be safeguards built in to avoid that anyway, just kidding around :) 21:42 < rusty> cbits: sure! And various parties will also want that so they can do timing analysis to try to deanonymize the network, etc etc.... 21:43 < cellvia> i assume the safeguard to that is these unknowable presigned checks 21:43 < ajd_> I like the fact that this means I can do the watching myself on servers out in the cloud somewhere, but there's no way for the cloud provider to steal my funds or even violate my privacy 21:43 < rusty> cellvia: yeah. Basically, I give you some signatures, but you can't tell waht they sign. When you see the thing they sign, you go "a ha!". 21:44 < cbits> That and default to having some trusted set of watchers built into the app, you can always opt out, but you'd always know if you were mitm there unless they were hacked themselves as well 21:44 < rusty> ajd_: It's pretty sweet (I should have mentioned adiabat == Tadge BTW) 21:44 < cellvia> and someone will invariably "see the thing they sign" since it hits the blockchain ? 21:44 < rusty> cbits: well, you can also use your other peers and have pairing watching arrangements, as well. 21:44 < rusty> cellvia: exactly. 21:44 < cellvia> or is this still before it hits the blockchain? 21:44 < rusty> cellvia: they gotta get into the blockchain to start that "1 day" timeout. 21:44 < cellvia> ok i see 21:45 < cellvia> its making sense 21:45 < cellvia> and if a revocation of that is in circulation, it wont be long before im caught 21:45 < cbits> ajd_, yeah using a private VPS would be cool. I'd do that. adiabat is the man. 21:45 < cellvia> if the above is the case, what is the point of allowing people to decide amongst themselves the timeout period ? 21:46 < cbits> In the case of a party cheating, is there a bigger percentage set toward fees to incentivize miners to mine it? 21:46 < cbits> (revocation tx) 21:46 < cellvia> i mean isnt there some algorithmic way to determine that based on the LN size, with certainty any cheating will be caught within X amount of time 21:46 < cbits> That'd also distinguish the tx more though. hm 21:47 < ajd_> you also have to get your revocation tx into the blockchain 21:47 < cellvia> "you" ? i thought there was an army of 3rd parties ready to jump on that on my behalf ? 21:48 < ajd_> More time means doing that will cost less in tx fees. 21:48 < rusty> cellvia: there may be a way, but it's easier to simply negotiate it up-front. That's how it is in the current spec. 21:48 < ajd_> Right, not necessarily you. But the revocation tx has to get confirmed. 21:48 < cellvia> ok, so this seems like an easy way to trick people 21:49 < cellvia> people who arent aware of confirmation times, issues, etc 21:49 < rusty> ajd_: true, and in theory if they're stealing less than the fee amount, don't bother. 21:49 < cellvia> might just sign up for the transaction 21:49 < cellvia> not look at the "timeout" 21:49 < cellvia> the timeout could be half an average BTC confirmation time 21:49 < rusty> (Technically, timeout is in blocks) 21:50 < cellvia> oh 21:50 < cellvia> ok 21:50 < cellvia> well, that could still be a viable way to trick someone 21:50 < cellvia> right? 21:50 < cellvia> i mean lets say you set the timeout to 1 block 21:50 < rusty> And you tell *me* what timeout is on the checks you give to me, and I tell *you* what the timout is on checks I give to you. 21:50 < ajd_> presumably this negotiation is done by the software not by manually popping up a box which asks the person 21:51 < cellvia> but lets say you are using software controlled by that person 21:51 < rabidus> it would be nice however "would like to be tricked?" 21:51 < cellvia> like their website 21:51 < ajd_> good software definitely won't allow someone to set an unreasonably low timeout without popping up a bunch of warning messages at the least 21:52 < ajd_> If you're using software controlled by that person who wants to steal from you you've already lost 21:52 < cellvia> true 21:52 < cellvia> so rusty you are saying there isnt a SHARED timeout, its indepedent to each of the 2 checks in the transaction ? 21:53 < rusty> Yep! You might be a mobile wallet and want 4 days to catch me cheating, I might be a permanent node in a datacenter and lots of backup systems and be happy with 6 confirms. 21:54 < rusty> (Actually, current defaults are 1 day, and allow them up to 3 days) 21:54 < cellvia> im still confused though. why would that matter. the whole network has my back 21:54 < cellvia> whether im on a phone or a supercomputer.. 21:54 < rusty> cellvia: because that's not actually implemented yet :) 21:54 < cellvia> i guess thats a separate piece? 21:55 < cellvia> so we've been discussin mostly micropayment channels so far 21:55 < rusty> cellvia: yeah, and it's pretty trivial, but code has to be written, tested, etc... 21:55 < cellvia> and then the network effect piece is "lightnng network" ? 21:55 < cellvia> where do the revocation secrets live btw 21:55 < rusty> Well, JP and TD invented both: this "revocation & delay" which makes bi-directional channels possible, and the network part. 21:56 < rusty> cellvia: you keep them, but turns out you can store ~infinite number in about 1K of disk space. 21:56 < cellvia> wow.... now that is magic. is that using a merkle tree 21:57 < rusty> 281474976710655 to be precise. 21:57 < rusty> cellvia: similar idea, called shachain in the spec. 21:57 < rusty> OK, so we ready for the network part? 21:57 < cellvia> was that invented for this? 21:57 < cellvia> shachain 21:58 < cellvia> sure 21:58 < rusty> cellvia: yeah, I came up with that one. But roasbeef came up with a similar one called elkrem. 21:58 < rusty> So, now we have rusty->cellvia, but we really want to do rusty->cellvia->ajd_ (etc). 21:58 < cellvia> wow. well thats f-ing awesome. ok so the network part, you mean the 3rd party revocation secret sharing? 21:59 < rusty> cellvia: no, we call that outsourcing watching. 22:00 < rusty> We do this using conditional payments. I say "Hey, cellvia, I'll give you $1 if you answer this Q within 6 hours. BTW, ajd_ has the answer". And you then say to ajd_: "I'll give you 0.99c if you answer this Q within 5 hours". 22:01 < rusty> If adj says "don't know" or doesn't give an answer for 5 hours, you can turn around and say "I don't know" to me (or just wait 6 hours). 22:02 < rusty> If ajd_ answers, you turn around and answer me, collecting the 1c profit. Even if he answers at the last possible moment, you have 1 hr to do this. 22:03 < rusty> Now, if things go wrong in the middle, you need to be able to take that check to the blockchain and get your money anyway. Fortunately, bitcoin is smart money, you can actually write a "check" that does this. 22:03 < cbits> 'ajd_: true, and in theory if they're stealing less than the fee amount, don't bother.' Why not mine that transaction, and then make another burning it all in fees for a miner to mine 22:03 < cellvia> so these payments are the incentive? to me this almost seems like some totally parallel thing to mining 22:03 < cbits> rusty: disincentives even stealing lower than fee amount 22:03 < rusty> cellvia: it's a race to the bottom, I imagine the fees will be tiny. 22:04 < rusty> cbits: well, adiabat argued similarly, which is why in practice there's a 1% reserve, so you gotta have some skin in the game. 22:04 < cbits> cool, I figured others would already have the same idea :) 22:05 < rusty> cellvia: ie. I used to hold a check saying "Pay $9 to cellvia. Pay $1 to me AFTER 1 day OR $1 to cellvia with revocation secret". 22:05 < cellvia> could this LN exist without the blockchain? is it strictly necessary for a network like this? i suppose you need some kind of "central authority" to enforce, but in our case we're choosing a decentralized central authority 22:06 < rusty> cellvia: Now it's like "Pay $9 to cellvia. Pay $1 to cellvia with the answer to Q, or AFTER 6 hours pay $1 to me, or pay $1 to cellvia with revocation secret". 22:06 < rusty> cellvia: yes, you *need* to be able to count on the bank being there, being robust, and not censoring your txs. Then you don't actually have to *use* it very often. 22:07 < cellvia> ok 22:08 < cellvia> still fuzzy on the last couple pieces, when you say it used to be 9 to cellvia, 1 after a day to me, or 1 to cellvia w/ recovation secret 22:08 < cellvia> for some reason thats not clicking 22:08 < cellvia> how was it like that before? 22:09 < rusty> That's a normal payment channel; it gives you the funds instantly, mine are delayed to give you a chance to use revocation secret. 22:11 < rusty> I made up the numbers. 22:12 < rusty> Anyway, in general, it looks like: 1. some to you 2. some to me after delay, or to you if you have the revocation secret. 3. some to you if you answer Q1, otherwise to me after some timeout. 4. some ti me if I answer Q2, otherwise to you after some timeout. 22:19 < cellvia> ok got it, except 3 and 4 22:19 < cellvia> im just not quite understanding the purpose behind it i think 22:20 < cellvia> are you saying this is a sequence? 22:20 < cellvia> rusty ^ 22:21 < rusty> cellvia: No, they're the conditional payments. 22:22 < rusty> cellvia: you could have offered me one (#4), I could have offered you one (#3), or more than one. 22:22 < cellvia> im just not following what conditional payments are for in this big picture 22:23 < cellvia> what do they achieve 22:23 < cellvia> besides being smart contracts or w/e 22:23 < rusty> cellvia: they let me make a payment to ajd_ without me having to trust you. 22:24 < rusty> cellvia: ajd_ gives me a Q, I send it to you, you send it to him. 22:24 < rusty> Nobody has to trust anyone else. 22:25 < cellvia> im just not understanding why a 3rd party is necessary in this 22:25 < cellvia> thank you for your patience BTW, really appreciating this 22:26 < rusty> cellvia: in this case, you're the 3rd party. I don't want to open a channel to ajd_ just to pay him 10c. 22:26 < rusty> (Or $1, or whatever) 22:26 < cellvia> ok i see 22:26 < cellvia> because its a blockchain hit to do so 22:26 < cellvia> which takes time 22:26 < rusty> Yeah, it also doesn't scale. 22:27 < cellvia> we are trying to reduce those 22:27 < cellvia> ok, so what about this case 22:27 < rusty> I may pay hundreds of different people, I don't want a channel with all of them. 22:27 < cellvia> you have a channel with me, you want to pay _ajd but i dont have a channel to him 22:28 < cellvia> and in fact, our channel mini network, doesnt connect to _ajd at all 22:28 < cellvia> how do you discover that 22:28 < cellvia> i suppose your software is tasked with that, and tasked with initiating a channel? 22:28 < cellvia> the payer's software 22:28 < rusty> cellvia: we publish our channels (if we want to route). So everyone knows; in this case I will have to open a channel to ajd_ to pay him, or do an onchain payment. 22:28 < rusty> Yep. 22:29 < cellvia> ok then this comes back to my original question 22:29 < cellvia> that i may have not asked lol 22:29 < cellvia> but this is what was confusing me... if this network extends to all nodes 22:29 < cellvia> then doesnt this effectively detach from the blockchain 22:29 < cellvia> except in the case of problems 22:29 < cellvia> where there needs to be enforcement 22:30 < cellvia> it seems like surely that must be fragile 22:30 < cellvia> lets say we have a network of a million lightning transactions that havent made it to the bank 22:30 < rusty> cellvia: except for opening new channels, closing old ones, enforcement, topping up channels and lowering amounts in channels? Yeah, kind of. 22:31 < cellvia> and then a number of them get invalidated 22:31 < cellvia> what about all those unrecorded ones that are all linked? 22:32 < cellvia> so what if it gets so detached, the topping up and lowering of channels is just infiinitely deferred... is that impossible? 22:32 -!- cbits [~cbits@2607:f380:a61:650:5892:6331:9da1:dbaa] has quit [Read error: Connection reset by peer] 22:33 < rusty> cellvia: No. The existence of the chain is what prevents you from having to use it, because everyone *knows* cheaters will get penalized. 22:33 < cellvia> i think i have this inaccurate vision of what the fully activated lightning network looks like: one huge channel that never gets sealed, or closed / committed 22:33 < rabidus> i guess ̃~2-3 channels 22:33 < rusty> No. More likely, imagine millions of machines which have 99.9% uptime, and so there's plenty of chain action all the time. 22:35 < cellvia> can you briefly explain what you mean exactly by "topping up" and "lowering amounts" in channels? what initiates that 22:35 < rusty> You might be using a channel more often than you think, or you buy more bitcoins -> top one up. 22:35 < cellvia> i get "opening new channels", "closing old ones", "enforcement" 22:35 < rusty> You might want to make an on-chain payment, or put into cold storage -> lowering amount. 22:36 < cellvia> ok i see 22:36 < cellvia> i like this idea 22:36 < cellvia> i like the bank or court analogy 22:37 -!- ThomasV_ [~ThomasV@x4db4c412.dyn.telefonica.de] has quit [Ping timeout: 268 seconds] 22:37 < cellvia> i think the passing around questions piece is a little hard to visualize, but makes sense 22:38 < cellvia> i guess last question now, what happens in a scenario like bitcoin has, where mining is very difficult (right?) and lots of transactions, when suddenly theres much less transactions, and i presume mining is easier (maybe im misunderstandinfg) 22:38 < cellvia> for the miners i mean 22:39 < cellvia> this doesnt disincentivize future mining does it? 22:49 < rusty> cellvia: Sorry, was runnign tests. 22:50 < rusty> cellvia: It's a good question, but it doesn't seem to hold up. lightning does things that on-chain can't do, but on-chain can do things lightning can't do, too. 22:50 < rusty> cellvia: the obvious point to make is that bitcoin with lgihtning is more valuable (can be used for microtransactions, instant payment). 22:51 < rusty> cellvia: but also, lightning fees and capacity. To send $1 over lightning, you need $1 in each channel on the route. 22:52 < rusty> cellvia: the risk for nodes on that route is that someone gets stuck and they can't use that $1 for other things for (some duration). 22:53 < rusty> cellvia: so, logically (and in the spec), fees set by nodes are proportional to amount sent. Unlike on-chain, where it's by weight. So there's some point at which it's cheaper to send on-chain. 22:53 < rusty> cellvia: But the capacity point is also true. To send $10,000 over lightning, you need to find channels between you and the recipient with $10,000 capacity. 22:58 < cellvia> oh wow, hadnt thought of that 22:58 < cellvia> why wouldnt you break that up into 100 $100 transactions 22:59 < cellvia> i guess the fees for that would accumulate enough too, to make it prohibitive 22:59 < cellvia> rusty^ 22:59 < cellvia> rusty ^ 23:00 < rusty> cellvia: yeah. But also, what happens if you run out of capacity halfway? Now you've half-paid... 23:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xlljnzsvhroqbptn] has joined #lightning-dev 23:00 < cellvia> so there are cases where it is literally impossible to send over lightning 23:00 < rusty> Lightning has a nice property that by providing the answer to the Q the merchant gave you, they give you proof that you paid. 23:01 < rusty> cellvia: definitely. Particularly since lightning on bitcoin has a 0.042 HTLC limit in the spec. 23:01 < cellvia> HTLC? 23:01 < rusty> Sorry, technical term for one hop of a conditional payment. 23:02 < rusty> cellvia: "Hash Timelock Contract." 23:13 < cellvia> i have no idea what kind of unit that would be though... .042 ... hours? 23:14 < cellvia> i think ajd_ shared this https://medium.com/@rusty_lightning/the-bitcoin-lightning-spec-part-1-8-a7720fb1b4da seems good 23:15 < rusty> Sorry, bitcoin :) 23:15 < rusty> cellvia: Glad you like it! 23:15 < cellvia> gotcha. one day .042 btc will be worth a lot 23:15 < cellvia> ;-) 23:15 < cellvia> already worth a bit 23:16 < cellvia> haha wait, now i see you wrote that ;-) rusty_lightning 23:17 < cellvia> well, you sir, are incredibly helpful. you transmitted to me what ive been looking for off and on the past couple weeks in an hour. thank you 23:17 < cellvia> i am off, and no doubt i'll be back again. i am a dev with admittely very little cryptographic experience, but fascinated with the new tech and its potential, looking for places to plug in 23:18 < rusty> Glad to help! 23:18 < cellvia> cheers :-) 23:18 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 23:43 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]