Super Testnet

Open source dev w/ bitcoin focus | supertestnet.org

bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

NIP-57 Address

supertestnet@coinos.io

Profile Code

nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpz4mhxue69uhkg6t5w3hjuur4vghhyetvv9uszrnhwden5te0dehhxtnvdakz7ek3d6m

Publishing to

ditto.pub/relay

nos.lol

nostr.oxtr.dev

Author Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

Show more details

Last Notes

2025-05-10 15:14:30

- reply

I was on there earlier this season:
https://www.youtube.com/live/VlP6AjM28hY?si=xgQRZTkDDNLJ67AY
I was also on there last season:
https://youtu.be/N2AR0mMJMho?si=nCqkhzgJMGf6Gz9h

2025-05-07 14:21:47

- reply

Oauth is good
Nauth is better
But "no" auth is best of all

2025-05-06 18:12:01

- reply

For spam less than 150 bytes, here is the tier list:
Lowest cost option: unfiltered op_returns
Middle cost option: unspendable outputs
Highest cost option: private mempools
I support the filters because they push the cost of spam up the tier list

2025-05-06 08:15:55

Everyone saying filters "don't work" because spammers are just using op_return_bot to get around them? Yeah, op_return_bot has to charges double the regular fee rate or its bypass doesn't work reliably. This is a huge deterrent. The filters work.
https://image.nostr.build/6fd148c9789b879204f4e4cec37afc97e7888bed1cc8edbaf8ae50fac519e73a.jpg
Source: https://github.com/benthecarman/OP-RETURN-Bot/blob/master/app/controllers/InvoiceMonitor.scala

2025-05-06 00:06:57

- reply

2025-05-03 17:06:33

- reply

I like monero, I think competition is good

2025-05-02 21:12:31

- reply

Turns out it was dumb, because I forgot that you have to commit to data to the control block in a prior tx, so in that sense it's just as bad as an inscription. You could get around this by putting the data in the taproot annex, but that is non standard so it would also require relaxing the anti-spam rules, which I don't want to do.

2025-05-01 19:47:34

Nate says:
"I don't understand why it matters how blocks get filled. Use lightning for basic spending if you want to use bitcoin as money. If you can't afford to, use ecash until you can. As for ease of running a node, a 4tb drive gets cheaper everyday. should be good for a decade or two."
Everything after the first sentence seems spot on. Also, I like the idea of reducing the cost of using lightning so that poor people can acquire self custody faster. Creating multiple channels in a single utxo seems like a promising way to do that.
https://x.com/beeforbacon1/status/1917881581257023528

2025-05-01 09:54:09

- reply

> He's wrong about unencrypted receiver (or meant something else)
I meant what I said: monero does not encrypt the receiver. If it did, monero devs could tell me what encryption standard they use (in lightning, we use the Sphinx encryption standard specified in bolt4) and they could point me to the code where the recipient's key gets encrypted (in lightning, that code is here: https://github.com/lightningnetwork/lnd/blob/b068d79dfbd2f583d890fd605953d0d4fb897a27/htlcswitch/hop/iterator.go#L114)
Monero does not encrypt the recipient's public key -- it gets published in plaintext on the blockchain -- so the protocol does not specify any encryption standard for that and there is nothing in the codebase where it gets encrypted.

2025-05-01 09:44:17

- reply

I like that I can point out how lightning fixes a privacy attack vector and the response is "ok but it doesn't fix ALL attack vectors -- there's probably some other one it's vulnerable to."
Yeah, probably. But even if other attack vectors exist, that's no reason not to fix this one. I think monero should fix it too, and I am glad FCMP is being worked on to hopefully do that.

2025-05-01 09:10:41

- reply

Both of these stories start with exchanges telling the authorities what pubkey received their money. The fact that they *know* what pubkey received their money (and can prove it) is a design flaw in monero. Lightning fixes it.
Also, in both of these stories, after the money went from the exchange to the user's pubkey, the analysts watched the blockchain to see where the money moved next, and it went to another exchange with a probabilistic identifier marking the user's pubkey as a possible sender. This enabled them to contact that exchange and find out the user's identity, which led to an arrest in one case and better evidence for the charges in the other.
Lightning fixes this too, because not only does lightning not tell them what channel the money went into in the first place, but when it moves out of the channel, the analysts don't get to see that, because the transaction isn't broadcasted. So they never see the money go to an exchange and thus can never know to contact them to obtain the user's identity.

2025-05-01 08:50:25

- reply

> How did he do that?!?
I was able to do it because of a flaw in monero: by design, the sender knows what address he sends his money into and can report that info to authorities with cryptographic proof. This has led to multiple legal charges against monero users, see the attached thread for more info.
Lightning, of course, fixes this. #nevent1q…7m94

2025-05-01 08:21:03

- reply

> He is using the view key to see things that are available by design for the sender. ... This is actually a feature, not a bug nor a weakness.
It has led to at least two people getting arrested.
The Finnish guy in this article: https://cointelegraph.com/news/finnish-authorities-traced-monero-vastaamo-hack got arrested after a CEX used this "feature" to trace his payment from their exchange to his private wallet. This "feature" told them the precise pubkey which held the money, which allowed them to tell the authorities to watch the blockchain for that pubkey to show up in future ring sigs. When it did, they discovered that he sent it to binance, where they got his KYC info and arrested him.
Nearly the same thing happened to the Columbian guy in this video: https://v.nostr.build/D4Nzp22vRF35IRnz.mp4
Morphtoken sent his monero to his private wallet, and the authorities subpoena'd them to find out what pubkey they sent it to. They told them, and then they watched that pubkey to see if it showed up in future ring sigs. It did, and they kept tracing it forward til he sent a pair of transactions via a "poisoned node" (one run by Chainalysis) without a VPN, and these transactions sent the money to a centralized exchange and a point of sale system. They were able to get his KYC info from one of them (probably the exchange) and arrested him.
So the "it's a feature, not a bug" cope rings hollow. Lightning is way better for your privacy because the sender does not know what channel his money ends up in. He cannot give that info to authorities because he does not have it, so they do not know where to watch for future transactions, so they never get to contact an exchange and ask for more details about a particular inbound transaction. Lightning fixes Monero's "feature, not a bug" problem where senders can see where their money goes and then report that info to authorities.

2025-04-30 22:12:39

- reply

I think monero's ring signature tech is cool, I like that it enables something similar to coinjoins but without needing everyone to sign something. It's better than doing a coinjoin unless you can get more than 16 people to join you in your coinjoin.
I also think monero's amount encryption tech is cool and better than the encryption standard we use in the lightning network. I wonder if we can adopt it in the lightning network. Their encryption standard has a feature called "perfectly blinding" which means that even if the encryption mechanism gets broken in the future, the data you get is still worthless without the decryption key. Lightning uses a less robust encryption standard and if it gets broken in the future, it would suck very badly for historical transactions.

2025-04-30 19:50:53

Found out today that Lightspark's statechain model does NOT use a blinded server. It's not a privacy tool. That's sad. I recommend preferring Mercury's over Lightspark's if privacy is important to you.
https://i.ibb.co/C5gjcYm5/no-blinded-server.png

2025-04-30 19:24:25

- reply

> doesn't do the volume
How much volume does it have to do to count as a DNM? $1 million per year? $1 million per day?
> different threat model
How are they different?

2025-04-30 19:19:43

- reply

> different threat model
How are they different?
> not a DNM
Why not?

2025-04-30 19:08:12

- reply

As Kanzan points out, monero has serious weaknesses against targeted surveillance
If *you* are worried about targeted surveillance, lightning offers better privacy than monero

2025-04-30 18:55:53

- reply

> and irrelevant in most cases
It is highly relevant when you're being tracked by authorities. They typically start by sending you some money and then watching what happens to it next on the blockchain. E.g. that's what they did in this case where they traced a finnish man's monero: https://cointelegraph.com/news/finnish-authorities-traced-monero-vastaamo-hack
And in the Columbian case (where they ALSO traced a guy's monero) they also relied on the ability of the sender (in this case, Morphtoken) to point out exactly where he sent the money: https://cointelegraph.com/news/chainalysis-leak-monero-traceability
Lightning fixes this.
The simple fact is, on lightning, the sender can't trace his own payment, but on monero, he can, and this difference helps authorities arrest monero users.

2025-04-30 12:08:37

- reply

What a conclusion! I traced the XMR and identified its destination AND the total amount in that address on monero. @npub14a6…z6rn meanwhile, could not trace my BTC or identify its destination or the total amount in the channel where it ended up. Is XMR worse than LN after all?
https://image.nostr.build/7301be65efd1242bf40ef655993f475804c8e8cf943c240e8be9d395fe2a1538.jpg https://image.nostr.build/9327b45f48e0f10adb0b4b30be6c824357c0f77336b3744f56195fd6a718fabb.jpg https://image.nostr.build/79f839e20b0cbb1ffdf6ba8ec5a1ca2e273d15537bac9c33d69463d72ba9575f.jpg

2025-04-30 10:58:17

- reply

What an interesting experiment! Due to the imperfect receiver privacy of monero, I am able to identify the exact address where he received money as well as the exact amount in that address. I can also watch the blockchain to see if it shows up as a possible spender in a future transaction. Neat stuff! Now let's wait and find out: can @nprofile…z90p tell me similar info for the LN payment he sent to me? Stay tuned! https://image.nostr.build/eae6303f872255273ccf90bf461f2951be3ee65aef805f3db0ace2662ff696cf.jpg

2025-04-30 09:23:43

Monero user @nprofile…z90p says monero has better receiver privacy than lightning. I issued him a challenge. Will he accept it? https://image.nostr.build/f5b260fd2d4087f2887b930cce1ce08c9e9421cfd9c4db0fe7ca9bfdf84e3962.jpg

2025-04-30 09:20:18

- reply

I have a challenge for you. lnbc10641910p1p5pr6klpp5refgj5cv3k0zajlcz8hztfz4sezcv9e7hfwkv2z99m0p2mwx64dqhp5uwcvgs5clswpfxhm7nyfjmaeysn6us0yvjdexn9yjkv3k7zjhp2scqzdyxqyjwf3sp55u5qqhs88t5e5ag0d6gvacjkhfk5l7jdxc6usewu4xy8tp7y8xss9qxpqysgq0tcz422qrphc27m6xukk4xgjaawgp5ae003805wr9g3n4jrhp3hypd5tn2qj4smrc43fcfyjwlvpms0ydcjl7wchdpy2q4rst46e6ygp2vaqna
Pay this $1 lightning invoice and I will send you $1 in xmr to an xmr "public address" of your choice. We'll see which of us learns more info about where the money ends up. Are you up to the challenge?

2025-04-30 09:05:40

- reply

> Should be easy since my Monero address is on my profile.
The ones on the blockchain aren't the same as the one in your profile. Nonetheless, it's better to (1) not publish them (2) encrypt them so that fewer people can see them. You know, like lightning does.
> Lightning nodes on a route (aka third parties) can see exact amounts passing through them. Nodes on Monero can't.
In both cases they get partial amount information. Monero leaves the fee unencrypted and in fact publishes it for all to see, and this is one of the tools chain analysts use to fingerprint what type of wallet you're using. Lightning does not publish the amount info, the routing nodes only get a lower bound on the amount sent; they don't know the full amount because they don't know if a multipath payment was used, and they also don't know the total fee paid because that's encrypted -- each routing node only knows how much you paid *them.*
> most LN payments are routed through a handful of large hubs
...he said, with no evidence
> ~90% of Lightning users don't enjoy almost any of the privacy benefits you lay out because they're using things like Wallet of Satoshi or Strike that see everything
Wallet of Satoshi and Strike don't see everything. Here's two critical details they're in the dark about: (1) they don't know what address the recipient receives the money into (neither the channel nor the htlc), because lightning invoices do not tell you that. (2) They don't know if the person who looks like the recipient is really the recipient or not (it might be a trampoline payment and they have no way to tell). Not even the sender knows that.
> Monero is better UX for privacy and it's by default
Monero has worse privacy under its slick UX and some LN wallets have better UX anyway.

2025-04-30 05:19:15

- reply

Yep! More private than monero for a lot of reasons:
- lightning invoices reveal less information than monero addresses
- in lightning transactions, the sender is encrypted (unlike monero, which uses 15 unencrypted decoys and 1 unencrypted real spender, and just hopes analysts can't eliminate the decoys)
- in lightning, the full amount is encrypted (unlike monero, which leaves the fee in plaintext)
- in lightning, the recipient is encrypted (unlike monero, which typically leaves the recipient's address and a change address in plaintext, though it does randomize their order, which is good)
- none of that data is published on a blockchain (unlike monero, where it is)
Monero does some pretty good things for your privacy and I can only identify the "real" sender of a monero transaction in about 1/5 cases, and only with about 80% confidence. Chain analytics companies can do a lot better because they have off-chain data that helps them eliminate more decoys. But by comparison with lightning, monero is pretty transparent.

2025-04-30 04:47:54

- reply

They created a sidechain model which requires some data about the sidechain to be accessible to users. Their model also involves a federation and I think it is perfectly reasonable to have each of the federation members store a copy of that data, but instead Citrea opted to dump it on bitcoin's blockchain to reduce the chance of it disappearing.

2025-04-30 04:11:10

- reply

Yes, there are two groups of people doing this:
(1) Stamps: https://www.ledger.com/academy/glossary/bitcoin-stamps
(2) Citrea: https://citrea.xyz/clementine_whitepaper.pdf
The Citrea paper is quite dense but I am referring to this sentence in particular: "A total of 144 bytes are committed, split into 3 outputs, one OP RETURN with 80 bytes of data and two taproot outputs with their script pubkey as the 32 byte data, making these outputs unspendable."

2025-04-30 04:07:49

- reply

Yes but this isn't trying to make sure you can spend the money in the future, only that you're not making a fake address that simply encodes 32 bytes of data without actually being spendable -- i.e. it ensures you're not abusing bitcoin outputs in the particular manner Stamps and Citrea do it

2025-04-30 03:42:39

I am not endorsing this idea but I am bringing attention to it because it sounds like a fun way to fight Citrea and Stamps:
Modify bitcoin core to enforce a mempool policy that rejects transactions that put money in addresses without including a proof that each address can be spent from. The proof doesn't go in the blockchain, it's just relayed with the tx to prove its outputs are spendable.
This would require wallets to create the proof when generating an address and share the proof with the sender. It would also require multisig wallets to use some sort of coordination mechanism to produce the proof. But it requires no consensus changes.
User flow: Alice wants to send money to Bob. Alice asks Bob for an address. Bob's wallet not only generates the address, but also signs the message "Proof of Spendable" with his private key and shares the signature with Alice, in the same qr code as his address. Alice's wallet scans the qr code and constructions a tx paying Bob's address, and when it sends the transaction to the mempool, it shares Alice's signature along with it.
Nodes only propagate the transaction through the network after verifying the signature so that they know Alice can actually spend the money in that address, meaning it's not just a data carrier. Stamps and Citrea, RIP.

2025-04-30 01:46:52

history of crypto scams:
2010-2015: random altcoins
2015-2016: ethereum
2017-2019: ICOs
2020-2022: defi
2022-2023: NFTs
2023-2024: inscriptions
2024-2025: fake L2s
2025-now: stablecoins

2025-04-29 23:04:52

Running spark
https://i.ibb.co/9k2HPp64/running-spark.png

2025-04-29 22:17:42

I support stengthening the filters in bitcoin core for the following reasons:
1. It's too easy imo to put arbitrary data on the chain
2. I observe that it has bad effects
3. I want to disincentivize it further
4. Filters seem to make arbitrary data more expensive

2025-04-28 16:02:42

- reply

Lightning would help a lot.
For one thing, the most popular monero wallets (Cake wallet, moneroj) don't send transactions to their peers, instead they connect to a random node from a list of RPC servers and send it in plaintext to them. Lightning wallets, by contrast, (1) encrypt your transactions and (2) only send the encrypted blob to a single node whom you have a channel with. That's way, way better.
For another thing, monero wallets reveal the recipient's address to the sender. They automatically log that information and if the sender is an exchange or other public entity, they can be subpoena'd and begin tracing the payment. Lightning wallets, by contrast, do not reveal the recipient's address to the sender -- not the channel, not the htlc, not anything that actually holds the money. They only get to see a public key that is used strictly for communication, and thanks to trampoline routing, it is quite common for that pubkey to not even belong to the recipient. That's way, way better.
For another thing, monero wallets list all possible senders in every transaction (unencrypted btw) and put that information on a permanent ledger. Lightning doesn't do that. So if a person is being targeted and uses monero to send their money to a centralized exchange, the exchange's address will show up in that transaction and -- if the exchange discloses their addresses to the police, as many do -- the police can subpoena them for information about what transactions sent them money. They can then show them a list where the target's address shows up as a possible sender in each transaction, which is very good evidence that he sent the money. The target can be caught that way, as happened in this finnish case: https://cointelegraph.com/news/finnish-authorities-traced-monero-vastaamo-hack
Since lightning wallets actually encrypt the sender and do not even share the encrypted blob with the recipient, it would help a lot if the guy chose lightning instead. The police would not see a transaction going to the exchange on the blockchain, would not know to contact them and ask them for more info, and even if they did, the exchange would not have any info to link the sender's wallet to any particular account. That's way, way better.

2025-04-28 13:42:39

Eat your heart out, @nprofile…22nz et. al.
LSPs can't tell if the pubkey in a bolt11 is the *real* destination or just another routing node
They *assume* it's usually the real destination but "YMMV" (i.e. they aren't sure)
Bolt11 has better privacy than a monero address
Source: https://x.com/PhoenixWallet/status/1916844583402590504

2025-04-26 15:44:51

- reply

I'm just waiting for a plane

2025-04-26 15:41:56

- reply

Oh wait, better:
deal
dell
fell
fill
file
five
live

2025-04-26 15:40:59

- reply

deal
dell
fell
fill
file
tile
tike
like
live

2025-04-14 22:47:13

- reply

idk

2025-04-14 21:40:50

Cool chart:
https://image.nostr.build/ea53a00fb46e7f1d7b3fd539560f8164362184bc6bc866e9d36d399737ddace6.jpg
h/t x.com/TristanBietsch

2025-04-09 02:59:00

- reply

sounds dope! Who needs to emulate covenants when you have them natively?

2025-04-09 02:34:39

The first bitvm hackathon is on the way! I'm thinking about porting my Bitcoin Lottery Contract to use bitvm: https://github.com/supertestnet/bitcoin-lottery-contract
I wouldn't use a bitvm federation though. (Say No to extra trust assumptions!) I would have users do the computation themselves. L2 coinflips!
https://bitvmx.org/force/

2025-04-05 21:42:56

I think most people who own boats are republicans

2025-04-03 17:23:27

I want spend and replace to be much easier. For me, spending sats, even over LN, takes longer than a card and fails more often. And replacing it takes hours for me. Cards are so much easier than spend-and-replace right now.

2025-04-01 21:10:07

- reply

Emessbee demos how to use nostr to coordinate a coinjoin without a coordinator:
https://github.com/supertestnet/coinjoin-workshop

2025-04-01 20:13:43

- reply

Awesome! I think I can create a tool for adding "edge names" -- names given by a friend to a friend-of-a-friend. Then we'll have a full petname system on nostr:
- A petname is the name you manually give to someone
- A proposed name is one given in a profile -- clients can display them with an indicator that they might be an imposter (unless/until you confirm them)
- An edge name is supplied for someone you haven't picked a petname for yet, by checking if any of the people you follow have given that person a petname
Can this system prove better than DNS? I dunno but I'd like to find out!

2025-03-31 07:23:04

- reply

I'm interested in pubky and I consider myself a nostr person
I think some of the ideas you guys have implemented are great and the rest are reasonable
I hope nostr becomes more like pubky in respect to the pubky ideas that I think are better and I hope pubky continues to improve
May the best protocol win

2025-03-30 14:39:51

- reply

are you sure indexers serve posts? I got the impression they only help you find homeservers faster, because looking them up on a DHT is slow

2025-03-30 13:31:47

- reply

I didn't know any clients implemented WoT or pagerank
I also doubt these are sufficient
If the members of BTS were on nostr, I suspect they would see over a million DMs every day when they log in, even with WoT and pagerank
And I doubt they would want to stick around in that kind of environment

2025-03-29 22:47:47

What if nostr sucks because (1) there are no tools for suppressing bots and therefore (2) real celebrities (the ones with millions of followers) don't want to post here and therefore (3) normies (i.e. the millions of people who follow celebrities) don't want to post here either (because their favorite people aren't here)

2025-03-29 02:52:47

- reply

I partly agree, but I do think DHTs are neat, and I'm glad someone's using them for something equivalent to "relay discovery." I'd kind of like to build out something similar to that for nostr.
I don't like that messages are not signed, that seems like a recipe for disaster, but I think it's important to John because if you have to sign every message, then you need to keep a key in a "hot wallet" or face the annoyance of breaking out your "cold wallet" whenever you want to post something. And I think John regards *that* as a recipe for disaster.
Anyway, I'm glad there are options!

2025-03-29 02:43:08

Here are my initial thoughts on the new Pubky social media protocol, which seems designed to compete with nostr:
#naddr1qv…sgrj

2025-03-28 00:43:28

- reply

Will you consider adding support for "linkable" ring signatures? They are required for my Emessbee protocol, and it would be a cool hackathon project to port Emessbee so that its ring signatures work on bitcoin's elliptic curve instead of Ed25519

2025-03-25 20:49:04

Today I released an essay re: the history of US federal loans and foreign aid from 1712 to 1917. It inpsired by a similar essay concerning times when the US *borrowed* money. I was unaware of a record of its *loans and grants,* so I made one.
https://telegra.ph/History-of-US-Federal-Loans-and-Foreign-Aid-03-25

2025-03-19 23:13:23

You've heard of chainalysis
Now I bring you "off-chain-alysis"
Matthew Yuk and I played "Ark ping pong" by sending each other a few payments on Ark. First I sent him 50k sats, then he sent me three payments worth 4500, 10k, and 100k. Then he said, "I annotated my transactions back to you so we can look at the vtxos being spent and observe the coin selection."
Here is his analysis:
https://image.nostr.build/a96c6073bc680a65c5bb31593e11cf7da41fb85555591cd2499739cdc5dc3a67.jpg

2025-03-19 22:50:48

- reply

today I've been testing the version of Ark by Second:
https://docs.second.tech/
it seems to have more testing infrastructure built out than the version of Ark by Ark Labs (https://arklabs.to/)
I think both versions run on Inquisition signet
Last I heard, Buraq is working on Brollup, which is a variant of Ark designed for defi, with native support for issuing altcoins on it (yuck!)

2025-03-19 22:29:19

- reply

I suspect it will be easy to do if:
- you don't do rounds frequently (rounds cost money, which means it's harder/costlier to run Ark if you do rounds frequently, and unless you're very generous you have to pass on those costs to your users as fees, which makes it annoying to use)
- your friends and family trust you to prevent doublespends (if they *don't* trust you, they have to settle each payment before considering it "received," and settling costs the operator money, which, again, means more fees for users)
Ark's big tradeoff seems to be this: costs rise if you do rounds often, and if you don't do rounds often, it has the same trust assumptions as a statechain -- i.e. the operator can doublespend payments

2025-03-19 22:09:21

ark is awesome
you can just send money
Someone else running ark posted a screenshot of their ark wallet, so I grabbed their pubkey and sent them some sats
https://x.com/matthewvuk2/status/1902450286989373568
then I gave him *my* pubkey so he can return the favor at his leisure
https://x.com/SuperTestnet/status/1902482044371820703
and it's asynchronous!

2025-03-19 03:53:15

https://image.nostr.build/0872f2f029ad4f8af2b7b838941ea164bb86abd3aab8106ab89132ba1ff08ae3.jpg

2025-03-18 19:01:31

- reply

I have a proposal for using my coinpool software to create permissionless liquidity pools for prediction markets:
https://gist.github.com/supertestnet/d4d9a8dc4c975dc36eec0a8816d1f99f
But I haven't done an implementation yet because I am still improving my coinpool software

2025-03-15 18:43:21

- reply

I hope you are doing well too!

2025-03-11 21:06:28

https://image.nostr.build/46d4e3debf270790679cfcf239c67c9f1fd5b99d7ed8005d865de76b6b7dd86a.png

2025-03-09 05:12:36

- reply

thank you but I hasten to remind you, while my ideas are interesting, most of them aren't practical, which is why no one uses them

2025-03-01 18:10:51

My coding philosophy is inspired by Wayne Gretzky
"You pass 100% of the tests you never write"
h/t @npub19z2…fkd4

2025-03-01 04:16:22

- reply

This risking your bitcoin with a third party to acquire fiat
It's not even p2p, due to the third party
Burn it to the ground

2025-02-27 22:53:14

Social credit scores are already here. A low credit score affects all of this:
- Employers might not hire you
- Landlords might not rent to you
- Utilities corps might not serve you
- Insurance corps might charge you more
- Judges in child support cases might charge you less
People worry it might come over from China. But it's already here for years now. They probably got the idea from us.

2025-02-27 14:13:45

Apparently my NWC tester is the most useful thing available if you want to add NWC to your client:
#nevent1q…j6xf

2025-02-25 18:54:43

- reply

how?

2025-02-25 18:38:08

The 2025 Bitcoin Report by River Exchange is released!
Here are some of my observations:
(1) The tx-per-second count fell. In their PREVIOUS report (2023) they estimated 6.6 million lightning transactions per month. They now estimate 2.42 million LN transactions per month. That's a drop of over 63%.
(2) Volume rose. Their previous report estimated 78.2M USD in monthly transaction volume. They now estimate 286.5M USD in monthly transaction volume. That's a rise of over 72%. They guess this is due to use of LN on exchanges, over 50% of which now support LN; users tend to deposit/withdraw larger amounts to exchanges.
(3) Looks like LN has something similar to a pareto distribution. 80% of volume is done by 14 nodes: "Our November 2024 dataset was made possible by 14 data providers, representing 79.4% of Lightning Network capacity."
But I question what they mean by "Lightning Network capacity." Usually this means "announced capacity," but Acinq and Blockstream are probably among their data providers, and they know about a lot of unannounced channels. I have asked them on twitter for clarification and I hope they reply soon.

2025-02-25 00:08:03

- reply

sounds like a fun thing to test for a hackathon project

2025-02-24 18:47:07

- reply

how? what info lets you group them?

2025-02-24 14:34:25

- reply

> It the service knows who you are
Good clarifying words
I was particularly thinking of robosats, which is a service that (1) doesn't know who I am (2) they recommend (and facilitate through their UI) creating a new account for every transaction
On a service like that, I think it is also wise to create a new bolt12 for every transaction (and thus every account), because otherwise they can correlate two different payments and build a profile on you that way

2025-02-24 13:33:45

- reply

Agreed, the problem is Phoenix's implementation, not the bolt12 spec

2025-02-24 13:11:16

- reply

yes, but phoenix wallet makes that hard. To make a new bolt12 in phoenix wallet, you must create a new wallet and pay for more inbound capacity. This disincentive encourages payment string reuse and is bad.

2025-02-24 13:03:04

- reply

I also cross-posted your correction on twitter so that it gets more visibility:
https://x.com/super_testnet/status/1894009493068906633

2025-02-24 12:55:35

- reply

I appreciate the correction you offer in the post I reply to below, and I think this is a good recommendation: for good privacy, don't reuse a bolt12 or any other payment string across multiple services. Instead, make a new payment string for each service you use.
#nevent1q…0d0g

2025-02-24 12:55:29

- reply

2025-02-24 12:53:22

- reply

Nuance all you want, the same applies: you should make a new payment string for every service
wallets like phoenix encourage bolt12 reuse across different services (by only letting you have one bolt12) and this is bad for privacy

2025-02-24 12:51:35

- reply

It's good to hear that ldk gives you a new bolt12 every time, I think that's what all wallets should do
> it’s not “because you reuse the same public key”, it’s because it’s the same thing!
True, I agree, the problem is reusing the same payment string across multiple accounts, regardless of whether that payment string unwraps to a bolt12 or an lnurl or anything else
For every new account at any service, you should make a new payment string

2025-02-24 12:13:15

- reply

bolt12 specifies, for Offers, a TLV of type: 22, value: 32 byte offer_issuer_id (i.e. a pubkey)
https://github.com/lightning/bolts/blob/master/12-offer-encoding.md

2025-02-24 08:13:31

Did you know bolt12 only lets you have a static qr code if you reuse the same pubkey again and again? This is bad for your privacy and allows companies like Chainalysis to offer a transaction monitoring tool for lightning. Bolt12 considered harmful.

2025-02-24 00:34:19

- reply

> its not the sender thats the problem...its the routing node
...who *also* doesn't see where the money ends up

2025-02-23 22:35:45

- reply

even if you're NOT using them, you still get better privacy than monero offers
because *even without them,* the recipient's address is still encrypted so that the sender can't see it

2025-02-23 16:35:53

- reply

Lightning invoices have better privacy than monero even when blinded paths are turned off
Because the recipient's address is still encrypted so that the sender can't see it

2025-02-23 15:39:58

Lightning: encrypts the sender via ChaCha20
Outcome: any LN wallet could have made that tx
Full Chain Membership Proofs on XMR: obscures the sender with a zero knowledge proof
Outcome: any XMR wallet could have made that tx
One big difference: lightning's method works right now

2025-02-21 04:02:09

- reply

I haven't muted you
I receive zaps to coinos because my node isn't always online, and coinos is

2025-02-19 12:55:22

- reply

> The trade offs are better privacy versus guaranteed supply
This isn't a necessary tradeoff anymore. Lightning offers better privacy than you can get on monero but still has an auditable supply.
Lightning transactions actually encrypt the sender, recipient, and full amount paid via its adaptation of the onion messaging protocol, the same tech that makes tor work.
Monero transactions do not encrypt the sender but merely obscure them in a set of 16 "candidates." They also don't encrypt the recipient but use "stealth addresses" that are subject to a similar "shared input heuristic" as chain analysts use to trace the bitcoin blockchain. And while monero transactions do encrypt the amount paid, they do not encrypt the "full" amount -- they leave the mining fee unencrypted. That might not sound like a big deal, but watch this chainalysis video about how they trace monero:
https://v.nostr.build/D4Nzp22vRF35IRnz.mp4
They make it clear that the fee paid reveals "fingerprinting" information about the type of wallet used, including whether the sender was a normal user, an exchange, or a miner.
If you want decent privacy, you're better off using bitcoin on lightning than you are with monero.

2025-02-18 00:16:59

- reply

I think nostr sucks and is unfit for use in production systems
That said, it is fun to build on, and it is useful for demos and hackathons because working on nostr is similar to working on a p2p system, but easier. So you can prototype on nostr and then move on to a "real" p2p system afterwards. Which is useful.
I created a Nostr Dev Course which you can check out here: https://www.udemy.com/course/nostrdevs/
My videos from it are also available for free on my webpage: supertestnet.org

2025-02-15 09:29:07

https://i.ibb.co/Ps98JT8T/htlcs-and-preimages-meme-smaller.gif

2025-02-13 22:46:35

- reply

Yes. The design I opted for instead ejects trolls from the signing ceremony if they fail to send in all requisite signatures, or send invalid signatures. Everyone else just restarts the signing ceremony without the trolls, but this time their admission fee is already paid, because they paid it the first time, so there's no need to pay again.
This model disincentivizes trolls; it costs them money to join the ceremony but refuse to sign (or give an invalid signature), but no one else is effected except that they restart the ceremony. In my tests with 11 people, the ceremony takes about 30 seconds, and if 1 user was a troll, it takes an additional amount of time that is slightly less than the original amount, due to having one less person. (So something like 30 seconds for the first try + 25 seconds for the second try.)
Another factor about anonymous coordinators: my hope is that users who have Umbrel nodes or similar will also run my coinpool software and thus onboard their friends and family to bitcoin. This is, in my opinion, safer than doing so via LNBits or LNDhub because those solutions are custodial, and if your Umbrel gets fried while your friends and family have their money on it, they can lose that money.
My coinpool software, by contrast, is self-custodial, so if your Umbrel gets fried, all it means is your users have to use their unilateral exit transactions to get out of the pool. That seems safer to me and thus more likely to appeal to the types of hardcore bitcoiners who purchase Umbrels and similar node boxes.

2025-02-13 15:49:58

- reply

Good point

2025-02-13 15:38:08

- reply

I oppose permanent subsidy
Does that make me trustworthy?

2025-02-13 14:57:08

- reply

> Fascinating blend of Hedgehog and CTV!
Thank you! I also think it is important to note that it works pretty well *without* CTV too.
> How does the 100 user limit per pool impact scalability?
My hope is that more and more people join pools as time goes by. I've designed pools to interoperate in two ways which I describe here: #nevent1q…ccju
> And could this work alongside existing solutions like Liquid Network, or is it a standalone ecosystem?
My model is fully lightning compatible so all users can interoperate with any network that is also lightning compatible. That includes Liquid, e.g. via boltz swaps.

2025-02-13 06:08:45

- reply

lol! I hope not

2025-02-13 06:07:24

- reply

The way I've designed my model, two things can happen if you try to send money to someone in a different coinpool:
(1) if the other person's pool uses the same coordinator as yours, then it will still work fine, you won't even notice a difference -- the coordinator will just forward your hedgehog payment between the two pools and it costs him nothing to do so, so it's just as fast/free as if you sent to someone in the same pool as you
(2) if the other person's pool does *not* use the same coordinator as yours, then the coordinator cannot forward your hedgehog payment "directly," but he can do so "indirectly:" he can ask the recipient to provide a lightning invoice locked to the same payment hash as the hedgehog payment, then pay the lightning invoice, then use the preimage to settle the pending hedgehog payment.
However, the number 2 has a downside: because it went over the lightning network, there are routing fees involved and the payment can get stuck, which means the routing node's money can get stuck. So he will probably have to charge a fee to the sender to cover those downsides, which overall means payments between pools involving different coordinators will not be as fast or as cheap as payments *within* a pool. But they'll still be asynchronous, and they'll be as fast/cheap as lightning, which is nice because lightning is already (usually) pretty fast and pretty cheap.

2025-02-13 04:52:35

My latest essay is "How coinpools improve bitcoin"
It also covers how CTV improves the coinpools that are possible todayMy latest essay is "How coinpools improve bitcoin"
It also covers how CTV improves the coinpools that are possible today
https://njump.me/naddr1qvzqqqr4gupzqgvra9r4sjqapufyl0vnc4kv4fz70e29em4c655y37vz206f0wt4qq2kxm2gwajrxe3n2fshwn6lvs6xgmnvxykh5g60zzr

2025-02-13 04:32:11

- reply

A lot of my recent work focuses on non-interactive coinpools. I figured out a way to do them on bitcoin if we had CTV + CSFS, and then, with a bit more thought, I figured out that my model didn't actually require those things, so I am now working on an implementation. But my model does benefit a lot from CTV (less sure about CSFS at this point) so let me outline how non-interactive coinpools fix the above problems and along the way I will share how CTV specifically improves coinpools.
Coinpools improve the problem of "mining fees are sometimes high" by letting you bypass them in more cases. If you're in a coinpool and pay someone else in the same coinpool, your payment does not show up on the base layer, it just involves modifying some unilateral withdrawal transactions such that the sender can withdraw less and the recipient can withdraw more. The transactions are off-chain, like LN transactions, so you can do that without paying a base layer fee.
Coinpools improve the problem of "confirmations usually take several minutes" in a similar manner. Payments *inside* a coinpool (i.e. to another pool user) merely involve modifying off-chain data (and revoking an old state), so they can be as fast as lightning. In most cases I expect them to be a bit faster because there's less need for pathfinding or negotiating with a variety of routing nodes. If the sender and the recipient are in the same pool, they only need to talk to each other and, in my model, a coordinator.
Coinpools improve the problem of "using it privately requires running a coinjoin server" in two ways: first, if you're in a coinpool and you send money to a bitcoin address, the blockchain doesn't know which coinpool user sent that payment. They might be able to trace the payment to the coinpool, but from the blockchain's perspective, that's just multisig; the actual person *inside* the multisig who sent the money is not revealed. However, my model uses a coordinator, and the coordinator probably knows which user sent the payment. Still, only 1 person knowing is better than having everyone on the blockchain know.
Second, if you send money to someone *inside* the coinpool, in my model, the only people who know about your payment are the sender, the recipient, and the coordinator, and the recipient does not know who the sender is. Moreover, my model allows users to act as bridges from LN to other pool users, so even the coordinator doesn't know if the person who *looks* like the sender was the *real* sender or just a bridge node, with the *real* sender being someone on lightning.
Coinpools improve the problem of "setup fees are sometimes high" by having multiple users share the setup cost. My model allows a single bitcoin transaction to fund a coinpool with a number of members between 1 and probably about 100. (The max I've actually successfully tested is 11.) If the users share the cost of that transaction, then even in a high fee scenario, where bitcoin transactions cost $50, each user only has to pay a fraction of that, where the fraction is determined by how many users are joining the pool. If 10 people are joining, each user would pay $5 instead of $50. If 50 people are joining, each user would pay $1. If 100 people are joining, each user would pay 50¢.
The setup is also where CTV greatly improves my model. For my model to work, the users have to coordinate to create the pool in something I call a "signing ceremony," which is very similar to a coinjoin. The signing ceremony has to be scheduled and each user has to show up for it or they won't get into the pool. With CTV, you could fix this: instead of a signing ceremony, an exchange could autosend your money into a coinpool on e.g. a monthly basis and email you the data you need to perform your unilateral exit. All they need from you is a pubkey, and they can do everything else.
Coinpools improve the problem of "payments frequently fail" by reducing the need for pathfinding, which is a typical cause of failure on lightning. If you are paying someone in the same pool as you, you always know an exact path: it will be you -> coordinator -> recipient. These short paths also reduce the likelihood of routing nodes having insufficient capacity to forward the payment. You've only got one "routing node" to worry about -- the coordinator.
Coinpools *in general* don't improve the problem of "payments aren't asynchronous" but my model in particular *does* improve that problem because I am combining it with my hedgehog protocol from last year, which *does* allow for asynchronous lightning-like payments. Relatedly, my coinpool model technically has a network model, it's just a hub-and-spoke network: the coordinator is connected to every user of the pool and can forward asynchronous hedgehog payments to them. This means you can send money to someone when they are offline; they'll get it whenever they *do* get online, even if *you* went offline in the meantime.
Coinpools improve the problem of "stuck" lightning payments by reducing the number of hops along the route. As above, a payment inside the pool (per my model) is always just sender -> coordinator -> recipient. Due to only having 1 hop, there are fewer opportunities for a node to have a network issue and cause a delay.
Coinpools have multiple ways of improving the problem of manual channel management. In particular, not all coinpool models *have* channels, so channel management is not always needed in a coinpool. My model, however, does have channels, so channel management is still a thing.
Nonetheless, my model improves channel management in two ways: first, the setup costs are lower for the reasons given above. Second, payment asynchronicity helps for the following reason:
The worst pain point in channel management *today* occurs when someone sends you a payment but it fails because you didn't have enough inbound capacity. That doesn't happen in my coinpool model because payments are asynchronous. If you don't have enough inbound capacity, the payment doesn't fail, it just remains pending. So all you have to do is open a new channel (i.e. enter a new pool) and *then* finalize the payment.
I hope this essay clarifies why coinpools improve the problems I outlined and why CTV improves coinpools. I also hope this gets you a bit excited for my latest coinpool invention, which I hope to release soon :D (It really is very close to demo-ready.)

2025-02-13 02:39:52

- reply

I agree with this post

2025-02-13 02:39:40

- reply

UX problems with base layer payments include:
- Mining fees are sometimes high
- Confirmations usually take several minutes
- Using it privately requires running a coinjoin server
UX problems with lightning payments include:
- Setup fees are sometimes high
- Payments frequently fail
- Payments aren't asynchronous (the recipient has to stand there with their device open waiting to do a revoke_and_ack on their old state -- unless they use a custodian)
- Payments that *do* succeed occasionally take more than 30 seconds (due to stuck payments, automatic retries, and no ability to say "stop retrying" in any existing wallets that I'm aware of)
- Using it privately requires manual channel management

2025-02-13 02:32:11

- reply

I don't believe nodes have to use the "memo" field for this. Note the phrase "description hash" in this sentence: "the server should fetch a description hash invoice where the description is this zap request note and this note only"
The purpose of the description hash field is so that you can have a description larger than what fits in the memo field. Instead of putting the full description in the memo, you just hash it and put the hash in the description hash field; then you can give the full description separately to your user.
Now, given that you tested this, it's probable that you found an *implementation* bug -- specifically, you found a zap implementation that assumes the description will fit in the memo field of a lightning invoice, which might *usually* work but -- as you found -- not always. The implementation should be updated to *check* if the description will fit in the memo field. If not, it should only put a snippet in there (or nothing at all) and instead use the *description hash* field.

2025-02-13 02:27:51

- reply

"Doing nothing" doesn't sound very safe
Using bitcoin sucks right now imo