On Thu, Dec 09, 2021 at 12:34:00PM +1100, Lloyd Fournier wrote:
> I wanted to add a theoretical note that you might be aware of. The final
> message "Bob -> Alice: revoke_and_ack" is not strictly necessary. Alice
> does not care about Bob revoking a commit tx that gives her strictly more
> coins.
Hi thread,
I was indeed mistaken. It does require four rounds for both parties to
fully transition to the next comimit tx and I don't think there is any easy
way around this. As you've pointed out there it's still only three rounds
before the message is forwarded so no performance decrease for
Hi Jeremy,
Thanks for sharing your thoughts.
To summarize your arguments: the intentionally malicious path to getting
the 0 sat output confirmed without being spent is uneconomical compared to
simply creating dust outputs. And even if it does happen, the tx spending
from the 0 sat output may
IMO this is not a big problem. The problem is not if a 0 value ever enters
the mempool, it's if it is never spent. And even if C2/P1 goes in, C1 still
can be spent. In fact, it increases it's feerate with P1's confirmation so
it's somewhat likely it would go in. C2 further has to be pretty
Bastien,
The issue is that with Decker Channels you either use SIGHASH_ALL / APO and
don't allow adding outs (this protects against certain RBF pinning on the
root with bloated wtxid data) and have anchor outputs or you do allow them
and then are RBF pinnable (but can have change).
Assuming you
Hi again AJ and list,
I have slightly re-worked your proposal, and came up with the following
(I also added the musig2 nonces for completeness):
Alice -> Bob: commitment_proposed
channel id
adaptor sigs for PTLCs to Bob in Alice's next commitment
musig nonces for Alice to spend
Hi Jeremy,
I brought up the exact same thing at coredev, but unfortunately I came up
with a way in which the 0 sat output could still enter the UTXO set under
those rules:
- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat
- Child C1 spends the 0 sat output for a combined feerate of 1 sat
Hi AJ,
I think the problem t-bast describes comes up here as well when you
> collapse the fast-forwards (or, anytime you update the commitment
> transaction even if you don't collapse them).
Yes, exactly.
I think doing a synchronous update of commitments to the channel state,
> something like:
On Tue, Dec 07, 2021 at 11:52:04PM +, ZmnSCPxj via Lightning-dev wrote:
> Alternately, fast-forwards, which avoid this because it does not change
> commitment transactions on the payment-forwarding path.
> You only change commitment transactions once you have enough changes to
> justify
Hi Z,
`SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four
> years?) or a similar "covenant" opcode,
such as `OP_CHECKTEMPLATEVERIFY` without any commitments or an
> `OP_CHECKSIGFROMSTACK` on an empty message.
> All you really need is a signature for an empty message, really...
>
Hi Jeremy,
Right now, lightning anchor outputs use a 330 sats amount. Each commitment
transaction has two such outputs, and only one of them is spent to help the
transaction get confirmed, so the other stays there and bloats the utxo set.
We allow anyone to spend them after a csv of 16 blocks, in
11 matches
Mail list logo
