Nostr notes by lisa neigut [ARCHIVE]

📅 Original date posted:2022-09-23 📝 Original message: Some ...

2023-06-09T13:06:49Z

In reply to nevent1q…t0qu
_________________________

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

📅 Original date posted:2022-09-13 📝 Original message: Hi ...

2023-06-09T13:06:47Z

In reply to nevent1q…fdh7
_________________________

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

📅 Original date posted:2020-02-12 📝 Original message: > ...

2023-06-09T12:58:45Z

In reply to nevent1q…kxs8
_________________________

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

📅 Original date posted:2020-02-11 📝 Original message: > ...

2023-06-09T12:58:44Z

In reply to nevent1q…tjzh
_________________________

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

📅 Original date posted:2020-02-10 📝 Original message: ...

2023-06-09T12:58:42Z

In reply to nevent1q…tf5l
_________________________

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

📅 Original date posted:2020-02-10 📝 Original message: ...

2023-06-09T12:58:41Z

In reply to nevent1q…7rtu
_________________________

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

📅 Original date posted:2020-02-13 📝 Original message: > ...

2023-06-09T12:58:41Z

In reply to nevent1q…2wxw
_________________________

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

📅 Original date posted:2020-02-10 📝 Original message: > ...

2023-06-09T12:58:39Z

In reply to nevent1q…aj6a
_________________________

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

📅 Original date posted:2020-02-06 📝 Original message: > ...

2023-06-09T12:58:38Z

In reply to nevent1q…yk8q
_________________________

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

📅 Original date posted:2020-02-04 📝 Original message: Rusty ...

2023-06-09T12:58:37Z

In reply to nevent1q…k5tk
_________________________

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

📅 Original date posted:2020-01-30 📝 Original message: hi ...

2023-06-09T12:58:24Z

In reply to nevent1q…cxea
_________________________

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

📅 Original date posted:2019-11-07 📝 Original message: > ...

2023-06-09T12:57:12Z

In reply to nevent1q…76jl
_________________________

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

📅 Original date posted:2021-10-25 📝 Original message:Hi ...

2023-06-07T23:00:17Z

In reply to nevent1q…jcvl
_________________________

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