Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

2021-10-04 Thread Luke Dashjr
On Monday 04 October 2021 16:14:20 Antoine Riard wrote:
> > The "dust limit" is arbitrarily decided by each node, and cannot be
> > relied upon for security at all. Expecting it to be a given default value
> > is in itself a security vulnerability
>
> Reality is that an increasing number of funds are secured by assumptions
> around mempool behavior.

In other words, simply not secured.

> And sadly that's going to increase with Lightning growth and deployment of
> other L2s.

L2s shouldn't build on flawed assumptions.

> Maybe we could dry-up some policy rules in consensus like the dust limit
> one :)

No thanks. Not sure that would even help (since policies can always be set to 
a higher dust limit than any consensus rule)
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

2021-10-04 Thread Luke Dashjr
On Monday 04 October 2021 15:09:28 Antoine Riard wrote:
> Still during August 2021, the Bitcoin Core dust limit was actively
> discussed on the mailing list. Changes of this dust limit would have
> affected the ongoing development of the mitigations.

The "dust limit" is arbitrarily decided by each node, and cannot be relied 
upon for security at all. Expecting it to be a given default value is in 
itself a security vulnerability.


P.S. It'd be nice if someone familiar with these could fill in 
https://en.bitcoin.it/wiki/CVEs
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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

2021-07-02 Thread Luke Dashjr
Yes, many systems doesn't really make sense. We can add editors and revise the 
BIP process as needed (BOLTs might prefer to use markdown?). Even aside from 
Lightning BIPs, there are several improvements that can be made, so it makes 
sense to address everything at once.

https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist

The BIP 2xx range has been set aside for Lightning years ago, and we can do 
similar things to help keep things organized within BIPs. Kalle suggested 
maybe it'd be better to do BIP "L###" instead, and perhaps that would work 
better if there's likely to be several sub-namespaces.

Luke


On Friday 02 July 2021 12:02:28 Dan Gershony wrote:
> Hi,
> There will be many layer 2 (and probably layer 3)  protocols (BOLT, RGB,
> Volts etc...) does it really make sense to merge them all into the BIPs
> system?
>
>
> On Fri, Jul 2, 2021 at 10:03 AM nathanael via Lightning-dev <
>
> lightning-dev@lists.linuxfoundation.org> wrote:
> > Michael Folkson  wrote:
> > > > Adding a third BIP editor more involved with Lightning sounds like a
> >
> > good idea.
> >
> > > Or alternatively if BOLTs were subsumed into BIPs I think Bastien
> > > would be a great additional BIP editor to cover Lightning related BIPs
> > >
> > > :) I think BOLTs being subsumed into BIPs would be nice but I'm
> > >
> > > pessimistic it will happen. Like legislation and regulation in the
> > > legacy financial system alphabet soups only expand they never get
> > > simplified. Let's at least resist alphabet soup expansion here.
> >
> > arent lightning improvements in the end bitcoin improvements too?
> > i am thinking of bips like the rfcs of the internet
> >
> > --
> > nathanael
> > ___
> > Lightning-dev mailing list
> > Lightning-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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

2021-07-01 Thread Luke Dashjr
BOLTs should be BIPs too. Ideally, the authors should be the ones to migrate 
them, but mirroring is fine - just nobody's taken the time to do it yet.

Please stop promoting lies about the BIP repo. I did not "steelman" anything.

Adding a third BIP editor more involved with Lightning sounds like a good 
idea.



On Thursday 01 July 2021 20:25:23 Olaoluwa Osuntokun wrote:
> > BIPs are already the Bazaar style of evolution that simultaneously
> > allows flexibility and coordination/interoperability (since anyone can
>
> create a
>
> > BIP and they create an environment of discussion).
>
> The answer to why not BIPs here applies to BOLTs as well, as bLIPs are
> intended to effectively be nested under the BOLT umbrella (same repo, etc).
> It's also the case that any document can be mirrored as a BIP, this has
> been suggested before, but the BIP editors have decided not to do so.
>
> bLIPs have a slightly different process than BIPs, as well as a different
> set
> of editors/maintainers (more widely distributed). As we saw with the Speedy
> Trial saga (fingers crossed), the sole (?) maintainer of the BIP process
> was able to effectively steelman the progression of an author document,
> with no sound technical objection (they had a competing proposal that
> could've been a distinct document). bLIPs sidestep shenanigans like this by
> having the primary maintainer/editors be more widely distributed and closer
> to the target domain (LN).
>
> The other thing bLIPs do is do away with the whole "human picks the number
> of documents", and "don't assign your own number, you must wait". Borrowing
> from EIPs, the number of a document is simply the number of the PR that
> proposes the document. This reduces friction, and eliminates a possible
> bikeshedding vector.
>
> -- Laolu
>
> On Wed, Jun 30, 2021 at 5:31 PM Ariel Luaces  wrote:
> > BIPs are already the Bazaar style of evolution that simultaneously
> > allows flexibility and coordination/interoperability (since anyone can
> > create a BIP and they create an environment of discussion).
> >
> > BOLTs are essentially one big BIP in the sense that they started as a
> > place for discussion but are now more rigid. BOLTs must be followed
> > strictly to ensure a node is interoperable with the network. And BOLTs
> > should be rigid, as rigid as any widely used BIP like 32 for example.
> > Even though BOLTs were flexible when being drafted their purpose has
> > changed from descriptive to prescriptive.
> > Any alternatives, or optional features should be extracted out of
> > BOLTs, written as BIPs. The BIP should then reference the BOLT and the
> > required flags set, messages sent, or alterations made to signal that
> > the BIP's feature is enabled.
> >
> > A BOLT may at some point organically change to reference a BIP. For
> > example if a BIP was drafted as an optional feature but then becomes
> > more widespread and then turns out to be crucial for the proper
> > operation of the network then a BOLT can be changed to just reference
> > the BIP as mandatory. There isn't anything wrong with this.
> >
> > All of the above would work exactly the same if there was a bLIP
> > repository 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
> > because many still perceive the BOLTs available for editing, so
> > changes continue to be made. If instead BOLTs were perceived as more
> > "consensus critical", not subject to change, and more people were
> > 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:
> > > > 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 trying to solve here is promoting more
> >
> > loosely
> >
> > > coupled evolution of the network. I think the BOLTs do a good job
> >
> > currently of
> >
> > > specifying what _base_ functionality is required for a routing node in
> > > a prescriptive manner (you must forward an HTLC like this, etc).
> > > However
> >
> > there's
> >
> > > a rather large gap in describing functionality that has emerged over
> >
> > time due
> >
> > > to progressive evolution, and aren't absolutely necessary, but enhance
> > > node/wallet operation.
> > >
> > > Examples of  include things like: path finding heuristics (BOLTs just
> >
> > say you
> >
> > > should get from Alice to Bob, but provides no 

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

2021-06-30 Thread Luke Dashjr
Or just use BIPs instead of further fracturing...?

On Jun 30, 2021 10:10 AM, Ryan Gentry via Lightning-dev 
 wrote:
>
> Hi all,
>
>
> The recent thread around zero-conf channels [1] provides an opportunity to 
> discuss how the BOLT process handles features and best practices that arise 
> in the wild vs. originating within the process itself. Zero-conf channels are 
> one of many LN innovations on the app layer that have struggled to make their 
> way into the spec. John Carvalho and Bitrefill launched Turbo channels in 
> April 2019 [2], Breez posted their solution to the mailing list for feedback 
> in August 2020 [3], and we know at least ACINQ and Muun (amongst others) have 
> their own implementations. In an ideal world there would be a descriptive 
> design document that the app layer implementers had collaborated on over the 
> years that the spec group could then pick up and merge into the BOLTs now 
> that the feature is deemed spec-worthy.
>
>
> Over the last couple of months, we have discussed the idea of adding a 
> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various 
> members of the community, and have received positive feedback from both app 
> layer and protocol devs. This would not affect the existing BOLT process at 
> all, but simply add a place for app layer best practices to be succinctly 
> described and organized, especially those that require coordination. These 
> features are being built outside of the BOLT process today anyways, so 
> ideally a bLIP process would bring them into the fold instead of leaving them 
> buried in old ML posts or not documented at all.
>
>
> Some potential bLIP ideas that people have mentioned include: each lnurl 
> variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment 
> metadata, p2p messaging formats, new pathfinding heuristics, remote node 
> connection standards, etc.
>
>
> If the community is interested in moving forward, we've started a branch [5] 
> describing such a process. It's based on BIP-0002, so not trying to reinvent 
> any wheels. It would be great to have developers from various implementations 
> and from the broader app layer ecosystem volunteer to be listed as editors 
> (basically the same role as in the BIPs). 
>
>
> Looking forward to hearing your thoughts!
>
>
> Best,
> Ryan
>
>
> [1] 
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>
> [2] 
> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>
> [3] 
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>
> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization 
> of Protocols at the Request of the Kommunity (h/t fiatjaf)
>
> [5] 
> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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

2020-05-05 Thread Luke Dashjr
On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> Trust-minimization of Bitcoin security model has always relied first and
> above on running a full-node. This current paradigm may be shifted by LN
> where fast, affordable, confidential, censorship-resistant payment services
> may attract a lot of adoption without users running a full-node.

No, it cannot be shifted. This would compromise Bitcoin itself, which for 
security depends on the assumption that a supermajority of the economy is 
verifying their incoming transactions using their own full node.

The past few years has seen severe regressions in this area, to the point 
where Bitcoin's future seems quite bleak. Without serious improvements to the 
full node ratio, Bitcoin is likely to fail.

Therefore, all efforts to improve the "full node-less" experience are harmful, 
and should be actively avoided. BIP 157 improves privacy of fn-less usage, 
while providing no real benefits to full node users (compared to more 
efficient protocols like Stratum/Electrum).

For this reason, myself and a few others oppose merging support for BIP 157 in 
Core.

> Assuming a user adoption path where a full-node is required to benefit for
> LN may deprive a lot of users, especially those who are already denied a
> real financial infrastructure access.

If Bitcoin can't do it, then Bitcoin can't do it.
Bitcoin can't solve *any* problem if it becomes insecure itself.

Luke

P.S. See also
https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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

2018-07-22 Thread Luke Dashjr
Lightning is covered by BIPs already. There's no need for a separate 
repository, and the existing BOLTs should be submitted to the BIPs repository 
too.

On Sunday 22 July 2018 13:45:21 René Pickhardt via Lightning-dev wrote:
> Hey everyone,
>
> in the grand tradition of BIPs I propose that we also start to have our own
> LIPs (Lightning Network Improvement proposals)
>
> I think they should be placed on the github.com/lightning account in a repo
> called lips (or within the lightning rfc repo) until that will happen I
> created a draft for LIP-0001 (which is describing the process and is 95%
> influenced by BIP-0002) in my github repo:
>
> https://github.com/renepickhardt/lips  (There are some open Todos and
> Questions in this LIP)
>
> The background for this Idea: I just came home from the bitcoin munich
> meetup where I held a talk examining BOLT. As I was asked to also talk
> about the future plans of the developers for BOLT 1.1 I realized while
> preparing the talk that many ideas are distributed within the community but
> it seems we don't have a central place where we collect future enhancements
> for BOLT1.1. Having this in mind I think also for the meeting in Australia
> it would be nice if already a list of LIPs would be in place so that the
> discussion can be more focused.
> potential LIPs could include:
> * Watchtowers
> * Autopilot
> * AMP
> * Splicing
> * Routing Protcols
> * Broadcasting past Routing statistics
> * eltoo
> * ...
>
> As said before I would volunteer to work on a LIP for Splicing (actually I
> already started)
>
> best Rene

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

2018-07-03 Thread Luke Dashjr
On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
> insecure for traditional applications where a third party might pay to
> an address a second time, and should only be used in special protocols
> which make that kind of mistake unlikely. 

I don't agree. Address reuse is undefined behaviour. Nobody should assume it 
is safe or works.

I intend to possibly use SIGHASH_NOINPUT for ordinary Bitcoin transactions in 
a wallet I am writing, which explicitly does not support address reuse.

Luke
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev