It's time for everyone to run their own Relays. On their smartphones especially.

It's time for big public relays to start adding some restrictions on the content they accept and from whom.

Poor man's poll: Is it

A) e-cash

B) ecash

C) eCash

D) none of the above

?

Yes i was thinking along similar lines. Also given the scenario requires physical proximity of sender and receiver, the payer already has internet access at that moment, which makes several things possible.

To be fair, iirc, this was the *exact* application of ecash that was imagined by people like Chaum, Brands etc. in their original papers (vendor in meatspace has network access, customer doesn't) so I'm definitely not claiming this doesn't make sense.

Two things we have in common: We love BITCOIN, and we love FREEDOM.

This happened during a demo of Tollgate, a tool for OpenWRT routers which let's users pay for WiFi with sats-denominated ecash. Friend of mine connects his phone to the wifi hotspot and is shown a captive portal that says it wants ecash from a certain mint. Friend doesn't have ecash. But I do.

I whip out my phone and create a 100 sat token, show it to him as a QR code, which he copies and pastes into the captive portal. A few seconds later, he's online. 1 sat = 1 minute internet.

We're just scratching the surface of what's possible.

Isnt a VPN a bad analogy? Nobody can see your tor traffic.

isnt it more like DNS?

how many people are using i2p? what kind of anonset are we talking?

Now we are able to write a post or send/receive DMs on #nostr using a #meshtastic device ( #LoRa ).

We are building a Open-Source app to use by your own as a service in a machine but also we will set up a website where you can manage your settings to allow sending posts and DMs from/to #nostr from/to a #meshtastic device.

Main cases of use (We thought, but probably more):

- Interact with #Nostr in remote areas.

- Interact with #Nostr with a device with no internet connection.

- Interact with #Nostr with a really private way.

- Interact with #Nostr with a really cheap device (less than $50).

- Interact with #Nostr with no tracking from third-parties.

Stay tuned.

Network-level privacy of the various coinjoins from the coordinator's point of view, ordered from most vulnerable to least.

Whirpool (regardless of whether you use tor or not, it's useless):

A (192.168.1.1) - D (192.168.1.1)

B (192.168.1.2) - C (192.168.1.2)

C (192.168.1.3) - B (192.168.1.3)

D (192.168.1.4) - A (192.168.1.4)

Wabisabi (let's assume that a user has two entries. I put the second one because it is a centralized service, but it really has a good implementation):

A (192.168.1.1) - D (192.168.1.4)

B (192.168.1.2) - C (192.168.1.5)

C (192.168.1.3) - B (192.168.1.6)

D (192.168.1.1) - A (192.168.1.7)

Joinstr(The VPN is a centralized point but the coordinator is a relay, and the relay will only see the same ip, although you could associate the two, vpn and relay, if a 3-letter agency intervenes, you can mitigate by changing relay between rounds):

A (192.168.1.1) - D (192.168.1.1)

B (192.168.1.1) - C (192.168.1.1)

C (192.168.1.1) - B (192.168.1.1)

D (192.168.1.1) - A (192.168.1.1)

Joinmarket, the coordinator is the taker, this mitigates the collection of the information, therefore it is not vulnerable to a network level tagging attack (from my point of view).

A (192.168.1.1) - D (192.168.1.1)

B (192.168.1.2) - C (192.168.1.2)

C (192.168.1.3) - B (192.168.1.3)

D (192.168.1.4) - A (192.168.1.4)

Just discovered BIP431.

My reaction is to be reminded of Shakespeare's "oh what a tangled web we weave, when first we practise to ... use game theory instead of cryptographic verification."

At least *restricting* scope (TRUC) makes the scope of the problem.. less intractable? Even that seems debatable.

Could you add some comment for the guys like me who maybe understand the idea but not the actual flow? Do you use nostr to coordinate the coinjoin transaction?

What is this for?