On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote:
> Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of
> taproot and implement PTLCs.
I think the conclusion from the discussions at the in-person LN summit
was to split these features up an implement them
On Wed, Oct 13, 2021 at 03:15:14PM +1100, Lloyd Fournier wrote:
> If you're willing to accept that "worst case" happening more often, I
> think you could then retain the low latency forwarding, by having the
> transaction structure be:
So the idea here is that we have two channel
On Tue, 12 Oct 2021 at 14:08, Anthony Towns wrote:
>
> If you're willing to accept that "worst case" happening more often, I
> think you could then retain the low latency forwarding, by having the
> transaction structure be:
>
> commitment tx
> input:
> funding tx
> outputs:
>
On Tue, Oct 12, 2021 at 04:18:37AM +, ZmnSCPxj via Lightning-dev wrote:
> > A+P + max(0, B'-B)*0.1 to Alice
> > B-f - max(0, B'-B)*0.1 to Bob
> So, if what you propose is widespread, then a theft attempt is costless:
That's what the "max" part prevents -- if your current balance is B and
Good morning aj,
> On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
>
> > ### Scorched earth punishment
> >
> > Another thing that I'd like to mention is that using revocable signatures
> > enables scorched earth punishments [2].
>
> I kind-of think it'd be more interesting to
On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
> ### Scorched earth punishment
> Another thing that I'd like to mention is that using revocable signatures
> enables scorched earth punishments [2].
I kind-of think it'd be more interesting to simulate eltoo's behaviour.
If Alice's
On Mon, Oct 11, 2021 at 09:23:19PM +1100, Lloyd Fournier wrote:
> On Mon, 11 Oct 2021 at 17:30, Anthony Towns wrote:
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim
On Mon, 11 Oct 2021 at 9:23 pm, Lloyd Fournier
wrote:
>
> Adjust the protocol so that you reciprocate the in-flight txs. So when I
> offer you a HTLC you first forward it and then lazily send me the signature
> for the inflight tx. Therefore I dont have to wait to get the HTLC on chain
> and
On Mon, 11 Oct 2021 at 17:30, Anthony Towns wrote:
>
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim the funds or know the preimage by time T is to close the
> channel on-chain
On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote:
> 2. The balance transaction - tracks the funding transaction, contains
> a "balance" output for each of the participants.
> 3. The inflight transactions - spends a balance output from the balance
> transaction and provides
Hey aj,
This is awesome work. My line of research on "witness asymmetric channels"
essentially ended up in a dead end because I couldn't see how they were
much better than naive PTLC lightning. The idea I really liked from it was
"revocable signatures". I hoped someone would eventually figure out
> H( private-key, msg, other-party's-nonce-pair, 1 )
That should work. I had thought that other-party's-nonce-pair would be unique
unknown randomness, but I can see now that it can be rederived from RA(n) or
RB(n).
> Hmm, you had me panicking that I'd been describing how to combine the
> two
On Sat, Oct 09, 2021 at 12:21:03PM +, Jonas Nick wrote:
> it seems like parts of this proposal rely on deterministic nonces in MuSig.
The "deterministic" nonces are combined with "recoverable" nonces via
musig2, so I think that part is a red-herring?
They're "deterministic" in the sense that
Hi,
it seems like parts of this proposal rely on deterministic nonces in MuSig.
Generally, this is insecure unless combined with heavy machinery that proves
correctness of the nonce derivation in zero knowledge. If one signer uses
deterministic nonces and another signer uses random nonces, then
Good morning aj,
> On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote:
>
> > A transaction is required, but I believe it is not necessary to put it
> > onchain (at the cost of implementation complexity in the drop-onchain case).
>
> The trick with that is that if you don't put it on chain,
On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote:
> A transaction is required, but I believe it is not necessary to put it
> *onchain* (at the cost of implementation complexity in the drop-onchain case).
The trick with that is that if you don't put it on chain, you need
to calculate the
Good morning aj,
> In order to transition from BOLT#3 format to this proposal, an onchain
> transaction is required, as the "revocable signatures" arrangement cannot
> be mimicked via the existing 2-of-2 CHECKMULTISIG output.
A transaction is required, but I believe it is not
17 matches
Mail list logo
