Hi Peter,
If feerate-dependent timelocks (FDTs) (1) are supported, it would be possible
to use CTV to define a transaction with a fixed fee and no anchor outputs, as
long as it's racing against a transaction with an FDT.
Regards,
John
(1)
nly
> to the miner that produced the block. Assuming that tx inputs less outputs
> represents an actual economic force is an error.
>
> e
>
>> On Dec 22, 2023, at 09:24, jlspc via bitcoin-dev
>> wrote:
>
>>
>>
>> Hi Antoine,
>>
>> Thanks for your t
ly one tx instead of the whole block.
Yes, I think that's a great idea!
Regards,
John
>
> On Fri, Dec 15, 2023 at 6:20 AM jlspc via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > TL;DR
> > =
> > * All known Lightning channel and factory protocols are
e issues of Lightning and other
> time-sensitive use-cases.
> (Note, I've not reviewed the analysis and game-theory in the face of miners
> collusion / coalition, as I think the introduction of a `claim_grace_period`
> is modifying the fundamentals).
>
> Best,
> Antoine
&
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 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 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 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
Hi Antoine,
Thanks for your insightful post on the interactivity issue.
Some thoughts are inline below.
> However, those constructions require all the users to be online and
> exchange rounds of signatures to update the balance distribution. Those
> liveliness/interactivity requirements are
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
14 matches
Mail list logo
