Cezary Dziemian [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-05 📝 Original message: Good morning group, My ...
📅 Original date posted:2019-06-05
📝 Original message:
Good morning group,
My friend came to similar (almost the same) conclusions over a year ago,
and I were working on implementation of this. I had first working prototype
based on clightning (but not trustless), but at that time there were so
many troubles with c-lightning, co I decided to make this solution based on
LND. Unfortunately, I have other issues with LND also. There are some API
method missing in LND and c-lightning also. This is the reason, I'm
seriously tired doing this. I think, that was mistake to start working on
that without more talks with you and community.
Tomorrow, we scheduled to talk if it make sense to continue. A lot of
options are possible. If you, agree, it would be valuable to make such
thing, I can work on it as full time job (my friend is wiling to pay for
that). I prefer to write it in Java rather and also need your support
especially in terms of lack of some API methods.
Please let me know, if we can build cross-implementation group to work on
such thing and if you are willing to help.
Best Regards,
Cezary Dziemian
pon., 12 lis 2018 o 11:05 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> napisał(a):
> Good morning lisa,
>
> > can simply close the channel. So if I'm charging for liquidity, I'd
>> actually
>> > want to charge for the amount (in mSAT/BTC) times time.
>>
>> So perhaps you could make a market here by establishing a channel saying
>> that
>>
>> "I'll pay 32 msat per 500 satoshi per hour for the first 3 days"
>>
>> When you open the channel with 500,000 satoshi donated by the other guy,
>> you're then obliged to transfer 32 satoshi every hour to the other guy
>> for three days (so a total of 14c or so).
>>
>> If the channel fails beforehand, they don't get paid; if you stop
>> paying you can still theoretically do a mutual close.
>>
>
> 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.
>
>
> I believe not?
> I do not see any terms in the contract regarding payments through the
> channel other than the "liveness" payment.
> So regardless of activity (or lack of activity) in the channel, the above
> payments should be made.
> If the taker misses a payment, the maker closes the channel outright,
> freeing itself from the obligation.
> If the maker refuses to route, it loses out on potential routing fees.
> Any activity through it do not seem to matter.
>
> This mechanism may actually be superior to the CLTV-encumberance I and
> Rene proposed.
>
> Regards,
> ZmnSCPxj
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190605/36f9459b/attachment.html>;
📝 Original message:
Good morning group,
My friend came to similar (almost the same) conclusions over a year ago,
and I were working on implementation of this. I had first working prototype
based on clightning (but not trustless), but at that time there were so
many troubles with c-lightning, co I decided to make this solution based on
LND. Unfortunately, I have other issues with LND also. There are some API
method missing in LND and c-lightning also. This is the reason, I'm
seriously tired doing this. I think, that was mistake to start working on
that without more talks with you and community.
Tomorrow, we scheduled to talk if it make sense to continue. A lot of
options are possible. If you, agree, it would be valuable to make such
thing, I can work on it as full time job (my friend is wiling to pay for
that). I prefer to write it in Java rather and also need your support
especially in terms of lack of some API methods.
Please let me know, if we can build cross-implementation group to work on
such thing and if you are willing to help.
Best Regards,
Cezary Dziemian
pon., 12 lis 2018 o 11:05 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> napisał(a):
> Good morning lisa,
>
> > can simply close the channel. So if I'm charging for liquidity, I'd
>> actually
>> > want to charge for the amount (in mSAT/BTC) times time.
>>
>> So perhaps you could make a market here by establishing a channel saying
>> that
>>
>> "I'll pay 32 msat per 500 satoshi per hour for the first 3 days"
>>
>> When you open the channel with 500,000 satoshi donated by the other guy,
>> you're then obliged to transfer 32 satoshi every hour to the other guy
>> for three days (so a total of 14c or so).
>>
>> If the channel fails beforehand, they don't get paid; if you stop
>> paying you can still theoretically do a mutual close.
>>
>
> 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.
>
>
> I believe not?
> I do not see any terms in the contract regarding payments through the
> channel other than the "liveness" payment.
> So regardless of activity (or lack of activity) in the channel, the above
> payments should be made.
> If the taker misses a payment, the maker closes the channel outright,
> freeing itself from the obligation.
> If the maker refuses to route, it loses out on potential routing fees.
> Any activity through it do not seem to matter.
>
> This mechanism may actually be superior to the CLTV-encumberance I and
> Rene proposed.
>
> Regards,
> ZmnSCPxj
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190605/36f9459b/attachment.html>;