Re: [Lightning-dev] Proof of payment (Re: AMP: Atomic Multi-Path Payments over Lightning)

2018-02-21 Thread Anthony Towns
On Tue, Feb 13, 2018 at 09:23:37AM -0500, ZmnSCPxj via Lightning-dev wrote: > Good morning Corne and Conner, > Ignoring the practical matters that Corne rightly brings up, I think, > it is possible to use ZKCP to provide a "stronger" proof-of-payment in > the sense that Conner is asking for. I

[Lightning-dev] Post-Schnorr lightning txes

2018-02-19 Thread Anthony Towns
Hi *, My understanding of lightning may be out of date, so please forgive (or at least correct :) any errors on my behalf. I was thinking about whether Greg Maxwell's graftroot might solve the channel monitoring problem (spoiler: not really) and ended up with maybe an interesting take on

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

2018-07-18 Thread Anthony Towns
(bitcoin-dev dropped from cc) On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote: > eltoo is a drop-in replacement for the penalty based invalidation > mechanism that is used today in the Lightning specification. [...] I think you can simplify eltoo further, both in the way the

Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?

2018-03-13 Thread Anthony Towns
On Tue, Mar 13, 2018 at 06:07:48PM +0100, René Pickhardt via Lightning-dev wrote: > Hey Christian, > I agree with you on almost anything you said. however I disagree that in the > lightning case it produces just another double spending. I wish to to > emphasize > on my statement that the in the

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

2018-10-13 Thread Anthony Towns
thony for pointing this out, I was not aware we could >> roll keypairs to reset the state numbers. >> >> I basically thought that 1billion updates is more than I would >> ever do, since with splice-in / splice-out operations we'd be >> re-anchoring on-chain on a regular

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-02 Thread Anthony Towns
On Fri, Nov 02, 2018 at 03:45:58PM +1030, Rusty Russell wrote: > Anthony Towns writes: > > On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote: > >> There's been some discussion of what the lightning payment flow > >> might look like in the future, an

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-03 Thread Anthony Towns
On Sun, Nov 04, 2018 at 01:30:48PM +1030, Rusty Russell wrote: > I'm not sure. Jonas Nick proposed a scheme, which very much assumes > Schnorr AFAICT: > Jonas Nick wrote: > > How I thought it would work is that the invoice would contain a > > Schnorr nonce R. (Note this means the "invoice" must

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-01 Thread Anthony Towns
On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote: > There's been some discussion of what the lightning payment flow > might look like in the future, and I thought I'd try to look forwards so > we can avoid painting ourselves into a corner now. I haven't spent time > on

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Anthony Towns
On Tue, Nov 06, 2018 at 10:22:56PM +, Gert-Jaap Glasbergen wrote: > > On 6 Nov 2018, at 14:10, Christian Decker > > wrote: > > It should be pointed out here that the dust rules actually prevent us > > from creating an output that is smaller than the dust limit (546 > > satoshis on Bitcoin).

[Lightning-dev] Probe cancellation

2018-11-09 Thread Anthony Towns
PING, It seems like ensuring reliability is going to involve nodes taking active measures like probing routes fairly regularly. Maybe it would be worth making that more efficient? For example, a risk of probing is that if the probe discovers a failing node/channel, the probe HTLC will get stuck,

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-08 Thread Anthony Towns
On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote: > > A node, via their node_announcement, > Most implementations today will ignore node announcements from nodes that > don't have any channels, in order to maintain the smallest routing set > possible (no zombies, etc). It seems

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-07 Thread Anthony Towns
On Wed, Nov 07, 2018 at 02:26:29AM +, Gert-Jaap Glasbergen wrote: > > Otherwise, if you're happy accepting 652 satoshis, I don't see why you > > wouldn't be happy accepting an off-chain balance of 652.003 satoshis; > > you're no worse off, in any event. > I wouldn’t be worse off when accepting

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread Anthony Towns
On Mon, Nov 05, 2018 at 01:05:17AM +, ZmnSCPxj via Lightning-dev wrote: > > And it just doesn't work unless you give over uniquely identifying > > information. AJ posts to r/bitcoin demonstrating payment, demanding his > > goods. Sock puppet says "No, I'm the AJ in Australia" and cut & pastes

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread Anthony Towns
On Sun, Nov 04, 2018 at 08:04:20PM +1030, Rusty Russell wrote: > >> > - just send multiple payments with the same hash: > >> > works with sha256 > >> > privacy not improved much (some intermediary nodes no longer know > >> > full invoice value) > >> > can claim partial payments

Re: [Lightning-dev] Base AMP

2018-11-16 Thread Anthony Towns
On Thu, Nov 15, 2018 at 11:54:22PM +, ZmnSCPxj via Lightning-dev wrote: > The improvement is in a reduction in `fee_base_msat` in the C->D path. I think reliability (and simplicity!) are the biggest things to improve in lightning atm. Having the flag just be incuded in invoices and not need

Re: [Lightning-dev] Packet switching via intermediary rendezvous node

2018-11-16 Thread Anthony Towns
On Thu, Nov 15, 2018 at 07:24:29PM -0800, Olaoluwa Osuntokun wrote: > > If I'm not mistaken it'll not be possible for us to have spontaneous > > ephemeral key switches while forwarding a payment > If this _was_ possible, then it seems that it would allow nodes to create > unbounded path lengths

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-21 Thread Anthony Towns
On Thu, Mar 21, 2019 at 10:05:09AM +, ZmnSCPxj wrote: > > IF OP_CODESEPARATOR OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF > > OP_CHECKDLSVERIFY OP_CHECKDLS > > Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV > > and allows binding to any prior update tx -- so works for an update

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-14 Thread Anthony Towns
On Thu, Mar 14, 2019 at 05:22:59AM +, ZmnSCPxj via Lightning-dev wrote: > When reading through your original post I saw you mentioned something about > output tagging somehow conflicting with Taproot, so I assumed Taproot is not > useable in this case. I'm thinking of tagged outputs as

[Lightning-dev] More thoughts on NOINPUT safety

2019-03-12 Thread Anthony Towns
Hi all, The following has some more thoughts on trying to make a NOINPUT implementation as safe as possible for the Bitcoin ecosystem. One interesting property of NOINPUT usage like in eltoo is that it actually reintroduces the possibility of third-party malleability to transactions -- ie, you

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-13 Thread Anthony Towns
On Wed, Mar 13, 2019 at 06:41:47AM +, ZmnSCPxj via Lightning-dev wrote: > > - alternatively, we could require every script to have a valid signature > > that commits to the input. In that case, you could do eltoo with a > > script like either: > > CHECKSIGVERIFY CHECKSIG > >

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-21 Thread Anthony Towns
On Fri, Mar 22, 2019 at 01:59:14AM +, ZmnSCPxj wrote: > > If codeseparator is too scary, you could probably also just always > > require the locktime (ie for settlmenet txs as well as update txs), ie: > > OP_CHECKLOCKTIMEVERIFY OP_DROP > > OP_CHECKDLSVERIFY OP_CHECKDLS > > and have update

Re: [Lightning-dev] Eltoo, anyprevout and chaperone signatures

2019-05-16 Thread Anthony Towns
On Thu, May 16, 2019 at 09:55:57AM +0200, Bastien TEINTURIER wrote: > Thanks for your answers and links, the previous discussions probably happened > before I joined this list so I'll go dig into the archive ;) The discussion was on a different list anyway, I think, this might be the middle of

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-01 Thread Anthony Towns
On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote: > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > `OP_CHECKSIG_WITHOUT_INPUT`. I don't think there's any meaningful difference between making a new opcode and making a new tapscript public key type; the

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-01 Thread Anthony Towns
On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev wrote: > With the recently renewed interest in eltoo, a proof-of-concept implementation > [1], and the discussions regarding clean abstractions for off-chain protocols > [2,3], I thought it might be time to revisit the

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-07 Thread Anthony Towns
On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote: > > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay > > field: it says 14, ." but Alice doesn't know anything other than > > so can't put in the onion? > Alice created the onion. Alice knows all

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-06 Thread Anthony Towns
On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote: > >> Rusty prepares a nonce, A and hashes it 25 times = Z. > >> ZmnSCPxj prepares the onion, but adds extra fields (see below). > > It would have made more sense to me for Alice (Zmn) to generate > > the nonce, hash it, and

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-05 Thread Anthony Towns
On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote: > Sure: for simplicity I'm sending a 0-value HTLC. > ZmnSCPxj has balance 1msat in channel with Rusty, who has 1000msat > in the channel with YAIjbOJa. Alice, Bob and Carol sure seem simpler than Zmn YAI and Rusty... > Rusty

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-08 Thread Anthony Towns
On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote: > Anthony Towns writes: > [ Snip summary, which is correct ] Huzzah! This correlates all the hops in a payment when the route reaches its end (due to the final preimage getting propogated back for everyone to justify the

Re: [Lightning-dev] eltoo towers and implications for settlement key derivation

2019-12-02 Thread Anthony Towns
On Tue, Nov 26, 2019 at 03:41:14PM -0800, Conner Fromknecht wrote: > I recently revisited the eltoo paper and noticed some things related > watchtowers that might affect channel construction. > In order to spend, however, the tower must also produce a witness > script which when hashed matches the

Re: [Lightning-dev] Lightning in a Taproot future

2019-12-17 Thread Anthony Towns
On Sun, Dec 15, 2019 at 03:43:07PM +, ZmnSCPxj via Lightning-dev wrote: > For now, I am assuming the continued use of the existing Poon-Dryja update > mechanism. > Decker-Russell-Osuntokun requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`, and > its details seem less settled for now than

Re: [Lightning-dev] Selling timestamps (via payment points and scalars + Pedersen commitments ) [try2]

2019-09-25 Thread Anthony Towns
On Wed, Sep 25, 2019 at 01:30:39PM +, ZmnSCPxj wrote: > > Since it's off chain, you could also provide R and C and a zero knowledge > > proof that you know an r such that: > > R = SHA256( r ) > > C = SHA256( x || r ) > > in which case you could do it with lightning as it exists today. > I can

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-02 Thread Anthony Towns
On Wed, Oct 02, 2019 at 02:03:43AM +, ZmnSCPxj via Lightning-dev wrote: > So let me propose the more radical excision, starting with SegWit v1: > * Remove `SIGHASH` from signatures. > * Put `SIGHASH` on public keys. > OP_SETPUBKEYSIGHASH I don't think you could reasonably do this for

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-05 Thread Anthony Towns
On Thu, Oct 03, 2019 at 01:08:29PM +0200, Christian Decker wrote: > > * anyprevout signatures make the address you're signing for less safe, > >which may cause you to lose funds when additional coins are sent to > >the same address; this can be avoided if handled with care (or if you > >

Re: [Lightning-dev] A proposal for up-front payments.

2020-02-27 Thread Anthony Towns
On Mon, Feb 24, 2020 at 01:29:36PM +1030, Rusty Russell wrote: > Anthony Towns writes: > > On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote: > >> And if there is a grace period, I can just gum up the network with lots > >> of slow-but-not-slow-enough

Re: [Lightning-dev] A proposal for up-front payments.

2020-02-23 Thread Anthony Towns
On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote: > > I think the way it would end up working > > is that the further the route extends, the greater the payments are, so: > > A -> B : B sends A 1msat per minute > > A -> B -> C : C sends B 2msat per minute, B forwards 1msat/min

Re: [Lightning-dev] A proposal for up-front payments.

2020-02-19 Thread Anthony Towns
On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote: > A different way of mitigating this is to reverse the direction in which the > bond is paid. So instead of paying to offer an htlc, nodes need to pay to > receive an htlc. This sounds counterintuitive, but for the described jamming >

Re: [Lightning-dev] A proposal for up-front payments.

2020-02-19 Thread Anthony Towns
On Thu, Feb 20, 2020 at 03:42:39AM +, ZmnSCPxj wrote: > A thought that arises here is, what happens if I have forwarded a payment, > then the outgoing channel is dropped onchain and that peer disconnects from > me? > > Since the onchain HTLC might have a timelock of, say, a few hundred

[Lightning-dev] Layered commitments with eltoo

2020-01-21 Thread Anthony Towns
Hi all, At present, BOLT-3 commitment transactions provide a two-layer pay-to-self path, so that you can reduce the three options: 1) pay-to-them due to revoked commitment 2) pay-to-me due to timeout (or: preimage known) 3) pay-to-them due to preimage known (or: timeout) to just the two

[Lightning-dev] Lightning dice

2021-01-25 Thread Anthony Towns
Hey all, Here's a rough design for doing something like satoshi dice (ie, gambling on "guess the number I'm thinking of" but provably fair after the fact [0]) on lighting, at least once PTLCs exist. [0]

Re: [Lightning-dev] [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-08 Thread Anthony Towns
On Wed, Jul 07, 2021 at 06:00:20PM -0700, Jeremy via bitcoin-dev wrote: > This means that you're overloading the CLTV clause, which means it's > impossible > to use Eltoo and use a absolute lock time, It's already impossible to simultaneously spend two inputs if one requires a locktime specified

[Lightning-dev] Impact of eltoo loss of state

2021-07-12 Thread Anthony Towns
Hello world, Suppose you have some payments going from Alice to Bob to Carol with eltoo channels. Bob's lightning node crashes, and he recovers from an old backup, and Alice and Carol end up dropping newer channel states onto the blockchain. Suppose the timeout for the payments is a few hours

Re: [Lightning-dev] [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-11 Thread Anthony Towns
On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote: > This would disallow using a relative locktime and an absolute locktime > for the same input. I don't think I've seen a use case for that so far, > but ruling it out seems suboptimal. > I think you meant disallowing a relative

Re: [Lightning-dev] Eltoo Burst Mode & Continuations

2021-07-10 Thread Anthony Towns
On Sat, Jul 10, 2021 at 02:07:02PM -0700, Jeremy wrote: > Let's say you're about to hit your sequence limits on a Eltoo channel... Do > you > have to go on chain? > No, you could do a continuation where for your *final* update, you sign a move > to a new update key. E.g., That adds an extra tx

Re: [Lightning-dev] #zerobasefee

2021-08-15 Thread Anthony Towns
On Sun, Aug 15, 2021 at 07:19:01AM -0500, lisa neigut wrote: > My suggestion would be that, as a compromise, we set a network wide minimum > fee > at the protocol level of 1msat. Is that different in any meaningful way to just saying "fees get rounded up to the nearest msat" ? If the fee is

Re: [Lightning-dev] #zerobasefee

2021-08-15 Thread Anthony Towns
On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote: > On 8/15/21 22:02, Anthony Towns wrote: > > > In > > > one particular class of applicable routing algorithms you could use for > > > lightning routing having a base fee makes the algorithm intra

Re: [Lightning-dev] #zerobasefee

2021-08-25 Thread Anthony Towns
On Tue, Aug 24, 2021 at 08:50:42PM -0700, Matt Corallo wrote: > I feel like we're having two very, very different conversations here. On one > hand, you're arguing that the base fee is of marginal use, and that maybe we > can figure out how to average it out such that we can avoid needing it. I'm

Re: [Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

2021-08-30 Thread Anthony Towns
On Thu, Aug 26, 2021 at 04:33:23PM +0200, René Pickhardt via Lightning-dev wrote: > As we thought it was obvious that the function is not linear we only explained > in the paper how the jump from f(0)=0 to f(1) = ppm+base_fee breaks convexity. (This would make more sense to me as "f(0)=0 but

Re: [Lightning-dev] #zerobasefee

2021-08-20 Thread Anthony Towns
On Mon, Aug 16, 2021 at 12:48:36AM -0400, Matt Corallo wrote: > > The base+proportional fees paid only on success roughly match the *value* > > of forwarding an HTLC, they don't match the costs particularly well > > at all. > Sure, indeed, there's some additional costs which are not covered by

[Lightning-dev] #zerobasefee

2021-08-14 Thread Anthony Towns
Hey *, There's been discussions on twitter and elsewhere advocating for setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing this to summarise my understanding in a place that's able to easily be referenced later. Setting the base fee to zero has a couple of benefits: - it

Re: [Lightning-dev] [bitcoin-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

2021-09-18 Thread Anthony Towns
On Fri, Sep 17, 2021 at 09:58:45AM -0700, Jeremy via bitcoin-dev wrote, on behalf of John Law: > I'd like to propose an alternative to BIP-118 [1] that is both safer and more > powerful. The proposal is called Inherited IDs (IIDs) and is described in a > paper that can be found here [2]. [...]

Re: [Lightning-dev] [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-13 Thread Anthony Towns
On Mon, Jul 12, 2021 at 03:07:29PM -0700, Jeremy wrote: > Perhaps there's a more general principle -- evaluating a script should > only return one bit of info: "bool tx_is_invalid_script_failed"; every > other bit of information -- how much is paid in fees (cf ethereum gas >

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-08-12 Thread Anthony Towns
On Tue, Aug 10, 2021 at 06:37:48PM -0400, Antoine Riard via bitcoin-dev wrote: > Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime of > the HTLC. Right: but that just means it's not something you should determine once for the HTLC, but something you should determine each

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-09 Thread Anthony Towns
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

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-11 Thread Anthony Towns
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

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-11 Thread Anthony Towns
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

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-11 Thread Anthony Towns
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 > ei

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-18 Thread Anthony Towns
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

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-19 Thread Anthony Towns
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 implemen

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-11 Thread Anthony Towns
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 > tr

[Lightning-dev] Lightning over taproot with PTLCs

2021-10-08 Thread Anthony Towns
Hi all, Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of taproot and implement PTLCs. It's particularly inspired by ZmnSCPxj's thoughts from Dec 2019 [0], and some of his and Lloyd Fournier's posts since then (which are listed in references) -- in particular, I think

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-08 Thread Anthony Towns
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

Re: [Lightning-dev] PTLCs early draft specification

2021-12-19 Thread Anthony Towns
On Wed, Dec 08, 2021 at 04:02:02PM +0100, Bastien TEINTURIER wrote: > I updated my article [0], people jumping on the thread now may find it > helpful to better understand this discussion. > [0] https://github.com/t-bast/lightning-docs/pull/16 Since merged, so

Re: [Lightning-dev] PTLCs early draft specification

2021-12-21 Thread Anthony Towns
On Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote: > The reason we have "toxic waste" with HTLCs is because we commit to the > payment_hash directly inside the transaction scripts, so we need to > remember all the payment_hash we've seen to be able to recreate the > scripts (and

Re: [Lightning-dev] PTLCs early draft specification

2021-12-08 Thread Anthony Towns
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

Re: [Lightning-dev] PTLCs early draft specification

2021-12-08 Thread Anthony Towns
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.

Re: [Lightning-dev] Impact of eltoo loss of state

2021-07-21 Thread Anthony Towns
On Wed, Jul 14, 2021 at 04:44:24PM +0200, Christian Decker wrote: > Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty > loss-of-state equates to loss-of-funds, in eltoo this is reduced to > impact only funds that are in a PTLC at the time of the loss-of-state. Well, the