<unnamed>

Public Key

npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2

Profile Code

nprofile1qqsgq3msadvdzc7k8u8ejm7kh6atuxuvtq49m42yeasmhg9u2v6hyzspzpmhxue69uhkummnw3ezuamfdejsklne9k

Publishing to

nostr.wine

Last Notes

2023-06-09 15:06:49 CEST

- 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 15:04:04 CEST

- reply

📅 Original date posted:2021-10-12
📝 Original message:
Love the idea of moving the specs etc to github.com/lightning, thanks so
much for generously offering to donate this Laolu. Strong ACK from me.
Given how difficult the existing org is wrt ownership etc, moving to a new
one makes a lot of sense to me.
Thanks Fabrice for bringing this up so we could discuss it and get a better
understanding of the difficulties with the existing situation.
- nifty
On Wed, Oct 13, 2021 at 00:48 Damian Mee <btc at meedamian.com> wrote:
> While I don't partake in the conversations too often, I just want to say I
> strongly support Olaoluwa suggestion. AFAIAA there's a lot of automations,
> dependencies, dockerfiles, or direct links to files that rely on the
> location of lnd github repo, and I'm sure not all of it would be able to
> handle Github redirect gracefully. While accessing spec is mostly a
> human/browser activity, where dealing with redirects is much easier.
>
> Plus, github.com/lightning/spec, github.com/lightning/bolts, and/or
> github.com/lightning/rfc would all be trivial to remember, and quick to
> type.
>
> On Tue, Oct 12, 2021 at 2:57 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
>
>> Hi Fabrice,
>>
>> > I believe that was a mistake: a few days ago, Arcane Research published
>> a
>> > fairly detailed report on the state of the Lightning Network:
>> > https://twitter.com/ArcaneResearch/status/1445442967582302213. They
>> > obviously did some real work there, and seem to imply that their report
>> > was vetted by Open Node and Lightning Labs.
>>
>> Appreciate the hard work from Arcane on putting together this report. That
>> said, our role wasn't to review the entire report, but instead to provide
>> feedback on questions they had. Had we reviewed the section in question,
>> we
>> would have spotted those errors and told the authors to fix them. Mistakes
>> happen, and we're glad it got corrected.
>>
>> Also note that lnd has _never_ referred to itself as the "reference"
>> implementation. A few years ago some other implementations adopted that
>> title themselves, but have since adopted softer language.
>>
>> > So I'm proposing that lnd's source code be removed from
>> > https://github.com/lightningnetwork/ (and moved to
>> > https://github.com/lightninglabs for example, with the rest of their
>> > Lightning tools, but it's up to Lightning Labs).
>>
>> I think it's worth briefly revisiting a bit of history here w.r.t the
>> github
>> org in question. In the beginning, the lightningnetwork github org was
>> created by Joseph, and the lightningnetwork/paper repo was added, the
>> manuscript that kicked off this entire thing. Later lightningnetwork/lnd
>> was
>> created where we started to work on an initial implementation (before the
>> BOLTs in their current form existed), and we were added as owners.
>> Eventually we (devs of current impls) all met up in Milan and decided to
>> converge on a single specification, thus we added the BOLTs to the same
>> repo, despite it being used for lnd and knowingly so.
>>
>> We purposefully made a _new_ lightninglabs github org as we wanted to keep
>> lnd, the implementation distinct from any of our future commercial
>> products/services. To this day, we've architected all our paid products to
>> be built _on top_ of lnd, rather than within it. As a result, users always
>> opt into these services.
>>
>> As it seems the primary grievance here is collocating an implementation of
>> Lightning along with the _specification_ of the protocol, and given that
>> the
>> spec was added last, how about we move the spec to an independent repo
>> owned
>> by the community? I currently have github.com/lightning, and would be
>> happy
>> to donate it to the community, or we could create a new org like
>> "lightning-specs" or something similar. We could then move the spec (the
>> BOLTs and also potentially the bLIPs since some devs want it to be within
>> its own repo) there, and have it be the home for any other
>> community-backed/owned projects. I think the creation of a new github
>> organization would also be a good opportunity to further formalize the set
>> of stakeholders and the general process related to the evolution of
>> Lightning the protocol.
>>
>> Thoughts?
>>
>> -- Laolu
>>
>> On Fri, Oct 8, 2021 at 5:25 PM Fabrice Drouin <fabrice.drouin at acinq.fr>
>> wrote:
>>
>>> Hello,
>>>
>>> When you navigate to https://github.com/lightningnetwork/ you find
>>> - the Lightning Network white paper
>>> - the Lightning Network specifications
>>> - and ... the source code for lnd!
>>>
>>> This has been an anomaly for years, which has created some confusion
>>> between Lightning the open-source protocol and Lightning Labs, one of
>>> the companies specifying and implementing this protocol, but we didn't
>>> do anything about it.
>>>
>>> I believe that was a mistake: a few days ago, Arcane Research
>>> published a fairly detailed report on the state of the Lightning
>>> Network: https://twitter.com/ArcaneResearch/status/1445442967582302213.
>>> They obviously did some real work there, and seem to imply that their
>>> report was vetted by Open Node and Lightning Labs.
>>>
>>> Yet in the first version that they published you’ll find this:
>>>
>>> "Lightning Labs, founded in 2016, has developed the reference client
>>> for the Lightning Network called Lightning Network Daemon (LND)....
>>> They also maintain the network standards documents (BOLTs)
>>> repository."
>>>
>>> They changed it because we told them that it was wrong, but the fact
>>> that in 2021 people who took time do do proper research, interviews,
>>> ... can still misunderstand that badly how the Lightning developers
>>> community works means that we ourselves badly underestimated how
>>> confusing mixing the open-source specs for Lightning and the source
>>> code for one of its implementations can be.
>>>
>>> To be clear, I'm not blaming Arcane Research that much for thinking
>>> that an implementation of an open-source protocol that is hosted with
>>> the white paper and specs for that protocol is a "reference"
>>> implementation, and thinking that since Lightning Labs maintains lnd
>>> then they probably maintain the other stuff too. The problem is how
>>> that information is published.
>>>
>>> So I'm proposing that lnd's source code be removed from
>>> https://github.com/lightningnetwork/ (and moved to
>>> https://github.com/lightninglabs for example, with the rest of their
>>> Lightning tools, but it's up to Lightning Labs).
>>>
>>> Thanks,
>>>
>>> Fabrice
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/20211013/ceeabee8/attachment.html>

2023-06-09 15:03:59 CEST

- 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 15:03:25 CEST

- 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 14:58:41 CEST

- 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 14:58:41 CEST

- 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 14:58:39 CEST

- 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 14:58:38 CEST

- 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 14:58:37 CEST

- 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 14:57:12 CEST

- 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 14:53:10 CEST

- 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 14:51:39 CEST

- 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-08 01:00:17 CEST

- 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>