On Tue, Jan 30, 2024 at 05:17:04AM +, ZmnSCPxj via bitcoin-dev wrote:
>
> > I should note that under Decker-Russell-Osuntokun the expectation is that
> > both counterparties hold the same offchain transactions (hence why it is
> > sometimes called "LN-symmetry").
> > However, there are two
Hi all,
It's been mentioned on bitcoin-dev [0] that linuxfoundation is apparently
going to cease hosting mailing lists in the next couple of months.
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022134.html
Anyway, I know some folks have already seen it, but I've
On 21 September 2023 11:44:47 am AEST, Lloyd Fournier
wrote:
>Hi AJ,
>
>On Wed, 20 Sept 2023 at 17:19, Anthony Towns wrote:
>
>>
>> I think:
>>
>> https://github.com/BlockstreamResearch/scriptless-scripts/pull/24
>>
>> describes (w/ proof sketc
On Wed, Sep 06, 2023 at 12:14:08PM -0400, Greg Sanders wrote:
> Since taproot channels are deploying Soon(TM), I think it behooves us to
> turn some attention to PTLCs as a practical matter, drilling down a bit
> deeper.
I think a bunch of these depends on who's interested in doing the work
to
On Fri, Sep 08, 2023 at 06:54:46PM +, jlspc via Lightning-dev wrote:
> TL;DR
> =
I haven't really digested this, but I think there's a trust vs
capital-efficiency tradeoff here that's worth extracting.
Suppose you have a single UTXO, that's claimable by "B" at time T+L,
but at time T
On Mon, Jul 31, 2023 at 02:42:29PM -0400, Clara Shikhelman wrote:
> > A different way of thinking about the monetary approach is in terms of
> > scaling rather than deterrance: that is, try to make the cost that the
> > attacker pays sufficient to scale up your node/the network so that you
> >
On Wed, Jul 19, 2023 at 09:56:11AM -0400, Carla Kirk-Cohen wrote:
> Thanks to everyone who traveled far, Wolf for hosting us in style in
> NYC and to Michael Levin for helping out with notes <3
Thanks for the notes!
Couple of comments:
> - What is the “top of mempool” assumption?
FWIW, I think
On Tue, Apr 18, 2023 at 07:17:34PM +, jlspc wrote:
> > One thing that confuses me about the paper is how to think about routing
> > to a "channel" rather than a node -- ie the payment from "E->FG->A" where
> > "FG" isn't "F" or "G", but "both of them".
> Yes, I found it very difficult to think
On Sat, Apr 08, 2023 at 10:26:45PM +, jlspc via Lightning-dev wrote:
> From my perspective, this paper makes two contributions (which, to be fair,
> may only be "interesting" :)
One thing that confuses me about the paper is how to think about routing
to a "channel" rather than a node -- ie
On Tue, Apr 04, 2023 at 12:00:32AM +1000, Anthony Towns wrote:
> On Sat, Mar 18, 2023 at 12:41:00AM +, jlspc via Lightning-dev wrote:
> > TL;DR
>
> Step 1: Tunable penalties;
> https://github.com/JohnLaw2/ln-tunable-penalties
>
> https://lists.linuxfoundation.org
On Sat, Mar 18, 2023 at 12:41:00AM +, jlspc via Lightning-dev wrote:
> TL;DR
Even with Harding's optech write ups, and the optech space, I barely
follow all this, so I'm going to try explaining it too as a way of
understanding it myself; hopefully maybe that helps someone. Corrections
On Mon, Apr 11, 2022 at 02:59:16PM -0400, Olaoluwa Osuntokun wrote:
Thread necromancy, but hey.
> > anything about Taro or the way you plan to implement support for
> > transferring fungible assets via asset-aware LN endpoints[1] will address
> > the "free call option" problem, which I think was
ds, and (R,s) is a BIP340 signature of m by
Bob, satisfying s*G = R + H(R,P,m)*P, and that signature serves as
her payment receipt from Bob.
Cheers,
aj
On Thu, Jan 26, 2023 at 11:04:12AM +1000, Anthony Towns wrote:
> On Tue, Jan 10, 2023 at 07:41:09PM +, vwallac
On Tue, Jan 10, 2023 at 07:41:09PM +, vwallace via Lightning-dev wrote:
> The open research question relates to how the sender will get an invoice from
> the receiver, given that they are offline at sending-time.
Assuming the overall process is:
* Alice sends a payment to Bob, who has
On Thu, Jan 05, 2023 at 06:59:42PM -0500, Antoine Riard wrote:
> > A simple advantage to breaking the symmetry is that if A does a unilateral
> > close, then B can immediately confirm that closure releasing all funds
> > for both parties. Without breaking the symmetry, you can't distinguish
> >
On Wed, Jan 04, 2023 at 01:06:36PM +1100, Lloyd Fournier wrote:
> The advantage of using a covenant
> is that the channel would not have an expiry date and therefore be a first
> class citizen among channels.
I think the approach here would be:
* receive funds on the in-potentiam address with
On Tue, Dec 13, 2022 at 08:22:55PM -0500, Antoine Riard wrote:
> > prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
> > broadcast one of either CA.n or RA.n, and will then have ~150 blocks
> > to claim the HTLC before its timeout
> From my understanding, with two party
On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote:
> The attack purpose is to delay the confirmation of the final settlement
> transaction S, to double-spend a HTLC forwarded by a routing hop.
> The cltv_expiry_delta requested by Ned is equal to N=144.
I believe what you're suggesting
On Thu, Dec 08, 2022 at 02:14:06PM -0500, Antoine Riard wrote:
> > - 2022-10-21, eltoo/chia:
> https://twitter.com/bramcohen/status/1583122833932099585
> On the eltoo/chia variant, from my (quick) understanding, the main
> innovation aimed for is
I'd say the main innovation aimed for is just
Hi all,
On the eltoo irc channel we discussed optimising eltoo for the 2-party
scenario; figured it was probably worth repeating that here.
This is similar to:
- 2018-07-18, simplified eltoo:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001363.html
- 2021-09-17, IID
On Thu, Sep 29, 2022 at 12:41:44AM +, ZmnSCPxj wrote:
> > I get what you're saying, but I don't think a "stock of liquidity"
> > is a helpful metaphor/mental model here.
> > "Liquidity" usually means "how easy it is to exchange X for Y" -- assets
> > for cash, etc; but for lightning, liquidity
On Tue, Sep 27, 2022 at 12:23:38AM +, ZmnSCPxj via Lightning-dev wrote:
> All monetisation is fee-based; the question is who pays the fees.
This isn't true. For example, if you can successfully track the payments
you route, you can monetize by selling data about who's buying what
from whom.
On Mon, Sep 26, 2022 at 01:26:57AM +, ZmnSCPxj via Lightning-dev wrote:
> > > * you're providing a way of throttling payment traffic independent of
> > > fees -- since fees are competitive, they can have discontinuous effects
> > > where a small change to fee can cause a large change to
On Thu, Sep 22, 2022 at 08:40:30AM +0200, René Pickhardt via Lightning-dev
wrote:
> While trying to estimate the expected liquidity distribution in depleted
> channels due to drain via Markov Models I realized that we can exploit the
> `htlc_maxium_msat` setting to act as a control valve and
On Fri, Sep 23, 2022 at 03:13:53PM -0500, lisa neigut wrote:
> Some interesting points here. Will try to respond to some of them.
> > pathfinding algorithms which depend on unscalable data collection
> Failed payment attempts are indistinguishable from data collection probing.
Even so, data
On Wed, Jun 29, 2022 at 12:38:17PM +, ZmnSCPxj wrote:
> > > ### Inverting The Filter: Feerate Cards
> > > Basically, a feerate card is a mapping between a probability-of-success
> > > range and a feerate.
> > > * 00%->25%: -10ppm
> > > * 26%->50%: 1ppm
> > > * 51%->75%: 5ppm
> > > *
On Sun, Jun 05, 2022 at 02:29:28PM +, ZmnSCPxj via Lightning-dev wrote:
Just sharing my thoughts on this.
> Introduction
>
> Optimize for reliability+
>uncertainty+fee+drain+uptime...
> .--~~--.
> /\
>
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 [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
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.
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
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 [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
> ei
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
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
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
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]. [...]
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
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
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
> 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
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
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.
Well, the
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
>
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
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
> 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
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
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]
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
> me?
>
> 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
>
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
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
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 ]
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
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...
> 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.
> OP_SETPUBKEYSIGHASH
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
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
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
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
> >
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
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
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
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,
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
> on
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
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
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
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
93 matches
Mail list logo
