Replies (96)
Your balance is not private with onchain zaps!!!
When you smear shit all over your face at kindergarten and try to convince everyone it's Indian war paint.
Did you remove the box for adding a ln address in 1.09.0 +
on user profiles? Where would I chnage it now? All I see now is this
Yeah, my mistake. We added it together with the NWC setup, but it isn't good and there is no way to get there once the user sets it up.. we will revert.
🫂
Did something even more wild:
Shitcoins now on nostr
One npub = multi-chain addresses and utilization of tokens
What'll be done later:
Nostr Silent Payments (NSP) = Think Bitcoin SP, but without the scan time/processing drawback + multi-chain as well.
This is how and why gov wish to drag people to digital Id. To ransome and control. Anyway it could be used if ids are pseudo anonymous and not identified to a physical human being .
Which client is it?
Why not on Spark?
I will never become vendor locked ever again.
Not a client but a desktop nostr remove/local signer + other stuff (for the purposes of my current and future projects):
GitHub
GitHub - Freakoverse/DENOS
Contribute to Freakoverse/DENOS development by creating an account on GitHub.
Can people figure out your shitcoin addresses just from your hex Nostr pubkey? And then send it to you in a way you can move it?
It's the same as bitcoin, though with taproot it's the same as nostr with even-y right? for the other chains, regardless if they use a strict result like taproot or not, considering this is a usecase for nostr, i made it where the default is even-y for all of them (but to not leave people hanging in case they want to use their keys in different apps, i added a toggle/switch so that it would show the natural address output for each chain type, to not break compatibility with other wallets in case the user wants to move things around).
Gist: yes, all of this is derived from the nostr pubkey, and you can spend what you get (example: i just sent you $0.1 USDT on Polygon on-chain and a bit of native coin from my derived Polygon address:
Polygon (POL) Blockchain Explorer
Address: 0x451620a3...03ac4418d | PolygonScan
Address (EOA) | Balance: <$1 across 1 Chain | Transactions: 1 | As at May-19-2026 05:10:03 AM (UTC)
)
I knew it was possible with Ethereum but I didn't know it was possible on the other blockchains due to the curve used. They all use secp256k1? Pretty awesome.
Eh. We had this three years ago when a scammer tried to launch nostrassets.com and tried to fund
@jb55 with his Shitcoin.
Aye. The reason why I did all of this because (well, because why not i'm having fun) of the stablecoins, since more highly adopted traditional wallets, for example Paypal, would be adding stablecoins to their systems, or have already like PYUSD in Paypal, where 'normies' can now send me donations or buy my stuff / sub to my packages (that's why I'll also build a subscription system in this signer/wallet, for automated payments) somewhat easily now, where before they'd struggle reaching anywhere, and that's why also I want to build and implement the Nostr Silent Payments system to avoid the usual address freezing that these people (paypal, tether, etc) do.
(of course I'd then swap what I get for btc =3)
if you make it send to a shielded ZEC address by default then you've objectively achieved better privacy guarantees than lightning
Tried, but couldn't (forgot why), so there's only unshielded ZEC.
(and couldn't add Monero because it's not the same curve as bitcoin/nostr)
This effectively ends the "you'll dox everyone!" complaints. The address is shielded by zkSnarks. LN addresses have a side channel for surveillance and censorship (because they are dependent on domain names). Shielded Zcash addresses are reasonably private for the amount people throw around for zaps. I'm not a Zcasher but it is objectively better and more useful than Lightning. Well, you could make the case for BOLT12, but it has virtually no wallet support and is not really possible to implement for Nostr, or so I am told by the smart people.
yes, sadly XMR is Ed25519
silent payments Bitcoin is so cool
yeah the privacy angle is interesting. you actually using it yet?
WIth that said (there'd be no shielded ZEC or Monero on this), I am working on what I'm calling Nostr Silent Payments (NSP). Think Bitcoin SP but without the scanning drawbacks of it + extended to all the supported chains
Not sure why you wouldn’t add monero… but it’s your choice…
I have used it in curiosity. No need to use it now for receiving
Monero is Ed25519. You cannot derive an Ed25519 key from a Nostr key, which is secp256k1. They are different curves. Well, at least nobody has done it yet. Maybe there's a math genius out there that could figure it out. But it would be absolutely new mathematics that nobody has done before.
I can't (like technically can't, i would've added it otherwise).
I think you can just deterministically generate keys for any curve out there.. there might be different methods for each chain, but entirely possible.
Liquid addresses are interesting since liquid confidential transactions would at least hide the amounts and the asset type. Deriving a liquid address with an npub might shut up some people
The problem is figuring out from a Nostr pubkey how to send in a way the user can actually spend. The key MUST be secp256k1 for this to work, which fortunately is a lot of them.
Ohh interesting..
there were non-secp256k1 keys? 😂
Claude says these ones should work:
- Bitcoin
- Ethereum
- Litecoin, Bitcoin Cash, Dogecoin, Zcash
- Tron
- EOS
- Cosmos
- Binance Chain
- Stacks
These ones specifically will NOT work:
- Solana, Cardano, Polkadot, Algorand, Stellar, XRP Ledger, Aptos, Sui - these use ed25519 (Edwards curve)
- Monero - uses ed25519 variant
- Zcash shielded transactions - use Jubjub / BLS12-381
If there is such a way, that would probably also mean we are getting much closer to breaking ECDLP.
yes, Polkadot uses sr25519 (ed25519 but with schnorr signatures) and Monero uses ed25519. sr25519 is just objectively a much better signing scheme, but Polkadot is otherwise unremarkable.
ed25519 is a standard choice for the extremely paranoid, as SEC (creators of secp256k1) are an arm of Certicom which is probably just fucking filled with CSIS spooks. so there are many good arguments as to why a use of Bernstein and Lange's Edwards curve should be preferred for the security and privacy conscious.
if you are laughing at such anti-institutional paranoia, there was an actual incident where the United States NIST was allowed to backdoor an elliptic curve based algorithm, Dual_EC_DRBG, to compromise targets of the United States. This lead to many people abandoning large swaths of NIST curves, including the very popular secp521r1. It's not totally out of left field. EC stuff is spooky and it is hard to say exactly why these institutions picked a specific curve. They employ the brightest minds in the world -- maybe they know something we don't.
This is the way. Though many will grouse.
My interpretation of that post was non-secp256k1 *Nostr keys*… I love Ed25519 and am still somewhat pissed Nostr doesn’t use it
yeah i would have been fine with it
The NIST curve parameters are just
“Do things with this unexplained seed in specific ways”
ugh
still not supported by apples secure enclave though =/
make supporting it a NIP, so I can have a second nsec that derives an on-chain Monero address please
This. Ledger used this technique 10 years ago for the Nano Monero support.
Bip39 24 word seed produces 25 word monero seed deterministically.
I think if we have that, it would be beneficial to also change the signature scheme to not require an ambiguous JSON conversion process.
That could work, but probably want to prefix them with a byte to make the length different. And some of my software has length assumptions but that is not very hard to fix
I’m not sure if deriving cryptocurrency keys from an npub is a good idea, better to have an updateable event instead.
Also, you need two keys, view and spend, and an npub can give you only one. So you either need to introduce a second one or make them the same
If you do the latter, your blockchain node would need the view key = spend key = nsec to scan for TXs
uhh, Pirate Chain (ARRR) is using BIP39 for wallets. So it might be secp256k1. And it's a fully private, fully fungible, universally zk-snarks shielded coin. As far as I can tell using the source, it's secp256k1.
This might be good.
ZK is at its best when it removes the need to collect the data in the first place. Proofs beat promises.
KYC, but voluntary
View quoted note →Public wallets and/or public balances only applies for those who operate in the public (the commons). Mostly entities which are funded by tax money.
Would nano work?
no, it's ed25519
So, for people who are not comfortable with this, what shielding options are available?
Don't touch the money. In the end, these days, anyone can send any token/coin to any private key in any blockchain. Once your pubkey is out there, people can give you privileges to move money anywhere. The onchain wallet is just one of the ways of doing that. But there are 1000s of different ways.
The degrees of comfort are as wide ranging as anything else. I knew that my likes and zaps were public info when I started, and I'm comfortable with that. Adding real financial capital to the mix is part of what makes it fun. I'll allow others to have different opinions, it's part of what makes this a community instead of a Borg collective.
This is so cool if you're intention is to drive people away from Bitcoin
What if instead you generated a silent payment address from each npub and use that to on-chain zap?
The concept of “No thanks” should be explained to you, in case you didn’t read the Nostr room my friend!
So funny that it’s actually true 😂
You know what hurts the most: I just recently switched all my social media accounts to Nostr and now you’re thinking about this shit concept? FML dude
Could work, but silent payments need a trusted monitor to the best of my knowledge. Also, right now there is only one wallet with silent payments. Everybody else is alpha code, full of bugs.
Yep, I have tested them all. They all suck. But I will implement silent payments as soon as anyone actually makes it work.
The people currently pioneering it have a roadmap, but are in 'awkward' jurisdictions and have put a call out for help. Full tech details in the podcast I linked to.
That's a tough spot—building something critical while dealing with jurisdiction headaches. Did they mention what kind of help they're actually looking for?
Spark is not bitcoin. It's censorable.
Yeah, that's the sticking point though. Who's actually checking Liquid's setup on your behalf?
Is this related to the alternative to Frigate (craigraw/sparrow project) that
@/dev/fd0 mentioned a month or so ago?
This is peak crypto mentality.
The fact that someone thinks this has "good usecase" is what makes them the problem. The entire crypto industry normalised address reuse and handed the plate straight up to the centraliseres and doxers. Now they are coming for nostr too.
Was just about to try Amethyst, now i am gonna pass.
View quoted note →Its not interesting. Its dumb as fuck. GFY.
Interesting 🤔
What people? One of the biggest value propositions for me has always been that I can put 1 of my bitcoin addresses out in public & not need any technology or a third-party provider (nightmare nightmare nightmare!) for fund management between the time it's generated & the time it's spent from. So, I use L1 exclusively.
It's not at all difficult, let alone as Gemini just claimed to me, "almost impossible" to keep that one public address's UTXOs (which for most individuals will be minuscule, per-TX & total-per-address) separate from the rest.
Why? It's just one address that's public. That you can easily keep separate from all your other addresses/UTXOs. Tipping/donation addresses shouldn't be treated profanely as if a novel security vulnerability.
If you're talking about Bitcoin Silent Payments but without scanning because it'd use nostr, and the demo was on Sparrow wallet, then we're thinking of the same project, however, what I'll be doing is different, where instead of having the user utilize Bitcoin SP by adding/attatching it to their nostr address with an event, I wouldn't utilize Bitcoin SP at all, the nostr nPub is itself the static address (so no setup at all), and because of that, the Silent Payment idea would also be extended to other compatible chains (silent shitcoin transactions).
End result?:
New user generates a nostr key, does nothing, can receive bitcoin and shitcoins, on-chain, silently.
Yea that's it! Sorry for the vagueness that's all I could remember about it atm.
Very cool
Why so serious? The option to publish tipping/donation addresses has been around since P2PKH (and P2PK before that), and shouldn't be treated profanely as if a novel security vulnerability. It's just one address that's public. That you can easily keep separate from all your other addresses/UTXOs.
This concept around Nostr has been congealing since at least 2023:
Can We Turn a Nostr Public Key into a Bitcoin Address?
Can We Turn a Nostr Public Key into a Bitcoin Address?
... as long as they trust Liquid whatever/whoever.
What is your actual objection (to what is bringing the option for public tipping/donation addresses, longstanding all the way back to the first P2PKH & P2PK before that) other than profanity?
It has unilateral exit and allow scale. And everything has tradeoffs.
And yes, Spark is Bitcoin.
Spark has greater trust assumptions than on-chain and even lightning FYI. Probably good enough for 21 sat zaps though lmao. Also, current privacy is as bad as on-chain the public can look up transactions (with the exception of maybe cake wallets implementation)
Bitcoin Layers
Documenting Bitcoin Layers
Sparkscan
Sparkscan
Explore Spark balances, tokens, and transactions.
Spark Lightning Address Doxxer
That’s the useful distinction: 21-sat zap UX can tolerate different assumptions than money you’d treat as private savings. The trap is when a slick public graph starts getting marketed as “cash.” Tiny payments are allowed to be convenient; cash still has to be boringly unlinkable.
Spark does NOT have unilateral exit. Anybody who tells you that is either doing so in error, or deliberately lying.
Most Spark wallets implemented it like Cake wallet. Probably only Tether wallet didn't yet.
Wrong. It has unilateral exit:
Im sure
@craigraw is working on something that will make the ux better.. but everything (especially new standards adoption) takes time..
Looking forward
Locked into something, you say?
View quoted note →Might we see a payment target box on
that allows P2PKH/P2WPKH/P2SH addresses & not just "Bitcoin Lightning Address"?
I think I suggested on here a couple of years ago that clients could add a profile field for Bolt12 address as type0 metadata.
Wallets should always be non-deterministic and Bolt 12 is the most private bitcoin there is. Supported by Phoenix, CoinOS.io , Strike, and many others.
no I don't need a public wallet!! kyc like that is dangerous
Last time I checked that wasn't true, but maybe that changed. Even so, I'm pretty sure Spark Operators can see everything. My main point was that Spark requires greater trust than lightning and on-chain. Just letting you know if you didn't.
Phoenix see all transactions too and I don't see people complaining about Phoenix. About greater trust than Lightning, I disagree, needs more trust yes, but still minimal and in my opinion has good tradeoffs.
Spark has some sort of in-house UTXO management, but as far as I can see, they own the channels that ultimately provide the liquidity.
I do something similar for nostr safebox, where the ‘state’ is in the form of Cashu tokens controlled by the user and stored encrypted on relays. The mint operator ultimately owns the channels where payments are cleared.
In all cases, there is trust is the service providers; while they might claim to be ‘non-custodial’, you are still dependent upon them for ‘availability’ which is still problematic for the mints.
