nomadshiba⚡⚡

its me, you know

bip352 / silent payments: sp1qqf95gnrh453sncve4yal29zedxll3k48a0kcxhted66nnu5frcshwqmduw4x6a9ggvcmesah9qu32jx95ust635ng6xrd570mpu9hhmn7cpwpee5

My Apps:
https://npub.name
https://hashrate.place

Public Key

npub1gkp4cdh5rktehjqjnqc09awey4302dpadlka6mes4fu5spes7fhqfsppqk

NIP-05 Address

me@nomadshiba.me

Profile Code

nprofile1qqsytq6uxm6pm9umeqffsv8j7hvj2ch4xs7klmwaduc2572gquc0ymspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsjnuak6

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1gkp4cdh5rktehjqjnqc09awey4302dpadlka6mes4fu5spes7fhqfsppqk

Show more details

Last Notes

2026-08-09 00:53:42 UTC

its not over
https://www.youtube.com/watch?v=CUSgE1YOW2c

2026-08-09 00:34:17 UTC

- reply

if this doesn't resolve now. we can keep fighting, it might take years a but the game theory might prove us right in the long run.

2026-08-08 22:36:48 UTC

https://blossom.primal.net/580ceb4893aec03aaa89198a083e80ed5a2c23287ab7ac1f3dccc717f999b899.png

2026-08-06 07:19:35 UTC

- reply

i dont know my client still sees one chain

2026-08-06 07:17:24 UTC

- reply

you guys use hardware wallets? i do the math in my head, with the seed in my head, that i created using quantum field noise.

2026-08-04 15:34:33 UTC

- reply

what are you saying?

2026-08-04 15:31:06 UTC

there is another sneaky misinformation camping that has been going for years.
people think "don't trust verify" is about self-custody, like having your own keys. which makes no sense.
its about running your own node, having your own verified copy of the timechain, so you can verify things.
self-custody is about "not your keys, not your coins", or "your keys, your coins" depending on the way you look at it.

2026-08-04 08:45:02 UTC

- reply

GM MIKE

2026-08-04 08:41:14 UTC

- reply

your keys, your coins

2026-08-03 19:59:27 UTC

great answer to many
https://blossom.primal.net/9c1a169c7fbed05d0a66a02ae02ccf025f8aecbe84677b80de9b7b52bbc3ae74.png

2026-08-03 09:41:30 UTC

EVERYONE SHOULD SEE THIS, SHARE IT
https://www.youtube.com/watch?v=F6Pig2rRoGE

2026-08-03 09:33:59 UTC

- reply

Okay for example this is an example of me using Handy right now. So right now I am writing this post, I mean speaking this post using my own voice on my PC. But I usually use it for example while talking with LLMs as well, large language models. So I use it during that as well, mostly. So I don't like use it for writing messages and stuff most of the time, I mostly use it for like writing to LLMs and stuff in my terminal.

2026-08-03 09:30:24 UTC

BTW Handy is a great speech-to-text client. really useful have been using it for almost a year on my linux machine.
https://github.com/cjpais/Handy
Whisper Large model is great, fast and consistent, its amazing.
https://blossom.primal.net/9704996c26f91ff2e93347d3ae216cf893340b4a9396bad052862fbae7734890.png

2026-08-03 08:05:15 UTC

- reply

yeah i meant as a user if you dont need to sync blocks, that means you just wanna use electrum.
tho electrum should be built in in bitcoin clients at this point.
---
im gonna yap a little:
the way i look at it is. its hard to verify funds you have without downloading all of the blocks/txs and verifying it fully.
its true you can only trust pow, but that doesn't prove if everything in those blocks are valid or not.
also i think if people get used to not being a "full" node it leaves a few big full node operators. which kinda centralizes the network.
i believe every bitcoin user should have their own bitcoin client have all of bitcoin offline.
bitcoin is not distributed, distributed kinda implies all of the nodes have some of the data, and they combine to create "the bitcoin network".
bitcoin is decentralized, meaning everybody has their own instance of bitcoin. they run the bitcoin itself. everyone runs all of bitcoin themselves.
that's why you can verify without trusting, that's why everyone decides what is the bitcoin's rules are for them, if you disagree, chain splits. etc. everyone has their own copy of the events.
that's why keeping bitcoin lean and mean is important, so every bitcoin user can have their own node.
so you should have your own. copy of the chain as fast as possible. and start staying in sync with the current state.
i believe L1 chain is something that should be small and everyone syncs, a final settlement everyone syncs and agrees on.
on top of this L1, job of an L2 is creating an isolated payment realm/channel that not everyone has to sync with. similar to lightning, nobody else needs to know or download my lightning txs, its an isolated state. L1 only sees the final settlement.
so that's why i said we need to do the initial sync as fast as possible with the least amount lf bandwidth.
---
so issue is existing bitcoin software sucks for user experience.
you have to install bunch lf software like the node set it up correctly, then install electrum, then install mempoolspace so you can actually see what is on your node, etc... its hard complex, and slow.
you can get a node in a box, but telling people to spend money to get their own node, is kinda kills the vibe, and not how you create mass adoption. or they can install something like start9os on a device they don't use, that's again complex amd requires you to have something laying around. again that's not something anyone can do on a whim.
so basically we should have new node software, bitcoin client that includes all of these + storage optimization to reduce disk space, and a new way to sync with compressed chunks instead of block by block. to reduce storage usage it should be opinionated a little, full nodes only, indexes are always on.
when we reduce the storage and the tech catches up, we can also finally have node in a phone, and can add bluetooth support to p2p network and maybe more. so not only sync through the internet but also bluetooth.
etc.
but most important points are:
- storage
- bandwidth
- speed
that's what my goal is.

2026-08-02 23:09:20 UTC

am i getting old? or was i like this always? getting tired easily.
come to think of it maybe im better now. maybe i was worse before. idk.
GN

2026-08-01 22:04:02 UTC

https://blossom.primal.net/c88e0fcc5deca1ef0d8a8b41c1fbfd1f90827e6ca8725f9251ba6ae2ff98096e.jpg https://blossom.primal.net/9055f67fba436d45625769fd2dc510095a492c2cf5f20ece225c8e0e9bd1546e.jpg https://blossom.primal.net/e50763a0efd0d436b301e4759086093c1ea4d942d0e2906a43f10c433fe097d5.jpg

2026-08-01 22:02:12 UTC

GN🍃

2026-08-01 21:48:57 UTC

learned this from luke
just call them "liar"
don't complicate it, don't try to make people understand their layered lies.
just call them a "liar"
this applies to everything, not just bip110.
really useful.

2026-08-01 12:34:44 UTC

EXACTLY
https://www.youtube.com/watch?v=rAPp3NBYhFE

2026-08-01 10:20:34 UTC

THIS IS BIG
#nevent1q…jxhc

2026-07-31 14:20:22 UTC

- reply

dude is acting all weird instead of owning and fixing it. truly mentally ill

2026-07-31 14:19:03 UTC

cope
#nevent1q…7eef

2026-07-31 08:20:42 UTC

- reply

honestly, and just to escape from a GPL license is insufferable

2026-07-31 06:35:43 UTC

- reply

exactly

2026-07-31 04:01:22 UTC

stop riding the big bitcoin dick

2026-07-31 03:58:26 UTC

corruption is a short term thinking low iq action. corruption is stupidity.
if a person against a patch(bip110) trying to close a vulnerability(taproot exploit), then expect them to be stupid about other things too.
scammers, exploits, corruption, stupidity.
dump your COLDCARD

2026-07-31 03:29:16 UTC

- reply

generated from different software, generated from different pairs of dice lol etc...
dont trust the dice manufactures.

2026-07-31 03:16:50 UTC

- Don't trust someone else's seed phrase generator.
- Use a multisig with keys generated using different methods.
- Have a SECURE passphrase on top of your seed phrase.
#nevent1q…gudq

2026-07-31 03:13:45 UTC

IF YOU HAVE COLDCARD MOVE YOUR FUNDS TO SOMETHING THAT'S NOT COLDCARD. FUNDS AREN'T SAFU

2026-07-29 23:35:07 UTC

- reply

collect

2026-07-29 22:46:30 UTC

24h clock sucks btw, i use 12h clock, easier to read. and i live in a 24h clock region.
GN

2026-07-27 07:46:39 UTC

- reply

once it appears doesnt disappear until i clear the browser's data or cache

2026-07-27 07:45:34 UTC

- reply

its mixed content error.
you are running scripts, or loading iframes from http sources, instead of https.
it appears randomly after a while, so probably a widget? or iframe or something?
like while scrolling on the timeline?
https://blossom.primal.net/f5e59c6e4ca8fe902c57626e85be2c905032d56897df64d92a439c4aafde2c14.png

2026-07-27 05:52:06 UTC

- reply

this sounds like a private message.

2026-07-26 16:12:47 UTC

- reply

i dont play games much anymore so haven't tried

2026-07-26 15:45:41 UTC

gmod was fun
https://youtu.be/PrJ-6H6G9UQ

2026-07-24 15:05:32 UTC

- reply

we need 300KB blocks.

2026-07-24 15:03:24 UTC

You have 2TB disk space, and you have to pick between storing Bitcoin Ledger, Games, Pictures and Videos, or LLM Models.
Issue is why do you have to pick?

2026-07-23 02:38:55 UTC

- reply

i dont like nostr streaming through a centralized relay anyway.

2026-07-20 19:33:50 UTC

im keep winning, i think they posted me on a chat room or something, amazing.
https://blossom.primal.net/6e8ee8a92c2d443c9931cb1b0276a9115a03581fcf7a5e19f03f493019a1b0fe.png

2026-07-20 16:12:35 UTC

this new "SpammersGFY" BIP110 signalling block is so cool
https://blossom.primal.net/5f3748e19b910321dad21288bbcfb3abbeb48d76a61f4de6c9d8d745a6644810.png

2026-07-20 09:03:13 UTC

make txs with low fees
https://blossom.primal.net/b526166b11ce95f265b61b9e2ea69c3e2f6d53b29bf433075fbe07d7c62b01bf.png

2026-07-20 03:20:42 UTC

got an achievement, slopplopp blocked me
https://blossom.primal.net/dd3b8743d39c922839f1b600a8952e96a38d537043e37f82fe20a462a4ff9938.jpg

2026-07-19 09:09:30 UTC

- reply

so it happens, randomly. every time i fix it byte clearing the SSL cache and stuff from Brave/Chrome.
idk about the exact reason but it seems like certificate is lasting in cache longer than its expiration or something? idk weird.
if it happens again, i will try to log more info

2026-07-18 08:04:29 UTC

As Mechanic said WE DONT CARE
https://www.youtube.com/watch?v=yCKiGzGc_2Q

2026-07-15 15:22:49 UTC

@nprofile…twc2 sometimes getting "Not secure" SSL errors on your web frontend.

2026-07-15 14:12:59 UTC

mimi is at it again
https://blossom.primal.net/b7c9d45919942944ec12184b26cde21bb38428f7ecbccfa8b0c0bfb0271f56d1.png

2026-07-13 09:39:35 UTC

summer is OVERRATED

2026-07-11 02:42:20 UTC

- reply

bip110 is not a filter

2026-07-10 13:30:00 UTC

- reply

just do it

2026-07-10 01:13:13 UTC

- reply

i hope in the later years we can remove witness discount, and also lower block size limit to 300kb.

2026-07-09 22:21:21 UTC

GN
https://blossom.primal.net/008ed642396e949777686f903716e994cdc2906f93bb98e01a6a622958d2b33f.mp4

2026-07-09 08:32:01 UTC

just realized i didn't eat or drink anything for the past 2 days

2026-07-09 07:34:08 UTC

- reply

i just woke up today and thought:
maybe you can try glass shaped candy?

2026-07-07 11:25:28 UTC

- reply

i like bip110.
we should also release the cat.
we should also remove witnesses discount.
we should also lower the block size limit.
we should also have a websocket and bluetooth protocol for p2p, along side the tpc one, and support dht as well as tor and ip2 built in.
electrum endpoints should also be built-in.
pruned node options should be removed to make full node size more optimized by leveraging built-in electrum indexes.
we need a new gui as well, and built-in explorer.
plugin support also needed.

2026-07-05 12:55:05 UTC

- reply

https://bip110.org ???

2026-07-03 09:17:13 UTC

- reply

https://bip110.org/

2026-06-27 05:23:51 UTC

GM
had some good fun dream

2026-06-18 20:01:29 UTC

- reply

bip110 is bitcoin, everything else chose to split, not bip110.

2026-06-18 15:54:32 UTC

- reply

https://blossom.primal.net/691482974b5ba8ccc16ae8f0aee590936226b283fb0e5b319056f3e1fbc5e745.mp4

2026-06-09 14:30:30 UTC

- reply

also i think you dont have DM inbox relays.
you can try yakihonne

2026-06-09 13:20:53 UTC

- reply

did you get my reply in the dms?

2026-06-09 08:05:15 UTC

Support BIP-110 you cowards!

2026-06-09 05:22:15 UTC

- reply

hey @nprofile…s6gp throw a dm

2026-06-09 04:39:02 UTC

- reply

learn to read retard

2026-06-08 21:40:50 UTC

- reply

you didnt give any reasons, made up arguments. its ok to not know things, you dont have to try hard to appear correct.
you are constantly lying about how kaspa works and its cryptography, using meaningless jargon to appear more qualified or feel better.
read the whole thread.
if you are gonna support kaspa at least learn how it actually works.
https://blossom.primal.net/25e75bffef2b8d71f0b19f66e979d9c367eeb55482e0e4323996fd81d4e0c5b8.jpg

2026-06-08 20:28:37 UTC

- reply

Same low iq energy as:
"Oh if ethereum security is just an illusion. Go attack it. You can't"

2026-06-08 19:59:52 UTC

turns out i was right.
it really is a delusion of a solution.
#nevent1q…v24m

2026-06-08 14:46:53 UTC

- reply

you dont seem to understand my point.
you are still thinking about a decentralized network where one "bad guy" does something out of the ordinary.
thats not about that, thats about how much you can resist "official" change. the decentralization aspect.
i already mentioned your point here:
> only way you can reject it meaningfully is you are online at that time, and see the invalid (for you) tx. and out right deny the utxo set.
you make most pow the valid chain (pre-pruned), as long as miners wants a change, that change happens.
once it happens no fresh node even with an older version rejects that chain. you just ride along.
again `utxo_commitment⁠` doesnt prove the specific script was following your ruleset. it only proves utxo set was valid, and seen as valid and has been built on top of it in the past by others. not you. call it what its, which is trusting the collective, social consensus with pow.
you can accept trade offs and say, "yeah i think kaspa does enough" but you dont do that. you insist that utxo_commitment⁠ and pow means verification of past txs some how.
you even admit 51% attack could create invalid utxo for your ruleset. thats the definition of utxo_commitment⁠ cant verify tx was following your ruleset back then. it means there is consensus and work done to accept that history no matter it fits into your rules or not. that's compliance not verification.
another example if you do a temporary hard fork that get deactivated a while later, even the freshly running old version nodes follows the hard fork chain after it deactivates.
its a really simple question:
Q: Do you know every TX before you is following YOUR RULES
A: No
but you keep arguing that "no i can verify", that's just wrong, you can only trust network in large says its good.
you didnt even answered bandwidth point, even if you are are pruning you still download. and with the goal of 100bps that looks even worse. do you think someone's laptop sync with every tx ever worldwide without hogging some stuff?
you also didnt answer periodic "smooth" hardfork activations kaspa has. thats not decentralization, thats a realase schedule of dev team. everybody complies to updates. node impls auto update.
you can't know if history was valid, you just know history has big support.
when i first asked "do you run kaspa" and you said "yes", you were wrong. you dont run kaspa. you listen to the kaspa network. illusion of a node running. if you were running it you would run it from the genesis. yes you can reject blocks as long as you are live. but unlike a bitcoin node you just accept what came before you. you TRUST others before you acted the way you hopped they would act.

2026-06-08 11:03:37 UTC

- reply

proof of consensus != proof of enforcement
also maybe you cant understand it but "L1 should be slow" isn't dogma. it's the cost of letting anyone verify without permission. you can disagree with the tradeoff, but you didn't solve anything. everything works the same its 1+1=2 its the reality of the universe. you love using words like "thermodynamic" so much, its not so hard to understand. its not a bitcoin thing, its any system ever.
you started a new kaspa node fresh:
- downloads the pruning point proof (just headers, not full blocks)
- checks PoW on those headers (only for ordering/consensus, not verifying the txs inside them)
- checks ghostdag structure + blue work (only picks the heaviest proof, says nothing about tx validity)
- downloads the UTXO set from an untrusted peer (the list of who owns what, streamed to you in chunks)
- hashes that set with muhash, compares it to the `utxo_commitment` field in the header (only confirms the set matches a number a miner wrote into the header)
- validates txs in the pruning point block only (that single block, against the set it was just handed)
- everything before the pruning point: never executed (no scripts run, no signatures checked, data never even downloaded)
what verifies what:
- PoW: energy was spent on the headers
- ghostdag/blue work: this proof is heavier than competing ones
- muhash check: the set you received matches a number in the header
- nothing: that the number was produced by valid txs following the rules
the `utxo_commitment` is just a value in a header. the node confirms "the set i got matches this value." it never confirms "this value came from valid execution." consistency, not correctness.
proof of consensus, not proof of enforcement.
nodes will rejectrt `utxo_commitment` if:
- a utxo set that doesnt hash to the value in the header, meaning someone hands you a snapshot thats been tampered with after the fact. the hashes won't match. rejected
- the only thing that breaks the check is a mismatch between the bytes you received and the committed hash. basically checksum.
- only way you can reject it meaningfully is you are online at that time, and see the invalid (for you) tx. and out right deny the utxo set.
`utxo_commitment` doesnt enforce that the transactions which produced that utxo set were valid. its generated by the miner who mined that block. if devs pushes an update and miners mine based on it during a period. and days pass. you have no idea if it fits your ruleset or not. you just accept it because its the most pow.
a fresh node goes:
does my downloaded set match this hash? Yes. Accepted.
it has no way to know the set contains coins that should never have existed.
the `utxo_commitment` proves the set matches what was committed.
it does not prove what was committed was legitimate by your rules.
it catches tampering with the snapshot, not "fraud" or period of rule change baked into the history, deep enough.
its trusting the work, not verification. and assuming the bandwidth a kaspa node spends, you cant have a lot of nodes that you cant easily find one that is telling you to double check that older block. if you can find a copy of the said block of course. assuming only few big cloud runners will be running a full node soon.
source: https://github.com/kaspanet/rusty-kaspa

2026-06-07 21:53:49 UTC

- reply

"Trust the 'Science'. Even thought I don't get it fully. Because it sounds sciency~"
"Just trying to prove myself right any means necessary, mentioning things that doesn't even exist in Kaspa"
You just hear some stuff that you dont fully understand and, go "oh so thats why" *clueless*.
THE mAth doesnt "prove" what you think it proves... Or you dont know what is suppose to be proving.
you think you have some cool new solution while mentioning 40 years old papers.
kaspa literally doesn't use zero knowledge proofs.
it uses muhash commitments and sampled headers. which is a hash of a set. it commits to what the set is, not to how the set was derived.
even if it did, zk proofs require a prover. someone generates the proof.
bitcoin doesn't need a prover. i am the prover. i run the computation myself from genesis.
you invoked zk proofs to sound technical. but kaspa doesn't even have them. and even if it did, it wouldn't solve the "valid by whose rules" problem. it would just move the trust to whoever generated the proof.
you don't even know what the scripts are.... as a newcomer node.
https://medium.com/@jcroger/why-archive-nodes-are-no-longer-essential-the-kaspa-proof-f15d3b64d24a
> While you can’t prove cryptographically that pre-pruning history is valid once it’s dropped, **social consensus** ensures that if deceit happened, at least one honest node would have detected it and preserved proof. This hybrid model guarantees consistency
https://hashdag.github.io/blog/syncing
> The primary goal of consensus systems is **facilitating agreement, not enforcing consistency**. And if the economic majority happens to follow and maintain a ledger to which an invalid transaction entered at some point in history, so be it,
> Kaspa nodes prune block data by default, and new nodes by default do not request historical data, rather, they **sync in SPV mode**, i.e., by downloading and verifying only block headers.
kaspa is just the other side of the bcash coin. "fuck verifying txs, we will just have lots of txs"
honestly im tried of all "lets make L1 fast" "solutions". L1 suppose to be slow and small.
stop trying to walk around it.

2026-06-07 18:59:42 UTC

- reply

also no. you cant assume tx fits to your rules because of a "proof".
that would be the best compression ever created.
you are losing information.
its impossible.
as i said in the beginning "delusion of a solution"

2026-06-07 18:57:25 UTC

- reply

you are still thinking about someone breaking rules. not rule changes.

2026-06-07 16:58:44 UTC

- reply

there is no way you can know if someone rejected something in isolation at some point.
the commitment proves the utxo set is consistent with the history that was accepted. it doesn't prove that history was valid by your rules.
those are different things.
you still cant verify what script ran, how.
the commitment proves "this utxo set is the result of this history"
it does not prove "this history followed the rules you would have enforced"
"this utxo is valid", valid by whose rules?

2026-06-07 14:12:30 UTC

- reply

> that block would be rejected by every node online at that moment.
you are saying it yourself here "at that moment".
what rejecting a change proposed by the kaspa devs looks like? what happens if miners support the change but you don't.
also nothing blindly trusts PoW.
but with default kaspa node if software rules changed at some point for a while you would have no idea because you dont replay those txs. you just trust what the network tells you the utxo is.
if a chain has 2x of pow of your current chain in bitcoin, but has a single tx that doesn't fit into your ruleset, you wouldn't pick that chain.
but with kaspa you have no idea that happened. you either have to always online to catch it, or run and verify every tx from the genesis.
you can only prove everyone on the network agreed that valid utxo set looked like "this" at some point.
no matter how many tricks, ideas you have not to verify txs one by one for real. none is actual verification of the tx.
that's trust, not verification.
you cannot meaningfully prove anything about the past.
have fun complying to another hard-fork that activates "smoothly"

2026-06-07 11:29:19 UTC

- reply

you get the utxo from from the snapshot.
you dont verify anything to that point.
you trust pow. that's almsot exactly like spv behavior.
if a bitcoin node sees an invalid tx they blacklist that block hash because the whole block is invalid.
you can't build on invalid tx. is that so hard to understand?
you can't just download a utxo set and call it verified just because it was timestamped in the DAG/chain.
you dont even know if the chain you are on is valid.
you just pick what ever has the most pow.
because you can't verify a tx from one week ago.
you trust the utxoset your are given.
be honest with yourself.
you are claiming things that are not real. be real.

2026-06-07 10:04:54 UTC

- reply

This dude mining with 4EH/s just found 2 blocks in the last 24 hours!
#nevent1q…4jay
https://ocean.xyz/stats/bc1q3595j3lnu4ywus85p5369tq3j983fqa786p3sq

2026-06-07 07:01:58 UTC

- reply

that's exactly what i said.
i also don't like bitcoin pruned nodes but they will at a least replay everything from the genesis. kaspa will just trust the PoW as if it verifies the txs somehow. that's very similar to a bitcoin spv node.
you said it yourself, you are using PoW as a trust mechanism to pick the chain, you are not validating blocks older than utxoset snapshot. you have no idea what older txs are, you are not validating that. you have no power to go "ah this old tx makes no sense, let's blacklist this block and find another chain without it". miners and full nodes control your chain/DAG. you trust the PoW, you dont verify. that's literally a SPV node.
and starting from utxoset snapshot is not a cool feature of kaspa that's just sacrificing verification for faster IDB. why? because you produce 10blocks per seconds right now. no normal user can sync that. its terabytes of data even now.
bitcoin limits block size and time on purpose to keep the chain small. because its the global state that every bitcoin user has to verify and sync with. then we have things like lightning, ark or others that create isolated states where not everyone has to sync with. that's how scaling works in any system, not just bitcoin.
your design sacrifices sovereignty, decentralization, and verification in favor of blocks-per-second.
#naddr1qq…lzae
and i said the node you linked only connects to 9 nodes because again a normal home hardware and internet can't handle 10 blocks per second i guess. how much bandwidth does that thing spent that you/they had to lower the node count to only 9?
why not 50 nodes?
you say you are running kaspa, but all you have is a pruned SPV client with ✨DAG✨. by desig kaspa is controlled by the miners and "archival" full nodes. you dont have a power to say "no". because you trust pow, don't verify.

2026-06-06 21:28:35 UTC

- reply

every cycle its the same always, we expect it, it happens, nothing new.

2026-06-06 19:21:24 UTC

- reply

that's not running kaspa, it just a peeking node/relay.
so you're trusting a handful of full real nodes for the entire history of the chain, since your pruned node doesn't replay anything.
it just accepts a UTXO snapshot. if those archival nodes lie, you can't detect it if you weren't listening during that time.
and if the ~317 node operators wanted to change the rules, what stops them? you just had a hard fork last month that the whole community "smoothly" complied with, and the installer you linked auto-updates itself. that's not a decentralized consensus, that's a dev team with a release schedule.
also curious what the bandwidth looks like at 100 bps, since you're already throttled to 9 peers just to make 10 bps manageable on normal hardware.
it sounds like another high-throughput-first crypto project, but with the illusion of node running.

2026-06-06 17:33:30 UTC

- reply

you sound like a kaspa user, are you running the kaspa on your computer?

2026-06-06 15:08:31 UTC

if you really want yield on your bitcoin, dont play finance games.
just rent some cheap hashrate and start mining.

2026-06-06 07:22:05 UTC

- reply

are you running kaspa?

2026-06-05 10:48:23 UTC

- reply

also linux ux is more pleasant now, thanks to ostree and flatpaks

2026-06-05 10:44:25 UTC

- reply

also monero doesn't have a size limit. which i don't like as a 300kb blocks supporter.

2026-06-05 10:33:20 UTC

ok work coding stuff is almost over.
100% done tonight.
then i continue making the atlas!!!

2026-06-05 07:36:28 UTC

people play with all kinds of bitcoin, crypto, and fiat games, but can't just buy bitcoin.
then they complain about the state they are in.

2026-06-05 07:00:26 UTC

Fountain is cool.
but wish it was nostr native.

2026-06-04 18:16:04 UTC

- reply

@nprofile…2jpv didn't look at it myself yet, but you asked something like this i right?

2026-06-04 16:27:15 UTC

follow your solar weather

2026-06-04 15:55:06 UTC

BTW I made this few months ago. Some sites dont support Nostr Remote Signers like Amber, only support browser extensions.
This extension acts as a Browser Nostr Signer but bridges the connection and let's you actually login with your Remote Signer instead.
https://chromewebstore.google.com/detail/remote-nip-07/dkeaighngpmilhnepghmdfjlmlgaomcl

2026-06-04 12:12:22 UTC

- reply

as always take the ideas, dont make heros.

2026-06-04 12:06:08 UTC

- reply

it changes based on the scale, the project, and the architectural complexity.
i cant think about "vibe coding" my personal projects, for example.
i also get my hands dirty at work once in a while. even when im not manually typing, i still have to verify the architecture the LLM created, explain the design in my head, how the code should work, etc. i cant imagine someone less experienced doing that well.
there are also things that require "inventing" like innovative game development, where you have to come up with new tricks, reduce allocations, make things faster, find new solutions. where LLM biased towards applying known solutions instead of creating domain specific solutions. they dont come up with an idea while in the toilet.

2026-06-04 11:50:45 UTC

- reply

im rarely motivated about the work code, so i kinda like it.
leaves me more time for my own projects.

2026-06-04 11:49:06 UTC

- reply

OMG LOOK AT ALL THESE PROFITABLE HASHRATE UNDER THE HASH VALUE, GO RENT IT.
https://blossom.primal.net/c42a579b2e8b3b775c05cec86f63e94372e101d032de4ad2d2a802853cc9ec1e.mp4
#naddr1qv…7rzv
#naddr1qv…89ss

2026-06-04 11:43:54 UTC

- reply

gonna make my own DE somewhere next year. fuck this shit.

2026-06-04 11:42:32 UTC

- reply

some dumb thing, hard-drive manufacturers started doing first years ago.
then apple started using it, and now some Linux DE(s) are started to use it...
it was fine when it was just Apple, but wtf Linux...
so annoying.
NO BODY USES 1000s it makes no sense. its a lie.

2026-06-04 11:31:56 UTC

you guys code to get employed?
i have nothing against people but.
people "learning to code" to get employed somewhere tires me so much.
when we used to talk about programming it was about building things, optimizing things, ideas, discovering new ways etc.
now if you mention programming people are like of yeah the job title: programmer. i mean i work but that came later. i work because i know it, and i need money. i dont code because i need money. i code because i gotta build.
if i had a lot of money, i would be coding more.

2026-06-04 11:14:58 UTC

clients should warn people about non-blossom uploads.
they can be tampered with, cant be verified. (unless they have the file hash in the event itself as well, i dont remember the nip)
i know many people use non-blossom cdns, but thats the points. the warning should scream to their face.

2026-06-04 11:06:52 UTC

- reply

yup thats the issue, you are using a blossom server, but its not in your blossom server list.
so probably clients are treating it as just another cdn. doesnt verify it.
this also means when you upload it, you dont have mirrors of it on other blossom servers.
https://blossom.primal.net/2843c145008363f280d68eb16c80a9352d704a100908b68ef98768b1ee47909b.png