Re: [Lightning-dev] Proposal: Add support for proxying p2p connections to/from LND

2022-09-01 Thread Olaoluwa Osuntokun
Hi Alex, This is a super cool project! I've shared some thoughts here in a comment on the draft PR: PR: https://github.com/lightningnetwork/lnd/pull/6843#issuecomment-1234933319 Also I cc'd the lnd mailing list on this reply, perhaps we can move the discussion over there (or in the issue) since

Re: [Lightning-dev] Onion messages rate-limiting

2022-07-01 Thread Olaoluwa Osuntokun
Hi Matt, > Ultimately, paying suffers from the standard PoW-for-spam issue - you > cannot assign a reasonable cost that an attacker cares about without > impacting the system's usability due to said cost. Applying this statement to related a area, would you also agree that proposals to introduce

Re: [Lightning-dev] Onion messages rate-limiting

2022-07-01 Thread Olaoluwa Osuntokun
Hi Val, > Another huge win of backpressure is that it only needs to happen in DoS > situations, meaning it doesn’t have to impact users in the normal case. I agree, I think the same would apply to prepayments as well (0 or 1 msat in calm times). My main concern with relying _only_ on

Re: [Lightning-dev] Achieving Zero Downtime Splicing in Practice via Chain Signals

2022-07-01 Thread Olaoluwa Osuntokun
29, 2022 at 5:35 PM Rusty Russell wrote: > Olaoluwa Osuntokun writes: > > Hi Rusty, > > > > Thanks for the feedback! > > > >> This is over-design: if you fail to get reliable gossip, your routing > will > >> suffer anyway. Nothing new here. >

Re: [Lightning-dev] Achieving Zero Downtime Splicing in Practice via Chain Signals

2022-07-01 Thread Olaoluwa Osuntokun
Hi Lisa, > Adding a noticeable on-chain signal runs counter to the goal of the move > to taproot / gossip v2, which is to make lightning's onchain footprint > indistinguishable from any other onchain usage My model of gossip v2 is something like: * there's no longer a 1:1 mapping of channels

[Lightning-dev] Using BOLT 8 to Send Wumbo Messages

2022-07-01 Thread Olaoluwa Osuntokun
Hi y'all, Quick post... A few weeks ago, some of the dlcspecs developers reached out to ask for feedback on this PR [1] that attempts to specify a way to send messages larger than 65 KB using BOLT 8 (Noise based encrypted transport). After taking a glance at the PR, I realized that it isn't

Re: [Lightning-dev] Onion messages rate-limiting

2022-06-29 Thread Olaoluwa Osuntokun
Hi t-bast, Happy to see this finally written up! With this, we have two classes of proposals for rate limiting onion messaging: 1. Back propagation based rate limiting as described here. 2. Allowing nodes to express a per-message cost for their forwarding services, which is described here

Re: [Lightning-dev] Achieving Zero Downtime Splicing in Practice via Chain Signals

2022-06-29 Thread Olaoluwa Osuntokun
requirements to detect onchain > closes at all, and optionally add a perm close message. > > Cheers, > Rusty. > > Olaoluwa Osuntokun writes: > > Hi y'all, > > > > This mail was inspired by this [1] spec PR from Lisa. At a high level, it > > proposes the

[Lightning-dev] Achieving Zero Downtime Splicing in Practice via Chain Signals

2022-06-27 Thread Olaoluwa Osuntokun
Hi y'all, This mail was inspired by this [1] spec PR from Lisa. At a high level, it proposes the nodes add a delay between the time they see a channel closed on chain, to when they remove it from their local channel graph. The motive here is to give the gossip message that indicates a splice is

Re: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary

2022-06-23 Thread Olaoluwa Osuntokun
Hi Michael, > A minor point but terminology can get frustratingly sticky if it isn't > agreed on early. Can we refer to it as nested MuSig2 going > forward rather than recursive MuSig2? No strong feelings on my end, the modifier _nested_ is certainly a bit less loaded and conceptually simpler,

[Lightning-dev] LN Summit 2022 Notes & Summary/Commentary

2022-06-07 Thread Olaoluwa Osuntokun
Hi y'all, Last week nearly 30 (!) Lightning developers and researchers gathered in Oakland, California for three day to discuss a number of matters related to the current state and evolution of the protocol. This time around, we had much better representation for all the major Lightning Node

Re: [Lightning-dev] Taro - Separating Taro concerns from LN token concerns

2022-05-02 Thread Olaoluwa Osuntokun
Hi John, > That said, I believe that the correct approach to supporting "tokens on > Lightning" is to make it a separate concern from Taro, and that LL should > create a separate BOLT proposal from the current Taro BIPs to ensure it LN > standards have a genericized protocol that all LN

Re: [Lightning-dev] [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

2022-04-11 Thread Olaoluwa Osuntokun
Hi Ruben, > Also, the people that are responsible for the current shape of RGB aren't > the people who originated the idea, so it would not be fair to the > originators either (Peter Todd, Alekos Filini, Giacomo Zucco). Sure I have no problems acknowledging them in the current BIP draft. Both

Re: [Lightning-dev] Taro: A Taproot Asset Representation Overlay

2022-04-11 Thread Olaoluwa Osuntokun
Hi Harding, Great questions! > 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 first discussed on this > list by Corné Plooy[2] and was later extended

Re: [Lightning-dev] [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

2022-04-08 Thread Olaoluwa Osuntokun
ring Taro token ownership from one > Bitcoin UTXO to another, do you generate a new UTXO for the recipient or do > you support the ability to "teleport" the tokens to an existing UTXO like > how RGB does it? If the latter, have you given consideration to timing > issues that m

[Lightning-dev] Taro: A Taproot Asset Representation Overlay

2022-04-05 Thread Olaoluwa Osuntokun
Hi y'all, I'm excited to publicly publish a new protocol I've been working on over the past few months: Taro. Taro is a Taproot Asset Representation Overlay which allows the issuance of normal and also collectible assets on the main Bitcoin chain. Taro uses the Taproot script tree to commit extra

Re: [Lightning-dev] Dynamic Commitments Part 2: Taprooty Edition

2022-03-24 Thread Olaoluwa Osuntokun
PM Olaoluwa Osuntokun wrote: > Hi y'all, > > ## Dynamic Commitments Retrospective > > Two years-ish ago I made a mailing list post on some ideas re dynamic > commitments [1], and how the concept can be used to allow us to upgrade > channel types on the fly, and also remove pe

[Lightning-dev] Dynamic Commitments Part 2: Taprooty Edition

2022-03-24 Thread Olaoluwa Osuntokun
Hi y'all, ## Dynamic Commitments Retrospective Two years-ish ago I made a mailing list post on some ideas re dynamic commitments [1], and how the concept can be used to allow us to upgrade channel types on the fly, and also remove pesky hard coded limits like the 483 HTLC in-flight limit that's

Re: [Lightning-dev] Taproot-aware Channel Announcements + Proof Verification

2022-03-23 Thread Olaoluwa Osuntokun
ion (FROST?) all together). -- Laolu On Wed, Mar 23, 2022 at 2:02 PM David A. Harding wrote: > On 22.03.2022 15:10, Olaoluwa Osuntokun wrote: > > ### Should the proof+verification strongly bind to the LN context? > > Today, nodes use the two bitcoin keys and construct a p

Re: [Lightning-dev] [RFC] Lightning gossip alternative

2022-03-22 Thread Olaoluwa Osuntokun
Hi Rusty, > Timestamps are replaced with block heights. This is a conceptually small change, but would actually make things like rate limiting updates for implementations easier and more uniform. A simple rule would be only allowing an update per block, which cuts down a lot on potential chatter

[Lightning-dev] Taproot-aware Channel Announcements + Proof Verification

2022-03-22 Thread Olaoluwa Osuntokun
Hi y'all, On the lnd side we've nearly finished fully integrating taproot into the codebase [1] (which includes the btcsuite set of libraries and also full btcwallet support), scheduled to ship in 0.15 (~April), which will enable existing users of lnd's on-chain wallet and APIs to start getting

Re: [Lightning-dev] A Proposal for Adding Bandwidth Metered Payment to Onion Messages

2022-03-22 Thread Olaoluwa Osuntokun
nding algorithms continue to evolve to factor in "reliability" information (usually some derived probability of success), which can tend to favor well managed and responsive nodes. [1]: https://github.com/lightning/blips/blob/master/blip-0003.md [2]: https://github.com/lightning/bolts/pull/6

[Lightning-dev] A Proposal for Adding Bandwidth Metered Payment to Onion Messages

2022-02-23 Thread Olaoluwa Osuntokun
Hi y'all, (TL;DR: a way to nodes to get paid to forward onion messages by adding an upfront session creation phase that uses AMP tender a messaging session to a receiver, with nodes being paid upfront for purchase of forwarding bandwidth, and a session identifier being transmitted alongside onion

Re: [Lightning-dev] Future of Atomic Multi-path Payments (AMP)?

2022-02-21 Thread Olaoluwa Osuntokun
Hi Jozef, > I'm working on a project that uses LND with Atomic Multi-path Payments > (AMP) invoices. It seems there isn't any mobile lightning wallet that is > able to send sats to AMP invoices. Any mobile wallet built on lnd v0.14 should be able to send to the reusable invoices (has the

Re: [Lightning-dev] Normal operation questions

2022-02-16 Thread Olaoluwa Osuntokun
and revocations, what > purpose do the additional commitments and revocations provide? > > > Thanks again! > Ben > > -- > Ben Weintraub > PhD Student > Khoury College of Computer Sciences > Northeastern University > https://ben-weintraub.com/ > >

Re: [Lightning-dev] Normal operation questions

2022-02-15 Thread Olaoluwa Osuntokun
Hi Benjamin, > 1) Multiple sources indicate that after Alice sends the `update_add_htlc`, > she should then send the `commitment_signed`, but why is it important that > she sends it first (before Bob)? As far as I understand, as long as she > doesn't revoke the old state before Bob commits to the

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

2021-11-02 Thread Olaoluwa Osuntokun
-- Laolu On Tue, Nov 2, 2021 at 7:34 PM Olaoluwa Osuntokun wrote: > Circling back to close the loop here: > > * The new Github org (https://github.com/lightning) now exists, and all > the > major implementation maintainers have been added to the organization as > admi

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

2021-11-02 Thread Olaoluwa Osuntokun
ace during the recent protocol dev meetup!), happy we were able to resolve things and begin the next chapter in the evolution of the Lightning protocol! -- Laolu On Fri, Oct 15, 2021 at 1:49 AM Fabrice Drouin wrote: > On Tue, 12 Oct 2021 at 21:57, Olaoluwa Osuntokun > wrote: > > Also not

[Lightning-dev] LN Summit 2021 Notes & Summary/Commentary

2021-11-02 Thread Olaoluwa Osuntokun
Hi y'all, A few weeks ago over a dozen Lightning developers met up in Zurich for two days to discuss a number of matters related to the current state and evolution of the protocol. All major implementations were represented to some degree, and we even had a number of "independent"

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

2021-10-12 Thread Olaoluwa Osuntokun
Hi Fabrice, > I believe that was a mistake: a few days ago, Arcane Research published a > fairly detailed report on the state of the Lightning Network: > https://twitter.com/ArcaneResearch/status/1445442967582302213. They > obviously did some real work there, and seem to imply that their report

Re: [Lightning-dev] Stateless invoices with proof-of-payment

2021-09-22 Thread Olaoluwa Osuntokun
Hi Joost, > The conventional approach is to create a lightning invoice on a node and > store the invoice together with order details in a database. If the order > then goes unfulfilled, cleaning processes remove the data from the node > and database again. > The problem with this setup is that

Re: [Lightning-dev] Opening balanced channels using PSBT

2021-09-22 Thread Olaoluwa Osuntokun
Hi Ole, It's generally known that one can use out of band transaction construction, and the push_amt feature in the base funding protocol to simulate dual funded channels. The popular 'balanceofsatoshis' tool has a command that packages up the interaction (`open-balanced-channel`) into an easier

Re: [Lightning-dev] Dropping Tor v2 onion services from node_announcement

2021-09-22 Thread Olaoluwa Osuntokun
Earlier this week I was helping a user debug a Tor related issue, and realized (from the logs) that some newer Tor clients are already refusing to connect out to v2 onion services. On the lnd side, I think we'll move to disallow users creating a v2 onion service in our next major release (0.14),

Re: [Lightning-dev] #zerobasefee

2021-08-16 Thread Olaoluwa Osuntokun
Matt wrote: > I'm frankly still very confused why we're having these conversations now 1000% this!! This entire conversation strikes me as extremely premature and backwards tbh. Someone experimenting with a new approach shouldn't prompt us to immediately modify the protocol to better "fit" the

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-07-01 Thread Olaoluwa Osuntokun
ory instead. I don't see the value in having both bLIPs and >> BIPs since AFAICT they seem to be functionally equivalent and BIPs are >> not restricted to exclude lightning, and never have been. >> >> I believe the reason this move to BIPs hasn't happened organically is >

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-07-01 Thread Olaoluwa Osuntokun
ere > strongly encouraged to write specs for new lightning features > elsewhere (like the BIP repo) then you would see this issue of growing > BOLTs resolved. > > Cheers > Ariel Lorenzo-Luaces > > On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun > wrote: > > &

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread Olaoluwa Osuntokun
> That being said I think all the points that are addressed in Ryan's mail > could very well be formalized into BOLTs but maybe we just need to rethink > the current process of the BOLTs to make it more accessible for new ideas > to find their way into the BOLTs? I think part of what bLIPs are

Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)

2021-02-22 Thread Olaoluwa Osuntokun
> I think the problem of accidental channel closure is getting ignored by > devs. > > If we think any anti-DoS fee will be "insignificant" compared to the cost > of closing and reopening a channel, maybe dev attention should be on > fixing accidental channel closure costs than any anti-DoS fee

Re: [Lightning-dev] Lightning Pool: A Non-Custodial Channel Lease Marketplace

2020-11-05 Thread Olaoluwa Osuntokun
Hi Z, Thanks for such kind words! > Is there a documentation for the client/server intercommunications > protocol? Long form documentation on the client/server protocol hasn't yet been written. However, just like Loop, the Pool client uses a fully-featured gRPC protocol to communicate with the

[Lightning-dev] Lightning Pool: A Non-Custodial Channel Lease Marketplace

2020-11-02 Thread Olaoluwa Osuntokun
Hi y'all, We've recently released a new system which may be of interest to this list, Lightning Pool [1]. Alongside a working client [2], we've also released a white paper which goes deeper into the architecture of the system. Pool builds on some earlier ideas that were tossed around the ML

Re: [Lightning-dev] Making (some) channel limits dynamic

2020-10-12 Thread Olaoluwa Osuntokun
> I suggest adding tlv records in `commitment_signed` to tell our channel > > peer that we're changing the values of these fields. I think this fits in nicely with the "parameter re-negotiation" portion of my loose Dynamic commitments proposal. Note that in that paradigm, something like this

Re: [Lightning-dev] Why should funders always pay on-chain fees?

2020-10-12 Thread Olaoluwa Osuntokun
> It seems to me that the "funder pays all the commit tx fees" rule exists > solely for simplicity (which was totally reasonable). At this stage, I've learned that simplicity (when doing anything that involves multi-party on-chain fee negotiating/verification/enforcement can really go a long

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Olaoluwa Osuntokun
Hi Z, > Probably arguably off-topic, but this post triggered me into thinking > about an insane idea: offchain update from existing Poon-Dryja to newer > Decker-Russell-Osuntokun ("eltoo") mechanism. Ooo, yeh I don't see why this would be possible assuming at that point no_input has been

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Olaoluwa Osuntokun
queue these un-acked > messages > and replay them after the commitment format update completes (or just drop > them > and cancel corresponding upstream HTLCs if needed). > > Regarding initiating the commitment format update, how do you see this > happen? > The funder activate

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Olaoluwa Osuntokun
-- Laolu On Mon, Jul 20, 2020 at 6:18 PM Olaoluwa Osuntokun wrote: > Hi y'all, > > In this post, I'd like to share an early version of an extension to the > spec > and channel state machine that would allow for on-the-fly commitment > _format/type_ changes. Notably, this wou

[Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-20 Thread Olaoluwa Osuntokun
Hi y'all, In this post, I'd like to share an early version of an extension to the spec and channel state machine that would allow for on-the-fly commitment _format/type_ changes. Notably, this would allow for us to _upgrade_ commitment types without any on-chain activity, executed in a

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

2020-06-21 Thread Olaoluwa Osuntokun
Hi Jeremy, The up-front costs can be further mitigated even without something like CTV (which makes things more efficient) by adding a layer of in-direction w.r.t how HTLCs are manifested within the commitment transactions. To do this, we add a new 2-of-2 multi-sig output (an HTLC indirect block)

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

2020-06-21 Thread Olaoluwa Osuntokun
Hi Rene, IMO this is mostly mitigated by anchor commitments. The impact of this attack is predicated on the "victim" paying 5x on-chain fees (for their confirmation target) to sweep all their HTLCs. Anchor commitments let the initiator of the channel select a very low starting fee (just enough

Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Olaoluwa Osuntokun
Hi Antoine, > Even with cheaper, more efficient protocols like BIP 157, you may have a > huge discrepancy between what is asked and what is offered. Assuming 10M > light clients [0] each of them consuming ~100MB/month for filters/headers, > that means you're asking 1PB/month of traffic to the

Re: [Lightning-dev] An update on PTLCs

2020-04-23 Thread Olaoluwa Osuntokun
BOLTs, which does actually seem relatively > minimal (although as you mention, these minimal changes to the BOLTs do > trigger large changes in many implementations). Also, good point on how > BOLT 11 (invoicing) will have to be altered as well, must've slipped my > mind. > > Best,

Re: [Lightning-dev] An update on PTLCs

2020-04-22 Thread Olaoluwa Osuntokun
Hi Nadav, Thanks for the updates! Super cool to see this concept continue to evolve and integrate new technologies as they pop up. > I believe this would only require a few changes to existing nodes: Rather than a "few changes", this would to date be the largest network-level update undertaken

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Olaoluwa Osuntokun
fee increase, it's likely that the war terminates with _one_ of them getting into the block, which seems to resolve everything? -- Laolu On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo wrote: > > > On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun wrote: > > > > Hmm, maybe the prop

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Olaoluwa Osuntokun
en everyone is made whole. [1]: https://github.com/bitcoin/bitcoin/pull/18191 On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo wrote: > A few replies inline. > > On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote: > > Hi Matt, > > > > > >> While this is somewha

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Olaoluwa Osuntokun
, Apr 22, 2020 at 4:05 PM Olaoluwa Osuntokun wrote: > Hi Z, > > > It seems to me that, if my cached understanding that `<0> > > OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then > adding > > that to the hashlock branch (2 witness bytes, 0.5 weight) w

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Olaoluwa Osuntokun
Hi Z, > It seems to me that, if my cached understanding that `<0> > OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding > that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty > low-weight mitigation against this attack. I think this works...so

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-21 Thread Olaoluwa Osuntokun
> So what is needed is to allow B to add fees to HTLC-Timeout: Indeed, anchors as defined in #lightning-rfc/688 allows this. > * With `SIGHASH_NOINPUT` we can make the C-side signature > `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side > signature for a higher-fee version of

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-21 Thread Olaoluwa Osuntokun
Hi Matt, > While this is somewhat unintuitive, there are any number of good anti-DoS > reasons for this, eg: None of these really strikes me as "good" reasons for this limitation, which is at the root of this issue, and will also plague any more complex Bitcoin contracts which rely on nested

[Lightning-dev] Anchor Outputs Spec & Implementation Progress

2020-03-30 Thread Olaoluwa Osuntokun
Hi y'all, We've been discussing the current state of the spec and implementation readiness of anchor outputs for a few week now on IRC. As detailed conversations are at times difficult to have on IRC, and there's no true history, I figured I'd start a new discussion thread where we can hammer out

[Lightning-dev] Potential Minor Sphinx Privacy Leak and Patch

2019-11-05 Thread Olaoluwa Osuntokun
Hi y'all, A new paper analyzing the security of the Sphinx mix-net packet format [1] (and also HORNET) has recently caught my attention. The paper is rather long and very theory heavy, but the TL;DR is this: * The OG Sphinx paper proved various aspects of its security using a model for

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

2019-11-05 Thread Olaoluwa Osuntokun
Hi Rusty, Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other alternatives for a few years now, and none of them seems to resolve the series of routing related incentive issues that prepaid HTLCs would. > Since both Offers and Joost's WhatSat are looking at sending messages, >

Re: [Lightning-dev] Rendez-vous on a Trampoline

2019-11-05 Thread Olaoluwa Osuntokun
Hi t-bast, > She creates a Bolt 11 invoice containing that pre-encrypted onion. This seem insufficient, as if the prescribed route that Alice selects fails, then the sender has no further information to go off of (let's say Teddy is offline, but there're other pats). cdecker's rendezvous sketch

Re: [Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

2019-10-11 Thread Olaoluwa Osuntokun
Hi Rusty, I think this change may be a bit misguided, and we should be careful about making sweeping changes to default values like this such as fees. I'm worried that this post (and the subsequent LGTMs by some developers) promotes the notion that somehow in Lightning, developers decide on fees

Re: [Lightning-dev] CVEs assigned for lightning projects: please upgrade!

2019-09-10 Thread Olaoluwa Osuntokun
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 We've confirmed instances of the CVE being exploited in the wild. If you’re not on the following versions of either of these implementations (these versions are fully patched), then you need to upgrade now to avoid risk of funds loss: * lnd

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-08-02 Thread Olaoluwa Osuntokun
> I found out recently (mid-2019) that mainnet Lightning nodes take an > inordinate amount of time to find a route between themselves and an > arbitrary payee node. > Typical quotes suggested that commodity hardware would take 2 seconds to > find a route Can you provide a reproducible benchmark

[Lightning-dev] Extending Associated Data in the Sphinx Packet to Cover All Payment Details

2019-02-07 Thread Olaoluwa Osuntokun
Hi y'all, I'm not sure how good defenses are on implementations other than lnd, but all implementations *should* be keeping a Sphinx reply cache of the past shared secrets they know of [1]. If a node comes across an identical shared secret of that in the cache, then they should reject that

[Lightning-dev] SURBs as a Solution for Protocol-Level Payment ACKs

2019-02-07 Thread Olaoluwa Osuntokun
Hi y'all, Recently we've started to do more design work related to the Sphinx packet (EOB format, rendezvous protocol). This prompted me to re-visit the original Sphinx paper to refresh my memory w.r.t some of the finer details of the protocol. While I was re-reading the paper, I realized that

Re: [Lightning-dev] Network probes

2019-01-18 Thread Olaoluwa Osuntokun
Hi Andrea, > This saves the receiving node from doing a database lookup Nodes can and eventually should start using bloom filters to avoid most database lookups for incoming payment hashes. The false positive rate can be set to a very low value as the bloom filter doesn't need to transmitted,

Re: [Lightning-dev] Mandatory "d" or "h" UX issues

2019-01-14 Thread Olaoluwa Osuntokun
It isn't mandatory. It can be left blank, none of the existing wallets require users to input a description when they make an invoice. On Mon, Jan 14, 2019, 3:28 PM Francis Pouliot I'm currently in the process of building the Lightning Network payout > feature which will allow users to purchase

Re: [Lightning-dev] Approximate assignment of option names: please fix!

2018-11-16 Thread Olaoluwa Osuntokun
> OG AMP is inherently spontaneous in nature, therefore invoice might not exist > to put the feature on. That is incorrect. One can use an invoice along with AMP as is, in order to tag a payment. As an example, I want to deposit to an exhcange, so I get an invoice from them. I note that the

Re: [Lightning-dev] Wumbological local AND global features

2018-11-15 Thread Olaoluwa Osuntokun
I realized the other day that the wumbo bit should also likely encompass wumbo payments. What good is a wumbo channel that doesn't also allow wumbo payments? Naturally if the bit is signalled globally, then this should also signal the willingness of the node to forward larger payments up to their

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

2018-11-15 Thread Olaoluwa Osuntokun
> 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 (looks to other nodes as a normal packet), possibly by controlling multiple

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

2018-11-08 Thread Olaoluwa Osuntokun
Was approaching more so from the angle of a node new node with no existing channels seeking to bootstrap connections to the network. -- Sent from my Spaceship On Fri, Nov 9, 2018, 9:10 AM Anthony Towns On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote: > > > A

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

2018-11-07 Thread Olaoluwa Osuntokun
> 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 for this to work, we would need to undo this at a global scale to ensure

Re: [Lightning-dev] Improving payment UX with low-latency route probing

2018-11-06 Thread Olaoluwa Osuntokun
Hi Fabrice, I think HORNET would address this rather nicely! During the set up phase (which uses Sphinx), the sender is able to get a sense of if the route is actually "lively" or not, as the circuit can't be finalized if all the nodes aren't available. Additionally, during the set up phase, the

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-05 Thread Olaoluwa Osuntokun
r operation up right afterwards. -- Laolu On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell wrote: > Olaoluwa Osuntokun writes: > > Hi Rusty, > > > > Happy to get the splicing train rolling! > > > >> We've had increasing numbers of c-lightning users get upset the

Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol

2018-11-05 Thread Olaoluwa Osuntokun
Hi tomokio, This is so dope! We've long discussed creating canned protocol transcripts for other implementations to assert their responses again, and I think this is a great first step towards that. > Our proposal: > Every implementation has compile option which enable output key information >

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-05 Thread Olaoluwa Osuntokun
> However personally I do not really see the need to create multiple channels > to a single peer, or increase the capacity with a specific peer (via splice > or dual-funding). As Christian says in the other mail, this consideration, > is that it becomes less a network and more of some channels to

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-11-05 Thread Olaoluwa Osuntokun
> This seems at odds with the goal of "if the remote party force closes, then > I get my funds back immediately without requiring knowledge of any secret > data" Scratch that: the static back ups just need to include this CSV value! -- Laolu On Tue, Nov 6, 2018 at 3:29 PM

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-11-05 Thread Olaoluwa Osuntokun
Hi Rusty, I'm a big fan in general of most of this! Amongst many other things, it'll: simplify the whole static channel backup + recovery workflow, and avoid all the fee related headaches we've run into over the past few months. > - HTLC-timeout and HTLC-success txs sigs are >

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-15 Thread Olaoluwa Osuntokun
> I would suggest more to consider the simpler method, despite its larger > onchain footprint (which is galling), The on-chain footprint is a shame, and also it gets worse if we start to allow multiple pending splices. Also the lack of a non-blocking splice in is a big draw back IMO. > but

Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity

2018-09-28 Thread Olaoluwa Osuntokun
you cancel back, then they know that you had enough bandwidth to _accept_ the HTLC in the first place. -- Laolu On Wed, Sep 26, 2018 at 5:54 PM Rusty Russell wrote: > Olaoluwa Osuntokun writes: > >> That might not be so desirable, since it leaks the current channel > >> cap

Re: [Lightning-dev] proposal for Lightning Network improvement proposals

2018-07-23 Thread Olaoluwa Osuntokun
ror` > message from BOLT #1 >* If the error is not specific to any channel: set channel_id to 0. > > A receiving node >* If experiment_name_hash is unknown: > - MUST fail the channel. >* If channel_id is 0 > - MUST fail all the channels > > Ration

Re: [Lightning-dev] proposal for Lightning Network improvement proposals

2018-07-22 Thread Olaoluwa Osuntokun
n was not about creating another place > but more about making the process more transparent or kind of filling the > gap that I felt was there. > > I am sorry for spaming mailboxes with my suggestion just because I didn't > understand the current process. > > > Olaoluwa

Re: [Lightning-dev] proposal for Lightning Network improvement proposals

2018-07-22 Thread Olaoluwa Osuntokun
We already have the equiv of improvement proposals: BOLTs. Historically new standardization documents are proposed initially as issues or PR's when ultimately accepted. Why do we need another repo? On Sun, Jul 22, 2018, 6:45 AM René Pickhardt via Lightning-dev <

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

2018-07-04 Thread Olaoluwa Osuntokun
> #1 lets us leave out double-funded channels. #2 and #3 lets us leave out > splice. > For myself, I would rather leave out AMP and double-funding and splicing > than remove ZKCP. It isn't one or the other. ZKCPs are compatible with various flavors of AMP. All of these technologies can be

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

2018-07-04 Thread Olaoluwa Osuntokun
veral tradeoffs, like everything else does. Also, everything we can do with Schnorr, we can also do with ECDSA, but today. -- Laolu On Wed, Jul 4, 2018 at 7:12 PM Rusty Russell wrote: > Olaoluwa Osuntokun writes: > > What's the nasty compromise? > > > > Let's also not under

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

2018-07-04 Thread Olaoluwa Osuntokun
What's the nasty compromise? Let's also not underestimate how big of an update switching to dlog based HTLCs will be. On Wed, Jul 4, 2018, 4:21 PM Rusty Russell wrote: > Christian Decker writes: > > > ZmnSCPxj via Lightning-dev > writes: > >> For myself, I think splice is less priority than

Re: [Lightning-dev] Rebalancing argument

2018-07-03 Thread Olaoluwa Osuntokun
Dmytro wrote: > Yet the question remains — are there obvious advantages of cycle > transactions over a smart fee/routing system? That's a good question, it may be the case that by modifying the fee structure to punish flows that unbalance channels further, then this can simplify the problem as

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

2018-06-25 Thread Olaoluwa Osuntokun
Hi René, Speaking at a high level, the main differ between modifying autopilot strategies (channel bootstrapping, and maintenance) vs something like splicing, is that the former is purely policy while the latter is actually a protocol modifications. With respect to difficulty, the first option

Re: [Lightning-dev] Scriptless Scripts with ECDSA

2018-05-07 Thread Olaoluwa Osuntokun
FWIW, Conner pointed out that the initial ZK Proof for the correctness of the Paillier params (even w/ usage of bulletproofs) has multiple rounds of interaction, iirc up to 5+ (with additional pipelining) rounds of interaction. -- Laolu On Mon, May 7, 2018 at 5:14 PM Olaoluwa Osuntokun <l

Re: [Lightning-dev] Scriptless Scripts with ECDSA

2018-05-07 Thread Olaoluwa Osuntokun
Hi Pedro, Very cool stuff! When I originally discovered the Lindell's technique, my immediate thought was the we could phase this in as a way to _immediately_ (no additional Script upgrades required), replace the regular 2-of-2 mulit-sig with a single p2wkh. The immediate advantages of this

Re: [Lightning-dev] Receiving via unpublished channels

2018-05-07 Thread Olaoluwa Osuntokun
AFAIK, all the other implementations already do this (lnd does at least [1]). As otherwise, it wouldn't be possible to properly utilize routing hints. > I want to ask the other LN implementations (lnd, eclair, ucoin, lit) As an side, what's "ucoin"? Searched for a bit and didn't find anything

Re: [Lightning-dev] Trustless WatchTowers?

2018-04-16 Thread Olaoluwa Osuntokun
Hi ZmnSCPxj, > It seems to me, that the only safe way to implement a trustless WatchTower, > is for the node to generate a fully-signed justice transaction, IMMEDIATELY > after every commitment transaction is revoked, and transmit it to the > WatchTower. No, one doesn't need to transmit the

Re: [Lightning-dev] Improving the initial gossip sync

2018-02-25 Thread Olaoluwa Osuntokun
date link policy state is for optimization/analysis, or to minimize payment latency at the cost of additional load. --Laolu On Fri, Feb 23, 2018 at 4:45 PM Olaoluwa Osuntokun <laol...@gmail.com> wrote: > Hi Rusty, > > > 1. query_short_channel_id > > IMPLEMENTATION

Re: [Lightning-dev] Improving the initial gossip sync

2018-02-23 Thread Olaoluwa Osuntokun
Hi Rusty, > 1. query_short_channel_id > IMPLEMENTATION: trivial *thumbs up* > 2. query_channel_range/reply_channel_range > IMPLEMENTATION: requires channel index by block number, zlib For the sake of expediency of deployment, if we add a byte (or two) to denote the encoding/compression scheme,

Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

2018-02-06 Thread Olaoluwa Osuntokun
Hi ZmnSCPxj, > This is excellent work! Thanks! > I think, a `globalfeatures` odd bit could be used for this. As it is > end-ot-end, `localfeatures` is not appropriate. Yep, it would need to be a global feature bit. In the case that we're sending to a destination which isn't publicly

Re: [Lightning-dev] lnd on bitcoind

2018-01-31 Thread Olaoluwa Osuntokun
Segwit has been merged into btcd for for sometime now. It's also possible to run with bitcoind. I encourage you to check out the documentation: https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md In lnd, the chain backend has already been abstracted[1]. This is what allows it to

Re: [Lightning-dev] General question on routing difficulties

2017-11-27 Thread Olaoluwa Osuntokun
Hi Pedro, I came across this paper a few weeks ago, skimmed it lightly, and noted a few interesting aspects I wanted to dig into later. Your email reminded me to re-read the paper, so thanks for that! Before reading the paper, I wasn't aware of the concept of coordinate embedding, nor how that

Re: [Lightning-dev] Minutes of Dev Meeting 2017-07-10

2017-08-07 Thread Olaoluwa Osuntokun
> I think it does already: Yep! An oversight on my part. > So, you're suggesting SIGHASH_SINGLE|SIGHASH_ANYONECANPAY? Precisely. The code modifications required to switch to this signing mode are trivial. > though it's a pretty obscure case where we want to close out many HTLCs at > once; this