Topics: add three new topic pages #1509
Conversation
_topics/en/cltv-expiry-delta.md
Outdated
| The CLTV expiry delta tries to prevent Bob from losing value this way. | ||
| When Alice gives Bob an HTLC that allows her to claim a refund after | ||
| `x` blocks, Bob gives Carol an HTLC that allows him to claim a refund | ||
| after `x - y` blocks. They _y_ parameter is Bob's HTLC expiry delta: |
There was a problem hiding this comment.
| after `x - y` blocks. They _y_ parameter is Bob's HTLC expiry delta: | |
| after `x - y` blocks. The _y_ parameter is Bob's HTLC expiry delta: |
_topics/en/cltv-expiry-delta.md
Outdated
| For example, imagine a payment that will be sent across 20 hops each | ||
| with an HTLC expiry delta of 100 blocks. If that payment stalls, it | ||
| could be up to 2,000 blocks (about two weeks) until the spender gets | ||
| a refund and is able to resend the payment again. |
There was a problem hiding this comment.
| a refund and is able to resend the payment again. | |
| a refund and can resend the payment again. |
_topics/en/cltv-expiry-delta.md
Outdated
| could be up to 2,000 blocks (about two weeks) until the spender gets | ||
| a refund and is able to resend the payment again. | ||
|
|
||
| There's no universally agreed upon tradeoff between security and |
There was a problem hiding this comment.
| There's no universally agreed upon tradeoff between security and | |
| There's no universally agreed-upon tradeoff between security and |
_topics/en/proof-of-reserves.md
Outdated
| does. | ||
|
|
||
| The simplest form of proof of reserves lists each depositor's name in a | ||
| form that can't be confused with any other depositor's name. Explicit |
There was a problem hiding this comment.
| form that can't be confused with any other depositor's name. Explicit | |
| form that can't be confused with any other depositor's name. The use of explicit |
_topics/en/proof-of-reserves.md
Outdated
|
|
||
| For privacy, each depositor's name may be replaced with a pseudonym. | ||
| However, depositors still need to ensure they are each given a unique | ||
| name. For more privacy, the association between name and exact deposit |
There was a problem hiding this comment.
| name. For more privacy, the association between name and exact deposit | |
| name. For more privacy, the association between the name and the exact deposit |
_topics/en/x-only-public-keys.md
Outdated
| checking operations to reduce the size of public keys. | ||
|
|
||
| The advantage for x-only public keys is that they save space. The | ||
| downside is that generated public keys most only used the allowed _y_ |
There was a problem hiding this comment.
| downside is that generated public keys most only used the allowed _y_ | |
| downside is that generated public keys only used the allowed _y_ |
(I think? I may not be parsing this sentence correctly.)
There was a problem hiding this comment.
I have similar confusion on the sentence
_topics/en/cltv-expiry-delta.md
Outdated
| received from Alice, so her funds are stuck as well. To avoid funds | ||
| becoming permanently stuck, HTLCs have an expiry after which Bob will | ||
| be able to claim a refund. After Bob receives his refund from Carol, he | ||
| can reject the payment from Alice (giving her a refund). Alternatively, |
There was a problem hiding this comment.
| can reject the payment from Alice (giving her a refund). Alternatively, | |
| can reject the payment from Alice, giving her a refund. Alternatively, |
(a weak suggestion, just personal preference, feel free to ignore)
_topics/en/cltv-expiry-delta.md
Outdated
| There's no universally agreed upon tradeoff between security and | ||
| worst-case payment delivery time, so LN implementations tend to each use | ||
| different default HTLC expiry deltas, often change those defaults, and | ||
| usually allow users to chose their own setting. |
There was a problem hiding this comment.
| usually allow users to chose their own setting. | |
| usually allow users to choose their own setting. |
_topics/en/proof-of-reserves.md
Outdated
| depositors have some assurance that Bank Corp could return their | ||
| deposited amounts if it was willing. | ||
|
|
||
| Proof of reserves can not guarantee that the funds are available. For |
There was a problem hiding this comment.
| Proof of reserves can not guarantee that the funds are available. For | |
| Proof of reserves cannot guarantee that the funds are available. For |
_topics/en/proof-of-reserves.md
Outdated
| 6 BTC | ||
| / \ | ||
| 3 BTC 3 BTC | ||
| / \ | ||
| (1 BTC: Alice) |
There was a problem hiding this comment.
I'm not sure, but does the node (hash) immediately to the right of Alice's node also need to be revealed? That is, both of the contributors to the "3 BTC" on the left side?
There was a problem hiding this comment.
Updated to separate the sum operations from the name operations, so it's (maybe) a little clearer that all Alice needs is the clear-text amount of the side branch and the hash commitment to the name of the person with that balance.
_topics/en/cltv-expiry-delta.md
Outdated
| it's how many blocks he has to claim a refund onchain before he could | ||
| potentially lose money if Alice claims her refund. | ||
|
|
||
| Higher HTLC deltas provide more safety as they give an LN node more time |
There was a problem hiding this comment.
| Higher HTLC deltas provide more safety as they give an LN node more time | |
| Higher HTLC expiry deltas provide more safety as they give an LN node more time |
_topics/en/cltv-expiry-delta.md
Outdated
|
|
||
| Higher HTLC deltas provide more safety as they give an LN node more time | ||
| to get an HTLC refund transaction confirmed onchain before that node is | ||
| at risk of losing funds. However, higher HTLC deltas magnify the |
There was a problem hiding this comment.
| at risk of losing funds. However, higher HTLC deltas magnify the | |
| at risk of losing funds. However, higher HTLC expiry deltas magnify the |
_topics/en/cltv-expiry-delta.md
Outdated
| - title: "LND #2759 lowers the default CLTV delta for all channels from 144 blocks to 40 blocks" | ||
| url: /en/newsletters/2019/04/02/#lnd-2759 | ||
|
|
||
| - title: "LN-Symmetry requires longer HTLC expiry deltas than expected" |
There was a problem hiding this comment.
| - title: "LN-Symmetry requires longer HTLC expiry deltas than expected" | |
| - title: "LN-Symmetry requires longer CLTV expiry deltas than expected" |
I think all topic references and body text should replace HTLC expiry delta with CLTV expiry delta. If we want to use the terms interchangeably, we should note that alias
There was a problem hiding this comment.
Good point! Making that edit and also adding a test to forbid "HTLC expiry delta" in the future.
_topics/en/x-only-public-keys.md
Outdated
| checking operations to reduce the size of public keys. | ||
|
|
||
| The advantage for x-only public keys is that they save space. The | ||
| downside is that generated public keys most only used the allowed _y_ |
There was a problem hiding this comment.
I have similar confusion on the sentence
_topics/en/x-only-public-keys.md
Outdated
| bytes. | ||
|
|
||
| The extra bit can be eliminated if only one of the two alternative _y_ | ||
| coordinates are allowed. X-only public keys do this, using a total of |
There was a problem hiding this comment.
| coordinates are allowed. X-only public keys do this, using a total of | |
| coordinates is allowed. X-only public keys do this, using a total of |
|
Doesnt seem like anything too intense coming out of these reviews (thanks @vostrnad and @LarryRuane !). You think we should work to get these fixups in and merge this PR, @harding ? |
- CLTV expiry delta - Proof of reserves - X-only public keys
harding
force-pushed
the
2024-02-topics-por-xo-ced
branch
from
a63b5e9 to
73327b5
Compare
|
Edits made. Thanks @LarryRuane @vostrnad @bitschmidty ! |
There was a problem hiding this comment.
Checked the diff, lgtm,
Thanks for putting these together @harding !
Topics were suggested on #721