--- Day changed Wed Nov 23 2016
00:41 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-tnmqvwbsllijytjr] has quit [Quit: Connection closed for inactivity]     
01:06 -!- berndj [~berndj@mail.azna.co.za] has quit [Ping timeout: 252 seconds]     
01:16 -!- jannes [~jannes@178.132.211.90] has joined #lightning-dev     
01:17 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has joined #lightning-dev     
01:23 -!- berndj [~berndj@mail.azna.co.za] has joined #lightning-dev     
01:37 -!- laurentmt [~Thunderbi@80.215.210.20] has joined #lightning-dev     
01:40 < stevenroose> has there been any research or discussion about using lightning together with confidential transactions? in order to preserve privacy over the channels that are open
01:40 < stevenroose> this could in fact be tested by deploying lightning on elements alpha
01:41 < gmaxwell> beyond twiddly engineering issues and the question of who you reveal channel amounts to for routing purposes, it should just work. I believe.
01:43 < stevenroose> yeah routing makes privacy a bit more difficult
01:44 < stevenroose> I'm not entirely up-to-date with how routing information is gathered
01:44 < stevenroose> it cannot be based on the state in the utxo set, but should be updated from actual states
01:45 < stevenroose> so how are updates communicated? 
01:46 < stevenroose> on the top of my head it might make sense that when you inform nodes on an updated version of the channel state, instead of providing actual values, you might provide lower values and add a range proof
01:46 < stevenroose> f.e. always provide a few 100 bucks of your channel regardless of the total current balance you have
01:47 < stevenroose> your counterparty can totally undo all your efforts for increased privacy though :p
01:47 < gmaxwell> yes, thats an option. someone more familar with the state of communication should explain it, I'm not current.
01:56 -!- laurentmt [~Thunderbi@80.215.210.20] has quit [Quit: laurentmt]     
02:08 -!- laurentmt [~Thunderbi@80.215.210.20] has joined #lightning-dev     
02:20 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #lightning-dev     
02:20 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
02:20 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev     
02:27 -!- laurentmt [~Thunderbi@80.215.210.20] has quit [Read error: Connection reset by peer]     
02:28 -!- laurentmt [~Thunderbi@80.215.210.20] has joined #lightning-dev     
03:00 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]     
03:04 -!- laurentmt [~Thunderbi@80.215.210.20] has quit [Quit: laurentmt]     
03:20 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev     
04:36 -!- Piper-Off is now known as Monthrect     
06:50 -lightningrfc:#lightning-dev- [lightning-rfc] cdecker pushed 1 new commit to master: https://git.io/v1ePR
06:50 -lightningrfc:#lightning-dev- lightning-rfc/master 4dde8e6 Christian Decker: Merge pull request #18 from lightningnetwork/license...
07:49 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #lightning-dev     
08:04 -!- laurentmt [~Thunderbi@80.215.210.20] has joined #lightning-dev     
08:15 -!- laurentmt [~Thunderbi@80.215.210.20] has quit [Quit: laurentmt]     
08:29 -!- fabrice__ [~fabrice@3.46-14-84.ripe.coltfrance.com] has joined #lightning-dev     
08:30 -lightningrfc:#lightning-dev- [lightning-rfc] sstone opened pull request #21: bolt 3: fix witness scripts (master...fixscripts) https://git.io/v1ejv
08:32 -!- Monthrect is now known as Piper-Off     
08:53 -!- aalex_ [~aalex@64.187.177.58] has joined #lightning-dev     
08:57 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
10:07 -!- Piper-Off is now known as Monthrect     
10:35 -!- aalex__ [~aalex@64.187.177.58] has joined #lightning-dev     
10:35 -!- fabrice__ [~fabrice@3.46-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
10:38 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
11:04 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #lightning-dev     
11:07 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]     
11:26 -!- Monthrect is now known as Piper-Off     
11:32 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev     
11:43 -!- Piper-Off is now known as Monthrect     
11:51 < midnightmagic> cd /nickserv
12:21 -!- Monthrect is now known as Piper-Off     
13:40 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
14:05 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev     
14:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev     
14:59 < rusty> Anyone have thoughts on PRs #19, #17, #16 and #14.  I'm tempted to merge #21 immediately, at least.
15:01 < rusty> roasbeef: so, I am going to submit an RFC today which (1) changes all 'len' and 'num' fields to 16 bits, and (2) uses the crypto packet length as the internal packet boundary.  (1) makes life easier (largest possible field currently is 4MB, which means you don't need to even check), and (2) restricts us to 64kb messages, but simplifies implementation significaantly (decode, process isntead of decode, buffer, process)
15:14 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
15:15 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
15:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev     
16:27 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell created fix-fee-calc (+1 new commit): https://git.io/v1vAy
16:27 -lightningrfc:#lightning-dev- lightning-rfc/fix-fee-calc 1e7e21b Rusty Russell: BOLT 3: Fix fee calculation....
16:28 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell opened pull request #22: BOLT 3: Fix fee calculation. (master...fix-fee-calc) https://git.io/v1vAH
16:32 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
16:39 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell pushed 1 new commit to master: https://git.io/v1vxB
16:39 -lightningrfc:#lightning-dev- lightning-rfc/master de87eaa Fabrice Drouin: BOLT 3: fix witness scripts...
16:40 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell closed pull request #21: BOLT 3: fix witness scripts (master...fixscripts) https://git.io/v1ejv
17:25 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
17:37 < roasbeef> rusty: uses packet length as an internal packet boundary? so as in stuffing multuple messages into an encrypted packet? 
17:38 < roasbeef> the diff between decode+process vs decode+buffer+process is just a couple lines
17:39 < roasbeef> if messages are limited to 64kb, then that means that you need to do fragmentation are the protocol messages level 
17:39 < roasbeef> its feasible that a nodes channel announcements exceed 64kb, with this proposal there'd need to be some continuation link between the two messages 
17:45 < roasbeef> restricing protocol messages to 64kb just seems uncessary, it forces us into a corner requiring a protocol update if we wish to send blocks/headers or w/e over the network in the future
17:48 < roasbeef> the rationale behind encapsulaing the protocol messges (as arbitrary blobs) within the crypto packets is that it decouples the max protocol messge size from the encrypted message transport, the soft limits on the protocol messages size can change independnt of the crypto packet header
17:48 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
17:50 < roasbeef> switching topics for a second: with the way the fee estimation is layed out atm, we'll end up overpaying if wipespread miners end up adopting vsize for fee calculation 
18:02 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mbzagksyprqdjcek] has quit [Quit: Connection closed for inactivity]     
18:10 < rusty> roasbeef: no, channel announce are now split, so can't be over 64k.
18:11 < rusty> roasbeef: and it's not that hard to split msgs, if it ever happens.  (Subheader with counter is the simplest).  More that using 2 byte lengths means you don't even hav to check if it's rational before allocating for decode.
18:11 < rusty> roasbeef: re: fees, I don't think so, since fee is in terms of weight now.
18:12 < roasbeef> by policy, fees are in terms of vsize 
18:12 < roasbeef> in bitcoin core at least 
18:12 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell closed pull request #19: BOLT 2: fix funding_locked announcement signatures. (master...fix-funding-locked-announce-sigs) https://git.io/vXjrQ
18:12 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell pushed 1 new commit to master: https://git.io/v1feQ
18:12 -lightningrfc:#lightning-dev- lightning-rfc/master 0dd4583 Rusty Russell: Merge pull request #17 from lightningnetwork/funding-created-single-byte-outindex...
18:12 < roasbeef> rusty: https://github.com/bitcoin/bitcoin/blob/7490ae8b699d2955b665cf849d86ff5bb5245c28/src/txmempool.cpp#L76
18:12 < rusty> roasbeef: yes, multply by 4 for lightning fees.
18:13 < rusty> roasbeef: note this changed yesterday, with commit 5f5f87d1240ed7e49e3a814cd9dfb89fc9775e26 :)
18:14 < rusty> roasbeef: field is now called 'feerate-per-kw' not 'feerate-per-kb'
18:14 < rusty> byte -> weight
18:14 < roasbeef> yeah I get that
18:14 < roasbeef> but i'm saying that fees are in terms of vsize, not weight
18:14 < roasbeef> for a transaction vsize < weight
18:15 < rusty> roasbeef: is vsize != weight?
18:15 < roasbeef> vsize gives the discount, weight scales up the non-witness part 
18:15 < roasbeef> vsize = (weight + 3)/ 4, iirc
18:16 < roasbeef> but that's policy 
18:16 < roasbeef> default policy* 
18:16 < roasbeef> so it's stil to be seen if miners rip that out or not
18:17 < roasbeef> rusty: so then what's the differece between splitting message at the protocol level (which requires buffering) vs having the protocol message size be larger than the crypto packet size (requires buffering also) 
18:17 < roasbeef> fragmenting messages*
18:17 < rusty> roasbeef: we may never have to do the latter...
18:18 < rusty> roasbeef: I'm still trying to figure out why fees are not simply done on weight...
18:19 < roasbeef> vsize shouldn't never been introduced imo, the initial calculations on segnet{1, 2, 3} were pretty hairy 
18:19 < roasbeef> visze is what actually gives the "fee discount" 
18:20 < rusty> well, if you charged by weight you'd still get a discount, since witness space weighs less.
18:20 < roasbeef> may never have to do the latter? what I mean is that atm, if the message is larger than 65k you split it up amongst several crypto packets, but to the reader it's as if they just read on ebig message 
18:21 < rusty> roasbeef: I'm saying we may never have a packet larger than 64k (we can't at the moment).  So you may never have to write that code.
18:21 < roasbeef> yeh, but we'd be overpaying 
18:21 < roasbeef> so we no longer care about having larger messages in the future? 64k just seems arbitrary restrictive 
18:22 < roasbeef> (for protocol message size) 
18:23 < roasbeef> in either case the code needs to be written, the question is just at which layer the fragmentation+reconstruction happens at
18:23 < rusty> roasbeef: but it does simplify thigns a little today.  Read into buffer, if >= whole packet, decrypt, unmarshal and pass up.
18:23 < rusty> roasbeef: yes, but we may never have to write the fragmentation+reconstruction code :)
18:24 < rusty> roasbeef: since it's not needed today, only in a speculative future scenario where we need to send big packets.
18:24 < rusty> roasbeef: I also suspect that almost every implementation will actually map packets to crypto 1:1 on output, so this won't be tested.
18:28 < rusty> roasbeef: OK, looking at core, vsize == weight / 4, unless ' nSigOpCost * nBytesPerSigOp'  is greater than weight.  Or unless I'm missing something?
18:28 < rusty> roasbeef: policy.cpp:213
18:30 < rusty> roasbeef: I wrote my autogenerator to parse the spec and write the marshal/unmarshal yesterday, and realized I could elide the "if (num > totlen / sizeof(thing)) goto fail" if num was always 2 bytes.
18:38 < rusty> And since our variable nums are always << 64k (error message length, feature bit length, scriptpubkey len, num-signatures)
18:46 < roasbeef> rusty: yeah, although the added sigop scaling is new to me. so I think that confirms my point w.r.t overpaying if we use weight depending on what miners adopt?
18:47 < rusty> roasbeef: I'm trying to think of why miners would use anything other than weight?  Isn't that by definition the optimal thing (modulo sigop limits)
18:49 < roasbeef> yeah it is, but the current policy in bitcoin core uses vsize by default for limiting in order to give a further fee discount to witness heavy transactions 
18:49 < roasbeef> they might end up ripping out the default polciy in favor of just using weight everywhere 
18:50 < roasbeef> i know luke for example would advocate for such an approach 
18:50 < rusty> I am totally confused.  vsize ~= weight / 4.  So they *are* using weight.
18:51 < rusty> What do you mean by "limiting"?
18:52 < roasbeef> i might be wrong, here's my current model: let's say a tx is 1000 vsize, and 4000 weight, the fee rate is 1000 satoshis-per-X, if we go by vsize we pay 1k satoshis by weight we pay 4k satoshis
18:52 < rusty> Nope.
18:52 < roasbeef> per-kX*
18:53 < rusty> roasbeef: vsize = weight / 4.  per-kb-fee = per-kw-fee / 4.  Thus, we calc "weight * per-kw-fee / 1000".   Core calcs "vsize * per-kb-fee / 1000".  
19:00 < rusty> roasbeef: maybe I should spell out feerate-per-kw == feerate-per-kb * 4 in the spec....
19:03 < rusty> roasbeef: how about I change it to "`feerate-per-kw` indicates the initial fee rate by weight (ie. 4 times by the more normally-used 'feerate per kilobyte') which this side..."
19:04 < adiabat> Having both "weight" and "vsize" is ... crazy
19:04 < adiabat> especially since getrawtransaction doesn't return a weight
19:05 < adiabat> only a vsize
19:05  * roasbeef goes to rip vsize out of btcd
19:05 < adiabat> and when you get a block over rpc
19:05 < adiabat> it only tells you the weight
19:05 < rusty> adiabat: well, vsize should really be split into "weight" and "sigop weight" and let the user do the max() operation.
19:06 < roasbeef> the sig op stuff there is "new"
19:06 < rusty> adiabat: vsize is really there because they couldn't change all the fee to be weight-based, not byte-based.
19:06 < adiabat> do any actual transactions exceed the sigop limit...?  maybe just... do something about those?
19:06 < roasbeef> but yeh, guess i'm wrong :) 
19:06 < roasbeef> adiabat: only if you try ;) 
19:06 < roasbeef> like thousands of inputs all packed 
19:06 < rusty> adiabat: this is more sigop density, not sigop total AFAICT.
19:07 < roasbeef> sigops are also currently scaled similar to weight 
19:07 < adiabat> right, which... I guess is a weird edge case that you can't really ban without soft forking...
19:07 < adiabat> could make it non-standard?
19:07 < rusty> adiabat: worse, even without sigop stuff, vsize is lossy since it has to round.
19:07 < adiabat> right, so if you get all the txs from a block
19:08 < adiabat> you still can't quite tell the weight of the block
19:08 < rusty> adiabat: I assume once segwit is everywhere, megatx get softforked out.
19:08 < rusty> adiabat: (ie. > 100k or major sigoppage)
19:08 < roasbeef> check out this beauty: https://www.smartbit.com.au/tx/5f4d2593c859833db2e2d25c672a46e98f7f8564b991af9642a8b37e88af62bc
19:08 < adiabat> rusty: eh, I'm skeptical they'd do that
19:09 < rusty> adiabat: Only way to close CVE-2013-2292 AFAICT
19:09 < adiabat> right, but they worry about nLockTimed txs
19:09 < roasbeef> hmm their segnet explorer got messed up it looks 
19:10 < rusty> adiabat: already non-standard since forever though.
19:10 < roasbeef> policy really doesn't matter though ;) 
19:10 < adiabat> policy matters in practice
19:10 < adiabat> OP_CHECKSIG only turned into OP_CHECKSIGVERIFY in "policy"
19:11 < adiabat> but it's basically a soft fork from a user perspective
19:12 < roasbeef> ok here's one that doesn't have borked data: https://testnet.smartbit.com.au/tx/c23b51d7ac34f4ff852581155c7493d9a88d38abf325cb1524cfd321ff48e309
19:15 < adiabat> how do they / will they determine if giant txs are ok?
19:15 < adiabat> all inputs are segwit?
19:15 < roasbeef> yeah they are all witness keyhash
19:16 < adiabat> that's sortof a non-trivial test though, gotta parse the whole thing first
19:16 < adiabat> guess you can flag all utxos in your db to make it a bit faster
19:16 < roasbeef> sigops are also scaled 
19:17 < rusty> roasbeef: so I can see from our discussion that I'm not going to reverse the decision on 8M packets, so I'll just suck it up and stick with 4 bytes lengths, too.
19:17 < roasbeef> that tx bumps up against the stripped size limit before it starts to hit the sigop limit 
19:19 < rusty> adiabat, roasbeef: BTW, is https://github.com/lightningnetwork/lightning-rfc/pull/14 at all useful for you, or are you going to generate by hand?
19:19 < rusty> (TL;DR: it spits out CSV summary of the messages from the spec)
19:20 < adiabat> i'm totally find w/ 65K messages... only thing that really goes over is blocks
19:20 < adiabat> *fine
19:21 < rusty> adiabat: yeah, I was arguing that it simplifies the layering (1 crypto pkt = 1 message) and lets us take the logical step to 2-byte "num" fields throughout as well.
19:21 < rusty> adiabat: but roasbeef wasn't convinced.
19:22 < adiabat> we don't actually have anything bigger than 65K though right..?
19:22 < rusty> adiabat: nope, not even close.
19:23 < rusty> adiabat: Oh shit.  No, we can have 1200 HTLCs.
19:23 < rusty> We need a sig for all of them, or 76k.
19:23 < rusty> I'll STFU now.
19:23 < adiabat> that seems... excessive
19:23 < adiabat> I thought it was like 100 HTLCs?
19:24 < roasbeef> well you can set up s smaller limit within your channel
19:24 < roasbeef> the 1200 is related to the max you can add yet still have a justice tx that sweeps them all at once 
19:24 < rusty> adiabat: well, user gets to decide.  It was 300, but bolt 5 calc 'Penalty Transaction Weight Calculation' said we can do 1252 HTLCs and still get a single penalry.
19:24 < adiabat> but you can't now anyway...
19:25 < rusty> adiabat: but it means you can do worst case, don't need to worry.
19:25 < adiabat> all penalty ("justice") txs are now 1 input, right?  because the HTLC is 2-stage?
19:25 < rusty> adiabat: you can still make a mega tx which does all penalties at once, save some size.
19:25 < adiabat> ah right, YOU can do that, but the watcher can't
19:26 < rusty> adiabat: yeah.
19:26 < adiabat> that's not really a limit though; you can split that up however you want
19:26 < rusty> adiabat: and in practice you're better off doing all the second-stages, then coming back and dealing with the others I think, using divide-and-conquer.
19:27 < rusty> adiabat: true.  It's something of a leftover from the pre-HTLC-tx method, but the number 1200 is so excessive I think it's reasonable.
19:27 < rusty> and it cuts out one corner case.
19:27 < adiabat> could limit it such that sweeping the whole set fits in 65K :)
19:27 < rusty> adiabat: exactly, 500 per side.
19:28 < rusty> Hmm, no...
19:28 < adiabat> although.. even this, why would a justice tx need to be encrypted and sent over between nodes?
19:29 < roasbeef> it wouldn't? the limit is about the max tx you can make that's still underweight but sweeps eerything 
19:29 < rusty> adiabat: no, restriction would be because commitment needs 1 sig for each HTLC output, plus one sig for each HTLC offered by local node.
19:30 < adiabat> ah, I see, not the penalty tx, the commit message
19:30 < adiabat> has the 2-stage HTLC sigs
19:30 < roasbeef> rusty: how do you run the tool?
19:31 < adiabat> I really like limits of 255... if I'd made bitcoin, txs would have max 255 inputs and 255 outputs
19:31 < rusty> So, if you want commit message in 64k, that means max-htlcs-per-side is 512 / 3.  Well, there's also the rest of the commit pkt...
19:32 < roasbeef> nvm got it :) 
19:32 < rusty> roasbeef: ./tools/extract-formats.py --message-types *.md OR  ./tools/extract-formats.py --message-fields *.md
19:32 < rusty> (Or combination of above... --check-alignment too)
19:34 < rusty> roasbeef: So, max packet size is 65535 - 8 bytes.  commit_sig message is 76 bytes + sigs.  Meaning we can fit 1022 sigs.
19:34 < rusty> Or 340 max.
19:35 < rusty> Let's go back to 300 per side and we're happy again.
19:35 < adiabat> or even 255, then you can label which HTLC with a 1 byte index...
19:35 < adiabat> not that you'll use that ... maybe somewhere..?
19:36 < rusty> adiabat: sure.  "microlightning"?
19:36 < adiabat> 300 is basically 255.
19:38 < rusty> adiabat: OK, I'll spec something up, see what it looks like.
19:38 < rusty> (I'm procrastinating sice I don't want to write tests for my autogenerated marshal/unmarshal code...)
19:41 < roasbeef> we already have a max-num-htlcs field, implementations can limit that based on w/e prefernces, hard limits should be based on constraints in the layer below us (bitcoin) 
19:41 < adiabat> mm.  I have to deal with deleting stuff from the watcher db ... it's ugly
19:42 < rusty> roasbeef: not really, unless you take the lower of the two values as minimum, you have to deal with the other side's crazy choices.
19:42 < rusty> s/as minimum/
19:42 < adiabat> also once unlimited activates we'll have to change all the max values...
19:42 < rusty> adiabat: well, we'll have to rip out segwit altogether, too...
19:43 < adiabat> I'm sure flexTrans will be pretty much the same
19:45 < rusty> In Trump America, the block sizes you!
19:46 < adiabat> heh... Oh also according to the redditwebs, lightning is the reason GS cancelled their R3 blockchain or something
19:46 < rusty> adiabat: yeah, that is such a combination of smart and stupid I don't know where to start...
19:47 < adiabat> I'm kindof miffed there have been *zero* illimunati attempts to compromise me.
19:47 < rusty> adiabat: although, you should totally do consulting for them since they are saving all that money on R3.
19:48 < adiabat> I actually went to the GS cafeteria a couple months ago
19:48 < adiabat> they didn't take cash.
19:51 < adiabat> Oh, actual lightning-dev: How about having different xor-masks for each user.  It's 1 or 2 extra lines of code and ... doesn't matter but feels vaguely safer
19:52 < adiabat> in theory it makes it harder for a watcher to realize two people are giving it the same channel to watch....
19:52 < adiabat> in practice, it'll be really easy to tell because they're so temporally correlated
19:52 < rusty> adiabat: ah, so "sha(me || you)" ?
19:52 < adiabat> yeah
19:52 < rusty> adiabat: sure, PR it and I'll commit it.
19:53 < adiabat> ok     
19:53 < rusty> adiabat: I think it's good practice to have someone else commit the PRs, even if trivial.
19:57 < rusty> Procrastinating: i=0; while sleep 10; do if [ $(($i % 360)) = 0 ]; then RATE=`wget -q -O- http://api.coindesk.com/v1/bpi/currentprice/USD.json | sed 's/.*"rate":"\([0-9.]*\)".*/\1/'`; fi; bitcoin-cli getblocktemplate | awk '/"fee"/ { FEES += $2 } /"height"/ { HEIGHT = $2 } END { print HEIGHT ":" FEES "($" FEES * '$RATE' / 100000000 ")" }'; i=$(($i + 1)); done
19:59 < adiabat> yeah fees are going up a bit
19:59 < adiabat> on current front page of redditwebs r/btc: "Fees are now well over 5% of the mining reward"
19:59 < adiabat> ... guess where that percentage ends up
20:00 < adiabat> boy will they be mad when they find out
20:00 < rusty> Yeah, this shows how much you get in the latest block with latest bitcoind (with maxblock set to 1M, maxweight 4M) for next block.
20:01 < adiabat> I'm actually kindof anti-CPFP...
20:02 < adiabat> because once that's in (which it is now) they'll probably never soft fork to make only confirmed utxos spendable
20:04 < roasbeef> uhh I don't think a change like that would _ever_ go over well 
20:04 < adiabat> I know... but it'd be so nice
20:04 < adiabat> so much simpler
20:05 < adiabat> validating a block would be easy to parallelize; one thread per tx, no dependencies
20:06 < rusty> OK, updated version.  https://gist.github.com/rustyrussell/25815d53f9174b248c46351e11b2e6f5
20:06 < rusty> 440303:123401888($911.692)=9%
20:06 < rusty> 440304:62908635($464.768)=5%
20:06 < roasbeef> that % of mining reward? 
20:06 < rusty> (That's blocknum:satoshis(USD value)=percentofsubsidy%
20:07 < roasbeef> cool :)
20:07 < adiabat> makes me want to start mining...
20:07 < adiabat> maybe a little late
20:07 < roasbeef> hahah there's always zcash I guess? 
20:07 < roasbeef> mined some ZEC with leetower
20:09 < adiabat> Does anyone actually use the magic ZKP tx types in that?
20:10 < roasbeef> looks like 1% are in shielded addresses according to https://explorer.zcha.in/statistics/network
20:11 < adiabat> huh, that's OK I guess.  But not great for anonymity if your set is only 1% of the rest of the network
20:12 < adiabat> also that "Cumulative Founder's Reward".... we definitely should have made [ANN] Lightning Sparx (SPX)
20:18 < roasbeef> it isn't too late ;) 
20:18 < roasbeef> some lightning-dev: we should prob have a test vector or two for the state-hints since there's a few ways you can encode it
20:18 < roasbeef> like to do set only the top bit in the sequence or the whole byte? 
20:18 < rusty> roasbeef: "The prefixed packet lengths are encoded as a `16-byte` big-endian integer."  ... I think s/byte/bit/
20:19 < rusty> roasbeef: state hints?
20:19 < roasbeef> rusty: hehe yeah 16-bit, I have some changes locally i'll push out soon to the doc also, got some feedback from ethan heilman 
20:19 < roasbeef> err state num encoding
20:20 < roasbeef> in the commit tx 
20:21 < rusty> roasbeef:  cool.  Am tempted to say <len> should cover cyphertext minus its MAC. otherwise you need to test len against < 16 too.
20:21 < roasbeef> mhmm, makes ense 
20:21 < roasbeef> sense* 
20:23 < rusty> "The underscore indicates that only `32-bytes` are extracted from the `HKDF`."  but I see no underscore?
20:23 < roasbeef> yeah, ethan pointed that out too, there was but then the output changed
20:24 < roasbeef> so that bullet point can be removed all otgehter 
20:27 < rusty> roasbeef: we never send a commitment number across the wire., they're implied?
20:28 < roasbeef> they're encoded in the locktime and sequence, I mean what we apply the xor-mask to 
20:28 < rusty> roasbeef: ah!  Right, with you now.
20:29 < rusty> roasbeef: yes, I totally want some test vectors for stuff like that.  As well as clarity in the spec.
20:30 < adiabat> oh also on that, start with commitment #1?
20:30 < adiabat> I've had commit #0 as invalid, seems to help make sense a bit
20:31 < adiabat> can change it though if people want to start on 0
20:31 < rusty> adiabat: you need to send extra data in that case for k0?
20:32 < adiabat> what's k0 here?
20:32 < rusty> adiabat: the first shachain node...
20:32 < rusty> Or you mean just offset by 1?
20:32 < adiabat> yeah I send the first, "revoking" state 0 which never happened
20:33 < adiabat> that way at state 1 you don't have like null values for things
20:33 < adiabat> so you always have a hash-tree when you have a channel
20:34 < roasbeef> seems like less work to just start at zero
20:34 < roasbeef> you already send out zero as part of the initial funding 
20:35 < adiabat> then you have to deal with not having a hash-tree sometimes
20:35 < adiabat> you then start your hash-tree on the second commitment.
20:35 < roasbeef> yeah, you need to save their un-revoked initial hash 
20:35 < roasbeef> same as just having a single item in the tree?
20:36 < adiabat> un-revoked means 0 items in the tree
20:36 < rusty> adiabat: Hmm, checkingn.... my shachain code simply handles a "nothing known" case as expected.  And you always need to keep the current hash(k).
20:37 < roasbeef> mhmm, you always need to hold onto an unreokved
20:37 < rusty> Exactly.
20:37 < adiabat> right, I'm saying if nothing's been revoked, you have nothing stored
20:37 < adiabat> it's a hash-tree with 0 hashes in it
20:37 < adiabat> that's separate from storing the points they're able to revoke
20:39 < rusty> adiabat: well, I always save 49 hashes (the worst case) rather than getting fancy in the db anyway. 
20:42 < adiabat> and just have them as 0s?
20:42 < rusty> adiabat: literally, yes.
20:43 < adiabat> OK... I can switch stuff around to start at commit #0, it's not really a technical thing, I just kindof liked starting at 1
20:43 < adiabat> and having 0 be 'setup'
20:56 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell created clarify-feeweight (+1 new commit): https://git.io/v1fLP
20:56 -lightningrfc:#lightning-dev- lightning-rfc/clarify-feeweight 20987be Rusty Russell: BOLT 2: clarify what feerate-per-kw stands for and how it's calculated....
20:57 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell opened pull request #23: BOLT 2: clarify what feerate-per-kw stands for and how it's calculated. (master...clarify-feeweight) https://git.io/v1fLX
21:04 < rusty> roasbeef: so, the 2 byte length on cryptopackets makes them unaligned (if you decrypt in place).  But if I use a 6-byte "type" header, it gets aligned again.  That's pretty horrible, though.
21:07 < rusty> adiabat: so, are we better off with a 8 byte or 6 byte type field? ^
21:07 < rusty> (or 2 byte type, 4 byte pad)
21:11  * rusty goes for 2 byte type, 4 byte padding.
21:14 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell opened pull request #24: [RFC] BOLT 1, BOLT 2, BOLT 5: 2-byte lengths everywhere. (master...rfc-short-packets) https://git.io/v1ftZ
21:14 < rusty> adiabat, roasbeef: RFC PR done ^^
21:56 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell closed pull request #16: BOLT 7: Use a flags word, not padding. (master...flags-in-routing) https://git.io/vXhpk
21:57 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell deleted flags-in-routing at 4806e27: https://git.io/v1fqP
22:26 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-uifjeeunnenmvqtd] has joined #lightning-dev     
22:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds]     
23:12 -!- aalex__ [~aalex@64.187.177.58] has joined #lightning-dev     
23:18 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 268 seconds]     
23:26 -!- aalex__ [~aalex@64.187.177.58] has joined #lightning-dev     
23:32 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev     
23:33 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 246 seconds]     
23:41 -!- aalex__ [~aalex@64.187.177.58] has joined #lightning-dev     
23:42 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
23:47 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
23:56 -!- aalex__ [~aalex@64.187.177.58] has joined #lightning-dev