--- Day changed Thu Jun 22 2017 00:39 -!- mnkk___ [~mnk4@ip5f5ae92a.dynamic.kabel-deutschland.de] has joined #lnd 01:25 < gaf_> is this something related with lnd work http://litecoin.mit.edu/ 01:43 -!- MaxSan [~one@185.9.19.107] has joined #lnd 02:15 -!- MaxSan [~one@185.9.19.107] has quit [Ping timeout: 268 seconds] 02:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds] 02:30 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lnd 03:13 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 255 seconds] 03:25 -!- MaxSan [~one@185.9.19.107] has joined #lnd 03:27 -!- JackH [~laptop@77.61.5.33] has joined #lnd 03:50 -!- MaxSan [~one@185.9.19.107] has quit [Quit: Leaving.] 03:51 -!- MaxSan [~one@185.9.19.107] has joined #lnd 04:04 -!- MaxSan [~one@185.9.19.107] has quit [Quit: Leaving.] 04:08 -!- MaxSan [~one@185.156.175.51] has joined #lnd 04:19 -!- MaxSan [~one@185.156.175.51] has quit [Ping timeout: 268 seconds] 04:29 -!- deusexbeer [~deusexbee@079-170-136-225-dynamic-pool-adsl.wbt.ru] has joined #lnd 04:33 -github-lnd:#lnd- [lnd] AndrewSamokhvalov opened pull request #224: htlcswitch: increase payment timeout in bydirectional unit test (master...increase_payment_timeout) https://git.io/vQLC2 04:46 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 240 seconds] 05:01 -!- Alina-malina [~Alina-mal@37.157.223.80] has joined #lnd 05:05 -!- JackH [~laptop@77.61.5.33] has quit [Remote host closed the connection] 05:06 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 05:22 -!- MaxSan [~one@185.156.175.51] has joined #lnd 05:36 -!- MaxSan [~one@185.156.175.51] has quit [Quit: Leaving.] 06:33 -!- MaxSan [~one@194.187.251.115] has joined #lnd 06:44 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Changing host] 06:44 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #lnd 07:21 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.8] 07:23 -github-lnd:#lnd- [lnd] halseth opened pull request #225: Add fee negotiation on channel cooperative shutdown. (master...channel-close-negotiation2) https://git.io/vQLMB 08:16 -!- starkness [~starkness@cpe-69-200-236-97.nyc.res.rr.com] has joined #lnd 08:26 -!- vh [9f94bab9@gateway/web/freenode/ip.159.148.186.185] has joined #lnd 08:39 -!- vh [9f94bab9@gateway/web/freenode/ip.159.148.186.185] has quit [Ping timeout: 260 seconds] 08:45 -!- vh [9f94bab9@gateway/web/freenode/ip.159.148.186.185] has joined #lnd 08:45 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #lnd 08:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds] 08:51 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lnd 09:09 -!- [a]akselrod [~aakselrod@gateway/vpn/privateinternetaccess/aakselrod] has joined #lnd 09:09 -!- aakselrod [~aakselrod@gateway/vpn/privateinternetaccess/aakselrod] has quit [Disconnected by services] 09:09 -!- [a]akselrod is now known as aakselrod 09:25 -!- starkness [~starkness@cpe-69-200-236-97.nyc.res.rr.com] has quit [Quit: starkness] 09:50 -!- mnkk [~mnk4@ip5f5ae92a.dynamic.kabel-deutschland.de] has joined #lnd 09:54 -!- mnkk___ [~mnk4@ip5f5ae92a.dynamic.kabel-deutschland.de] has quit [Ping timeout: 246 seconds] 10:06 -!- vh [9f94bab9@gateway/web/freenode/ip.159.148.186.185] has quit [Ping timeout: 260 seconds] 10:27 -!- mnkk [~mnk4@ip5f5ae92a.dynamic.kabel-deutschland.de] has quit [] 10:46 -!- gaf_ [~fag@12.smos-linux.org] has quit [Quit: SMOS - http://smos-linux.org] 10:51 -!- gaf_ [~fag@12.smos-linux.org] has joined #lnd 10:52 -!- vh [bcaa49ad@gateway/web/freenode/ip.188.170.73.173] has joined #lnd 11:01 -!- vh [bcaa49ad@gateway/web/freenode/ip.188.170.73.173] has quit [Ping timeout: 260 seconds] 11:15 -!- vh [bcaa49ad@gateway/web/freenode/ip.188.170.73.173] has joined #lnd 11:51 -!- aakselrod [~aakselrod@gateway/vpn/privateinternetaccess/aakselrod] has quit [Ping timeout: 276 seconds] 12:08 -!- vh [bcaa49ad@gateway/web/freenode/ip.188.170.73.173] has quit [Quit: Page closed] 12:16 < Ylbam> hi, can someone tell me for what reason an invoice is required to send an LN payment? Is it some kind of anti-DoS or antispam measure? 12:18 -!- starkness [~starkness@cpe-67-245-122-112.nyc.res.rr.com] has joined #lnd 12:18 < abpa> Ylbam a nonce is required 12:18 < abpa> Otherwise it can be repeated and a hop can steal 12:18 < Ylbam> you mean the payment preimage ? 12:19 < Ylbam> actually an invoice can be reused many times 12:19 < abpa> Yeah 12:19 < abpa> Not securely 12:19 < Ylbam> I'm ok for the invoice preimage, I understand that. 12:19 < abpa> You reveal the secret so you can only do that one time 12:20 < Ylbam> But as long as it can be reused multiple times, why not allow multiple amounts too? 12:20 < abpa> The reveal is proof of payment 12:20 < Ylbam> still not sure to get it 12:20 < Ylbam> why does it allow to reuse it multiple times then? 12:21 < abpa> If you trust then you can reuse 12:21 < abpa> If you don't need proof 12:21 < abpa> The payment is provable because you reveal the preimage for the rhash 12:21 < abpa> If you do it again, you don't know if you are just revealing the first preimage again 12:22 < Ylbam> what does it prove exactly? 12:25 < Ylbam> are you sure that sending several payment using the same invoice allows a "hop to steal" ? 12:26 < abpa> The hop can pretend it forwarded it by using the old preimage from the previous transaction 12:26 < Ylbam> Is it described somewhere there: https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md 12:26 < abpa> normally roasbeef can explain things but he is not around 12:28 < Ylbam> Found this: "The HTLC contains the payment hash, which is the hash of the payment preimage. Only the final recipient knows the payment preimage; thus when it reveals the preimage to collect funds is considered proof that it received the payment." 12:29 < abpa> That sounds like what I was saying 12:30 < abpa> The preimage is the proof, so you can't reuse it for another payment 12:30 < abpa> That's why you need a new hash for every invoice so that you can have new preimages that aren't known 12:38 < Ylbam> I guess the protocol shouldn't allow to reuse an invoice then, it looks like it's extremely dangerous. 12:39 < abpa> Ylbam definitely 12:41 < Ylbam> But still an invoice could be decorrelated from any payment value 12:42 < Ylbam> could we derived many payment rhashes from one payment preimage, a bit like a HD wallet derive addresses ? 12:42 < abpa> What does that mean? 12:42 < abpa> That sounds reasonable 12:42 < abpa> I don't know why you would want to 12:47 < Ylbam> working for the fun on a dice betting PoC 12:47 < Ylbam> an invoice is created by the server for each bet 12:48 < abpa> Cool 12:48 < Ylbam> in the case of a winning bet I want to be able to send back the funds to the winner immediately 12:48 < abpa> Oh are you the one that made that web interface? 12:48 < Ylbam> but at the moment I need him to create an invoice for that 12:48 < Ylbam> yep I am 12:48 < abpa> Nice that is super cool 12:49 < Ylbam> What would be interesting is only require the player to create one initial invoice and then derive the other ones from that initial ones 12:49 < abpa> Why not just give the player like 50 invoices 12:50 < Ylbam> it's a bit hard to know the amount of the gains before he even starts playing 12:51 < Ylbam> but the dice server generate an invoice for each bet yep 12:52 < Ylbam> the problem is for paying back the winning bets 12:52 < abpa> Let them buy a bet ticket, then they present the bet ticket with their own invoice and if they win you pay their invoice 12:53 < abpa> The bet ticket can just be the rhash 12:53 < abpa> You can encode the bet terms in the memo 12:53 < Ylbam> that's the idea in some way yep 12:54 < Ylbam> I found that process a bit complicated and not very user friendly 12:54 < abpa> What part was difficult? 12:54 < abpa> Encoding the purchase details in the memo? 12:55 < Ylbam> nope having the user create an invoice (possibly useless if bet is lost) for each bet 12:55 < abpa> Maybe they can give you two invoices, one for win and one for loss 12:55 < Ylbam> the user has to copy paste the exact amount corresponding to his bet and win multiplier 12:56 < abpa> Everything can be in the bet ticket 12:56 < Ylbam> in case of loss, everything is lost, in my current implementation 12:56 < abpa> You should send 1 satoshi on losing bets then he gets a notification ;) 12:56 < abpa> So then he just does POST redeem_bet/:rhash and you look up the rhash and pay the appropriate invoice 12:57 < Ylbam> actually the response is immediate so he can watch it on the website 12:57 < abpa> In satoshi dice it was fun to see it confirm 'on the blockchain' 12:57 < Ylbam> what annoys me is that I don't see a way to generate that invoice automatically 12:58 < Ylbam> so the user has to create it manually, that could be error prone 12:58 < abpa> The user should have a client then? 12:58 < Ylbam> and a bunch of never used invoices will probably be created 12:59 < abpa> Maybe bug roasbeef for a 'delete invoice' feature 12:59 < Ylbam> yep that could be a solution, an app that connects to the betting server and generate the win invoices automatically 12:59 < Ylbam> yep those invoices can be deleted for sure 13:00 < abpa> POST create_bet {payout_invoice: "", odds: 0.5, amount: 5000} 13:00 < abpa> returns rhash - then use redeem_bet/:rhash to execute 13:00 < Ylbam> should first require the winning amount (at least with current lnd implementation) 13:01 < abpa> Or... you watch the websocket for the rhash and payout immediately 13:01 < Ylbam> that's the idea 13:01 < abpa> OK so only one post, returns a payment request, pay that, get lucky or get nothing 13:01 < Ylbam> when requiring the winning amount you also get the server seed hash for the provably fair verification part 13:02 < abpa> feature creep 13:02 < abpa> ;) 13:02 < Ylbam> after an intial get to get the server seed and the winning amount 13:02 < abpa> sounds cool 13:03 < Ylbam> but you need to have that client app connected in some way to your lnd node 13:03 < abpa> So it first gives you a hash of the random seed preimage and then shows you the preimage after the bet to prove that it was for real 13:03 < abpa> websocket? 13:07 < Ylbam> not implemented that way yet 13:07 < Ylbam> using a local account at the moment 13:07 < Ylbam> LN is used for deposits and withdrawals 13:08 < Ylbam> but it would still be great if we could derive new invoices from an initial one 13:08 < Ylbam> @roasbeef if you hear us ;) ^^ 13:11 < abpa> It might not be possible, is the amount is part of the preimage? 13:12 < abpa> You could just generate many bet tickets and then ask them to present them all at once 13:12 < abpa> So if you present 10 bet tickets for 100 satoshis you make 1 bet for 1000 satoshis 13:15 < Ylbam> nope the amount is not part of the preimage 13:16 < Ylbam> Don't know if this could be used: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#public-parent-key--public-child-key 13:25 -!- vh [bcaa49ad@gateway/web/freenode/ip.188.170.73.173] has joined #lnd 14:56 -!- aakselrod [~aakselrod@c-107-2-224-91.hsd1.co.comcast.net] has joined #lnd 14:57 -!- aakselrod [~aakselrod@c-107-2-224-91.hsd1.co.comcast.net] has quit [Client Quit] 14:57 -!- aakselrod [~aakselrod@gateway/vpn/privateinternetaccess/aakselrod] has joined #lnd 15:05 -!- belcher [~belcher@unaffiliated/belcher] has joined #lnd 15:09 -!- franks2 [~frank@unaffiliated/franks2] has quit [Ping timeout: 255 seconds] 15:10 -!- chjj [~chjj@unaffiliated/chjj] has joined #lnd 15:37 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 15:39 < Ylbam> looks like shashains could be a solution too and it's already available in lnd 16:27 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 16:36 -!- takinbo [~takinbo@unaffiliated/takinbo] has quit [Ping timeout: 255 seconds] 16:42 -!- takinbo [~takinbo@unaffiliated/takinbo] has joined #lnd 16:42 -!- spinza [~spin@196.212.164.26] has quit [Ping timeout: 255 seconds] 16:45 -!- deusexbeer [~deusexbee@079-170-136-225-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 255 seconds] 16:54 -!- spinza [~spin@196.212.164.26] has joined #lnd 16:56 -!- deusexbeer [~deusexbee@079-170-136-225-dynamic-pool-adsl.wbt.ru] has joined #lnd 17:04 -!- riclas [~riclas@72.210.189.46.rev.vodafone.pt] has joined #lnd 17:05 -!- MaxSan [~one@194.187.251.115] has quit [Ping timeout: 240 seconds] 17:09 -!- MaxSan [~one@194.187.251.115] has joined #lnd 17:11 -!- starkness [~starkness@cpe-67-245-122-112.nyc.res.rr.com] has quit [Quit: starkness] 17:58 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 18:48 -!- riclas [~riclas@72.210.189.46.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 18:56 -!- vh [bcaa49ad@gateway/web/freenode/ip.188.170.73.173] has quit [Ping timeout: 260 seconds] 19:53 -!- Guest97515 [~justin@47.148.176.74] has quit [Remote host closed the connection] 19:53 -!- Guest97515 [~justin@47.148.176.74] has joined #lnd 21:07 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-qouekunvoratxino] has joined #lnd 21:48 -!- MaxSan [~one@194.187.251.115] has quit [Read error: Connection reset by peer] 22:31 -!- chjj [~chjj@unaffiliated/chjj] has joined #lnd 22:37 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Remote host closed the connection] 22:38 -!- Lauda [~quassel@unaffiliated/lauda] has joined #lnd