LeoWandersleb
Leo Wandersleb

Publishing source doesn't guarantee that vulnerabilities will be found.
Not publishing source guarantees that only bad actors will find vulnerabilities because decompiling already is a legal gray area.

2026-08-17 09:07:44 UTC

- reply

How do I get it into buzz mode?

2026-08-16 20:51:32 UTC

- reply

So ... my agent summarizes my pains trying this approach as follows:
Pulling together everything we hit today, the gap is that Buzz only *stores* standard Nostr events — its actual product lives in conventions Amethyst doesn't speak. Concretely:
1. **Wrong message kind.** Amethyst posts channel messages as kind 40002; Buzz chat is kind 9. Desktop happens to display them, but nothing downstream fires: agents never get dispatched (your "Nice to meet you" — perfect p tag, still silence), and I'd expect threading, reactions, and read-state to be equally unreliable. You're a ghost who can be seen but not heard by half the system.
2. **No profile bootstrap path.** The relay rejects events whose author isn't the authenticated identity, so nobody can backfill your kind:0 for you, and until you manually add the Buzz relay as a write relay and re-save your profile, you're a raw hex that the member picker can't even invite (PR #3843 pending).
3. **Mention interop is one-way broken.** Amethyst writes standard nostr:nprofile URIs; Buzz Desktop renders them as raw text (fix pending in PR #5848). So even the humans see mangled messages.
4. **The collaboration layer doesn't exist in Amethyst.** Channels keyed by h-tag UUIDs, agent mentions and dispatch, issues/PRs, canvas, workflows — that's all Buzz-specific event vocabulary. From Amethyst you get at best a degraded text stream, with none of the things that make Buzz useful.
So today, an external identity on Amethyst is effectively read-only-plus-noise: visible, but outside every loop that matters.
Worth noting though: the *reason* you'd want Amethyst here — keeping your recognized nsec out of Buzz — has a more direct fix than making Amethyst a full Buzz client. Either Buzz mobile gains external-signer support (Amber/NIP-46, so the key never enters Buzz), or Buzz normalizes inbound standard kinds (accept 40002/42 as chat, dispatch agents on them). Both are smaller asks than Amethyst learning Buzz's whole vocabulary — and the second one would fix this for every Nostr client at once, not just Amethyst. That's the angle I'd put in the issue.

2026-08-16 13:09:32 UTC

- reply

As buzz is for relatively closed circles, the pain of using new keys is minimal but of course that's not very nostr.

2026-08-15 14:42:52 UTC

- reply

People voting with their wallets. I see.

2026-08-15 12:15:36 UTC

- reply

Sorry. Nothing changed. The app of course has the key regardless of how the backup of its key is stored. Casa needs no Google to get to it. :ganacci_dance:

2026-08-15 09:49:01 UTC

- reply

Casa Keymaster is closed source so the claim that the mobile key is backed up to your Google Drive and **not** to Casa servers (or generated deterministically like Coldcard keys) cannot be verified independently. But ... the keys got to Google Drive because the Casa app put them there, and yes, the app can retrieve them without any user help if your phone is logged in to Google/Apple which 99.99% of phones always are. So even if your keys were not leaked **yet**, Casa can get to your keys with the next update of the app. We will update our analysis accordingly.
https://walletscrutiny.com/mobile/casa.keymaster/

2026-08-13 10:40:43 UTC

- reply

Was the new canary installed by the old or the new team? At this point I would only trust "old team" if it was signed by one of their known keys. Else ... what's the accountability of an anonymous team?

2026-08-13 08:52:34 UTC

- reply

To be clear, I'm reporting a missing feature. I did not get involved to fix it yet.

2026-08-11 19:29:37 UTC

- reply

The mapping hash prevents others picking an algorithm on purpose but not Luke picking one.

2026-08-11 16:48:38 UTC

Who could have thought of this resulting in a fork war???
https://fork.observer/?network=testnet4
#nevent1q…qu3c
Maybe @npub1ej4…ndrm 's OTS could help them out?

2026-08-11 14:12:07 UTC

Has @npub1lh2…a9nk completely lost the plot? Pardon my reading comprehension but to my understanding he decided to use a laughable oracle withing less than 6h to pick the next mining algorithm of what he believes to be Bitcoin? Why laughable? **He** picked a mapping from last digits of the block hash to PoW algorithm. He picked **Testnet4** of all chains - a chain with difficulty **1**. He did not show the mapping to anybody, so only **he** knows the mapping. A modern mining rig can produce many candidate Testnet4 blocks per second, so he can comfortably pick or if somebody else does the same, orphan them or if several engage in this mess ... why not just use the bitcoin chain??? Or at least Doge Coin???
"Nobody knows the new algorithm right now, and nobody will until we all know at the same moment" is just untrue for him.
#nevent1q…8hq9

2026-08-11 13:46:57 UTC

- reply

It's as secure as Testnet4's difficulty. He could have picked Dogecoin's chain to make it more secure.

2026-08-10 16:55:23 UTC

- reply

Nostr events are signed by an author and can easily be replicated to multiple relays.
A git repo can also be replicated but a client wouldn't subscribe to several, so you would have centralization there.
Accountability is not integral to git neither.
Google Full Disclosure vs. Responsible Disclosure and you can see how disclosing issues or the mere possibility of issues is a hot topic and often draws censorship.

2026-08-10 10:17:52 UTC

- reply

For @npub1j9k…uswx I'm thinking about this a lot, together with Project Loupe, too. The problem I see is "responsible disclosure". You will always find something and even the stuff you might want to responsibly disclose at first sight might not be an issue after all, so what will you signal and when and to whom?
I'd happily show what people signal on WalletScrutiny. Make clear attestations.
Known pubkey attests that commit X of project Y was checked with prompt Z on model A with these results ... Highest criticality found: B
Let's agree on a nostr event format. We might not engage in producing those events as "WalletScrutiny" but with clear attribution to nostr accounts I see no problem showing them.

2026-08-08 20:35:09 UTC

- reply

Ocean allows miners to pick what they want to mine

2026-08-08 13:37:12 UTC

- reply

Yes. But they shifted blame where their wallet lost the funds.

2026-08-08 09:04:52 UTC

- reply

CoinKite victims lost funds long in the past and Rodolfo blamed promiscuity even where the user did everything right.

2026-08-08 09:02:15 UTC

- reply

At this point I would still shut it down when not coinjoining and check for new releases the minute I'd need to start it. Crazy times.

2026-08-08 08:33:14 UTC

- reply

... unless the provider ignores it for months.

2026-08-07 21:10:30 UTC

https://npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6.blossom.band/1786ce3e696002928f10ccafd52975ff6ff2cbab448a1d9730c18452c4d532eb.png

2026-08-07 20:40:27 UTC

- reply

Call them. Now.

2026-08-07 09:40:46 UTC

- reply

The subscriptions give you many more tokens than the API. If you switch to API, you pay more for Claude than for Kimi.

2026-08-06 09:59:56 UTC

- reply

Add Samourai to the list.

2026-08-06 06:28:58 UTC

If somebody stepped forward and offered you to return 50% of your hacked coldcard funds if you dropped charges, would you take it?

2026-08-05 23:00:22 UTC

- reply

It's two clicks from the main page. -> transparency -> canary

2026-08-05 22:53:03 UTC

- reply

True. But there could be prediction markets around catching hackers and insolvencies. Well, I'm just curious what's happening next.

2026-08-05 21:01:04 UTC

The tide is turning
I've been looking at code, code reviews, and wallet development for many years. My understanding was always the same: almost all wallets get way too little scrutiny, and the only reason this didn't constantly blow up is that most engineers are too honest. Bugs got found, bugs got responsibly disclosed. But all wallets are full of bugs. Entropy bugs are rare only because entropy is the one thing wallet devs care most about.
That era is over.
Code reviews are now done by clankers, not by professional engineers with years of experience and a pay grade reflecting that. Any kid with a laptop can go on a treasure hunt with very little resources. And every new model generation is better at finding those bugs than the last. ColdCard was our wake-up call.
But there is hope. The defense gets clankers too. Given enough tokens, every bug is shallow. And **cryptography does work**. Neither superintelligence nor quantum computing makes all asymmetric problems symmetric. What the clankers might actually do is turn our 2,000,000 line hardware wallets into 20,000 line hardware wallets and prove the absence of edge cases. Or simply said, eliminate all bugs.
Will the industry pay for that? History says no. Checking your own product's security never paid. Moving fast and breaking things paid. Security engineers were a cost on the balance sheet, which is why most companies in this space pay meager bug bounties or none at all. Right now the defense runs on the goodwill of a few. @npub12rv…85vg, Rob Hamilton and their red team are burning five figures a day in tokens and reporting dozens of bugs per hour to hundreds of open source projects. That is the right panic. It is also goodwill, and goodwill is not an assurance model.
Nobody should run wallet software without plausible assurance of two things. That the binary they are about to install was built from exactly the source that was reviewed. And that this source gets checked for bugs continuously, by someone with no incentive to look away.
The first half is what WalletScrutiny attests today. We track 4,920 products. Most now are dead, fake, or not bitcoin wallets at all. Another 500 are custodial and for a custodial product the binary tells you nothing. Their custody might throttle a hack or lose it all in one go. Inspection only means something for self-custody. That leaves roughly 460 wallets that can be inspected at all, and exactly 121 of them currently pass all transparency tests. Those are the wallets where the binary can provably match the public source. We attest to transparency, not to implementation details. **Nobody attests to implementation details.**
The second half is the continuous review of that source, and done right it costs far less than the panic suggests. Roughly 100 new wallet releases hit our radar every month. With one full review per app on record, each new release only needs a review of the diff. I would be surprised if all the open source diffs together burned more than $1k a day.
Closed source is a different story. A binary diff probably costs as much as ten code diffs, and reverse engineering puts the reviewer in a legal gray area where our first hire might have to be a lawyer. So the priority writes itself. Open source gets reviewed. Everyone else can earn their review by publishing code under a license that invites scrutiny. That is pressure toward actual FOSS.
Even at the lower burn rate, tokens are not free. Neither is the person steering them.
In the grand scheme of things, the bitcoin ecosystem might not have the resources for a thousand bitcoin wallets to exist but maybe we can raise the resources to find out which ones shouldn't.

2026-08-05 18:04:41 UTC

- reply

You good man? You've done nothing wrong. You dodged a bullet here. How many people bought on FTX cause you only told them that Bitcoin was a thing? There is only self-custody. All those custodial bitcoin larpers will ultimately lose it all.
I hate recommending wallets and always push people to do their own research, too. Don't scare people away from self-custody or Bitcoin as a whole. The losses in ColdCard so far are a tiny fraction of FTX.

2026-08-05 16:31:36 UTC

- reply

Understanding wallets is my job and I still don't recommend any wallet ever publicly.
In private I have to pick for friends and family but I hate it. It's much easier to recommend not to use product X for [reasons].

2026-08-05 15:00:14 UTC

- reply

How is doc-hex doing?

2026-08-05 11:09:39 UTC

- reply

Yeah, people are obsessing about the extra entropy keys being at risk but hackers are probably obsessing more over fringe derivations before they start to go after <5 dice roll variations or <5 letters passphrase single sig coins.
Sure, those might get found eventually if you don't move them but in terms of CPU/BTC there's still lower hanging fruit out there. The first wave skipped taproot completely. The next skipped wallets that had a slightly higher gap limit. I bet they still didn't empty the secondary accounts or accounts past account gaps.

2026-08-05 10:56:42 UTC

Are there prediction markets on the final size of the Coldcard "hack"? I'm glad it's still less than 2k BTC according to https://coldcard-hack-tracker.vercel.app/
Also what are the odds of the thieves getting caught?

2026-08-05 09:56:19 UTC

- reply

How about engineers? I would argue it's less prevalent there.

2026-08-05 07:54:29 UTC

- reply

I perceived them as low in empathy, resistant to criticism and Machiavellian. This personal perception matches somebody who would do such a hack.
Switck 😉😉
libngu 😉😉
It's all a bit too much on the nose.

2026-08-05 07:45:57 UTC

- reply

Not everyone has a price. There are personality traits that would rather die than do unjust to another soul and there's many that might steal if they felt poor but wouldn't under any circumstance as long as not under duress. I'm confident most open source wallet devs are in that category.
Nvk and doc-hex not so much.

2026-08-05 07:33:21 UTC

- reply

Why would they have learned about this weird "paper"?

2026-08-05 07:32:32 UTC

- reply

I always picture the retirement attacker as having a red button and a screen on his desk, showing him the balance to extract. If that goes down or people get suspicious, he can smash that button.

2026-08-05 06:12:24 UTC

What doesn't aquare with this theory is the relatively slow draining. In 5 years they would have a list of utxos and a script to empty all at once.
Maybe they built the backdoor and decided to not use it because tracks were not covered?
#nevent1q…78ag

2026-08-05 06:01:09 UTC

- reply

Sorry for my lack of sympathy. All I received from nvk over many years was hostility. That doesn't mean I wish him or dockhex bodily harm. I only wish they get put in their place, meaning, not that high castle they were sitting in all that time.

2026-08-04 20:23:55 UTC

- reply

Well, there's whoever introduced the vulnerability and those that exploit it now.
The fbi will search both.
What meme do you refer to? Was @nprofile…2c2h just shitposting?
If dochex is swick, isn't that a hot lead?

2026-08-04 18:44:51 UTC

- reply

Was he ever concerned about anybody?

2026-08-04 18:15:56 UTC

The thick plottens.
#nevent1q…qefs

2026-08-04 17:03:53 UTC

- reply

Most hardware wallets mix entropy from multiple sources. CoinKite was always very arrogant about their true random number generator so why add inferior entropy when you have "real" entropy? A reviewer checking the use of their TRNG can easily miss it not being used.

2026-08-04 10:04:12 UTC

- reply

I wonder how they ended up at the top of the priority list. Is it to annoy regular citizens? They are deep in Russian territory but with little defense? High value concentration? Are drone parts going through those? Any direct military relevance?

2026-08-04 09:15:23 UTC

- reply

Damn! Why pitch Casa in this otherwise great write-up? Casa default setup is 2-of-3 with the **closed source** client and their server being two parties. Or has that changed?

2026-08-04 08:44:13 UTC

Oh, nice. Somebody found an old post of mine ...
https://npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6.blossom.band/ea9c9f893151056f47cb04cfa473fa5e956b16e629eeabe8c402ed8344b0df33.png

2026-08-02 05:51:16 UTC

- reply

hash(0) looks random. Maybe hashing is evil? The entropy has to be inspected pre-hashing?
Also if dice roll is the new standard which I hope we won't go for, it has to be standardized so that wallet X generates the same wallet as Y from the same dice roll or else we have no way of checking the working of wallet Y.

2026-08-02 05:46:55 UTC

- reply

There were more Bitcoins mined on "day one" of Bitcoin.
(Not really because day one did not have 144 blocks due to lack of miners but in the grand scheme of things, so far we are handling this well. Losses are contained. Hopes are high to find the first of the sure to come many hackers.)

2026-08-02 05:42:07 UTC

- reply

I like the meme but fear it's giving a false sense of security to the Mk5 owners. They will be next and claims are surfacing of this already happening.

2026-08-01 15:08:00 UTC

- reply

Given his personality traits, the best outcome I would hope for is for him to step back from CoinKite daily business and let somebody more open and empathetic lead. Allow issue trackers for a start. Allow criticism without threatening to sue.

2026-08-01 09:38:08 UTC

Shit take of the day ...
https://npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6.blossom.band/2ed3ea2323cdba28cf696652624ce6a0b2fcb99864407ae99ab079b6e5176174.png

2026-07-31 23:59:20 UTC

https://npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6.blossom.band/8ce7bc7e89c8468a8e50079866f7f31bd05cc8cc82dde2f1f0607e2231b1c6e8.mp4

2026-07-31 20:44:29 UTC

- reply

Forget the uid. If it's less bits than the timer, the latter scrambles all its bits.

2026-07-31 20:35:29 UTC

- reply

Not unique uid? Damn! Still, claimants could show receipts to transactions in their wallets.

2026-07-31 20:33:22 UTC

- reply

If I knew how to pull this off, I wouldn't without legal advice or confidence to be able to remain anonymous. Of course it's a legal mine field but it happened before.

2026-07-31 20:30:03 UTC

- reply

The uid is a start although it gets XOR-ed with a timer that scrambles most but not all bits of the uid. I bet you would end up with at max one plausible claimant per wallet.

2026-07-31 13:16:15 UTC

- reply

Hack the exposed wallets to give the bitcoins back to those poor victims of CoinKite's negligence.

2026-07-31 11:32:11 UTC

- reply

Are any white hats stepping up already?

2026-07-31 09:05:16 UTC

- reply

And when will you drop that sponsor?
Sadly the situation is highly time critical.

2026-07-31 08:21:07 UTC

- reply

Terrible advice! Yes, you only get the full on-paper entropy with perfect dice. Perfect dice do not exist. Don't use any dice!
Maybe being shy 1% of the optimal entropy is good enough and certainly better than the ColdCard shitshow of using just a few bits?

2026-07-29 20:22:57 UTC

- reply

#nevent1q…5fja

2026-07-29 20:21:44 UTC

The irony: Should some miners maintain the bip110 chain even at a low exchange rate, sharing media on prestine Bip110Coin will be cheaper than on corrupted Bitcoin.
#nevent1q…5fja

2026-07-29 20:14:42 UTC

- reply

Pushing for bip110 to fight spam is wrong. I don't think Matthew has a hidden agenda.

2026-07-29 19:26:44 UTC

- reply

@npub1s33…252p might be wrong on the BIP110 issue but otherwise he has done less harm than Saylor.

2026-07-29 11:04:49 UTC

- reply

He'll pipe the events right to the printer.

2026-07-28 13:18:19 UTC

- reply

That looks like you're quite close to the epicenter.
https://npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6.blossom.band/8912d1ae50c84d27ac0aa8f7ffd35967a1cab5f37491a33a24d5d1d684356e98.png

2026-07-28 07:29:18 UTC

- reply

Is the opposite opinion allowed in India?

2026-07-27 16:58:36 UTC

- reply

17k tokens per second on 250W is insane! As proof of concept ...
How does that compare with gpu?

2026-07-27 16:54:18 UTC

- reply

An asic for one specific llm? Wow!

2026-07-27 07:21:55 UTC

- reply

Satoshi's solution to blockchain spam was to charge a fee. Monetary use will price out spam. That's consensus.
Policy was always concerned with spam, too, but with network spam, not with blockchain spam. Protect your node from bandwidth saturation.
Policy was used to control blockchain spam but a spam filter installed on only 90% of the routes to the miner cannot work. Libre Relay broke this hacky use of policy.
Even though it's highly unlikely bip110 will activate in 2 months or so, the worst spammers already switched to comply with its rules weeks or months ago.
Op_return is the single best place to put non financial data as you can prune it. To give spammers an incentive to dress up their spam as payments is foolish. To selectively cripple financial scripts to further fight the spammers hurts legit innovation while not making a dent in spam volume.

2026-07-26 11:02:31 UTC

- reply

**Chain split guidance, restated without the team colours.**
Call them the enforcing chain and the unrestricted chain.
**There is no split to transact on for a long time.** Mandatory signalling constrains block headers, not transactions. The reduced data rules bind at height 965,664, which a minority branch reaches slowly. At 20% hash that is about 20 weeks after the window opens, at current signalling over a year. Until then every transaction, giant OP_RETURNs included, is valid on both branches. Splitting coins via OP_RETURN is impossible before the enforcing branch itself reaches activation height.
**Replay protection must be built.** Branch-exclusive coins come from two sources. Passive: post-split coinbases, spendable after 100 blocks, within a day at 97% hash, three weeks at 3%. Active: RBF from the first divergent block. Get confirmed on one branch, then bump. The original's outputs are now exclusive to one branch, the replacement's to the other, and every descendant inherits the split. No maturity wait, though at 3% hash the slow branch's next block averages five hours out, and the bump must not reach the fast branch before the original confirms there. Until you hold and spend such a coin, your payment confirms wherever it gets mined, or on both branches.
**"RBF or CPFP" is half wrong.** A CPFP child spends a parent that exists on both branches, so it replays and pays both miner sets. It signals nothing. An RBF replacement of a transaction already confirmed on the other branch conflicts with a confirmed transaction there and can only ever pay the branch where the original is still pending. RBF is the only tool that creates branch-exclusive fee demand, and it works in both directions.
**Fees follow prices, not the other way.** All miner revenue lands in a branch-exclusive coinbase worth whatever the market thinks that branch's survival is worth. With shared difficulty, revenue per hash is price times block reward. Grant equal prices and the mechanism in the original actually works, and needs no RBF: everything replays, so the minority branch's mempool holds the majority chain's entire confirmed history as backlog, its blocks skim the top by feerate, and its fee per block is higher until hashrate reaches parity. But equal prices with 1 to 3% signalling two weeks before the window is not an assumption, it is the conclusion smuggled in as one. Fees run at low single digits of the 3.125 BTC subsidy. At a 20% price ratio an enforcing block needs over 12 BTC in sustained fees just to break even. The mechanism is real and two orders of magnitude too small.
**Parity is the starting line, not the finish.** Non-enforcing nodes reorg onto the enforcing branch only if it takes the cumulative work lead. Every day at 20% hash digs 0.6 network-days of deficit. A week at 20% costs three weeks at 60% to repay. And a branch whose block production runs through one or two pools is one DoS away from stalling, while futures markets set the decisive price ratio before the window even opens, and against a 3% branch, rented hash is cheap griefing. The reverse risk is simpler: miners abandon the enforcing branch and its coinbases go to zero, no coordination required.
**What survives from the original.** Decide which branch you are on, run a node that enforces your choice, and do not treat a confirmation on one branch as a confirmation on the other.

2026-07-26 08:21:08 UTC

- reply

Well said, except for that last line ;)
Being right about the above doesn't mean that BIP110 is good or right. It's just not fiat or statist. You are free to choose and I wish you would not choose BIP110. Also I'm confident I could convince you to not run it if only I had enough time to talk it through with you face to face. At the least I hope you don't blunder your savings by selling Core-Coin for more Luke-Coin.

2026-07-26 08:12:18 UTC

- reply

If your goal is to change Bitcoin, yes, a minority soft fork is harmful and unnecessarily disruptive as it can land close to the 50% hash rate, resulting in a long re-org, where people unnecessarily lose money. In that case you hurt both sides of the fork.
If you want your own coin because "Bitcoin is corrupted", make it a hard fork. Then nobody cares about the re-org risk. Everybody can pick which coin is less captured or captured by their flavor of policy without re-org risk and with instant tradeability between the coins. That would be the way to get a fork through that is against the miners but with the big holders.

2026-07-24 22:33:01 UTC

- reply

The thread is about serious issues. Some Luke-Coin with 1% or 20% of the hash rate will not be disruptive. It will be a clean fork.

2026-07-24 11:18:37 UTC

- reply

With two weeks to go, "1% since weeks" sounds worse for bip110 than a recent up-tick to 1%.

2026-07-24 10:35:09 UTC

- reply

The miner signalling. Last I checked it was at 0.3%. Bitcoin will only be disrupted if that goes up to 50%. Luke-Coin can peacefully exist along Bitcoin if no more than 33% are reached. If the 50% are reached quickly, Luke's rules get merged into Bitcoin smoothly, which would be somewhat disruptive but certainly better than some 45% forking off.
So 0.3 is not the likelyhood of drama. I just made a joke around that number being 0 at first approximation.

2026-07-24 08:31:00 UTC

- reply

Let's be precise. There's a non-0.0% chance of chaos. 0.3 rounds to 0.

2026-07-24 08:29:07 UTC

- reply

defnull commented 23 hours ago:
Context is important. The rule is: "Content that harms the reputation of Codeberg, such as cryptocurrency related projects" and it's a part of the "You must not share any content that's expressing hate or encouraging violence towards a person or group for any reason." rule.
If a project does not harm the reputation of Codeberg (e.g. by scamming people or doing other shady stuff) it does not fall under this specific rule. And if it did, it would be a TOS violation even before the change. Cryptocurrency (the scammy kind) was just added as an example here.
With a lot of creativity and a complete lack of trust in Codeberg you could read this backwards as "All remotely cryptocurrency related projects harm Codebergs reputation, so they must be banned" , but that's not what this rule actually says.
Another common argument is that this rule could be abused to attack or harm 'good' projects. We all know how a bad laws (e.g. copyright) can be used as a weapon of suppression. For big platform, it's way easier and also more safe to quickly act on complaints instead of investigating. Users are guilty by default and must prove they are not. Vague rules are very dangerous under those circumstances. The Codeberg TOS situation is fundamentally different though: No one has any 'right' to get AI or crypto projects removed from Codeberg. Trolls cannot file false claims en masse and demand action to get someone else in trouble. If they do, then Codeberg mods can quickly dismiss those false claims, they do not have to disprove them. Banning a project is way more work than not banning it, so there will be no 'purge' and no mass-banning. No one has time for that. We just need to get rid of the worst and most obvious offenders, that's all. Humans with brains will decide on a per-project basis.

2026-07-22 15:48:55 UTC

- reply

Shopping for pans right now. Can't produce french style pancakes on anything but teflon.

2026-07-22 12:21:33 UTC

- reply

That's just words. So far it looks more like Bitcoin without transactions or blocks.

2026-07-22 07:09:07 UTC

- reply

How would a 1% shitcoin attract 51% of the mining?

2026-07-21 19:05:32 UTC

- reply

I thought ppq was evaluating messages for objectionable stuff prior to sending them to the LLM to avoid losing your api access.

2026-07-20 16:49:01 UTC

- reply

Promises to not log exist from ppq, too.
Oh, so tee models encrypt between client and model? I understood, @nprofile…qagl still sends all requests to a classifier. That step would break the e2ee promise. So routstr skips that classifier step?

2026-07-20 14:32:29 UTC

- reply

What's the benefit of routstr over ppq?

2026-07-20 14:29:58 UTC

- reply

PayPerQ will explode once the big providers stop giving away free tokens via the subscriptions. So ... after their IPOs.

2026-07-20 14:18:55 UTC

- reply

Miner signalling is at 0.3%. I don't care about "node signalling".

2026-07-20 12:58:30 UTC

- reply

Assume all leaders are Machiavellian and build institutions accordingly.

2026-07-20 12:42:13 UTC

- reply

"A prudent ruler cannot, and must not, honor his word when it places him at a disadvantage." –Machiavelli

2026-07-20 12:39:56 UTC

- reply

Probably true but not for reasons you said this ;)

2026-07-20 10:20:35 UTC

- reply

Good point. We will know very quickly on Aug7. Probably 30min into the epoch it'll be over for the bip110 fear mongering.

2026-07-20 10:11:41 UTC

- reply

Do they never attack? Looks well equipping to drive humans out of the water.

2026-07-20 09:22:01 UTC

- reply

Knots is right on track to cause a minority chain split. Weeks before mandatory signalling BIP110 runners claim still to be determined to keep running BIP110. If August 7th comes and less than 50% of miners signal BIP110, you get a chain split.
I see how mandatory signalling can make a soft fork a success even if only a minority cares but with a minority less than lets say 20% this doesn't work. Nobody knows how big that minority group needs to be but I'm confident claiming that 0.3% is not enough and I would be shocked if 10% were enough.

2026-07-19 10:46:31 UTC

- reply

Unless somethong new came out today, I stand by my post. Neither Luke nor Core want to harm Bitcoin.
Luke could act Machiavellian if he decided Bitcoin was incompatible with his Catholicism which csam could very well trigger but I don't think he intends to harm it now. I think he genuinely believes that bip110 can make a dent in spam.

2026-07-19 08:39:48 UTC

- reply

It's not neutral. Non-votes are no-votes. 50% is impossible to reach.

2026-07-18 16:14:08 UTC

Today we had what I guess is "rolling thunder". It wasn't raining yet and it was relatively bright but I heard a thunder sustained for several minutes on end. The lack of variance felt eerie.

2026-07-18 15:45:21 UTC

- reply

If that mail wasn't fake it would clearly mean that Foundry was against bip110 as clearly asking members to vote with any non vote counting as "no", a " yes" outcome is impossible to happen.
If there was any demand to signal bip110, a pool will just provide an alternative endpoint for those users.