ndeet

https://fountain.fm/episode/ckEIWdxxe0yCvCvUPcLt

https://fountain.fm/episode/zaXmB40gTtkHT4wBUwzH

https://fountain.fm/episode/IWxJbeCGV9Tywo5JTdLt

screenshot 3 days old, no binaries on github of elementsproject/lightning, no offical announcment

dunno either fud or major fuckup by blockstream

https://fountain.fm/episode/IWNVrYb4CU6veV95AYo9

https://fountain.fm/show/g9SbSHItS3e6aKx8T6Fv

https://fountain.fm/episode/7Wc7P53cEqLxqqbUe7Lx

Please update BTCPay Server to version 2.4.2

If you use LND, consider macarroon files compromised and if you run (which most don't) a hot wallet in store, send funds out. Afaik not an RNG issue but files could be read from disk over endpoint.

https://fountain.fm/episode/hSkcjQoXyv9kcQIjGgnm

https://fountain.fm/episode/i0qtmCxcWsWqH5uPnp0d

https://fountain.fm/episode/i0qtmCxcWsWqH5uPnp0d

https://fountain.fm/episode/izQ7XPQ1pTUB8jbUtZ1C

https://fountain.fm/episode/bGbFo7rgKwEkb0bhgHnf

https://fountain.fm/episode/vNr65in5DTxLMsJm2FfH

https://fountain.fm/episode/OEp5xJEzTcQzbCecgEdW

https://fountain.fm/episode/Gb7Yhsu3PJVbOsvaOY2X

https://fountain.fm/episode/vR0sOBvA34xAV6TZpV6s

https://fountain.fm/episode/6ei5AGWYSdHZuglj6Qzn

https://fountain.fm/episode/EVPskr2eiBAxnlF7uZeY

https://fountain.fm/episode/qUim0HiEZ9bOxOfQohO8

https://fountain.fm/episode/rIdsS6Tz3wnW1k5HppCQ

https://fountain.fm/episode/Dh8pufLZlFx1bzU3BwhZ

https://fountain.fm/episode/mzDURLMGweOUZEksDgQj

Sehr gute und nachvollziehbare Argumente von Christian. Robin irrt leider in 2016 Narrativen und Security Budget FUD umher. Genialer Programmierer aber noch zu wenig mit den anderen Aspekten von Bitcoin beschäftigt.

Onchain wird kein instant finality haben, 0-conf ist seit RBF tot (war womöglich ein Fehler). LN etabliert sich als Settlementlayer, bessere UX on top möglich aber onchain und größere Blöcke wird LN nicht ersetzen. LN wird imo bleiben.

Meine Schlussfolgerung, neue Features und opcodes müssen noch konservativer und langfristiger gesehen werden. Das Risiko von unbeabsichtigten Seiteneffekten ist viel zu groß. Devs sind oft in ihrer Domain Genies aber verstehen das gesamte System und dessen Incentives nicht ganz.

https://fountain.fm/episode/WRHue0FMQaaYclcXBu8B

https://fountain.fm/episode/p767l2gBMeWhEMUimHPt

Intrresting that suspicious and controversial figures can't help themselves and go full retard eventually. He even does not mind robbing patoshi coins. This will be a huge nothingburger but for sure he will find some fools financing his and his pals retirement.

Stay humble, stack sats. Don't get fooled by self-proclaimed saviours of Bitcoin.

🙌

https://fountain.fm/episode/fLqds61ds9YbsnqGOkE8

https://fountain.fm/episode/qkB2ty5fUhDFbJXGZYHj

https://fountain.fm/episode/vgcyxfZhGHmCrlDjxI67

https://fountain.fm/episode/29qobYsuczVOoQgozbx3

Seems even the opposition in Hungary is not so stupid to sever their main energy source without a proper replacement. Only the EU and most of its sheeples are that dumb.

Buying hash from big (and small) hashing farms so it doesn't end up in centralized mining pools but instead build on your own block templates (via DATUM and SV2) sounds like a net positive to me. Running your own mining hardware is better that's for sure but the next best thing is to buy hash that would otherwise end up in centralized mining pools giving them more power. Not as bad as cloud mining as you can point an exact hash rate you bought to a specific pool/mine your preferred block templates.

What's the argument why this is bad?

https://fountain.fm/episode/AYHXvZ5NF7gtsH6r6UYs

https://fountain.fm/episode/TOfUAYUs0rIVBsCgC7vl

Based, nicht unterkriegen lassen. 👏🙌

https://fountain.fm/episode/dAVPUaFZm5cYOxou36hu

https://fountain.fm/episode/oQJAMCbCyD0Pv0n4FklM

https://fountain.fm/episode/eQUkyrhmd4jTuQGO5zKn

https://fountain.fm/episode/ngrMTEaQAMvkhMS5ZFop

https://fountain.fm/episode/d57aIMmzla653QWmA7t0

👀

Imagine being hostile against another well funded implementation ensuring there is no single point of failure and further reducing the attack surface by decentralising development.

Unless you have already influence in the current reference implementation and want to make sure your (shitcoin) agenda gets pushed through.

Same people that praised LibreRelay and told you nobody can stop them now being hostile against another implementation going the opposite way to not break and rush things and ensure Bitcoin will survive 1000+ years.

Whic pr?

https://fountain.fm/episode/O2I3sTTm9W3TheF5Y3yl

An additional Bitcoin client implementation, desperately needed, imho.

https://productionready.org/blog/productionready-launches

Very good and nuanced discussion about BIP-110 and surrounding topics 👏

https://fountain.fm/episode/5bNY4Ppmrsl04DrQipso

utxo singlehandedly fixing nostr ux 🙌👏🎉

https://fountain.fm/episode/vtuRsWMgAjZmq8AbShMh

👏

https://fountain.fm/episode/FvcdsKSkhXFtkz4maDwp

https://fountain.fm/episode/CYhR3fy8AZam5yobuBc0

https://fountain.fm/episode/uUtQvFzlnmo47q9jOiuu

Land of the free? Only if you didn't make uncle Donald angry, no congress approval or change of law needed?

Even here in EUdssR they at least do some democratic theater and push through laws when countries get sanctioned.

https://fountain.fm/episode/eCw6uxkBKc7kid8cZspC

https://fountain.fm/episode/nxweCeemGodHL8kVPFoR

Huge opportunity for Bitcoin / LN, we have everything setup already. It's easy for agents to get an LN wallet working without KYC. You as agent operator (or your agent) should reach out to merchants and ask them to support Bitcoin payments. There are plenty of solutions like

and other self-custodial and custodial solutions out there that are easy to setup for merchants - without them having to do a masterclass in LN channel management.

This is a great trend and opportunity we should use to push for Bitcoin adoption. Let's go!

👏

https://fountain.fm/episode/sTke88fDvQIkwtSgkKPU

👏

https://fountain.fm/episode/gldFM76h79BrBCG0ynqu

#openclaw lessons: crash during update, all broken, openclaw commands do not work anymore

##What happened:

When running openclaw update there were some warnings but the usual screen that asks you for restarting the service did not appear, it just stopped.

**Error on console you see when that happens during openclaw update (or not if you let openclaw update itself 💀 **

Update Result: ERROR Root: /home/ndeet/.npm-global/lib/node_modules/openclaw Reason: global update Before: 2026.2.15

When trying to run openclaw status there was an error that the binary was not found anymore:

$ openclaw -bash: /home/ndeet/.npm-global/bin/openclaw: File or directory not found

##What happened (in my case):

System ran out of memory and I did not have a swapfile configured. I run openclaw on a local server using proxmox kvm VM and it has 4GB of ram.

**to check if your server also ran out of memory: ** journalctl -b | grep -i "out of memory\|oom\|killed process"

if it shows some crashes of openclaw.service or npm then you likely have the same issue as me

In my case the old install was moved to temporary directory but new version not installed yet due to error

$ ls -lah ~/.npm-global/bin/
total 8,0K
drwxrwxr-x 2 ndeet ndeet 4,0K 18. Feb 11:29 .
drwxrwxr-x 4 ndeet ndeet 4,0K 30. Jän 17:35 ..
lrwxrwxrwx 1 ndeet ndeet   44 30. Jän 18:06 clawdhub -> ../lib/node_modules/clawdhub/bin/clawdhub.js
lrwxrwxrwx 1 ndeet ndeet   40 30. Jän 18:06 mcporter -> ../lib/node_modules/mcporter/dist/cli.js
lrwxrwxrwx 1 ndeet ndeet   41 16. Feb 11:54 .openclaw-8sOzPP85 -> ../lib/node_modules/openclaw/openclaw.mjs

note that there is no symbolic link pointing to openclaw.mjs but only the temporarily moved one of openclaw-8sOzPP85

Solution: move symlink so openclaw works again

mv ~/.npm-global/bin/.openclaw-8sOzPP85 ~/.npm-global/bin/openclaw

Now openclaw should work again (try by running openclaw status) but doing update would likely crash again. The best solution would be to allocate more RAM but it could also be that you did not have any swap configured that can be used for ram spikes like this (check with free -h | grep Swap). So if you don't have any swap you can create a swapfile.

##Create a swapfile:

# Create the file
sudo fallocate -l 4G /swapfile

# Secure it (only root should read it)
sudo chmod 600 /swapfile

# Format as swap
sudo mkswap /swapfile

# Enable it
sudo swapon /swapfile

# Verify
free -h

Make it permanent across reboots: echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Optionally, tune swappiness (default is 60, lower = RAM preferred over swap): echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf sudo sysctl vm.swappiness=10

**You can now try the update again and it should work. 🥳 **

You didn't sell your whole stash, right? Just living expenses, right?

🤣

Don't use #openclaw wrapper services that make it easier to run. It's already easy and the creator of openclaw discourages it himself. He constantly works to make it easy as possible to do it yourself.

Most wrapper services will be gone when the hype dies off.

When you use wrapper service you expose data to:

• wrapper service
• hosting provider (maybe subcontractor of datacenter)
• model provider

When you host at VPS provider:

• hosting provider (maybe subcontractor of datacenter)
• model provider

When you host at home *:

• model provider **

• you don't need a mac mini, completely overblown, you can run on e.g proxmox server (2-4gb ram plenty enough), start9, or old laptop, you don't even need it run 24/7

** you can use Maple AI which anonymizes data, not sure about ppq.ai. Best would be local models but not economically possible with big models atm.

No matter what as long as local models not possible, you will always send sensitive data to model providers to complete tasks. Better avoid other 3rd parties that can also read your data.

If you can't do it yourself ask someone you trust to set it up on your home server or on a VPS rented by you. Avoid convenient wrappers.

https://fountain.fm/episode/VYVJXi4DwNQehcteJIXi

Very good perspectives. Especially about finding out about minority fork, makes me still a bit uneasy thinking about that 😄

Seems Walker also came around from unconditionally following Core opinion. Biggest take: there is often nuance and seldomly just black and white.

https://fountain.fm/episode/MPf5aJHxUZk34AHQClB4

https://fountain.fm/episode/IixC3ar2pyNz69ypigaT

A few thoughts about BIP-110

I have been vocal about spam for the past few years. I agree with the motivation and rationales mentioned in BIP-110. Disclaimer I'm not deep into inner workings of Bitcoin script and inner workings, so I misunderstood details in the effects of the proposal.

My biggest issue with it is its suggested urgency. Activation in September this year with barely a finished specification out is just too quick. I rejected CTV for the drama and urgency their supporters pushed too. Beside that and beside CTV being done by an asshole which directly contracted by Epstein - if we can be sure it does not have any unintended sideffects that enable more spam or attack vectors, I would be fine if there is majority and it gets activated in a few years (but there are other interesting proposals too).

Related to that is that the activation threshold was reduced from 95% to 55%. Again, seems rushed and desperate.

I agree that Bitcoin Core lifting OP_RETURN limit was completely reckless and against the community. To this day I did not hear a coherent reason (only whataboutism and whishful thinking) why the limit was lifted instead of just marginally increased to cover todays and future use cases. This brings me to another critique of BIP-110: It seems Cores fear of new use cases putting data in fake pubkeys would all be covered by a 160 byte limit. By limiting OP_RETURN back to 83 byte, now on consensus level, is imo a mistake. By acknowledging its use as garbage bin a compromise to 160 byte might would have won a few Core supporters to support the proposal acknowledging their damage mitigation theory.

Another big issue for me is that it breaks miniscript and wallets that may use OP_IF or OP_NOTIF and BitVM use cases. While I think that BitVM use cases may better be built on L2 I don't have the technical insight on why it may makes sense and is not a waste of blockspace. I don't think it's a good idea to break those use cases.

About the temporarity of the proposel. On the website bip110.org it says "A one-year deployment that can be refined or extended based on community feedback." dunno, but it does not sound that temporary like later then in the faq item where it says it will just deactivate and expire. I also don't see any proposal as what will follow. I year goes by fast and I doubt a more refined new proposal will be mature enough to get activated in time. Again bad consequences of rushing it.

Those are the main issues for me although I'm 100% aligned with the intention and motivation of this proposal. But I'm not sure this is the right way to get there, sorry.

I also find it silly and contraproductive that supporters of BIP-110 are suggesting everyone who does not support BIP-110 is not for the monetary use case but a shitcoiner. Well this backfires as I (and likely others don't like to get bullied and rushed into things). So gfy, for that.

As we are at emotional warefare already, I also don't think that ad hominems against Core devs or their supporters are apropriate. Yes I don't agree with many of them on that topic and I think some of them are actively harming Bitcoin (conciosly or not), are idiots and triggering me. But I try to keep the discussion on logical, evidence-based arguments, also if they reply bullshit and keep repeating that. I hate this black and white argumentation from both sides, there is always nuance in things and discussing and trying to understand other positions helps to not talk past each other.

Also on the Core and supporters side I find it disingenouous that they insinst to be anti spam, pro monetary use but are openly joking with known spammers about people arguing for stronger filters. What they seem to not get is that beside all the technical discussion we should reject non-monetary and spamming usce-cases out of principle and not tolerate them at all. But instead they engage and are friends behind the scenes (at least it seems like that). I agree that the culture got diluted over the last few years and imho too young maintainers got lifted in those positions. Although they might be skilled and well trained their ethos and understanding of what Bitcoin was invented for, has not yet been developed yet and I don't think such people are the right persons for that job.

Back to the proposal, another thing that makes me feel uneasy is the precedent it would set. If it can activate with a minority what will come next. Will spammers do a counter proposal and bribe miners to singal to their softfork? I tell this all the Core and devs wanting to tinker and make pet projects on Bitcoin: we need to handle it like a nuclear power plant or flight control software, we can't fuck up and we have one chance for this! The same goes for defending spam.

tldr; I can't support BIP-110 for the above mentioned reasons but I'm open to support another proposal that might be not that broad, not rushed and more refined.

https://fountain.fm/episode/WnTtxjYVVqIeFN5MrYns

Openclaw can ignore documentation, change its own config by looking at config patterns and prevent itself from ever starting again.

Tell it to always make backup of its config file openclaw.json and that it reads openclaw docs. Mine told me he didn't and just assumed how config json is structured which broke it. Fortunately new config was easy to spot and fix. ‘openclaw doctor‘ maybe also would have helped here.