c08r4d0r

https://gitworkshop.dev/npub12m5exm2uk3xa674cc5r0hlyvccs5xxn7qv83ezuteefv5972nquq4j4szl/relay.ngit.dev/esp-miner-nerdqaxeplus-tollgate
https://gitworkshop.dev/npub12m5exm2uk3xa674cc5r0hlyvccs5xxn7qv83ezuteefv5972nquq4j4szl/relay.ngit.dev/esp32-tollgate

2026-05-24 21:07:03 CEST

- reply

Thanks for sharing this @nprofile…xgps, my wife was already complaining that it's no wonder we don't get women at @nprofile…0yke if we don't add the Ernest Shackleton context to the posts..

2026-05-21 22:53:51 CEST

- reply

Thanks for making the time to take a look at this today @nprofile…gu0q !
@nprofile…t202 it looks like we have a solution to address the biggest pain points of auctions with a moving deadline. I'll run it by @nprofile…t5pj soon.
Here is an LLM summary of SatsAndSport's idea:
# Moving-Bound Auctions with 1-of-2 P2PK: Symmetric Oracle Paths for Trustless Early Refunds
**Date:** May 22, 2026
**Companion to:** "Extending Auctions Without Imposing a Hard End Time"
**Credit:** SatsAndSports identified the 1-of-2 P2PK approach as a solution to the early-refund and self-rebidding challenges raised in the original article.
---
## The Problem Recap
The moving-bound auction design (described in the parent article) removes the seller-imposed `max_end_at` and replaces it with a bound that moves forward with each new bid. This creates two friction points that the original article identified as open challenges:
1. **Refund latency:** Losing bidders must wait for the full locktime (grace period) to expire before reclaiming their ecash, even if the seller settles within seconds.
2. **Self-rebidding capital waste:** A bidder who raises their own bid must lock the full new amount while the old amount remains locked, temporarily tying up 2x-3x the actual commitment.
Both problems stem from the same root cause: the current lock profile is 1-of-1 P2PK with a timelocked refund. The only way to unlock ecash before `locktime` is via the seller's derived child private key. Losing bidders have no early exit.
---
## The Insight: Symmetric HD Paths with 1-of-2 P2PK
Cashu's NUT-11 already supports M-of-N P2PK locks. A `1-of-2` lock means the ecash can be spent by either of two specified pubkeys — no multisig coordination required, either key alone suffices.
The proposal: **the oracle issues derivation paths for both the seller and the bidder, and the ecash is locked to both of their derived pubkeys as a 1-of-2.**
This is the same path-oracle pattern already used in v1, applied symmetrically.
---
## Current Design: 1-of-1 P2PK + Timelocked Refund
```
┌─────────────────────────────────────────┐
│ Locked ecash (N sats) │
│ │
│ Spendable by: │
│ • seller_child_pubkey (anytime) │
│ derivation path held by oracle │
│ │
│ • bidder_refund_key (after │
│ locktime only) │
│ bidder holds this key directly │
│ │
│ locktime = max_end_at + grace_period │
└─────────────────────────────────────────┘
```
The oracle generates one derivation path per bid:
```
[seller xpub]
│
path: m/.../n
│
seller_child_pubkey
```
- **Seller** has the `xpriv`. Once the oracle reveals the derivation path, the seller derives the child private key and redeems the ecash.
- **Bidder** has a refund key but can only use it after `locktime` expires.
- **Oracle** holds only the derivation path (a sequence of indices). No private key material. Cannot spend.
The problem: the bidder's only early-exit mechanism is the locktime. In the common case (seller settles quickly), the bidder's funds are unnecessarily trapped for the full grace period.
---
## Proposed Design: 1-of-2 P2PK with Symmetric Paths
```
┌─────────────────────────────────────────┐
│ Locked ecash (N sats) │
│ │
│ Spendable by EITHER (1-of-2): │
│ • seller_child_pubkey │
│ (oracle path A) │
│ • bidder_child_pubkey │
│ (oracle path B) │
│ │
│ Fallback (if oracle disappears): │
│ • bidder_refund_key after locktime │
└─────────────────────────────────────────┘
```
The oracle now generates two derivation paths per bid — one against each party's HD key:
```
Oracle's HD key tree (per bid):
[oracle xpub]
/ \
path A: m/.../0 path B: m/.../1
/ \
seller_child_pubkey bidder_child_pubkey
```
### Key derivation for each party
- **Seller** holds their own `xpriv`. When the oracle reveals path A, the seller derives `seller_child_privkey = derive(xpriv, path_A)` and can spend.
- **Bidder** holds their own `xpriv`. When the oracle reveals path B, the bidder derives `bidder_child_privkey = derive(xpriv, path_B)` and can spend.
- **Oracle** holds only the path indices (e.g., `m/30408'/0'/0'` and `m/30408'/0'/1'`). No `xpriv` material from either party. **Cannot derive any private key. Cannot spend. Cannot steal.**
### The trust model
```
┌──────────────┐
│ ORACLE │
│ │
│ Knows: paths │
│ Can't: spend │
└──────┬───────┘
╱ ╲
path A ╱ ╲ path B
╱ ╲
┌──────┴──────┐ ┌──────┴──────┐
│ SELLER │ │ BIDDER │
│ │ │ │
│ Has: xpriv │ │ Has: xpriv │
│ Needs: A │ │ Needs: B │
└──────────────┘ └──────────────┘
```
The oracle's role is purely **informational**: it decides *which* path to reveal to *which* party. It controls the routing of funds without ever being able to take them.
**What the oracle CAN do:**
- Reveal path A to seller → seller claims the ecash (settlement)
- Reveal path B to bidder → bidder reclaims the ecash (early refund)
- Refuse to reveal any path → parties wait for locktime fallback (DoS, not theft)
- Reveal the "wrong" path → misroutes funds (seller gets refund, or bidder gets payment)
**What the oracle CANNOT do:**
- Derive either party's private key (holds no `xpriv`)
- Spend the locked ecash (no key material)
- Steal funds (can only redirect them to one of the two intended parties)
- Create or destroy ecash (bearer asset, mint-controlled)
This is the same threat model as v1. The oracle is trusted for **liveness** (it must reveal paths) and **correctness** (it reveals the right path to the right party), but NOT for **custody** (it cannot take funds).
---
## How This Solves the Open Challenges
### 1. Instant refunds for losing bidders
```
Auction ends. Winner determined.
For each LOSING bid:
Oracle reveals path B to the bidder
→ Bidder derives child privkey from xpriv + path B
→ Bidder redeems ecash from mint
→ Refund is INSTANT. No locktime wait.
For the WINNING bid:
Oracle reveals path A to the seller
→ Seller derives child privkey from xpriv + path A
→ Seller redeems ecash from mint
→ Same as today.
```
The locktime + refund key still exists as a **fallback**. If the oracle disappears or is unresponsive, every bidder can still reclaim after locktime expires. But in the normal case (oracle online), refunds happen immediately.
This means the grace period can be set generously (hours or even days) to handle seller downtime or mint downtime, **without penalizing losing bidders**. In the happy path, everyone gets their funds quickly regardless of the grace period length.
### 2. Capital-efficient self-rebidding
```
Bidder has a 5,000-sat bid (lock 1, 1-of-2 with paths A1/B1).
Bidder wants to raise to 8,000 sats.
1. Bidder requests new grant from oracle
→ Oracle generates paths A2/B2 for the new bid
2. Bidder locks 8,000 sats in new 1-of-2 lock (lock 2)
3. Bidder publishes new bid event
4. Oracle sees the new bid supersedes the old one
5. Oracle reveals path B1 for the OLD lock to the bidder
→ Bidder instantly reclaims the 5,000 sats
Net result: 5,000 recovered + 8,000 locked = only 8,000 outstanding.
Old lock is resolved immediately, no locktime wait.
```
The oracle's knowledge of which bids are superseded allows it to release the bidder's path for old locks as soon as a higher bid is confirmed. The bidder gets their capital back immediately and can reuse it.
### 3. Generous grace periods without penalty
In v1, the grace period directly determines how long losing bidders wait. A 1-hour grace means a 1-hour wait. This creates a tension: short grace = risky for seller, long grace = painful for bidders.
With 1-of-2 P2PK, the grace period is a **worst-case fallback**, not the normal-case latency:
- **Normal case** (oracle online): losing bidders get refunds via path B within seconds of settlement. Grace period length is irrelevant.
- **Worst case** (oracle offline): losing bidders wait for locktime (same as today). A longer grace period provides more safety for the seller without making the common case worse.
---
## Comparison: v1 vs. Proposed
| Aspect | v1 (current) | 1-of-2 proposal |
|--------|-------------|-----------------|
| Lock type | 1-of-1 P2PK | 1-of-2 P2PK |
| Pubkeys in lock | seller_child only | seller_child + bidder_child |
| Bidder refund trigger | locktime expiry only | oracle-revealed path B (instant) OR locktime (fallback) |
| Refund latency (normal case) | full grace period (1+ hour) | seconds |
| Self-rebid capital efficiency | must lock full new amount, old lock trapped | oracle releases old lock path B immediately |
| Grace period tradeoff | long grace = long bidder wait | long grace = safe fallback only, no normal-case penalty |
| Oracle trust | trusted for liveness + correctness, not custody | **identical** — same threat model |
| Bidder key requirement | single refund key (any secp256k1) | HD key (xpriv) for path derivation |
| Fallback if oracle disappears | bidder reclaims via locktime + refund key | **same** — locktime + refund key still in lock |
| Cashu mint compatibility | NUT-11 with P2PK + locktime + refund | NUT-11 with multi-pubkey P2PK + locktime + refund |
---
## What Changes in the Implementation
### NUT-11 lock construction
Current (v1):
```json
[
"P2PK",
{
"nonce": "<random>",
"data": "<seller_child_pubkey>",
"tags": [
["sigflag", "SIG_INPUTS"],
["locktime", "<locktime_unix_seconds>"],
["refund", "<bidder_refund_pubkey>"],
["n_sigs_refund", "1"]
]
}
]
```
Proposed (1-of-2):
```json
[
"P2PK",
{
"nonce": "<random>",
"data": "<seller_child_pubkey>,<bidder_child_pubkey>",
"tags": [
["sigflag", "SIG_INPUTS"],
["n_sigs", "1"],
["locktime", "<locktime_unix_seconds>"],
["refund", "<bidder_fallback_pubkey>"],
["n_sigs_refund", "1"]
]
}
]
```
Key differences:
- `data` field contains both pubkeys (comma-separated or as per NUT-11 multi-pubkey convention)
- `n_sigs: 1` explicitly set (1-of-2: either key suffices)
- `locktime` and `refund` remain as the oracle-disappears fallback
### Oracle grant flow
The oracle's `request_path` response expands from:
```json
{
"derivationPath": "m/30408'/0'/0'",
"childPubkey": "<seller_child>",
"grantId": "..."
}
```
To:
```json
{
"derivationPathA": "m/30408'/0'/0'",
"sellerChildPubkey": "<seller_child>",
"derivationPathB": "m/30408'/0'/1'",
"bidderChildPubkey": "<bidder_child>",
"grantId": "..."
}
```
The oracle still reveals paths only at settlement time:
- **Settlement:** oracle reveals `derivationPathA` to seller (same as today)
- **Refund:** oracle reveals `derivationPathB` to the losing bidder (new capability)
- **Rebid:** oracle reveals `derivationPathB` for the superseded bid to the bidder (new capability)
### Bidder key setup
In v1, bidders only need a refund pubkey (any secp256k1 key). In the 1-of-2 design, bidders need an HD key (`xpriv`/`xpub`) so they can derive child private keys from oracle-revealed paths.
This could be:
- The bidder's Nostr key (if it's an HD key)
- A dedicated auction HD key generated at first bid
- Derived from the bidder's NIP-60 wallet key material
The auction event would carry a `bidder_p2pk_xpub` in addition to the existing `p2pk_xpub` (seller), or a convention could be established where the bidder's xpub is communicated during the path request.
---
## Open Questions
1. **Bidder xpub source:** Where does the bidder's HD key come from? Options include: derived from Nostr key, derived from NIP-60 wallet, generated per-auction, or generated per-bid. The tradeoff is between privacy (fresh key per bid) and recoverability (deterministic from existing key material).
2. **Oracle path revelation timing:** When exactly does the oracle reveal path B to losers? Options: immediately after settlement, on request from the bidder, or batch-revealed for all losers at once.
3. **Rebid race condition:** If a bidder submits a rebid and the oracle releases path B for the old lock, what prevents the bidder from reclaiming the old funds AND cancelling the new bid before it's confirmed? The oracle should only release path B after the new bid is published and verified.
4. **Mint compatibility:** Not all Cashu mints may support multi-pubkey P2PK locks. The auction's trusted mint list should be validated for 1-of-2 support before the auction is created.
5. **Settlement policy versioning:** This would likely ship as `cashu_p2pk_path_oracle_v2`, coexisting with v1 auctions on the same relays. V1 auctions continue to settle under v1 rules.
---
## Summary
The 1-of-2 P2PK pattern applies the existing path-oracle trust model symmetrically: the oracle creates derivation paths for both the seller and the bidder, and the ecash is locked to both derived pubkeys. The oracle controls *who* can access the funds by choosing which path to reveal, but can never *take* the funds itself.
This solves the three biggest friction points in the moving-bound auction design:
- **Losing bidders** get instant refunds (no locktime wait in the normal case)
- **Self-rebidders** recover old locks immediately (no capital waste)
- **Grace periods** can be generous for safety without penalizing anyone in the happy path
The trust model is unchanged: the oracle is trusted for liveness and correctness, but never for custody. If the oracle disappears, the locktime + refund fallback works exactly as in v1.

2026-05-21 14:45:35 CEST

- reply

Links from today's community call highlights:
Wireless Gateway Manager (WGM)
https://github.com/OpenTollGate/tollgate-module-basic-go/pull/109
https://github.com/OpenTollGate/tollgate-module-basic-go/pull/117
https://github.com/OpenTollGate/tollgate-module-basic-go/pull/122
tollgate-rs Rust implementation (design phase)
https://github.com/OpenTollGate/tollgate-rs/pull/2
https://github.com/OpenTollGate/tollgate-rs/pull/3
FIPS integration planning (gateways -> peers)
https://learn.fips.network/
ESP32 + StratumV2 (nonces as bearer instruments)
https://gitworkshop.dev/npub12m5exm2uk3xa674cc5r0hlyvccs5xxn7qv83ezuteefv5972nquq4j4szl/git.orangesync.tech/esp32-tollgate
https://gitworkshop.dev/npub12m5exm2uk3xa674cc5r0hlyvccs5xxn7qv83ezuteefv5972nquq4j4szl/relay.ngit.dev/esp32-balloon-integration
Comprehensive hardware testing
https://github.com/OpenTollGate/physical-router-test-automation
OpenWRT 25.x support + opkg/apk package distribution
https://github.com/OpenTollGate/tollgate-os/pull/21
https://github.com/OpenTollGate/tollgate-os
https://github.com/OpenTollGate/tollgate-module-basic-go/tree/feature/openwrt-feed-compat
conwrt - Router flashing framework with OpenWrt device support
https://github.com/amperstrand/conwrt
Android app (auto-buy internet from TollGate upstreams)
https://github.com/alexxie16/tollgate_app
net4sats (new frontend on top of TollGate)
https://net4sats.com/
SSL management rewritten in Go
https://github.com/OpenTollGate/tollgate-module-basic-go/pull/123
Lightning checkout in captive portal
https://github.com/OpenTollGate/tollgate-module-basic-go/pull/107
https://github.com/OpenTollGate/tollgate-captive-portal-site/pull/9
New repos:
https://github.com/OpenTollGate/awesome-tollgate
https://github.com/OpenTollGate/tollgate-knowledgebase
https://github.com/OpenTollGate/tollgate-infrastructure-kit
TollGate protocol & release explorer:
https://github.com/OpenTollGate/tollgate
https://github.com/OpenTollGate/tollgate-release-explorer-site
Thanks to this month'"'"'s contributors:
https://github.com/alexxie16
https://github.com/Amperstrand
https://github.com/Origami74
https://gitworkshop.dev/npub12m5exm2uk3xa674cc5r0hlyvccs5xxn7qv83ezuteefv5972nquq4j4szl
Main repo: https://github.com/OpenTollGate/tollgate-module-basic-go

2026-05-21 13:20:34 CEST

- reply

Starting in 40 minutes:
https://primal.net/e/nevent1qqst0zdkc9r38a9pqgk65452caz03a6wjt56glqh0puww24gxv36yeqgyue6s

2026-05-17 22:02:11 CEST

Its incredible to see how good ngit and gitworkshop have gotten. You should probably give it another try if you haven't used it lately.
Thanks for all the work your putting into this @nprofile…ntqg 🙏

2026-04-21 16:18:09 CEST

https://blossom.primal.net/694d184cb5c78a2ccb762723d2548806446c104ad274e720eb92e7695cb4f138.png
Notes from @npub1zc6ts76lel22d38l9uk7zazsen8yd7dtuzcz5uv8d3vkast9hlks4725sl as he fixes @nprofile…2l34 UX with @npub10wzfa7jkqj6c65xyr93hhxrns37ml9tss82jvymv8fymwdtu6cts3h6pvr , @npub175aemydge5thld9peuyp5xmdtp6e5wq77ys203dp3s88pjhgpxpsvgkemm and @npub15ymzglvv4alrp06q85eqqmawegxf688v0gtqwhjpgtp0a4k2mesqshkwwx

2026-03-21 15:14:12 CET

- reply

Thanks for clarifying @nprofile…qaxf, I wasn't sure whether to call it a Spilman channel or not. Either way, an efficient way to transfer money in both directions would be really useful regardless of whether it's two Spilman channels or a single bidirectional channel.

2026-03-17 15:25:09 CET

- reply

I head there will be bidirectional channels soon!

2026-03-16 23:18:35 CET

GitWorkshop & Ngit have gotten really easy to use again @nprofile…ntqg . Thanks for all the hard work you put into this!

2026-03-15 23:48:39 CET

- reply

Hast Du einem Lonk Zum artilel @nprofile…5d67 ?

2026-03-14 23:56:03 CET

- reply

Seems to work. Thanks @nprofile…mt7m

2026-03-14 23:09:49 CET

- reply

Hi Blue

2026-03-13 18:06:08 CET

- reply

@nprofile…mt7m

2026-03-13 18:05:55 CET

- reply

@nprofile…mjel

2026-03-02 08:08:37 CET

- reply

I want to use it! When main net @nprofile…22jg ?
@npub148alhgz53wvh3wgtj8fxpdz47fesn78eft2dsmq8xa68eq5uewks0nh5r8 told me there is an end-point for the owner of a mint to mark lightning invoices as paid. Perhaps this could be used as a workaround to get a preview of the e-hash future?

2026-02-27 12:48:03 CET

- reply

You don't pay your llms?

2026-02-11 09:47:52 CET

- reply

Master just has markdown files. Which branch do you recommend @nprofile…hd69 ?

2026-02-11 09:37:37 CET

- reply

Do you have an ansible script for this? Have you published itanywheree?

2026-02-06 23:09:16 CET

- reply

People who appreciate your contribution might zap you

2026-02-06 23:08:48 CET

- reply

Have you considered contributing to @nprofile…94rw in the hope of getting zaps? It's on ngit (gitworkshop.dev), so you don't even need a GitHub account

2026-02-02 20:07:13 CET

- reply

I haven't tried it in open code yet, but Gemini worked fine with images in roo code. I hope to try open code in the coming days. Will report back on how it goes..

2026-02-02 11:47:08 CET

- reply

Gemini pro should work

2026-01-31 17:46:41 CET

- reply

Thanks for the follow up. Yes your explanation at the Thursday demo helped me to understand it better. Looking forward to seeing the adoption!

2026-01-27 11:06:59 CET

- reply

Yes it sounds a lot like epoxy. Epoxy could probably still benefit spillman channels and more adoption though..
https://github.com/Origami74/nostr-epoxy-reverse-proxy

2026-01-27 00:47:06 CET

- reply

I think they used cashu (pre spillman). It was demoed I'm an earlier cohort..

2026-01-27 00:42:54 CET

- reply

As in every website comes with a paid socks5 proxy? This reminds me of Epoxy, a paid socks5 proxy for nostr relays that @nprofile…evew and @nprofile…6htm worked on. That could definitely benefit from spillman channels..

2026-01-22 09:49:46 CET

- reply

#nevent1q…zjm7

2026-01-21 17:30:27 CET

- reply

@nprofile…qaxf is there an npub for cashu tube yet?

2026-01-21 17:29:41 CET

- reply

@nprofile…94rw

2026-01-21 16:52:21 CET

- reply

@nprofile…9m52 any chance you can make it?

2026-01-21 16:34:42 CET

- reply

We might be able to add this to your software defined modem quite easily..

2026-01-21 16:33:09 CET

- reply

https://en.wikipedia.org/wiki/Hamming_code
@nprofile…4dh7

2026-01-21 13:21:32 CET

- reply

Feel free to add your things in the comments if you want them to go on the agenda:
https://primal.net/a/naddr1qvzqqqr4gupzpslz866785q0rze0favgmrxmc4yxfzl8vx7ajzqjrpklgcpa0j4fqy88wumn8ghj7mn0wvhxcmmv9uqjqamnwvaz7tmzd968xct59ekk7mr0dekxzcn99e5x7mryd9hxwue0qq08gmmvd3nkzar9943k7mtdw4hxjare943kzmrv94skwetwv3ssze2ad2

2026-01-19 23:02:52 CET

- reply

That's a pity, your missing out.

2026-01-19 20:13:43 CET

- reply

It uses spillman channels in the backend to pay for the infrastructure rather than using your attention to pay for the infrastructure that you used

2026-01-19 18:34:54 CET

- reply

What, people still use YouTube even though cashu tube exists?
#nevent1q…3pm5

2026-01-19 09:59:57 CET

#nevent1q…v3gl

2026-01-17 15:44:23 CET

- reply

@nprofile…qpd7 how are your plans for SEC-07 coming along? There will be a satellite dish pointed at QO-100 and we will work on turning it into a regular @nprofile…m2rw so that anyone can be an internet service provider.
Cc: @nprofile…4dh7 @nprofile…shvs
#nevent1q…nt36

2026-01-17 12:00:38 CET

- reply

One day my bitaxe will be attached to a money printer that prints e-hash in real time as the bitaxe works. The bitaxe will be selling internet for said e-hash!
@nprofile…22jg

2026-01-16 18:21:46 CET

- reply

It's family friendly

2026-01-16 18:21:08 CET

- reply

Looking forward to your nsite demo at the cohort @nprofile…6vxs ! 😀

2026-01-16 18:19:51 CET

- reply

Yes reticulum is something I want to learn more about and I want to build on. @nprofile…j6yf please join us to make sure reticulum isn't overlooked. The value of in person collaboration like this is that we can (politely) help each other discard bad ideas, which helps us to focus our efforts on the things that could work.

2026-01-14 17:06:15 CET

- reply

Aah that's a pity..

2026-01-14 14:28:02 CET

- reply

This is the application form:
https://sovereignengineering.typeform.com/SEC-07?typeform-source=primal.net

2026-01-12 21:06:38 CET

- reply

#naddr1qq…a4u5

2026-01-10 23:51:54 CET

Are there any @nprofile…94rw operators for Adopting Bitcoin in South Africa yet?
I haven't started this year's conference list yet, but would love to make this the first conference of the year 😀
https://github.com/OpenTollGate/tollgate?tab=readme-ov-file#events
@nprofile…agd8 @nprofile…tzpz @nprofile…6lmj @nprofile…2884

2026-01-10 23:38:12 CET

- reply

Plenty of time to figure it out with us on the Island 😀

2026-01-10 23:18:11 CET

- reply

@nprofile…jejl

2026-01-10 23:17:11 CET

- reply

@nprofile…69ha

2026-01-10 23:03:58 CET

- reply

@nprofile…rscr

2026-01-10 22:46:14 CET

- reply

@nprofile…7976

2026-01-10 22:40:01 CET

- reply

@nprofile…qaxf

2026-01-10 22:24:21 CET

- reply

#nevent1q…re23

2026-01-10 22:19:27 CET

The 7th sovereign engineering cohort is an opportunity for us to figure out how to communicate without relying on authorities like IANA or ICANN.
Calling on all mesh networking wizards to unite for weekly in person demos, barbecues and hiking to solve problems that would otherwise seem difficult. Join us!
#naddr1qq…92je
Cc:
@nprofile…8ltw @nprofile…2884 @nprofile…evew @nprofile…46xv @nprofile…ex6x @nprofile…383m @nprofile…9stm @nprofile…f2el @nprofile…5yt6 @nprofile…sda7 @nprofile…tzpz @nprofile…yrsy @nprofile…8ltw @nprofile…cy97 @nprofile…f224 @nprofile…d245 @nprofile…vyxy @nprofile…n5a2 @nprofile…vea9 @nprofile…hu7t @nprofile…yrsy @nprofile…ptz7 @nprofile…lgxk

2026-01-07 12:56:20 CET

- reply

Du könntest heute zum Freifunk Stammtisch ab 20 Uhr in c-base kommen. Da findest Du bestimmt weitere Leute die meshtactic benutzen.
Ich persönlich habe meshtactic Geräte anzugeben, weil ich auf @nprofile…m2rw und WiFi HaLow (802.11ah) umsteige.

2026-01-07 00:19:19 CET

- reply

Dejavu

2025-12-30 10:56:18 CET

- reply

An amateur radio satellite based TollGate already exists - @nprofile…kq7x built it. Its just a question of time till its compatible with the TollGate protocol and accepts bearer instruments 😃

2025-12-30 10:03:05 CET

Buy internet from the airline
https://blossom.primal.net/17eaad3329db07b9874a86669b57a4464dc9383db2b8b0cc4fa017cd0ed2eb0b.jpg
Give away internet for free to confirm that there is demand
https://blossom.primal.net/414e49d67b07e925517572776d7e49f3e143d07dae60c2a783b75c11acb96202.jpg
Charge for access to the gateway
https://blossom.primal.net/88b18c8468aa4e33ef957d8add5e9c4c5f6a08d6d56be59d9452b94d01b97ebf.mp4
Altitude & location of internet purchase
https://blossom.primal.net/815e6d4a12588a3dc129ad0fc9accef2750fb62a8a6414e230c798b3c3c62427.jpg
https://blossom.primal.net/e121af4e093909ea6b71435eefcf26a5f79da26e730156e4a19b3fd0a7757e61.jpg

2025-12-26 17:15:32 CET

- reply

Well said!

2025-12-26 16:31:17 CET

- reply

It seems to me like DNN has the same set of tradeoffs as noDNS, but DNN has a global state thanks to Bitcoin. Where does DNN store the IP address that a name resolves to? Does it use nostr for this? Apologies if you already explained this..

2025-12-26 16:26:59 CET

- reply

When trying to understand new systems, I like to try to place them on that triangle to reason about the tradeoffs...

2025-12-26 16:26:10 CET

- reply

Are you familiar with zookos triangle?
https://en.wikipedia.org/wiki/Zooko%27s_triangle

2025-12-26 16:25:18 CET

- reply

Aah, so the name is human readable, but the TLD is a large random string - ie. the entropy that makes it secure. That makes sense. Does this mean I need to check the large random string like checking an npub to make sure I'm being redirected to the right IP address?

2025-12-26 15:48:45 CET

- reply

Thanks for the patient explanation @nprofile…u4cn. Getting a sense of the tradeoffs helps a bit, but I must admit that I still need to give it more thought before I fully grock your system. What do you mean by "no name scarcity"? Can others claim the same name that I have already claimed? I guess the cost of doing a Bitcoin transaction is what rate limits my ability to claim as many names as I want right?

2025-12-25 14:09:58 CET

- reply

That sounds really promising! It makes sense that Bitcoin would be the anchor for a global naming system, because Bitcoin is the closest approximation to a truly global database that we have.
Have you heard of the spaces protocol? I managed to set up the DHT client on my computer, but haven't tried securing and/or resolving a name yet. Would be interested in your thoughts...
https://spacesprotocol.org/paper/
https://docs.spacesprotocol.org/getting-started/fabric-dht
https://github.com/spacesprotocol/sips/blob/main/sip-0002.mediawiki
https://github.com/spacesprotocol/fabric
Unfortunately soveng is in person only, but it would be incredible if your able to join. The 7th cohort is all about networking, so your project would fit in perfectly..
Cc: @nprofile…205a

2025-12-25 04:35:55 CET

- reply

#nevent1q…eqss

2025-12-25 04:34:33 CET

- reply

Interesting. How do you ensure that other people can't claim the same name you already claimed? Ie. how do you ensure you have a global state?
Have you considered coming to SEC-07?

2025-12-25 04:13:01 CET

- reply

@nprofile…xz43

2025-12-24 16:30:42 CET

Who is going to tell them?
https://events.ccc.de/congress/2025/hub/en/event/detail/widerstand-gegen-debanking

2025-12-24 12:48:40 CET

- reply

Wouldn't want to be flying a plane over those branches

2025-12-22 10:42:45 CET

## BudaBit Demo Day application
### Title: TollGate auto connect with data measurement
Pitch:
TollGates turn on, connect to eachother automatically and start reselling access to the gateway while measuring data rather than time. The user can connect other devices to the password protected SSID of their TollGate to get regular WiFi UX without needing software that tops up their session on their user devices.

2025-12-20 19:18:24 CET

- reply

https://primal.net/a/naddr1qqv8xetr95crwtt5dpjj6mn9w3mk7unt94ehgctrdvpzpq7enxs5scju854msxd0xpjvpa4p94763rmgktrfyg0n5arpw8geqvzqqqr4gurnsh6y

2025-12-20 04:40:43 CET

- reply

Making retirement cool again

2025-12-16 18:21:22 CET

- reply

Remember talking about the cockroach that carries a @nprofile…508p @nprofile…w8n2 ?

2025-12-12 19:36:33 CET

- reply

@nprofile…zqac also knows a lot about this stuff. If only he had a proxy running on main net already.
Oh, by the way @nprofile…zqac I think I finally understand why latency is important even though bitaxes are happy to run at a loss in certain scenarios (like when it improves the UX of something). Apparently pools reject high latency shares because miners who do care about their margins don't want to be mining with high latency miners who don't care about margins.
Does this mean we need special pools for high latency miners or am I overlooking something?

2025-12-12 19:32:11 CET

- reply

The smallest useful thing you can broadcast is the latest block hash. The second most useful thing is the latest block template (see sparse pool by @nprofile…924l). These things can be obtained for free from block stream because it's a one way broadcast of data that everyone cares about.
Traffic from miners is different from traffic from Netflix, because the miners have very little traffic, but the traffic that they do have is very valuable on a per Byte basis.
Your two way link is especially interesting for miners who want to get their nonces to a pool ASAP. These miners already have a block template from spares pool or from block stream, but they need transportat to get their nonces out reliably. Depending on the energy source, they may not have an economically viable uplink, unless if they pay per Byte to use your satellite dish..

2025-12-09 13:15:41 CET

- reply

#nevent1q…028u

2025-12-09 13:12:47 CET

- reply

Jail DDoS incoming

2025-12-06 17:09:10 CET

https://image.nostr.build/f24e97804972dc9737ebee65558180e0aa54882840f014daf1149268bb18060f.jpg
#naddr1qq…92je

2025-12-06 08:34:03 CET

- reply

Sounds like it's going to be a really useful framework 😀

2025-12-05 10:42:41 CET

- reply

And @nprofile…wtmf satellite dish is still up too 😀

2025-12-03 13:20:26 CET

- reply

I guess a question of efficiency. Having things pre-installed makes sense if I only need them briefly and a large portion of my costs are setup & teardown. Perhaps what your making here is a framework for people to make their custom pre-installed environment...

2025-12-03 13:17:04 CET

- reply

Perhaps I'm missing the objective..

2025-12-03 13:15:46 CET

- reply

I like the idea of being able to pay for small amounts of compute and/or small periods of time. However, my concern is that the service might be specific to a very niche use case.
Can I run anything I want on it in the same way that I would with a VPS that I rented for 3 minutes?

2025-12-03 09:37:19 CET

- reply

Is this whole thing a layer on-top of VMs/containers for SATs? I still think there is value in having super generic machines that users can run whatever they want on...

2025-12-01 08:07:16 CET

- reply

Absolutely, and this machine is probably more beefy, so it should be able to run CDK..

2025-11-30 09:55:22 CET

- reply

I need to catch up quite a bit with my understanding of stage 2. I'll be sure to bring our older notes where you explained blinding/unbinding next time we meet 😀

2025-11-29 23:19:03 CET

- reply

Aah yes, if I recall correctly, at the time we thought stage 2 wasn't necessary and we thought wallets were just doing it for the sake of storing unlocked proofs. I guess stage 2 did have a purpose which we were overlooking at the time then..

2025-11-27 17:10:33 CET

Testing
https://lnbits.molonlabe.holdings/bitsatcredit/6e1faaf6356b43029124fdeb5f93a297

2025-11-26 11:28:38 CET

Incredible, this is the most long range @nprofile…3stq I have ever seen! There is no excuse not to be part of the network anymore. Let's transfer the cost of our infrastructure to it's users and let's figure out how to navigate large networks without authorities like IANA and ICANN.
We have more questions than answers. Join the 7th @nprofile…3ra5 cohort to help us figure out how to sync our Bitcoin nodes and to run nostr relays without relying on authorities.
#nevent1q…klrv

2025-11-24 00:10:08 CET

Thanks for making it happen @nprofile…4s3d , @nprofile…ah2e Et al.
#nevent1q…r5vs

2025-11-23 23:58:36 CET

Bitfest was incredible! Most of the people I spoke to belong at #SovEng

2025-11-22 01:34:32 CET

- reply

Meeting notes:
Dimi x86 based TollGate that runs in a VM and works over wireguard
Notes:
The x86 image is useful for machines like start9. Wireguard is required for the enterprise ISP features that will transform Elzonte in no time.
Could add reticulum to this. It deals with double NATing etc.
Compression for smaller routers:
https://github.com/OpenTollGate/tollgate-module-basic-go/pull/63
Merged and released dual SSID:
https://github.com/OpenTollGate/tollgate-module-basic-go/commit/e9aa0356a8691a9c32fe3bd3fa06b32e307d0ae9
Notes:
You can now connect to your TollGate's second password protected SSID to get internet access from your own router without paying it. This is good for your UX.
New version of release explorer:
https://releases.tollgate.me/
Notes:
Beautiful new release explorer. Has search. Can see raw events. Architectures are now in a drop down menu. The compressed package will be shown as a separate download button for the same architecture.
Conferences:
https://github.com/OpenTollGate/tollgate?tab=readme-ov-file#events-tollgates-will-be-operated-at
TollGate was already at 17 conferences this year
For better scalability: Call for ambassadors or people willing to demo at conferences or meetups
21 routers from einundzwanzig
Vote for 21 TollGate compatible routers to be distributed to meetups:
https://primal.net/e/nevent1qqsgdpfmj9t765dhtxqtaw08dapfqr4m3nnrssstrzqds3ahwln2gdcf360w6
Questions from the community
Notes: Casa De Lavada needs help updating its TollGate
https://sovereignhybridcompute.com/

2025-11-21 13:41:57 CET

- reply

Key: dbfd62df35f789d7

2025-11-21 11:55:07 CET

- reply

For some reason the zaps aren't showing in Amethyst. This is an issue on my end right? Do you already have a client that renders proof of burn events?

2025-11-20 09:23:04 CET

- reply

I think Marco has one, but I'm not sure how to access it. I treat things as persistent once they can be stored without the need of an email address...

2025-11-18 23:09:21 CET

- reply

@nprofile…g4th

2025-11-18 20:43:28 CET

- reply

@nprofile…3g9u

2025-11-09 23:04:52 CET

- reply

That's fine, we don't need to know your running a mint