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
On Wed, Dec 08, 2021 at 04:02:02PM +0100, Bastien TEINTURIER wrote:
> I updated my article , people jumping on the thread now may find it
> helpful to better understand this discussion.
>  https://github.com/t-bast/lightning-docs/pull/16
Since merged, so
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
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
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
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, 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
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 .
I kind-of think it'd be more interesting to simulate eltoo's behaviour.
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
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
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
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
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 , and
some of his and Lloyd Fournier's posts since then (which are listed in
references) -- in particular, I think
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  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 . [...]
On Thu, Aug 26, 2021 at 04:33:23PM +0200, René Pickhardt via Lightning-dev
> 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
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.
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
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
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
> 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
There's been discussions on twitter and elsewhere advocating for
setting the BOLT#7 fee_base_msat value  to zero. I'm just writing
this to summarise my understanding in a place that's able to easily be
Setting the base fee to zero has a couple of benefits:
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
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.
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
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
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
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
> 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
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
> to use Eltoo and use a absolute lock time,
It's already impossible to simultaneously spend two inputs if one
requires a locktime specified
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
) on lighting, at least once PTLCs exist.
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
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
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
> Since the onchain HTLC might have a timelock of, say, a few hundred
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
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
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
> Decker-Russell-Osuntokun requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`, and
> its details seem less settled for now than
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
On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
> Anthony Towns writes:
> [ Snip summary, which is correct ]
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
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
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
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...
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
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.
I don't think you could reasonably do this for
On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev
> With the recently renewed interest in eltoo, a proof-of-concept implementation
> , and the discussions regarding clean abstractions for off-chain protocols
> [2,3], I thought it might be time to revisit the
On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote:
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
I don't think there's any meaningful difference between making a new
opcode and making a new tapscript public key type; the
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
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
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
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
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
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
(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
On Tue, Mar 13, 2018 at 06:07:48PM +0100, René Pickhardt via Lightning-dev
> 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
> on my statement that the in the
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.
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
Mail list logo