02d769cb73

tech

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

bitcoin

> 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

Scoresby

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.

Google released data on how much energy an AI prompt uses

k00b

> Economists at the Bank of International Settlements just proposed that *any coin* that has *ever* passed through a no-KYC wallet should be banned from regulated services.

L0la L33tz nprofile1qqsd3fhv7rped64g77dyf9l7ndmae9mkxdz37099cc6wyzr9jytxg7cvak07l

![allow list](https://m.stacker.news/105165)

Bank of International Settlements Paper Proposes KYC For Non-Custodial Wallets

> Proving that @elonmusk 's theory that Stealth Fighters can be tracked with cheap cameras is correct by using a brand new technique that I made to detect asteroids by precisely tracking planes better than any current radar with just three $30 web cams.

$30 webcams track stealth planes via asteroid detection - @ConsistInconsis

> “Civilization is the progress toward a society of privacy. The savage’s whole existence is public, ruled by the laws of his tribe. Civilization is the process of setting man free from men.” – Ayn Rand

> The creator must be an individual free from other men. He has to think on his own, act on his own, and achieve his own ends. He can only do so if he is not coerced by other individuals. 

Bitcoin Mixing | The Ethics

Abdel [(@dimahledba on X)](https://x.com/dimahledba) posted this pretty cool note about using starks to prove that a bitcoin transaction is not "spam."[^1]. 

People can stick arbitrary data in a transaction by making it look like any number of things: a public key, a script, a merkle root, a hash. Abdel is proposing a way of using stark's to prove something like a public key is an actually valid public key that corresponds to a private key. Whether or not you think spam is a problem, it's always delightful to see bitcoiners wonking away at solutions.

[^1]: I'm still in denial that any valid transaction can be spam, but the conversation has been beaten to death at this point -- but I'm still going to stick some scare quotes around the word.

Here's [Abdel's post](https://xcancel.com/dimahledba/status/1953085228240580894#m) so you don't have to go look it up:

> Hear me out, PONS: Proof Of Non-Spam for Bitcoin!
> 
> I was discussing with @LukeDashjr about various usage of ZKP for Bitcoin, and he came with this intriguing idea to use Zero Knowledge Proofs to fight spam on Bitcoin (without breaking some designs such as BitVM).
> Initially I was sceptical, but the more I think about it, the more I am convinced that it could be a very interesting idea to explore.
> 
> Just to be concrete, here are some examples of valid / non spam materials that could be theoretically proven via a system like PONS:
> - Schnorr public keys: Prove knowledge of corresponding private key
> - Hash preimages: Prove knowledge of data hashing to claimed values
> - Taproot scripts: Prove leaf scripts are valid Bitcoin Script, not arbitrary bytes
> - Merkle roots: Prove correspondence to actual Merkle trees of valid elements
> 
> As usual, I like to experiment and play with ideas, so I started to implement a proof of concept of this idea, for the minimalistic simplest example here that is: prove that a public key is "real" and not a "fake" public key.
> 
> You can see in the demo video below the following flow:
> - Generate a Schnorr public key and its corresponding private key
> - Create a digital signature of an arbitrary message
> - Run a Cairo program that verify the signature against the public key
> - Generate a STARK proof of the Cairo program execution using STWO prover
> - Verify the STARK proof using STWO verifier
> 
> Sorry @LukeDashjr I know that you consider Rust as a woke language haha, but for now we have the STWO prover and verifier only implemented in Rust, so I used it for the demo. We can easily integrate the STWO verifier in Bitcoin Core or Knots via ffi though (as we already did in another POC).
> 
> So of course here it's completely overkill to use a STARK proof for this and you could do it much more efficiently without a ZKP, but it is to show how the architecture could look like end to end.
> 
> There are many interesting design questions, like how to make nodes / miners play nicely and prioritise transactions with valid proofs, how to incentivise the generation of proofs, how to make it efficient and not bloated, etc.
> 
> I am curious to hear your thoughts on this idea, and if you think it could be a good idea to explore further.

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

There's also [a video demo](https://x.com/dimahledba/status/1953085230593487089)

pons: Proof Of Non-Spam for Bitcoin - AbdelStark

econ

When you actually learn the ideals of socialism, specifically central planning, you realize that many American politicians aren't really all that against it. I'm not talking about Democrats only either. There are many institutions in American society that are highly socialist in how they are facilitated. Here are some examples.

What do I mean? Mainly I'm referring to central planning, and if you think about central planning being the far left of the spectrum, free markets would be the other extreme. The things I will list are far more to the left than we probably acknowledge.

## Hospitals

While most hospitals are privately owned, most people are not aware of how centrally planned they have become in most states. In order for a hospital to be built, there is a process that has to be followed called a Certificate of Need (in most states). I first learned about this many years ago when I asked my father‑in‑law why there was only one hospital in our area. The hospital has a terrible reputation and record. Many people will drive over an hour and a half to avoid using it. Knowing this, I was perplexed about why another hospital hadn't popped up to compete with them. So how is a Certificate of Need obtained? Through a committee of mostly politicians—politicians who get campaign money from the existing medical providers. And this, this classic pattern we should all be aware of, is why we don't have true market competition for hospital care. I mean, imagine if we didn't have these impartial and educated arbiters of public need to decide how many hospitals we need in an area...

## Utilities

Power companies, water companies, and sewer systems are almost always either completely centrally operated by cities or so heavily regulated that they are private in name only. At best, we have a government‑established monopoly. The government decides which company is given the right to operate, and no competition is even allowed. For the state, it’s a great solution. Think about PG\&E in California. The public thinks of PG\&E as a private company. But in reality, their pricing of power, their ability to build power generation, and their governance are almost completely dictated by the state. I honestly wonder if it wouldn't be better if the state just dissolved the company and ended this farce. At least then the public would point their fingers at the correct root problem: central planning.

In California—which isn't alone in this, by the way—the state restricts the building of new power generation. The state hasn't allowed a significant power generator to be built since 1985. The state uses far more power than it generates, and the power companies must import power from other states. Of course, this drives up the cost of power and is the main reason why power is more expensive in the Golden State. It doesn't have to be this way. Allow competition. Allow companies to come in and build new power generation that isn’t these solar science experiments. The vast majority of building that has been done in the state is for natural gas plants. They are basically required due to the spikes and valleys produced by grids dependent on solar.

## Firefighters

The volunteer firefighter is becoming a thing of the past. Over the years, I've had several friends who used to do this. Firefighting started as a volunteer and privately run operation. It still is in some places, but this is exceedingly rare. One need only look at what happened in Southern California to see the consequences of centrally planned fire prevention and firefighting.

## The Fed

The biggest example and most broadly influential is the Fed. The price of money (credit) is centrally planned and managed. It galls me every time I hear a conservative decry socialism and then defend the Fed.

## Price Controls

Price controls are, on the surface, largely discredited. Even the average person will laugh if you suggest them in many situations. But the poisonous idea of central planning at the center of the rot of socialism is far too present in so‑called free nations. These ideas have not been destroyed. Until they are proven to be terrible, we will suffer the consequences. We see price controls in the form of rent control, insurance regulation in many states, and anti‑price‑gouging laws.

## What Did I Miss?

I could go on and on about this. I could probably think of a dozen or more examples of central planning in our so‑called free nation. What is a big one I missed? What is a big one that bugs you?


Socialism In Plain Sight

kepford

lightning

It goes straight to the point: Free lightning address. Get zapped on Nostr. Connect to hundreds of apps.

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

[Megalitic](https://megalithic.me/) team just launched a new service few days ago, a new @Rizful_com  web wallet, a straightforward experience to get a lightning wallet and start routing sats with zero-conf and setup. No channel opening required. Custodial, yes, but no KYC. A perfect decoy wallet.

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

You'll need an account, but good news: anonymous email services and VPNs are OK.

Each account gets: 
- 10 Lightning Addresses
- 10 Nostr public keys
- Yes, you can import your existing `npubs` (no `nsec` required)
- Receive zaps and payments FREE 
- Send sats for a small fee (depending on network conditions)
- Payments settle in less than one second

Use it on your pc or save it as PWA in your mobile.

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



NEW RIZFUL wallet: The easiest FREE way to get started with Lightning.

supratic

crypto

Often, I skim most of the quantum stuff because the explanations trend heavily towards the technical and I don't see how spending a ton of time trying understand the math is really that useful for a layman like myself. 

Still, it's nice to have a general sense of things, and here we have both @niftynei ([the linked article](https://insider.btcpp.dev/p/sphincs)) and @bitcoin_devs (https://stacker.news/items/1064943, https://stacker.news/items/1065841) giving us more accessible explanation of a new signature scheme proposed by roasbeef. 

Tl;dr - quantum resistant signatures are bigger than the signatures currently used by Bitcoin. "A Segwit v1 Schnorr signature is 64-bytes of onchain data; comparable SPHINCS+ benchmark sigs are 3-7k bytes." But unlike some other hash based signature schemes, SPHINCS+ can safely sign multiple times. 

The real reason I like nifty's article is that she does a great job of explaining some of the obstacles we are dealing with in developing and adopting a QR scheme. 

SPHINCS+ - explained by nifty

# WOTS (Winternitz One Time Signatures) explained

**Part 3: SPHINCS+**  
1/

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

2/

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

3/

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

4/

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

---

We’ve now seen how WOTS works.  
But it’s not quite secure enough on its own…

**WOTS+**, with checksums and bitmasks, patches those holes.

---

**Next Post:**  
👉 *WOTS+*

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

📌 Follow [@Bitcoin_Devs](https://x.com/Bitcoin_Devs) so you don't miss it!

**Resources:**  
- https://sphere10.com/articles/cryptography/pqc/wots
- https://er4hn.info/blog/2023.12.16-sphincs_plus-step-by-step/



WOTS (Witernitz One Time Signatures) explained

bitcoin_devs

nostr

I’ve designed a decentralized advertising protocol on top of Nostr, Lightning and proof of work. 

The full specs are drafted [here](https://ngengine.org/docs/nip-drafts/nip-ADS/).

Unlike current systems, which rely on tracking and profiling users against their own will, and even the proposed [Nostr-DAN](https://github.com/nostr-protocol/nips/pull/955) which merely makes user data public, so... arguably even worse, this approach flips the script entirely.

Advertisers broadcast signed bids with metadata to nostr; user apps then independently choose which ads to display, by filtering them relay-side and client-side.

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

When a user app selects an ad, the negotiation begins: either party may reject or bail out the negotiation at any time, incurring in a proof‑of‑work or rank penalty on the other side.

If the negotiation succeed, the payout is sent instantly via Lightning to the `lud06` or `lud16` address set in the kind 0 metadata event of the "app" pubkey, that could be a pubkey assigned to the app that the user is running or of the user itself.

The advertiser’s side of each negotiation is managed by a delegate service, that can be a trusted third‑party service, or self‑hosted if preferred. These delegate services can apply additional heuristics and checks to decide when to process a payout or impose a pow penalty if the counterparty attempts to cheat.

This integrates with the existing Nostr protocol and is flexible enough to support various advertising models, such as:
- The classic ad model targeted to a specific, centralized app    
- A Brave-reward style reward model that compensates users directly    
- A Satogram-like, open broadcast model that any app can pick up and display

This is a crude, mostly complete, implementation of the protocol: [NostrGameEngine/nostrads](https://github.com/NostrGameEngine/nostrads) 
that is demoed on: [https://nostr-ads.ngengine.org/](https://nostr-ads.ngengine.org/)

I built a decentralized Advertising Network protocol on Nostr

rblb

![](https://m.stacker.news/101561)
Just shipped BTC & Lightning payments 🚀

@hongbaobitcoin
 use BTCPay Server payment processor :

- 0% Fees & No Third-party
- Open-source, censorship-resistant and free.
- Self-hosted: 9$ / mo (soon)

API is not as great as Stripe but it does the job.
Dev time : 2 weeks
https://hongbaob.tc/

BTC/Lightning payment is done

SalmaChan

I hadn't heard of the paper @supertestnet discusses here. But as always, I sure do learn a lot from what he says. 

His nostr note is worth a read if you want to learn a little about lightning privacy and the way people might attack it. 


Super Testnet reviews paper analyzing lightning privacy attacks

The LNP/BP Standards Association is excited to announce **the final production-ready release of the RGB smart contracts consensus layer (v0.12)!**

From today, all RGB contract developers and issuers can deploy contracts on both testnet and Bitcoin mainnet using this stable consensus release.

**⚠️ Important:** For security and ecosystem consistency, we strongly recommend re-issuing any contracts created with pre-release versions using this final v0.12.

**🛠️ Please note:**

This is a consensus layer release. It will be followed by releases of the standard library and applications. The consensus layer is unique among RGB libraries because it defines contract stability: only changes at the consensus level can break backward compatibility for contracts. Therefore, with this final v0.12 release, contracts are now forward-compatible.

Read the full release details on https://rgb.tech/blog/release-v0-12-consensus/

RGB consensus layer released to production

dr_orlovsky

Recently, Wallet of Satoshi [announced they were releasing a self-custodial wallet.](https://x.com/walletofsatoshi/status/1923875750165479768) And then yesterday, Lightspark [announced WoS would be launching on Spark](https://x.com/spark/status/1940168641301119094).

I didn't really know much about [Spark](https://docs.spark.money/home/welcome), so I thought a brief explainer would be nice.

# Spark is a statechain

So, you start by deciding to deposit onchain funds into a Spark Entity. This is a statechain. A statechain is a way of sharing utxos. 

If there was a single 1btc utxo and you and 9 other people all had a presigned transaction that sent a portion of the 1 btc to your personal address, you could say you were sharing the utxo. But that isn't very useful.

If, however, you could safely change the amounts on your pre-signed transactions so that it changed the relative portions owned by each person, you could transfer bitcoin from one person's ownership to another's without changing anything onchain. This is what statechains do: with the help of a coordinator or group of coordinator's they distribute pre-signed exit transactions updated to reflect any transfers of bitcoin between the people using the Spark.

Before you deposit, you have to work with the operators of the Spark Entity (there are [currently only two](https://docs.spark.money/home/faq)) to create an aggregated public key. You and however many operators are in the Spark Entity create this public key using [a version of FROST](https://docs.spark.money/spark/frost-signing). 

This public key is used to create a taproot deposit address, which will receive your deposit into the statechain.[^1]

[^1]: Something that isn't clear to me is how this onchain deposit becomes part of the shared utxo that the Spark is using....or do they share a ton of utxos and yours is just one more added to their pot?

Before you send funds to this address, you and the operators in the Spark Entity collaboratively sign two transactions that together serve as your unilateral exit to the chain.

You hopefully will not have to broadcast these pre-signed transactions, but they are your security assurance: if you feel people are cheating you, you broadcast and get your money back.

Once both these transactions are signed by you and the Spark operators, you can deposit funds to your deposit address.

# Transferring funds via Spark

Transfer of funds in Spark (and other statechains) is achieved by tweaking the Spark Entity's key and signing a new exit transaction for the receiver of the funds.

The sender of funds on Spark could still try to broadcast their old presigned transaction, but it includes a timelock that is designed to be slightly longer than a timelock on your presigned transaction -- so you have an opportunity to publish your exit transaction before them.

However, if all the Spark operators fail to delete the old key they were using, the user who sent you funds could ask them to participate in signing a new exit transaction which includes the funds supposedly received by you. 

So you have to trust the Spark operators to delete their keys -- which is what they say they will do. 

From [the Spark "Trust Model"](https://docs.spark.money/spark/trust-model) page:

> ***If*** an operator follows this protocol, the transferred funds are secure, even against future coercion or hacking. Spark strengthens this model by using multiple operators, ensuring that as long as one (or the required threshold) deletes their key, users remain secure and have perfect forward security. (emphasis added)

This is trust assumption no. 1 in Spark: operators must delete old keys.

# Why people might use something like Spark

Spark allows users to send funds to each other by changing their respective share of ownership of a single utxo without changing the onchain spending conditions of the utxo. 

So 4 people could send funds back and forth between each other without ever needing to publish a transaction onchain (as long as the Spark operators are doing what they say and deleting old tweaked keys with every transfer).

This is pretty cool because transfers can be instant and low fee, and you could have a whole lot of people sharing one single utxo.

# "No, the new Wallet of Satoshi is not 'self-custodial'"

@bluematt posted [a very helpful clarification](https://stacker.news/items/1020261) about what self-custody is and what it is not.

> Spark is, of course, much better than a classic custodial wallet - it allows for unilateral exit if the operator shuts down and deletes their keys (once they finish implementing it) - but it still requires fully trusting the operator. If the operator changes the code running on their server and swap coins with folks, they can steal coins going forward.

I've already discussed the first trust assumption (operator must delete their key), but bluematt's second point is also important: you don't know what kind of code the Spark operators are running.

I suppose there is a world where if the wallet app you are using is open source and if you trust that a lot of people are reviewing the code on it, it could make sure that the cryptography the operators are using is real and correct -- although perhaps I am wrong. I'm not a cryptographer. 

While Spark says they are [open source](https://github.com/buildonspark), I couldn't find out if Wallet of Satoshi is. So as far as I can tell, running WoS, you don't have any assurances that your Spark operators are running the code they say they are.

So trust assumption no. 2 is that you trust Wallet of Satoshi because you don't have anyway of seeing what the Spark operator's are doing.

It's fair to question whether this counts as self-custody (in the same way it's fair to question whether ecash is self custody[^2]). I think it is better than custodial WoS. But it's probably not great to call it a self-custodial bitcoin wallet. 

[^2]: ecash is self custodial, but it's not bitcoin.

# Want to learn more about statechains?

Shinobi recently wrote an [article about statechains for Bitcoin Magazine](https://bitcoinmagazine.com/technical/bitcoin-layer-2-statechains), but I didn't find it too helpful in understanding what is going on here. 

But Shinobi also has an [older article about Mercury Layer](https://stacker.news/items/408927/r/Scoresby?commentId=409041) that I found a little better (even though it's solely focused on Mercury's version of statechains).  

The Mercury Layer AMA from 2024 was somewhat helpful, particularly @tptrevethan's response [here](https://stacker.news/items/408927/r/Scoresby?commentId=409041).