📅 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>;
Benjamin [ARCHIVE] /
npub17k…sr5tq
2023-06-09 12:43:50
in reply to nevent1q…gugc
Author Public Key
npub17kz55p7ysz4ftvq2xyr2zamc776cygwcm5fdz8ndj3jm5umm65xq4sr5tqPublished at
2023-06-09 12:43:50Event JSON
{
"id": "48feb6f0c8ae72b2c11155ec38e20824f3a106029c68d0b57d206f1c2455722e",
"pubkey": "f5854a07c480aa95b00a3106a17778f7b58221d8dd12d11e6d9465ba737bd50c",
"created_at": 1686314630,
"kind": 1,
"tags": [
[
"e",
"03990f127b6e54e518e627269d29601b4135cf31490a121eebe8865e4878ad6a",
"",
"root"
],
[
"e",
"a257bff9fd2c2ad0f868afab0ba2d94ad5db5c383146d94dbfae7ef551fca9c1",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-07-30\n📝 Original message:\n\u003e\u003e Still trying to get the details right of this protocol.\n\nMe too, but I have some more basic problems.\n\n\u003e\u003e Assume a payment route: Alice\u003c\u003eBob\u003c\u003eCarol\n\n* how does Alice know Bob and Carol? In Bitcoin there needs to be\nout-of-band key exchange, but there is no ID attached to the keys. The\nconcept of a hub seems to imply either use of standard PKI or Web-of-trust.\nBoth have big problems when it comes to large, frequent financial\ntransactions.\n\n* why should Bob even participate in this transaction? Currently I don't\nsee that incentives are described. That is a fundamental part of Bitcoin\nand makes network based intermediation possible (Alice \u003c\u003e computer network\nwith N nodes \u003c\u003e Carol). From the point of view of a node, Bitcoin does not\nhave a scalability issue. The only concern of the node is to maximize\nknowable profit.\n\nOn Thu, Jul 30, 2015 at 4:41 AM, Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e Christopher Jamthagen \u003ccjamthagen at gmx.com\u003e writes:\n\u003e \u003e Still trying to get the details right of this protocol. Please correct\n\u003e \u003e me if I am wrong in any of my assumptions below.\n\u003e\n\u003e \u003e Assume a payment route: Alice\u003c\u003eBob\u003c\u003eCarol\n\u003e\n\u003e \u003e Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice\n\u003e \u003e updates her commitment tx with Bob including the HTLC output and Bob\n\u003e \u003e does the same with Carol.\n\u003e\n\u003e OK.\n\u003e\n\u003e \u003e Carol witholds R, forcing Bob to broadcast the commitment tx between\n\u003e \u003e Bob and Carol.\n\u003e\n\u003e Yep, Carol goes non-responsive. Got it.\n\u003e\n\u003e \u003e Carol can now spend the HTLC output because she knows R and thus\n\u003e \u003e revealing it to the world. Alice now also refuses to update the\n\u003e \u003e commitment tx with Bob, forcing Bob to broadcast that commitment tx.\n\u003e\n\u003e Poor Bob. Yep.\n\u003e\n\u003e \u003e This commitment tx is putting a delay on\n\u003e \u003e Bobs ability to spend the HTLC output (as well as all other outputs to\n\u003e \u003e him), but Alice can spend the HTLC output if the CLTV has expired.\n\u003e\n\u003e Indeed, don't ever offer an HTLC less than your delay!\n\u003e\n\u003e \u003e In most examples I have seen, the CLTV is 2 days between Alice and Bob\n\u003e \u003e and 1 day between Bob and Carol, and all CSV delays are 3 days.\n\u003e\n\u003e I haven't seen an example which included a CSV delay amount.\n\u003e\n\u003e As the discussion with Joseph is establishing, the minimum CSV you allow\n\u003e controls the worst-case HTLC you can accept. CSV of a few hours should\n\u003e be OK if you're online all the time. I think...\n\u003e\n\u003e Anyone want to do some stats on that? CSV uses the median time of last\n\u003e 11 blocks, so to some extent you can tell the worst case...\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150730/4b836826/attachment.html\u003e",
"sig": "8fa4cb54b8dd9572cf1bd050ee583a67d27ff1df200d6b60e4e2d2451fd62123f1aada667f4a6ee55b16a927a51b3d74244f1683eeb82119780e8b38bdd94ab2"
}