--- Day changed Mon Jan 09 2017 00:03 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:20 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 00:22 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: Later.] 00:35 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 00:42 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 01:29 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 01:42 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 01:43 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 02:21 -githubby:#lightning-dev- [lightning] cdecker opened pull request #107: Add coverage reporting (master...coverage) https://git.io/vMlU8 03:24 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #lightning-dev 03:28 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #lightning-dev 04:44 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has joined #lightning-dev 04:45 -!- cjamthagen_ [~user@h-88-153.a230.priv.bahnhof.se] has quit [Quit: WeeChat 1.0.1] 04:56 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #lightning-dev 04:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 04:56 -!- BashCo__ [~BashCo@unaffiliated/bashco] has joined #lightning-dev 05:00 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 248 seconds] 05:01 -!- cjamthagen [~user@h-88-153.a230.priv.bahnhof.se] has joined #lightning-dev 05:06 -!- ZhibiaoPan [~ZhibiaoPa@static-ip-34-127-134-202.rev.dyxnet.com] has joined #lightning-dev 05:10 -!- ZhibiaoP_ [~ZhibiaoPa@1.180.212.101] has quit [Ping timeout: 258 seconds] 05:13 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 05:13 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 05:14 -!- ZhibiaoPan [~ZhibiaoPa@static-ip-34-127-134-202.rev.dyxnet.com] has quit [Remote host closed the connection] 05:20 -!- BashCo__ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 256 seconds] 05:21 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 05:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] 05:57 -!- waxwing [~waxwing@62.205.214.125] has quit [Quit: Leaving] 06:10 -!- waxwing [~waxwing@62.205.214.125] has joined #lightning-dev 06:38 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 06:39 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 06:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 07:04 -!- molz [~molly@unaffiliated/molly] has quit [Quit: Leaving] 07:05 -!- molz [~molly@unaffiliated/molly] has joined #lightning-dev 07:29 -!- Netsplit *.net <-> *.split quits: molz 07:30 -!- Netsplit over, joins: molz 07:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 07:56 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 08:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 08:32 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 08:58 -!- AmikoPay_CJP [~AmikoPay_@a83-163-77-195.adsl.xs4all.nl] has joined #lightning-dev 09:05 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has quit [Quit: Leaving] 09:40 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] 10:05 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] 10:22 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 10:33 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 10:34 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:04 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #lightning-dev 11:32 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-dzgzpnkazzgdqmjg] has joined #lightning-dev 12:01 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 254 seconds] 12:13 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 12:26 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 13:16 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 255 seconds] 13:50 -!- AmikoPay_CJP [~AmikoPay_@a83-163-77-195.adsl.xs4all.nl] has quit [Quit: Leaving] 14:01 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 14:13 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 14:35 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 14:37 -githubby:#lightning-dev- [lightning] cdecker opened pull request #108: makefile: Be more verbose in `check-daemon-makefile` (master...daemon-headers) https://git.io/vM8P5 14:43 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 14:44 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 14:45 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 14:46 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:56 -githubby:#lightning-dev- [lightning] rustyrussell pushed 1 new commit to master: https://git.io/vM8Dr 14:56 -githubby:#lightning-dev- lightning/master af43cc5 Christian Decker: makefile: Be more verbose in `check-daemon-headers`... 14:57 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 14:57 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:58 -githubby:#lightning-dev- [lightning] rustyrussell closed pull request #107: Add coverage reporting (master...coverage) https://git.io/vMlU8 15:01 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:02 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 17:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wmbaukwwojpiytea] has quit [Quit: Connection closed for inactivity] 17:43 -!- BW^- [~Bwbwbwbwb@unaffiliated/bw-/x-2460362] has joined #lightning-dev 17:49 < BW^-> guys, if A is sending funds to B via C and D so the channels utilized are AC, CD, and DB, will the transmitted funds need to pre-exist in ALL of those channels? 17:51 < rusty2> BW^-: yes. 18:06 < adiabat> channels don't exist without funds in them 18:10 < BW^-> rusty2: pm 18:10 < BW^-> rusty2: aha. 18:10 < rusty2> Yes, so everyone needs bitcoin. 18:11 < BW^-> rusty2,adiabat: what does this mean for the overall performance of the network? i guess the first thing it means is that Lightning will initially be the very most practical for small transactions, 18:11 < BW^-> microtransactions indeed 18:11 < BW^-> as the liquidity requirements overall are quite huge 18:11 < adiabat> those will be easiest 18:12 < adiabat> transactions should be a lot smaller than the total amount in the channel 18:12 < BW^-> given this architecture characteristic, what can we understand about Lightning's stability with respect to and fees for delivering a payment a given size at a given time? 18:12 < BW^-> mhm 18:12 < adiabat> by fees do you mean fees to miners? 18:12 < rusty2> BW^-: it depends very much on traffic patterns. But the lightning model lends itself to proportional fees (unlike onchain), so it makes sense anwyay. 18:12 < BW^-> adiabat: fees to intermediaries 18:13 < BW^-> mhm. 18:13 < BW^-> ok interesting. 18:13 < adiabat> if the fees to intermediates is ever higher than an on-chain fee... make a new channel 18:13 < BW^-> adiabat,rusty2: if I am going to pay you over a long time and I don't know yet how much i will pay at this or that time, the lightning model makes a lot of sense. also if I have the same situation of payment in general in lightning, it's the same - i.e., 18:13 < adiabat> so it shouldn't get worse 18:14 < BW^-> adiabat,rusty2: i know i'll pay within lightning over a long time but I don't know yet to whom in the network and when, then, loading up a lightning channel makes a lot of sense 18:14 < adiabat> counterparty doesn't matter much 18:14 < BW^-> adiabat,rusty2: but what about the receiving parties? because someone needs to have a lightning channel with preloaded BTC in it for the receiving chap, no? 18:14 < adiabat> you could say the same way "I'm going to spend my money for a month, and then on the 1st, I'll get paid" 18:16 < adiabat> yeah, if you want to send someone money but they're not able to receive on any of their channels, you can open a new one with them 18:17 < BW^-> adiabat: you mean I open a channel directly to the guy? 18:17 < adiabat> yeah, you can pay him as part of the channel creation 18:18 < BW^-> aha 18:19 < BW^-> adiabat,rusty2: one more Q here - is there any way that there could be more than 2 persons in a Lightning channel? 18:19 < BW^-> i guess it makes sense that it could. 18:19 < BW^-> rusty2: PM =) 18:19 < adiabat> maybe / kindof, it gets real complicated 18:19 < BW^-> rusty2: anyhow not important pm :)) 18:19 < BW^-> adiabat: how come? 18:20 < adiabat> if someone cheats, who gets the punishment? 18:20 < adiabat> is it 2v1? 18:20 < BW^-> yey! 18:20 < BW^-> adiabat: PM too =)) same 18:20 < BW^-> aha 18:20 < adiabat> you can potentially have multiple parties on both sides 18:20 < BW^-> hm 18:20 < adiabat> without them knowing 18:20 < BW^-> adiabat: of what consequence is that.. hmm.. 18:21 < BW^-> adiabat: what if i would devise a local scheme and skip the punishment 18:21 < BW^-> adiabat: can i have three? 18:21 < BW^-> adiabat: or say, 100? 18:21 < adiabat> skip punishment == you broke lightning 18:21 < adiabat> so please tell is if you do! 18:21 < BW^-> =)) 18:21 < BW^-> adiabat: what if i run a lightning-inspired scheme for a limitedg roup or something, with slightly other laws of nature 18:21 < BW^-> no worries 18:21 < adiabat> I mean with schnorr sigs, the sides might appear to each other to be a single entity 18:22 < adiabat> but actually be several parties working together 18:22 < BW^-> adiabat: aha. what does that say about a usecase where A, B, C ... N open a lightning channel to transact with each other, and each of them have a balance within it 18:22 < BW^-> adiabat: so what i want is basically then that any of those A .. N parties can "sue" on the blockchain to get back the payment later 18:22 < BW^-> if any party malbehaves 18:23 < adiabat> problem is, what if C does something bad 18:23 < adiabat> A sues 18:23 < adiabat> B sues 18:23 < BW^-> adiabat: and the most important thing is that noone can steal within that group of A .. N , e.g. if A has 0.1, B has 0.2, C has 0.3 .. and N has 0.4 , then those bitcoins cannot be transfered to anyone else without the respective party commanding of that 18:24 < adiabat> well, you've got these old states, that the blockchain isn't aware of 18:24 < BW^-> adiabat: one way would be simply for all others to say "ok we know C is an axehole" and just reclaim their btc on the network. no need to penalize him, just ignore him forever. 18:24 < adiabat> that might be possible, but 18:24 < adiabat> then there's no penalty 18:24 < adiabat> and free attacks are dangerous 18:24 < BW^-> yeah i see what you mean 18:24 < BW^-> that's a good point. 18:25 < BW^-> adiabat: if I run A .. N , will the channel open transaction be bigger? 18:25 < BW^-> adiabat: also must all parties A .. N participate actively both in the channel open and channel close? 18:25 < adiabat> probably not; even n of n gets turned into a script hash 18:25 < adiabat> channel close would be bigger without schnorr 18:26 < adiabat> open, yes, everyone needs to participate 18:26 < BW^-> cool! 18:26 < BW^-> aha. 18:26 < adiabat> close, no, anyone can close on their own, which is also a problem for many parties 18:26 < BW^-> adiabat: what does that participation [for opening] consist of? 18:26 < BW^-> mhm. 18:26 < adiabat> in current code, you ask them for some pubkeys 18:26 < adiabat> and then ask them to sign some transaction 18:26 < BW^-> so if they just contribute that - and the BTC - right. 18:26 < BW^-> cool. 18:27 < adiabat> they don't contribute BTC 18:27 < adiabat> for them, it's a zero-risk process 18:27 < adiabat> A: "hey give me a pubkey" B: ok, sure, here: 03afbc34.... 18:27 < BW^-> adiabat: wait, and how does that lead to B's bitcoin being locked in the channel? 18:27 < adiabat> A: "Ok sign this with that pubkey" B: ok, sure whatever, 3002131... 18:28 < adiabat> A can send B coin in this process 18:28 < adiabat> or afterwords 18:28 < BW^-> adiabat: question - why have you pursued to do two-person lightning channels rather than multi-person? 18:28 < BW^-> is it because it's easier to calculate on and predict behavior of in a network setting 18:28 < adiabat> way simpler. And it's not simple :) 18:28 < BW^-> networked 18:28 < BW^-> mhm 18:28 < adiabat> even the single funder vs multi-funder 18:29 < adiabat> it doesn't seem too hard to make both parties fund a channel 18:29 < adiabat> A and B both contribute 18:29 < adiabat> but... in practice, it's kindof a mess. Especially UI-wise 18:29 < adiabat> do you tell your software, "I'll put 1BTC in a channel with anyone!" because that seems risky 18:30 < adiabat> or you specify what people, and how much, and when? but if you know all those details, why not just make those channels...? 18:30 < BW^-> adiabat: wait, what's your point about single vs multi funder? 18:30 < BW^-> aha 18:30 < BW^-> gotcha. 18:30 < adiabat> it's why having B's interaction be zero-risk is easier 18:30 < BW^-> adiabat: one question - why exactly is SegWit needed for Lightning to scale? 18:30 < adiabat> in the software, there's no real cost to providing a pubkey 18:30 < BW^-> i saw the paper but maybe there's a more concentrated way to put it 18:30 < adiabat> i dunno "scale" but 18:31 < adiabat> channel duration would be limited without it 18:31 < adiabat> or some other malleabiliy fix 18:31 < adiabat> but at this point we've all coded stuff with segwit so... 18:31 < BW^-> aha. 18:31 < adiabat> the part in the opening process where A asks for signatures 18:32 < BW^-> adiabat: so.. bitcoin.sipa.be/ver9-50k.png maybe in 2018 we'll have segwit? 18:32 < adiabat> and B says, sure, I'll sign something with this pubkey I just made up and gave you 18:32 < BW^-> adiabat: how does segwit help channel duration to be unlimited? 18:32 < adiabat> that signature A gets in the beginning, that happens before A signs 18:32 < adiabat> to fund the channel 18:32 < adiabat> without fixing malleability, B's signature might not work 18:33 < BW^-> adiabat: how why? 18:33 < adiabat> B's signature is spending from the channel txid... which doesn't exist yet 18:33 < adiabat> A hasn't even shown B the transaction, just the txid 18:34 < adiabat> but A could broadcast, fund the transaction, and then the txid changes 18:34 < adiabat> then B's signature points to the old txid which never got confirmed 18:34 < adiabat> so the money is still in the channel... still A and B's pubkey... but.. 18:34 < adiabat> if B disappears, A's money is stuck 18:35 < BW^-> adiabat: ouch, ah. 18:35 < adiabat> so A could lose all their money. B could help, sure 18:35 < adiabat> but maybe B is working with the miner, or keeps the channel hostage 18:35 < BW^-> adiabat: okay so the need for the segwit update is just that you can cement TXID:s and that way get a /more/ robust structure 18:36 < adiabat> so instead, if malleability is sill an issue, you can make the channel not just multisig 18:36 < adiabat> but multisig OR A signs after 1 week 18:36 < BW^-> adiabat: how would that look? 18:36 < adiabat> so if that malleability problem happens, A has to wait a week, and get all the money in the channel back 18:36 < adiabat> annoying but OK 18:37 < adiabat> problem then is, if the problem doesn't occur, you can use the channel for a week, but once the week is up... 18:37 < adiabat> A can just take all the money. So B must close it before that time. 18:37 < adiabat> So then it's finite duration channels which is no fun. And another opportunity to forget to turn your computer on, and lose money. 18:38 < adiabat> oh and the outsourcing stuff woulndn't work either, so more opportunities to forget to pay attention, and lose money 18:38 < BW^-> interesting. 18:38 < BW^-> adiabat: outsource what? 18:38 < adiabat> punishment 18:39 < BW^-> aha. 18:39 < BW^-> interesting. 18:39 < BW^-> ok. 18:39 < BW^-> adiabat: can I read up about a multiple-person lightning channel anywhere? that would be interesting. 18:39 < BW^-> (and so, before segwit, those would live for a predefined amount of time only, and have some other lacks) 18:40 < BW^-> adiabat: btw, why only predefined lifetime before Segwit? 18:40 < adiabat> multi-person is >2? 18:40 < BW^-> adiabat: ah yeah 18:40 < adiabat> I don't know of much writing about that 18:40 < BW^-> mhm 18:40 < adiabat> finite time is because you have to choose that timeout before you start the channel 18:41 < BW^-> adiabat: and with segwit, why don't you need to? 18:41 < adiabat> because you know B's signature will be OK 18:42 < adiabat> so you can close the channel whenver you want 18:42 < BW^-> aha. 18:42 -!- ZhibiaoPan [~ZhibiaoPa@static-ip-34-127-134-202.rev.dyxnet.com] has joined #lightning-dev 18:42 < BW^-> adiabat: and in the malleability situation, you don't know it would be OK because his txid could have changed, so you could be tricked etc., ok 18:43 < BW^-> adiabat,rusty2: btw may I ask an short unrelated bitcoin scripting question? just wanted your very brief take on it, very simple 18:45 < adiabat> ok 18:47 < BW^-> adiabat,rusty2: cool. say that i'm running a centralized "accelerated bitcoin transfers" scheme. the idea is that i cosign your transaction with a secret key I keep, and I promise i'll only sign once, and that way people who trust me will know that any correctly signed transaction with my key, is a valid spend, and therefore in that trusted circle they can accept such transfers instantly (rather than waiting for 3 confirmations) 18:47 < adiabat> sure, that's like greenaddress 18:47 < adiabat> maybe some other companies 18:47 < BW^-> adiabat,rusty2: however, of course it's desirable for participants in such a scheme to be able to escape such a scheme so that i not become some kind of custodian or their funds otherwise are locked up if i disappear etc. 18:48 < BW^-> adiabat: (nice, how does greenaddress do this?) 18:48 < adiabat> I think greenaddress also uses nlocktime 18:48 < BW^-> adiabat,rusty2: to enable that, I would suggest the introduction of a second cosigning key that YOU have, and the only catch here is tha tif you make a transaction with it, then that transaction should only effectuate after 72 hours. 18:48 < adiabat> so if they go down / go rogue, you wait and you can sweep the funds. Haven't looked closely though 18:48 < rusty2> adiabat: yes, they use either signed nlocktime-payback-to-you, or a 2/3 where you control the other (offline) key. 18:48 < BW^-> and any spend done with the first signature should be overriding and have priority. 18:49 < adiabat> there's no "priority" though 18:49 < rusty2> BW^-: yeah, that's more like a vault, requiring covenants. 18:49 < adiabat> I mean there WAS "priority" but they took it out :( 18:49 < adiabat> (but it was something else) 18:54 < BW^-> adiabat,rusty2: em.. can I implement the priority thing? 18:54 < rusty2> BW^-: no, requires introspection, which requires a lot of design, more bikeshedding, and a softfork. 18:54 < BW^-> adiabat: it would be really nice if this was possible. any way of scripting would work. actually someone suggested it's implementable, via BIP 112. 18:54 < BW^-> oouch. ok. 18:55 < adiabat> certainly depends what you mean by "priority" 18:55 < BW^-> rusty2: so even with quirky script workarounds there's no way to attain what i suggested i.e. "instant transfer scheme thanks to centralized signer, with escape-with-delay for user" 18:56 < BW^-> adiabat: i just mean that the user can escape without hurting the value of the centralized instant transfer signing scheme 18:56 < adiabat> you could call lighting states that are newer as having "priority" but the blockchain doesn't directly see that 18:56 < adiabat> well then you have a fundamental conflict... 18:56 < BW^-> adiabat: what i mean here is that if the centralized signing scheme signs a transfer for you for N BTC right now and tells its friends, what about at the same time before they learn to know about it, you escape your BTC too 18:56 < BW^-> adiabat: that would be a big problem 18:56 < adiabat> you want the scheme to prevent double spends, but you also want the user to be able to unilaterally spend 18:56 < BW^-> adiabat: it would make the direct-transfer signing scheme useless. 18:57 < rusty2> BW^-: having the server hand you a signature for a timelocked transaction does exactly what you want. 18:57 < rusty2> (and is what GreenAddress already does) 18:57 < BW^-> adiabat: exactly - but - the unilateral spend would be with a delay such that if he did it the centralized servicew ould hear about it and be able to blacklist that particular element within its scheme 18:58 < BW^-> rusty2: but does that time out after a while so it needs continuous resubmission on the blockchain? 18:58 < BW^-> rusty2: the idea here is the central can spend anytime, but the escape can only be done with 72h delay and subject to that the central didn't attempt to do any spend up to that those 72h passed 18:58 < adiabat> but you don't want the whole network seeing tx A, then someone saying "no tx A is bad, here's tx B" 18:58 < adiabat> and you can't enforce that anyone even saw B 18:58 < BW^-> adiabat: em, well, that would be fine. but just any way to attain this logic would be enough. 18:59 < BW^-> adiabat: i can trust that the Bitcoin gossipping will be effective in less than 72h 18:59 < adiabat> then it's somewhat like the lightning penalty txs 18:59 < BW^-> adiabat: you got into something here, that I can "call lightning states" - what do you mean 18:59 < BW^-> right 18:59 < BW^-> yeah 18:59 < rusty2> rusty2: no. You say "hey, server, I want to spend $1 to foobar, give me your signature". It gives you the signature for the tx, *AND* a signature for a tx which sends the change output to you, timelocked for 72 hours. 19:01 < BW^-> rusty2: in this scheme, the change would just be recycled in the scheme. the involved parties would be Adam, Bob and Cesar, who introduce their BTC into the scheme, to enjoy direct spending to each other, and that is done by that hteir BTC is cosigned by Central. then the last party is Central, which produces signing keys on its secret computer. 19:04 < BW^-> rusty2: if Adam sends BTC to Bob, then, he will just sign his transaction in such a way that the change will be subject to the Central signing rule as usual, as to perpetuate the scheme 19:04 < BW^-> he doesn't need to of course. 19:05 < BW^-> rusty2: so the idea then in the scheme is that Adam, Bob and Cesar are welcome to cancel the signing scheme with Central anytime, but, this hsould be done in such a way that it's synchronized with Central. 19:06 < BW^-> rusty2: Central is watching the blockchain so if any "escape" is sent to the blockchain then if the escapes are programmed by a script to effectuate after 72 or 168h only, then we know Central will have seen it and can simply blacklist that party from its signing directory 19:06 < BW^-> rusty2: and just in case Adam is trying to use Central to make a direct transfer and at the same time attempt to doublespend by escaping too, then, that won't work thanks to the delay. 19:07 < BW^-> (doublespend in the way that Bob and Cesar would take Central's signature as proof of the payment and any other spend on those BTC being done would havoc the scheme.) 19:07 < BW^-> very well. 19:07 < BW^-> rusty2,adiabat: can i do this? I guess lightning-style "suing" can be recycled here. 19:07 < BW^-> how would the solution look approx? 19:07 < BW^-> i do not want to take your time so i hope the above description was more than enough from my side, your input on this one would be much appreciated =) 19:14 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 19:16 < BW^-> adiabat,rusty2: ? 19:17 < rusty2> Good luck developing your scheme! 19:17 < BW^-> in a way i guess you said it already (rusty2 said timelocked transaction and adiabat said use lightning suing mechanism) however a final comment to kind of make what you think apparent would be much appreciated. 19:17 < BW^-> thanks =) 19:19 < BW^-> rusty2: what do you see is possible for an escape mechanism? 19:19 < adiabat> I dunno, blacklists probably aren't sufficient punishment if users are anonymous 19:20 < BW^-> adiabat: that's a good point. e.g. the three confirmations to deposit into the scheme in the first place would be insufficient. 19:20 < adiabat> people might have other ideas in #bitcoin-wizards or #bitcoin maybe? 19:20 < BW^-> adiabat: so some kind of ratelimited registration to the centralized scheme would be needed too. 19:21 < adiabat> but then, rate limited implies not anonymous 19:21 < BW^-> adiabat: thanks. will check there. last thing here now, how would you implement the escape logic, do you feel bitcoin is well suited for it today? 19:21 < adiabat> unless... proof of work 19:21 < adiabat> and then you end up at the genesis block again :) 19:21 < BW^-> will not start a proof of work system with own mining :)) 19:21 < BW^-> right =) 19:21 < BW^-> likely someone will make an open system to solve this sometime next 10 years. 19:21 < BW^-> i was more looking for a bandaid solution in the interim. 19:22 < adiabat> well, bitcoin sortof DID solve anonymous digital scarcity, which is nice 19:22 < BW^-> adiabat: how make the escape? (i got your two suggestions, time locked and reuse lightning sue) 19:22 < adiabat> there are lots of lock time options useful for this 19:23 < adiabat> nLock'd tx, cltv, csv... probably most to look at there 19:27 < midnightmagic> It did not solve anonymous digital scarcity. 19:27 < BW^-> adiabat: right. i thought you could have a preference in terms of how to do it, like, make a script looking this and this. anyhow. in all cases thanks for your suggestions above. 19:34 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 19:40 < BW^-> where is Lightning at now, development-wise? 19:40 < BW^-> i understood the person to person channels work well (presuming SegWit so on testnet). 19:40 < BW^-> what about the upper layer, the routing? 19:40 < BW^-> will be exciting to see it on Litecoin soon :) 19:41 < adiabat> not sure who's working on a litecoin version... guess it wouldn't be hard to port 19:43 < BW^-> mhm. 19:56 < BW^-> adiabat: what library code do you use to deliver schnorr signatures? also does their use rely on script versioning? 20:02 < adiabat> no schnorr sigs yet 20:02 < adiabat> that might be a while. proably a bip later this year 21:39 -!- waxwing [~waxwing@62.205.214.125] has quit [Quit: Leaving] 22:06 -githubby:#lightning-dev- [lightning] rustyrussell pushed 34 new commits to master: https://git.io/vM4CY 22:06 -githubby:#lightning-dev- lightning/master 350d8ed Rusty Russell: log: don't include dstate any more.... 22:06 -githubby:#lightning-dev- lightning/master 4a23309 Rusty Russell: log: rename struct log_record to struct log_book.... 22:06 -githubby:#lightning-dev- lightning/master 7b1a4fc Rusty Russell: utils: add tal_hex() helper.... 22:15 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #lightning-dev 22:42 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 22:52 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 23:02 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds] 23:02 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ycjdzczdatzltaxo] has joined #lightning-dev 23:30 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev