Super Testnet

Open source dev w/ bitcoin focus | supertestnet.org

bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

NIP-57 Address

supertestnet@coinos.io

Profile Code

nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpp4mhxue69uhkummn9ekx7mqppamhxue69uhkummnw3ezumt0d5n272hn

Publishing to

nos.lol

nostr.mom

nostr.oxtr.dev

Author Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

Show more details

Last Notes

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-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: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-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-24 13:33:45

- reply

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

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:29

- 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: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 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 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-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-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: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: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

2025-02-13 00:51:06

CTV is not just the most secure soft fork proposal
It's probably the most secure thing *conceivable* among all possible actions/ideas
Anyway *something* is the most secure idea possible, what if it *is* CTV?
https://upload.wikimedia.org/wikipedia/commons/7/73/Dodecahedron.gif

2025-02-11 18:50:16

- reply

more bitcoins

2025-02-11 18:49:49

- reply

No because it's not bitcoin-only. You use that lending platform to borrow altcoins by putting up bitcoins as collateral. I want a lending platform where you borrow *bitcoins* by putting up bitcoins as collateral.

2025-02-07 16:28:03

Monero people will tell you monero is untraceable but you can watch a video of chainalysis tracing it transaction by transaction. Here is the video: https://v.nostr.build/D4Nzp22vRF35IRnz.mp4
Here are the timestamps:
26:55 - Morphtoken to the perp
30:43 - Perp to ChangeNow or Liquid Exchange
32:49 - Perp to Exodus Wallet
35:08 - Perp to Exodus Wallet or mining pool
36:51 - Perp to Centralized Exchange or Merchant POS, this is how they nabbed him

2025-02-07 15:12:55

This is a pretty cool report:
https://breez.technology/report
But I was hoping for updated transaction estimates. In 2023 River estimated a lower bound of about 6.6 million LN transactions per month:
https://river.com/learn/files/river-lightning-report-2023.pdf
Is there a new/better estimate? Anyone?

2025-02-04 16:37:50

- reply

Yeah, it's sad. But it's hard to blame them. Using bitcoin sucks. Lots of work to do!

2025-02-02 15:22:14

- reply

> Essentially you're saying it has the potential to be very private, but what does that matter when it comes to how vast majority are using it?
It matters imo because people who seek really good privacy ought to have the motivation to take a few extra steps
> It's similar to why PGP failed to get broader adoption. UX means only you and and a handful of people are using Lightning that way.
So? Anyone can still do it if they want to.
> I showed you a chart of tech advancements since inception of Bitcoin. Bitcoin blocksize hasnt even kept up conservatively.
Good. Relatedly, here's a chart of Moore's law: https://gist.github.com/supertestnet/2d41e7533e51cebf9f557587d349aa60
It seems it stopped applying sometime between 2003 and 2013. I'm glad bitcoin didn't go with the wishful thinking option.
> Seems all for nothing at the expense of usability: ~60,000 node runners. ~50-100 million Bitcoin users. Apparently vast majority of Bitcoiners won't ever run a node even if they can.
The ones not running a node are probably ignorant or don't sufficiently care about self sovereignty -- *yet.* But still, if you aren't running a node, you aren't self-sovereign, because the people who run the nodes set the rules.
> Also Bitcoin is relying on this "wishful thinking" too to some degree since Lightning doesn't even scale globally without 100MB+ blocksize.
It does: https://x.com/peterktodd/status/1813928457946153056
>"that incentivizes them to place *their own* limit on the size of their own blocks"
Not sure I understand what you're saying. Why would they do this? Penalty of increasing blocksize decreases with more use. Those doing that would just be leaving money on the table.
Because the larger the blocks, the harder/longer they take to validate, therefore a miner can undercut his competitors by mining a smaller block that gets propagated/validated before the big blocks do. A bird in the hand is worth two in the bush.
>"You're not sovereign if you're not running a node"
So you're conceding 95%+ of Bitcoin/Lightning is not sovereign?
I doubt it's 95% but yes, if you're not running a node you aren't self sovereign and most LN users do not run a node. That is no reason not to do so yourself. You're not a lemming. You don't have to be like anyone else.
> I think it's safe to say there are way more Monero node runners as a percentage of users than Bitcoin. Bitcoin has far more users, but the difference in total nodes is only a factor of 2x-6x vs Monero depending how you count them.
Yeah, probably. But we'll see if that continues to be the case if monero ever becomes popular. I doubt it because of the choice to allow dynamic block sizes.
> Ok, but doesn't that mean Bitcoin will be in an even worse state?
I don't think so. "Actually 0" seems better than "trending toward zero." It guarantees you never overpay miners and thus unjustly rob users.

2025-02-02 13:45:44

- reply

> Only a select few can arguably claim they have better privacy on Lightning. Vanishingly few Lightning users are transacting privately and non-custodially.
I do not understand this argument. To me it completely misses the point: I argue that self-custodial lightning has better privacy than custodial lightning and your response is "yeah but most people prefer custodial lightning." So? Who cares if most people prefer something inferior? Why does that matter? *You* (or anyone who wants good privacy) can choose the *better* solution. You are not subject to the choices of others.
> Correct me if I'm wrong but your whole forecast seems to rest heavily on technological advancement remaining stagnant over time. Historically we see the exact opposite.
I don't think my argument relies on that assumption. Making blocks dynamic in size with the hope that someday technology will solve all the problems it brings <-- that seems like wishful thinking. Limiting their size to a small value seems like a far better idea: it pushes adoption of layered scaling while also penalizing spam attacks.
> Dynamic block size means fees will always stay low even with increased adoption
I think monero is pitched between the horns of a dilemma: if blocks get big and fees stay low then it means miners do not have to worry about orphan rates, which means mining is centralized. If blocks get big and mining is *not* centralized the miners *do* have to worry about orphan rates, and that incentivizes them to place *their own* limit on the size of their own blocks so that propagation and validation is faster and the orphan rate is smaller. If that miner-selected limit ever applies, you get the worst of both worlds: rising fees *and* large blocks.
> meaning more sovereign usage and better operability with L2s
You're not sovereign if you're not running a node
> Tail emission means we don't have to roll the dice on tx fees securing our blockchain in the future
You do: monero uses permanent inflation mixed with a fixed issuance of 0.6 XMR or less. Permanent inflation means the XMR issued is designed to constantly deflate in value. So at some point 0.6 XMR will have no material value. It will be worth less than 60 cents of today's money. Consequently, miners will need another source of revenue. You're rolling the dice that one will exist.

2025-02-01 20:05:49

- reply

there's a nice little button to switch it to whichever direction you prefer
I prefer LTR (left to right) so that's how I set it

2025-02-01 20:01:42

We did it! The mempool cleared!
https://i.ibb.co/ZzP2RNbp/we-did-it.png

2025-01-31 22:27:53

Current state of my coinpool software based on hedgehog -- which now supports asynchronous payments *even when* routed over a network!
https://i.ibb.co/mVjvymSg/hedgehog-factory-demo-4.gif

2025-01-31 20:33:55

- reply

I agree with this sentence and I hope you think I honestly discuss the drawbacks of my positions
If not, I hope to remedy that through future (or present) discussions

2025-01-27 16:04:32

- reply

I want to congratulate @nprofile…fy07 for finding an LN transaction and posting it
Let's see info he learned:
- sender? Himself -- assuming he sent from a self-custodial wallet, he even knows the address or channel of the sender, wow!
- recipient? He knows the recipient's communication pubkey, node, and node name -- though not learn the address or channel that received the money
- Amount? 69 sats
- Fee? less than 1 sat
That's a lot of info! More than I'd get from analyzing a monero transaction.
Reading this back, it sounds sarcastic; it's not, I am being genuine: this really is more info than I'd get from analyzing a monero transaction, and it motivates me to work on making LN better. Thanks Kevin!

2025-01-27 02:37:02

- reply

I'm sure that's why its github explicitly says, "Monero isn't made to integrate with Tor" source: https://github.com/monero-project/monero

2025-01-26 22:01:20

- reply

your "explanation" was basically "well bisq isn't very big yet so they aren't at risk"
which is, at least in my opinion, a very silly thing to say
you have to start using good privacy when you're small so that it protects you when you grow big
hence tor + LN

2025-01-26 21:25:27

- reply

That stealth address technology really is a wonderful piece of privacy tech and I cannot use it to find any of the xmr transactions you've made in the last month
You win your challenge, now win mine!

2025-01-26 21:17:56

- reply

Nice try but those are zap receipts, not LN transactions:
https://i.ibb.co/2qVbv77/zap-receipts.png

2025-01-26 21:04:34

Day 3 of asking monero people to just *show me* an LN transaction so I can see what info they can glean from it
Can you see what channel or address *sent* the money? Can you see what channel or address *received* it? Can you see the *amount sent*? Can you see the *fee paid*?
So far they can't even *show me* a transaction on LN -- let alone any information from it
Calling @nprofile…knr3 and @nprofile…u2wh -- maybe yall can help?

2025-01-26 20:19:21

Interesting comparison from the githubs for monero and LND:
"Monero isn't made to integrate with Tor"
"lnd currently has complete support for using Lightning over Tor"
https://i.ibb.co/Yd474n6/xmr-doesnt-use-tor.png
https://i.ibb.co/Jdg7KrS/ln-uses-tor.png

2025-01-26 15:01:28

https://i.ibb.co/SV6xVzv/Bitcoin-Internet-LN-Tor.png

2025-01-26 06:10:53

- reply

Yes, I am doing a workshop called "Build Your Own Coinpool, No Forks Required"
It is essentially a how-to for this software. I plan to do a demo that showcases *something like* what I envision as an ideal user experience (or at least plant a seed -- I'm terrible at UX), and then -- God willing -- we will build the core functionality from scratch.
My hope is that people who work on LN wallets will send their devs to learn how to do this so they can integrate something similar for their users.

2025-01-26 06:06:36

- reply

Paxful's ceo went to prison precisely because the feds treat p2p exchanges as unlicensed money transmitters and money launderers, which are also charges they bring against operators of drug-dealing DNMs like Alphabay:
https://www.justice.gov/usao-edca/pr/paxful-inc-co-founder-pleads-guilty-conspiracy-fail-maintain-effective-anti-money
Robosats and Bisq operate on tor so as to not get caught and go to prison, and LN helps with that, because it's tor for money

2025-01-26 05:03:05

- reply

I didn't link a clearnet site, you did
and instead of quibbling over the definition of DNM, why don't you address the point? Bisq & robosats face the exact same risks as other DNMs but lightning protects them from getting caught
Why do they rely on LN if its privacy is as bad as you claim?

2025-01-26 05:00:18

- reply

#nevent1q…ymsg

2025-01-26 04:59:52

- reply

it's very silly to say the term "darknet market" means something other than "a market on the darknet" just so you can ignore robosats & bisq, who face the exact same risks as other DNMs but rely on LN's privacy to avoid getting caught
it's also silly for you to ignore this DNM: http://ikduzlpwcc4khvj27rlywgic6eaxj5w3brj4uo54z2sfyj7b2hfrepyd.onion

2025-01-26 02:25:20

- reply

No, my node is off pretty much all the time, I just turn it on when I need to make a payment
Though in order not to have to trust my counterparty, I do have to "check in" (i.e. open the wallet) once every two weeks or trust a watchtower

2025-01-26 00:39:52

- reply

List of exchanges that implemented lightning:
https://github.com/theDavidCoen/LightningExchanges

2025-01-26 00:37:13

- reply

>I don't understand this and need someone to explain it like I'm 10
I will explain it to you like you're an adult: it's similar to how onion messaging works. You send an encrypted message to party K, who finds inside an encrypted message for party L. He sends it to party M, who finds an encrypted message inside for party N. And so on. No party knows who the sender is except the sender themselves.
>Starting address and amount ->hops to node still same transaction nothing is hidden
Lots of stuff is hidden: the routing node does not know who the sender or recipient is, nor if the amount is the full amount, a partial amount, or a decoy (aka a payment probe).
-> next node same transaction two nodes now hiding start point
It's not just that "two nodes" are hiding the starting point; the first routing node does not know if the previous person is the sender or just another routing node. So from his perspective there might be *any number* of nodes hiding the starting point. What hides the starting point is that you can't tell a starting point from another routing node.
> To me even though the node hops and the start point maybe hidden the BTC is still able to be traced back to the original address that started the transaction right?
No. Just like with onion messaging, routing nodes can ask one another if they routed the payment, and maybe some will collude and reply "yes, I helped route the payment." But even if all routing nodes collude, they can only ask the sender "Did you help route the payment?" and if he does not reply, they don't know if he was the sender or just a routing node who refuses to collude.

2025-01-26 00:26:45

- reply

Monero has less privacy by default than lightning
By default, in monero, the sender is unencrypted, the recipient is unencrypted, the amount is only partially encrypted, the transaction is published for all to see, and p2p traffic is not encrypted.
By default, on lightning, everything is fully encrypted (sender, recipient, amount, and p2p traffic) and the transaction is never published.

2025-01-26 00:22:31

- reply

It works like onion messages. Before bolt12, by default, you send someone money by creating a path to their node: Alice pays Bob to pay Carol to pay Dave to pay Edna to pay Filbert. Filbert's invoice tells Alice how to construct a path to his node, and consequently Alice can find Filbert's node on the network, and construct a path to him.
With bolt12, the default way to send money is by creating a paty to a "rendezvous" node: Alice pays Bob to pay Carol to pay Dave...but she doesn't know anything beyond that. Filbert's node is talking to Dave waiting for him to say "I've got a message for you, but I don't know who it's from." (But it's from Alice.) Filbert's node then decrypts/reads the message and tells Dave "you should have a payment from someone that is meant to come to me. Let's finish the route." And then they finish the route together (Dave -> Edna -> Filbert) and settle the payment.
By this method, Alice never learns where Filbert's node is on the network and does not know where she sent the money. Also, lightning payments are atomic, so this is all done without ever letting any routing node (Bob, Carol, Dave, or Edna) ever have custody of the funds. Each routing node can either forward the payment or cancel the payment, but not keep the payment for themselves.

2025-01-25 22:54:07

- reply

Monero's weaknesses are why it is compromised:
- timing attacks
- merge analysis
- recency bias
- unencrypted recipients
- unencrypted senders
- amounts only partially encrypted
- all transactions permanent & public
- senders know where they sent their money to
LN is just so much better

2025-01-25 22:33:56

- reply

Kanzan and his friends right now:
https://i.ibb.co/xzjKw4G/deny-til-we-die-meme.gif

2025-01-25 22:14:22

- reply

Context:
Finnish feds trace xmr: https://cointelegraph.com/news/finnish-authorities-traced-monero-vastaamo-hack
Japanese feds too: https://cointelegraph.com/news/monero-transactions-japanese-authorities-arrest-18-scammers
Ciphertrace explains how they trace monero: https://v.nostr.build/D4Nzp22vRF35IRnz.mp4
Popular monero wallets accidentally doxing users & their monero txs to chainalysis: https://digilol.net/blog/chainanalysis

2025-01-25 22:09:12

https://i.ibb.co/zPcqvb6/monero-getting-traced.gif

2025-01-25 15:25:30

- reply

https://image.nostr.build/970ea231fbc51c88b75b4b994c7fa93edba40cf0825c0952bcd618964d6992a1.png

2025-01-25 15:23:54

- reply

I'm a huge fan of the FCMP idea and I look forward to seeing them implemented
It will make the fight much more fair

2025-01-25 04:37:26

- reply

Of course, if the guy had used lightning instead of monero, the Finnish technique wouldn't have worked. The swap service wouldn't know what address received the money (because lightning hides the recipient's address from the sender) and binance would not know what address sent it to their exchange (because lightning hides the sender's address from the recipient)

2025-01-25 04:26:38

- reply

https://image.nostr.build/019777f34578ba5d2dc809caa8dad66dce377fee9eacf30452e50175e58ce94b.jpg

2025-01-25 04:11:58

- reply

I encourage readers to listen to the podcast and draw their own conclusions
also this one with me and Luke Parker (monero dev): https://x.com/super_testnet/status/1824431745443279044

2025-01-25 03:26:33

- reply

> anyone on the path knows the amount of the payment
Thanks to the commonality of multipath payments, nodes along the path only know a lower bound of the amount, not the definite amount
> it is possible to identify recipients, and senders with high accuracy, by only controlling some of the nodes on the path
I do not think this is true. Let's suppose you control 5 nodes along the path (Charlie, Dave, Edna, Filbert, and Genna) and you start to trace a payment that flowed through your nodes. You trace it back to Bob on the "sender" side and Harry on the "recipient" side. But you can't tell whether Bob is *really* the sender or just another routing node. And you can't tell if Harry is *really* the recipient or just another routing node. All you know is, those nodes were as far as you could trace it.

2025-01-25 02:35:04

How privacy works in monero versus lightning
https://image.nostr.build/b76f2420ed5271285c2efdbfe953b135eba2f439bf7c69a9853e859f6a7e356b.png

2025-01-24 23:02:34

- reply

you mean because it wasn't a Nintento-made pokemon game?

2025-01-24 22:18:32

Someone ran pokemon on bitcoin using bitvm 🤯
https://blog.rootstock.io/noticia/pkmn_bttl-a-pokemon-battle-game-written-in-zig-and-executed-with-bitvmx/

2025-01-24 20:56:04

Me versus monero people lately
https://i.ibb.co/6XYBfWy/bisq-and-robosats-meme.png

2025-01-22 18:29:30

Some people say LN usage is primarily custodial. My statistics don't support that
Here's a list of LN wallets on Google Play, with their kind (custodial or not) listed with their number of downloads
https://gist.github.com/supertestnet/5bceb60d9c691da744a55dad3f60e65e
Conclusion: self custodial LN wallets are more popular

2025-01-20 15:21:51

- reply

I don't understand the project. Generically, it seems like they want to put the King James Bible on a nostr relay that they self-host. I don't see a problem with putting stuff on your own relay, though I do wish they used a *complete* 73-book bible like the Douay Rheims instead of the KJV, which, in most editions since the 1800s, only includes 66 books of the bible.

2025-01-16 16:16:30

- reply

I don't think it really needs to be a server. Lightning wallets only need to get online every 2 weeks or so to ensure their counterparty isn't cheating. I think a bitvm wallet could do the same thing. As an (occasional) bitvm dev, I want to ensure my bitvm programs use a 2 week timelock to give users time to (1) open their device and check that the program was executed correctly (2) and penalize their counterparty if they ran it wrong.

2025-01-10 01:55:16

This is an interesting article: https://dba.xyz/a-bitcoin-l2-thesis/
But I have two objections.
#1: the author accuses bitcoin of having a "lack of programmability." It doesn't. Bitcoin Script is computationally universal because it has all the logic gates, and the bitvm whitepaper proved that you can get around the script size constraints by transporting state from one transaction to the next. So bitcoin script is fully programmable: anything a real computer can do, bitcoin script can do. It just requires lots of transactions (i.e. it's expensive).
#2: the author ignores the lightning network on the grounds that he wants to "mostly focus on fully programmable L2s."
But the lightning network is just as programmable as bitcoin is. A lightning transaction is just a bitcoin transaction that you haven't broadcasted yet. So you can do just as much programming therein as you can do in a "regular" bitcoin transaction, and even create a bitvm-like chain of transactions executing a complex program, all built on a lightning transaction and therefore on a layer 2.
I want to see work done in that direction.

2025-01-04 22:17:11

- reply

My bankify wallet is an example:
https://github.com/supertestnet/bankify
It does not verify the response received from a mint and is therefore vulnerable

2025-01-02 15:26:23

Are exchanges violating Europe's MICA law by listing ethereum?
MICA says: "[Exchanges] shall prevent the admission to trading of crypto-assets that have an inbuilt anonymisation function unless the holders of those crypto-assets and their transaction history can be identified by the [exchange]." (Title I Article 76 Section 3 - full text here: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1114&qid=1735616578262)
Tornado Cash is built into Ethereum. It's a smart contract, which means it's just like a consensus rule in these respects: ethereum nodes must keep a copy of the smart contract; any eth user may use it; and as long as the majority of validators keep approving transactions that use it, the other validators must fall in line or fall out of consensus.
One might say "yeah but it's optional, so it doesn't count as built in." But aren't they delisting zcash and dash? The anonymization functions in *those* cryptocurrencies are optional too. Maybe there's some nuance about what "built in" means. I don't think the MICA law defines it. Perhaps a lawsuit should happen to get the courts to define it; possible outcome A: zcash and dash get relisted; possible outcome B: ethereum gets delisted.

2024-12-31 03:47:43

- reply

I think I found it.
Title I Article 76 Section 3 says:
"The operating rules of [every] trading platform for crypto-assets shall prevent the admission to trading of crypto-assets that have an inbuilt anonymisation function unless the holders of those crypto-assets and their transaction history can be identified by the crypto-asset service providers operating a trading platform for crypto-assets."
Full text here: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1114&qid=1735616578262

2024-12-31 00:50:37

- reply

I am trying to look it up for myself but I can't find the text of the law (it's called Mica)
I found an official summary document but a word search for privacy did not yield anything useful
People keep saying the law requires exchanges to delist privacy coins; in just wondering, where does it say that? What is the precise language of the prohibition? Does anyone have a quote?

2024-12-29 11:47:55

- reply

> Since October 2024, the EU prohibits the use of privacy coins
Source?

2024-12-28 05:24:11

- reply

defi services can still profit from other parts
e.g. they can continue taking a % of staking rewards (that's the app layer, not the frontend)
they can still run "searchers" to front-run customers
they can still receive airdrops
it's only *frontends* that mustn't make a profit

2024-12-28 05:19:35

- reply

I wonder if this means defi service providers will create a "non-profit arm" solely responsible for creating and running a frontend service
Only the frontend services are categorized as brokers, and only if they make a profit
So just keep that part profit-free and you're gold

2024-12-28 05:08:29

It is annoying that the new IRS defi document does not contain page numbers. (source: https://public-inspection.federalregister.gov/2024-30496.pdf) But pdf readers do.
And I note that on page 41, they clarify that a software developer is not a broker unless they get "consideration" (i.e. money) for their code. Yay!

2024-12-26 06:21:56

- reply

Likewise!

2024-12-25 01:03:59

- reply

Poors Law
The cost of AI technology drops by half every year

2024-12-25 01:00:52

- reply

Op returns burn any bitcoins they contain
And I'm not interested in counting non-bitcoin payments

2024-12-24 19:03:08

- reply

Op returns and p2a outputs also wouldn't count because they aren't payments

2024-12-24 19:02:13

- reply

Yeah, though I'd assume one output per tx is "change" and doesn't count

2024-12-24 03:46:34

unusually slow network today
the average block in the last 24 hours only had 3.59 tps in it (i.e. 2154 transactions) and NO BLOCK had more than 6.33 tps (3801 transactions)
https://i.ibb.co/N216mk9/unusual-result.png

2024-12-23 21:00:19

yesterday someone pointed out a building and said, "that's a robot furniture factory"
why the robots want furniture is a mystery I guess I'll never know

2024-12-22 22:57:33

- reply

No
But you just gave a new project idea: it would be cool to have a tool where you can paste a set of one or more ecash qr codes, and it will make a shareable link that you can give to anyone; if they visit your link, they see an interface that shows them the amount in the qr code and a Send button to send it via lightning to any LN compatible wallet.

2024-12-22 16:34:42

- reply

I could have just printed the tokens directly from the mint, instead of running lnbits, but the tokens would have worked with fewer wallets -- and if I wanted to retain self custody of the money I would have to run the mint anyway, might as well run lnbits

2024-12-22 16:30:41

- reply

No but it would have been cheaper. I had to pay phoenix a setup fee to open my channel

2024-12-22 14:51:02

Perfectionists never ship

2024-12-20 16:34:01

- reply

A more complete explanation of how we did it is available here:
https://stacker.news/items/817809

2024-12-20 16:16:39

- reply

The piñata held 51 qrs: sticky paper on black foam (all bought for $2 in total at a paper store). We had 100k sats in prizes divided up like this:
1 qr code worth 22,500 sats ($22.50)
10 worth 4000 ($4)
10 worth 2000 ($2)
10 worth 1000 ($1)
10 worth 500 (50¢)
10 worth 250 (25¢)

2024-12-20 16:11:59

Meet the Bitcoin Piñata!
We think it's the first piñata ever that pays you bitcoin. Myself and a bunch of other bitcoiners bashed it yesterday in Guadalajara during a Posada (Mexican Christmas party). So much fun!
https://video.nostr.build/5a202e6829e21b665480dfc46ac8ff542c2cd69a3595fa221c4652036a141834.mp4

2024-12-19 21:13:01

- reply

I didn't think of BitTorrent! Good call. Is there a website somewhere that estimates the total number of active seeders?

2024-12-19 17:27:07

Bitcoin vs the World: how big is btc's network compared to other large networks?
Here's my analysis: https://stacker.news/items/816200

2024-12-18 19:28:35

if we activate the P2QRH bip by @nprofile…crn3 then bitcoin will finally have a quantum resistant signature scheme
at which point we should stop calling it a "cryptocurrency" and start calling it a "quantum wampum"
https://github.com/cryptoquick/bips/blob/61aac1a91a596cdeed75ed7f5c5c19b0b4b923ef/bip-p2qrh.mediawiki

2024-12-16 22:06:18

- reply

1. It feels a bit different to me, but anyway telling my users to download *anything* (even bitcoin core) is too much
2. That sounds like the same thing as making my own faucet, and it is my understanding that any faucet will quickly stop working unless you rate limit your users, which is exactly the thing I don't want to do