--- Day changed Tue Nov 24 2015
01:02 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
01:02 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #lightning-dev
01:03 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
01:03 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #lightning-dev
02:06 -!- CoinMuncher [~jannes@178.132.211.90] has joined #lightning-dev
03:02 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
03:39 -!- matsjj_ [~matsjj@p5B2093BB.dip0.t-ipconnect.de] has joined #lightning-dev
03:43 -!- matsjj [~matsjj@p20030089EA107E047892F20D24EAFAFC.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
04:28 < matsjj_> aj, you around?
04:29 < aj> hey
04:30 < matsjj_> oh great stuff - just thinking through some of the timeframes and scripts for commit transactions... one thing that we completely forgot about while designing onion routing - nodes need to know the absolute cltv timeout - which is related to their depth within a route
04:32 < aj> matsjj_: yeah; they also need to know the tx amount which will decrease slowly as fees get taken in correlation with their depth in the route
04:32 < matsjj_> aj, that is okay though, since they don't know the initial amount
04:33 < aj> matsjj_: they don't know the initial timeout either though?
04:34 < matsjj_> when two nodes add a payment to the commit tx, they will add something like 'paymentR + sig E ||  cltv 2 day + csv 1 day + sig D || revocationH + sig E' ... the absolute cltv timeout increases by 1 day for each hop distance from the receiver
04:35 < aj> you mean "decreases by 1 day" surely?
04:36 < matsjj_> yea pretty much... we start with 20 days between the initial sender and the first hop, and it will decrease with each hop
04:40 < matsjj_> I mean we can always start with a random timeout between 20-40... these timeouts are super difficult to get them right though... 1 day per hop seems to be super high as well, but 1 day should be the minimum for now to be able to revoke
05:10 < aj> matsjj_: yeah, i think you're right. maybe it'll turn out timeout steps of a couple of hours are enough, so starting off at five days and ending up at three or four days would be fine; then you could just randomize your start by a couple of days and it'd be fairly hard to tell
05:11 < matsjj_> hm yea, timeouts between nodes can probably be in the order of hours... 
05:12 < matsjj_> with 6 hours and 20 hops, we end up with 5 days... so this sounds a lot more reasonable
05:51 < matsjj_> aj, that would also mean that you can steal all the money if you can push someone offline for a few hours
05:54 < aj> matsjj_: not all the money, just that transaction; OP_CSV is all the money
05:55 < matsjj_> aj, all the money encumbered in a payment at this state... which may be all money of the channel if I set it up this way 
05:58 < aj> matsjj_: i think it's a bit hard to exploit still
05:59 < aj> matsjj_: suppose timeout is 4 days, and you subtract about four hours at each hop
05:59 < aj> matsjj_: (err, s/4 days/96 hours/)
06:00 < aj> matsjj_: ie, Bob can collect the payment at up to 100 hours, Carol at 96 hours, and Dave at 92 hours
06:00 < matsjj_> there are two unknown for nodes as well, as they don't know the initial timeout nor the amount of total nodes.. so even little variance gives quite a good amount of added privacy
06:01 < aj> matsjj_: at 92 hours, Carol *could* safely reject the transaction, and Bob can roughly estimate this. if Carol doesn't do so, he can close the Bob/Carol channel and aim to resolve on the blockchain
06:03 < aj> matsjj_: if Bob sees Carol try to claim the funds from the blockchain anywhere between hour 92-100 Bob can claim the funds from Alice, and is happy; at any time from hour 96+ Bob can get a refund
06:03 < matsjj_> yea, he has 4 hours before carol can refund the tx
06:05 < aj> matsjj_: so i think that's 8 hours when Carol has to knock Bob off the network (so that he can't even access the blockchain), which seems like it should be hard (since he's just being a client using the blockchain at that point, not trying to serve anything)
06:08 < matsjj_> aj, but if we have 4 hours between each hop, it translates into CSV 4 Hours in the script, doesn't it? so Bob can broadcast an old commit later to collect it after the csv delay
06:09 < aj> no, CSV is completely independent
06:09 < aj> CLTV of 96 hours, CSV of 42 days if you wanted
06:10 < matsjj_> I thought so as well, but these two needs to be equal ... otherwise one guy can tear down all channels from nodes within the route
06:10 < matsjj_> http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html
06:14 < matsjj_> If our channel makes it to the blockchain, I am only able to make a transaction and reveal R after the CSV timeout... you however need R within the CLTV-difference in order to pull funds from the next hop in the chain
06:14 < aj> right, that's a problem if your now+DELAY < TIMEOUT, though? i thought the solution was just to bump OP_CSV by timeout-now where necessary?
06:15 < aj> ah yes, right!
06:15 < matsjj_> its a problem because we only use one script output for everything ^^ in the original design where we had another layer of transactions building on top of these, we could abstract revocation and claiming a payment
06:18 < aj> yeah, so now+DELAY < TIMEOUT means the recipient can steal funds, now+DELAY > TIMEOUT means the sender can steal funds?
06:19 < aj> maybe htlc's need different delays on each side of the commitment tx?
06:19 < matsjj_> I don't understand your 'now+DELAY < TIMEOUT' notation :)
06:19 < matsjj_> hmm
06:20 < aj> commitment tx held by bob: [Bob + R + OP_CSV DELAY | Alice + Revoke_Bob | Alice + OP_CLTV TIMEOUT ]
06:21 < matsjj_> aj, thats what I scrambled together recently, trying to understand these... https://gist.github.com/matsjj/3f6dd2a95d11c1f1e1df
06:21 < matsjj_> basically A making a payment to E over B, C, E, A-B and B-C is not written out there
06:21 < matsjj_> oh B-C is written out
06:24 < aj> hmm
06:25 < aj> so i'm confused as to why you have 'csv 7 days' for some things and 'csv 1 day' for others
06:25 < matsjj_> the csv 7 days are luckily independent of the payments, these are just the rest of the balance
06:26 < matsjj_> like before the payment D and E both had a balance of 10 BTC in the channel
06:27 < matsjj_> we can remove the first two lines of each commit tx if we are just interested in actual payment scripts
06:34 < aj> yeah
06:37 < aj> i guess you could just reintroduce layered transactions (especially with segwit), and have the receivers commitment look like "pay to [A+B R | CLTV A]" and have a pre-signed tx spending it signed by A and waiting R and B's sig that spends to "OP_CSV + B || revoke + A"
06:38 < aj> hmm, no you need the ||revoke+A in the first one as well
06:40 < matsjj_> we also need sighash_noinput for these layered transactions, as in this case neither C nor D know R, so they cannot construct the transaction where R is used to claim the payment, and so they cannot build a transaction spending that, without the txid ;)
06:41 < matsjj_> thats only possible with noinput
06:41 < matsjj_> so I guess we are stuck with the 6 hours - 1 day payment/revocation delay for now :/
06:49 < aj> i think segwit is enough for the layered txs
06:49 < matsjj_> hmmm thinking about it, I think you are right
06:49 < matsjj_> as the sigScript is no longer part of the txid
06:50 < aj> enough layers of indirection that it's hard to keep track
06:50 < matsjj_> it is really ugly though :( I really wish we don't need these added layers
06:51 < matsjj_> but they allow us to have these timeframes completely independent... force the R value within 5 minutes, and still being able to revoke for a week after 
09:14 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has joined #lightning-dev
09:31 -!- mustyoshi [~mustyoshi@c-68-37-216-210.hsd1.mi.comcast.net] has joined #lightning-dev
10:00 -!- mustyoshi [~mustyoshi@c-68-37-216-210.hsd1.mi.comcast.net] has quit [Ping timeout: 250 seconds]
10:15 -!- bedeho_ [~bedeho@195.159.234.190] has quit [Ping timeout: 246 seconds]
10:22 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev
11:01 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
11:06 -!- matsjj_ [~matsjj@p5B2093BB.dip0.t-ipconnect.de] has quit []
11:07 -!- matsjj [~matsjj@p5B2093BB.dip0.t-ipconnect.de] has joined #lightning-dev
11:12 -!- matsjj [~matsjj@p5B2093BB.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
11:14 -!- matsjj [~matsjj@162.216.46.180] has joined #lightning-dev
11:20 -!- matsjj_ [~matsjj@p20030089EA107E5AE57FED906E2B14D0.dip0.t-ipconnect.de] has joined #lightning-dev
11:23 -!- matsjj [~matsjj@162.216.46.180] has quit [Ping timeout: 255 seconds]
11:52 -!- mustyoshi [~mustyoshi@c-68-37-216-210.hsd1.mi.comcast.net] has joined #lightning-dev
13:18 -!- mjerr [~mjerr@p5B2093BB.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
13:24 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has quit [Quit: Ik ga weg]
14:52 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:52 -!- mode/#lightning-dev [+o rusty2] by ChanServ
15:04 -!- cfields_ [~quassel@unaffiliated/cfields] has joined #lightning-dev
15:19 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []
15:20 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
15:20 -!- mode/#lightning-dev [+o rusty2] by ChanServ
15:24 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev
16:03 <@rusty2> matsjj_: ping?
16:07 -!- mustyoshi [~mustyoshi@c-68-37-216-210.hsd1.mi.comcast.net] has quit [Remote host closed the connection]
16:32 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection]
16:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zowntxnmndwnhcxr] has quit [Quit: Connection closed for inactivity]
17:28 <@rusty2> matsjj_: So, gmaxwell says "Came up with a scriptpubkey that makes people reveal their private keys in bitcoin", but warns "it's ugly" and is delaying reveal in the hopes someone comes up with a better one.
18:09 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
18:52 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
20:46 < aj> rusty2: i think i figured out his approach, and (if so) it's totally ugly :) but worst case, we could use an ugly solution, then provide that as an argument for why a new op code that makes it clean/simple/efficient is a good idea...
20:46 <@rusty2> aj: really?  I'm impressed; I gave up!
20:48 < aj> rusty2: he also pointed out that you can use point addition for the randomisation steps rather than point multiplication; ie R1=g*X, R2=g*P1 + R1, R3=g*P2 + R2. apparently calculating g*X + Y is must faster than ECC Y*X
21:02 <@rusty2> aj: you should mention your solution to gmaxwell, and collect your prize!*   [* prize may not exist]
21:03 < aj> rusty2: i just did, and his solution is different /o\
21:47 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds]
22:05 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
22:05 -!- mode/#lightning-dev [+o rusty2] by ChanServ
22:22 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
22:41 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
22:41 -!- mode/#lightning-dev [+o rusty2] by ChanServ
22:48 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds]
23:08 -!- mjerr [~mjerr@p5B2093BB.dip0.t-ipconnect.de] has joined #lightning-dev
23:22 < matsjj_> aj, heh! thats so cool though, I would go with an ugly solution any day... even though I fail to see how it is possible with all of the math op codes disabled
23:25 < aj> matsjj_: it's the splice/string operations that is harsh. OP_LEFT would make it trivial (and like rusty pointed out, segwit makes it easy-ish to re-enable disabled op codes!)
23:26 < matsjj_> you do it with string operations?! :o
23:27 < matsjj_> yea I read his post, but I still fail to see how to enable a soft fork without miner consensus
23:27 < aj> matsjj_: it just makes it a soft fork rather than a hard fork
23:28 < matsjj_> ohhh right, never considered these are hard forks - yea indeed, much easier then
23:28 < aj> matsjj_: string operations makes it easy -- you just force them to present two signatures that are mostly the same, and ECDSA breaks
23:29 < matsjj_> huh? but where does this get us in presenting the private key?
23:29 < aj> matsjj_: (two signatures by the same key, with the same r, but different s allow you to derive the private key)
23:29 < matsjj_> ohhhh right
23:30 < matsjj_> wow
23:30 < matsjj_> thats indeed ugly haha - but very clever
23:30 < aj> nono, that's not ugly
23:30 < matsjj_> computation to derive the private key is trivial, right?
23:31 < aj> yeah, it's just bignum modular arithmetic, not even ECC calculations
23:31 < matsjj_> yea I see that it is a very cheap way to do it, so indeed not ugly... 
23:31 < aj> ugly is doing it without the string ops. mine involves evaluation six signatures as part of the script, and i'm not sure it's safe
23:32 < aj> (ie eight sigops for every htlc, equivalent of 400 bytes per output)
23:33 < matsjj_> and its using only active op?
23:33 < aj> yeah!
23:33  * matsjj_ claps
23:33 < aj> but like i said, i'm not sure it's safe
23:34 < aj> and gmaxwell's solution (also using only active ops) is different
23:34 < matsjj_> but 400 bytes is quite a lot, especially since the counter party can force the broadcast on you
23:35 < aj> yeah (it's not really 400B, i'm translating the sigop limit per block into a comparable number of bytes -- ie 50B per sigop)
23:36 < aj> but still, real privacy with current bitcoin script???
23:36 < matsjj_> yea the privacy we gain by doing so is sooo fantastic
23:37 < aj> it's great for atomic swaps across chains too
23:38 < aj> (you and i can safely swap 100 LTC for 1 BTC, but no one else can associate the two transfers)
23:39 < matsjj_> I guess with ECKeys there are also ways we can correlate the keys to a new pubkey, so it remains a simple one key script
23:44 < aj> hmm
23:45 < aj> if anchor transactions sit in the blockchain for a long time while a channel stays open, they'll get high priority when spent, and if priority overrides fees, they'll be free :)
23:45 < matsjj_> except that core decided on monday that the whole transaction priority thing should get deleted ;)
23:46 < aj> yeah :)
23:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kssotdfzbjvavpmi] has joined #lightning-dev