ndeet
ndeet@btcpayserver.org
npub1qm72...74md
Let's change the world with #bitcoin. Working on BTCPay Server integrations for e-commerce solutions. Mostly PHP and JS.
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.
View quoted note →
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 @BTCPay Server 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!
View quoted note →
#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?
View quoted note →
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.
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.
View quoted note →
Fountain
THE Bitcoin Podcast • The Biggest Threat to Bitcoin | Jimmy Song • Watch on Fountain
What's the biggest threat to Bitcoin? Is it Quantum? Developers? BIP110? Governments? Or something else entirely…
In this episode, I sit down wi...
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.
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.