Olaoluwa Osuntokun [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-06 to 2023-01-11
💬 Posted a total of 200 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, BOLT Draft, RFC
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-10-18 13:02:09 UTC

- reply

📅 Original date posted:2023-10-16
🗒️ Summary of this message: The email acknowledges the recipient's efforts in reporting an issue and discusses the implementation of mitigations in the lnd software. It also mentions the discovery of a transaction-relay jamming attack affecting lightning channels and the deployment of mitigations by major lightning implementations. The email concludes by mentioning the need to determine the robustness of the deployed mitigations against advanced attackers.
📝 Original message:
Hi Antoine,
Thanks for this great write up, and also your diligence in reporting this
issue to the various implementations, and game planning with us re
mitigations and attack scenarios.
One small clarification: all of lnd's relevant mitigations were in place by
lnd v0.16.1-beta [1], which was released on April 24th 2023. Since then
we've fixed some performance regressions introduced due to some of the
mitigations (mempool watching), and in 0.17.1 we'll start to use the new
`gettxspendingprevout` RPC call with bitcoind to further reduce load.
[1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-beta
-- Laolu
On Mon, Oct 16, 2023 at 10:04 AM Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> (cross-posting mempool issues identified are exposing lightning chan to
> loss of funds risks, other multi-party bitcoin apps might be affected)
>
> Hi,
>
> End of last year (December 2022), amid technical discussions on eltoo
> payment channels and incentives compatibility of the mempool anti-DoS
> rules, a new transaction-relay jamming attack affecting lightning channels
> was discovered.
>
> After careful analysis, it turns out this attack is practical and
> immediately exposed lightning routing hops carrying HTLC traffic to loss of
> funds security risks, both legacy and anchor output channels. A potential
> exploitation plausibly happening even without network mempools congestion.
>
> Mitigations have been designed, implemented and deployed by all major
> lightning implementations during the last months.
>
> Please find attached the release numbers, where the mitigations should be
> present:
> - LDK: v0.0.118 - CVE-2023 -40231
> - Eclair: v0.9.0 - CVE-2023-40232
> - LND: v.0.17.0-beta - CVE-2023-40233
> - Core-Lightning: v.23.08.01 - CVE-2023-40234
>
> While neither replacement cycling attacks have been observed or reported
> in the wild since the last ~10 months or experimented in real-world
> conditions on bitcoin mainet, functional test is available exercising the
> affected lightning channel against bitcoin core mempool (26.0 release
> cycle).
>
> It is understood that a simple replacement cycling attack does not demand
> privileged capabilities from an attacker (e.g no low-hashrate power) and
> only access to basic bitcoin and lightning software. Yet I still think
> executing such an attack successfully requests a fair amount of bitcoin
> technical know-how and decent preparation.
>
> From my understanding of those issues, it is yet to be determined if the
> mitigations deployed are robust enough in face of advanced replacement
> cycling attackers, especially ones able to combine different classes of
> transaction-relay jamming such as pinnings or vetted with more privileged
> capabilities.
>
> Please find a list of potential affected bitcoin applications in this full
> disclosure report using bitcoin script timelocks or multi-party
> transactions, albeit no immediate security risk exposure as severe as the
> ones affecting lightning has been identified. Only cursory review of
> non-lightning applications has been conducted so far.
>
> There is a paper published summarizing replacement cycling attacks on the
> lightning network:
>
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
>
> ## Problem
>
> A lightning node allows HTLCs forwarding (in bolt3's parlance accepted
> HTLC on incoming link and offered HTLC on outgoing link) should settle the
> outgoing state with either a success or timeout before the incoming state
> timelock becomes final and an asymmetric defavorable settlement might
> happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network"
> section 2.3 for a classical exposition of this lightning security property).
>
> Failure to satisfy this settlement requirement exposes a forwarding hop to
> a loss of fund risk where the offered HTLC is spent by the outgoing link
> counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming
> link counterparty's HTLC-timeout.
>
> The specification mandates the incoming HTLC expiration timelock to be
> spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC
> expiration timelock, this exact interval value being an implementation and
> node policy setting. As a minimal value, the specification recommends 34
> blocks of interval. If the timelock expiration I of the inbound HTLC is
> equal to 100 from chain tip, the timelock expiration O of the outbound HTLC
> must be equal to 66 blocks from chain tip, giving a reasonable buffer of
> reaction to the lightning forwarding node.
>
> In the lack of cooperative off-chain settlement of the HTLC on the
> outgoing link negotiated with the counterparty (either
> `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, the
> lightning node should broadcast its commitment transaction. Once the
> commitment is confirmed (if anchor and the 1 CSV encumbrance is present),
> the lightning node broadcasts and confirms its HTLC-timeout before I height
> is reached.
>
> Here enter a replacement cycling attack. A malicious channel counterparty
> can broadcast its HTLC-preimage transaction with a higher absolute fee and
> higher feerate than the honest HTLC-timeout of the victim lightning node
> and triggers a replacement. Both for legacy and anchor output channels, a
> HTLC-preimage on a counterparty commitment transaction is malleable, i.e
> additional inputs or outputs can be added. The HTLC-preimage spends an
> unconfirmed and unrelated to the channel parent transaction M and conflicts
> its child.
>
> As the HTLC-preimage spends an unconfirmed input that was already included
> in the unconfirmed and unrelated child transaction (rule 2), pays an
> absolute higher fee of at least the sum paid by the HTLC-timeout and child
> transaction (rule 3) and the HTLC-preimage feerate is greater than all
> directly conflicting transactions (rule 6), the replacement is accepted.
> The honest HTLC-timeout is evicted out of the mempool.
>
> In an ulterior move, the malicious counterparty can replace the parent
> transaction itself with another candidate N satisfying the replacement
> rules, triggering the eviction of the malicious HTLC-preimage from the
> mempool as it was a child of the parent T.
>
> There is no spending candidate of the offered HTLC output for the current
> block laying in network mempools.
>
> This replacement cycling tricks can be repeated for each rebroadcast
> attempt of the HTLC-timeout by the honest lightning node until expiration
> of the inbound HTLC timelock I. Once this height is reached a HTLC-timeout
> is broadcast by the counterparty's on the incoming link in collusion with
> the one on the outgoing link broadcasting its own HTLC-preimage.
>
> The honest Lightning node has been "double-spent" in its HTLC forwarding.
>
> As a notable factor impacting the success of the attack, a lightning
> node's honest HTLC-timeout might be included in the block template of the
> miner winning the block race and therefore realizes a spent of the offered
> output. In practice, a replacement cycling attack might over-connect to
> miners' mempools and public reachable nodes to succeed in a fast eviction
> of the HTLC-timeout by its HTLC-preimage. As this latter transaction can
> come with a better ancestor-score, it should be picked up on the flight by
> economically competitive miners.
>
> A functional test exercising a simple replacement cycling of a HTLC
> transaction on bitcoin core mempool is available:
> https://github.com/ariard/bitcoin/commits/2023-test-mempool
>
> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits
> from the HTLC-timeout being usually broadcast by lightning nodes only once
> every block, or less the replacement cycling malicious transactions paid
> only equal the sum of the absolute fees paid by the HTLC, adjusted with the
> replacement penalty. Rebroadcasting randomly and multiple times before the
> next block increases the absolute fee cost for the attacker.
>
> Implemented and deployed by Eclair, Core-Lightning, LND and LDK .
>
> Local-mempool preimage monitoring: As the replacement cycling attacker in
> a simple setup broadcast the HTLC-preimage to all the network mempools, the
> honest lightning node is able to catch on the flight the unconfirmed
> HTLC-preimage, before its subsequent mempool replacement. The preimage can
> be extracted from the second-stage HTLC-preimage and used to fetch the
> off-chain inbound HTLC with a cooperative message or go on-chain with it to
> claim the accepted HTLC output.
>
> Implemented and deployed by Eclair and LND.
>
> CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid
> by the attacker, a risk of the HTLC-preimage being detected or discovered
> by the honest lightning node, or the HTLC-timeout to slip in a winning
> block template. Bumping the default CLTV delta hardens the odds of success
> of a simple replacement cycling attack.
>
> Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.
>
> ## Affected Bitcoin Protocols and Applications
>
> From my understanding the following list of Bitcoin protocols and
> applications could be affected by new denial-of-service vectors under some
> level of network mempools congestion. Neither tests or advanced review of
> specifications (when available) has been conducted for each of them:
> - on-chain DLCs
> - coinjoins
> - payjoins
> - wallets with time-sensitive paths
> - peerswap and submarine swaps
> - batch payouts
> - transaction "accelerators"
>
> Inviting their developers, maintainers and operators to investigate how
> replacement cycling attacks might disrupt their in-mempool chain of
> transactions, or fee-bumping flows at the shortest delay. Simple flows and
> non-multi-party transactions should not be affected to the best of my
> understanding.
>
> ## Open Problems: Package Malleability
>
> Pinning attacks have been known for years as a practical vector to
> compromise lightning channels funds safety, under different scenarios (cf.
> current bip331's motivation section). Mitigations at the mempool level have
> been designed, discussed and are under implementation by the community
> (ancestor package relay + nverrsion=3 policy). Ideally, they should
> constraint a pinning attacker to always attach a high feerate package
> (commitment + CPFP) to replace the honest package, or allow a honest
> lightning node to overbid a malicious pinning package and get its
> time-sensitive transaction optimistically included in the chain.
>
> Replacement cycling attack seem to offer a new way to neutralize the
> design goals of package relay and its companion nversion=3 policy, where an
> attacker package RBF a honest package out of the mempool to subsequently
> double-spend its own high-fee child with a transaction unrelated to the
> channel. As the remaining commitment transaction is pre-signed with a
> minimal relay fee, it can be evicted out of the mempool.
>
> A functional test exercising a simple replacement cycling of a lightning
> channel commitment transaction on top of the nversion=3 code branch is
> available:
> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
>
> ## Discovery
>
> In 2018, the issue of static fees for pre-signed lightning transactions is
> made more widely known, the carve-out exemption in mempool rules to
> mitigate in-mempool package limits pinning and the anchor output pattern
> are proposed.
>
> In 2019, bitcoin core 0.19 is released with carve-out support. Continued
> discussion of the anchor output pattern as a dynamic fee-bumping method.
>
> In 2020, draft of anchor output submitted to the bolts. Initial finding of
> economic pinning against lightning commitment and second-stage HTLC
> transactions. Subsequent discussions of a preimage-overlay network or
> package-relay as mitigations. Public call made to inquiry more on potential
> other transaction-relay jamming attacks affecting lightning.
>
> In 2021, initial work in bitcoin core 22.0 of package acceptance.
> Continued discussion of the pinning attacks and shortcomings of current
> mempool rules during community-wide online workshops. Later the year, in
> light of all issues for bitcoin second-layers, a proposal is made about
> killing the mempool.
>
> In 2022, bip proposed for package relay and new proposed v3 policy design
> proposed for a review and implementation. Mempoolfullrbf is supported in
> bitcoin core 24.0 and conceptual questions about alignment of mempool rules
> w.r.t miners incentives are investigated.
>
> Along this year 2022, eltoo lightning channels design are discussed,
> implemented and reviewed. In this context and after discussions on mempool
> anti-DoS rules, I discovered this new replacement cycling attack was
> affecting deployed lightning channels and immediately reported the finding
> to some bitcoin core developers and lightning maintainers.
>
> ## Timeline
>
> - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg
> Sanders and Gloria Zhao
> - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier,
> Matt Corallo and Olaoluwa Osuntunkun
> - 2022-12-23: Sharing to Eugene Siegel (LND)
> - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightning
> potential affected projects)
> - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layers
> issuers) and initial proposal of an early public disclosure
> - 2022-01-19: Collection of analysis if other second-layers and
> multi-party applications affected. LN mitigations development starts.
> - 2023-05-04: Sharing to Wilmer Paulino (LDK)
> - 2023-06-20: LN mitigations implemented and progressively released. Week
> of the 16 october proposed for full disclosure.
> - 2023-08-10: CVEs assigned by MITRE
> - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling
> attack existence to security at bitcoincore.org.
> - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 /
> CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks
>
> ## Conclusion
>
> Despite the line of mitigations adopted and deployed by current major
> lightning implementations, I believe replacement cycling attacks are still
> practical for advanced attackers. Beyond this new attack might come as a
> way to partially or completely defeat some of the pinning mitigations which
> have been working for years as a community.
>
> As of today, it is uncertain to me if lightning is not affected by a more
> severe long-term package malleability critical security issue under current
> consensus rules, and if any other time-sensitive multi-party protocol,
> designed or deployed isn't de facto affected too (loss of funds or denial
> of service).
>
> Assuming analysis on package malleability is correct, it is unclear to me
> if it can be corrected by changes in replacement / eviction rules or
> mempool chain of transactions processing strategy. Inviting my technical
> peers and the bitcoin community to look more on this issue, including to
> dissent. I'll be the first one pleased if I'm fundamentally wrong on those
> issues, or if any element has not been weighted with the adequate technical
> accuracy it deserves.
>
> Do not trust, verify. All mistakes and opinions are my own.
>
> Antoine
>
> "meet with Triumph and Disaster. And treat those two impostors just the
> same" - K.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231016/cef364c3/attachment-0001.html>

2023-06-09 13:06:20 UTC

- reply

📅 Original date posted:2022-06-27
📝 Original message:
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 in process,
"enough" time to propagate through the network. If a node can see this
message before/during the splicing operation, then they'll be able relate
the old and the new channels, meaning it's usable again by senders/receiver
_before_ the entire chain of transactions confirms on chain.
IMO, this sort of arbitrary delay (expressed in blocks) won't actually
address the issue in practice. The proposal suffers from the following
issues:
1. 12 blocks is chosen arbitrarily. If for w/e reason an announcement
takes longer than 2 hours to reach the "economic majority" of
senders/receivers, then the channel won't be able to mask the splicing
downtime.
2. Gossip propagation delay and offline peers. These days most nodes
throttle gossip pretty aggressively. As a result, a pair of nodes doing
several in-flight splices (inputs become double spent or something, so
they need to try a bunch) might end up being rate limited within the
network, causing the splice update msg to be lost or delayed significantly
(IIRC CLN resets these values after 24 hours). On top of that, if a peer
is offline for too long (think mobile senders), then they may miss the
update all together as most nodes don't do a full historical
_channel_update_ dump anymore.
In order to resolve these issues, I think instead we need to rely on the
primary splicing signal being sourced from the chain itself. In other words,
if I see a channel close, and a closing transaction "looks" a certain way,
then I know it's a splice. This would be used in concert w/ any new gossip
messages, as the chain signal is a 100% foolproof way of letting an aware
peer know that a splice is actually happening (not a normal close). A chain
signal doesn't suffer from any of the gossip/time related issues above, as
the signal is revealed at the same time a peer learns of a channel
close/splice.
Assuming, we agree that a chain signal has some sort of role in the ultimate
plans for splicing, we'd need to decide on exactly _what_ such a signal
looks like. Off the top, a few options are:
1. Stuff something in the annex. Works in theory, but not in practice, as
bitcoind (being the dominant full node implementation on the p2p network,
as well as what all the miners use) treats annexes as non-standard. Also
the annex itself might have some fundamental issues that get in the way of
its use all together [2].
2. Re-use the anchors for this purpose. Anchor are nice as they allow for
1st/2nd/3rd party CPFP. As a splice might have several inputs and outputs,
both sides will want to make sure it gets confirmed in a timely manner.
Ofc, RBF can be used here, but that requires both sides to be online to
make adjustments. Pre-signing can work too, but the effectiveness
(minimizing chain cost while expediting confirmation) would be dependent
on the fee step size.
In this case, we'd use a different multi-sig output (both sides can rotate
keys if they want to), and then roll the anchors into this splicing
transaction. Given that all nodes on the network know what the anchor size
is (assuming feature bit understanding), they're able to realize that it's
actually a splice, and they don't need to remove it from the channel graph
(yet).
3. Related to the above: just re-use the same multi-sig output. If nodes
don't care all that much about rotating these keys, then they can just use
the same output. This is trivially recognizable by nodes, as they already
know the funding keys used, as they're in the channel_announcement.
4. OP_RETURN (yeh, I had to list it). Self explanatory, push some bytes in
an OP_RETURN and use that as the marker.
5. Fiddle w/ the locktime+sequence somehow to make it identifiable to
verifiers. This might run into some unintended interactions if the inputs
provided have either relative or absolute lock times. There might also be
some interaction w/ the main constructing for eltoo (uses the locktime).
Of all the options, I think #2 makes the most sense: we already use anchors
to be able to do fee bumping after-the-fact for closing transactions, so why
not inherit them here. They make the splicing transaction slightly larger,
so maybe #3 (or something else) is a better choice.
The design space for spicing is preeetty large, so I figure the most
productive route might be discussing isolated aspects of it at a time.
Personally, I'm not suuuper caught up w/ what the latest design drafts are
(aside from convos at the recent LN Dev Summit), but from my PoV, how to
communicate the splice to other peers has been an outstanding design
question.
[1]: https://github.com/lightning/bolts/pull/1004
[2]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020045.html
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220627/1544d48a/attachment.html>

2023-06-09 12:57:11 UTC

- reply

📅 Original date posted:2019-11-05
📝 Original message:
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,
> it's time to float actual proposals.
IMO both should just be done over HORNET, so we don't need introduce a new
set of internal protocol level messages whenever we have some new
control/signalling need. Instead, we'd have a control/signal channel (give
me
routes, invoices, sign this, etc), and a payment channel (HTLCs as used
today).
> 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed
> (new field), and a hash.
The prepay amount should be signalled in the update add message instead.
This lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we
need a new onion field as well to signal the incoming amount the node
_should_ have received (allows them to detect deviations in the sender's
intended route).
> 3. Failing/succeeding an HTLC returns some of those msat, and a count and
> preimage (new fields).
Failing shouldn't return the prepay amount, otherwise extending long lived
HTLCs then cancelling them at the last minute is still costless. This
costlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the
biggest incentive flaw that exists today in the greater routing network.
> You get to keep 50 msat[1] per preimage you present[2].
We should avoid introducing any new constants to the protocol, as they're
typically dreamed up independent of any empirical lessons learned from
deployment.
On the topic of the prepay cost, the channel update message should be
extended to allow nodes to signal prepay costs similar to the way we handle
regular payment success fees. In order to eliminate a number of costless
attacks possible today on the routing network, nodes should also be able to
signal a new coefficient used to _scale_ the prepay fee as a function of the
CLTV value of the incoming HTLC. With this addition, senders need to pay to
_add_ an HTLC to a remote commitment transaction (fixed base cost), then
also need to pay a variable rate that scales with the duration of the
proposed outgoing CLTV value (senders ofc don't prepay to themselves). Once
we introduce this, loop attacks and the like are no longer free to launch,
and nodes can dynamically respond to congestion in the network by raising
their prepay prices.
-- Laolu
On Mon, Nov 4, 2019 at 6:25 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> It's been widely known that we're going to have to have up-front
> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
> spam).
>
> Since both Offers and Joost's WhatSat are looking at sending
> messages, it's time to float actual proposals. I've been trying to come
> up with something for several years now, so thought I'd present the best
> I've got in the hope that others can improve on it.
>
> 1. New feature bit, extended messages, etc.
> 2. Adding an HTLC causes a *push* of a number of msat on
> commitment_signed (new field), and a hash.
> 3. Failing/succeeding an HTLC returns some of those msat, and a count
> and preimage (new fields).
>
> How many msat can you take for forwarding? That depends on you
> presenting a series of preimages (which chain into a final hash given in
> the HTLC add), which you get by decoding the onion. You get to keep 50
> msat[1] per preimage you present[2].
>
> So, how many preimages does the user have to give to have you forward
> the payment? That depends. The base rate is 16 preimages, but subtract
> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
> onion. The blockhash is the hash of the block specified in the onion:
> reject if it's not in the last 3 blocks[3].
>
> This simply adds some payment noise, while allowing a hashcash style
> tradeoff of sats for work.
>
> The final node gets some variable number of preimages, which adds noise.
> It should take all and subtract from the minimum required invoice amount
> on success, or take some random number on failure.
>
> This leaks some forward information, and makes an explicit tradeoff for
> the sender between amount spent and privacy, but it's the best I've been
> able to come up with.
>
> Thoughts?
> Rusty.
>
> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
> 655msat per message. Flat pricing for simplicity; we're trying to
> prevent spam, not create a spam market.
> [2] Actually, a number and a single preimage; you can check this is
> indeed the n'th preimage.
> [3] This reduces incentive to grind the damn things in advance, though
> maybe that's dumb? We can also use a shorter hash (siphash?), or
> even truncated SHA256 (128 bits).
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191105/b461390a/attachment-0001.html>

2023-06-09 12:51:11 UTC

- reply

📅 Original date posted:2018-07-22
📝 Original message:
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 <
lightning-dev at lists.linuxfoundation.org> 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
>
>
> --
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180722/3c9c305d/attachment.html>