lisa neigut [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-10-17 to 2022-09-23
💬 Posted a total of 38 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, c-lightning, Web 8-init
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2

Profile Code

nprofile1qqsgq3msadvdzc7k8u8ejm7kh6atuxuvtq49m42yeasmhg9u2v6hyzspzfmhxue69uhk7enxvd5xz6tw9ec82csxdm5eq

Publishing to

offchain.pub

Author Public Key

npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2

Show more details

Last Notes

2023-06-09 13:06:56 GMT

- reply

📅 Original date posted:2022-09-23
📝 Original message:
Hi all,
We'd like to announce the 0.12.1 release[1] of core-lightning, named by
@adi2011.
This is a point release with a few bug fixes and build improvements: it's a
recommended upgrade from 0.12.0, with no new features.
For a list of differences, please see [v0.12.0..v0.12.1](
https://github.com/ElementsProject/lightning/compare/v0.12.0...v0.12.1).
## Highlights for Users
- Now with fewer bugs!
- Topology plugin could crash when it sees duplicate private channel
announcements.
- `getinfo` no longer displays unannounced addresses; shows correct port
for discovered IP addresses.
- Newly created channels sometimes were inexplicably disconnected, this has
been fixed!
## Highlights for the Network
- Bad gossip store reads and gossip propagation fixed.
## Highlights for Developers
- Reliance on `mako` and `mrkd` python libraries has been removed.
Since v0.12.0 we've had 26 commits from 5 different contributors over 29
days.
~ @niftynei, Christian, and Rusty
[1] https://github.com/ElementsProject/lightning/releases/tag/v0.12.1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220923/6eb274b4/attachment.html>

2023-06-09 13:06:49 GMT

- reply

📅 Original date posted:2022-09-23
📝 Original message:
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.
I don't think it's realistic to think that payments are going to stop
failing in
an environment where we continue to prioritize privacy of channel balances.
I think I pretty nicely illustrated the benefits of using payment bands in
my original
post wrt to a balance between "probe-ability" and some obfuscation of
balance, along
with a net reduction in the bandwidth consumption required to get this
basically
required information for payment success.
Rene Pickhardt has a less private, less costly, more granular, smaller scope
proposal for sharing channel balances w/ directly connected peers; I think
this is worth investigating independently of this proposal.
> depend on the centralized entities performing the data collection
I like to think that the introduction of negative fees make channel
balance data a competitive advantage and will actually cause node
operators to more closely guard their balances / the balance data
they've collected about peers, which should hopefully reduce the current
trend of sharing this information with centralized parties.
Note that with the present protocol design, the network incentives are such
that centralized efforts to collect exact balance data already exist. So
moving to this design has the potential to reduce the incentive to
participate
in the data collection, at the very least it does not make it worse than
current.
> this costs Alice nothing extra but reduces network capacity by consuming
> HTLC slots for her, Bob, and every other forwarding channel.
the network already limits the size of htlcs that are allowable with the
htlc_maximum_msat, which I understand is typically set at a rate below 1/4
of channel capacity (citation needed). Which is to say that the large
consumption of a channel in a single HTLC is currently relatively
prohibited.
It's likely this proposed change would actually encourage operators to set
their htlc_maximum_msat higher, now that there's a direct financial cost
tied to larger channel bandwidth consumption.
Great questions! Hope that gives a better picture of the current landscape.
Also h/t to ZmnSCPxj for the excellent "four parallel channels" analogy,
this is
a really elegant way to think about the proposal.
On Thu, Sep 22, 2022 at 11:39 PM David A. Harding <dave at dtrt.org> wrote:
> On 2022-09-22 16:08, ZmnSCPxj wrote:
> > Basically, you can model a rate card as four separate channels between
> > the same two nodes, with different costs each.
> > If the path at the lowest cost fails, you just try at another route
> > that may have more hops but lower effective cost, or else try the same
> > channel at a higher cost.
>
> That's a very easy to understand explanation of how to use the system,
> thanks!
>
> > If your concern is valid, one wonders why it would not already exist
> > now in the current network where try-and-try-again is the standard
> > overall algorithm for payments.
>
> My concern is about pathfinding algorithms which depend on unscalable
> data collection (e.g. frequent whole network probing). If such an
> algorithm performs much better than those algorithms which depend on
> scalable data collection (e.g. receiving gossip), then the network may
> grow to depend on the centralized entities performing the data
> collection to the detriment of its robustness and its participants'
> independence.
>
> Try-and-try-another-path is somewhat problematic in this regard since,
> even with no additional action like probing, entities which send many
> payments will likely perform significantly better than entities which
> send few payments owing to the high-frequency spenders gaining more
> knowledge about which channels and amounts recently worked or did not.
> It seems to me that a more idealized system would only rarely have
> forwarding failures so that high frequency spenders wouldn't receive
> much more information than low frequency spenders. To that regard, fee
> ratecards feels like a small step in the wrong direction because
> modeling one channel as four separate channels further normalizes
> failure and so further moves the system towards centralized dependency.
> That said, as you mentioned in a previous post[1], I agree ratecards is
> better than frequently issuing new channel updates with modified fees.
>
> Thanks,
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220923/07d0d25b/attachment.html>

2023-06-09 13:06:47 GMT

- reply

📅 Original date posted:2022-09-13
📝 Original message:
Hi all,
I've been talking about them for a bit[^1], now[^2], but here's a more
formal proposal for fee ratecards.
Spec PR + implementation to come.
## What is a fee ratecard?
A ratecard is a set of four values, positive or negative, that price different
bands of available liquidity for a channel.
A ratecard replaces the current `fee_proportional_millionths` and
`fee_base_msat` currently used to calculate the owed fees for
forwarding a payment on the
lightning network.
Instead, with ratecards, a channel operator may specify four different
rates for a channel's liquidity, that will automatically be updated
depending on the current channel capacity. The four capacity bands are fixed
at 0-25%, 26-50%, 51-75%, and 76-100%.
Currently, all payments are priced equally. Fee ratecards update this such that
payments can be priced differently, depending on the current available
capacity in a channel. This allows node operators to dynamically price
their liquidity, without needing to continually issue gossip updates as
the balance changes (which may leak payment flow timing).
## Spec Changes + Implementation Notes
To the `channel_update` gossip message, we add a TLV with one defined
type, `ratecard`. The ratecard contains 4 16-bit signed integers, one
for each quarter of channel capacity. (0-25, 26-50, 51-75, 76-100%).
```
1. `tlv_stream`: `channel_update_tlvs`
2. types:
1. type: 1 (`ratecard`)
2. data:
* [`s16`:`fee_basis_0_25`]
* [`s16`:`fee_basis_26_50`]
* [`s16`:`fee_basis_51_75`]
* [`s16`:`fee_basis_76_100`]
```
If a node is advertising a `ratecard` in their `channel_update` for
that channel, a routing node SHOULD pick the rate to pay based on
their current guess of the channel's capacity as well as priority for
the payment.
If a payment is high priority, it is recommended to pay at the highest feeband,
to ensure delivery (if possible).
On payment failure, the response is the same (you return a copy of the
`channel_update` in the onion). You MAY give an additional hint as to
what the current
acceptable feerate is for a payment.
If the feerate card entry is set, the rates there take precedence over the
`fee_base_msat` and the `fee_proportional_millionths`.
The `feerate` card effectively removes the ability to set a `fee_base_msat`.
To minimize payment routing failure, it is recommended to set the
`fee_proportional_millionths` to the same rate as the highest `ratecard`
rate. (Most likely the `ratecard`.`fee_basis_0_25`).
Note that `ratecards` unit is in basis points, not millionths. As basis points
are 1/10,000, they're 100x less than the same value expressed as millionths.
- A `basis_point` value of 5 is a fee of 5msat on a 10k msat payment.
- A `fee_proportional_millionths` of 500 is a fee of 5msat on a 10k
msat payment.
The current expected price for sats to be pushed to the other side of the
channel is to be priced by the lowest ratecard capacity band that that payment
will push the balance into.
For example, if a payment moves 50k through a 100k channel which is currently
at a total available capacity of 75k sats (which means it'll move the capacity
from 75k to 25k), that payment will be expected to pay a rate equal to the
0-25% band, as it'll push the available capacity into the 0-25% range.
Using this rule, HTLCs consuming significant portions of a channel's
total capacity are more likely to pay higher fees.
### Motivation and Rationale
At the last in-person spec meeting, it was noted that channel capacity is
often of variable value depending on the amount of capacity currently
available in that channel.
It was also noted that we'd like to allow node operators to experiment
with negative fees.
You can't easily allow for negative feerates with our current gossip messages,
as it would give gossip an economic value which may have an adverse impact
on the ability of nodes to stay up to date with the current lightning channel
topology; it also stands to greatly increase the volume of gossip
updates issued by any one node, which should scale with payment volume,
as nodes update their gossip to change their current fees on any one channel.
Note that some nodes already automatically update their channel fees based on
the available capacity in a channel; fee ratecards should be a more succinct
way for node operators to express more fine grained prices of their existing
capacity, with a much reduced bandwidth burden.
### Feerate Cards, Frequently Asked Questions
#### Why four evenly spaced buckets? Why not X function?
1. Expressibility
Fees are calculated by the node creating the route for a payment, using
parameters set by the channel node operator. These paramters must be
communicated via gossip to every node, and then used as inputs to the
routing function.
Parameters need to be uniform and well understood such that
routing algorithm designers can make efficient use of them.
Four buckets is wide enough such that payment should
be able to find/pick a current channel capacity with good
probability, yet hopefully expressive enough for routing
operators to be able to price their available liquidity
with sufficient granularity.
Four evenly spaced buckets also make it much easier to
reason about information leakage (binary search).
2. Predictability for payment success.
Feerate cards don't introduce any new risk to payment failure,
as the current fee rates of a channel may currently differ
from a node's gossip information.
Rather, feerate cards offer a way for your routing algorithm
to dynamically decide on what level of capacity it estimates
the channel to be at, and its tolerance for failures.
#### Won't this leak my channel balance?
At most, feerate buckets reduce the total number of payment attempts
required to find an exact channel balance by 2.
It does, however, provide a much lower 'cost of capital' mechanism
for discovering which band of payment is likely to succeed.
Currently, to discover if a 100k channel has capacity for a 75k sat payment,
you'd need 75k sats of available liquidity in the node leading up to
that channel (or 25k in the opposite direction) from your probe node, in
order to discover if that bucket is available.
This ties up available liquidity along the entire probe route.
With feerate cards, you could do a 1k sat payment at each feerate card
fee band, and discover the approximate bucket without tying up
as much of your own own outband capital.
This makes probing more feasible for any node that wants to make a payment,
while reducing the capital tied up to discern the same amount of information.
#### More data in the channel_update message! Just what we need, more gossip.
It's anticipated that feerate cards will greatly reduce the number of
`channel_update`s issued by a node, by allowing node operators to dynamically
price their liquidity by available capacity via a single, static
`channel_update`.
This should reduce or remove the need to rebroadcast a `channel_update` when a
channel's capacity changes.
#### How do negative fees work?
Astute readers may notice that the proposed feerate card bands can be expressed
as negative numbers. This allows node operators to price the liquidity
available in their channel at a discount.
Here's a good way to think about the impact a negative fee will
have on your channel balances.
A feerate of 5 basis points means that, in order to push 10k sats from
one of your channel balances to the peer, another of yours must push
you 10,005 sats. This means you always need more inbound than outbound
in order to route a payment (unless you're using zero fees, in which case
you'd need an equal amount).
Negative fees reverse this. At -5 basis points, you'd only need to receive 9,995
on an inbound channel to cause you to push out 10k sats. This allows you
to reallocate your inbound capacity at a slight discount to the party
who's responsible for moving the capital.
#### What happened to payment base fees?
They're going away (they do not work with negative rates).
Hopefully ratecards will give you enough expressivity to figure out
good rates for your channel capacity without them.
### Credits
This proposal is a marriage of Clara Shikleman's push to start thinking
about negative fees, and ZmnSCPxj's comments on the variability of
value of a channel's liquidity based on current capacity.
~niftynei
[^1]: [Slides on liquidity +
lightning](https://docs.google.com/presentation/d/1gK5_JvDl6aR8EqEKIxfdIHMR2vNIgHUS5tydP2kB_gA/edit?usp=sharing)
[^2]: [Presentation of slides at btcpp in
Austin](https://www.youtube.com/watch?v=voEbAeS_B5w)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220913/4d5cd38e/attachment.html>

2023-06-09 13:06:22 GMT

- reply

📅 Original date posted:2022-06-29
📝 Original message:
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.
I'm admittedly a bit confused as to why onchain signals are even being
seriously
proposed. Aside from "infallibility", is there another reason for
suggesting
we add an onchain detectable signal for this? Seems heavy handed imo, given
that the severity of a comms failure is pretty minimal (*potential* for
lost routing fees).
> So it appears you don't agree that the "wait N blocks before you close
your
channels" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144?
fwiw I seem to remember seeing that it takes ~an hour for gossip to
propagate
(no link sorry). Given that, 2x an hour or 12 blocks is a reasonable first
estimate.
I trust we'll have time to tune this after we've had some real-world
experience with them.
Further, we can always add more robust signaling later, if lost routing
fees turns
out to be a huge issue.
Finally, worth noting that Alex Myer's minisketch project may well
help/improve gossip
reconciliation efficiency to the point where gossip reliability is less
of an issue.
~nifty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220629/5a104870/attachment.html>

2023-06-09 13:04:20 GMT

- reply

📅 Original date posted:2021-10-19
📝 Original message:
FYI c-lightning now has a discord server for general questions, dev-chats,
and community support.
You can join it here: https://discord.gg/WW56GGHavu
We're also still on Telegram at https://t.me/lightningd and IRC at
#c-lightning on the libera.chat node.
~nifty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211019/5ff75c67/attachment.html>

2023-06-09 13:03:59 GMT

- reply

📅 Original date posted:2021-10-04
📝 Original message:
FYI the next version of c-lightning will contain the proposed
`max_dust_htlc_exposure_msat` as outlined in #919
<https://github.com/lightningnetwork/lightning-rfc/pull/919/files>; the
given expected vulnerabilities patch table should have reflected this.
> The vulnerabilities are expected to be patched in:
> * Eclair: v0.6.2+ (CVE-2021-41591)
> * LND: v0.13.3+ (CVE-2021-41592)
> * LDK: v0.0.102 (not released as production software yet)
* C-lightning v0.10.2 (CVE-2021-41593)
Lisa
On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi,
>
> I'm writing a report to disclose specification-level vulnerabilities
> affecting the Lightning implementations.
>
> The vulnerabilities are expected to be patched in:
> * Eclair: v0.6.2+ (CVE-2021-41591)
> * LND: v0.13.3+ (CVE-2021-41592)
> * LDK: v0.0.102 (not released as production software yet)
>
> The vulnerabilities are also affecting c-lightning (CVE-2021-41593).
>
> Those vulnerabilities can be exploited in a wide range of attacks, going
> from fee blackmailing of node operators, burning liquidity of your
> competing LSPs or even stealing your counterparty channel balance if you
> avail mining capabilities. Exercise of the vulnerability revealed that a
> majority of the balance funds can be at loss.
>
> Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
> exploitation and multiple insights about attacks.
>
> Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
> about mitigations development.
>
> # Problem
>
> The current BOLT specification only requires Alice's `dust_limit_satoshis`
> (applied on Alice's commitment) to be under Alice's
> `channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
> selectable by Alice, she can inflate the dust limit until reaching the
> implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
> of chan capacity).
>
> Any in-flight incoming HTLC under Alice's dust limit will be converted as
> miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
> and as such they're still owned by Bob, until resolution (i.e a RAA
> removing the HTLC from Alice's commitment). This limitation only applies
> per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
> burned as fees. Therefore, Alice is free to inflict a substantial loss to
> Bob funds by publishing her commitment on-chain.
>
> In-flight outgoing HTLC are also committed as fees on Bob's commitment if
> they're under Bob's threshold. Alice can also exploit from this angle by
> circular routing HTLCs until reaching Bob's
> `max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
> goes on-chain to timeout an offered HTLC or claim an accepted HTLC.
>
> Dust HTLC processing can be also exploited at `update_fee` reception.
>
> As the BOLT3's fees computation encompasses the negotiated feerate from
> `update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
> trimmed, the amount of balance at risk is a function of current mempool
> feerates.
>
> The maximum of funds at risk on a counterparty commitment is:
>
> counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
> `feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
> `max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
> counterparty's `dust_limit_satoshis`)
>
> If the opener is also the attacker, the negotiated feerate can be
> manipulated beyond the "honest" mempool feerates only upper bounded
> implementation-defined value (before fixes, LDK: 2 * high-feerate of our
> fee-estimator). If the opener is the victim, the negotiated feerate is
> still a safety concern in case of spontaneous mempool spikes.
>
> Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
> inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
> HTLC is removed. They're still at risk of the sum of the HTLCs under the
> dust limit being maliciously burned.
>
> # Solution
>
> A first mitigation is to verify the counterparty's announced
> `dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
> reception and reject if it's estimated too large (see #894)
>
> For LDK, we choose the value of 660 satoshis as it's beyond the highest
> dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
> safety. Propagation of Lightning time-sensitive transactions shouldn't be
> affected.
>
> A second mitigation is to define a new configurable limit
> `max_dust_htlc_exposure` and apply this one at incoming and outgoing of
> HTLC.
>
> For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged this
> value as a substantial loss for our class of users. Setting this too low
> may prevent the sending or receipt of low-value HTLCs on high-traffic
> nodes. A node operator should fine-tune this value in function of what
> qualifies as an acceptable loss.
>
> We would like to ensure that the node isn't suddenly exposed to
> significantly more trimmed balance if the feerate increases when we have
> several HTLCs pending which are near the dust limit.
>
> To achieve this goal, we introduce a new `dust_buffer_feerate` defined as
> the maximum of either 2530 sats per kWU or 125% of the current
> `feerate_per_kw` (implementation-defined values).
>
> Then, upon an incoming HTLC, if the HTLC's `amount_msat` is inferior to
> the counterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the
> `dust_buffer_feerate`. If the `amount_msat` plus the
> `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
> the HTLC should be failed once it's committed.
>
> Upon an outgoing HTLC, if the HTLC's `amount_msat` is inferior to the
> counterparty's `dust_limit_satoshis` plus the HTLC-success fee at the
> `dust_buffer_feerate`. If the `amount_msat` plus the
> `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
> the HTLC should not be sent and fail without forwarding.
>
> The check symmetry must also be applied on holder commitment transactions.
> See PR #919 for more details.
>
> A last mitigation is ensuring that at `update_fee` reception, the pending
> `dust_balance` at the new proposed feerate isn't superior to
> `max_dust_htlc_exposure_msat`.
>
> # Background
>
> The dust limit is a base layer policy stopping the relay of a transaction
> if one of its outputs is under a given threshold. The goal of this policy
> is to prevent the pollution of the UTXO set with low-value outputs and as
> such increase the amount of work done by full-nodes.
>
> Lightning commitment transactions should be able to propagate at any point
> during the channel lifetime to unilaterally enforce on-chain a balance. A
> Lightning commitment transaction with one of its outputs below the dust
> limit would fail to relay and thus jeopardizes funds safety.
>
> To prevent this, BOLT2 requires counterparties to announce a
> `dust_limit_satoshis` during channel opening (at
> `open_channel`/`accept_channel` exchange). This `dust_limit_satoshis` must
> be under the same party's `channel_reserve_satoshis`. This value is static
> for the channel lifetime.
>
> During commitment signatures exchange, each counterparty's limit is
> applied on each counterparty's commitment (e.g A's `dust_limit_satoshis` is
> applied on A's commitment, though both A and B have to generate and sign
> the transaction). An output below this limit is trimmed to fees and won't
> materialize on the commitment.
>
> The specification didn't require that the `open_channel`/`accept_channel`
> receiver verify that the announced `dust_limit_satoshis` isn't too large.
>
> The specification didn't require that the sum of the dust HTLC committed
> as fees was verified against an upper bound.
>
> # Discovery
>
> Vulnerabilities around our dust HTLC processing have been known for years
> by some LN developers/researchers.
>
> During Q1 2019, private discussions on the Rust-Lightning-side (LDK before
> marketing rebranding) about potential safety risks around dust HTLC
> processing.
>
> In November 2019, Rusty Russell (c-lightning) opened an issue against the
> specification mentioning the lack of check of counterparty's dust limit
> (#696).
>
> In May 2020, I published a high-level attack scenario "Miners Dust
> Inflation attacks on Lightning Network", leveraging this lack.
>
> In February 2021, I did a test of the first vulnerability against LND
> software and successfully burnt the majority of the targeted node balance
> in fees. As it sounds to me like a check missing in the specification, I
> notified CL/LND/Eclair/LDK maintainers. Mitigations started to be developed
> on the LDK-side.
>
> In July 2021, in the context of `option_dusty_htlcs_uncounted`
> discussions, Eugene Spiegel (LND) reported on how to exploit the
> trimmed-to-dust mechanism at `update_fee` reception. Discussions followed
> on the best way to mitigate this new vector.
>
> During August 2021, mitigations were developed and released on the
> LDK-side. vulnerabilities were disclosed to other Lightning projects (Muun
> wallet, Electrum). From the LDK-side, a public disclosure date was proposed.
>
> 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.
>
> While this report highlights the lack of well-defined communication
> process across Lightning teams, developers from 3 different
> implementations have actively participated in the vulnerabilities
> diagnostic and mitigations development of those long-standing specification
> issues affecting the whole Lightning ecosystem.
>
> All mistakes and opinions are my own and please verify any information
> reported.
>
> # Timeline
>
> * 2021-04-19: Working exploit of the vulnerability against LND,
> CL/LND/Eclair/LDK maintainers notified
> * 2021-07-21: Finding by Eugene Siegel on how to exploit the
> trimmed-to-dust mechanism at `update_fee` reception
> * 2021-08-11: BOLT PR #894 opened by Bastien Teinturier, covering the lack
> of verification of counterparty per-HTLC `dust_limit_satoshis`
> * 2021-08-16: Mitigations developed in LDK, communication of a public
> disclosure date
> * 2021-08-26: Notification to Muun wallet, non-affected
> * 2021-08-27: Notification to Electrum wallet
> * 2021-10-04: Full Disclosure of CVEs
> * 2021-10-04: Submit BOLT PR #919 covering the remaining vulnerabilities
> _______________________________________________
> 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/20211004/8cba7b8d/attachment-0001.html>

2023-06-09 13:03:25 GMT

- reply

📅 Original date posted:2021-08-15
📝 Original message:
The field of economics has done much work over the past few decades
demonstrating that “Free” is problematic in practice because humans will go
out of their way to externalize costs elsewhere (e.g. time, in the case of
lightning), given the promise of freedom. In other words, actors often act
irrationally to get a free deal.
As protocol designers, it would be remiss to ignore this (repeatedly
demonstrated) truth.
To avoid this, we’ve been suggesting setting a min_htlc_value requirement.
The problem with zbf + a min_htlc size requirement is that it makes tiny
payments impossible over lightning, which was one of the original design
goals of the system, and is an important feature to keep/support as
lightning grows into poorer economic bases and the bitcoin market price
continues to rise.
My suggestion would be that, as a compromise, we set a network wide minimum
fee at the protocol level of 1msat. Naively, this seems it should be easy
to add to calculations using single-dimension optimization (or trivial
enough to ignore entirely), it removes the “free lunch” irrationality
honeypot zbf opens, and it provides a way forward for the continued use of
micropayments.
The result is that micropayments have a different payment regime than
“non-micropayments”, (which may still incentive almost irrational behavior)
but at least there’s no *loss* felt by node operators for
handling/supporting low value payments. 10k micropayments is worth 10sats.
It’s also simple to implement and seems rather obvious in retrospect.
The only confounding future change that I can see us making would be the
introduction of negative fees, which are useful as a way to induce payments
to rebalance channels passively. This seems like something we can revisit
once a proposal for negative fees is being seriously considered, however.
On Sun, Aug 15, 2021 at 05:59 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning aj, et al.
>
> > 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 means you only have one value to optimise when trying to collect
> > the most fees, and one-dimensional optimisation problems are
> > obviously easier to write code for than two-dimensional optimisation
> > problems
>
> Indeed, this is a good point regarding this.
>
>
> > - when finding a route, if all the fees on all the channels are
> > proportional only, you'll never have to worry about paying more fees
> > just as a result of splitting a payment; that makes routing easier
> > (see [1])
>
> If we neglect roundoff errors.
>
> On the other hand, roundoff errors involved are <1msat per split, so it
> probably will not matter to most people.
>
> > So what's the cost? The cost is that there's no longer a fixed
> minimum
> > fee -- so if you try sending a 1sat payment you'll pay 0.1% of the
> fee
> > to send a 1000sat payment, and there may be fixed costs that you have
> > in routing payments that you'd like to be compensated for (eg, the
> > computational work to update channel state, the bandwith to forward
> the
> > tx, or the opportunity cost for not being able to accept another
> htlc if
> > you've hit your max htlcs per channel limit).
> >
> > But there's no need to explicitly separate those costs the way we do
> > now; instead of charging 1sat base fee and 0.02% proportional fee,
> > you can instead just set the 0.02% proportional fee and have a
> minimum
> > payment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02%
> > of that is 1sat. Nobody will be asking you to route without offering
> a
> > fee of at least 1sat, but all the optimisation steps are easier.
>
> Should this minimum a node will be willing to forward be part of gossip,
> and how does this affect routing algorithms?
>
> > You could go a step further, and have the node side accept smaller
> > payments despite the htlc minimum setting: eg, accept a 3000 sat
> payment
> > provided it pays the same fee that a 5000 sat payment would have.
> That is,
> > treat the setting as minimum_fee=1sat, rather than
> minimum_amount=5000sat;
> > so the advertised value is just calculated from the real settings,
> > and that nodes that want to send very small values despite having to
> > pay high rates can just invert the calculation.
>
> I like this idea, as I think it matches more what the incentives are.
> But it requires a change in gossip and in routing algorithms, and more
> importantly it requires routing algorithms to support two different fee
> schemes (base + proportional vs min + proportional).
>
> On the other hand, this still is a two-dimensional optimization algorithm,
> with `minimum_fee` and `proportional_fee_millionths` as the two dimensions.
> So maybe just have a single proportional-fee mechanism...
>
> >
> > I think something like this approach also makes sense when your
> channel
> > becomes overloaded; eg if you have x HTLC slots available, and y
> channel
> > capacity available, setting a minimum payment size of something like
> > y/2/x**2 allows you to accept small payments (good for the network)
> > when you're channel is not busy, but reserves the last slots for
> larger
> > payments so that you don't end up missing out on profits because you
> > ran out of capacity due to low value spam.
> >
> > Two other aspects related to this:
> >
> > At present, I think all the fixed costs are also incurred even when
> > a htlc fails, so until we have some way of charging failing txs for
> > incurring those costs, it seems a bit backwards to penalise
> successful
> > txs who at least pay a proportional fee for the same thing. Until
> we've
> > got a way of handling that, having zero base fee seems at least fair.
>
> Yes, the dreaded mechanism against payment lockup, which as far as I
> understand has a lot of thought already sunk into it without any
> widely-accepted solution, sigh.
>
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> 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/20210815/cb1c33c6/attachment.html>

2023-06-09 13:03:21 GMT

- reply

📅 Original date posted:2021-08-09
📝 Original message:
We're pleased to announce the 0.10.1 release of c-lightning
<https://github.com/ElementsProject/lightning/releases/tag/v0.10.1>, named
by @nalinbhardwaj.
This is a *recommended* upgrade: payment secrets in invoices are now
compulsory, and offers and dual funding drafts have been updated, so these
(experimental) features are incompatible with previous releases!
*NOTE*: Users of the rebalance or drain [plugins](
https://github.com/lightningd/plugins) MUST update, as payment secret is
now compulsory.
## Highlights for Users
- `experimental-dual-fund` allows advertizement of funding rates which we
will contribute to channels automatically, on a 1-month lease.
- `withdraw` and `close` (if peer supports) now supports Taproot (and other
future) addresses.
- `listchannels` can now be queried by destination, as well as source.
- `plugin rescan` now automatically reloads plugins which have changed.
- We try to restart automatically if we notice subdaemons have been
upgraded underneath us.
- `fundpsbt` will no longer include uneconomic UTXOs (unless `all`).
- `close` will return a stream of notifications if there is a delay in
closing.
- Unilateral close feerates were reduced from bitcoind's "2 CONSERVATIVE"
to "6 ECONOMICAL".
- Tor v2 is deprecated: please upgrade to v3!
- Fixed disconnection bug when an HTLC failed.
- Fixed bug in rapid feerate changes, and make code space them out (LND
compat).
- Fixed bug where Tor on different ports could be advertized incorrectly.
- Fixed various bugs to make `pay` more robust.
## Highlights for the Network
- payment secrets in invoices are now compulsory, finally closing a
potential probing (or, with amountless invoices, stealing) attack.
- `option_shutdown_anysegwit` allows peers to close channels to any future
segwit version address (taproot!).
- `keysend` now understands routehints, for routing to unpublished nodes,
and sets the final CLTV to 22, for rust-lightning nodes.
- `invoice` now allows creation of wumbo invoices (> 0.0429 BTC).
- We will now discuss old channels with peers who reconnect, even if we
consider them closed.
## Highlights for Developers
- Manual pages now document *exactly* the JSON you can expect from each
command (and it's tested!)
- Plugins can now publish notifications for other plugins to listen to.
- `force-feerates` allows complete feerate override (mainly for regtest),
and a bug fixed where we could send 0 update_fee on regtest.
- The HSM daemon is now separated into libhsmd, which also provides Python
bindings.
- `createonion` can now make variable-sized onions, and `sendonion` no
longer requires `direction` and `channel` for `firsthop`.
- `dev-sendcustommsg` is now simply `sendcustommsg`.
- Many offers API improvements and updates, including unsigned offers
(smaller QR codes!).
More details can be found in the [changelog](
https://github.com/ElementsProject/lightning/blob/v0.10.1/CHANGELOG.md).
Thanks to everyone for their contributions and bug reports; please keep
them coming.
Since 0.10.0, we've had 526 commits from 15 different authors over 114 days.
A special thanks goes to the 6 first time contributors:
- Nalin Bhardwa
- Nathanael
- LightningHelper
- OpenOms
- Urza
- Valentine Wallace
Cheers,
Lisa, Christian, ZmnSCPxj, Rusty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210809/b52db2be/attachment-0001.html>

2023-06-09 13:02:43 GMT

- reply

📅 Original date posted:2021-06-28
📝 Original message:
Hey all,
The dual-funding proposal has been up for a while now, and while we've had
some really great reviews from a few people (@ariard + @rustyrussell thanks
for
your comments in particular).
As a refresher, the PR is available here:
https://github.com/lightningnetwork/lightning-rfc/pull/851.
I wanted to make a quick summary of some of the biggest objections to
the protocol. Most of these were made during the course of the 2018 spec
meeting in Adelaide and while we've done a decent job of architecting
around them,
I wanted to make them explicit.
If there's more to add, please do.
## Point One
One: dual-funding (really the collaborative transaction protocol) requires
you to share your UTXO set with the channel peer.
This is true, in a 'limited' sense, where 'UTXO set' is actually constricted
to 'UTXOs you're using for funding transactions'.
On the face of it, this seems to be quite concerning to folks. Here's a
few things
that I think make this less concerning than it might appear at the outset.
First, let's consider the current opening case. You (or your channel peer)
constructs a transaction and shares the TXID and outpoint that the funding
output can be found at. This transaction is published and mined,
after the transaction is at sufficient depth a gossip announcement
is broadcast to the entire network, explaining where the transaction can be
found.
Under the current protocol, it's reasonable\* to conclude that
every UTXO in the funding transaction belongs to a single party, the opener.
Assuming that all the UTXOs in your wallet will, at some point, end up
in a lightning channel, all of your UTXOs will be *publicly* associated with
your node at some point (in the current model). Your UTXO set is only
private in the present, given a long enough time period (and channel opens)
they will all be tied to your node.
For this reason, it's probably not a great idea to fund wallets using a
separate wallet that hasn't been coinjoined or otherwise obfuscated. In
fact, I think you can make a fairly decent argument (under the existing UTXO
model) for not mixing lightning funds with any funds you wish to remain
truly
private/unassociated to an 'entity'.
Given that you're currently telling everyone what UTXOs your node owns
(or at least has a 50/50 chance of owning..) let's consider the interactive
transaction protocol.
Assuming a 2-party dual-funded open, as an outside observer it's much more
difficult to tell which
UTXOs belong to who (though you can probably guess given input amounts and
change outputs; maybe a good heuristic for opens is to use whole UTXOs).
In this on-chain respect, the dual-funding protocol is no worse, and in the
best case much
better for on-chain coin-analysis heuristics than the current protocol.
\* There are a few clear exceptions where other protocols (such as Pool,
iiuc)
have been developed that make this heuristic bunk as they *also* build a
multi-party
transaction, however afaik all of these other protocols (joinmmarket, pool)
still require sharing
your UTXOs with another (trusted) party, difference is you know in theory
where "the Pool
auctioneer" lives, whereas you don't really know much about "any random
node that wants to open
a channel". Seems like there might be some room in this space for better
information
about prospective channel peers...
## Point Two
Two: an active prober can use the interactive transaction protocol to
discover your wallet's entire UTXO set.
Given the assumption that all of your node funds will, at some point,
be used to open a lightning channel, a single attacker discovering a subset
of your UTXOs is simply a 'fast-forward' of what will eventually become
public information.
That being said, much smarter minds (e.g. JoinMarket, which suffers from
a very similar issue in what I would argue an even more privacy-conscious
context) than mine have employed the PoDLE protocol to make the discovery
of every UTXO more costly for a potential attacker. This is something
we can add quite trivially to the protocol, at the cost of grossly
increasing
the gossip traffic.
Worth noting that even without PoDLE you can much slow this type of
attack by reusing the same UTXO across every open attempt, being choosy
about which peers you do offer liquidity up to (do they have other
established
channels? what's their uptime?) etc.
A dedicated attacker could probably figure out your UTXO set, but that's not
much different from the current system; the only difference is the span of
time
it takes them to figure it out.
## Things We've Done to Counter This:
I had the pleasure of finally meeting Nadav of SuredBits and DLC fame in
Miami
a few weeks ago. The DLC team has adopted a version of the interactive
transaction protocol for their own purposes. Nadav pointed out that the
protocol we landed on for lightning interactive construction transactions
is *quite* interactive; the DLC version modified it to use batching to
transmit the input/output sets (the interactive protocol is one-by-one).
The rationale for doing the addition of inputs and outputs in a non-batched
fashion is that this allows for you to interleave UTXOs from a variety
of sources, for example multiple channel opens in the same tx. With the
current
protocol, you can initiate a dual-funded open with many peers at the same
time,
each of which may contribute UTXOs and outputs for their own respective
channel opens or UTXO consolidations etc.
This gives us the real possibility of doing multiparty coinjoins on
lightning.
In fact, this is currently possible with c-lightning *today* using
the multifundchannel command (h/t to ZmnSCPjx for the original framework
for multifund opens).
As written, the interactive transaction protocol is exceedingly flexible.
We traded off succinctness for some plausible deniablity wrt
any UTXOs you send to any peer -- are they yours or are they
some third party's? How to tell?
I think it's interesting to point out that "succinctness" in rounds
of required interaction is typically a *highly* desirable trait for
any cryptographic protocol. The establishment of a lightning channel
relationship,
however, isn't a cryptographic signature. A lightning channel, by its very
nature, is typically a highly interactive relationship between two peers.
Increasing the rounds of messaging required to establish the channel doesn't
change the overall interactivity profile of a channel's operation, thus
adding rounds of comms to channel open is generally a no-op in terms of
performance/uptime requirements of a node's operations.
## How important is UTXO privacy on lightning?
Obviously important. But given that the real transactions happen inside
of channels, invisibly, and that your public channels really truly
are public via the gossip protocol the much more important "thing" in the
lightning arena isn't your UTXO privacy so much as *not* associating your
identity with your node.
## Does Taproot fix this?
I'm not up to date enough on the progress of Taproot scripts, however,
assuming the current requirement that every routing node is able to
independently
verify the opening output script via the signatures provided
in the channel_announcement, it seems reasonable that on-chain transactions
will still be assignable to a node given gossip data. (Purely on-chain
analysis
will be stymied, however.)
# In Exitus
There are legitimate concerns regarding sharing UTXOs with other peers
in the process of opening a channel. The current protocol, as implemented,
introduces a mechanism for some plausible deniability wrt who those UTXOs
actually belong to, as well as providing the tools for building multi-party
coinjoins as
opens. Further, with PoDLEs, we can at least achieve a similar level of
protection
as JoinMarket currently enjoys.
Finally, regardless of what open mechanism you're using, it's worth
reiterating
that best practice is to not *ever* tie your identity to your lightning
node.
And it may be worth reconsidering what wallet source you're using to fund
announced channel opens.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210628/71a44fbe/attachment-0001.html>

2023-06-09 12:59:59 GMT

- reply

📅 Original date posted:2020-04-30
📝 Original message:
We're pleased to announce the 0.8.2 release of c-lightning, named by
@arowser <https://github.com/arowser>.
This is a minor release and includes a few new and experimental features,
as well as bug-fixes and performance wins.
Highlights for Users
- New config option --large-channels (also known as 'wumbo') which
enables opening channels of any size. (Note that your peer must also
support large channels.)
- This release includes a keysend plugin, which will enable receiving
'keysend' payments, as first introduced by Lightning Labs
<https://github.com/lightningnetwork/lnd/pull/3795>. Note that the
included keysend plugin is receive only for this release. Nodes which do
not want the hassle of spontaneous unrequested payments should add
'disable-plugin=keysend' to their config!
- We'll now announce multiple connection endpoints for a single 'type',
e.g. multiple IPv4 addresses.
- A new FAQ
<https://github.com/ElementsProject/lightning/blob/master/doc/FAQ.md>!
- Big performance improvment in the pay command (~1s speedup on average)
Highlights for the Network
- c-lightning nodes can now participate in creating larger channels
(with the --large-channel config option).
- We now wait until the first payment through a channel before updating
the feerate; this should help with some spurious closures at channel open
or re-connect that were occurring against older versions of other
implementations.
Highlights for Developers
- A new command getsharedsecret for getting the BOLT-compliant shared
secret finding for a node and a point.
- The API for the 'Bitcoin backend' plugin infrastructure has been
documented!
- Facilities for building rendez-vous compatible onions has been added
to the onion devtool
- Plugin options will now respect the type they were given in the
manifest.
- Fixes with plugin cleanups and hangs.
- Python2 has been removed as a dependence.
More details can be found at
https://github.com/ElementsProject/lightning/blob/v0.8.2/CHANGELOG.md
Thanks to everyone for their contributions and bug reports; please keep
them coming.
Since 0.8.1, we've had 236 commits from 10 different authors, with 2 first
time contributors:
- Dr. Maxim Orlovsky @dr-orlovsky <https://github.com/dr-orlovsky>
- Dave Scotese @dscotese <https://github.com/dscotese>
Cheers,
Lisa, Christian, Rusty, and ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200430/d91e2979/attachment.html>

2023-06-09 12:58:45 GMT

- reply

📅 Original date posted:2020-02-12
📝 Original message:
> Probably so that address reuse is not dinged, i.e. I have two UTXOs with
the same address and want to make two different channels with different
peers.
Having 2 utxos locked to the same pubkey will map to a single H2 value
though, which is what is used to flag utxo reuse. With a PoDLE you're
proving that you have a *key* for a utxo; the verifier checks that the key
you say you know does in fact map to controlling the utxo that you say it's
attached to. Whether or not you added the utxo to the signature commitment
doesn't add anything to the security of the verification.
At worse, it might leak what other utxo that the initiator controls, if
they accidentally commit to the wrong utxo and the peer decided to try
grinding utxo outpoints on the offchance that one matched.
On Tue, Feb 11, 2020 at 10:04 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning niftynei, and waxwing, and list,
>
> > > s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x
> >
> > > and as before transfer opening: (P, P2, u, s, e) with receiving-node
> implicitly reconstructed to do the verification of the Schnorr sig. It's
> basically a message in a signature.
> >
> > Oh that's *much* nicer than calculating a second commitment.
> Verification by any node that's not the intended recipient will fail, as
> they'll use the wrong node_id (their own).
> >
> > It seems unnecessary to me to commit to the utxo, since the pubkey pair
> effectively does that. What's the motivation for including it?
>
> Probably so that address reuse is not dinged, i.e. I have two UTXOs with
> the same address and want to make two different channels with different
> peers.
>
> While address reuse Is Bad, you might not have much control over some wog
> who is supposed to pay you and decides to give you your money in two
> separate UTXOs to the same address.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200212/1c55131e/attachment.html>

2023-06-09 12:58:44 GMT

- reply

📅 Original date posted:2020-02-11
📝 Original message:
> s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x
> and as before transfer opening: (P, P2, u, s, e) with receiving-node
implicitly reconstructed to do the verification of the Schnorr sig. It's
basically a message in a signature.
Oh that's *much* nicer than calculating a second commitment. Verification
by any node that's not the intended recipient will fail, as they'll use the
wrong node_id (their own).
It seems unnecessary to me to commit to the utxo, since the pubkey pair
effectively does that. What's the motivation for including it? Though, now
that I think about it, it does seem imperative to verify that the pubkey
provided is in fact locked to by the utxo script, which we can do since the
script will have been provided in the `tx_add_input` message.
Seems worth nothing that, given such a proof, you can grind to find out who
the intended node was. However, if the failure is indeed because of the
"venus flytrap" attack I mentioned above, it'd pretty obviously be the node
sending you the invalid signature (or a node that they spoofed/MITM'd),
which isn't much of a leak. Actually, this 'grindability' might be quite
useful for finding the originator of the attack, if needed. There's no
reason for you to leak a PoDLE signature, but if you do you're
potentially tying an H2 commitment offer to your node id. Seems very nice
indeed!
One of the stated goals of implementing PoDLEs was to be "compatible with
JoinMarket", but I believe this compatibility goal only extends as far as
the H2 construction (and not the proof), so we're ok there with this tweak.
Cheers!
niftynei
On Tue, Feb 11, 2020 at 10:05 AM AdamISZ via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> niftynei, ZmnSCPxj and list:
>
>
> Zmn** pinged me about this discussion and I thought I could add something
> directly:
>
>
> First, re:
> > I'd like to propose that we add a second commitment requirement to the
> PoDLE that JoinMarket uses, to limit the use of a commitment's validity to
> be only between an initiator and a single peer. Otherwise you can enable
> something I'll call the "pouncing venus-flytrap attack"[1].
>
> Here's some thoughts that may give context to this (excellent) observation:
>
> This issue didn't crop up (well, kinda! I do remember discussion about it)
> in our use case because takers always send out to 5-12 (typically) makers
> at once, and the HP2 only needs to get broadcast by one to stop any reuse.
> But whichever way you look at it, it's a very good point! And in LN case,
> seems like a very substantial attack (certainly no question it could be
> allowed for 2 party protocol).
>
> In case a brief summary of JM mechanism is helpful, I added some info on
> the the taker-maker conversation at the end of this mail [1].
>
> Second, re:
> > ## Mitigation
> > Have each initiator provide two commitments: one to the shared/global J
> > point and one to a point that is found from the hash of the
> non-initiating
> > node's node_id.[2]
>
> I get the thinking here, and it makes a lot of sense, but I do think it
> can be done more compactly.
> If the commitment is H(P2), the opening of the commitment could be altered
> to include the receiving node:
>
> s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x
>
> and as before transfer opening: (P, P2, u, s, e) with receiving-node
> implicitly reconstructed to do the verification of the Schnorr sig. It's
> basically a message in a signature.
>
> As you note, we wouldn't want to ban usage of a H(P2) value based on an
> incorrect opening; we just use that failure to decide to not hand over our
> utxo information (as receiver of the commitment). But unless I missed
> something, doing it the above way is the more logical/compact choice.
>
> Seems like there's a lot of fine nuance here. A malicious counterparty can
> always choose to blacklist. In Joinmarket we accept (because of our
> stringent no-identity policy) some roughness and assume some meaningful
> level of honest participation. A Taker issuing a request to 10 cps hopes
> that at least some number (min 4 by default) will actually respond to an
> honest request; if say 8 of 10 do so, he will do the coinjoin with those.
> That it is brittle or flaky is why we allow 3 tries for each qualifying
> utxo (qualified on age, size), and also allow custom insertion of
> additional utxos (although it's rarely if ever needed). It works fine in
> practice, for now, but it is not watertight; if you have overwhelmingly
> malicious counterparties you are kinda screwed from other angles, as well
> as this one. Meanwhile on the Maker side we're trying to create a kind of
> 'herd immunity'; as long as some few of them are honest, word will get out
> about used commitments which will stop free spam queries,
> at least (but it's not a super strong defence!).
>
>
> [1] Taker-Maker convo (excerpt); some notes re: commitments/PoDLE.
> ===
> !fill amount, oid, commitment (HP2)
> -- this is where a taker sends to each maker an hp2 value. This is the
> step intended to enforce scarcity, and the assumption in JM was always that
> this would basically inevitably get shared. Because there are typically
> 5-12 makers involved, this seemed a reasonably safe assumption.
> If the commitment value is already used and thus not valid, it gets
> broadcast immediately. If it's not, it only gets shared as part of the
> !ioauth step below.
>
> !pubkey key
>
> -- this is just the maker giving an ephemeral key for the encryption
>
> !auth (s, e, u, P, P2)
> -- (encrypted) this is the taker opening the above commitment. It's rather
> weird at first sight, because he is opening immediately after committing,
> with apparently no step inbetween; but in fact the implicit intermediate
> step is the broadcast (exactly what is being questioned with 'venus
> flytrap').
>
> !ioauth maker-utxo-data
> -- notice the maker is only sending this utxo data (encrypted of course)
> after proof of ownership of the utxo above.
> It's only at this step that the hp2 commitment value is (a) added to the
> maker's local "used up" list, and (b)privmsged to 1 randomly chosen other
> bots in the trading pit, who then pubmsgs it to everyone (and that happens
> multiple times because multiple makers in tx), and they in turn record it
> as "used".
>
> The mechanism is both not very strong - we use 3 allowed attempts per utxo
> - and imperfect in its "justice"; such commitments can be "used up" by
> failures of one's counterparties. But it does serve to stop trivial global
> snooping, and doesn't cost anything in terms of identity or locked funds,
> so it has served a purpose (we did actually see such attacks before it, and
> not after it).
>
> I'd also note that in terms of the venus flytrap attack mentioned, there
> could be a small time window between one maker receiving !auth and at least
> one other honest maker getting to broadcast step at !ioauth; while I don't
> think that's very practical in our use case, it is for sure a theoretical
> concern and removing it could be either slightly, or extremely, important
> in another use case.
>
> Thanks,
> Adam Gibson/waxwing/AdamISZ
>
> Sent with ProtonMail Secure Email.
>
>
> _______________________________________________
> 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/20200211/d140fadd/attachment-0001.html>

2023-06-09 12:58:42 GMT

- reply

📅 Original date posted:2020-02-10
📝 Original message:
I'd like to propose that we add a second commitment requirement to the
PoDLE that JoinMarket uses, to limit the use of a commitment's validity to
be only between an initiator and a single peer. Otherwise you can enable
something I'll call the "pouncing venus-flytrap attack"[1]. Venus-flytrap
because they sit in wait for victims; pouncing because the venus-flytrap
then attacks other nodes using the provided fly/utxo bait.
## The Attack
A malicious node sits and waits until another, honest, node initiates an
open with them. They wait until the honest initiator has sent them the
commitment and utxo proof. They then use the provided, non-blacklisted utxo
and commitment proof to attempt to open a channel with as many other nodes
as possible, simultaneously. They may either fail to respond or not fail
the original channel open. They fail every other open attempt,
simultaneously. Each of the nodes they've griefed will blacklist the
provided UTXO; the honest initiator has now had their utxo blacklisted.
## Mitigation
Have each initiator provide two commitments: one to the shared/global J
point and one to a point that is found from the hash of the non-initiating
node's node_id.[2]
The global-point commitment is the one that is blacklisted; the node_id's
commitment prevents the other party from being able to re-use a commitment
in another channel, as they'll be unable to produce a valid commitment to
the point derived from the node_id of their victim (so the victim will know
the commitment has been re-used).
This has implications for 'multi-channel opens', in that any node
initiating an open MUST provide at least one utxo of their own. This seems
like an acceptable limitation, imo.
The protocol adjustments required for this are :
- Add a second commitment to the TLV of `open_channel2`; two H2's, one for
the 'global J' and one for the 'nodes J', with the global point commitment
always appearing first.
- The TLV type for the `tx_add_input` for the 'committed utxo' will now
include an array of two `proof of dle's`, in commitment hash order.
1. tlvs: `add_input_tlvs`
2. types:
1. type: 1 (`proof_of_dle_array`)
2. data:
*[`2*proof_of_dle`]
1. subtype (`proof_of_dle`)
*[`64*byte`:`s||e`]
*[`33*byte`:pubkey`]
*[`33*byte`:pubkey2`]
A node that provides a valid global point but an invalid 'local point'
commitment should be immediately errored on and potentially blacklisted.
A failure of this type should *not* result in a blacklist of the global
commitment.
[1] There's probably a better analogy here, but it's escaping me at the
moment.
[2] We reuse JoinMarket's NUMs point generation idea of appending a counter
to a hash until a valid positive-public key point is found, but without the
index.
On Mon, Feb 10, 2020 at 5:11 PM lisa neigut <niftynei at gmail.com> wrote:
> Here's some thoughts I had on PoDLE's and lightning. An enormous
> tip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket
> has done here already.
>
> - The initiating message (in the case of open channel, this would be
> `open_channel2`) is extended to include an 'H2' field in its TLV, a 32-byte
> hash commitment to the P2 key.
> - Only one H2 commitment is required.
> - The `tx_add_input` message, as specified previously, is extended to an
> include a TLV type. This must be present on the input addition that
> corresponds with the UTXO used for the originally transmitted commitment
> - The non-initiator SHOULD wait to send any `tx_add_input` messages of
> their own until after receiving a `tx_add_input` message with a valid PoDLE
> TLV extension.
>
> 1. tlvs: `add_input_tlvs`
> 2. types:
> 1. type: 1 (`proof_of_dle`)
> 2. data:
> *[`64*byte`:`s||e`]
> *[`33*byte`:pubkey`]
> *[`33*byte`:pubkey2`]
>
> - If the proof is incorrect, the non-initiator MAY fail the transaction
> collaboration or respond with `tx_complete`. There is no need for them to
> publish the PoDLE.
> - If the proof is correct, the non-initiator verifies that the commitment
> (hash of pubkey2) has not been communicated to them via gossip.
> - If the proof is not in their gossip store, the transaction collaboration
> continues. It is considered 'safe' for the non-initiator to send
> `tx_add_input` to their peer.
> - If the proof IS in their gossip store, the transaction collaboration
> SHOULD reply with `tx_complete`. It is considered 'unsafe' for the
> non-initiator to send `tx_add_input`. (This allows errored/erroring
> initiators to use blacklisted utxos, however it prevents them from privy to
> any other nodes' UTXO set.)
> - The initiator MUST NOT remove the committed to UTXO from the
> collaboration set.
>
> - If the transaction collaboration fails/is errored by the initiator,
> - the non-initiator SHOULD broadcast the original PoDLE commitment to
> the gossip network.
> - the non-initiator MAY delay broadcast to allow the initiating node
> to re-attempt the open.
>
> The gossip message for a PoDLE blacklist entry is as follows:
>
> 1. type: 259 (`podle_blacklist`)
> 2. data:
> *[`signature`:`signature`]
> *[`32*byte`:`H2`]
> *[`point`:`node_id`]
> *[`u32`:`timestamp`]
>
> Note that the `node_id` is the id of the node that signs (and broadcasts)
> the blacklisted PoDLE. h/t to ZmnSCPxj for the gossip construction.
> The timestamp is added as a convenience for peers to trim/discard
> blacklist participants as they wish depending on time/staleness.
>
> ## Some Notes:
> - The JoinMarket protocol allows nodes to use any of a range of secondary
> points for J. Since the lightning version of this allows blacklisted UTXOs
> to still open channels, albeit without participation from the peer, it
> seems unnecessary to allow for more than one valid J point. I'd propose
> fixing the J the same zero-index point used by JoinMarket. This reduces the
> number of valid H2's that are available for any given utxo set, while also
> keeping blacklisted H2's compatible with the blacklist set generated by
> JoinMarket implementations.
> - The blacklist originates from the 'non-initiating' peer, and does not
> reveal the offending node's id.
> - Assuming that every node honestly participates in the blacklist, only
> verified H2's will be submitted to the blacklist
> - A malicious non-initiator can only prevent an honest initiator from
> using the committed UTXO for collaborative transactions; they won't prevent
> them from successfully initiating a one-sided transaction with honest peers.
> - Only nodes that have at least one public channel will be able to
> contribute to the public PoDLE blacklist. This means it's possible for a
> malicious initiator to grief non-public nodes without much consequence,
> however this requires the ability to send inbound messages to private
> nodes, i.e. more likely for a close or splice interaction.
> - As ZmnSCPxj has pointed out elsewhere, a malicious peer could broadcast
> junk H2's; it is acceptable to rate-limit the number of PoDLE blacklists
> generated by a peer.peer
> - It is possible for a malicious peer to fail to relay their `H2` entries
> in the blacklisted gossip set.
> - Duplicate H2 gossip should replace older timestamped versions.
> - Elsewhere we've had a discussion/concern over floods of PoDLE blacklist
> messages. It's possible for gossip message floods to originate from a
> malicious peer; they also might signal an ongoing probe attempt. Given a
> timestamp and a rough measure of the number of utxos' currently outstanding
> in the mempool, however, it should be possible to distinguish the two.
>
> ## Open Questions:
> - Should PoDLE be required for every collaborative transaction (opens,
> splices + closes), or only for opens? It seems reasonable to limit them
> just to opens, as for all others you'll already have a shared UTXO with the
> peer.
> - Is fixing the generator point too restrictive? JoinMarket allows for a
> range of acceptable NUMS (J) points (up to 256). The smaller the pool of
> eligible J's, the smaller the pool of potential blacklisted PoDLE's (up to
> no. NUMs * current utxo count). One upside to allowing a larger pool of J's
> means that the same UTXO can be retried on failure. One downside to
> allowing a pool of J's means that a single UTXO can be validly retried in a
> probe attack against a variety of peers.
>
> On Thu, Jan 30, 2020 at 5:32 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning darosior, ariard, niftynei, and list,
>>
>> > We could also consider PoDLE as used in JoinMarket, which solves a
>> similar problem.
>> >
>> https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
>> > Basically, a PoDLE commits to a UTXO, without being trivially grindable
>> from the UTXO set and also including a proof that the creator of the PoDLE
>> knows the secret key behind it.
>> > It can later be opened to reveal which UTXO the opener allocated.
>> > If the opener aborts (i.e. does not provide its signatures to the
>> funding transaction) then the acceptor can gossip the UTXO and the revealed
>> PoDLE as well to the rest of Lightning, so that the opener at least cannot
>> reuse the same UTXO to probe other potential acceptors.
>> > (though, my understanding, there is no clear way to determine when we
>> can safely delete old PoDLEs: maybe each node can keep it around for a
>> month, which might be good enough to limit the practical ability of a snoop
>> to probe other nodes)
>> > I believe JoinMarket also has solved the issue of allowing a UTXO to be
>> used at most N times (for example due to "honest" failures, such as
>> connectivity interruptions which might cause an abort of the protocol); I
>> think it involves appending a single byte to something that is hashed, and
>> ensuring its value is less than N, so that it can only be used from 0 to N
>> - 1 (and thus allow a UTXO to be used at most N times).
>> >
>> > Getting into contact with waxwing / Adam Gibson for this might be
>> useful to fill out how PoDLE works and so on; basically, I believe this
>> issue is a practically solved problem already for JoinMarket, though
>> waxwing may be able to provide a more nuanced opinion.
>>
>> I communicated with waxwing, and he said:
>>
>> * See also: https://joinmarket.me/blog/blog/poodle \[sic\].
>> * The counter I mentioned is implemented using the second generator point.
>> * The PoDLE construction requires the standard base point `G`, and
>> another generator point `J`.
>> * To create the generator point `J`, JoinMarket appends the counter
>> byte (the one used to limit N number of uses of the same UTXO) to `G`,
>> hashes it, then uses a coerce-to-point.
>> * PoDLE is sometimes called DLEQ elsewhere.
>> * There is no concrete answer on "when to delete old PoDLE"; JoinMarket
>> never deletes (though they might if throughput increases).
>> * Watermarks like `nLockTime`, `nSequence`, `nVersion` are currently
>> fixed values; JoinMarket sees no reason to change this since equal-valued
>> CoinJoins are otherwise obvious to chain analysis anyway.
>> * But note: JoinMarket implements PayJoin, which is not otherwise
>> obvious onchain, and does indeed do anti-fee-sniping emulation for PayJoin.
>> * JoinMarket also strives to make similar feerates across users.
>>
>> In any case, for myself, my thoughts are:
>>
>> * I observe that our use-case is quite similar to a PayJoin:
>> * The opener proposes to make a payment (to a channel between the
>> opener and the acceptor, rather than outright giving control to the
>> acceptor as in PayJoin).
>> * The acceptor adds some UTXOs which will contribute to the payment
>> output (i.e. the channel).
>> * This probably does mean we want to later consider `nLockTime`
>> anti-fee-sniping as well in multi-funded channel opens.
>> * Speaking of multi-funded channel opens, it seems to me this interactive
>> tx construction mechanism as well can be later used for channel factories.
>> * Similarly, PoDLE techniques would be useful as well to multi-funded
>> channel factories.
>> * It would probably be a good idea to share PoDLE format with JoinMarket
>> so we can share PoDLE with them (there could be bridges that share PoDLE
>> between a JoinMarket maker and a Lightning node, and each network already
>> has its own gossip protocols, so LN just needs a gossip protocol for
>> sharing PoDLEs as well).
>> * Probably we can mandate in some BOLT spec to retain PoDLE for at least
>> a year or a month or two weeks or so, which should be enough to slow down
>> probe attempts.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/f584936f/attachment-0001.html>

2023-06-09 12:58:41 GMT

- reply

📅 Original date posted:2020-02-10
📝 Original message:
Here's some thoughts I had on PoDLE's and lightning. An enormous
tip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket
has done here already.
- The initiating message (in the case of open channel, this would be
`open_channel2`) is extended to include an 'H2' field in its TLV, a 32-byte
hash commitment to the P2 key.
- Only one H2 commitment is required.
- The `tx_add_input` message, as specified previously, is extended to an
include a TLV type. This must be present on the input addition that
corresponds with the UTXO used for the originally transmitted commitment
- The non-initiator SHOULD wait to send any `tx_add_input` messages of
their own until after receiving a `tx_add_input` message with a valid PoDLE
TLV extension.
1. tlvs: `add_input_tlvs`
2. types:
1. type: 1 (`proof_of_dle`)
2. data:
*[`64*byte`:`s||e`]
*[`33*byte`:pubkey`]
*[`33*byte`:pubkey2`]
- If the proof is incorrect, the non-initiator MAY fail the transaction
collaboration or respond with `tx_complete`. There is no need for them to
publish the PoDLE.
- If the proof is correct, the non-initiator verifies that the commitment
(hash of pubkey2) has not been communicated to them via gossip.
- If the proof is not in their gossip store, the transaction collaboration
continues. It is considered 'safe' for the non-initiator to send
`tx_add_input` to their peer.
- If the proof IS in their gossip store, the transaction collaboration
SHOULD reply with `tx_complete`. It is considered 'unsafe' for the
non-initiator to send `tx_add_input`. (This allows errored/erroring
initiators to use blacklisted utxos, however it prevents them from privy to
any other nodes' UTXO set.)
- The initiator MUST NOT remove the committed to UTXO from the
collaboration set.
- If the transaction collaboration fails/is errored by the initiator,
- the non-initiator SHOULD broadcast the original PoDLE commitment to
the gossip network.
- the non-initiator MAY delay broadcast to allow the initiating node to
re-attempt the open.
The gossip message for a PoDLE blacklist entry is as follows:
1. type: 259 (`podle_blacklist`)
2. data:
*[`signature`:`signature`]
*[`32*byte`:`H2`]
*[`point`:`node_id`]
*[`u32`:`timestamp`]
Note that the `node_id` is the id of the node that signs (and broadcasts)
the blacklisted PoDLE. h/t to ZmnSCPxj for the gossip construction.
The timestamp is added as a convenience for peers to trim/discard blacklist
participants as they wish depending on time/staleness.
## Some Notes:
- The JoinMarket protocol allows nodes to use any of a range of secondary
points for J. Since the lightning version of this allows blacklisted UTXOs
to still open channels, albeit without participation from the peer, it
seems unnecessary to allow for more than one valid J point. I'd propose
fixing the J the same zero-index point used by JoinMarket. This reduces the
number of valid H2's that are available for any given utxo set, while also
keeping blacklisted H2's compatible with the blacklist set generated by
JoinMarket implementations.
- The blacklist originates from the 'non-initiating' peer, and does not
reveal the offending node's id.
- Assuming that every node honestly participates in the blacklist, only
verified H2's will be submitted to the blacklist
- A malicious non-initiator can only prevent an honest initiator from using
the committed UTXO for collaborative transactions; they won't prevent them
from successfully initiating a one-sided transaction with honest peers.
- Only nodes that have at least one public channel will be able to
contribute to the public PoDLE blacklist. This means it's possible for a
malicious initiator to grief non-public nodes without much consequence,
however this requires the ability to send inbound messages to private
nodes, i.e. more likely for a close or splice interaction.
- As ZmnSCPxj has pointed out elsewhere, a malicious peer could broadcast
junk H2's; it is acceptable to rate-limit the number of PoDLE blacklists
generated by a peer.peer
- It is possible for a malicious peer to fail to relay their `H2` entries
in the blacklisted gossip set.
- Duplicate H2 gossip should replace older timestamped versions.
- Elsewhere we've had a discussion/concern over floods of PoDLE blacklist
messages. It's possible for gossip message floods to originate from a
malicious peer; they also might signal an ongoing probe attempt. Given a
timestamp and a rough measure of the number of utxos' currently outstanding
in the mempool, however, it should be possible to distinguish the two.
## Open Questions:
- Should PoDLE be required for every collaborative transaction (opens,
splices + closes), or only for opens? It seems reasonable to limit them
just to opens, as for all others you'll already have a shared UTXO with the
peer.
- Is fixing the generator point too restrictive? JoinMarket allows for a
range of acceptable NUMS (J) points (up to 256). The smaller the pool of
eligible J's, the smaller the pool of potential blacklisted PoDLE's (up to
no. NUMs * current utxo count). One upside to allowing a larger pool of J's
means that the same UTXO can be retried on failure. One downside to
allowing a pool of J's means that a single UTXO can be validly retried in a
probe attack against a variety of peers.
On Thu, Jan 30, 2020 at 5:32 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning darosior, ariard, niftynei, and list,
>
> > We could also consider PoDLE as used in JoinMarket, which solves a
> similar problem.
> >
> https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
> > Basically, a PoDLE commits to a UTXO, without being trivially grindable
> from the UTXO set and also including a proof that the creator of the PoDLE
> knows the secret key behind it.
> > It can later be opened to reveal which UTXO the opener allocated.
> > If the opener aborts (i.e. does not provide its signatures to the
> funding transaction) then the acceptor can gossip the UTXO and the revealed
> PoDLE as well to the rest of Lightning, so that the opener at least cannot
> reuse the same UTXO to probe other potential acceptors.
> > (though, my understanding, there is no clear way to determine when we
> can safely delete old PoDLEs: maybe each node can keep it around for a
> month, which might be good enough to limit the practical ability of a snoop
> to probe other nodes)
> > I believe JoinMarket also has solved the issue of allowing a UTXO to be
> used at most N times (for example due to "honest" failures, such as
> connectivity interruptions which might cause an abort of the protocol); I
> think it involves appending a single byte to something that is hashed, and
> ensuring its value is less than N, so that it can only be used from 0 to N
> - 1 (and thus allow a UTXO to be used at most N times).
> >
> > Getting into contact with waxwing / Adam Gibson for this might be useful
> to fill out how PoDLE works and so on; basically, I believe this issue is a
> practically solved problem already for JoinMarket, though waxwing may be
> able to provide a more nuanced opinion.
>
> I communicated with waxwing, and he said:
>
> * See also: https://joinmarket.me/blog/blog/poodle \[sic\].
> * The counter I mentioned is implemented using the second generator point.
> * The PoDLE construction requires the standard base point `G`, and
> another generator point `J`.
> * To create the generator point `J`, JoinMarket appends the counter byte
> (the one used to limit N number of uses of the same UTXO) to `G`, hashes
> it, then uses a coerce-to-point.
> * PoDLE is sometimes called DLEQ elsewhere.
> * There is no concrete answer on "when to delete old PoDLE"; JoinMarket
> never deletes (though they might if throughput increases).
> * Watermarks like `nLockTime`, `nSequence`, `nVersion` are currently fixed
> values; JoinMarket sees no reason to change this since equal-valued
> CoinJoins are otherwise obvious to chain analysis anyway.
> * But note: JoinMarket implements PayJoin, which is not otherwise
> obvious onchain, and does indeed do anti-fee-sniping emulation for PayJoin.
> * JoinMarket also strives to make similar feerates across users.
>
> In any case, for myself, my thoughts are:
>
> * I observe that our use-case is quite similar to a PayJoin:
> * The opener proposes to make a payment (to a channel between the opener
> and the acceptor, rather than outright giving control to the acceptor as in
> PayJoin).
> * The acceptor adds some UTXOs which will contribute to the payment
> output (i.e. the channel).
> * This probably does mean we want to later consider `nLockTime`
> anti-fee-sniping as well in multi-funded channel opens.
> * Speaking of multi-funded channel opens, it seems to me this interactive
> tx construction mechanism as well can be later used for channel factories.
> * Similarly, PoDLE techniques would be useful as well to multi-funded
> channel factories.
> * It would probably be a good idea to share PoDLE format with JoinMarket
> so we can share PoDLE with them (there could be bridges that share PoDLE
> between a JoinMarket maker and a Lightning node, and each network already
> has its own gossip protocols, so LN just needs a gossip protocol for
> sharing PoDLEs as well).
> * Probably we can mandate in some BOLT spec to retain PoDLE for at least a
> year or a month or two weeks or so, which should be enough to slow down
> probe attempts.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/047f7af7/attachment.html>

2023-06-09 12:58:41 GMT

- reply

📅 Original date posted:2020-02-13
📝 Original message:
> With PoDLE this would not be possible I think, as you would not be able
to open the PoDLE commitment with the other node as the target (if we go
with the modified PoDLE which also commits to which node an opening is for,
to prevent the pouncing venus flytrap attack).
Good question. It should be possible to do multi-channel open even with the
PoDLE signature committing to a node_id.
- An initiator can use the same utxo (h2) as their proof for multiple
peers; the signatures passed to each peer will have to commit to that
specific peer's node_id, however.
- The revised PoDLE signature commitment requires every initiator to
include at least one of their own inputs in the tx. Attempting to initiate
an additional open etc using someone else's utxo's won't work (this is the
pouncing venus flytrap attack which we're preventing). The initiator
including at least one input is expected behavior, at least in the open
case, since the opener has to cover the fees for the funding output.
- Ideally, a node would remove the PoDLE TLV data from any 'forwarded'
`tx_add_inputs` that isn't the input they're proving for, to prevent
leaking information about which inputs belong to other parties. I say
ideally here because even if you fail to do this, the peer can iterate
through all the provided commitment proofs until one of them
matches/verifies with the upfront provided PoDLE.
On Thu, Feb 13, 2020 at 12:18 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Rusty, niftynei, and list,
>
> > > > - Serial ids should be chosen at random
> > > >
> > > > - For multiparty constructions, the initiator MUST flip the bottom
> bit of any received inputs before relaying them to a peer.
> > > >
> > > > - Collisions of serial ids between peers is a protocol error
> > > >
> > >
> > > I suppose we should define collision to mean "equal in all bits except
> the lowest bit".
> >
> > No, literally equal. i.e. you can only make this error by clashing with
> > yourself.
>
> hmm, I thought the entire point of having the low bit was that you could
> multifund in such a way that the initiator creates multiple channels
> simultaneously with multiple nodes?
> So you would have to take the UTXOs of one peer and give it to the other
> peer claiming it as your own.
> Or something.
>
> With PoDLE this would not be possible I think, as you would not be able to
> open the PoDLE commitment with the other node as the target (if we go with
> the modified PoDLE which also commits to which node an opening is for, to
> prevent the pouncing venus flytrap attack).
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200213/b925f71c/attachment.html>

2023-06-09 12:58:39 GMT

- reply

📅 Original date posted:2020-02-10
📝 Original message:
> But if you impose the blockheight - 6 in the Lightning protocol level,
and Lightning succeeds (meaning a substantial fraction of blockchain
transactions are Lightning opens)...
> --- then transactions with `nLockTime` equal to the block they are
included in minus 5 will be more common than others, and would be a
reliable indicator that the transaction is a Lightning channel funding
attempt.
Ah good point. This can be mitigated by setting the acceptable range up to
100 then, matching the behavior of bitcoind.
<https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2507-L2544>
On Thu, Feb 6, 2020 at 6:23 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning lisa,
>
> > > I am unsure what is the purpose of this minus 6.
> >
> > The original motivation was to keep the funding transaction from being
> rejected from the mempool in the case of a re-org, but as you pointed out,
> the 'next block' is always at -par or ahead of the current chain tip, so
> I'm not sure this accomplishes this goal. I'm not sure how bitcoind
> handles the mempool in the case of the 'best block' moving to another tip,
> the goal of setting it to -6 is to avoid the funding transaction being
> evicted.
>
> My understanding is that it rewinds the abandoned tip, putting the
> transactions in those blocks back into its local mempool (which may lead to
> evictions if the mempool gets full), all the way to the branch-off point,
> then it re-adds blocks back to the new tip (which can lead to removals from
> the mempool, if transactions in the block spend the same UTXOs (or *are*
> the same transactions) as transactions in the mempool).
> The main effect is that there could be suddenly higher fee pressure for
> the transactions in the reorged-away blocks (because of possible mempool
> congestion if the longer chainsplit has fewer transactions per block), but
> that is why the dual-funding protocol has RBF built-in right?
>
> Setting blockheight - 6 also increases the incentive of potential
> deliberate reorgers to actually perform a reorg attack, because the
> transaction you just added is valid for earlier blocks that the reorger
> wants to rewrite.
> This is a bad thing, because you want your funding txout to be confirmed,
> not have parts of global hashpower contemplating reorgs and delaying your
> confirmations even more.
>
>
> >
> > In practice, setting the locktime back a few blocks makes the funding
> transaction eligible for inclusion in any of the previous six blocks, so in
> case of a reorg there's a higher probability it will have been included in
> the reorganization. In other words, it enables fee-sniping for up to 6
> blocks in the hopes that any 'eligible' re-org includes the funding
> transaction (the short channel id will change, but otherwise the channel
> open will be the same).
> >
> > On second thought, this doesn't seem like something that we should
> include at the protocol level; if a peer wanted to 'allow fee-sniping for
> up to X blocks', then they'd simply relay the "blocktip" that they're using
> for the nLocktime to be at the depth they'd desire. Though it might be
> worth imposing a limit as to how far back in the past a peer can allow
> fee-sniping for... no more than 6 blocks from our current tip seems
> reasonable. (This would then limit the 'acceptable range' for an offset of
> an initiator to 5, as your peer may be off from your tip by one.)
> >
> > On that note, I believe bitcoind fuzzes the nLocktime value to obfuscate
> exactly what blockheight the outgoing transaction was composed / broadcast
> at, which is probably something we should encourage in lightning
> implementations as well.
>
> But if you impose the blockheight - 6 in the Lightning protocol level, and
> Lightning succeeds (meaning a substantial fraction of blockchain
> transactions are Lightning opens) --- then transactions with `nLockTime`
> equal to the block they are included in minus 5 will be more common than
> others, and would be a reliable indicator that the transaction is a
> Lightning channel funding attempt.
> The fuzzing may not be big enough to cover that, as there is a 10% chance
> to fuzz and about 1% subsequent chance (total 0.1% chance) that Bitcoin ore
> will put a transaction at blockheight - 6 (as opposed to the 99 other
> possibilities: blockheight - 0 to blockheight - 99 inclusive).
> So once more than 0.1% of onchain transactions are Lightning
> dual-fundings, an analyst has > 50% chance of correctly betting that a
> blockheight - 5 transaction (yes, - 5, because a transaction can typically
> be added only on the next block) is a Lightning funding.
>
>
> You are better off with blockheight, possibly with SPV-header-chain-proofs
> if one side or the other thinks the blockheight has changed since one side
> or the other proposed it.
>
>
> Regards,
> ZmnSCPxj
>
> >
> > On Wed, Feb 5, 2020 at 8:25 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> >
> > > Good morning niftynei,
> > >
> > > > Rusty had some suggestions about how to improve the protocol
> messages for this, namely adding a serial_id to the inputs and outputs,
> which can then be reused for deletions.
> > > >
> > > > The serial id can then also be used as the ordering heuristic for
> transaction inputs during construction (replacing current usage of BIP69).
> Inputs can be shared amongst peers by flipping the bottom bit of the
> serial_id before relaying them to another peer (as your own).
> > >
> > > What happens if the initiator deliberately provides serial IDs 0x1,
> 0x3, .... while the acceptor naively provides serial IDs from
> `/dev/urandom`?
> > >
> > > Then the balance of probability is that the initiator inputs and
> outputs are sorted before the acceptor.
> > > Now, this is probably not an issue, since the initiator and acceptor
> both know which inputs and outputs are theirs and not theirs, so they could
> just reveal this information to anyone, so an actor providing such lousy
> serial IDs is just hurting its own privacy relative to blockchain analysts,
> so probably will not happen in practice.
> > >
> > > My initial reaction was to propose adding a secret-sharing round where
> the resulting key is XORed to each serial ID before sorting by the XORed
> serial ID, but this might be too overweight, and again the initiator is
> only hurting its own privacy, and the two participants already know whose
> money is whose anyway....
> > >
> > > >
> > > > See below for details.
> > > >
> > > > > 1. type: 440 `tx_add_input`
> > > > >
> > > > > 2. data:
> > > > >
> > > > > * [`32*byte`:`channel_identifier`]
> > > >
> > > > * [`32*byte`:``serial_id`]
> > > >
> > > > Add a serial id.
> > > >
> > > > Each input addition must have a unique serial id.
> > > >
> > > > No addition may have a repeated id number.
> > > >
> > > > The initiator's serial id's must be odd. The non-initiator's serial
> id's must be even.
> > > >
> > > > Serial ids are used as sorting heuristic for input ordering in final
> transaction, replaces BIP69
> > > >
> > > >
> > > > > * [`u64`:`sats`]
> > > > >
> > > > > * [`sha256`:`prevtx_txid`]
> > > > >
> > > > > * [`u32`:`prevtx_vout`]
> > > > >
> > > > > * [`u16`:`prevtx_scriptpubkey_len`]
> > > > >
> > > > > * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
> > > > >
> > > > > * [`u16`:`max_witness_len`]
> > > > >
> > > > > * [`u16`:`scriptlen`]
> > > > >
> > > > > * [`scriptlen*byte`:`script`]
> > > >
> > > > Removes the signal_rbf; everything will be flagged as RBF eligible.
> (This makes verifying RBF eligibility during a RBF round simpler.)
> > >
> > > Yes. Ish.
> > > RBF and privacy do not work well together unfortunately.
> > > This is still initiator-pays, right?
> > >
> > > > > 1. subtype: `witness_element`
> > > > >
> > > > > 2. data:
> > > > >
> > > > > * [`u16`:`len`]
> > > > >
> > > > > * [`len*byte`:`witness`]
> > > > >
> > > > > ## General Notes
> > > > >
> > > > > - All output scripts must be standard
> > > > >
> > > > > - nLocktime is always set to 0x00000000
> > > >
> > > > - If a blockheight to be used as nLocktime is communicated in the
> initiation step, is set to blockheight-6; otherwise set to zero-
> > >
> > > I am unsure what is the purpose of this minus 6.
> > >
> > > If you fear blockheight disagreements, this is probably a good time to
> introduce block headers.
> > > So for example if the acceptor thinks the initiator blockheight is too
> high, it could challenge the initiator to give block headers from its known
> blockheight to the initiator blockheight.
> > > If the acceptor thinks the initiator blockheight is too low, it could
> provide block headers itself as proof.
> > > This could be limited so that gross differences in blockheight are
> outright rejected by the acceptor (it could `error` the temporary channel
> ID rather than accept it).
> > >
> > > This is SPV, but neither side is actually making or accepting a
> payment *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.
> > >
> > > Massive chain reorgs cannot reduce blockheight, only increase it (else
> the reorg attempt fails in the first place) so there must still exist at
> least one chain(split) with the highest known blockheight already given a
> proof-of-header-chain, and all you really need is some mining activity on
> top of *one* split that confirms your funding transaction.
> > >
> > > If it is not because of blockheight disagreements or massive chain
> reorgs, what is the purpose of `blockheight - 6`?
> > >
> > > > - Serial ids should be chosen at random
> > > > - For multiparty constructions, the initiator MUST flip the bottom
> bit of any received inputs before relaying them to a peer.
> > > >
> > > > - Collisions of serial ids between peers is a protocol error
> > >
> > > I suppose we should define collision to mean "equal in all bits except
> the lowest bit".
> > >
> > > Regards,
> > > ZmnSCPxj
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/26f95449/attachment-0001.html>

2023-06-09 12:58:38 GMT

- reply

📅 Original date posted:2020-02-06
📝 Original message:
> I am unsure what is the purpose of this minus 6.
The original motivation was to keep the funding transaction from being
rejected from the mempool in the case of a re-org, but as you pointed out,
the 'next block' is always at -par or ahead of the current chain tip, so
I'm not sure this accomplishes this goal. I'm not sure how bitcoind
handles the mempool in the case of the 'best block' moving to another tip,
the goal of setting it to -6 is to avoid the funding transaction being
evicted.
In practice, setting the locktime back a few blocks makes the funding
transaction eligible for inclusion in any of the previous six blocks, so in
case of a reorg there's a higher probability it will have been included in
the reorganization. In other words, it enables fee-sniping for up to 6
blocks in the hopes that any 'eligible' re-org includes the funding
transaction (the short channel id will change, but otherwise the channel
open will be the same).
On second thought, this doesn't seem like something that we should include
at the protocol level; if a peer wanted to 'allow fee-sniping for up to X
blocks', then they'd simply relay the "blocktip" that they're using for the
nLocktime to be at the depth they'd desire. Though it might be worth
imposing a limit as to how far back in the past a peer can allow
fee-sniping for... no more than 6 blocks from our current tip seems
reasonable. (This would then limit the 'acceptable range' for an offset of
an initiator to 5, as your peer may be off from your tip by one.)
On that note, I believe bitcoind fuzzes the nLocktime value to obfuscate
exactly what blockheight the outgoing transaction was composed / broadcast
at, which is probably something we should encourage in lightning
implementations as well.
On Wed, Feb 5, 2020 at 8:25 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning niftynei,
>
>
> > Rusty had some suggestions about how to improve the protocol messages
> for this, namely adding a serial_id to the inputs and outputs, which can
> then be reused for deletions.
> >
> > The serial id can then also be used as the ordering heuristic for
> transaction inputs during construction (replacing current usage of BIP69).
> Inputs can be shared amongst peers by flipping the bottom bit of the
> serial_id before relaying them to another peer (as your own).
>
> What happens if the initiator deliberately provides serial IDs 0x1, 0x3,
> .... while the acceptor naively provides serial IDs from `/dev/urandom`?
>
> Then the balance of probability is that the initiator inputs and outputs
> are sorted before the acceptor.
> Now, this is probably not an issue, since the initiator and acceptor both
> know which inputs and outputs are theirs and not theirs, so they could just
> reveal this information to anyone, so an actor providing such lousy serial
> IDs is just hurting its own privacy relative to blockchain analysts, so
> probably will not happen in practice.
>
> My initial reaction was to propose adding a secret-sharing round where the
> resulting key is XORed to each serial ID before sorting by the XORed serial
> ID, but this might be too overweight, and again the initiator is only
> hurting its own privacy, and the two participants already know whose money
> is whose anyway....
>
> >
> > See below for details.
> >
> > > 1. type: 440 `tx_add_input`
> > >
> > > 2. data:
> > >
> > > * [`32*byte`:`channel_identifier`]
> >
> > * [`32*byte`:``serial_id`]
> >
> > Add a serial id.
> >
> > Each input addition must have a unique serial id.
> >
> > No addition may have a repeated id number.
> >
> > The initiator's serial id's must be odd. The non-initiator's serial id's
> must be even.
> >
> > Serial ids are used as sorting heuristic for input ordering in final
> transaction, replaces BIP69
> >
> >
> > > * [`u64`:`sats`]
> > >
> > > * [`sha256`:`prevtx_txid`]
> > >
> > > * [`u32`:`prevtx_vout`]
> > >
> > > * [`u16`:`prevtx_scriptpubkey_len`]
> > >
> > > * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
> > >
> > > * [`u16`:`max_witness_len`]
> > >
> > > * [`u16`:`scriptlen`]
> > >
> > > * [`scriptlen*byte`:`script`]
> >
> > Removes the signal_rbf; everything will be flagged as RBF eligible.
> (This makes verifying RBF eligibility during a RBF round simpler.)
>
> Yes. Ish.
> RBF and privacy do not work well together unfortunately.
> This is still initiator-pays, right?
>
>
> > > 1. subtype: `witness_element`
> > >
> > > 2. data:
> > >
> > > * [`u16`:`len`]
> > >
> > > * [`len*byte`:`witness`]
> > >
> > > ## General Notes
> > >
> > > - All output scripts must be standard
> > >
> > > - nLocktime is always set to 0x00000000
> >
> > - If a blockheight to be used as nLocktime is communicated in the
> initiation step, is set to blockheight-6; otherwise set to zero-
>
> I am unsure what is the purpose of this minus 6.
>
> If you fear blockheight disagreements, this is probably a good time to
> introduce block headers.
> So for example if the acceptor thinks the initiator blockheight is too
> high, it could challenge the initiator to give block headers from its known
> blockheight to the initiator blockheight.
> If the acceptor thinks the initiator blockheight is too low, it could
> provide block headers itself as proof.
> This could be limited so that gross differences in blockheight are
> outright rejected by the acceptor (it could `error` the temporary channel
> ID rather than accept it).
>
> This is SPV, but neither side is actually making or accepting a payment
> *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.
>
> Massive chain reorgs cannot reduce blockheight, only increase it (else the
> reorg attempt fails in the first place) so there must still exist at least
> one chain(split) with the highest known blockheight already given a
> proof-of-header-chain, and all you really need is some mining activity on
> top of *one* split that confirms your funding transaction.
>
> If it is not because of blockheight disagreements or massive chain reorgs,
> what is the purpose of `blockheight - 6`?
>
>
>
> > - Serial ids should be chosen at random
> > - For multiparty constructions, the initiator MUST flip the bottom bit
> of any received inputs before relaying them to a peer.
> >
> > - Collisions of serial ids between peers is a protocol error
>
> I suppose we should define collision to mean "equal in all bits except the
> lowest bit".
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200206/f7cc9d4e/attachment-0001.html>

2023-06-09 12:58:37 GMT

- reply

📅 Original date posted:2020-02-04
📝 Original message:
Rusty had some suggestions about how to improve the protocol messages for
this, namely adding a serial_id to the inputs and outputs, which can then
be reused for deletions.
The serial id can then also be used as the ordering heuristic for
transaction inputs during construction (replacing current usage of BIP69).
Inputs can be shared amongst peers by flipping the bottom bit of the
serial_id before relaying them to another peer (as your own).
See below for details.
1. type: 440 `tx_add_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`32*byte`:``serial_id`]
Add a serial id.
Each input addition must have a unique serial id.
No addition may have a repeated id number.
The initiator's serial id's must be odd. The non-initiator's serial id's
must be even.
Serial ids are used as sorting heuristic for input ordering in final
transaction, replaces BIP69
* [`u64`:`sats`]
>
> * [`sha256`:`prevtx_txid`]
>
> * [`u32`:`prevtx_vout`]
>
> * [`u16`:`prevtx_scriptpubkey_len`]
>
> * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
>
> * [`u16`:`max_witness_len`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> Removes the signal_rbf; everything will be flagged as RBF eligible. (This
makes verifying RBF eligibility during a RBF round simpler.)
> 1. type: 442 `tx_add_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id`]
Add a serial id. Same rules as for inputs, but a distinct counter set is
used.
Used for ordering the transactions’ outputs, replacing BIP69
> * [`u64`:`sats`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> 1. type: 444 `tx_remove_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id`]
Input to remove identified by the serial id, not txid and index.
>
> 1. type: 446 `tx_remove_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id]
Output to remove identified by the serial id, not output script and amount.
> 1. type: 448 `tx_complete`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
Total counts removed from tx_complete. The txid exchanged in the `tx_sigs`
will serves as a checksum for the transaction.
> 1. type: 448 `tx_sigs`
>
> 2. data:
>
> * [`channel_id`:`channel_identifier`]
>
> * [`u16`:`num_witnesses`]
>
> * [`num_witnesses*witness_stack`:`witness_stack`]
>
> 1. subtype: `witness_stack`
>
> 2. data:
>
* [`u16`:`num_input_witness`]
>
> * [`num_input_witness*witness_element`:`witness_element`]
>
prev_out and prev_txid are removed; witnesses ordered implicitly by
serial_id.
> 1. subtype: `witness_element`
>
> 2. data:
>
> * [`u16`:`len`]
>
> * [`len*byte`:`witness`]
>
>
>
> ## General Notes
>
> - All output scripts must be standard
>
> - nLocktime is always set to 0x00000000
>
- If a blockheight to be used as nLocktime is communicated in the
initiation step, is set to blockheight-6; otherwise set to zero-
- Serial ids should be chosen at random
- For multiparty constructions, the initiator MUST flip the bottom bit of
any received inputs before relaying them to a peer.
- Collisions of serial ids between peers is a protocol error
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/d6136e56/attachment-0001.html>

2023-06-09 12:58:24 GMT

- reply

📅 Original date posted:2020-01-30
📝 Original message:
hi max — great question. PSBT is a great protocol for wallet interop but a
bit overweight for tx collaboration between two peers
On Wed, Jan 29, 2020 at 17:29 Max Dignan <maxdignan at gmail.com> wrote:
> Hey Antoine,
>
> Would PSBT (BIP 174 -
> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) be a good
> solution to this?
>
> -Max
> _______________________________________________
> 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/20200129/c9d358a8/attachment.html>

2023-06-09 12:58:18 GMT

- reply

📅 Original date posted:2020-01-27
📝 Original message:
Some of the feedback I received from the check-in for the dual-funding
proposal this past Monday was along the lines that we look at simplifying
for breaking it into smaller, more manageable chunks.
The biggest piece of the dual-funding protocol update is definitely the
move from a single peer constructing a transaction to two participants.
We're also going to likely want to reuse this portion of the protocol for
batched closings and splicing. To that extent, it seemed useful to
highlight it in a separate email.
This is a change from the existing proposal in the dual-funding PR #524
<https://github.com/lightningnetwork/lightning-rfc/pull/524> -- it allows
for the removal of inputs and outputs.
The set of messages are as follows.
Note that the 'initiation' of this protocol will be different depending on
the case of the transaction (open, close or splice):
1. type: 440 `tx_add_input`
2. data:
* [`32*byte`:`channel_identifier`]
* [`u64`:`sats`]
* [`sha256`:`prevtx_txid`]
* [`u32`:`prevtx_vout`]
* [`u16`:`prevtx_scriptpubkey_len`]
* [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
* [`u16`:`max_witness_len`]
* [`u16`:`scriptlen`]
* [`scriptlen*byte`:`script`]
* [`byte`:`signal_rbf`]
1. type: 442 `tx_add_output`
2. data:
* [`32*byte`:`channel_identifier`]
* [`u64`:`sats`]
* [`u16`:`scriptlen`]
* [`scriptlen*byte`:`script`]
1. type: 444 `tx_remove_input`
2. data:
* [`32*byte`:`channel_identifier`]
* [`sha256`:`prevtx_txid`]
* [`u32`:`prevtx_vout`]
1. type: 446 `tx_remove_output`
2. data:
* [`32*byte`:`channel_identifier`]
* [`u64`:`sats`]
* [`u16`:`scriptlen`]
* [`scriptlen*byte`:`script`]
1. type: 448 `tx_complete`
2. data:
* [`32*byte`:`channel_identifier`]
* [`u16`:`num_inputs`]
* [`u16`:`num_outputs`]
1. type: 448 `tx_sigs`
2. data:
* [`channel_id`:`channel_identifier`]
* [`u16`:`num_witnesses`]
* [`num_witnesses*witness_stack`:`witness_stack`]
1. subtype: `witness_stack`
2. data:
* [`sha256`:`prevtx_txid`]
* [`u32`:`prevtx_vout`]
* [`u16`:`num_input_witness`]
* [`num_input_witness*witness_element`:`witness_element`]
1. subtype: `witness_element`
2. data:
* [`u16`:`len`]
* [`len*byte`:`witness`]
## General Notes
- Validity of inputs/outputs is not checked until both peers have sent
consecutive `tx_complete` messages.
- Duplicate inputs or outputs is a protocol error.
- Feerate is set by the initiator, or in the case of a closing transaction,
negotiated before the transaction construction is initiated.
- Every peer pays fees for the inputs + outputs they contribute, plus
enough to cover the maximum estimate of their witnesses. Overpayment of
fees is permissible.
- Initiator is responsible for contributing the output/input in question,
i.e. the
funding output in the case of an opening, or the funding input in the
case of a close.
(This means that the opener will pay for the opening output). In the case
of a splice,
the initiator of the splice pays for the funding tx's inclusion as an
input and the
new 'funding tx' output.
- Any contributor may signal that their input is RBF'able. The nSequence
for this input should be set to 0xFEFF FFFF, 0xFFFFFFFF otherwise.
- The initiating peer is understood to be paying the fee for the shared
transaction fields (nVersion [4], segwit marker + flag [2], input + output
counts [2-18], witness count [1-9], nLocktime [4]; total [13-40bytes])
- Inputs MUST be segwit compatible (PW* or P2SH-PW*)
- All output scripts must be standard
- nLocktime is always set to 0x00000000.
- The `num_inputs` and `num_outputs` in `tx_complete` is a count of that
peer’s final input and output contributions, net any removals.
- Either peer may add or remove inputs and outputs until both peers have
successfully
exchanged a `tx_complete` message in succession.
- Either peer may only add or remove their own input or output.
- In the case that a `tx_complete` agreement cannot be reached, either peer
may
fail the channel or open protocol (whatever is reasonable for the
particular case)
- In the case of a splice, this would be a soft error (channel returns to
normal operation until
otherwise failed or closed.)
- In the case of an open, this would be a failure to open the channel.
- In the case of a close, a failed collaborative close would result in an
error and a unilateral close.
### Considering the Simple Open case (2 parties)
- Both peers signal `opt_dual_fund`
- Opener initiates a channel open with `open_channel2` message, indicating
the feerate for the opening transaction
- Accepter signals acceptance of channel open as proposed, including
proposed feerate, via `accept_channel2`
- Opener sends `tx_add_output`, with the funding output for the sum of both
peer’s funding_amount
- Opener sends `tx_add_input` for each input the wish to add to the funding
transaction
- Opener sends `tx_add_output` for their change
- Opener sends `tx_complete`
- Accepter sends `tx_add_input` for each input they wish to add to the
funding transaction
- Accepter sends `tx_add_output` for their change.
- Accepter sends `tx_complete`
- Opener sends `tx_complete`
- Opener and accepter exchange commitment signatures; etc.
### Considering the Splice case:
- Both peers signal `opt_splice_ok`
- One peer initiates a splice, also signaling the feerate for the
transaction. Exact protocol unspecified herein.
- Initiator sends `tx_add_input` with the original funding output
- Initiator sends `tx_add_output` with the new, post-splice funding output
- Initiator sends `tx_add_input/output` as needed to add all desired inputs
+ outputs
- Initiator sends `tx_complete`
- Peer sends `tx_add_input/output` as needed to add all desired inputs +
outputs
- Initiator sends `tx_complete`
- Peer sends `tx_complete`
- Initiator + peer exchange commitment signatures, etc.
### Considering the Close case:
- Both peers signal `opt_collaborative_close` in their `node_announcement`.
- A peer initiates a close sending a `shutdown`, as per usual.
- A feerate is negotiated. Out of band for this particular portion of the
protocol.
-The closing initiator (peer which first sent `shutdown`), sends
`tx_add_input` to spend the funding output and `tx_add_output` to add their
output for the channel closure.
- The peer responds with `tx_add_output`, adding their output to the close
transaction.
- If `option_upfront_shutdown_script` is flagged but no such output with a
value at or within a reasonable feerate gap of the peer's funding output is
present, then the peer must fail the channel.
## Updating a collaborative transaction with RBF:
- If any input is flagged as RBF’able, then the transaction is considered
eligible for RBF
- RBF can be initiated by either party, and serves as an initiation for
another round of transaction composition, as outlined above.
- Note that this section has been cribbed and re-purposed from the original
RBF proposal for splicing, see
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001621.html
1. type: 45 (`init_rbf`) (`option_collaborative_rbf`)
2. data:
* [`32`:`channel_id`]
* [`4`:`fee_step`]
Each `fee_step` adds 1/4 (rounded down) to the initial
transaction feerate. eg. if the initial feerate was 512 satoshis per
kiloweight, `fee_step` 1
is 512 + 512 / 4 = 640, `fee_step` 2 is 640 + 640 / 4 = 800.
The sender:
- MUST set `fee_step` greater than zero and greater than any prior
`fee_step`.
The recipient:
- if the new fee exceeds the sender's current balance minus reserve
after it is applied to the splice transaction:
- MUST error.
NOTES:
1. 1/4 is a reasonable minimal RBF, but as each one requires more
tracking by the recipient, serves to limit the number you can create.
2. Rule 4 of BIP125 requires a feerate increase to at least surpass the
minimum transaction relay setting. Ratcheting by 25% should satisfy this
requirement
3. An additional rule will be added to the checks of an RBF transaction
that it must include at least one identical, replaceable input as the
original transaction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200127/ca2e504d/attachment-0001.html>

2023-06-09 12:57:12 GMT

- reply

📅 Original date posted:2019-11-07
📝 Original message:
> Imagine the following setup: a network of nodes that trust each other
The goal of this pre-payment proposal is to remove the need for trusted
parties.
On Thu, Nov 7, 2019 at 07:38 Joost Jager <joost.jager at gmail.com> wrote:
> > Isn't spam something that can also be addressed by using rate limits for
>> > failures? If all relevant nodes on the network employ rate limits, they
>> can
>> > isolate the spammer and diminish their disruptive abilities.
>>
>> Sure, once the spammer has jammed up the network, he'll be stopped. So
>> will everyone else. Conner had a proposal like this which didn't work,
>> IIRC.
>>
>
> Do you have ref to this proposal?
>
> Imagine the following setup: a network of nodes that trust each other (as
> far as spam is concerned) applies a 100 htlc/sec rate limit to the channels
> between themselves. Channels to untrusted nodes get a rate of only 1
> htlc/sec. Assuming the spammer isn't a trusted node, they can only spam at
> 1 htlc/s and won't jam up the network?
> _______________________________________________
> 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/20191107/70d3266f/attachment.html>

2023-06-09 12:54:35 GMT

- reply

📅 Original date posted:2019-03-15
📝 Original message:
Hello Rene,
This is a legitimate concern. Thank you for raising it.
I have three suggestions for how to mitigate this. The first is to return a
non-specific error message which, while in the aggregate might be used to
approximate a nodes’ uncommitted balance, would at least offer plausible
deniability to the exact cause for the failure.
The second proposal is in a similar vein. A node might add a privately held
randomization vector, which would return an error to any open channel
request with probability p. Thus an attacker wishing to ascertain a nodes
balance would not know with any certainty if the request they sent failed
because of a lack of available liquidity or for some other non-related
reason.
Finally, and perhaps most compellingly, rather than return an error, the
open channel should always succeed, but for any value at or below the
requested liquidity amount. The opening channel balance agreed upon between
the two nodes would then be adjusted to reflect the “correct” amount of
push_msat for the actual amount of funding_satoshi contributed by the
accepter (i.e. zero if the accepter node sends accept_channel2 with a
funding_satoshi balance of zero). If the amount of liquidity offered up by
the accepter is unacceptable to the opener, then they may choose to fail
the channel opening negotiation.
This third proposal, combined with a randomization vector (i.e with
probability p you always offer an amount less than the proposed amount)
would remove some of the certainty around a nodes unconfirmed balance. As
with channel balances, however, there is always the possibility of a
probabilistic attack i.e. lots of open channel requests sent over a short
period of time that would give an attacker a reasonable approximation of
your nodes available balance. A node could mitigate this by including an
exponential backoff for open channel requests from any one node,
essentially rate limiting the number of open channel requests that it will
accept from a single peer, or peers globally.
A node may also choose to set a policy around what it considers reasonable
liquidity requests from a peer (i.e. no more than 0.05 BTC from any peer),
which would further limit their exposure on the upper end of information
gathering.
Finally, as this liquidity feature is optional, any node who is truly
interested in preserving the privacy of their funds may continue to
establish channels the old fashioned way, i.e. via out of band negotiation
with other, trusted node operators.
Cheers,
Lisa
On Fri, Mar 15, 2019 at 08:29 René Pickhardt via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hey everyone,
>
> during the spec meeting we have discussed intensively about dual funded
> channels and potential game theory with the fees however I now believe that
> we missed out another important crucial part which is the privacy of the
> node providing liquidity.
>
> While I have not seen a concrete example for a channel establishment
> protocol that supports dual funded channels I have seen this proposal (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html
> ) for advertising channel liquidity which assumed that the `open_channel`
> message would be modified as follows:
>
> `open_channel`:
> new feature flag (channel_flags): option_liquidity_buy [2nd least
> significant bit]
> push_msat: set to fee payment for requested liquidity
> [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding
> requested at channel open
>
> ...
>
> If a node cannot provide the liquidity requested in `open_channel`, it must
> return an error.
>
> With such a protocol I could now (basically only at the cost of internet
> traffic) probe a lower bound for the amount of BTC available by a node that
> allows for dual funded channels and abort the channel establishing process
> at some time before I ever spend / lock any of my own bitcoin.
>
> As I can even participate in the peer protocol without having a single
> channel open this situation seems to be even more severe.
>
> I don't have a clear suggestion how to mitigate against this. One general
> potential idea / solution would be to make spamming / probing more
> expensive. For example we could require the person to open a channel first
> and then ask the partner to splice something in (meaning we don't allow for
> one tx dual funded channels). In that case the node requesting liquidity
> had to do an onchain tx. also the requests to splice in can be identified
> and the person who feels to be probed can choose to fail the channel. I am
> not happy with my barrier as it would still be able to relatively cheaply
> abuse this and we run into a whole bunch of game theory about fees again.
>
> As the lightning network seems very keen to provide strong privacy to its
> users (c.f.: onion routing, keeping channel balances private, encrypted
> transport layer,...) I thought it is worthwhile pointing out the problem
> with the privacy for dual funded channels even though I don't have a
> concrete solution yet.
>
> 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/20190315/29fea470/attachment-0001.html>

2023-06-09 12:53:17 GMT

- reply

📅 Original date posted:2018-12-03
📝 Original message:
>
>
> > +----+ +----+
> > where node A is the ‘initiator’ and node B is the ‘dual-funder’
>
> We currently use the terms funder and fundee, which are now
> inaccurate ofc. Perhaps 'opener' and 'accepter' are not great english,
> but they map to the messages well?
>
'opener' and 'accepter' do map to the messages. I've adopted it for the
rest of this response, to see how it fits in context.
"Another subtle point is the feerate_per_kw field; in the old scheme it
applied to the first commitment tx, but here it applies to both the
first commitment tx and the funding tx itself"
You're right. Initially I didn't think the `accepter` would care since
they're not paying them,
but you need it to be able to construct the funding transaction. I'll add a
second field, it seems
important to keep them separated esp since the timing consideration for the
fees is different (now vs the future).
> The sending node:
> > -
> > MAY begin channel establishment using `open_channel2`
>
> - MUST NOT send `open_channel`.
>
> > Otherwise the receiving node:
> > -
> > MUST return an error.
>
> This is a requirement for receiving `open_channel` IIUC?
>
> ie.
>
> The receiving node MUST fail the channel if:
> ...
> - `option_dual_fund` has been negotiated.
>
Does v2 of channel open necessarily deprecate the original between two
upgraded nodes?
This seems more sane than having both as an option...will update.
>
> > ____`funding_puts2`
>
> We can probably drop the 2 here and call it, um.. `funding_compose`?
> (Thanks thesaurus.com). I get where you're going with 'puts, but it
> took me a while :)
Initially only the duplicated messages had the 2-suffix, but ended up
adding it to all of them to denote that they belonged to the v2 of channel
open... I can see how that's confusing though.
+1 for `funding_compose`, it's definitely more easily understood. :-D
...
> > MUST NOT send a number of `input_data` and/or `output_data` which
> > exceeds the `put_limit`
>
> Side note: I wonder if we should relax this limit when we talk about
> `option_will_fund_for_food`?
>
Yes! Thanks for pointing this out.
>
> > -
> > MAY send an empty message
>
> Be explicit? MAY offer zero `num_inputs` and `num_outputs`. That's not
> quite an empty message...
>
I defined it a few lines above, but that's not super easy to see from this.
Will fix.
>
> > The receiving node:
> >
> > If is the initiator (A):
> >
> > -
> > MUST fail the channel if the `num_inputs` plus `num_outputs` is
> greater
> > than the `put_limit`
>
> How about MAY? It's a protection thing, but less to change when we
> option_will_fund_for_food. Unless we set the `put_limit` to min (4) or
> something in that case?
>
+1 for MAY, considering that the opener will be paying the fees.
The limit for what's reasonable to pay is fairly subjective, i.e. perhaps
the opener doesn't
care how many inputs/outputs the acceptor adds.
>
> Oh, it needs to check max_extra_witness_len is reasonable too, since
> that will affect the fees. Each signature adds 74, and pubkey adds 34,
> so I think MUST BE less than 500 is perfectly reasonable (for both
> reader and writer).
>
Ack
> > ___`funding_locked2`
> >
> > // same as v1
> >
> > Requirements:
> >
> > A dual-funding node (B):
> >
> > -
> >
> > SHOULD broadcast their funding transaction if it does not see the
> > transaction broadcast after a reasonable timeout.
>
> Let's just reuse `funding_locked` maybe?
>
> Not sure why this should wait for broadcast?
>
I was overthinking this*. Can't think of a reason for both sides not to
broadcast; will amend.
* confused it with conflicting transaction broadcast behavior
> > == RBF for Channel Establishment v2
> >
> > _____`init_rbf`
> >
> > This message is sent by the initiator, after the funding transaction has
> > been broadcast but before the `funding_locked2` has been exchanged.
> >
> > [32: `channel_id`]
> > [8: funding_satoshis]
> > [8:dust_limit_satoshis]
> > [8:channel_reserve_satoshis]
> > [4: feerate_per_kw]
> > [`2`:`num_inputs`]
> > [`num_inputs*input_info`]
> > [`2`:`num_outputs`]
> > [`num_outputs`*ouput_info`]
>
> Typo again :)
>
> > Requirements
> >
> > The sending node:
> > - MUST be the initiator (A)
> > - MAY update the amount, fee rate, dust limit, or channel reserve for
> the
> > channel
>
> - MAY send init_rbf if it considers the most recent funding tx unlikely
> to be confirmed in reasonable time.
> - MUST set `feerate_per_kw` larger than the most recent funding tx.
>
Another good reason to break out `funding_txn_feerate_per_kw` from
`commitment_txn_feerate_per_kw` in `open_channel2`
>
> Do we really want to negotiate everything again? It seems like the
> funder should be able to maybe add *new* inputs and outputs (though TBH
> I think that's going to be unusual enough that we could omit it), but
> doing a wholesale replacement means we have to be careful that the all
> RBFs end up having at least one input in common. Yech.
>
Only allowing the opener to add new inputs/outputs drives down the scope of
a RBF a good deal. I like it.
Adding new inputs seems like a common sense bare minimum, especially if we
assume wildly unpredictable fee rates.
> >
> > Rationale:
> >
> > Once an `init_rbf` has been accepted by the dual-funding node, the
> message
> > flow returns to `commitment_signed2` and proceeds as above, with the
> > exception that the `temporary_channel_id` remains as the `channel_id` for
> > the currently published but unmined transaction.
>
> By this stage, we are no longer using temporary_channel_id though.
>
> But it's an excellent point I had missed. The channel_id changes on
> each renegotiation. We could either switch channel_id *after*
> each accept_rbf, or keep the original channel_id until funding_locked2 (in
> which case it should have a "final_channel_id" field, to make sure we're
> talking about the same funding tx).
>
> Since we have to handle the "oops, old one got in!" it might be weird to
> see `funding_locked2` with an old txid. Perhaps we stick with the
> original channel_id until then, and flip *after* funding_locked2 is sent
> and received.
>
>
Would it be more sane to continue to include the temporary channel id,
in addition to the 'current' (i.e. most recently negotiated funding txn)
channel id,
until the funding_locked2 is sent (adds a `temporary_channel_id` field for
`commitment_signed2`, ` funding_signed2` and `funding_locked2`, in addition
to `channel_id`)?
That way, all opening messages would have a stable id across an RBF
re-negotiation, `temp_channel_id`.
Sticking with the first broadcast funding transaction hash feels
a bit misleading in the case of a second round of `commitment_signed2` and
`funding_signed2`.
> And yeah, no `update_fee`, `announcement_signatures` until that
> funding_locked2 exchange is complete, so we don't get those with an
> unsettled channel_id.
>
> > The channel id that becomes fixed for this node will be determined by the
> > `funding_locked2` message.
> >
> > ___`accept_rbf`
> >
> > This message accepts an RBF request, and renegotiates a dual-funder’s
> > funds, dust limit, and channel reserve, and sends the dual-funder’s
> updated
> > puts.
>
> I would make this an empty message, simply an ack. And note that
> the channel_id after this is that of the RBFed tx.
>
> The question then becomes what do we do about reconnection. I suggest:
>
> opener: if we haven't sent funding_signed, consider it cancelled. If
> we've received funding_signed, it's obviously locked in. If we sent
> and didn't received, re-xmit.
>
> accepter: must remember rbf if we sent commitment_signed2. If we
> received funding_signed it's locked in. If we receive an init_rbf,
> drop the one we remembered. If we receive funding_signed, continue.
>
> We still need to address the funding_tx construction; BIP69-style seems
> like an unnecessary information leak here. A 128-bit seed in
> open_channel2 could be added, with sorting by SHA(seed | <marshal of
> input> | <marshal of witness>) and SHA(seed | <marshal of output>)?
>
> Phew!
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181203/4ac6a8cb/attachment.html>

2023-06-09 12:53:10 GMT

- reply

📅 Original date posted:2018-11-27
📝 Original message:
Hello fellow Lightning devs!
What follows is a draft for the new dual funding flow. Note that the
`option_will_fund_for_food` specification has been omitted for this draft.
===== Proposal
Create a new channel open protocol set (v2), with three new message types:
`funding_puts2`, `commitment_signed2`, and `funding_signed2`, plus two for
negotiating RBF, `init_rbf` and `accept_rbf`.
Quick overview of the message exchange for v2:
+-------+ +-------+
| |--(1)--- open_channel2 ---->| |
| |<-(2)-- accept_channel2 ----| |
| | | |
| |--(3)-- funding_puts2 ----->| |
| |<-(4)-- funding_puts2 ----- | |
| | | |
--->| |--(5)-- commitment_signed2 -->| |
| | |<-(6)-- commitment_signed2 ---| |
| | A | | B |
| | |--(7)--- funding_signed2 ---->| |
| | |<-(8)--- funding_signed2 -----| |
| | | | |
| | |--(a)--- init_rbf ----------->| |
----| |<-(b)--- accept_rbf ----------| |
| | | |
| |--(9)--- funding_locked2 ---->| |
| |<-(10)---funding_locked2 -----| |
+-------+ +-------+
where node A is the ‘initiator’ and node B is the ‘dual-funder’
== Negotiating the use of dual_funding (open_channel2) flow
Willingness to use v2 is flagged in init via `option_dual_fund`.
`init`
local channel feature flag, `option_dual_fund`
== Channel establishment with dual_funding
____`open_channel2`:
[32:chain_hash]
… // unchanged
[1:channel_flags]
[?: options_tlv]
options_tlv:
1.
Type: 1 `option_upfront_shutdown_script`
1.
[2:len]
2.
Value: `shutdown_scriptpubkey`
If nodes have negotiated `option_dual_fund`
The sending node:
-
MAY begin channel establishment using `open_channel2`
Otherwise the receiving node:
-
MUST return an error.
____ `accept_channel2`:
[32:temporary_channel_id]
… // unchanged
[33:first_per_commitment_point]
[?: options_tlv]
options_tlv:
1.
Type: 1 `option_upfront_shutdown_script`
[2:len]
Value: `shutdown_scriptpubkey`
____`funding_puts2`
This message exchanges the input and output information necessary to
compose the funding transaction.
[32:temporary_channel_id]
[`2`:`num_inputs`]
[`num_inputs*input_info`]
[`2`:`num_outputs`]
[`num_outputs`*ouput_info`]
1. subtype: `input_info`
2. data:
* [`8`:`satoshis`]
* [`32`:`prevtxid`]
* [`4`:`prevtxoutnum`]
* [`2`:`scriptlen`]
* [`scriptlen`:`script`]
* [`2`:`max_extra_witness_len`]
* [`2`:`wscriptlen`]
* [`wscriptlen`:`wscript`]
1. subtype: `output_info`
2. data:
* [`8`:`satoshis`]
* [`2`:`scriptlen`]
* [`scriptlen`:`script`]
Requirements:
The sending node:
-
MUST ensure each `input_info` refers to an existing UTXO
-
MUST ensure the `output_info`.`script` is a standard script
-
MUST NOT spend any UTXOs specified in funding_puts2 until/unless the
channel establishment has failed
If is the initiator (A):
- MUST NOT send an empty message (`num_inputs` + `num_outputs` = 0)
If is the dual-funder (B):
-
consider the `put_limit` the total number of `num_inputs` plus
`num_outputs` from `funding_puts2`, with minimum 2.
-
MUST NOT send a number of `input_data` and/or `output_data` which
exceeds the `put_limit`
-
MAY send an empty message
The receiving node:
If is the initiator (A):
-
MUST fail the channel if the `num_inputs` plus `num_outputs` is greater
than the `put_limit`
If has not yet sent a `fund_puts2` for this channel establishment
- SHOULD send their `fund_puts2` message
Otherwise
-
SHOULD send `commitment_signed2`
Rationale:
Each node must have a complete set of the transaction inputs/outputs, to
derive the funding transaction hash.
There is a dual_funding protocol that only requires one side to send their
witness data and inputs. This is more efficient, however it results in
asymmetry between the nodes, where one is revealing their UTXOs before the
funding transaction is committed.. We mitigate this asymmetry by asking the
initiator (A) to send their set of inputs before the dual-funder (B) does.
NB: This is reusing the input/output structures from the Splicing proposal,
but with a more generalized name.
____`commitment_signed2`
This message exchanges the counterparty’s signature for the first
commitment transaction, so it can broadcast the funding transaction knowing
that funds can be redeemed.
[32: `channel_id`]
[`64`: commitment_signature`]
Requirements:
The sending node:
-
MUST derive the `channel_id` from the funding transaction’s id
-
MUST set signature to the valid signature, using its funding_pubkey for
the initial commitment transaction, as defined in BOLT #3
If it has not received a `funding_puts2`
-
MUST NOT send their `commitment_signature`
The receiving node:
-
MUST verify the commitment signature is valid for the funding
transaction -> commitment transaction that it has derived independently
If this signature is invalid it
-
MUST fail the channel
If it has not sent a `commitment_signed2` message
-
MUST send their `commitment_signed2` message
If this is in a flow initiated from `init_rbf`,:
-
MUST save the temporary_channel_id until the channel funding transaction
has been locked (this is the channel id of the currently broadcast
transaction)
Rationale:
In the previous channel establishment protocol, we were able to compress
the commitment signature exchange into `funding_created`/`funding_signed`.
With dual funding, we need interaction to build the funding transaction --
commitment sig exchange is now a separate step.
___`funding_signed2`
This message exchanges the witness data for the inputs that were originally
sent in the `funding_puts2` message.
[`32`:`channel_id`]
[`2`:`num_witnesses`]
[`num_witnesses*witness_stack`]
Requirements:
The sending node:
- MUST remember the details of this funding transaction
- MUST NOT send a `witness_stack` whose length exceeds the corresponding
`max_extra_witness_len`
If they have NOT received a valid `commitment_signed2` message
-
MUST not send their `funding_signed2` message
The receiving node:
-
SHOULD check that the number of witnesses sent matches the number of
inputs
If a `witness_stack` length exceeds the corresponding
`max_extra_witness_len`:
-
MAY error.
If is the `initiator` (A):
-
SHOULD apply `witness` to the funding transaction and broadcast the
result.
Rationale:
Exchanging witness data allows either side to broadcast the funding
transaction. It also maintains the information symmetry between the nodes.
___`funding_locked2`
// same as v1
Requirements:
A dual-funding node (B):
-
SHOULD broadcast their funding transaction if it does not see the
transaction broadcast after a reasonable timeout.
== RBF for Channel Establishment v2
_____`init_rbf`
This message is sent by the initiator, after the funding transaction has
been broadcast but before the `funding_locked2` has been exchanged.
[32: `channel_id`]
[8: funding_satoshis]
[8:dust_limit_satoshis]
[8:channel_reserve_satoshis]
[4: feerate_per_kw]
[`2`:`num_inputs`]
[`num_inputs*input_info`]
[`2`:`num_outputs`]
[`num_outputs`*ouput_info`]
Requirements
The sending node:
-
MUST be the initiator (A)
-
MAY update the amount, fee rate, dust limit, or channel reserve for the
channel
The receiving node:
-
MAY reject (error) the RBF request if:
-
the fee rate, dust, or channel reserve is unreasonable
-
MUST reject (error) the RBF request if:
-
the `fee_rate` is less than the rate that was originally proposed
-
the `funding_satoshis` amount is less than the previous negotiated
`push_mast`
-
It considers the `feerate_per_kw` too small for timely processing or
unreasonable
-
the `dust_limit_satoshis` is greater than the
`channel_reserve_satoshis`
-
the initiator’s amount for the initial commitment transaction is not
sufficient for full fee payment
-
the `inputs`.`satoshis` does not sum to the `funding_satoshis`
-
the `funding_satoshis` is insufficient to create the transaction at
the new `fee_rate`
-
there is no overlap in the proposed inputs and the original input set
included in the currently published funding transaction
-
they have already received or sent a `funding_locked2` message
-
If there are no errors or unreasonable demands:
-
SHOULD send an `accept_rbf`
Rationale:
Once an `init_rbf` has been accepted by the dual-funding node, the message
flow returns to `commitment_signed2` and proceeds as above, with the
exception that the `temporary_channel_id` remains as the `channel_id` for
the currently published but unmined transaction.
The channel id that becomes fixed for this node will be determined by the
`funding_locked2` message.
___`accept_rbf`
This message accepts an RBF request, and renegotiates a dual-funder’s
funds, dust limit, and channel reserve, and sends the dual-funder’s updated
puts.
[32: `channel_id`]
[8: funding_satoshis]
[8:ndust_limit_satoshis]
[8:channel_reserve_satoshis]
[`2`:`num_inputs`]
[`num_inputs*input_info`]
[`2`:`num_outputs`]
[`num_outputs`*ouput_info`]
Requirements:
The sending node:
-
MAY update the amount, dust limit, or channel reserve for the channel
The receiving node:
-
MAY reject (error) the RBF request if:
-
the dust or channel reserve is unreasonable
-
MUST reject (error) the RBF request if:
-
the `funding_satoshis` amount is less than the previous negotiated
`push_mast`
-
the `dust_limit_satoshis` is greater than the
`channel_reserve_satoshis`
-
the total fees incurred by the `input_info`s and `output_info`s at
the new `fee_rate` is more than their `funding_satoshis`
otherwise:
-
SHOULD send a `commitment_signed2` message
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181127/b864846e/attachment-0001.html>

2023-06-09 12:52:21 GMT

- reply

📅 Original date posted:2018-11-12
📝 Original message:
On Wed, Nov 7, 2018 at 11:02 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
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 for this to work, we would need to
> undo
> this at a global scale to ensure these announcements propagate?
>
Right on. I'm not too worried about this tbh; a new node on the network
could easily fix this by taking liquidity from another node that's already
offering it, to create a few balanced channels to itself. This would a) put
it on the map and b) make the liquidity that it's looking to offer more
valuable, as the other channels it's opened make it more likely to be
routed through.
>
> Aside from the incentives for leaches to arise that accept the fee then
> insta close (they just drain the network and then no one uses this), I
> think
> this is a dope idea in general! In the past, I've mulled over similar
> constructions under a general umbrella of "Channel Liquidity Markets"
> (CLM),
> though via extra-protocol negotiation.
>
> -- Laolu
>
>
> On Wed, Nov 7, 2018 at 2:38 PM lisa neigut <niftynei at gmail.com> wrote:
>
>> Problem
>> ====================================
>> Currently it’s difficult to reliably source inbound capacity for your
>> node. This is incredibly problematic for vendors and nodes hoping to setup
>> shop as a route facilitator. Most solutions at the moment require an
>> element of out of band negotiation in order to find other nodes that can
>> help with your capacity needs.
>>
>> While splicing and dual funding mechanisms will give some relief by
>> allowing for the initial negotiation to give the other node an opportunity
>> to put funds in either at channel open or after the fact, the problem of
>> finding channel liquidity is still left as an offline problem.
>>
>> Proposal
>> =====================================
>> To solve the liquidity discovery problem, I'd like to propose allowing
>> nodes to advertise initial liquidity matching. The goal of this proposal
>> would be to allow nodes to independently source inbound capacity from a
>> 'market' of advertised liquidity rates, as set by other nodes.
>>
>> A node, via their node_announcement, can advertise that they will match
>> liquidity and a fee rate that they will provide to any incoming
>> open_channel request that indicates requests it.
>>
>> `node_announcement`:
>> new feature flag: option_liquidity_provider
>> data:
>> [4 liquidity_fee_proportional_millionths] (option_liquidity_provider)
>> fee charged per satoshi of liquidity added at channel open
>> [4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged
>> for providing liquidity at channel open
>>
>> `open_channel`:
>> new feature flag (channel_flags): option_liquidity_buy [2nd least
>> significant bit]
>> push_msat: set to fee payment for requested liquidity
>> [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding
>> requested at channel open
>>
>> `accept_channel`:
>> tbd. hinges on a dual funding proposal for how second node would send
>> information about their funding input.
>>
>> If a node cannot provide the liquidity requested in `open_channel`, it
>> must return an error.
>> If the amount listed in `push_msat` does not cover the amount of
>> liquidity provided, the liquidity provider node must return an error.
>>
>> Errata
>> ======================================
>> It's an open question as to whether or not a liquidity advertising node
>> should also include a maximum amount of liquidity that they will
>> match/provide. As currently proposed, the only way to discover if a node
>> can meet your liquidity requirement is by sending an open channel request.
>>
>> This proposal depends on dual funding being possible.
>>
>> Should a node be able to request more liquidity than they put into the
>> channel on their half? In the case of a vendor who wants inbound capacity,
>> capping the liquidity request allowed seems unnecessary.
>>
>> Conclusion
>> =======================================
>> Allowing nodes to advertise liquidity paves the way for automated node
>> re-balancing. Advertised liquidity creates a market of inbound capacity
>> that any node can take advantage of, reducing the amount of out-of-band
>> negotiation needed to get the inbound capacity that you need.
>>
>>
>> Credit to Casey Rodamor for the initial idea.
>> _______________________________________________
>> 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/20181112/f94d4806/attachment.html>

2023-06-09 12:52:19 GMT

- reply

📅 Original date posted:2018-11-12
📝 Original message:
Hello ZmnSCPxj,
You bring up some good points.
On Wed, Nov 7, 2018, 21:19 ZmnSCPxj <ZmnSCPxj at protonmail.com wrote:
> Good morning Lisa,
>
> On Wednesday, November 7, 2018 2:17 PM, ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
> Good morning Lisa,
>
> >Should a node be able to request more liquidity than they put into the
> channel on their half? In the case of a vendor who wants inbound capacity,
> capping the liquidity request
> >allowed seems unnecessary.
>
> My initial thought is that it would be dangerous to allow the initiator of
> the request to request for arbitrary capacity.
>
> For instance, suppose that, via my legion of captive zombie computers
> (which are entirely fictional and exist only in this example, since I am an
> ordinary human person) I have analyzed the blockchain and discovered that
> you have 1.0 BTC you have reserved for liquidity requests under this
> protocol. I could then have one of those computers spin up a temporary
> Lightning Node, request for 1.0BTC incoming capacity with only some nominal
> fee, then shut down the node permanently, leaving your funds in an
> unuseable channel, unable to earn routing fees or such. This loses you
> potential earnings from this 1.0 BTC.
>
> If instead I were obligated to have at least greater capacity tied into
> this channel, then I would also be tying up at least 1.0 BTC into this
> channel as well, making this attack more expensive for me, as it also loses
> me any potential earnings from the 1.0 BTC of my own that I have locked up.
>
> As you point out below, at the very least a liquidity providing node would
get paid. Another thing worth considering is that the spec, as written, is
merely a mechanism for advertising and receiving offers for dual funding.
There are no rules about what offers you, as a liquidity advertising node,
have to accept. A node operator has the flexibility to reject any offer
above or below their stated fee rate, or if they don't relish the idea of
funding a badly skewed channel. If you're worried about capital being tied
up unnecessarily, you can reject offers without a sizeable input of their
own.
There are, however, scenarios where requests for badly skewed channels make
sense. Imagine that you're a large vendor, such as Amazon. You're likely
not going to ever need much outbound capacity, but you will be perpetually
in the market for more inbound capacity.
In fact, as a liquidity provider, I think that you'll probably be delighted
to have an open channel with Amazon, as there's a good chance that channel
will be highly utilized, which means more fee traffic for you, and a high
probability that they'll be requesting more liquidity from you in the
future, as the existing channel gets unbalanced.
> A counterpoint to this argument, however, is that if the fee for the
> liquidity is high enough, then it does not matter to you whether I use the
> 1.0 BTC or not: you have already been paid for it.
>
> This however brings up the other potential attack:
>
> 1. I advertise that I have 1.0 BTC available for liquidity requests.
> 2. You answer this advertisement, and pay me a good fee for this 1.0 BTC
> being locked into a channel.
> 3. After the channel is opened, I immediately close it, having earned the
> fee for liquidity, without in fact delivering that liquidity.
>
> Perhaps we can modify channel commitment transactions for channels opened
> via liquidity requests, so that they have an `nSequence` that prevents them
> from being claimed for a month or so. What do you think?
>
At what point should a liquidity providing node (maker) be able to close
the channel? Immediately is not very beneficial to either of you -- you
both tied up your money for the time required to push through bitcoin txns
through, plus you lose closing + opening fees. Stipulating a length of time
isn't necessarily beneficial either -- if you've connected to a high volume
payment channel, the liquidity you've provided will be used up rather
quickly, rendering the channel itself pretty useless.
I think there's definitely some clever things we can do to provide stronger
guarantees around a 'minimum service offer', and they can be investigated
independently of the advertisement mechanism that I've proposed here.
Independent of what guarantees the protocol offers, there's a bunch of
strategies that individual nodes can additionally take to limit potential
losses: starting with by soliciting small liquidity offers, shopping around
for the best rates, blacklisting IP addresses/node id's of unreliable
nodes, using a ratcheting mechanism (start with a small liquidity request
that you close/rebalance upward as the incoming capacity is drained).
Considering incentives, keeping a high-traffic channel open should be worth
more in routing fees than the liquidity that you've provided. If the
liquidity market acts rationally, it should price itself to reflect this
reality and the risk of being laolu'd should remain fairly insignificant.
> Regards,
> ZmnSCPxj
>
> To my mind, this may become important.
>
> Regards,
> ZmnSCPxj
>
>
> Conclusion
> =======================================
> Allowing nodes to advertise liquidity paves the way for automated node
> re-balancing. Advertised liquidity creates a market of inbound capacity
> that any node can take advantage of, reducing the amount of out-of-band
> negotiation needed to get the inbound capacity that you need.
>
>
> Credit to Casey Rodamor for the initial idea.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181112/45e41973/attachment-0001.html>

2023-06-09 12:52:19 GMT

- reply

📅 Original date posted:2018-11-12
📝 Original message:
On Wed, Nov 7, 2018 at 10:17 PM Anthony Towns <aj at erisian.com.au> wrote:
> On Wed, Nov 07, 2018 at 06:40:13PM -0800, Jim Posen wrote:
> > can simply close the channel. So if I'm charging for liquidity, I'd
> actually
> > want to charge for the amount (in mSAT/BTC) times time.
>
> So perhaps you could make a market here by establishing a channel saying
> that
>
> "I'll pay 32 msat per 500 satoshi per hour for the first 3 days"
>
> When you open the channel with 500,000 satoshi donated by the other guy,
> you're then obliged to transfer 32 satoshi every hour to the other guy
> for three days (so a total of 14c or so).
>
> If the channel fails beforehand, they don't get paid; if you stop
> paying you can still theoretically do a mutual close.
>
I think that this can also be gamed by a second, cooperating node that
sends payments through the channel to meet the rate and capture the fees
for the first. You can make this less likely by charging higher
transmission fees that make such an attack infeasible, and it's less
'damaging' than an immediate close in that there's still open capacity
available for some time, at least until the 'bogus' payments have drained
the capacity that you solicited in the first place.
> Maybe a complicated addition to the protocol though?
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181112/f34b2bd2/attachment.html>

2023-06-09 12:52:17 GMT

- reply

📅 Original date posted:2018-11-07
📝 Original message:
Problem
====================================
Currently it’s difficult to reliably source inbound capacity for your node.
This is incredibly problematic for vendors and nodes hoping to setup shop
as a route facilitator. Most solutions at the moment require an element of
out of band negotiation in order to find other nodes that can help with
your capacity needs.
While splicing and dual funding mechanisms will give some relief by
allowing for the initial negotiation to give the other node an opportunity
to put funds in either at channel open or after the fact, the problem of
finding channel liquidity is still left as an offline problem.
Proposal
=====================================
To solve the liquidity discovery problem, I'd like to propose allowing
nodes to advertise initial liquidity matching. The goal of this proposal
would be to allow nodes to independently source inbound capacity from a
'market' of advertised liquidity rates, as set by other nodes.
A node, via their node_announcement, can advertise that they will match
liquidity and a fee rate that they will provide to any incoming
open_channel request that indicates requests it.
`node_announcement`:
new feature flag: option_liquidity_provider
data:
[4 liquidity_fee_proportional_millionths] (option_liquidity_provider) fee
charged per satoshi of liquidity added at channel open
[4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged
for providing liquidity at channel open
`open_channel`:
new feature flag (channel_flags): option_liquidity_buy [2nd least
significant bit]
push_msat: set to fee payment for requested liquidity
[8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding
requested at channel open
`accept_channel`:
tbd. hinges on a dual funding proposal for how second node would send
information about their funding input.
If a node cannot provide the liquidity requested in `open_channel`, it must
return an error.
If the amount listed in `push_msat` does not cover the amount of liquidity
provided, the liquidity provider node must return an error.
Errata
======================================
It's an open question as to whether or not a liquidity advertising node
should also include a maximum amount of liquidity that they will
match/provide. As currently proposed, the only way to discover if a node
can meet your liquidity requirement is by sending an open channel request.
This proposal depends on dual funding being possible.
Should a node be able to request more liquidity than they put into the
channel on their half? In the case of a vendor who wants inbound capacity,
capping the liquidity request allowed seems unnecessary.
Conclusion
=======================================
Allowing nodes to advertise liquidity paves the way for automated node
re-balancing. Advertised liquidity creates a market of inbound capacity
that any node can take advantage of, reducing the amount of out-of-band
negotiation needed to get the inbound capacity that you need.
Credit to Casey Rodamor for the initial idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/07fce24b/attachment.html>

2023-06-09 12:51:39 GMT

- reply

📅 Original date posted:2018-10-16
📝 Original message:
To add some context to this, if you start accepting HTLC's for the new
balance after the parallel commitment is made, but before the re-anchor is
buried, there's the potential for a race condition between a unilateral
close (or any revoked commitment transaction) and the re-anchoring
commitment transaction, that spends the 'pre-committed' UTXO of splicing in
funds and the original funding transaction.
You can get around this by waiting until both the pre-commitment UTXO and
the re-anchor have cleared a minimum depth before accepting HTLC's for the
new balance totals, but that's twice as long of a wait as the first,
synchronized re-commitment scheme that Rusty originally proposed.
It also makes leaving the original funding transaction 'exposed' (ie Rene's
version of parallel splice) untenable, as there's always the risk of an old
state being published to consume that input. This foobars your current HTLC
commitments.
On Tue, Oct 16, 2018 at 3:31 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Rusty Russell <rusty at rustcorp.com.au> writes:
> > If we're going to do side splice-in like this, I would use a very
> > different protocol: the reason for this protocol was to treat splice-in
> > and splice-out the same, and inline splice-in requires wait time. Since
> > splice-out doesn't, we don't need this at all.
> >
> > It would look much more like:
> >
> > 1. Prepare any output with script of specific form. eg:
> > OP_DEPTH 3 OP_EQUAL OP_IF
> > <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
> > OP_ELSE
> > <blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
> > <myrescue_pubkey> OP_CHECKSIG
> > OP_ENDIF
> >
> > 1. type: 40 (`splice_in`) (`option_splice`)
> > 2. data:
> > * [`32`:`channel_id`]
> > * [`8`: `satoshis`]
> > * [`32`: `txid`]
> > * [`4`: `txoutnum`]
> > * [`4`: `blockheight`]
> > * [`33`: `myrescue_pubkey`]
> >
> > 1. type: 137 (`update_splice_in_accept`) (`option_splice`)
> > data:
> > * [`32`:`channel_id`]
> > * [`32`: `txid`]
> > * [`4`: `txoutnum`]
> >
> > 1. type: 138 (`update_splice_in_reject`) (`option_splice`)
> > data:
> > * [`32`:`channel_id`]
> > * [`32`: `txid`]
> > * [`2`:`len`]
> > * [`len`:`errorstr`]
> >
> > The recipient of `splice_in` checks that it's happy with the
> > `blockheight` (far enough in future). Once it sees the tx referred to
> > buried to its own `minimum_depth`, it checks output is what they
> > claimed, then sends `update_splice_in_accept`; it's followed up
> > `commitment_signed` like normal, but from this point onwards, all
> > commitment txs signatures have one extra sig.
>
> Lisa started asking pointed questions, and so I noticed that parallel
> splice doesn't work with Poon-Dryja channels.
>
> The counterparty can spend the old funding txout with a revoked spend.
> Sure, I can take all the money from that, but what about the spliced
> input?
>
> I came up with increasingly elaborate workarounds, but nothing stuck.
>
> Back to Plan A...
> Rusty.
> _______________________________________________
> 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/20181016/6855b1ec/attachment.html>

2023-06-09 12:40:56 GMT

- reply

2023-06-09 12:40:52 GMT

- reply

2023-06-09 12:40:19 GMT

- reply

2023-06-07 23:03:17 GMT

- reply

📅 Original date posted:2022-02-09
📝 Original message:Changing the way that RBF works is an excellent idea. Bitcoin is overdue
for revisiting these rules. Thanks to @glowzo et al for kicking off the
discussion.
I've been thinking about RBF for a very long time[1], and it's been fun to
see other people's thoughts on the topics. Here's my current thinking about
this, and proposal for how we should update the rules.
### Changing the Rules? How to Change Them
Regarding how to change them, Bram and aj are right -- we should move to a
model where transaction relay candidates are evaluated on their net
increase in fees per byte paid, and remove the requirement that the gross
fee of the preceding transaction is met or exceeded.
Our current ruleset is over complicated because it attempts to solve two
problems at once: the miner's best interests (highest possible fee take)
and relay policy.
I believe this is a mistake and the mempool should change its goals.
Instead, the mempool relay design for RBFs should be built around 1)
increasing the the per-byte fees paid of a transaction and 2) providing a
simple policy for applications building on top of bitcoin, such that
knowledge of the mempool is not required for successfully issuing
relay-able RBF transactions.
(A simple "must increase the per-byte feerate" heuristic for RBF relay
candidates has the nice benefit of being easy to program to on the
application side, and only requires knowledge of the previous candidate
transaction, not the entire mempool or any previous tx's relative position
within it.)
Finally, when blockspace is competitive , this simple policy ensures that
the per-byte value of every subsequent relayed transaction increases the
per-byte value of pending bytes for the next block. This provides a measure
of DoS protection and ensures that every relayed byte is more valuable (to
the miner/network) than the last.
*The only time that RBF is critical for relay is during full block periods
-- if there's not enough transactions to fill a block, using RBF to ensure
that a transaction is mined in a timely manner is moot. As such, RBF rules
should not be concerned with low-block environments.
### Mempools and Relay
The mempool currently serves two masters: the profit motive of the miner
and the relay motive of a utxo holder. It is in the interest of a user to
send the miner a high per-byte tx, such that it might end up in the next
block. It is in the miner's best interest to include the highest per-byte
set of transactions in their block template.
There is some conflation here in the current RBF policies between what is
in the mempool and what is considered a candidate for the block template.
If a miner has already included a more profitable package of txs into their
block template than a more valuable per-byte tx that the network has
relayed to them, it should be the responsibility of the block template
constructor to reject the new proposed tx, not the nodes relaying the
transaction to said miner.
This is a policy that the miner can (and should) implement at the level of
the template construction, however.
Is it the responsibility of the mempool to provide the best "historical"
block opportunity for a miner (e.g. the highest paying block given all txs
it's ever seen)? I would say no, that the ability of a utxo owner to
re-state the spend condition of a pending transaction is more important,
from a use-case perspective, and that the mempool should concern itself
solely with relaying increasingly more profitable bytes to miners. Let the
miners concern themselves with deciding what the best policy for their own
block construction is, and the mempool with relaying the highest value
bytes for the network. Net-net, this will benefit everyone as it becomes
easier for users to re-submit txs with increasingly greater feerates,
creating more active competition for available blockspace as more
applications are able to include it as a feature (and it works, reliable,
as a relay mechanism).
### Packages and RBF
Packages make the increasing per-byte rule less of a guarantee that
increasing the per-byte value of a single transaction will net a given
miner more fees than including the entire package.
Let's decompose this a bit. It's helpful to think of tx packages as
'composable txs'. Basically when you consider a 'package' it is actually a
large tx with sub-components, the individual txs. As a 'composed tx', you
can calculate the per-byte feerate of the entire set. This is the number
that you, as someone issuing an RBF, would need to beat in order to move
your tx up in the pending block queue.
RBF, however, is a transaction level policy: it allows you to replace any
*one* component of a package, or tree, with the side effect of possibly
invalidating other candidate txs. If the 'composed tx' (aka package) had a
net per-byte value that was higher than the new replacement transaction
because of a leaf tx that had an outsized per-byte feerate, then it would
be more profitable for the miner to have mined the entire package rather
than the replacement.
This edge case complicates the picture for the miner. Considered from the
viewpoint of the user issuing the RBF, however, it is far simpler. In the
ideal case, a person is issuing an RBF because the previous tx tree, even
with its high fee sub-component, was not a candidate for the next block.
And, in some cases, increasing the sub-component's per-byte feerate will
not achieve the goal of moving the tx any closer to being mined. It's only
by increasing the feerate above the present feerate of the candidate plus
desendents (tx package) that the transaction will advance in the queue.
While not uncomplicated, this is a simple enough metric for a wallet to
track, and does not require any knowledge of the current mempool to
effectively surpass. It's the wallet's responsibility to track this though;
failure to take descendants into account when deciding on the next per-byte
feerate for an RBF *will* mean that your RBF will be ineffective at
achieving the goal of getting your UTXO spent. Any wallet is incentivized
to always provide a higher per-byte feerate than the 'composed tx' (tx and
its descendants), so as to ensure an actual improvement in the unconfirmed
transaction's position in the block queue, so to speak.
Note that the v2 protocol for channel opens in lightning uses an RBF
negotiation that adheres basically to these rules (ea transaction must have
a strictly greater per-byte feerate).
We enforce a rate of 65/64th as the required increase in feerate for each
subsequent channel open transaction.
https://github.com/lightning/bolts/pull/851/files#diff-ed04ca2c673fd6aabde69389511fa9ee60cb44d6b2ef6c88b549ffaa753d6afeR1154
### RBF and DoS
Admittedly, changing these rules will increase the number of times that any
UTXO is eligible to be retransmitted (relayed) via the bitcoin node
network. Strictly increasing the per-byte feerate however ensures that this
re-relay is increasingly more expensive to the UTXO owner, however.
### in exitus
These are the things I've been thinking about with regards to RBF. I hope
they can help to highlight the challenges in the RBF design space a bit
more clearly, as well as spelling out the case for using a simple heuristic
such as "solely increasing per-byte feerate" as a good candidate for the
revised RBF policy.
~niftynei
[1]
https://basicbitch.software/posts/2018-12-27-Explaining-Replace-By-Fee.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220209/c2920d26/attachment.html>

2023-06-07 23:00:17 GMT

- reply

📅 Original date posted:2021-10-25
📝 Original message:Hi all,
In a recent conversation with @glozow, I had the realization that the
mempool is obsolete and should be eliminated.
Instead, users should submit their transactions directly to mining pools,
preferably over an anonymous communication network such as tor. This can
easily be achieved by mining pools running a tor onion node for this
express purpose (or via a lightning network extension etc)
Mempools make sense in a world where mining is done by a large number of
participating nodes, eg where the block template is constructed by a
majority of the participants on the network. In this case, it is necessary
to socialize pending transaction data to all participants, as you don’t
know which participant will be constructing the winning block template.
In reality however, mempool relay is unnecessary where the majority of
hashpower and thus block template creation is concentrated in a
semi-restricted set.
Removing the mempool would greatly reduce the bandwidth requirement for
running a node, keep intentionality of transactions private until
confirmed/irrevocable, and naturally resolve all current issues inherent in
package relay and rbf rules. It also resolves the recent minimum relay
questions, as relay is no longer a concern for unmined transactions.
Provided the number of block template producing actors remains beneath, say
1000, it’d be quite feasible to publish a list of tor endpoints that nodes
can independently + directly submit their transactions to. In fact, merely
allowing users to select their own list of endpoints to use alternatively
to the mempool would be a low effort starting point for the eventual
replacement.
On the other hand, removing the mempool would greatly complicate solo
mining and would also make BetterHash proposals, which move the block
template construction away from a centralized mining pool back to the
individual miner, much more difficult. It also makes explicit the target
for DoS attacks.
A direct communication channel between block template construction venues
and transaction proposers also provides a venue for direct feedback wrt
acceptable feerates at the time, which both makes transaction confirmation
timelines less variable as well as provides block producers a mechanism for
(independently) enforcing their own minimum security budget. In other
words, expressing a minimum acceptable feerate for continued operation.
Initial feerate estimation would need to be based on published blocks, not
pending transactions (as this information would no longer be available), or
from direct interactions with block producers.
~niftynei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211025/a5c7aebf/attachment.html>