02d769cb73

Memes

I would remind you all that on https://www.memeamigo.lol you can upload your own pictures and make them like christmas memes, adding stickers and fund items, plus you can embed sats into the image with cashu. Later the recipients can claim the gift with the same image.

Add sats here:


![](https://m.stacker.news/123449)

and claim here:


![](https://m.stacker.news/123450)


Reminder: MemeAmigo embed sats into postcards

DarthCoin

culture

![squat monopoly](https://m.stacker.news/122626)

As you guys showed interest in knowing more about the squatting scene in Amsterdam, so I decided to write the first instalment on my life as an aspirant squatter in Amsterdam. I am recalling this from memory. Note this was only my experience. The history of squatting in the Netherlands started in the 1960s and lasted till 2011 when it was finally prohibited by law. I only witnessed the last 5 years of this remarkable epoch of this subculture. Beyond my story, squatting history is hallmarked with big battles against the state/establishment that might pique your interest.

1. [Geen Woning Geen Kroning](https://en.wikipedia.org/wiki/Amsterdam_coronation_riots) (No Housing No Crowning; 1980): A major riot when squatters attempted to stop the inauguration of Queen Beatrix as a protest against the housing shortage.

2. [Vondelstraat Rellen](https://en.wikipedia.org/wiki/Vondelstraat_riots) (Vondelstraat Riots; 1980): Military intervention to remove the barricades and enforce the eviction of a squat at the Vondelstraat that became a major shelling point to express dissatisfaction with authority. 

https://www.youtube.com/watch?v=5VOTV9tcNIk

**Episode 1: The Squatting Manual**

My adventure started by attending my first kraakspreekuur (KSU; squat speaking hour) in [Joe's Garage](https://joesgarage.nl/), the main headquarters of the squatting community in Amsterdam-East at the Pretoriusstraat. A German guy called Momo led this group and he taught me the basics on a Tuesday night on how to find and open up your own apartment. Momo was a great guy. A computer hacker in his early 30s, brown hair and glasses. He ran an online squatting forum and a private squatting email server. Eloquent, smart, educated, charismatic, he was the Morpheus of my personal hack my own house journey.
I got the basic information this evening and ‘The Squatting Manual’ (English Guide: [De Kraakhandleiding](https://ksuoost.squat.net/englishGuide.html). This little self-published booklet that looked like a miniature pulp magazine contained all the information on how to pirate your own house. From finding a potential house, how to open it, how to connect utilities to make the home liveable, etc.. I was told to never let the manual fall into the wrong hands and burn it if the police would ever capture me one early morning. 

The first stage of finding a potential squat is to survey the streets in the area where you want to live. Everyday I went out on my bike through Amsterdam-East with a notebook to pen down all the addresses that appeared empty. By law a place needs to be empty for at least 1 year to make the squat legal. However you can't do in depth research on all the locations that seem unoccupied. You start out with ~100 addresses, but by checking them on different days and different times, you can quickly strikethrough 80%-90% of your potential targets. You check for moving curtains, lights, you put matches in the doors to record whether doors are being opened, you ask the neighbors (most valuable) what's the situation with that place and introduce yourself as the nephew of the previous renter, etc… 

Once you've got about 5-10 addresses that are clearly empty and verified empty for over a year, you have to research the finer details of the target location. Are there any renovation permits out, who are the owners, why is it empty, and how long is it likely to remain empty, etc. This first stage took me about 1 month of daily work, surveying and researching for about 2 hours a day.

Finally, I was down to 2-3 targets and I checked back in with the headquarters at KSU Oost. They actually kept a list of potential squats and I hit a match they had in their database. You might ask why they didn't give me this information beforehand. Well, the reason is that aspirant squatters need to prove their worth, seriousness and willingness in order to keep the community pure with individuals who can dedicate themselves to the squatting life. It's a tight-knit community that highly depends on cooperation and mutual protection against maffia and police. The so-called 'wild’ squatting, opening up a house without the oversight of a KSU headquarter, was frowned upon and considered unethical and egoic. 

That's it for episode 1. I hope you enjoyed this. In episode 2 I'll tell you about the day we broke into the [apartment at Ruyschstraat 32](/items/1349496), one of the 3 targets on my survey list.

---
FYI
@Signal312
@02d769cb73
@BITC0IN
@Artilektt
@optimism

Squatting Amsterdam Ep. 1 — The Squatting Manual

bitcoingraffiti

bitcoin

# Stealing people's coins is a red line

I find myself in a surprising position: I agree with @nvk. Here's what he [posted on X](https://x.com/nvk/status/1998765929837326470):

> UTXOs are sacred. 
> We don't fork to steal them.
> We don't fork to expire them.
> We don't fork cancel them.
> 
> This is the slippery slope.
> 
> This is the hill worth dying on.

I strongly agree with this statement. It's something that I've argued as evidence that things like BIP 110 and The Cat are not serious proposal. 

Surely @supertestnet is not going to come along and tell me that there is a soft fork that I am actively enforcing with my node which confiscated utxos...

# Did BIP 16 makes some coins unspendable?

Super recently posted about this Stack Exchange question on X: 

> The BIP turned a particular "hashlock" locking script pattern (`OP_HASH160 OP_DATA_20 20-byte-value OP_EQUAL`) into a "magical" bytecode pattern which, after authenticating an input's top stack element against the hash then also executes it using Script VM.
> 
> The BIP references 1 historical transaction that spent from an output that matched the pattern:
> 
> > These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) [1]. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. [2]. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).
> 
> which made me wonder - are there other, unspent, historical hashlock outputs which may have been made unspendable (if they weren't already) by introduction of the P2SH feature?

The answer to this question is provided by the same person who asked it:

> Even before BIP-0016 activation, there were some outputs that matched the P2SH pattern. Only one of them was spent before activation, and the rest have likely been made unspendable by the BIP-0016 upgrade since spending them would have to satisfy consensus rules not enforced when they were created. Total amount locked in those outputs was 0.044 BTC.

And they also provide a handy table of the utxos they believe were made unspendable by BIP 16.
 
Table 1: Outputs matching the locking script pattern OP_HASH160 OP_DATA_20 value_20 OP_EQUAL, extracted from blocks 0 to 173805.

| Block Height | TXID | Output Index | Satoshi Amounts | Locking Script | Status |
| --- | --- | --- | --- | --- | --- |
| 170052 | 9C08A4D78931342B37FD5F72900FB9983087E6F46C4A097D8A1F52C74E28EAF6 | 1 | 400000 | a91419a7d869032368fd1f1e26e5e73a4ad0e474960e87 | Spent |
| 170054 | B0539A45DE13B3E0403909B8BD1A555B8CBE45FD4E3F3FDA76F3A5F52835C29D | 1 | 400000 | a914e8c300c87986efa84c37c0519929019ef86eb5b487 | Unspent |
| 170434 | D0636198EA55FADEE5B4CCC07C85012DB7D07C2D25790B3AEC770C86617801C0 | 1 | 1000000 | a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87 | Unspent |
| 170442 | 9AB59E2D4BE16C470160EB9B9A9D9799EAF29AF0461AEA131E748659D806FA1A | 0 | 1000000 | a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87 | Unspent |
| 170442 | 658FC92061F1C4125D5CD1034EB8A1F09BFEBD32A988D855EB7EE63689759A21 | 0 | 1000000 | a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87 | Unspent | 
| 170556 | 510B5A44935109E249A704C2900AA9D8303166062E81D2AC852C965B6266DCEE | 0 | 1000000 |  a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87 | Unspent |

Super also found [another Stack Exchange question](https://bitcoin.stackexchange.com/questions/117321/what-was-the-first-ever-bip-16-transaction-read-not-bip-13) about when the first BIP 16 spend occurred and which was answered by the same user:

> Before P2SH activation, they could be spent as just hashlock contracts. After P2SH activation, they could only be spent if the hash preimage also happened to be a redeem script that would pass execution.
> 
> The TXO created in block 170052 was actually spent in block 170060 as hashlock, not P2SH, because P2SH rules weren't active at the time. 

If all of this feels too confusing, just think about it 

# So was it a mistake or was it intentional?

Ever-helpful, Super comes to the conclusion that freezing these five utxos (one utxo was specifically exempted) was indeed intentional.

Super found [a note](https://github.com/bitcoin/bitcoin/blob/13891a8a685d255cb13dd5018e3d5ccc18b07c34/src/validation.cpp#L2305) in Bitcoin Core that says:

```
    // BIP16 didn't become active until Apr 1 2012 (on mainnet, and
    // retroactively applied to testnet)
    // However, only one historical block violated the P2SH rules (on both
    // mainnet and testnet).
    // Similarly, only one historical block violated the TAPROOT rules on
    // mainnet.
    // For simplicity, always leave P2SH+WITNESS+TAPROOT on except for the two
    // violating blocks.
```

# Intention doesn't even matter: if you run anything greater than Core v 0.6.0, you are actively preventing five utxos from being spent

Super [argues](https://x.com/SuperTestnet/status/2001184144219410774) that it is inconsistent to be against confiscation in one case but to be totally fine for it in another case. 

> For those wondering how this relates to the spam debate, some people on the Core side like to say they oppose any attempts to disable the utxos of spammers because confiscation is unconscionable. But their node is actively keeping old utxos unspendable too

He [also says](https://x.com/SuperTestnet/status/2001179025033588872):

> If the best counter you've got is "it happened 13 years ago and there's a chance it was by accident" then I'll remind you that the confiscatory rule is still in your node right now. You can eliminate it if confiscation violates your principles. You can't claim ignorance.

# The nuances

Vojtěch Strnad (who also edited the original Stack Exchange question) replied to Super with some nuance about these five utxos:

> There is a major difference, the outputs made unspendable by P2SH were anyone-can-spend before (i.e. weren't secured by a signature) and so had no ownership guarantees to begin with. Also we're talking about 0.044 BTC at 2012 prices, less than a single dollar.

I suspect it does not much matter whether the intent of the original PR was to confiscate those five utxos or not. I do, however, recognize that there may be a difference along the lines Vojtěch describes: freezing nyone can spend outputs may be less problematic than freezing outputs secured by private keys. But Super's point is pretty strong: there are five utxos that are actively considered unspendable by everyone running the post segwit Bitcoin code. 

This makes it difficult for people like nvk and me to say "UTXOs are sacred, they are a red line." If that is true, why aren't we making a fuss about the utxos that were frozen by BIP 16?

Super [makes a good point](https://x.com/SuperTestnet/status/2001180110951469364) here: 

> If you think it's okay to maintain *that* confiscatory rule to avoid bad consequences, maybe show a little grace toward those who want to add a new confiscatory rule to eliminate different bad consequences.

I still do not feel that confiscating people's utxos should be treated lightly or accepted as a reasonable course in changes to block validation rules; however, I can't deny that I run a node that has confiscated 5 utxos worth .044 BTC. 

Supertestnet's gotcha: BIP16 also confiscated coins

Scoresby

econ

How _CRAZY_ that [it's still](https://en.wikipedia.org/wiki/Laffer_curve) around!

![](https://m.stacker.news/118645)

It's a beautiful piece of simple economics, not exactly _directly_ applicable in the real world but conceptually accurate enough that it's worth bearing in mind always. 


“If you tax a product less results/If you subsidize a product more results./We've been taxing work, output and income and subsidizing non-work, leisure and un-/employment./The consequences are obvious!”
---

> In 1974 economist Art Laffer sketched a new direction for the Republican Party on this napkin. Displeased with President Gerald Ford’s decision to raise taxes to control inflation, four men got together at a Washington, DC restaurant to think about alternatives. Laffer was joined by journalist Jude Wanniski and politicians Dick Cheney and Don Rumsfeld. Laffer argued that lowering taxes would increase economic activity. Wanniski popularized the theory, and politicians Don Rumsfeld and Dick Cheney carried it out.

Today I Learned that the Laffer Curve Napkin Is on Display in the Smithsonian

denlillaapan

In addition to rolling out bitcoin acceptance to Square terminals, CashApp allowing users to send bitcoin from dollar balances, and the incorporating a btc map of merchants into CashApp, Block is also hosting a coffee and donut food truck in Washington, DC, to raise awareness about the stupid way that US tax code treats bitcoin. 

As part of this effort they've also launched this website: btcismoney.xyz

![](https://m.stacker.news/118228)

Square's advocacy website for a de minimis exemption

lightning

If you run a PUBLIC routing node you must do heavy lifting to manage properly your liquidity.
And here is an interesting proposal.
Let's see what knowledgeable stackers think about it.

>I use the auto-fee tool in Lightning Terminal for fee management. It works well to direct flows toward specific peers, but it doesnt not currently help in receiving flows from peers.
>Could negative inbound fees be incorporated into the tuning algorithm? This helps entice flows toward my node, which I otherwise can only control by lowering fees on a swath of other channels.

https://github.com/lightninglabs/lightning-terminal/issues/1157

Let's see what stackers think about this proposal

Excellent advice from Rizful today. This is start for a Bitcoin Circular Economy.

---
Make money with your Alby Hub or Rizful Node in 3 steps
1. find Shopify merchants who want to accept Lightning
2. run a BLFS instance for those merchants (50+ merchants on a $5/mo VPS)
3. take a small percent of sales

All of this is possible with BLFS. Directions:
https://github.com/MegalithicBTC/BLFS

---

Source:
nevent1qvzqqqqqqypzp9lcfzkucnrzwe59leyyym09v9yg0j99rtdqg6xwcu0m4yuzw2g3qqs0ygvxhek57e4xw73mx6l9p40zg2y9r4rvrlp3lvq0ae6uzt9ak6qgg2pxz

A merchant example using this option:
nevent1qvzqqqqqqypzp9lcfzkucnrzwe59leyyym09v9yg0j99rtdqg6xwcu0m4yuzw2g3qqsrw2k9j3h2ms3s4kr5h9kgv2r3r89d2nc33mwl852mlx9cqf44knsamgy9y

Make money with your Alby Hub or Rizful Node in 3 steps

tech

https://www.youtube.com/watch?v=WfzcKAzgB9s

I have had on my to do list to sit down and mess with BitChat.

This video was helpful to see the basic functionality.

I have a vision of assembling some base station that can be deployed in a hurry.

Vision:
Android tablet, solar panel, charger controller, weather proof box, and a long pole to get it up high in the air.  To act as a dedicate relay station.


BTC Sessions -  BITCHAT Tutorial and Demo

Wumbo

https://www.youtube.com/watch?v=7GeCq1qwqjc

I like the premise of how this will discourage advertiser from doing ads in the long term, by causing their ad budget to be used up.

However in the short term it would seem like a way for the Google and other companies that sell ad space to earn the increase revenue.  At least until their customers protest the click data.

https://adnauseam.io/

>As online advertising becomes ever more ubiquitous and unsanctioned, AdNauseam works to complete the cycle by automating ad clicks universally and blindly on behalf of its users. Built atop uBlock Origin, AdNauseam quietly clicks on every blocked ad, registering a visit on ad networks' databases. As the collected data gathered shows an omnivorous click-stream, user tracking, targeting and surveillance become futile. Read more about AdNauseam in this paper.

Louis Rossman - "Why I uninstalled ublock origin"  Adnauseam new plugin

I'm getting frustrated with my hosted lightning node on Voltage.

There are at least 3 issues I've come across:

__LNBITS + NWC connection issue__ - no NWCProvider extension available; can't update LNbits
__LNBITS + NOSTR ZAPS ISSUE__ (zaps not showing in nostr, although I receive them)
__THUNDERHUB VERSION ISSUE__ - can't update & can't pay Lightning Addresses without updating)

It is $25/month, running and managing it is still quite technical, and I also need to manage my own liquidity. I don't want to self-host a node because I don't have a computer to keep online 24/7 (and keep connected even in case of power or internet outage), plus in the long term, I want to be travelling again. 

If anyone here has experience with both: __How does Alby Cloud compare to Voltage?__ Or is there anything else you'd recommend?

Also, if I were to migrate from Voltage to Alby, how much (if any) of my node & settings can I "take with me" to the new provider (i.e. open channels, LNbits instances, BTCPayServer setup, etc.)?

Voltage vs Alby Cloud

Kontext

Bitcoin Postcards - Send Memories with Bitcoin

sime

tutorials

With [Bitcoin Core synced](https://stacker.news/items/1265616) on your [Ubuntu server](https://stacker.news/items/1263116), you have the "library" of all transactions. Now, we install the "search engine."

**Fulcrum 2.0.0** is a high-performance Electrum server that indexes your entire blockchain. This allows your desktop and mobile wallets (like Sparrow) to query your node for balances and transaction histories instantly. This ensures your addresses, balances, and financial history never leave your own hardware.

Fulcrum has been historically prone to corruption of data. This has been solved in the newest release of 2.0 which we'll use in this guide. No longer do you need to fear power outages corrupting your data.

### Phase 1: Download & Verify

First, we'll create the directories for Fulcrum's software and its database. The database *must* live on your NVMe drive for performance, so we'll place it in your home directory (`~/fulcrum_db`).

```bash
# Create a directory for the binaries and one for the database
mkdir -p ~/fulcrum ~/fulcrum_db
```

Next, we download the latest release, its checksums, and the developer's signature. (The `v2.0.0` release is a major update; we'll use that as you specified).

```bash
# Set version for easy upgrades
FULCRUM_VERSION=2.0.0

# Create a downloads folder and enter it
mkdir -p ~/downloads
cd ~/downloads

# Download the binary, checksums, and signature
wget https://github.com/cculianu/Fulcrum/releases/download/v${FULCRUM_VERSION}/Fulcrum-${FULCRUM_VERSION}-x86_64-linux.tar.gz
wget https://github.com/cculianu/Fulcrum/releases/download/v${FULCRUM_VERSION}/Fulcrum-${FULCRUM_VERSION}-shasums.txt
wget https://github.com/cculianu/Fulcrum/releases/download/v${FULCRUM_VERSION}/Fulcrum-${FULCRUM_VERSION}-shasums.txt.asc
```

Now, we verify the download. This is not optional.

```bash
# Import the GPG key for the lead developer, Calin Culianu
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys D11F6013C7561B43CD8A6630E260946D33226505

# Verify the signature on the hash file
gpg --verify Fulcrum-${FULCRUM_VERSION}-shasums.txt.asc Fulcrum-${FULCRUM_VERSION}-shasums.txt
```

Look for a **"Good signature"** message. This confirms the hash file is authentic.

```bash
# Check your download against the trusted hash
sha256sum --check --ignore-missing Fulcrum-${FULCRUM_VERSION}-shasums.txt
```

You **must** see the line: `Fulcrum-${FULCRUM_VERSION}-x86_64-linux.tar.gz: OK`

### Phase 2: Install & Generate SSL Keys

Now that the software is verified, let's install it into the `~/fulcrum` directory you created.

```bash
# Extract the archive
tar -zxvf Fulcrum-${FULCRUM_VERSION}-x86_64-linux.tar.gz

# Move the binaries and example config into your ~/fulcrum directory
mv Fulcrum-${FULCRUM_VERSION}-x86_64-linux/* ~/fulcrum/
```

Next, we'll generate a self-signed SSL certificate so your wallet can connect to your node over an encrypted channel.

```bash
cd ~/fulcrum
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 \
  -keyout key.pem \
  -out cert.pem
```

This command will ask you a series of questions (Country, State, etc.). Since this is a private, self-signed certificate, you can press **Enter** to accept the defaults for every prompt.

### Phase 3: Configuration

We will copy the example config and edit it to match your setup.

```bash
cd ~/fulcrum
cp fulcrum-example-config.conf fulcrum.conf
nano fulcrum.conf
```

Make the following changes. **Pay close attention** to the user (`satoshis`) and the `rpcpassword`.

```ini
# --- Fulcrum Config ---
# This is the main database directory.
# It MUST be on your NVMe.
datadir = /home/satoshis/fulcrum_db

# --- Bitcoin Core Connection ---
# Point to your bitcoind service
bitcoind = 127.0.0.1:8332

# These MUST match your bitcoin.conf
rpcuser = satoshis
rpcpassword = YOUR_STRONG_PASSWORD_FROM_BITCOIN.CONF

# --- Server Ports ---
# Allow other computers on your network (like your desktop)
# to connect over an encrypted channel.
ssl = 0.0.0.0:50002

# Point to the SSL certs we just made
cert = /home/satoshis/fulcrum/cert.pem
key = /home/satoshis/fulcrum/key.pem

# Optional: Uncomment and set a banner file
# banner = /home/satoshis/fulcrum/banner.txt

# --- Performance & Privacy ---
# We have 24GB RAM. bitcoind is using 4GB.
# Let's give Fulcrum 5GB (5120MB).
db_mem = 5120

# We are a private node, no need to peer.
peering = false
```

Save and exit (`Ctrl+X`, `Y`, `Enter`).

#### (Optional) Create a Welcome Banner

This is a great way to verify you're connected to your own node.

```bash
nano ~/fulcrum/banner.txt
```

Create some ASCII art (e.g., from `patorjk.com/software/taag/`) and save the file. When you connect with Sparrow, this text will appear. Note: `I had to ensure there was an additional space or the ASCII got misfigured.`

### Phase 4: Create the `systemd` Service

This service will automatically start Fulcrum after `bitcoind` is running.

```bash
sudo nano /etc/systemd/system/fulcrum.service
```

Paste this configuration, which is corrected for your user (`satoshis`) and your service dependencies.

```ini
[Unit]
Description=Fulcrum Electrum Server
# We require bitcoind to be running first
After=bitcoind.service
Requires=bitcoind.service

[Service]
# Run as your 'satoshis' user
User=satoshis
Group=satoshis

# Run the Fulcrum binary and point it to our config file
ExecStart=/home/satoshis/fulcrum/Fulcrum /home/satoshis/fulcrum/fulcrum.conf

# Give the database a long time to shut down gracefully
TimeoutStopSec=30min

# Set a high file limit for the database
LimitNOFILE=8192
Restart=on-failure

[Install]
WantedBy=multi-user.target
```

Save and exit.

### Phase 5: Launch & Monitor

We're ready to launch. First, open the firewall for the encrypted port (`50002`).

```bash
sudo ufw allow 50002/tcp
sudo ufw reload

# Reload systemd, enable, and start Fulcrum
sudo systemctl daemon-reload
sudo systemctl enable --now fulcrum.service
```

Now, monitor the sync. Fulcrum must index the entire blockchain. This is a very I/O-intensive process that will take **many hours to a full day**. Your NVMe drive will be working hard.

```bash
journalctl -fu fulcrum.service
```

You will see it processing blocks. Let this run until it is caught up and is only reporting new mempool transactions.

### Phase 6: Connect Sparrow Wallet

Once Fulcrum is synced, open Sparrow on your desktop:

1.  Go to **File** -\> **Preferences** -\> **Server**.
2.  Change the "Type" to **Private Electrum Server**.
3.  **URL:** Enter your node's LAN IP (e.g., `192.168.8.50`).
4.  **Port:** `50002`
5.  Check the **"Use SSL"** box.
6.  Click **"Test Connection"**.

Sparrow will show a pop-up warning you that the certificate is "self-signed." This is expected and secure. Click "Allow" to permanently trust your node's certificate. The light in the bottom-right corner will turn green.

Tutorial for Fulcrum 2.0.0: Your Private Electrum Server

expatriotic

I published my perspective on Bitcoin governance: https://pretyflaco.github.io/bitcoingovernance/

Where does Bitcoin derive its censorship-resistance from? And how do we preserve it?

Sharing some frameworks I've found helpful 👇

The main insight: Bitcoin's unique value comes from censorship-resistance, and the two magic ingredients to achieve it are:

✅ Free users
✅ Free software

-> Censorship-resistance requires free users
-> Free users require free software

Traditional governance asks "who decides?"

These systems are easy to co-opt and can therefore never preserve censorship-resistance.

Bitcoin governance asks "how do we preserve free users?", and this is they key to preserving censorship-resistance.

For developers, this means:

-> Optimize for user agency
-> Default to user choice over "optimal" outcomes

Remember: we're building infrastructure for freedom.

These are just my current thoughts - governance philosophy evolves with experience - but it's clear to me that censorship-resistance is a derivative of free users.

There is a leap of faith required in bitcoin’s governance model.

We must trust that when users are given genuine freedom and access to good information, they will make choices that preserve what makes bitcoin valuable.

Users who want bitcoin to remain censorship-resistant will choose software and rules that maintain that property.

Users who prefer other properties may make different choices, but the network’s evolution will reflect the aggregate of all these individual decisions.

When we take the leap and trust that free users will make the right choices, Bitcoin succeeds.

I would love to hear perspectives from builders, users, and researchers working on or thinking about these problems.

https://pretyflaco.github.io/bitcoingovernance/

A perspective on bitcoin governance

flaco

MeshSense is a simple, open-source application that monitors, maps and graphically displays all the vital stats of your area's Meshtastic network including connected nodes, signal reports, trace routes and more!

![screenshot](https://m.stacker.news/107794)

MeshSense: Meshtastic monitor

m0wer

> Frigate is an experimental Electrum Server testing Silent Payments scanning with ephemeral client keys.
>
> It has three goals:
> 
> 1. To provide a proof of concept implementation of the Remote Scanner approach discussed in the BIP352 Silent Payments Index Server Specification (WIP).
> 1. To propose Electrum RPC protocol methods to request and return Silent Payments information from a server.
> 1. To demonstrate an efficient "in database" technique of scanning for Silent Payments transactions.
>
> This is alpha software, and should not be used in production.
>
> **[...read more at github.com](https://github.com/sparrowwallet/frigate)**

Frigate Electrum Server

0xbitcoiner

There is an xcancel thread I have been reading, it's a long one and I don't know why some of these issues haven't been better discussed (at least to the best of my knowledge.)

Doesn't it relate intimately to the conversations around "data"... and Knots and "spam mitigation???"

The conversation is between @Murch and Chris Guida (who's not on Stacker News?). I have tried to post the xcancel links here... it's not easy but I will do my best with links and screenshots as there are some fundamental questions... I wish I had answered.

1) First of all, there is a *fundamental disagreement* as to whether or not Bitcoin transactions of a "monetary" purpose can outbid those of a speculative or "arbitrary-data" origin.

Chris says that arbitrary data has significantly more demand... than payment data for you know *actual Bitcoin* [monetary] transactions.

![](https://m.stacker.news/107232)

Chris makes the comment that demand for arbitrary data (relative to monetary) may be 1000x... and the only thing holding back the arbitrary data floodgates is filtering (and/or "hostility").

![](https://m.stacker.news/107233)

Murch says that's not true as Bitcoin payments can (and will) be 'more efficient'... while also alluding to the reality of limited blockspace and the need for *higher value* transactions...

-----------------

The conversation then goes on to suggest that... the demand for "arbitrary data" (Jpegs on chain + memecoin 'tickers') is so great as to be 1000x that of Bitcoin [monetary]...

To which I say
> If that's true *we are DONE...*

Bitcoin is supposed to support, magnify, and ultimately align with economic incentives. If the 'economic incentives' are for those relating to "arbitrary data" and its storage and "sale" in a *very* speculative fashion...

*How the hell are filters supposed to work???* Aren't people supposed to WANT Bitcoin and WANT to transact with it? How do you "filter" out something with 1000x *greater demand* that people want to USE?

Wouldn't the JPEG people simply spool up their *own* nodes with which to transact/speculate AND/OR relay???

![](https://m.stacker.news/107243)

(Isn't this basically "information-warfare" on-chain?)
----------------

2) Then the conversation shifts to the nature and *reasons* for the bloat of the UTXO set. *How* did the UTXO set get bloated and why???

Chris and Murch discuss BRC20s and Runes transactions (over 50% of transactions today) and how that resulted in more UTXOs.

@Murch says that BRC20 "inscription" tokens *can* and will in many cases be swept up and consolidated. This is something I (tried to?) address in an earlier post https://stacker.news/items/1211686/r/028559d218

*This* is an example of such a consolidation... right?

![](https://m.stacker.news/107235)

From their conversation:

![](https://m.stacker.news/107236)

My understanding is that the reason for the 'gazillion outputs' in the BRC20 token "transactions"... was because the spammers were "pretending" that the more outputs, the more "tokens" they could generate in a single transaction.

The thousands of outputs didn't *themselves* carry any data... they just represented more "tokens" (which is of course completely arbitrary) so the more OUTPUTS the more TOKENS.

![](https://m.stacker.news/107237)

But why... exactly would a token system need to be designed this way??? Why not have more tokens with *fewer* outputs? 2 to 1? 5 to 1? 10 to 1... isn't ALL OF THIS completely arbitrary???

![](https://m.stacker.news/107238)

I read this whole thread (LONG conversation between Murch and Chris) 3 times before it dawned on me how *arbitrary* all these data-storage-token-speculation-schemes are. Who decides "which sat" is special? And how can filters keep degens from coming up with their own...

"json-based client-side validation colored coin scheme"? 🤦

----------------

3) The conversation *then* briefly turns to the economics of consolidating the "dust" from BRC20s... where the AI bot says that such dust never gets consolidated because it's "irrational to ever spend them."

![](https://m.stacker.news/107241)

In an imperfect world... don't we *want* these low fee-rate consolidations???

![](https://m.stacker.news/107242)

4) Finally... the conversation turns to what to do about "UTXO bloat" in the future?

Chris writes (and makes an interesting point):

![](https://m.stacker.news/107245)

So what DOES keep the degens from creating a new "opreturn-rc20" token meta-protocol in the future?
Isn't op_return (with 80 bytes + plus the inscription "hack") enough space to create an almost *endless* number of 

- token protocols
- memecoins
- plus other speculative schemes?
- What makes a "Rune" special when it could be called a "Loon" or "Dune" or "Moon" or "SafeMoon"...

The fastest degen to create the greatest number of outputs and consolidate/NOT consolidate them...
Wins the prize???

Which Sat is first? Which is 'last?' Which tokens get 'named' first depending on 'which' exact output?

-------------------

After all, what prevents a GOVERNMENT from *attacking* Bitcoin by spending a *relatively* modest amount of money, taking Bitcoin and "dividing it up" into *millions* of UTXOs for which only THEY have the keys?

- Without arbitrary data?
- Without op_return?
- Or using the Witness 'exploit'?

If the goal were to 'harm the chain' it's not the 'arbitrary data' doing the harm... UTXOs could be doubled/tripled in number without being filtered by Knots OR Core or without *any* arbitrary data added.

Within the most conservative relay policy, without changing consensus...

What is the answer to such an attack???

![](https://m.stacker.news/107247) 

![](https://m.stacker.news/107248)

(These "transactions" don't increase the UTXO set beyond op_return... so they aren't an "attack"...
Or are they?! 😉)

Murch and Chris have a conversation - What is Going on Here???

028559d218

*I don't agree with Zucco's opinion about spam, but I think he has been an interesting voice in the debate -- also the thread to which he is replying is pretty interesting: Adam Back and Luke Jr discussing filters*

> Satoshi added many mempool filters himself, also mentioning spam explicitly (famous Lady Gaga discussion with Andresen). Virtually all Core developers for years agreed with and built on this approach, including current champions of the removal path (you can find mentions in this sense of Sipa, Gmax, Achow), often mentioning spam explicitly, with the main exception of Todd, who for many years argued for a mempool=blocks fee-rate-based approach, now culminating in the LibreRelay fork. To some degree, full-RBF was an instance of this debate (while not spam-related) where most devs (including Luke-jr actually agreed with Todd. Slowly, more people moved on Todd side (the only explicit reference I've seen so far about the change of heart is the tweet from Achow about "growing up").
> 
> In 2021, an unintentional bug shipped with Taproot (but not connected with Taproot itself) defused one such filter (datacarriersize) for some txs. In 2023, shitcoin scammers abused the witness discount to create a 4Mb block (impossible to create with non-spam txs), using txs that *would have* bypassed the filters thanks to the bug *if broadcast* (but it's noteworthy that the spam was *not* broadcast, it was sent directly to a colluding mining pool, paid offband, so even non-broken filters wouldn't have stopped it). After that, it seems like an important priority for the current Core mantainers is to move Core towards a more LibreBitcoin-style. Personally, as an illiterate pleb who listens to podcasts, I consider the technical arguments in this sense legit and overall directionally sound, even if they don't justify the prioritization/rush, especially considered the widespread opposition by many power-users, builders, entrepreneurs, advocates/activists. 
> 
> Some people, including myself, are under the impression the the rush/priority is more driven by ego struggles, social dynamics and power games which have *little* to do with technical mempool policy debates: avoiding (inevitably-painful) self-reflection on the 2021 bug, justifying social proximity by many current contributors to the shitcoin scammers involved in this kind of spam (eg: Rijndael), not hurting feelings of colluding mining pools currently funding Core development but also monetizing OoB payments for spam (eg: Mara), regulating old grudges with maverick/outcast/contrarian devs (eg: Luke-jr, especially after the conflict with him escalated since the FBI hinted at a Core meetup as the origin of a nasty cybercrime at Luke's expenses), venting envy by many contributors that said maverick/outcast/contrarian devs received investment money (eg: many of them wrote to Dorsey publicly to try to convince him to remove his support to Luke-jr efforts towards mining decentralization), overall political devides (including a Bitcoin version of the overall "DEI" and "woke" related cultural wars).
> 
> Regardless of my (and other people's) interpretation (cf last paragraph) of the reasons mempool policy tweaking is considered a priority (I have to add there *are* two weak but not-irrelevant arguments for that: Todd made a case a mempool=blocks approach is safer for L2 unilateral exits, some devs made the case that *because of* the current spam attack we should actively engage with harm-reduction by opening up the less damaging attack surfaces like op_return to hijack some pressure from the more damaging ones like UTxOset), the effect of the conflict was also a very bad management of the GitHub repo, with obviously good-faith, balanced, nuanced, polite and insightful comments hidden as "spam" (ironic), disagreeing parties with lots of skin in the game banned from the repo, contentious PRs closed only to be insta-reopened to let some ACK from friends sneak in and close them again, etc. That also escalated further the conflict.
> 
> There are some things happening off-line as well which escalated things: for example some fairly neutral but not "aligned" developers have been excluded from in-person Core meetups, after having been criticized for not taking a strong enough position in this debate. Some of us get to know about these things from personal conversations, but the involved parties often ask not to publish details, in order to avoid further retribution. So we end up with some public outspoken figures (including for example Mechanics) raising red flags about an overall Core problem, but most viewers not being able to verify any details. Then it becomes a religious/tribal choice of "camps": every argument on one side is a "lie". On my personal account, I can say that some philosophical issue (people claiming absurd things about the nature of spam or censorship) triggered me more than the policy debate itself. I could have kept more cool if less people called filtering "censorship" (utter self-contradictory nonsense) or spam "impossible when valid/expensive (utter self-contradictory nonsense).

Giacomo Zucco on the history of filters in Bitcoin

PROBLEM: ICANN, DNS, HTTPS 

Centralized control over the internet and our usernames. Every brand in the world has to pay rent similar to property tax to exist on the internet. Certificate authorities are not signed by your personal keys, instead they are signed by central authority keys. Transactions must be approved and can be rerouted to different addresses when going through https.

Domains are digital assets and should be permissionless.

SOLUTION: SPACES PROTOCOL https://spacesprotocol.org/ 

Spaces are memorable sovereign handles anchored in Bitcoin with minimal on-chain footprint. They are easier to share compared to an npub, and can be used to sign things just like a regular public key.


WHAT MAKES SPACES SPECIAL?
Spaces are anchored in Bitcoin, the most secure Proof-of-Work blockchain, and have the following properties:

Primary spaces are community identifiers, capped at ~3600 per year, acquired through permissionless auctions on the Bitcoin blockchain.

Each primary Space is a community that may issue sovereign handles off-chain known as subspaces.

Spaces AND subspaces (once allocated) are permissionless and as secure as Bitcoin itself! No bridges, slashing, or any kind of optimistic security.

The spaces protocol is designed with zk-light clients in mind making these identities verifiable on resource constrained devices.

Subspaces do not need to trust the community operator once allocated, and they can do 100% of their transactions on-chain if they wish.

Minimal on-chain footprint.

Spaces vs. ENS
For full verification, you can sync the entire spaces protocol with a pruned Bitcoin full node on an old Raspberry PI. Bitcoin is the most secure Proof-of-Work blockchain today, and it's relatively lightweight compared to running an Ethereum node. The majority of ENS integrations trust centralized third-parties defeating the whole purpose of decentralized identities.

Spaces enable auctions with arbitrary bids implemented directly on the Bitcoin blockchain. Auctions are designed as a fair competition for naming rights. Instead of distributing spaces on a first-come, first-served basis, the protocol employs a bidding system. This approach helps ensure that valuable names don't all end up concentrated in the hands of a few quick actors.

Spaces are restricted to 10 a day to prevent market flooding and to ensure each name receives adequate attention during auctions.

Pre-auctions
Users propose spaces they're interested in by placing bids

Each proposed name accumulates interest based on the value of the bids it receives

Names advance to the auction phase when they become one of the top 10 highest-bid spaces on a given day

The protocol releases up to 10 spaces per day which is about 3600 per year

Auctions
Once a name receives sufficient interest by being one of the top 10 highest-bid spaces on a given day, it enters the auctions phase.

Auctions last for 10 days.

Anyone can bid just as they normally did in pre-auctions.

To prevent sniping, any last-minute bids extend the auction by one day.

Claim Period
Once the 10-day auction concludes, the winning bidder may claim their space.

It's crucial for the winner to claim immediately because:

The auction remains open indefinitely until the space is claimed.

Someone can still outbid you during this period.

Where do proceeds from auctions go?
All proceeds from the auctions are burned. This means that the BTC used for bids is permanently removed from circulation. This approach ensures that no single entity profits from the auctions. Names aren't anyone's property to begin with! The Spaces protocol is built on cypherpunk principles, emphasizing decentralization, privacy, and individual empowerment that means:

No Premine: There was no initial allocation of names to the developers or any centralized entity.

No token: BTC is the currency!

Open and Permissionless: Anyone can participate in the auctions and use the protocol without seeking permission from a central authority.

Transparent: All auctions happen directly on the Bitcoin blockchain. CHECK IT OUT FOR YOURSELF https://explorer.spacesprotocol.org/ 

👀Permissionless Naming

anon

Tether Fun Unbelievable Details - Part III

Hi folks!

@Alice_and_the_Wonderland has developed an improved LNemail web client. And we have now made it the official inbox. See https://stacker.news/items/1023808 for the original post.

Here's a screenshot:

![screenshot](https://m.stacker.news/105501)

Way better than the original one. Many thanks!

Feel free to open feature/improvement requests and pull requests at https://github.com/lnemail/lnemail

LNemail: Improved inbox frontend

lnemail

> In total, the median prompt—one that falls in the middle of the range of energy demand—consumes 0.24 watt-hours of electricity, the equivalent of running a standard microwave for about one second. 

> That’s significant, because in this measurement, the AI chips—in this case, Google’s custom TPUs, the company’s proprietary equivalent of GPUs—account for just 58% of the total electricity demand of 0.24 watt-hours. 
>
> Another large portion of the energy is used by equipment needed to support AI-specific hardware: The host machine’s CPU and memory account for another 25% of the total energy used. There’s also backup equipment needed in case something fails—these idle machines account for 10% of the total. The final 8% is from overhead associated with running a data center, including cooling and power conversion. 

33x improvement in energy efficiency year over year is nothing to sneeze at: 

> The report also finds that the total energy used to field a Gemini query has fallen dramatically over time. The median Gemini prompt used 33 times more energy in May 2024 than it did in May 2025, according to Google.