<div>Good morning lisa,<br></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> &gt; can simply close the channel. So if I'm charging for liquidity, I'd actually<br></div><div> &gt; want to charge for the amount (in mSAT/BTC) times time. <br></div><div> <br></div><div> So perhaps you could make a market here by establishing a channel saying<br></div><div> that<br></div><div> <br></div><div> &nbsp; "I'll pay 32 msat per 500 satoshi per hour for the first 3 days"<br></div><div> <br></div><div> When you open the channel with 500,000 satoshi donated by the other guy,<br></div><div> you're then obliged to transfer 32 satoshi every hour to the other guy<br></div><div> for three days (so a total of 14c or so).<br></div><div> <br></div><div> If the channel fails beforehand, they don't get paid; if you stop<br></div><div> paying you can still theoretically do a mutual close.<br></div></blockquote><div><br></div><div>I think that this can also be gamed by a second, cooperating node that sends payments through the channel to meet the rate and capture the fees for the first. You can make this less likely by charging higher transmission fees that make such an attack infeasible, and it's less 'damaging' than an immediate close in that there's still open capacity available for some time, at least until the 'bogus' payments have drained the capacity that you solicited in the first place.<br></div></div></div></blockquote><div><br></div><div>I believe not?<br></div><div>I do not see any terms in the contract regarding payments through the channel other than the "liveness" payment.<br></div><div>So regardless of activity (or lack of activity) in the channel, the above payments should be made.<br></div><div>If the taker misses a payment, the maker closes the channel outright, freeing itself from the obligation.<br></div><div>If the maker refuses to route, it loses out on potential routing fees.<br></div><div>Any activity through it do not seem to matter.<br></div><div><br></div><div>This mechanism may actually be superior to the CLTV-encumberance I and Rene proposed.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div><div><br></div><div><br></div>