--- Day changed Mon Mar 19 2018 00:46 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 00:53 -!- volition [~volition@203.87.121.143] has joined #lightning-dev 00:58 -!- anome [~anome@unaffiliated/anome] has joined #lightning-dev 01:01 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 01:02 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 01:03 -!- anome [~anome@unaffiliated/anome] has joined #lightning-dev 01:05 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 01:06 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 01:08 -!- migoreng [~migoreng@219.88.232.71] has quit [Quit: Leaving] 01:23 -!- anome [~anome@unaffiliated/anome] has quit [] 01:38 -!- wump is now known as wumpus 01:40 -!- dabura667_ [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #lightning-dev 01:40 -!- dabura667_ [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Read error: Connection reset by peer] 01:47 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 01:47 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 02:00 -!- anome [~anome@unaffiliated/anome] has joined #lightning-dev 02:02 -!- dabura667_ [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #lightning-dev 02:02 -!- dabura667_ [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Read error: Connection reset by peer] 02:08 -!- anome [~anome@unaffiliated/anome] has quit [Read error: Connection reset by peer] 02:08 -!- bitonic-cjp [~bitonic-c@92-111-70-106.cable.dynamic.v4.ziggo.nl] has joined #lightning-dev 02:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection] 02:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 02:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #lightning-dev 02:42 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 04:17 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 04:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 04:23 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 04:25 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev 04:32 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 04:33 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 04:34 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds] 04:37 -!- _Sam-- [greybits@gateway/vpn/privateinternetaccess/sam--/x-37783179] has joined #lightning-dev 04:38 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has joined #lightning-dev 04:54 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev 04:56 < stiell> Hello, I've been looking into AMP and noticed that it doesn't work by the "selling a preimage" method of regular payments and thus can't provide proof of payment. 04:57 < stiell> After thinking about this for a while, I think I've come up with an alternative that does provide proof of payment. It is extremely simple so I may be missing something, but I can't see any obvious flaw or disadvantage of it. 04:58 < stiell> Maybe someone with more expertise can have a look? https://gist.github.com/stiell/08c1b014ddc1467146e711b684343d26 04:59 < stiell> ("Hello, I just discovered Lightning and I'm here to fix it!" ;) 05:02 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 05:04 -!- volition [~volition@203.87.121.143] has quit [Remote host closed the connection] 05:08 < stiell> Basically, if you think of regular payments as buying a specific preimage, VAMP works by buying any one of several preimages specified by the invoice. The invoice is considered paid if at least one of the preimages has been paid for. The buyer initiates a payment for all preimages simultaneously, with the values of the partial payments adding up to the total specified by the invoice. The seller settles 05:08 < stiell> the payments only when they can all be settled such that the total value is greater or equal to that of the invoice. 05:19 < mac______> The invoice is considered paid if at least one of the preimages... The buyer initiates a payment for all... ? 05:21 < stiell> Not necessarily all, one or a subset is also possible as long as the sum of values in greater or equal to that of the invoice. 05:23 < stiell> E.g. a payer without support for VAMP would simply ignore the extra payment hashes and pay the full amount to the first one. 05:24 -!- ebx [~ebx@unaffiliated/ebex] has joined #lightning-dev 05:26 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 05:30 -!- dcousens [~dcousens@110.140.197.162] has quit [Ping timeout: 256 seconds] 05:30 < stiell> But it is necessary for the invoice to be considered paid if the seller hasn't settled all payments initiated by the buyer, otherwise the seller could reject one of the payments, take a lower amount and not fulfill their part of the deal, falsely claiming the buyer didn't provide full payment. Thus "at least one". 05:34 -!- dcousens [~dcousens@110.140.62.103] has joined #lightning-dev 05:49 -!- shesek [~shesek@bzq-84-110-53-228.cablep.bezeqint.net] has joined #lightning-dev 05:49 -!- shesek [~shesek@bzq-84-110-53-228.cablep.bezeqint.net] has quit [Changing host] 05:49 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 06:00 -!- cypher_ is now known as cypher 06:00 -!- cypher [~cypher@ryu.tnt.cx] has quit [Changing host] 06:00 -!- cypher [~cypher@unaffiliated/cypher] has joined #lightning-dev 06:06 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 06:11 -!- riclas [riclas@148.63.37.111] has joined #lightning-dev 06:13 -!- LightningK0ala [5862c944@gateway/web/freenode/ip.88.98.201.68] has joined #lightning-dev 06:19 < LightningK0ala> Hey everyone. Is there a rule in lnd that for a channel, the minimum amount in local / remote balance must be at least 10% of the total capacity of the channel? 06:27 < chujev> nah I have channels with 0 on one side 06:30 < AndyS2> oh, it does that? That's risky because the party with 0 funds on their side can try to steal without losing funds. 06:34 < LightningK0ala> @chujev was it > 0 before? i.e. did you / the other node spend it all to reach 0? 06:35 < chujev> no, it's 0 from the start 06:38 -!- JackH [~laptop@host-80-47-80-55.as13285.net] has quit [Quit: Leaving] 06:41 < AndyS2> hm, if there's no previous state with more than 0, then stealing isn't possible, right? 06:44 < chujev> i'm a LN n00b, not sure how it works under the hood. according to "lncli listchannels" all my channels have 0 on one side. i used LND autopilot. 06:57 < LightningK0ala> I can get 0 from the start as well, I meant after you make payments it's not possible to go below 10% capacity (not sure if this is true but it's what I'm observing with these two channels I have). 06:59 < AndyS2> LightningK0ala: I'd guess that this is the security margin. maybe it's not 10%, but a fixed amount? 07:02 < AndyS2> if you could 'go' to 0 on your side of the channel, you could just try to announce an old channel state to steal money with no risk involved. The other party can still stop you from receiving those stolen funds, but it won't get anything from you because you have 0 in the channel. For that reason, going to 0 is probably not something the client does on its own 07:03 < AndyS2> if you still have some money in the channel and attempt to steal by publishing an old channel state, the other party gets the money left on your side of the channel/all money 07:05 < LightningK0ala> Hmm I see 07:06 < LightningK0ala> Is it normal that I'm able to pay the same invoice more than once? 07:07 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-pvcogfzovwzdbrbq] has quit [Quit: Connection closed for inactivity] 07:09 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 07:09 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev 07:13 -!- wxss [~user@192-30-89-138.baremetal.cloudsingularity.net] has joined #lightning-dev 07:19 -!- nirved [~nirved@2a02:8071:b58a:3c00:5c93:ec78:14ff:558c] has quit [Ping timeout: 246 seconds] 07:20 -!- LightningK0ala [5862c944@gateway/web/freenode/ip.88.98.201.68] has quit [Ping timeout: 260 seconds] 07:23 -!- HFRadical [~none@103.254.153.99] has quit [Ping timeout: 240 seconds] 07:29 -!- nirved [~nirved@2a02:8071:b58a:3c00:2072:11ba:3449:fbf4] has joined #lightning-dev 07:53 -!- BlackSheep [~yaaic@109.73.88.218] has joined #lightning-dev 08:18 -!- LightninK0ala [5862c944@gateway/web/freenode/ip.88.98.201.68] has joined #lightning-dev 08:18 -!- LightninK0ala [5862c944@gateway/web/freenode/ip.88.98.201.68] has quit [Client Quit] 08:44 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has joined #lightning-dev 09:08 -!- bitonic-cjp [~bitonic-c@92-111-70-106.cable.dynamic.v4.ziggo.nl] has quit [Quit: Leaving] 09:17 -!- wxss [~user@192-30-89-138.baremetal.cloudsingularity.net] has quit [Ping timeout: 248 seconds] 09:19 -!- wxss [~user@209.58.165.1] has joined #lightning-dev 09:35 -!- BlackSheep [~yaaic@109.73.88.218] has quit [Ping timeout: 256 seconds] 09:39 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has quit [Quit: probably someone interrupted me] 09:42 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has joined #lightning-dev 09:57 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has quit [Quit: probably someone interrupted me] 10:04 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has joined #lightning-dev 10:26 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 10:31 -!- BlackSheep [~yaaic@109.73.88.218] has joined #lightning-dev 10:39 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has quit [Quit: probably someone interrupted me] 10:44 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has joined #lightning-dev 10:48 < BlackSheep> in recksplorer only nodes whit almost one open channel is shown? I've a full node (debian btcd lnd) working but whit no btc on it, for now... There is a website that show all ln nodes, also nodes whit no open channels? i simply want to see if my alias is ok 10:55 -!- Cogito_Ergo_Sum [~Myself@athedsl-314680.home.otenet.gr] has joined #lightning-dev 10:55 -!- Cogito_Ergo_Sum [~Myself@athedsl-314680.home.otenet.gr] has quit [Changing host] 10:55 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #lightning-dev 10:57 < mlz> BlackSheep, if your node has never had a channel, it won't show on the recksplorer 10:57 < mlz> BlackSheep, is your btcd fully synced to the blockchain? 10:59 < BlackSheep> mlz, yes 11:02 -!- cluelessperson_ is now known as cluelessperson 11:03 < mlz> BlackSheep, you have to have at least one channel before your node is on that explorer 11:11 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev 11:21 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 264 seconds] 11:23 < BlackSheep> i build my node on a good ibm server with the blockchain on 2 raid0 ssd disks, made it for performance. my bottleneck is the bandwidth and latency but next month optical fiber will be ready here. I made it for passion and study, i love decentralization and try to contribute... do you think there will real use of node like mine in future or is the same thing to install any gui ln client on any low performance machine? sry for my poor english... i mea 11:30 < mlz> BlackSheep, some people have used mainnet channels to buy a few things, and there have been a lot test channels on testnet, if you're not quite familiar with it, I would suggest you try this on testnet 11:38 -!- ebx [~ebx@unaffiliated/ebex] has joined #lightning-dev 11:39 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has quit [Quit: probably someone interrupted me] 11:40 -!- go1111111 [go1111111@gateway/vpn/privateinternetaccess/go1111111] has joined #lightning-dev 11:51 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has joined #lightning-dev 11:54 -!- adiabat [~adiabat@45.63.20.152] has quit [Quit: WeeChat 1.4] 11:56 < BlackSheep> mlz, ok 11:56 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 11:57 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #lightning-dev 11:57 < BlackSheep> mlz, anyway my question is another... t 11:57 -!- adiabat [~adiabat@45.63.20.152] has joined #lightning-dev 11:59 < BlackSheep> think i can't explain good what i mean.. no prob... is not important, sry 12:00 -!- tinova33 [~tinova@lemoncat.org] has quit [Remote host closed the connection] 12:02 -!- toidi_ [6d4958da@gateway/web/freenode/ip.109.73.88.218] has joined #lightning-dev 12:02 < mlz> BlackSheep, want to open a channel? 12:03 -!- toidi_ [6d4958da@gateway/web/freenode/ip.109.73.88.218] has quit [Client Quit] 12:05 < BlackSheep> i do it tonight... waiting tx from exchange. tnx anyway! 12:21 -!- ruby32 [~ruby32@158.106.219.26] has joined #lightning-dev 12:25 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has quit [Quit: probably someone interrupted me] 12:26 -!- BlackSheep [~yaaic@109.73.88.218] has quit [Ping timeout: 264 seconds] 12:27 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has joined #lightning-dev 12:40 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has quit [Quit: probably someone interrupted me] 12:43 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has joined #lightning-dev 12:45 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 12:46 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 12:54 -!- lndbot [~lndbot@138.197.213.35] has joined #lightning-dev 12:54 -!- lndbot1 [~lndbot@138.197.213.35] has quit [Read error: Connection reset by peer] 12:55 -!- Ytxyyuu2 [~Ytxyyuu@78-71-46-150-no260.tbcn.telia.com] has joined #lightning-dev 12:55 -!- Ytxyyuu2 [~Ytxyyuu@78-71-46-150-no260.tbcn.telia.com] has quit [Client Quit] 12:58 -!- Ytxyyuu [~Ytxyyuu@78-71-46-150-no260.tbcn.telia.com] has quit [Ping timeout: 256 seconds] 12:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:03 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-wizchbechkexszda] has joined #lightning-dev 13:04 -!- TeaPanda [~TeaPanda@unaffiliated/teapanda] has joined #lightning-dev 13:07 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 13:07 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has joined #lightning-dev 13:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 13:14 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 13:15 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [] 13:15 <+roasbeef> stiell: "proof of payment" is pretty undefined imo 13:16 <+roasbeef> also one of the key components is that the sender can rebalance flows as they wish, aand aren't locked into a set number of hashes 13:17 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #lightning-dev 13:24 < stiell> roasbeef: My proposal allows sender to choose number of flows (up to maximum provided by invoice) and choose how to distribute value across them. 13:24 <+roasbeef> the original does as well 13:24 <+roasbeef> i don't see what yours adds at all 13:24 <+roasbeef> perhaps you didn't fully grok the original? 13:24 <+roasbeef> the receiver would need to guess how many flows the sender would use with what you're proposing 13:32 < stiell> If the receiver provides too many hashes, that wastes some invoice space, but I don't see that as a big problem. Eventually, I imagine invoice data would be transferred over some automated protocol rather than clipboards or QR codes, and an interactive protocol could have them negotiate number of hashes. 13:32 < stiell> My proposal restores proof of payment and is much simpler than the original. 13:32 < stiell> What's undefined about proof of payment? 13:35 < lndbot> did you see the extensive discussion had on the mailing list re: proof of payment? 13:36 < stiell> I did. 13:37 < stiell> Or, at least Re: AMP. 13:38 < lndbot> hash/preimage is not a really a proof by any rigorous defintion 13:39 < lndbot> if i’m understanding the proposal correctly, it’s not even atomic? 13:39 < stiell> Ok, let's call it purchase of preimage then. 13:39 <+roasbeef> your proposal also isn't actually atomic 13:40 < stiell> It's no less atomic than it needs to be. 13:40 -!- dafunkiz_ [~dafunkizd@209.63.143.172] has quit [Quit: probably someone interrupted me] 13:40 <+roasbeef> the whole point is that it's atomic 13:40 < lndbot> and why would you need to purchase a preimage? 13:40 <+roasbeef> the recvr can't pull until all the funds get there and the flow is completed 13:40 < lndbot> the whole point of lightning is that everything’s atomic 13:40 < stiell> It is fully atomic in the sense that either the invoice is considered fully paid or not paid at all. 13:40 < lndbot> no, because the receiver can pull partial payments without all of them being received 13:41 < stiell> And so what? 13:41 < stiell> That's the receiver's problem. 13:41 < lndbot> um, no? 13:41 < stiell> You can also take an atomic payment and throw half of it into a black hole, so what? 13:41 < lndbot> if i send 80% of the funds, and 20% get lost, what should the receiver do? 13:42 < stiell> Get lost how? 13:42 < lndbot> game theory says they will just take 80% and say screw you 13:42 < lndbot> network connectivity, bandwidth constraints, malice 13:42 < stiell> The receiver does not accept any payment until all partial payments are finalisable. 13:43 < stiell> They can take 100% and say screw you too. 13:43 < lndbot> your proposal requires trust in the receiver 13:43 < stiell> No. 13:43 < lndbot> if they take 100%, then the payment was successful. that’s the whole point of atomcity 13:43 < lndbot> yes 13:43 < stiell> You trustlessly buy one of the provided preimages. 13:44 <+roasbeef> why would you buy a preimage? 13:44 <+roasbeef> i'd recommend reviewing the original proposal 13:44 < stiell> Idk, why would you make a lightning payment at all? 13:45 < schnerchi> exit 13:45 < stiell> A preimage could be used further in a smart contract, e.g. 13:45 -!- anome [~anome@unaffiliated/anome] has joined #lightning-dev 13:45 <+roasbeef> stiell: you're misunderstanding the fundamantal components of the scheme, and attempting to suggest a non-solution 13:46 < stiell> In semi-trusted scenarios, which would be common, the preimage provides as a proof of payment. 13:46 <+roasbeef> we go for as trust minimzed as possible 13:46 <+roasbeef> also "proof of payment" isn't well defined 13:47 <+roasbeef> i'd check out some of the recent things on the mailing list to get up to speed 13:50 < stiell> Any particular thread/subject? 13:52 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #lightning-dev 13:52 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host] 13:52 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev 13:57 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 13:58 -!- eklitzke [~evan@fsf/member/eck] has quit [Quit: bye] 14:00 -!- eklitzke [~evan@fsf/member/eck] has joined #lightning-dev 14:07 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit [] 14:07 -!- ebx [~ebx@unaffiliated/ebex] has joined #lightning-dev 14:08 -!- anome [~anome@unaffiliated/anome] has quit [] 14:10 -!- anome [~anome@unaffiliated/anome] has joined #lightning-dev 14:11 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: leaving] 14:12 < stiell> roasbeef: you talk about "a failure mode where if the sender fails to actually satisfy all the payment flows, then the receiver can still just pull the monies (and possibly not disperse a service, or w/e)". I see several issues with this statement. First, if the "sender fails" to satisfy all the payment flows [but completes some], whose fault is that really? AIUI, the receiver is in full control of 14:12 < stiell> settling or rejecting an outstanding payment once it has reached the receiver. If the receiver starts pulling payments before having access to a total value that meets the invoiced amount, that is the equivalent of taking a full payment and then throwing some of it back at the sender. Would you say it was the _sender_ that failed in that case? Secondly: "then the receiver can still just pull the monies 14:12 < stiell> (and possibly not disperse a service, or w/e)" Alright. And what enforces the dispersion of a service upon _full_ payment? Likely nothing. But if there is something that enforces it, and seeing as you'd like to minimise trust, there ought to be, why does it not then enforce the _partially_ pulled payment? In both cases the receiver was in full control of accepting the amount paid! I must conclude that 14:12 < stiell> the only case where this is a "failure mode" is where whatever enforcement/incentive mechanism to make the receiver keep their part of the deal is fundamentally flawed! 14:13 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #lightning-dev 14:13 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host] 14:13 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev 14:15 < jojeyh> stiell, there is no system in the world that could trustlessly guarantee that once you give up a service or product you can guarantee payment 14:15 < jojeyh> stiell, lightning does not solve this problem 14:16 -!- booyah [~bb@193.25.1.157] has joined #lightning-dev 14:17 < jojeyh> stiell, lightning just guarantees that if someone tries to use a previously revoked transaction (HTLC) that the other side of the channel can take all the funds 14:17 -!- anome [~anome@unaffiliated/anome] has quit [] 14:17 < jojeyh> which is super strong game theoretically 14:17 < jojeyh> and i think the best feature of the lightning protocol 14:17 < jojeyh> or at least the most interesting 14:18 < jojeyh> i highly recommend you read the whitepaper by poon/dryja 14:19 < jojeyh> and then also the lightning-rfc specs on github 14:20 < stiell> I know how LN works. I have read the whitepaper. 14:20 < jojeyh> well regardless lightning does not solve the problem you are talking about above 14:21 < stiell> My point was rather that the argument that risk of a partial payment was a failure mode is absurd. 14:21 < jojeyh> what do you mean 'risk of a partial payment' ? 14:21 < lndbot> stiell, a payment can fail for reasons outside of the control of either sender and receiver. in some cases, it may not be possible to ascribe blame accurately. atomicity of the payment, totally separate from w/e invoicing scheme is used, protects the sender from these unnecessary risks 14:21 < jojeyh> are you referring to an actual spec in the protocol 14:22 < stiell> "a failure mode where if the sender fails to actually satisfy all the payment flows" 14:22 < lndbot> jojeyh is right, in that ln does not guarantee delivery of the goods/services directly 14:23 < stiell> AIUI, a recipient is fully able to atomically settle multiple payments. 14:23 < stiell> i.e. either all payments of some set are settled or none are. 14:23 < jojeyh> which BOLT are you referring to? 14:24 < jojeyh> stiell, do you mean like if there are multiple HTLCs in bound between a channel? 14:24 < stiell> The ability to atomically settle multiple payments is not a standard, it is a property of the system. 14:25 < lndbot> stiell, it is the desired standard if those multiple payments are fragments of a logical payment 14:25 < stiell> jojeyh: multiple HTLCs, yes, but they can be in different, unrelated channels. 14:28 < jojeyh> stiell, ok now you said that it was absurd that partial payment was a failure mode, what do you mean by this? 14:28 < jojeyh> can you break down your throught process there for me 14:29 < jojeyh> thought* 14:29 < stiell> Can you come up with an example where only some partial payments were settled, and it's not the fault of the receiver? 14:30 < stiell> And I'll try to explain why I think it's still the fault of the receiver :) 14:31 < jojeyh> honestly i'm still not sure what you are alluding to when you say partial payment 14:31 < jojeyh> do you mean if an HTLC makes it past a few nodes in the route then fails? 14:31 < stiell> As referred to in AMP. 14:32 < stiell> i.e. a single payment is split into multiple partial payment that follow different paths. 14:32 < jojeyh> what is AMP 14:33 < stiell> AMP: Atomic Multi-Path Payments over Lightning, the thing roasbeef told me to go read again :) https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html 14:34 < stiell> He's talking about a "failure mode" of naïvely splitting up one payment into several smaller payment with the same hash but different paths. 14:35 < jojeyh> k let me read it 14:35 < stiell> I argue that it is 100% the receivers responsibility to avoid this "failure mode", and that avoiding it is 100% possible. 14:35 < jojeyh> i haven't gotten all the mailing list stuff cause i couldn't get added for awhile 14:36 < lndbot> stiell, let’s say i send 5 partial payments, and only 3 of them reach the receiver. the other two get black-holed because of node failure 14:36 < lndbot> if i understand correctly, you’re saying that it would be the fault of the receiver if they decide to settle back these 3, even though they didn’t receive the payment in full? 14:37 < stiell> conner: Then there are 3 outstanding payments. They have not been settled. The receiver can reject them, or the sender will settle the state before the payment after a while on-chain. 14:37 < lndbot> stiell, the receiver _can_ reject them, but they can also settle them if they want because they’re not atomic 14:37 < jojeyh> stiell, i feel like that would create a lot of unnecessary on chain transactions 14:38 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: leaving] 14:38 < jojeyh> to enforce as a protocol spec 14:38 < lndbot> i think we all agree that the receiver shouldn’t settle them, but the point is use cryptography to make that impossible 14:38 <+roasbeef> ^ bingo 14:38 < stiell> conner: yes, and that would mean (in my proposal) that they accepted the invoice as paid. 14:39 < stiell> jojeyh: It can happen *right now* with any payment whatsoever. There is no difference. 14:39 < jojeyh> i'm gonna go read this long mamajam before i keep going with this lol 14:39 <+roasbeef> your proposal is a step backwards stiell 14:39 < jojeyh> looks like a good read 14:39 < lndbot> accepting the invoice as paid is meaningless if it does not accurately model the intrinsics of how that payment is made 14:39 <+roasbeef> please read the recent posts on the mailing list 14:39 < stiell> Game theory 14:40 < stiell> why _would_ the receiver accept a partial payment if that means accepting it as a full payment? Why should the sender care if they saved some money? 14:41 <+roasbeef> stiell: your proposal isn't insufficient, it assumes as total number of flows a head of time 14:42 <+roasbeef> it removes all flexibility 14:42 <+roasbeef> please read the existing literature and the recent follow ups 14:43 < stiell> A maximum total, yes. Assuming invoices are non-interactively generated. 14:43 < stiell> But the sender can choose any number of partial payments from one up to said maximum. 14:44 < stiell> Non-interactively. 14:56 < stiell> roasbeef: I did have an idea on how to fix the problem with having to choose a maximum number of flows ahead of time, though. I don't know enough about the onion routing protocol to know how feasible it is, but I was thinking sending back the next hash in the response to an initiated payment. Such hashes are either signed on the fly or have been committed in a hash tree in the invoice. Can the receiver 14:56 < stiell> send back such a hash (and either signature or merkle tree expansion) while keeping the HTLC open? 14:57 <+roasbeef> it's already solved 14:57 <+roasbeef> re-read the original proposal 14:57 <+roasbeef> and the follow ups 15:03 -!- anome [~anome@unaffiliated/anome] has joined #lightning-dev 15:04 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 15:08 -!- kiltzman [~k1ltzman@95.215.47.208] has quit [Ping timeout: 260 seconds] 15:08 -!- anome [~anome@unaffiliated/anome] has joined #lightning-dev 15:10 -!- kiltzman [~k1ltzman@95.215.47.208] has joined #lightning-dev 15:10 -!- Tennis [~Tennis@unaffiliated/tennis] has joined #lightning-dev 15:16 -!- afftfqdv [~fnmyvw@108-234-170-116.lightspeed.jcsnms.sbcglobal.net] has joined #lightning-dev 15:16 -!- afftfqdv [~fnmyvw@108-234-170-116.lightspeed.jcsnms.sbcglobal.net] has quit [Client Quit] 15:17 -!- Tennis [~Tennis@unaffiliated/tennis] has quit [Read error: Connection reset by peer] 15:31 -!- MaxSan [~user@86.105.9.67] has joined #lightning-dev 15:34 -!- spinza [~spin@196.212.164.26] has quit [Quit: Coyote finally caught up with me...] 15:42 -!- anome [~anome@unaffiliated/anome] has quit [] 15:43 -!- spinza [~spin@196.212.164.26] has joined #lightning-dev 15:50 -!- bsm117532 [~mcelrath@2601:184:417f:5f02:b089:1fd0:37d9:c2f3] has joined #lightning-dev 15:58 -!- wxss [~user@209.58.165.1] has quit [Quit: leaving] 16:00 -!- TeaPanda [~TeaPanda@unaffiliated/teapanda] has quit [Read error: Connection reset by peer] 16:05 -!- danielh_ [~danielh@speedtest.sbbs.se] has quit [Ping timeout: 260 seconds] 16:05 -!- danielh_ [~danielh@speedtest.sbbs.se] has joined #lightning-dev 16:09 -!- melvster [~melvin@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 256 seconds] 16:26 -!- robzon [~robzon@178235204182.warszawa.vectranet.pl] has quit [Read error: Connection reset by peer] 16:27 -!- robzon_ [~robzon@178235204182.warszawa.vectranet.pl] has joined #lightning-dev 16:43 -!- BlackSheep [~yaaic@109.73.88.218] has joined #lightning-dev 16:53 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev 17:19 -!- BlackSheep [~yaaic@109.73.88.218] has quit [Ping timeout: 264 seconds] 17:55 -!- jojeyh [~delphi@2602:306:b8b6:b970:fd7a:d9c1:cf21:55ad] has quit [Ping timeout: 245 seconds] 17:55 < mryandao> reconnect 18:01 -!- dabura667_ [~dabura667@153.142.228.110] has joined #lightning-dev 18:02 -!- dabura667_ [~dabura667@153.142.228.110] has quit [Client Quit] 18:18 -!- HFRadical [~none@103.254.153.99] has joined #lightning-dev 18:18 -!- HFRadical [~none@103.254.153.99] has quit [Max SendQ exceeded] 18:29 -!- jojeyh [~delphi@2602:306:b8b6:b970:91b8:cf9d:84e6:cef5] has joined #lightning-dev 18:39 -!- MaxSan [~user@86.105.9.67] has quit [Remote host closed the connection] 18:53 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 264 seconds] 19:18 -!- riclas [riclas@148.63.37.111] has quit [Ping timeout: 240 seconds] 19:18 <+roasbeef> bitconnect 19:18 < mryandao> lol 19:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 19:39 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 19:39 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #lightning-dev 19:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 19:47 -!- eklitzke [~evan@fsf/member/eck] has quit [Quit: bye] 19:48 -!- eklitzke [~evan@fsf/member/eck] has joined #lightning-dev 21:37 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has quit [Ping timeout: 240 seconds] 21:39 -!- simlay [~simlay@gateway/tor-sasl/simlay] has quit [Remote host closed the connection] 21:39 -!- simlay [~simlay@gateway/tor-sasl/simlay] has joined #lightning-dev 22:50 -!- dcousens [~dcousens@110.140.62.103] has quit [Quit: The Lounge - https://thelounge.github.io] 23:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] 23:36 -!- melvster [~melvin@ip-86-49-18-198.net.upcbroadband.cz] has joined #lightning-dev