Hi Eric,
I agree that users can pay miners offchain and miners can create blocks where
the difference between inputs and outputs exceeds the fees paid (by mining
their own transactions). I model that behavior as dishonest mining. Onchain
fees seem to reflect congestion for now, but it's true
Hi Boris,
Responses inline below:
Sent with Proton Mail secure email.
On Friday, December 22nd, 2023 at 8:36 AM, Nagaev Boris
wrote:
> Hi John!
>
> I have two questions regarding the window, which are related.
>
> 1. Why is the window aligned? IIUC, this means that the blocks mined
>
Hi Antoine,
Thanks for your thoughtful response.
Comments inline below:
> Hi John,
> While the idea of using sliding reaction window for blockchain congestion
> detection has been present in the "smart contract" space at large [0] and
> this has been discussed informally among Lightning devs
TL;DR
=
* All known Lightning channel and factory protocols are susceptible to forced
expiration spam attacks, in which an attacker floods the blockchain with
transactions in order to prevent honest users from putting their transactions
onchain before timelocks expire.
* Feerate-Dependent
Hi aj,
A few more thoughts on this trust/safety vs. capital efficiency tradeoff:
> Optimising that formula by making LA [the channel's active lifetime] as large
> as possible doesn't
> necessarily work -- if a casual user spends all their funds and
> disappears prior to the active lifetime
Hi Antoine,
> "I also think resizing channels can be done fairly effectively
>off-chain
>with hierarchical channels [1] (and even better with hierarchical channels
>within timeout-trees)".
>Yes, transactional scaling of Lightning (i.e how many transfers can be
>performed off-chain per on-chain
Hi ZmnSCPxj,
> Good morning John,
> On the other hand, if the consensus rules are changed to allow even
> simple covenants, this scaling bottleneck is eliminated.
> The key observation is that with covenants, a casual user can
> co-own an off-chain Lightning channel without having to sign
Hi Dave,
Yes, exactly.
The figures and the descriptions that accompany them are correct, but the
initial text description had an error.
Regards,
John
Sent with Proton Mail secure email.
--- Original Message ---
On Sunday, September 24th, 2023 at 2:40 PM, David A. Harding
wrote:
Hi Antoine,
Thanks for your note. Responses are in-line below:
> Hi John,
> Thanks for the proposal, few feedback after a first look.
> If Bitcoin and Lightning are to become widely-used, they will have to
> be adopted by casual users who want to send and receive bitcoin, but who
> do not
Hi Rusty,
> I've read the start of the paper on my vacation, and am still
> digesting it. But even so far, it presents some delightful
> possibilities.
Great!
> As with some other proposals, it's worth noting that the cost of
> enforcement is dramatically increased. It's no longer one
Hi aj,
I completely agree with your observation that there's an important trust/safety
vs. capital-efficiency tradeoff, and I almost completely agree with your
analysis.
> (There are probably ways around this with additional complexity: eg,
> you could peer with a dedicated node, and have
TL;DR
=
* The key challenge in scaling Lightning in a trust-free manner is the creation
of Lightning channels for casual users.
- It appears that signature-based factories are inherently limited to
creating at most tens or hundreds of Lightning channels per UTXO.
- In contrast, simple
Replies inline:
> > > One thing that confuses me about the paper is how to think about routing
> > > to a "channel" rather than a node -- ie the payment from "E->FG->A" where
> > > "FG" isn't "F" or "G", but "both of them".
> > Yes, I found it very difficult to think about, and I kept getting
> One thing that confuses me about the paper is how to think about routing
> to a "channel" rather than a node -- ie the payment from "E->FG->A" where
> "FG" isn't "F" or "G", but "both of them".
Yes, I found it very difficult to think about, and I kept getting confused
between concepts like
Comments below:
>> Step 1: Tunable penalties;
>> > href="https://github.com/JohnLaw2/ln-tunable-penalties;>https://github.com/JohnLaw2/ln-tunable-penalties
>> >
Hi aj,
Thanks for your great write-up!
Comments below:
> Even with Harding's optech write ups, and the optech space, I barely
> follow all this, so I'm going to try explaining it too as a way of
> understanding it myself; hopefully maybe that helps someone. Corrections
> welcome, obviously!
Hi Dave,
Thank you for your clear and insightful response.
Comments inline below:
>Hi John,
>Thank you for another innovative application of your tunable penalties.
>I see two key benefits being described by your paper[1]:
>- **Offchain channel resizes:** in state 0, Alice and Bob share
TL;DR
=
* Dynamic management of Lightning channel capacity is required to support
efficient Lightning Network (LN) payments
- On-chain resizing introduces delays, adds costs and limits scalability
- Fast and cheap resizing may be required to support watchtower-free LN
payments for
TL;DR
=
* Factories that create and update a large number of Lightning channels
efficiently are essential for scaling the Lightning Network.
* This post presents the first known protocol for Lightning factories that can
be closed unilaterally in O(1) time using O(1) on-chain transactions.
I'd like to make two corrections to this post:
1) The link for reference [8] should be:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
(thanks to David A. Harding for this correction).
2) An extension of the FFO protocol was described in which the parties
TL;DR
=
* This post presents a channel protocol that's optimized for use within channel
factories.
* The protocol allows HTLCs to be resolved on-chain:
* without making the expiry of the HTLC depend on the time to close the
factory, and
* without closing the factory.
* The key ides is the
Hi Bastien,
Thanks for your detailed response.
I see how the use of a pre-signed "splice" transaction that allows the
dedicated user to obtain some of their capital creates an inherent trade-off
between the dedicated user's capital efficiency and the casual user's ability
to be offline for an
TL:DR
=
* It's possible to modify the Lightning channel protocol to impose tunable
penalties for putting old transactions on-chain.
* The key idea is the use of separate value transactions and control
transactions.
* The Tunable-Penalty (TP) protocol also allows a watchtower to use storage
Hey Bastien,
Thanks for your reply.
Responses are in-line below:
> Hey John,
>
> Thanks for sharing, this is very interesting.
>
> There is a good insight here that we can remove the intermediate
> HTLC-timeout transaction for outgoing payments because we are the
> origin of that payment (and
Hi Dave,
Thanks for reading and for doing a better job of explaining the ideas than I
did!
Responses are in-line below:
> Hi John,
>
> I had difficulty understanding your proposal description here and in
> your paper[1]. I wonder if others are having the same the same
> difficulty, so
This is the first in a series of posts on ideas to improve the usability
and scalability of the Lightning Network. This post presents a new channel
protocol that allows casual users to send and receive Lightning payments
without having to meet onerous availability requirements or use a
watchtower
Response to email from Anthony Towns sent on 20210918 at 11:37:40 UTC
==
aj,
Thanks for taking the time to go through my paper on inherited IDs (IIDs).
Also, thanks for your concise and accurate description of the IID proposal and
the 2Stage channel
27 matches
Mail list logo
