--- Log opened Mon Dec 31 00:00:07 2018
02:22 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:36 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
02:45 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
02:57 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 246 seconds]
03:16 -!- nothingmuch [~user@62.102.148.164] has joined #c-lightning
03:33 -!- wraithm [~wraithm@unaffiliated/wraithm] has quit [Ping timeout: 246 seconds]
03:34 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #c-lightning
03:49 < blockstream_bot> [Christian Decker, Blockstream] That's great Yuval, still reading on the crypto details of macaroons, fascinating stuff :) 
04:03 < nothingmuch> it's such an elegant construction
05:10 -!- jasan [~jasan@195.91.48.205] has joined #c-lightning
05:27 < jb55> nothingmuch: how are they different from something like jwt?
05:32 < nothingmuch> somewhat similar, jwt is more complex since canonicalizing JSON is tricky, and they also support asymmetric crypto, but both are used as bearer tokens
05:32 < nothingmuch> however the main distinguishing factor for macaroons, which is appropriate in this case, is the concept of caveats
05:33 < nothingmuch> given a valid macaroon, you can construct a derived one with additional constraints (to be verified & validated by the server) by using the MAC of the antecessor macaroon as a secret for the next HMAC in the sequence
05:37 < jb55> ah
05:38 < jb55> neat
05:42 < nothingmuch> it's actually more even interesting than that, 3rd party caveats allow even more flexible delegation of access rights without burdening the validating server, so for something general purpose it allows very clean separation of concerns
06:13 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #c-lightning
07:00 -!- AmikoPay_CJP [~AmikoPay_@546810F4.cm-12-1a.dynamic.ziggo.nl] has joined #c-lightning
07:28 -!- AmikoPay_CJP [~AmikoPay_@546810F4.cm-12-1a.dynamic.ziggo.nl] has quit [Quit: Leaving]
07:35 < jb55> nothingmuch: another thing I realized I'm going to need is fine-grained access to the pay command for withdrawals. so macaroon's might work for this. 
07:36 < jb55> something like: user requests withdrawal, pay will only accept the command if the password and two factor for that user is correct...
07:37 < jb55> still have to think about how that would be done, because I'm assuming a worse case scenario where my application server is compromised. so an attacker shouldn't be able to forge anything from there to make valid withdrawals...
08:08 < nothingmuch> jb55: that's what 3rd party macaroons can be good for, basically either the app can use a macaroon (by delegating to the user or by hiding from the user) that requires another service to "discharge" the caveat, and this could require 2fa
08:09 < nothingmuch> the 3rd party server and the proxy would need to agree on a secret, and either the user agent orthe app node would be required to obtain such a discharge macaroon from the 3rd party server, which can add caveats such as expiry etc for the proxy to validate
08:14 -!- jasan [~jasan@195.91.48.205] has quit [Quit: Happy]
08:18 < nothingmuch> (the paper also discusses macaroons based on public key crypto, but i'm not aware of any implementation)
09:29 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds]
09:53 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
11:19 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
11:20 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
11:22 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
11:24 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
11:25 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
11:30 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving]
11:33 < nothingmuch> jb55: any thoughts on stealing the socat lifecycle model more or less as is, but conceptually as if "fork" option is always passed to the first addr? i'm not very experienced with it but it seems like a decent way to approach the socket level stuff
11:35 < jb55> nothingmuch: yeah afaict you would need to due to calls like waitanyinvoice which would block other clients
11:37 < nothingmuch> is that re the model in general or just re the always fork assumption?
11:37 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
11:38 < nothingmuch> (and if the former, please elaborate)
11:44 < jb55> nothingmuch: was just referring to the fact if you were handling requests from multiple clients, if you had a simple loop-based accept,recv,etc it wouldn't work because calls to waitanyinvoice would block further requests. So you would need to fork to handle the blocking cases...
11:44 < jb55> if that makes sense...
11:45 -!- deusexbeer [~deusexbee@079-170-138-071-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 246 seconds]
11:45 < jb55> sorry if I'm just repeating something obvious if that's not what you were referring to
11:50 < nothingmuch> indeed, that was part of my assumptions already... what i meant by its lifecycle model is the idea of the 2 addresses not being a server and client socket implicitly, but rather that the first address is handled before the second
11:51 < nothingmuch> i can't imagine this being a general purpose thing without multiplexing & long lived, so it seems like emulating its forking behaviour would be mandatory
13:14 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
13:29 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
14:34 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:40 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
21:07 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-muhzynlsjblcoded] has left #c-lightning []
21:07 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-muhzynlsjblcoded] has joined #c-lightning
22:35 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
22:48 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
22:59 -!- farmerwampum [~farmerwam@184.75.209.90] has quit [Quit: farmerwampum]
22:59 -!- farmerwampum [~farmerwam@184.75.209.90] has joined #c-lightning
23:04 -!- farmerwampum [~farmerwam@184.75.209.90] has quit [Client Quit]
23:04 -!- farmerwampum [~farmerwam@184.75.209.90] has joined #c-lightning
23:20 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds]
--- Log closed Tue Jan 01 00:00:08 2019