Sentiment check for something we're doing in Lightning.Pub
- We want operators to own the decision of what risk they expose themselves to with regards to re-orgs, so this setting would be customizable.
- However, we still need to set a default. What I think is a sane default, and what users think it should be, are not necessarily the same.
Hense, a poll.
Situation:
- A guest can deposit via chain and spend via LN. If there's a re-org after the operator credits the user thereby allowing LN withdrawal, a re-org could be exploited leaving the Pub operator with a loss of those sats.
- One might also run a Pub explicitly to provide this swap service given Pub's nostr-based discoverability makes it a defacto decentralized non-atomic swap market.
Considerations:
- The reason to not only credit off of 6+ blocks you might be competing for users on UX and thus fee revenue.
- The reason not to do only 1 block is a 1 block re-org seems to happen on average every 45 days. This does not necessarily mean an attack, but could.
- 2+ block re-orgs are rare, 3+ very rare, but if you're doing volume, could mean a significant loss if you're attacked.
Decision:
If you were running a Pub, or any swap service for that matter, what is the minimum confirmations you would set before users can spend?
10.0%
29.1%
3-5 72.7%
6+18.2%
11 votes \ 20h left
How about you let the user chose? This is how @BareBits does it
While testing, it asked me if I has a noffer during the installation process, fiy.
thats the intent, question is... the default
Ideally this be configurable for amount ranges, or I need to be able to set both a tx size and tx volume constraint for automated processing.
If I can only configure this, then it's going to be 3 or 4.
If I can set additional thresholds, something like max 1 tx per block, max 100k sats, I'd even be fine with 1 - I wouldn't wanna take custody of huge amounts of sats anyway.
We already have 3 tiers, so would be exposing that to get away from hard coding
Settings table would be like this
eg
<1M sats = 1 1M-100M = 2 >100M = 3the
tier<n>LimitSatsare cumulative? or per-tx?(edit: also
s/M/k/g)per tx
so you're saying if you got 10 100k transactions you'd prefer treat them all as tier 2 instead of tier 1?
Yes. At least within the scope of the threshold. Active attackers will per their job description fuck you if you don't have cumulative controls.
For simplicity, pleb people amounts:
100k = 1 500k = 3 default = 6So 100k = 1 means 100k cumulative in the current block can go through, everything after that goes into tier 2, until 500k, requiring 3 confirmations, and everything after 500k in last(3) blocks goes into 6 confirmations. Could probably live with just the first and default tier at 3 though
This means that at current orphan rates I'd risk 100k per
~month.I'd let operators configure the minimum confirmations, and optionally require higher confirmations for larger deposits
1 leaves the operator open to abuse
2 is on the fence, almost ok
3 I'd say 3 is the sweet spot for general use
4,5,6+ is for incrementally larger amounts which can be set as previously mentioned
Yea we already have tiers, but current;y hard-coded and don't want to keep it that way. We're exposing them for customization and revisiting defaults while we do it.