Benjamin [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-30 📝 Original message: >> Still trying to get ...
📅 Original date posted:2015-07-30
📝 Original message:
>> Still trying to get the details right of this protocol.
Me too, but I have some more basic problems.
>> Assume a payment route: Alice<>Bob<>Carol
* how does Alice know Bob and Carol? In Bitcoin there needs to be
out-of-band key exchange, but there is no ID attached to the keys. The
concept of a hub seems to imply either use of standard PKI or Web-of-trust.
Both have big problems when it comes to large, frequent financial
transactions.
* why should Bob even participate in this transaction? Currently I don't
see that incentives are described. That is a fundamental part of Bitcoin
and makes network based intermediation possible (Alice <> computer network
with N nodes <> Carol). From the point of view of a node, Bitcoin does not
have a scalability issue. The only concern of the node is to maximize
knowable profit.
On Thu, Jul 30, 2015 at 4:41 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Christopher Jamthagen <cjamthagen at gmx.com> writes:
> > Still trying to get the details right of this protocol. Please correct
> > me if I am wrong in any of my assumptions below.
>
> > Assume a payment route: Alice<>Bob<>Carol
>
> > Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice
> > updates her commitment tx with Bob including the HTLC output and Bob
> > does the same with Carol.
>
> OK.
>
> > Carol witholds R, forcing Bob to broadcast the commitment tx between
> > Bob and Carol.
>
> Yep, Carol goes non-responsive. Got it.
>
> > Carol can now spend the HTLC output because she knows R and thus
> > revealing it to the world. Alice now also refuses to update the
> > commitment tx with Bob, forcing Bob to broadcast that commitment tx.
>
> Poor Bob. Yep.
>
> > This commitment tx is putting a delay on
> > Bobs ability to spend the HTLC output (as well as all other outputs to
> > him), but Alice can spend the HTLC output if the CLTV has expired.
>
> Indeed, don't ever offer an HTLC less than your delay!
>
> > In most examples I have seen, the CLTV is 2 days between Alice and Bob
> > and 1 day between Bob and Carol, and all CSV delays are 3 days.
>
> I haven't seen an example which included a CSV delay amount.
>
> As the discussion with Joseph is establishing, the minimum CSV you allow
> controls the worst-case HTLC you can accept. CSV of a few hours should
> be OK if you're online all the time. I think...
>
> Anyone want to do some stats on that? CSV uses the median time of last
> 11 blocks, so to some extent you can tell the worst case...
>
> Cheers,
> Rusty.
> _______________________________________________
> 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/20150730/4b836826/attachment.html>;
📝 Original message:
>> Still trying to get the details right of this protocol.
Me too, but I have some more basic problems.
>> Assume a payment route: Alice<>Bob<>Carol
* how does Alice know Bob and Carol? In Bitcoin there needs to be
out-of-band key exchange, but there is no ID attached to the keys. The
concept of a hub seems to imply either use of standard PKI or Web-of-trust.
Both have big problems when it comes to large, frequent financial
transactions.
* why should Bob even participate in this transaction? Currently I don't
see that incentives are described. That is a fundamental part of Bitcoin
and makes network based intermediation possible (Alice <> computer network
with N nodes <> Carol). From the point of view of a node, Bitcoin does not
have a scalability issue. The only concern of the node is to maximize
knowable profit.
On Thu, Jul 30, 2015 at 4:41 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Christopher Jamthagen <cjamthagen at gmx.com> writes:
> > Still trying to get the details right of this protocol. Please correct
> > me if I am wrong in any of my assumptions below.
>
> > Assume a payment route: Alice<>Bob<>Carol
>
> > Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice
> > updates her commitment tx with Bob including the HTLC output and Bob
> > does the same with Carol.
>
> OK.
>
> > Carol witholds R, forcing Bob to broadcast the commitment tx between
> > Bob and Carol.
>
> Yep, Carol goes non-responsive. Got it.
>
> > Carol can now spend the HTLC output because she knows R and thus
> > revealing it to the world. Alice now also refuses to update the
> > commitment tx with Bob, forcing Bob to broadcast that commitment tx.
>
> Poor Bob. Yep.
>
> > This commitment tx is putting a delay on
> > Bobs ability to spend the HTLC output (as well as all other outputs to
> > him), but Alice can spend the HTLC output if the CLTV has expired.
>
> Indeed, don't ever offer an HTLC less than your delay!
>
> > In most examples I have seen, the CLTV is 2 days between Alice and Bob
> > and 1 day between Bob and Carol, and all CSV delays are 3 days.
>
> I haven't seen an example which included a CSV delay amount.
>
> As the discussion with Joseph is establishing, the minimum CSV you allow
> controls the worst-case HTLC you can accept. CSV of a few hours should
> be OK if you're online all the time. I think...
>
> Anyone want to do some stats on that? CSV uses the median time of last
> 11 blocks, so to some extent you can tell the worst case...
>
> Cheers,
> Rusty.
> _______________________________________________
> 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/20150730/4b836826/attachment.html>;