--- Log opened Mon Feb 04 00:00:40 2019
00:50 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
00:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
01:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
01:25 -!- queip [~queip@unaffiliated/rezurus] has quit [Quit: bye, freenode]
01:34 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning
02:13 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:27 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
02:54 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #c-lightning
02:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
03:41 -!- mn3monic [jsz@unaffiliated/mn3monic] has quit [Ping timeout: 250 seconds]
03:42 -!- mn3monic [jsz@unaffiliated/mn3monic] has joined #c-lightning
04:34 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
04:48 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
05:39 -!- Amperture [~amp@24.136.5.183] has quit [Remote host closed the connection]
05:49 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning
08:15 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
08:25 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
08:35 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
08:41 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning
08:44 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
09:03 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
09:04 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
09:55 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
09:59 <@cdecker> t0mix: you can actually specify the entire route when using `sendpay` instead of `pay`
09:59 <@cdecker> `pay` internally uses `getroute` followed by `sendpay` :-)
10:28 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
10:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
11:11 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #c-lightning
12:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
14:10 < t0mix> cdecker, I noticed. but I have to manually modify the route - increase delay, increase msatoshi for each hop. or, am I doing it wrong?
14:13 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:18 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
14:24 < ctrlbreak> rusty: Obviously didn't intend any offence or really even any gender/species assumptions using my colloquialism :-S... sometimes I slip up from my go to 'homies'. lol.
14:24 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 256 seconds]
14:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
14:34 < molz> lol
14:35 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 256 seconds]
14:35 < molz> no worries rusty made the same mistake once :x
14:36 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
14:52 < t0mix> cdecker, I mean, I have to manually modify the route IF I want to sendpay from specific channel
15:00 -!- ebx [~ebx@unaffiliated/ebex] has quit [Quit: bye]
15:03 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
15:05 < rusty> niftynei: I've been thinking about reproducible builds.  Ideally, I'd like to use a released distro (ie. vanilla from install medium, no upgrades), but there's no reliable source of the additional packages we need.  So I think we need to pick versions of those, have the sha256sums in the repro-build script itself, and host them somewhere.
15:12 < ctrlbreak> rusty , molz ... I dig: setchannelfee <short-chanid-or-peerid> <base> <ppm>
15:12 < rusty> ctrlbreak: https://github.com/ElementsProject/lightning/issues/2316
15:14 < ctrlbreak> I've been stewing on something for a couple weeks based on somethings I learned while looking at 'strange fee values' power users like Rompert were setting. 
15:15 < ctrlbreak> I need to understand better how get/query route functions factor in fee settings but....
15:15 < ctrlbreak> I think I have a concept for something I've kinda been calling a 'Rompert Gate' or 'Valve' in my head ;-)
15:15 < ctrlbreak> I just wish I wasn't back to a 8-6 job now :-S...
15:16 < ctrlbreak> ima sketch something up and share with you guys.
15:16 < ctrlbreak> F%$@%$#.
15:16 < ctrlbreak> Homies.
15:18 < jb55> I'm not too familiar with the HTLC code but would it be difficult to implement this? https://github.com/lightningnetwork/lnd/pull/2455 does it require a bolt?
15:21 < jb55> I'm interested in building a plugin that does recurring payments to a node using this
15:25 < molz> ctrlbreak, hahahaha
15:26 < molz> can i tell rompert? lol
15:26 < ctrlbreak> Yes.
15:26 < rusty> jb55: yes, it needs a bolt.  It will probably get one despite my opposition, since doing it Right is much more work.
15:26 < ctrlbreak> Because I've pretty much convinced myself that he/they are probably implementing something similar.
15:35 < ctrlbreak> Here you are.  This is what I've been thinking about, and why I would desire the ability to have fine grained control over per channel fees: https://imgur.com/a/2GnkVYh
15:37 < ctrlbreak> THis is just the general idea.  It may be crazy and not feasible.  Obviously the function of the asymptotic curve should be configurable... and I personally imagine a long tail in the "nominal fee range" between 0.5 and 1.... but you could also mirror it I guess :-S ?
15:38 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
15:38 < ctrlbreak> Anyway.. just a concept.  Threw the fuzz value in there so that you could at least attempt to obfuscate and frustrate someone trying to suss out channel balances and 'money flows' via analysis.
15:40 < rusty> ctrlbreak: yeah, it was assumed early on that we would tweak fees to try to rebalance.
15:41 < ctrlbreak> lol.. oh!
15:42 < rusty> ctrlbreak: but two things happened.  First, we had lots of other things to do :)  Second, fees are so low it's unlikely to work. 1ppm is ridiculous.
15:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
15:44 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
15:45 < ctrlbreak> rusty: agreed, and 1ppm could be your target 'nominal fee'... and you could just raise it dramatically if your local balance on the channel is non-existent.
15:46 < rusty> ctrlbreak: the problem is that, at existing fee levels, that's basically the same as disabling i.
15:46 < ctrlbreak> so as to prevent a (sane) route generator from proposing it.
15:47 < ctrlbreak> If I have a channel with 0 local balance and 1mil sat capacity... I can't route through it anyway.  Setting a fee of something insane... like channel capacity in that case would have the effect of simply saying (I can't route through this channel at the moment... but it does exist! :-P)
15:48 < ctrlbreak> I'm pretty confident this is what Rompert was doing as part of some script he created (which also apparently had bugs relating to CLTV values, but that's a diff story ;-)
15:48 < rusty> ctrlbreak: we considered not sending a channel_update at all until we ahve some capacity.  But niftynei pointed out that's an active data leak, as to who funded the channel.
15:48 < rusty> ctrlbreak: indeed, I agree.
15:49 < ctrlbreak> Yeah, I understand that implementing something like I drew definitely leaks information about the state of the channel balance...
15:50 < ctrlbreak> ...Just an idea :-)
15:50 < jb55> rusty: what is the right way to do it?
15:54 < molz> rusty, btw, about what you said:  <rusty> molz: you can't, that's a deanonymizaion vector.  You can see a payment go past, then probe to see if it went where you think it did... :(
15:54 < jb55> rusty: referring to id:87sh0ke4rt.fsf@rustcorp.com.au ?
15:54 < molz> you still can know by looking at the code that the invoice has been paid
15:55 < rusty> jb55: bolt11 "offers".  Basically a template invoice; you send a message to the payee to get the real invoice, then pay.
15:55 < jb55> I see
15:56 < rusty> molz: ?   I think not, since all failures (wrong payee, right payee) will look the same?
15:56 < rusty> jb55: yeah, that thread.
15:59 < molz> rusty, this code:  if (!wallet_invoice_find_unpaid(ld->wallet, &invoice, payment_hash)) {
15:59 < molz> 		failcode = WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS;
15:59 < molz> 		goto fail;
16:00 < rusty> molz: sure, and that's the same codepath whether it's a paid invoice or a completely unknown one?
16:01  * rusty is confused...
16:02 < molz> well it can be figured that it's been paid, right?
16:03 < molz> also, paying more fees to obfuscate the amount.. can't people figure out by doing some simple math? 
16:04 < rusty> molz: let's start again.  An intermediary node sees a payment succeed.  It can't probe various endpoints to see which one was the target of the payment, since it gets the same error whether it guesses the right endpoint or not.
16:04 < rusty> molz: fee fuzzing is more about obscuring path length than amount.
16:06 < molz> i thought you said 'round numbers are not anonymous' or something so i thought fee fuzzing to obscure the amount 
16:08 < jb55> rusty: is the idea that the more complicated way retains proof of payment? In my case that's not needed. I just need one-off, potentially anonymous, recurring donations. spontaneous payments + cron pay plugin seems to solve this.
16:08 < rusty> jb55: even donations need receipts.
16:09 < molz> jb55, that PR is not quite complete 
16:09 < rusty> jb55: I mean, in the current lightning network we totally go on trust.  But designing for that is a huge mistake.
16:10 < rusty> If I don't get a receipt for my virtual graveyard tulips it's OK.  When lightning grows up, it won't be.
16:10 < rusty> Similarly, we don't need HTLCs or penalty transactions right now.  Would be *way* simpler!
16:11 < rusty> Nor do we need onioning
16:12 -!- rh0nj [~rh0nj@88.99.167.175] has joined #c-lightning
16:14 < jb55> sigh guess I should take a look at this schnorr moon math to understand what you
16:14 < jb55> 're saying
16:20 < jb55> this email thread is helping
16:34 -!- mn3monic [jsz@unaffiliated/mn3monic] has quit [Ping timeout: 250 seconds]
16:35 -!- mn3monic [jsz@unaffiliated/mn3monic] has joined #c-lightning
16:47 < rusty> jb55: turns out I was wrong.  Schnorr is not enough for what I wanted to do, hence the bolt11 offer -> invoice dance
16:52 -!- Amperture [~amp@24.136.5.183] has joined #c-lightning
16:57 < jb55> rusty: in my use case the offer invoice dance would be ok if I could do it automatically. I think I would just need the first bolt11 invoice to kick off a subscription... perhaps it has metadata that describes what future offers should look like?
16:57 < jb55> if that makes sense
17:01 < jb55> The flow would be: user pays the first subscription invoice. Then the node would register a subscription. Every month it sends an offer, auto-paying a new invoice.
17:07 < jb55> and I guess the server could adjust the invoice amount each month if they're priced in fiat which is nice
17:08 < jb55> well wait... 
17:08 < jb55> probably wouldn't want to auto-pay that then...
17:08 < jb55> hmmm
17:14 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
17:27 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
17:55 <@niftynei> rusty re: reproducible builds gitian is a pretty  nice set of tools for doing 'all that' wrt vanilla distro plus hashes of all included packages
17:56 <@niftynei> jb55 what's wrong with auto-paying if the stuff is priced in fiat?
17:56 < rusty> niftynei: where do I get a vanilla distro though?  And why should I trust gitian?  Last I looked, it was impossible to build bitcoind reproducibly without it, which would be ideal.  I don't mind if people use gitian to reproduce my build, but I want to do it in raw hw.
17:56 <@niftynei> i see
17:56 < jb55> niftynei: was thinking about the situation where an evil server returns a large amount
17:57 < rusty> jb55: exactly.
17:57 <@niftynei> i mean you can do gitian on raw hardware 
17:57 < rusty> jb55: yeah, your app needs to have some guidelines for fiat.
17:57 <@niftynei> actually i'm not exactly sure what you mean by 'raw hardware' in this case
17:57 < rusty> niftynei: really?  I though it did everything inside a VM.
17:58 < rusty> niftynei: install ubuntu.  Build.  Check binaries match.
17:58 <@niftynei> i mean it does but there's two layers of VMs, one of which is optional
17:58 < rusty> niftynei: one too many :)
17:59 <@niftynei> if you're already running an ubuntu distro (ie me), you can just straight up run the lxc(? cna't remember acronym) container
17:59 <@niftynei> realistically i thnk you're gonna want the container
17:59 < rusty> niftynei: sure, but who built that container?
17:59 <@niftynei> oic
17:59 <@niftynei> ahahaha
17:59 < jb55> hmm I should try a gitian build on nixos... last I tried it seems like they required ubuntu to build for some reason...
18:00 <@niftynei> cory fields + carl dong(?) were working on something called turtles that bootstraps from clang/gcc
18:01 < rusty> niftynei: so, it's fairly easy to turn off ubuntu updates do you get the same packages as the day it shipped.  Then you check that they're the same versions (and, why not, sha256sum).
18:01 <@niftynei> i couldn't get it to build when i tried but i also didn't try allll that hard
18:02 <@niftynei> jb55 i'm curious what the user interface is that you have in mind for recurring payments
18:02 < jb55> niftynei: same as current ux with bolt11 invoices, except your node remembers to pay every month.
18:02 <@niftynei> like ... imo you could do something lowkey with emails
18:02 < jb55> niftynei: yeah I have that now
18:03 < jb55> but was hoping for something more streamlined
18:03 <@niftynei> but i recognize that not everyone has as neat an inbox as mine :D
18:03 < jb55> would be nice to look at your node and see all the current subscriptions, since its such a common scenario
18:04 < jb55> having to deal with 15 subscriptions via your email every month is not user friendly
18:04 <@niftynei> yeah but rusty would you be posting/hosting the 'blessed' ubuntu distro then?  or who's doing the from source check of the ubuntu version you pick?
18:04 < rusty> niftynei: I would use the existing ISOs, yes.
18:05 <@niftynei> rusty: maybe i'm being dense but i don't quite get how wrapping that in a container is problematic?
18:06 < rusty> niftynei: it's far harder to me to audit.
18:06 <@niftynei> i seee. so it's not the iso that's the bugbear, it's the container... so to speak
18:07 < rusty> niftynei: using kvm/a container is OK for reproduction, but someone should do it bare metal.
18:07 <@niftynei> you need the container for the reproducibility, but for the gold standard you want raw metal
18:07 <@niftynei> ok yeh i get it now :ok:
18:08 <@niftynei> my impression from the bitcoin project was that they just trust the masses, to an extent
18:08 <@niftynei> like if X people manage to repro then we're ok
18:09 <@niftynei> jb55: my intuition around the recurring payment problem at the moment is that it's more of a wallet software issue than anything
18:10 <@niftynei> ideally you'd have some fancy wallet that shows you 'recurring payments' (maybe all endpoints that it hits to pay?) 
18:10 < jb55> niftynei: the problem right now is that there's no standard way to request a new invoice to pay
18:11 <@niftynei> w/ wallet side controls that allow you to gate what amounts are 'autopayable' and what requires a re-ack of permission
18:12 <@niftynei> ah good point. 
18:12 <@niftynei> yeah, the model i've got in my head requires your wallet knowing who to ask for what when
18:12 < jb55> niftynei: my idea was to create a clightning plugin that either does spontaneous payments of a configured amount, which doesn't need new invoices but rusty says that's not a good idea
18:13 < rusty> jb55: that's a bit harsh. I think it might be a useful stepping stone...
18:13 < jb55> rusty: yeah perhaps if there was an upgrade path from there
18:14 <@niftynei> from a vendor perspective, i think there's a lot of value for having a protocol for pushing invoices to nodes
18:14 <@niftynei> 'pushing' more like sending to their 'pay me' queue
18:15 <@niftynei> would that solve the problem you're looking to tackle with the spontaneous payments jb55?
18:17 < jb55> niftynei: yup that work work as well. then the recurring payment plugin would use that feature, with an additional caveat of only *autopaying* if the returned invoice amount is less than or equal to a configured amount
18:17 <@niftynei> yeah. i don't think that's something in the spec atm, but i could see building such a queue via plugins as a secondary protocol in a way, at least to tryout
18:18 <@niftynei> the problem is getting it widely understood across the ecosystem tho 
18:18 <@niftynei> gurgh
18:18 <@niftynei> aside from subscriptions tho, it'd be hella great for business transactions too tho
18:19 < jb55> perhaps recurring payments could be standardized so that any wallet could register subscription payments, but the 'offer -> invoice' dance is a nice stepping stone and perhaps could be used for other features.
18:19 <@niftynei> totally!
18:20 <@niftynei> rusty: what's the magic for getting fatal() calls to log?
18:20 < rusty> niftynei: hmm, they should log....
18:20 <@niftynei> this specifically is a db_fatal log?
18:21 <@niftynei> if that's helpful? i turned on developer & valgrind and have log-level at debug
18:22 <@niftynei> i was trying to re-run a database upgrade and it was failing silently
18:27 <@niftynei> there's messages in here about only being reachable for testing? https://github.com/ElementsProject/lightning/blob/master/wallet/db.c#L461
18:39 <@niftynei> ack <roasbeef> y'all set max in flight to max uint64, which is greater than the cahnnel capacity
18:40 < rusty> niftynei: that's because db_fatal() is fatal outside testing...
18:55 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #c-lightning
19:47 < rusty> jb55: is libsodium on nixos?  Have patch to use system one if suitable, updating install instructions...
19:49 < jb55> rusty: it is. sounds good, will update for next release...
20:03 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 244 seconds]
20:11 -!- achow101 [~achow101@unaffiliated/achow101] has joined #c-lightning
21:50 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-evztbxqdurfwpjrm] has left #c-lightning []
21:50 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-evztbxqdurfwpjrm] has joined #c-lightning
22:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
23:17 <@niftynei> oh i see. is there an expectation that the fatal() messages log somewhere?
23:51 <@niftynei> roasbeef re: the max htlc thing, lnd is enforcing an unspecified requirement that the `max_htlc_value_in_flight_msat` sent in channel opening be less than or equal to the funding satoshi.
23:52 <@niftynei> which means c-lightning nodes can't open channels with LND nodes
23:54 <@niftynei> at least not on whatever version of lnd i'm running atm
23:56 <@niftynei> i realize this is orthogonal to your point about how we're using the max_htlc_inflight as the ceiling for the maximum_msat channel_update field thing, instead of also channel_capacity
--- Log closed Tue Feb 05 00:00:41 2019