m0wer

Satoshi also mentioned that address reuse should be avoided (in the white paper in fact), and that's no argument for changing the consensus rules to reject address reuse transactions. Not saying either one is a good idea, just pointing out the difference between "shouldn't" and "can't".
Also, Satoshi is not a god. Definitely an awesome person or group of people. But not something to follow blindly.

2026-07-16 15:04:59 CEST

- reply

2026-07-16 06:52:33 CEST

- reply

The latter. It involves an intermediate step which has onchain transaction fees, but no swap fees.

2026-07-15 23:12:34 CEST

- reply

Voilà!

2026-07-15 22:16:36 CEST

- reply

Yeah... It does.
I do hope that a more active ecosystem also attracts more liquidity.
The channels don't need to be long lived. Makers can use them as inputs for CJs (cooperative close directly into a CJ). So it's not really locked liquidity as long as the peer is online. They can also close them, ideally after the balance has shifted.
The problem I see with the automatic sweep and many other similar ideas, is that they lack the incentive to do so. They would be paying fees for something that's good for future takers privacy, but only costs them money. And takers don't know the "quality" of makers UTXOs. Apart from that, they would leak a lot of info by consolidating so many UTXOs at once...
The incentives are a bit tricky. I thought that the taker "forcing" them to get change as channel opens, or at least having takers prefer makers that do support that, is a nice "trick". Then they can do whatever they want with it. Ideally, being swap providers, lnproxy providers, and being able to just use that shared UTXO as their CJ inputs, is enough of a motivation to keep it (instead of paying fees out of their own pocket to close the channel as soon as they get it).

2026-07-15 22:09:20 CEST

- reply

Nice catch 😜
Takers might need to "fake" a swap whenever they want to spend. But if they do so, the onchain fingerprint is "perfect". A maker could give an equal amount P2TR otuput to a swap claim address (onchain could look like a 1 input 2 outputs tx). The "maker" has change from the swap, but the other "branch" of that swap are now someone else's. That might do whatever with it. How could you tell if it was a real swap or not?
But there are other ways. Takers can also get channel opens as change outputs. Which could then be spent in part (splice, swap out, rebalance, ...) or fully (ideally cooperatively as well). And of course, makers can also eventually spend!
Probably by the time we get there we can come up with simpler ideas though.
The challenge definitely is complexity.

2026-07-15 22:02:06 CEST

Decentralized lnproxy (provider discovery through Nostr) working on signet :-)
PR: https://github.com/lnproxy/lnproxy-relay/pull/31
Try it at: https://m0wer.github.io/lnproxy-webui2/?network=signet
BTW this is a nice web LN wallet for testing on signet: https://ln.signet.coinbin.org/

2026-07-15 19:05:46 CEST

- reply

The idea for now is that they have their own public channels for that. They can use the private ones they know of if they want to route for LN->onchain swaps. Or they could pick a neighbor to wrap an LN invoice of theirs for a onchain->LN swap, the swap requester then pays to the other nodes pubkey and the emitter receives it through the private channel they share, shifting the balance from the original CJ change.
There are many things to keep in mind though, but let's see how it unfolds.

2026-07-15 18:38:29 CEST

Let me present you what could be the future of JoinMarket and hopefully a great tool for Bitcoin privacy and fungibility.
First of all, there is the motivation. JM makers have an onchain fingerprint, that although it's hard to follow, limits the privacy achieved by the takers. The full details are at https://gist.github.com/m0wer/a228c625fcb6a27c32e298ec903dfc44
But to save you some time, here the main problems described there are: unique enough maker fees, co-spending of inputs, makers never spending, ... Which in the worst case scenario, would mean that a pure onchain observer could potentially cluster some makers across mixdepths and reduce the anonymity set by one of CoinJoins where they participate.
So what can we do? Well, we can use this chance to bring JM to the next level. And create such a transaction graph "mess" that becomes a chain analyst nightmare :-)
Let me explain. We can't ever get fully rid of the links between UTXOs onchain, or at least not without a way more complex multi taker model that leads to Knapsack "dense" transactions. But we can strive for something, that is that no single party ever has all the information.
The idea is the following. JM makers could become Lightning Network swap providers. Like Boltz, like SwapMarket, like electrum swapserver. Using Taproot swaps and advertising through Nostr. LN swap users get a simple and trustless client side web UI, makers get "fresh" UTXOs from onchain->LN swaps and the opportunity to "spend" CJ outputs for LN->onchain swaps. Oh, and another source of fees. LN swap users get cheaper swaps from the increased competition.
But this is not enough. We need to break the subset sum analysis onchain. We want to stop maker clustering from the root. Here is the next idea, JM CJ participants (makers and taker) could get their change as an LN channel open. Or two, with random other peers and the change amount split randomly between both channels. So a maker that has a 10 M sats input in a 5 M sats CJ no longer gets just a clear ~5M sats change, instead, two LN channel opens where the balance is hidden. Maybe 2M sats in one and 3M sats in the other. But an external observer wouldn't know. Not even which channel is whose!
You could say, well, but an active attacker could probe those channels balance. Maybe, but not really. Those channels would be private simple taproot (HTLC based, not PTLC yet unfortunately), so not advertised to the network. And, BTW, onchain they look like any other P2TR output BTW. Advertised only when needed with a SCID alias that does not reveal the onchain UTXO. But hey, who knows, maybe some peer node that gets the SCID could try to probe it. Fear not! There's another ingredient coming to the mix.
lnproxy is a great service to hide the destination node of an LN BOLT11 invoice by having a relay/proxy node wrap it. The payment hash is the same, only the recipient can settle the payment. But whoever sees the wrapped invoice sees the relay/proxy pubkey instead of the destination one.
Why not decentralize lnproxy through Nostr and then makers can be lnproxy providers as well? Just to add a little bit more noise to their LN activity and help move the balances around. So that if these change as channels ever close (cooperatively) the onchain fingerprint those not help understand what happened in the opening CJ. Or that UTXO can still be used as CJ inputs if signed cooperatively. Or, of course, as LN channels for swaps of lnproxy. Some kind of noisy spin of CoinjoinXT.
What we need for this and what we're currently working on at jm-ng:
- A JM taproot only pit.
- Decentralized lnproxy.
- Decentralized LN swap providers.
- Protocol wiring for the change as channel CJ coordination.
- People to actually use this and not be overwhelmed by the complexity.
But if we manage to make this work, we will have awesome onchain and LN privacy. And a way for service providers to earn money anonymously by providing privacy to others. So it's definitely worth a try :-)

2026-07-15 16:44:04 CEST

Introducing Muse Spark 1.1
https://ai.meta.com/blog/introducing-muse-spark-meta-model-api/
Sad that it's not open weights :(
https://stacker.news/items/1525344

2026-07-15 13:30:56 CEST

- reply

BTW release notes now include a section with the config.toml template diff.
No need to apply everything everytime, just whatever new settings or default changes you're interested in (if you had set them, otherwise the new defaults automatically apply).
#nevent1q…7y4y

2026-07-14 21:10:26 CEST

- reply

opencode FTW

2026-07-14 16:49:07 CEST

https://github.com/joinmarket-ng/joinmarket-ng/releases/tag/0.34.0
Automatic history import for existing wallets, fee quantization defaults for better privacy, coin control labels, local mempool API support, bug fixes, and security hardening.

2026-07-14 14:26:58 CEST

- reply

I would guess that's just a fee reserve right? Not the actual cost.

2026-07-12 16:51:00 CEST

- reply

wtf

2026-07-12 16:38:40 CEST

- reply

So, what if JM makers "gambled" their change? Maybe chunks of it?
Just a random idea: Could the probabilities be adjusted so that if maker A that "has" 1M sats change and maker B that "has" 3M sats, instead get proportional chances (¼ and ¾ respectively) to win 4M sats? Maybe they're willing to play this game for a expected value of 0 but a positive expected value of privacy gain.
I guess it doesn't work with more than 2 participants, but if it did, I'm sure many JM takers would be willing to gamble their change, for either a 10x that makes it worth it to deal with it (toxic change), or just lose it.

2026-07-10 00:49:03 CEST

- reply

superspeeded by #nevent1q…ydlk

2026-07-09 21:57:34 CEST

Wasabi coordinator tagging attack explanation and PoC: https://gist.github.com/m0wer/2e2f0a3241d8e7651ffdda4435e729ec

2026-07-09 15:01:40 CEST

You are fully trusting the coordinator with your privacy when using Whirpool (Samourai). Here are some practical attacks with a PoC.
https://gist.github.com/m0wer/e701bf5934474935c459b5e84e5d4e1b

2026-07-07 19:46:48 CEST

- reply

In many cases the default variance is not enough to overlap with any other maker (and even when it is, the anonymity set might not be great).
When several maker do overlap in fees, randomization becomes "harmful" IMO. Because it then helps track an individual maker by following their "randomly unique" fee through the orderbook.
This second part is arguable. But for a simple message to reach makers and give them an "easy" fix, I think it is better to not get into much detail (but the links expand on this for anyone interested).

2026-07-07 13:57:46 CEST

JoinMarket makers with unique enough fees are easily clustereable across mixdepths and don't provide much privacy to takers that choose them.
Imagine there is only one maker that charges 0.123% fee. An external observer can identify that maker's equal amount outputs when they are provided as inputs for another coinjoin with the same fee (observable onchain).
So I would encourage makers to select one of these quantized fees and disable randomization. This is an opt in change that joinmarket-clientserver and joinmarket-ng makers can apply on their own.
The more makers on the same quantized fee, the better anonymity for them and consequently for takers that pick them.
More info at https://joinmarket-ng.github.io/coinjoin-simulator/mainnet-deanon.html and https://github.com/joinmarket-ng/joinmarket-ng/issues/508
https://blossom.primal.net/85c865af60dfba6d9e990b7a700fee698e37310c0c7f0fd6dcb724ea24ce1696.jpg

2026-07-05 16:41:19 CEST

JoinMarket makers can be clustered (across mixdepths). Two ways:
- Easily if their CJ fee is unique enough and reused between rounds.
- Harder by gathering co-spending thought many rounds and waiting for the intersection to be narrow enough.
It's easier said than done in practice. Bit it's still something to improve.
Here is a more detailed explanation of the problem and possible solutions that could bring JM achieved anonymity to the next level.
https://gist.github.com/m0wer/a228c625fcb6a27c32e298ec903dfc44
Feedback welcome!

2026-07-05 16:21:06 CEST

Nice podcast. Bitcoin is unstoppable, but you are not.
Privacy is what makes you not worth attacking.
https://youtu.be/0_hlkmpw1sk

2026-07-05 11:43:22 CEST

- reply

Tumbler (sweep) works in Jam V2 with jm-ng backed😎

2026-07-05 09:54:46 CEST

- reply

You said makers know "all the takers". I said makers know only as much as a passive onchain observer. Which is what that comment talks about.
The tumbler works, and its functionality can be achieved manually as well. Additionally, I've implemented options like https://github.com/joinmarket-ng/joinmarket-ng/pull/280 that hide the taker onchain fingerprint.
And currently working on many other improvements at the ecosystem level.
JM is not perfect and I'm happy to point out its flaws. Makers knowing "all the takers" is not one of them.

2026-07-04 11:54:48 CEST

- reply

It's important to note the JM is a market. There are offers with 0 fees. And offers with rather high fees. The question is how much Sybil attack risk you're willing to tolerate.
I honestly don't think Whirlpool is great... You really are trusting the coordinator with too many things: ensure fresh liquidity, not isolate all participants into Sybil rounds (it could just give a unique round ID to each request), and then there's also post mix cleanliness which I don't think most users do well. And with fixed denominations it's even harder to do that right.
Wasabi coordination is nicer IMO but there are similar tagging attacks the coordinator could do. And there's also the post mix problem.
Maybe I would also recommend it for newbies. Because risking privacy from the coordinator ia better than nothing.
But I really think the solution is a market and is decentralized. That's why I work in JM. It's almost impossible to prevent tagging attacks completely with central coordinators.
And BTW it looks the most used Wasabi coordinator runs behind a Cloudflare tunnel. Meaning Cloudflare could do some interesting connection timing analysis passively and link inputs together and even get some info on the output mapping. And of course it could selectively drop connections and so on. And since the round success rate is around 16% for large rounds (iirc). So that's really bad IMO.
Good thing of not making money from people using JM is that I'm free to talk about flaws and limitations. This is would be very hard to do for a company running a centralized coordinator whose existence depended on it being used.

2026-07-04 11:35:53 CEST

- reply

True.

2026-07-04 11:28:38 CEST

- reply

Yes! jm-ng is backwards compatible, so it can use the existing liquidity and provide it as well.
Here is an orderbook watcher that has more details about makers and directories: https://joinmarket-ng.sgn.space/

2026-07-04 11:24:43 CEST

- reply

In JM, makers don't know anything else about the taker other than what an external onchain observer sees, and their own input-output mapping (of course). The taker is the coordinator and signs last. Each maker sees the whole unsigned transaction and signs their inputs. JM has other "flaws" though.
In Wasabi and Samourai you are trusting the coordinator not to attack you. But it could. See: tagging attacks.
I think we would all be better off if Bitcoin privacy wasn't about "cults".

2026-07-01 13:29:45 CEST

- reply

Fair point. It was more of a clickbaity opinion than a rigorous idea.
With using it wrong I meant using AI to avoid thinking rather than using it to enhance thinking.
That's just one aspect of it, of course if there's a task that you don't enjoy doing and AI can do it good enough, it's logical to use it for that.

2026-07-01 12:51:51 CEST

- reply

I've never been more intellectually challenged in my life. AI has taken over all the "simple" tasks such as waiting for tests and fixing failures, dealing with dependencies, writing documentation, ... And I get to deal with the more complex stuff way more often than before.

2026-07-01 12:49:10 CEST

If AI is making you "think less", you are using it wrong.

2026-06-30 19:34:34 CEST

- reply

Sure. I think its goal is to explain the timeline and core concepts only.

2026-06-30 15:45:09 CEST

- reply

Blame @nprofile…kuag 🤪
I originally posted it there but then on nostr the markdown links are stripped out and appear at the bottom (at least on Primal).

2026-06-30 14:55:44 CEST

Jam V2 beta (JoinMarket WebUI)
https://github.com/joinmarket-webui/jam/releases/tag/v2.0.0-beta.0
TLDR: Big frontend rewrite with many improvements. Using [https://github.com/joinmarket-ng/joinmarket-ng/](https://github.com/joinmarket-ng/joinmarket-ng/) as the backend.
A standalone docker image for fearless beta testers is coming next.
Any and all feedback is highly appreciated.
Please know, that there are still open issues and refactorings needed before the final release.
https://stacker.news/items/1517235

2026-06-30 14:16:29 CEST

- reply

where was it?

2026-06-30 11:47:34 CEST

- reply

"""
~August 2026
Mandatory Lock-in
If not locked in early, mandatory signaling begins — blocks that don't signal are rejected as invalid, guaranteeing lock-in.
"""
bip110.org

2026-06-30 07:13:39 CEST

- reply

Sure, only if over the difficulty threshold. But that's what pools count anyway, and would be impractical to fake it. The same principle of mining itself.
But they have to be verified! The novelty here is that until now pools just cared about the coinbase transaction, now they might have to care about all! And I still don't know the answer to my original question of what will OCEAN do about that.

2026-06-30 07:09:25 CEST

- reply

Sure, but the ordinary "race" part is very relevant. Same will happen on the non BIP-110 side of things (that's what I meant).
In any case, a miner seeking profitability only, wants to be on a pool where all other miners share the same consensus rules. Otherwise your peers "wins" become your failures. And at the same time you want that pool to be on the side "winning" the race overall.
So I think there might be a shift of miners towards more centralized pools that enforce one side or the other.

2026-06-30 07:03:14 CEST

- reply

It's explained pretty well here: https://bip110.orange.surf/

2026-06-29 21:28:36 CEST

- reply

No idea, better ask tbk.

2026-06-29 21:26:52 CEST

- reply

Of course there is! What would be the point to mining otherwise!
The block hash includes the merkle root of the transactions, so it could be verified easily. And it must be checked! Otherwise how does the pool know to what address you are mining the reward to? Would a pool pay a miner that might be sending the block reward + fees to their own address? You don't need to disclose the whole merkle tree to prove that the coinbase transaction is correct. But the mechanism is there.
In the case of BIP-110 activation, I guess the BIP-110 miners wouldn't want to share rewards with miners that, if lucky, would include "invalid" transactions that they would later reject as a valod block. So then you need to check the whole merkle tree to recompute the root and validate the shares of all miners.

2026-06-29 21:15:17 CEST

- reply

Thanks for the answer. I meant this with the profitability question:
#nevent1q…jeve

2026-06-29 14:40:14 CEST

- reply

Oh and about profitability, the problem is not the small difference in fees depending on the block transactions. I was talking about having most of the pool's hashrate mining only over a BIP-110 chain of blocks (fork) that then get reorged so all those block rewards are gone and the hashrate "wasted". The impact of profitability would be huge in this case. And it's more about what people within the pool decide to do, not even conditional to overall support of BIP-110.

2026-06-29 14:36:10 CEST

- reply

DATUM allows for pooled mining while each miner decides on their block template. That's what I was referring to.
Currently, you can mine for Ocean pool and get paid the proportional share of your hashrate for the pool mined blocks while choosing your own block templates.
This gets interesting if some blocks stop being considered valid. Or if Ocean needs to check every miner's block template to decide if their shares are valid or not.
And Ocean is a company. That does way more than "organizing hashrate" so it's not crazy to ask them for their intentions on this topic.

2026-06-29 13:54:00 CEST

@nprofile…0rnh @nprofile…c93l Will OCEAN pool enforce BIP-110 compliance for DATUM miners? And for its stratum?
What happens to a DATUM miner that builds its own block templates if it finds a block that includes non compliant transactions? Or even if it doesn't find it, does the hashrate still count?
And of the pool enforces BIP-110 even if only for stratum, I guess rewards will come from BIP-110 blocks only. Which means lower profitability (but same would happen in the other side). But additionally means that many block rewarda are at risk of being invalidated (reorg). So what happens to LN instant payouts?
Don't these questions deserve an official announcement? Maybe I've missed it but couldn't find any.

2026-06-29 11:08:25 CEST

- reply

Frontend: big rewrite. Smoother and with new features, especially interesting for understanding failures.
Backend: v1 supports only joinmarket-clientserver (now archived) v2 supports JoinMarket NG which is maintained and provides new endpoints for Jam (history, logs, ...).

2026-06-29 07:49:47 CEST

Jam v2 (JoinMarket WebUI) beta is out! Adding compatibility for JoinMarket NG as the backend. See https://github.com/joinmarket-webui/jam/releases/tag/v2.0.0-beta.0
And @nprofile…79xu has audited and co-signed up to the latest release of JoinMarket NG: https://github.com/joinmarket-ng/joinmarket-ng/commit/947552bead929c342282019932ff12fe17cc44af
Huge milestones! Long live JoinMarket.

2026-06-25 23:11:28 CEST

- reply

https://blossom.primal.net/c1899ebb9449dcfdc537d556adb34e4c9244347b16df61d10e3d05eda1cff70f.jpg

2026-06-25 07:52:27 CEST

- reply

what is it?

2026-06-22 17:29:19 CEST

- reply

Would it be possible to create a bridge between Waze or similar and roadstr?

2026-06-21 09:32:43 CEST

- reply

Estamos pendientes de que salga la beta pronto, le queda muy poquito.

2026-06-21 09:32:10 CEST

- reply

sí porfa!

2026-06-21 09:31:16 CEST

- reply

I think the bigger problem there is needing a company to perform businesses. That's why "tainted" coins are a problem, not because they have anything wrong on their own. But even if you cared about that, LN fixes that. Blockchains don't scale anyway.

2026-06-21 09:26:42 CEST

- reply

Monero is still vulnerable to many attacks that collapse anonymity. That's why they're working on FCMP++. But even with that fixed, blockchains don't scale.

2026-06-21 09:10:46 CEST

- reply

Should I be angry at my grandma because of her public pension? She's receiving way more than she contributed.
Unfortunately many people benefit unfairly from the state. Should I also "hate" anyone that went to a public university or hospital?
I see the point, but don't think it's fair. I hate the state, which is clearly who steals from me. And I'm disappointed of those who defend that robbery (whether they benefit from it or not). But I don't get into second order beneficiaries. Is a public health doctor net negative? Is a university professor? Where's the line?

2026-06-19 15:14:45 CEST

- reply

Monero is not (completely) private. And doesn't scale well.

2026-06-16 22:53:58 CEST

How would Bitcoin work if there was a human settlement on Mars? And further away?
The time it takes for electromagnetic waves traveling at the speed of light though open space is between 3 and 22 minutes depending on the relative position between the Earth and Mars.
So for example, Mars miners would be at a great disadvantage at first! And reorgs (chain forks) would occur more often.
For regular transactions, it would just mean higher waiting times for Mars users.
But Lightning Network path finding... Probably impractical!
What if there's a human (or another intelligent life form) settlement further away? As in weeks or light years far?
Should each 10 light minute radius area get their own coin? And then the market does its thing setting the exchange rates? Or?

2026-06-16 21:22:24 CEST

- reply

That's called a private company 🤔

2026-06-16 20:53:31 CEST

- reply

how do I buy musk without kyc

2026-06-16 14:53:59 CEST

- reply

timechain!

2026-06-14 21:31:26 CEST

- reply

ack

2026-06-12 11:29:45 CEST

https://bitcoincore.org/en/2026/06/06/privatebroadcast-ip-leak/

2026-06-11 22:33:50 CEST

- reply

Is that so?

2026-06-10 23:03:03 CEST

- reply

Woild be ao mice though :(

2026-06-10 22:40:46 CEST

- reply

congrats @nprofile…pt0r ;-)

2026-06-10 22:33:24 CEST

Stablecoins are winning. We can use this as an opportunity.
Slides from @nprofile…pptm
https://blossom.primal.net/6a3b3af1b5397ae2a2682c0266ec01f60e30a4df50026551b716b6abee9d5798.jpg

2026-06-10 18:14:10 CEST

complexipy: Code complexity analyzer
https://github.com/rohaquinlop/complexipy
Blazingly fast cognitive complexity analysis for Python, written in Rust.
> Cognitive complexity measures how hard code is to understand by humans, not machines.
Unlike traditional metrics like cyclomatic complexity, cognitive complexity accounts for nesting depth and control flow patterns that affect human comprehension. Inspired by [G. Ann Campbell's research](https://www.sonarsource.com/resources/cognitive-complexity/) at SonarSource, complexipy provides a fast, accurate implementation for Python.
**Key benefits:**
* **Human-focused** - Penalizes nesting, flow breaks, and human-unfriendly logic
* **Actionable insights** - Identifies genuinely hard-to-maintain code
* **Different from cyclomatic** - Measures readability while cyclomatic measures structural, testing, and branch density
Try it with:
```shell
pip install complexipy
complexipy . --failed --suggest-refactors # in a python project
```
Example output for JoinMarket NG:
```
joinmarket-ng/tumbler/src/tumbler/runner.py
TumbleRunner::_run_taker_phase 19 ❌ FAILED
Refactor plans:
1. Extract complex block into helper function, lines 351-405
estimated: 19 -> 7 (-12)
steps:
- move the selected block into a private helper
- pass required values as parameters
- return the result/status needed by the caller
TumbleRunner::_run_maker_phase 24 ❌ FAILED
Refactor plans:
1. Extract complex block into helper function, lines 496-523
estimated: 24 -> 6 (-18)
steps:
- move the selected block into a private helper
- pass required values as parameters
- return the result/status needed by the caller
2. Flatten loop body with continue guards, lines 500-521
estimated: 24 -> 14 (-10)
steps:
- add negative condition checks at the top of the loop
- use continue for skipped items
- keep the main processing path unindented
3. Flatten nested condition block with guard clauses, lines 505-506
estimated: 24 -> 22 (-2)
steps:
- invert the outer condition
- return early when the condition fails
- move the main success path one indentation level left
- repeat for inner nested conditions where safe
```
https://stacker.news/items/1505973

2026-06-10 13:53:16 CEST

- reply

Cyberpunks write code.

2026-06-10 13:45:40 CEST

- reply

crazy

2026-06-10 13:40:11 CEST

- reply

nice try NSA

2026-06-09 15:06:37 CEST

- reply

Oh! I really like that idea.
I guess humans having something to lose is also what makes us "lazy". We cut corners and make mistakes because we try to save time.
It is really amazing what one can achieve with the non laziness properties of AI. I've tried many times to have my papers/books directory organized (directory structure, filenames, metadata) and failed. It just takes to be in a rush once to open the door to chaos.
But with AI, I just throw new stuff under pending/ and trigger the AI to follow the recipe. And it changes completely the mental cost of adding new content to the library.
Another big advantage is probably preventing writing fingerprinting. For anyone that has written enough publicly, there's probably sufficient information to uniquely identify that writing style.
Interesting.

2026-06-09 14:57:18 CEST

- reply

Cashu is not Bitcoin. It's debt. An IOU.
But financial debt is not bad on its own. The problem is usually the debtor. Fiat in a bank is debt squared. With the additional disadvantage of 0 privacy and collaboration with the state.

2026-06-09 14:22:25 CEST

- reply

What if Bitcoin already had all it needs to scale and do so with decent privacy?
I want my friends&family Bitcoin services to be as good as my Jellyfin+Ombi setup. People *ask* for an account, it's not me pushing it to them. Because it's better than Netflix, easy to use, and it just works.
Now, I want to improve my cashu mint setup. Find a nice mobile wallet to recommend (looks like minibits for now), and have a fast and robust LN node underneath so that payments work and settle fast.
Will share the final setup once it proves to work for my users.
#naddr1qq…4gxm

2026-06-09 09:55:21 CEST

- reply

#nevent1q…565g
The idea of the next Satoshi Nakamoto being non-human left me thinking last night. I think that won't be the case, because they lack something: caring. They just don't care. They have nothing to lose!
We could already throw an AI into a VPS with a LN wallet with some funds and ask it to run a service or something to eventually "make a living" and pay for its tokens. But why would it? Any mistake that kills its "cron" or main process would "kill" it. And I'm super sure that it will make such a mistake rather quickly. Because it doesn't care.
Even if we got through that, imagine it stays "alive" for long and creates an online service that people pay for (idk, something like nadanada/LNVPN, or nostr.wine). Does it really care about customers? It would be great at apologizing, but probably not enough to keep the service reliable and prevent mistakes on the first place.
I was thinking about this for JoinMarket development: couldn't an AI just handle questions, issues, decide the roadmap, and work on the code? Technically yes. But it probably would take at most a few weeks until there's a funds loss bug or the software becomes unusable due to feature bloat for example.
The difference is that a human cares. The same thing that makes us reluctant to admit mistakes, is what motivates us to avoid them "harder". Ego? Reputation? Responsibility? An AI doesn't have that, for good and for bad.
That's why AI produces sloppypasta: #naddr1qv…nsa5

2026-06-08 21:37:37 CEST

Pieter Wuille (fun) Facts
http://pieterwuillefacts.com/
https://stacker.news/items/1504789

2026-06-08 20:42:21 CEST

- reply

sad :(

2026-06-08 17:14:17 CEST

Am I Being Pwned? - Browser Extension Scanner
https://amibeingpwned.com/
https://stacker.news/items/1504617

2026-06-08 16:51:15 CEST

DeepSWE: Measuring frontier coding agents on original, long-horizon tasks
https://deepswe.datacurve.ai/
![benchmark](https://m.stacker.news/144105)
> Today's leading public coding benchmarks are starting to saturate at the frontier: top models cluster within a narrow score band where adjacent configurations often overlap on confidence intervals. DeepSWE is a long-horizon software engineering benchmark built to separate them. It delivers four advances over existing public benchmarks:
> **Contamination free**: Tasks are written from scratch, not adapted from existing commits or PRs, so no model has seen the solution during pretraining.
> **High diversity**: Tasks span a broad pool of 91 repositories across 5 languages.
> **Real-world complexity**: Prompts are ~half the length of SWE-bench Pro's, yet solutions require 5.5x more code and \~2x more output tokens.
> **Reliable verification**: Verifiers are hand-written to test software behavior rather than implementation details.
> The result is a benchmark that reflects how today's frontier coding agents actually perform in software engineering work.
https://stacker.news/items/1504607

2026-06-08 16:28:05 CEST

How Did DeepSeek V4 Make V4 So Cheap? - YouTube
https://www.youtube.com/watch?v=gC76aeibdFA
Paper: https://www.alphaxiv.org/abs/deepseek-v4
https://stacker.news/items/1504595

2026-06-08 10:15:55 CEST

Looking for feedback on https://github.com/joinmarket-ng/jmp/pull/3 (Taproot offers)

2026-06-08 08:04:56 CEST

The Economics of Protocol Design: Proposing Lightning over Ark‬ - YouTube
https://www.youtube.com/watch?v=hqKQ4Rky3tY
René Pickhardt at BTC++ conference.
Description: Venture Capital Money has a surprising influence over protocol design. Not rarely technical sound solutions won't find consensus due to market sentiment and selfish interests of participants. We investigate this with the example of the debate about ark vs. lighting network as the future payment system for Bitcoin.
Paper: [https://arxiv.org/abs/2601.04835](https://arxiv.org/abs/2601.04835)
https://stacker.news/items/1504446

2026-06-07 21:57:10 CEST

- reply

yes! what's about to say that. And that did not save them

2026-06-06 21:21:33 CEST

- reply

And if you set the minimum reserve to match those, there's no security problem anymore.

2026-06-06 21:19:31 CEST

- reply

It uses the underlying node default fee limits. Right?

2026-06-05 12:29:44 CEST

We're now co-signing JoinMarket NG releases!
@nprofile…79aj has reviewed up to 0.30.0 and that's the first co-signed release.
https://github.com/joinmarket-ng/joinmarket-ng/commit/9a6e8d4333ff716336c05671e07bd9454dc7f43d
He also fixed a docker image reproducibility issue.
Still looking for more eyes. If you can review the code and want to co-sign with us, please reach out.

2026-06-05 10:40:32 CEST

- reply

do they? they look more like inflation "detection" more than explanations on why it would be unlikely for it to happen in the first place

2026-06-05 10:21:34 CEST

- reply

What's interesting is how they manage to keep the TRY exchange rate more or less stable against other currencies. Prices have rosen like crazy but the TRY/EUR pair has barely moved.

2026-06-05 07:44:04 CEST

- reply

That doesn't solve the "censoring". Primal uses a special caching relay for reading. Which is not a nostr relay but some custom thing. I guess you could self host that, but it's not as simple as configuring additional relays.
On top of that they have an npub blacklist which I'm not sure where it comes from and that might not be easy to avoid.

2026-06-04 22:49:48 CEST

I have a problem. I only like Primal for its UX but I'm getting tired of "mentioned event not found". Did not come to nostr for censorship but for censorship resistance.
Any Nostr client recommendations? Have tried Iris and wisp already and was not convinced :(

2026-06-04 20:10:55 CEST

- reply

Good luck enforcing that🤭

2026-06-04 08:20:36 CEST

- reply

sad :(

2026-06-02 10:18:08 CEST

- reply

sad :(

2026-06-02 10:10:07 CEST

- reply

The relay is not the problem. There are many relays already. But Primal is designed around their caching relay which is not easily replaceable.

2026-05-31 21:16:20 CEST

- reply

Sure. But there's a big difference between who has access to it and what it stores. Selectively excluding notes sounds pretty intentional.

2026-05-31 13:40:26 CEST

Is Primal censoring stuff?
https://stacker.news/items/1499789

2026-05-31 13:23:24 CEST

- reply

2026-05-30 22:48:23 CEST

Cashu Mint Auditor
https://audit.8333.space/
This app sends random Lightning payments between mints. Forever. The sats go in a circle until all is lost to fees or rugs. If a mint fails to pay an invoice, it is marked with a scary red label.
https://stacker.news/items/1499492

2026-05-30 17:43:07 CEST

- reply

can't zap you! but thanks :-)