Nostr notes by Super Testnet

I'm trying to piece together their logic, and I think the ...

2026-10-10T17:16:17Z

In reply to nevent1q…t4eu
_________________________

I'm trying to piece together their logic, and I think the starting point is this: the sender of a lightning payment gets to see the recipient's invoice, and sometimes the invoice has a "node key" in it that belongs to the recipient. When the thief withdrew stolen money from Blink, he gave them an invoice that had a "node key" in it, and that "node key" belonged to a node with public, announced data on the lightning graph. It's called aegis-ln.

I suspect that was the starting point for Blink's investigation. I believe they figured aegis-ln likely belongs to the thief, and since it has public, announced channels, they investigated those channels. For publicly announced channels, their funding txs are public, so they could check what addresses funded them.

That lead them to a bitcoin address which they call the "collection" address because it collected money from Fedimints. I haven't thoroughly investigated this part yet, but if I'm reading their report right, they seem to allege that this "collection" address was reused in the following manner:

The collection address allegedly funded the aegis-ln node's L1 wallet, which opened at least one LN channel with that money; and after the aegis-ln node's channels were closed, the collection address *also* contributed funds to a an L1 tx *with* the aegis-ln node's money, where the thief sent the stolen money to a new destination, combining funds from the Blink theft with money collected from the Fedimints.

I'm not 100% sure about all of the above paragraph, but that's the picture starting to emerge in my mind. So far, the initial lightning trace appears to be from Blink to the aegis-ln node, and they seem to be basing this so-called "proven" trace (I question the proof) in part on the fact that aegis-ln's pubkey appeared in the invoice they paid -- which, imo, is no proof at all. But it's not the only piece of data they are relying on. Read their essay for more details.

Nah, monero make it worse

2026-10-10T15:35:58Z

In reply to nevent1q…e8dj
_________________________

Nah, monero make it worse

#nevent1q…u5ez

2026-10-10T15:35:16Z

In reply to nevent1q…7qt4
_________________________

quoting nevent1q…u5ez
> you expose a profound misunderstanding of how stealth addresses and ring signatures actually work

I look forward to examining why you think that in the rest of this post

> Referencing a past output in a ring signature as a decoy is standard mixin behavior (it is not key reuse)

It is an unnecessary data leak that monero puts on a permanent, transparent ledger, and it gets people arrested, because chainalysis collects and analyzes that data. Moreover, it is key reuse: the key was used once when the recipient received money and a second time when he spent it. It sounds like you have a very narrow definition of what counts as "use" and are mad that I'm using a more reasonable definition. Let me ask you directly: is a key used when a person receives money? Is it used when they spend money? Are those two different times? I look forward to your answers.

> The Chainalysis examples you continually cite do not represent cryptographic vulnerabilities or blockchain leaks

They absolutely do. Chainalysis relies on the data they gather from the blockchain to help the police arrest their targets, and that data includes the ring signatures, the output keys, and the fee data. That data is leaked to a transparent, permanent ledger by protocol design, and some of it has already resulted in several arrests, as cited in the case studies pointed out here: https://supertestnet.github.io/monero-privacy-leaks/

Saying "the tracers *also* use *out-of-band* data when they can get it" does not change the fact that they rely on on-chain data too, and that data is needlessly leaked to a transparent, permanent ledger, which makes tracing much easier for them.

> Monero blockchain itself has never leaked spend histories

Lol, your dam has a thousand holes and you point to the one place that hasn't broken yet and say "but THAT part's still intact! Stop pointing out all the places where water is getting through and drowning people! Focus on the stones still in place!" It's a ridiculous, denialist approach.

> conflating out-of-band operational security blunders with cryptographic protocol failure is pure intellectual dishonesty

That's not what I'm doing. Users often do make opsec blunders. Often, that happens several txs down the trail, and the tracers only find the txs where the user made the blunder by tracing their monero txs several steps down until they find an opsec mistake.

This happened in the Columbian drug dealer case, and you can watch their video breakdown of the trace by clicking the link on my website. Here's a text breakdown for you.

At timestamp 34:03, they begin their trace with tx0: febcf2df049586a5b8c55e17f7627ce3751d19976f9f0c07dccd4836dbd7f3d1 -- where the target received money into monero in output 1.

Then, at timestamp 34:54, they analyze a follow-up tx, tx1: e4f525b214ef7310b53dd2e81be42801c7ee1a7c259ac0a093d813b493a788a8 -- where the target sent money received in tx0 into output 1.

Then, at timestamp 36:36, they analyze a follow-up tx, tx2: a5202cb022921d624d0e9a40a9d7e0cdc4d9cfeb0be11501414fe5a9c0cdd2a8 -- where the target sent money received in tx1 to output0.

Then, still at 36:36, they analyze a follow-up tx, tx3: bd39f43a8d5bee47feff2f22792977d0a4d3972ee0e4b2718b6208f1a6380d0d -- which is the step where the target leaked his ip address when he sent the money received in tx2 into another output without using a VPN. He broadcasted tx3 through a node that Chainalysis got data from. Chainalysis thus learned his ip address, and found him.

You may decide to focus blame entirely on the opsec mistake he made at tx3, where he leaked his ip address. But you ignore tx0, tx1, and tx2, where they collected and followed the data leaked by the monero blockchain itself, in order to trace the money *to* tx3 and associate it with their target. In reality, the blame lies in both places: monero shouldn't have leaked that data (it should work more like LN) *and* the target shouldn't have leaked his ip address while broadcasting tx3. But your denialism is ridiculous: it is not true that the only thing at fault here was the ip leak. They never would have found tx3 where he leaked that data if they couldn't trace the money through tx0, tx1, and tx2 first.

> your attempts to dismiss FCMP++ by comparing it to Lightning's Sphinx routing are equally nonsensical

I don't try to dismiss FCMP. I think it's a significant improvement. It's just not as good as what we're already doing in lightning. The person who claims they will win the silver prize in the future is not dismissed just because someone else already won the gold prize. Silver and gold are both good. But your future silver prize is currently theoretical, may never happen, and is not as good.

> FCMP...expand[s] the anonymity set from 16 to the entire cumulative history of outputs... Lightning's onion routing offers nowhere near this level of privacy

It does. Lightning's packets are encrypted blobs that could contain *any* information. One payment packet is indistinguishable from another, in such a way that *any* wallet could have created it, even one spun up ten minutes ago and which is never used again. That anonymity set is at least as large as the one FCMP extends to. LN's anonymity set is, in fact, an infinite set, because the set of wallets that could have made any given payment packet includes all wallets that might exist for only the space of a few minutes just to make that packet, and that number is infinite. Monero’s anonymity set is currently 16 by comparison, and after FCMP (if it ever comes) it will still be a finite number, though in the millions, and thus really good (like silver compared to gold).

> While Sphinx encrypts routing hops, intermediate nodes along a payment path must know the exact HTLC amount and CLTV expiry passing through their channel in order to update local channel commitment transactions. Claiming intermediate routing nodes don't know the routed amount is factually false.

They do not know the "total" amount because of multipath payments

> Even with Multi-Path Payments, large routing hubs holding massive network liquidity can trivially perform timing, flow, and volume correlation analysis

You neglected several important "ifs": if the money doesn't flow through them, they don't get to analyze it; if only part of it flows through them, they don't learn the full amount; even if the full amount *does* flow through them, they cannot know that; they also don't know if the next node or nodes on the route are the recipient or not; and the person trying to trace the payment may not know who all to ask, and the ones he does ask may have a variety of privacy policies and refuse to answer. In lightning, not even the sender knows the ultimate destination node, let alone the routing nodes. This is much better than monero. Monero needlessly gives the sender a proof of which key belongs to the recipient as well as a proof of the amount received by that key in that tx, and it leaks fee data, input data, and output data to a permanent ledger along the way.

> framing the fact that a sender knows how much they sent to a recipient as a "privacy leak" is perhaps your most absurd mental gymnastic yet

You guys keep on restating a falsehood and can't seem to keep it straight. Let me ask you directly. Do you acknowledge that the following things are different on lightning? The "amount the sender sent" on lightning is different from the "amount the recipient(s) received." Do you acknowledge that? And do you acknowledge that the sender *knows the former* (which you two keep falsely criticizing me for denying) but -- in lightning -- he *does not know the latter* whereas in monero he does. That is a leak on monero that lightning fixes. The sender should not know how much the recipient(s) received or even if there are multiple recipients that he doesn't know about. It's none of his business. It's like the album store example: the buyer should know he paid, and get his receipt atomically, but if the money got split up between the clerk, the album's producer, and the artist, the buyer should not know that, nor the amounts they each received. That business is internal to the album store and is none of the buyer's business. Monero leaks that data and LN does not.

> A sender knowing the precise amount they transferred to a recipient is how basic arithmetic works, not a protocol flaw

The flaw is that he knows how much the recipient received as well as the number of recipients. That is an unnecessary data leak and a protocol flaw. Lightning fixes it.

> you completely ignore Lightning's glaring structural vulnerability: Active channel probing!

I do not ignore it. Channel probing is a flaw and deserves further work, I often talk about it and highlight progress being made in that department, like multiparty channels, which further dilute the potential information gleanable from channel probing, and prepaid htlcs, which increase the monetary cost of channel probing, and forwarding delays, which do two things: they increase the time cost of channel probing while simultaneously making it more likely that the capacities of other channels on the network (plus the one being probed) change mid-payment, thus fuzzing the data.

> any low-cost probe node can send fake payment probes across the network to continuously map balance changes across public channels

I question your claim that continuous probing is cheap, easy, or likely to yield a continuous set of accurate data. An attempt to learn the state of the whole network by probing was tried in 2020: https://arxiv.org/abs/2004.00333

It took 9 hours to get data about only 65% of the network, due to natural network delays and the prober’s method of probing a set of nodes, waiting for the htlcs to succeed or fail, and then probing the next set. Some of these delays are not things the prober can fix. In the test, these delays meant the state of the network was changing continuously during the probing, and once they had the full data, it was no longer an accurate picture. A prober could try connecting to more nodes simultaneously, but the costs rise if they try that, and even then, the probers may find the same thing the testers found: lots of nodes don't respond, lots of nodes aren't even announced, and there are lots of delays that harm the data.

> This allows malicious actors or government surveillance hubs to monitor payment flows in real time and deanonymize transacting parties with extreme statistical confidence without ever needing access to private keys

Your conclusion does not follow since so many of your premises are flawed. Also, the ongoing Blink case demonstrates a non-malicious party trying to trace a payment, and all the gaps in their knowledge are telling. We'll see if they are able to catch the criminal or not. I think we’re already learning a lot even now, and how long it takes them to nab him, if they do at all, will tell even more.

> Lightning's threat model inherently exposes users to traffic analysis, Sybil attacks, and active network surveillance by intermediate routing partners.

Sure, it has problems, and good devs are working on them, and more work is needed before anyone could make a claim like “tracing lightning is impossible.” But it's already better than monero in many respects: it leaks less data permanently, it leaks less data to the public, and it gives less data to senders. It gives too much data to routers, which is undoubtedly a problem, but even now it's better than monero if both are used carefully.

> Monero secures privacy at Layer 1 by default, I mean, concealing sender, receiver, and transaction amount simultaneously

Nah, it exposes data about all of those, as demonstrated on the site I linked. That data is often collected from the permanent, transparent monero ledger, analyzed, and used to charge criminals with crimes. You’re better off not leaking it to the public. You're better off with lightning.

The way they "prove" that aegis-ln belongs to the perp is ...

2026-10-08T22:16:42Z

In reply to nevent1q…25vs
_________________________

The way they "prove" that aegis-ln belongs to the perp is also interesting. They mark this as "proven" and give two reasons in the "how we know" section: the first is that this node showed up as the "node pubkey" in an ln invoice they paid, but that is no proof at all, because proxies exist to disrupt the assumption that "node pubkeys" belong to the recipient. They can be faked, and if that was their only reason, they wouldn't know. Maybe aegis-ln is really just a proxy.

Their second reason is stronger, and involves address reuse by the perp. Allegedly he opened a channel from aegis-ln to someone else using funds deposited to aegis-ln from an address he previously used in preparation for the theft. If that is true it's a much bigger mistake by the perp, and suggests that LN privacy devs still have a lot of work to do. Privacy tools need to automate this stuff so that addresses are not reused. But I haven't verified the site's "proofs" yet so I'm really not sure they are all as certain as they claim to be.

Yes, that is interesting, as is his alleged decision to ...

2026-10-08T21:55:27Z

In reply to nevent1q…js6m
_________________________

Yes, that is interesting, as is his alleged decision to repeatedly send funds from fedimints to an address he used earlier in the theft preparations. He apparently put funds back into a fedimint again and I suspect he didn't make that mistake the second time, but withdrew to fresh addresses, or lightning channels.

This is really exciting. This is the first time I've heard of ...

2026-10-08T18:32:46Z

This is really exciting. This is the first time I've heard of a thief moving funds over lightning to obfuscate his trail, and the first time I've seen someone try to trace the flow of funds over lightning and claim they know where it now sits: https://www.blink.sv/blog/phase-two-following-the-coins-in-public

> Being against taxes does not equal wanting free stuff It ...

2026-09-29T15:09:13Z

In reply to nevent1q…g38n
_________________________

> Being against taxes does not equal wanting free stuff

It does. Taxes are a form of rent. Demanding 0 taxes is thus a form of demanding 0 rent, which is freeloading.

> inefficient and wasteful organization

You can lament their inefficiency and even try to reform them. But you don't get to withhold the money you owe them just because you don't like how they spend it. It's their money. The renter can't stop paying rent just because he notices the landlord buys too much booze.

> landlords don't coordinate with employers to take rent ...

2026-09-28T19:52:54Z

In reply to nevent1q…ng8v
_________________________

> landlords don't coordinate with employers to take rent from wages

Some do. Ever hear of Section 8 housing? The fact that most landlords collect rent in a different manner does not change the fact that the government is a landlord who extracts "rent" (taxes) from everyone who lives on its land.

quoting
nevent1q…a05m
If the only difference between rent and taxes is "rent is voluntary," then it follows that taxes are the same thing as rent, except compulsory.

Rent is a charge on the use of something (such as a location) for a period of time

Human nature compels all of us to exist in places for periods of time. So the owners of those places have a natural right to charge us for the use of those spaces. That's why rent exists and is reasonable to pay if you are a tenant in someone's building, and it is also why taxes exist and are reasonable to pay if you are a resident in someone's country.

#nevent1q…a05m

2026-09-28T19:49:54Z

In reply to nevent1q…atsk
_________________________

quoting nevent1q…a05m
If the only difference between rent and taxes is "rent is voluntary," then it follows that taxes are the same thing as rent, except compulsory.

Rent is a charge on the use of something (such as a location) for a period of time

Human nature compels all of us to exist in places for periods of time. So the owners of those places have a natural right to charge us for the use of those spaces. That's why rent exists and is reasonable to pay if you are a tenant in someone's building, and it is also why taxes exist and are reasonable to pay if you are a resident in someone's country.

> it's whether payment is negotiated or extracted ...

2026-09-27T04:56:06Z

In reply to nevent1q…kwhx
_________________________

> it's whether payment is negotiated or extracted

quoting
nevent1q…a05m
If the only difference between rent and taxes is "rent is voluntary," then it follows that taxes are the same thing as rent, except compulsory.

Rent is a charge on the use of something (such as a location) for a period of time

Human nature compels all of us to exist in places for periods of time. So the owners of those places have a natural right to charge us for the use of those spaces. That's why rent exists and is reasonable to pay if you are a tenant in someone's building, and it is also why taxes exist and are reasonable to pay if you are a resident in someone's country.

Wrong, because taxes are not theft, taxes are rent People who ...

2026-09-27T02:08:35Z

In reply to nevent1q…f5ry
_________________________

Wrong, because taxes are not theft, taxes are rent

People who oppose taxes are the whiny people I'm complaining about

Communists, the lot of them

"not understanding economics is why your argument isn't ...

2026-09-26T22:05:56Z

In reply to nevent1q…rtqw
_________________________

"not understanding economics is why your argument isn't compelling"

I challenge you to find a proof somewhere in economics that contradicts my argument

The fact that I said "you don't need to be an economist ...

2026-09-26T20:11:49Z

In reply to nevent1q…vsr2
_________________________

The fact that I said "you don't need to be an economist to see this" and you read it as "economics is irrelevant" shows your reading comprehension

People who oppose taxation are like people who oppose rent Oh, ...

2026-09-26T19:30:59Z

People who oppose taxation are like people who oppose rent

Oh, you want free stuff? Get in line, the real world costs money

Libertarianism is just crybaby communism

Idk, I've never tried

2026-09-12T23:50:11Z

In reply to nevent1q…8wtv
_________________________

Idk, I've never tried

An underappreciated thing about the new Wavelength software from ...

2026-09-12T17:09:05Z

An underappreciated thing about the new Wavelength software from Lightning Labs is its name. It doesn't have "Ark" in its name. It's probably the first new payment-focused bitcoin software in the past three years that has avoided that sound.

Monero leaks https://supertestnet.github.io/monero-privacy-leaks/

2026-08-29T19:08:45Z

In reply to nevent1q…jcm4
_________________________

Monero leaks

https://supertestnet.github.io/monero-privacy-leaks/

Today I released a recording of my recital of chapter 8 of my ...

2026-08-18T22:02:21Z

Today I released a recording of my recital of chapter 8 of my ongoing work, "The Life of Robin Hood." Listen to it here: https://venatoverba.com/2026/08/18/chapter-eight-of-the-life-of-robin-hood.html

Idk, if the blog post I put it under is tested as the opening ...

2026-08-14T05:15:50Z

In reply to nevent1q…vlr2
_________________________

Idk, if the blog post I put it under is tested as the opening post of a new thread, a comments section is basically just a forum thread imo

Doing that is a type of coinswap. And it is awesome, and it is ...

2026-08-13T22:49:28Z

In reply to nevent1q…g5nm
_________________________

Doing that is a type of coinswap. And it is awesome, and it is great to see the number of providers grow. I think miners are a particularly apt group to be providers of such a service because they have always-on server, are used to bitcoin as income, and have a steady supply of new sats to treat as merchandise.

Yeah! But there are some sad aspects to this: (1) most of the ...

2026-08-13T17:52:49Z

In reply to nevent1q…9ua8
_________________________

Yeah! But there are some sad aspects to this: (1) most of the rental sites do KYC on their users (2) I think 100% of them are custodial. It would be really cool to have a model where a rental website gets a "prepayment" that is locked in such a way that it only gets "unlocked" if they deliver the expected amount of hashrate -- e.g. if the coinbase you're searching for actually gets found.

So, the bip110 drama is over now, and a bunch of hashrate lost ...

2026-08-13T17:39:22Z

So, the bip110 drama is over now, and a bunch of hashrate lost its buyers, making it available at lower prices. And Ocean still works. It's possible to trade in your old coins for some fresh coinbase outputs. Is anyone building tools to automate this and make it more accessible?

Most pro110 miners are renting rigs from sites that don't ...

2026-08-08T17:02:41Z

Most pro110 miners are renting rigs from sites that don't accept bip110 coins. Those pro110 miners can only keep mining if they maintain a reserve of non110 coins, to pay with those. That means the most economically significant pro110ers will still be supporting the non110 chain!

Here's something that interests me about the coldcard bug: it ...

2026-08-06T19:36:04Z

Here's something that interests me about the coldcard bug: it had 2 random number generators. The "bad" one was seeded with data including keypresses, the timestamp, and the device id. I can understand that, it's probably how I would seed it. What was the "good" one seeded with?

Earlier this week they turned off their swap server, apparently ...

2026-08-05T21:52:50Z

In reply to nevent1q…ctra
_________________________

Earlier this week they turned off their swap server, apparently for the same reason Boltz did: a malicious actor started automated probing their infrastructure for weaknesses, and found some, and it was becoming clear that the code wasn't production ready. If I had to guess, the same thing has happened again, but with other things they were running on the same server.

Another piece of LN infrastructure goes down this week: ...

2026-08-05T21:47:04Z

Another piece of LN infrastructure goes down this week: https://zeusln.com/blog/security-update-2026-08-05/

That is not always true. For example, consider the coinbase txs ...

2026-08-02T18:22:39Z

In reply to nevent1q…l8k2
_________________________

That is not always true. For example, consider the coinbase txs on the 110 chain, and any txs descended from them. Non-110 nodes will only accept those txs if the blockchain they are in has more proof of work than the non-110 chain. That looks very unlikely, so this will probably result a chain split where some txs on the 110 chain are rejected on the non-110 chain, and vice versa.

Last year the US government sent a bailout to Argentina. Now it ...

2026-08-02T18:17:17Z

Last year the US government sent a bailout to Argentina. Now it is apparently sending a bailout to Japan: https://www.cnbc.com/2026/08/01/us-treasury-intervenes-to-support-yen-after-japan-steps-in-ft.html

quoting
nevent1q…sr37
Usually, Japan's government steps in about now to lower this number, mainly by selling US treasuries. But I think their "outflow" of US treasuries has exceeded their "income" of the same for a while now. I wonder if they can keep it up, or if they have to let inflation run hotter

Your new rules would ruin bitcoin by potentially freezing the ...

2026-08-01T22:02:59Z

In reply to nevent1q…wvm3
_________________________

Your new rules would ruin bitcoin by potentially freezing the funds of innocent users. My mindset is to oppose such efforts. I hope y'all fix bip110 and try again later. Maybe y'all can get more support with a better bip.

It will only activate on nodes that are running bip110, and those ...

2026-08-01T22:01:22Z

In reply to nevent1q…nldx
_________________________

It will only activate on nodes that are running bip110, and those nodes will stop accepting bitcoin blocks almost immediately after they activate the new rules. Leading to yall being on a dead chain with no blocks, no exchange support, and no network effect. Sayonara.

It's plausible, but unlikely imo. I suspect 95% or more of ...

2026-08-01T21:56:50Z

In reply to nevent1q…nnyw
_________________________

It's plausible, but unlikely imo. I suspect 95% or more of miners aren't concerned about this fork. They are unlikely to signal unless they suddenly gain an interest in doing so, and nome seems forthcoming. It's probably not even a discussion point in their decision making meetings.

I suspect that, other than miners who are already part of Ocean, any miners who *do* analyze their options during decision making meetings will discuss it in terms of two options -- signal or ignore -- and they'll decide that ignoring it improves their bottom line. This is because, if they ignore the 110ers, about 2% of miners will fork off, and cease to be competition. That means the relative share of hashrate from the remaining miners effectively grows, which means they earn more money.

In other words, if a miner named Billy currently has 10 exahash, and the entire bitcoin network together has 1000 exahash, then Billy has 1%. The pro110ers seem to have about 20 exahash, which is around 2%. But they are about to effectively go offline, bringing the total down to 980. So if Billy just ignores this, he'll end up with 10 exahash out of 980, which is 1.02% -- a slight increase. That should make Billy more profitable, so my naive analysis of game theory suggests miners who have ignored this drama so far will want to continue to ignore it once mandatory signaling starts.

A bittersweet day approaches. In this, the last period before ...

2026-08-01T20:40:39Z

A bittersweet day approaches. In this, the last period before mandatory bip110 signaling, there are so few blocks left that even if bip110ers mined them all, they would still fail to achieve 55%. So they will fork off in 1018 blocks. Come back with a better proposal than bip110.

This cool new block explorer emphasizes the data footprint of ...

2026-08-01T00:01:30Z

This cool new block explorer emphasizes the data footprint of various transactions, especially the difference segwit made: beta.satoshi.space

H/t x.com/uanbtc

The best marketing is true

2026-07-22T17:54:58Z

In reply to nevent1q…00qq
_________________________

The best marketing is true

Looks like it

2026-07-17T19:06:56Z

In reply to nevent1q…j5ed
_________________________

Looks like it

I think this news indicates that one aspect of the marketing by ...

2026-07-17T17:55:39Z

I think this news indicates that one aspect of the marketing by Ocean Pool and DMND Pool has been effective. Namely, enough hashers want a say in how the blocks they produce look, that older pools are trying to find ways to give them that say, lest they go to pools that offer it. https://x.com/i/status/2078129671728722053

> End receiver has to share that invoice though I assume? ...

2026-07-17T04:19:07Z

In reply to nevent1q…5y2x
_________________________

> End receiver has to share that invoice though I assume?

It's not strictly necessary. You could use a keysend payment to pay a group of nodes atomically without getting an invoice from the recipient. But if you *do* get an invoice from the recipient, that doesn't mean you are trusting him.

The invoice need not contain a list, created by the end node, of the people to pay. It *could* contain such a list, since ln invoices support custom fields; but it could also just be an ordinary ln invoice, and the sender could choose what additional nodes to pay through some out-of-band method.

The point is, LN routing works by atomically splitting a large amount into small sums which are dropped off node by node, atomically, and this can be turned into a payment splitting function by rendering each payment as just a large routing fee. But it has some drawbacks, like not working well if a recipient does not run a routing node.

> Lightning itself can't natively split payments I think ...

2026-07-16T16:11:38Z

In reply to nevent1q…futz
_________________________

> Lightning itself can't natively split payments

I think it can. If the wallet knows it wants to pay 400 sats to Alice, 300 to Bob, and 500 to Carol, it can arrange a route that passes through each of their nodes, and drop pending fee htlcs off at each one, whose value corresponds to the amount desired for that node. The last node reveals the preimage and then everyone gets paid. That's an atomic split payment that lightning has native support for.

I would love it if a web wallet similar to coinos allowed me to ...

2026-07-09T22:00:36Z

I would love it if a web wallet similar to coinos allowed me to give it a list of N preimages and have it create the next N lightning invoices using those preimages.

This would allow me to make a digital downloads store that has no backend logic. I could upload files to my server that are encrypted with a certain key, and then use the web wallet to sell users "secret" preimages which, when added to a corresponding "public" string, create the decryption key.

The logic could therefore all be done on the frontend: show the user an invoice, check if it is paid via the web wallet's api, get the preimage, construct the decryption key, and give the user their now-decrypted file.

Thus the server for a webstore could be a simple file storage system, such as Github Pages, and all the logic could be done on the the frontend, except for the delivery of the secret, which is done by the web wallet, in a way that the frontend can detect.

I would love it if a web wallet similar to coinos allowed me to ...

2026-07-09T21:55:08Z

I would love it if a web wallet similar to coinos allowed me to give it a list of N preimages and have it create the next N lightning invoices using those preimages.

This would allow me to make a digital downloads store that has no backend logic. I could upload files to my server that are encrypted with a certain key, and then use the web wallet to sell users "secret" preimages which, when added to a corresponding "public" string, create the decryption key. The logic can therefore all be done on the frontend: show the user an invoice, check if it is paid via the web wallet's api, get the preimage, construct the decryption key, and give the user their now-decrypted file.

Thus the server for a webstore could be a simple file storage system, such as GitHub pages, and all the logic could be done on the frontend, except for the delivery of the secret, which is done by the web wallet, in a way that the frontend can detect.

BIP110 reached 1% of hashrate today. 18/(1743+18) = 0.0102 I ...

2026-07-09T20:02:57Z

BIP110 reached 1% of hashrate today. 18/(1743+18) = 0.0102

I recommend reviewing my URSF110 proposal: https://github.com/supertestnet/ursf-110

Can you recommend a writeup about how aut-ct provides sybil ...

2026-07-02T21:55:12Z

In reply to nevent1q…hjdk
_________________________

Can you recommend a writeup about how aut-ct provides sybil resistance in this context?

> Batch openings don't seem to provide much scalability ...

2026-07-01T04:13:04Z

In reply to nevent1q…amq8
_________________________

> Batch openings don't seem to provide much scalability benefit

I think they do. Suppose 10 people onboard to LN via Phoenix Wallet. Let's compare what it looks like with and without batching them.

Without batching: 10 inputs, 10 signatures, and 20 outputs (the channel + change)
With batching: 1 input, 1 signature, 11 outputs (10 channels + change)

The latter is clearly much more efficient in terms of chain space and therefore much cheaper, and more scalable. The benefits accrue as the number of users onboarded in batches grows.

I do see evidence that Lightning Labs sometimes does batched ...

2026-06-30T19:50:27Z

In reply to nevent1q…q6lh
_________________________

I do see evidence that Lightning Labs sometimes does batched channel opens via their Lightning Pool service: "All cleared orders in a batch are executed using a single batch transaction, allowing participants to pay lower chain fees compared to non-batched channel opening." https://lightning.engineering/posts/2020-11-02-pool-deep-dive/

Lightning Pool is different from Lightning Loop, but it's at least an example. I don't think Acinq has ever said they do batched channel opens for their users, but I might be missing something.

Can you provide documentation that loop or phoenixd does batched ...

2026-06-30T19:32:37Z

In reply to nevent1q…7mk3
_________________________

Can you provide documentation that loop or phoenixd does batched channel opens? I don't think either one does

Today I noticed this in the original LN whitepaper: "A ...

2026-06-30T19:24:15Z

Today I noticed this in the original LN whitepaper: "A Funding Transaction may have multiple outputs with multiple Commitment Transactions...[One output could] requir[e] additional signatures from security services."

The first sentence suggests the possibility of batch txs for opening channels, and the second sentence suggests the possibility of multiparty channels. Those are both ways to scale up lightning usage beyond just "raise the block size." Not only can several users share a funding tx, they can also share an *output* in that tx.

Source: https://lightning.network/lightning-network-paper.pdf";,

relevant: #nevent1q…n2lw

2026-06-30T19:09:40Z

In reply to nevent1q…tamv
_________________________

relevant:

quoting nevent1q…n2lw
On the other hand, they can also use it against you...

https://thereallo.dev/blog/claude-code-prompt-steganography

This stuff is neither amazing nor egregious, imo. But it *is* sneaky. Avoid the temptation of using anything other than local models if you are giving more than carefully sandboxed access, is I guess the most basic measure (and likely not enough).

nevent1q…gszd

False. I am just glad that resource exists and glad to see Chris ...

2026-06-30T15:11:47Z

In reply to nevent1q…fpq0
_________________________

False. I am just glad that resource exists and glad to see Chris spread fewer falsehoods. I maintain that bip110 is a bad idea for the reasons I outline here: https://github.com/supertestnet/ursf-110

Chris has done a good thing, and has made honest his list of ...

2026-06-29T01:17:39Z

Chris has done a good thing, and has made honest his list of economic nodes in favor of bip110. Review it here: https://v0-bitcoin-companies-table.vercel.app/

https://x.com/i/status/2071390336580989076

Very cool #nevent1q…xam0

2026-06-28T20:51:52Z

Very cool

quoting
nevent1q…xam0
We are very close to being able to have communication that is practically undetectable even by an aggressive censor like the CCP. Here's the basis of my claim: in order to be uncensorable, it's not only required that the data can't be readable (that's trivially achieved with end to end encryption), but also, the channel used to convey the messages needs to be 100% not suspicious. This is what we call steganography, and it's not only as hard as it seems, it's even harder. For example, you can embed data easily into low order bits of an image, but that doesn't successfully pass the "innocent" test. The pattern embedded in the binary file is statistically detectable with (not even very advanced) mathematics, so the censor will catch you. So you find yourself having to solve a strange problem: how to "mix" your secret message with some "innocent" message (called in the literature "cover text") in such a way that the innocent message is not suspicious. People have tried things like: embedding data in whitespace in text; this is obviously not good enough, though it's an amusing idea. Recently I started mulling over whether LLMs might be *the* solution to this problem, because an LLM's state evolution is governed by random choice, so if you embedded your data into that random stream, the output could be plausible innocent text while the hidden message was encoded in the randomness. (If you already see problems with that idea, well done, we'll get to it...)>

It turns out I am not even slightly original: Meteor https://eprint.iacr.org/2021/686 already had this idea in 2021 before LLMs had taken off, and moreover it tweaks the basic idea in the specific way needed to make it work. I won't bother expanding on the details rn. But I'll point out the limitations: for a receiver of the hidden message to actually receive it, they have to use exactly the same LLM, in exactly the same state, as the sender did (because it extracts the message from the random choices of token, which are stateful; the next token depends on the previous ones).

The upshot of this: if we had a scenario where a "decent" LLM could be loaded by users on both sides, and the sender generating output from that model is plausible innocent text (true for a decent model, not true for a really crappy small model), then you have a properly undetectable communication channel that no censor, even a suspicious one, would be able to see. But it'd be very stateful: Alice and Bob would need to set it up in advance with a key exchange. The idea of the model being *public* (which the paper discusses), could *kind of* work, again, if the model is very good. The bandwidth would still be fairly low (but much higher than bits in jpegs!). Not really clear, but we're a way off from this, but it could come in future. Plausible but difficult for communication that is extremely dangerous.

Notice again the pattern of how access to compute could be crucial for freedom.

Through logic such as this: - About 1 in 1000 bitcoin buyers in ...

2026-06-28T19:35:54Z

In reply to nevent1q…lmsf
_________________________

Through logic such as this:

- About 1 in 1000 bitcoin buyers in my addressable market runs a bitcoin node. In other words, the total set of my addressable market is probably "all the node runners multiplied by 1000."

- For each node runner in bitcoin generally, there are probably 1000 similarly minded people in bitcoin who do *not* run a node -- this goes for pro-110-ers, anti-110-ers, and 110-ignorers

- Among the ~20% of node runners who are pro-110-ers, each one id likely to stop recognizing my bitcoins in August and they will only buy forkcoin after that

- Combined with my first two points, if they are accurate, that means about 20% of bitcoin buyers in general will stop buying my bitcoins in August

- That's bad and I should be pretty open to doing things that can stop it from happening

Typo correction in the last sentence: Their utility is real, but ...

2026-06-28T19:24:12Z

In reply to nevent1q…zkss
_________________________

Typo correction in the last sentence:

Their utility is real, but more nuanced than that, and simplifications like "A reusable address that can't be tracked" are therefore potentially harmful.

This is cool, but I think you are overselling the privacy by ...

2026-06-28T19:22:36Z

In reply to nevent1q…xfqh
_________________________

This is cool, but I think you are overselling the privacy by saying silent payment addresses "can't be tracked." For example, suppose Bisq adds support for silent payment addresses (which would be a good thing btw) and I use the same SP address with two different sellers on Bisq. But unbeknownst to me, they are actually colluding, sting operators trying to collect info about Bisq users.

Such sting operators can compare notes and learn that the same person bought from Bisq twice, because they both sent money to the same SP address. That allows them to do some tracking that they *couldn't* do if I had avoided SP address reuse.

I think it is unwise to generally recommend reusing SP addresses without fear of tracking. Their utility is real, but more nuanced than tha, and simplifications like "A reusable address that can't be tracked."

> where are you getting the 20%? I was thinking of this chart, ...

2026-06-28T19:15:30Z

In reply to nevent1q…fghg
_________________________

> where are you getting the 20%?

I was thinking of this chart, but I thought it said 17% and I was rounding up

Source: https://luke.dashjr.org/programs/bitcoin/files/charts/services.html

I think they theoretically should care about the potentially lost ...

2026-06-28T16:57:44Z

In reply to nevent1q…ev3z
_________________________

I think they theoretically should care about the potentially lost revenue from a big chunk of regular bitcoin buyers leaving for a fork coin. I suspect miners make much more money from selling their subsidy revenue on exchanges than they do from selling their fee revenue. And if 20% of bitcoiners stop buying that subsidy, it could be a critical hit for many of them.

Today the BIP110 people made a list of economically significant ...

2026-06-28T04:08:54Z

Today the BIP110 people made a list of economically significant people and groups who currently support or plan to support bip110. Such a list is definitely useful. Sadly it looks like this one is largely a bunch of made up nonsense.

Review the list here: v0-bitcoin-companies-table.vercel.app

It has some things in common but Zeus's zaplocker ...

2026-06-27T04:00:07Z

In reply to nevent1q…wgmn
_________________________

It has some things in common but Zeus's zaplocker functionality is not as good. With zaplocker, if Alice sends a payment Alice -> Bob -> Carol -> Dave, three people -- Alice, Bob and Carol -- all have to fund an htlc and keep it pending til Dave gets online.

With LDK's protocol, only Alice funds an htlc and keeps it pending. This is better because pending htlcs on the lightning network are a constrained resource, so creating fewer of them is good.

In case you want to know why pending htlcs are a constrained resource, it is because pending htlcs temporarily consume two other limited resources on nodes: htlc slots and outbound capacity.

Each channel has a limited amount of outbound capacity because that is money and no one has unlimited money. Each channel also has a limited number of htlcs that can be pending at once, for several reasons. One of them is that, when force closing a channel, all of your pending htlcs have to be represented on the blockchain as the outputs and sometimes the inputs of one or more transactions. Each additional one takes up more bytes, and transactions can only be a limited size, so there is a number X where you can't have more than X inputs+outputs in a transaction, and therefore can't have more than X pending htlcs in a channel.

Possibly the biggest news of the last five years, imo: Lightning ...

2026-06-26T23:00:45Z

Possibly the biggest news of the last five years, imo: Lightning Dev Kit might have just fixed the lightning problem where your payment fails if the recipient is offline. They not only have a protocol spec, but code + a guide for adding support in wallets: https://lightningdevkit.org/blog/async-payments-receiving-while-offline

Cool! But please retain the option to set a custom electrum ...

2026-06-26T17:01:52Z

In reply to nevent1q…zv8p
_________________________

Cool! But please retain the option to set a custom electrum server. It is becoming a pretty standard feature these days, and allows people an easier way to do self custody: running your own electrum server is easier than running your own esplora server. (Though I suppose technically an esplora server *is* an electrum server, just with extra stuff on top.)

This is pretty fun. Here's a suggestion: instead of relying ...

2026-06-26T06:05:09Z

In reply to nevent1q…2n6v
_________________________

This is pretty fun. Here's a suggestion: instead of relying only on esplora servers, also give users an option connect to an electrum server via websockets instead. Here's some sample code to get you started:

List of electrum servers that accept websocket connections:

```
wss://btc.electroncash.dk:60004
wss://bitcoin.grey.pw:50004
wss://blackie.c3-soft.com:57004
wss://electrum.jochen-hoenicke.de:50010
wss://blockstream.info/electrum-websocket/
wss://mempool.guide/electrum-websocket/
```

Code for talking to them:

```
var socket = new WebSocket( 'wss://blockstream.info/electrum-websocket/' );
var formatted_command = {
"id": "test123",
"method": "blockchain.block.header",
"params": [ 101 ],
}
var handleFunction = async message => {
console.log( message.data );
}
socket.addEventListener( 'message', handleFunction );
socket.send( JSON.stringify( formatted_command ) );
```

List of useful methods:

```
blockchain.address.get_proof, [address]
blockchain.scripthash.get_balance, [scripthash]
blockchain.scripthash.get_history, [scripthash]
blockchain.scripthash.get_mempool, [scripthash]
blockchain.scripthash.listunspent, [scripthash]
blockchain.block.header, [height]
blockchain.block.headers, [start_height, count]
blockchain.estimatefee, [number]
blockchain.headers.subscribe, []
blockchain.transaction.broadcast, [rawtx]
blockchain.transaction.get, [tx_hash, verbose || false]
blockchain.transaction.get_merkle, [tx_hash, height]
```

As far as I know, Ocean doesn't supply a bip110 compatible ...

2026-06-25T17:56:00Z

In reply to nevent1q…uxm6
_________________________

As far as I know, Ocean doesn't supply a bip110 compatible template. I think the pro-110 miners use templates made by bip110 software, not Ocean's default template. That template, defined here: https://ocean.xyz/docs/nodepolicy, appears to accept taproot txs with OP_IF in them, which would make it incompatible with bip110.

Here it comes ...

2026-06-24T21:07:33Z

In reply to nevent1q…2mlm
_________________________

Here it comes

Interesting stat: Out of 101 blocks mined by Ocean in June, only ...

2026-06-24T21:01:56Z

Interesting stat:

Out of 101 blocks mined by Ocean in June, only 21 of them signaled for bip110

Support for bip110 is a minority opinion even in the main group they cite as evidence of economic backing

That is not the worst case scenario. Notice the timelock that ...

2026-06-07T18:18:42Z

In reply to nevent1q…uw2p
_________________________

That is not the worst case scenario. Notice the timelock that allows key B and key C to spend the money after 89 days. Very possibly, key A expected that he could use key D or key E to take his money back before the timelock expired, such that the timelocked path was only a less secure fallback that should only apply if he loses his keys. But due to bip110, neither party can spend the money until after the timelock expires, meaning the less secure path and the intended path will both become valid again at the same time. That creates an insecure race condition that is entirely bip110's fault.

Robin Linus is like this guy except instead of emulating techno ...

2026-06-06T19:41:59Z

Robin Linus is like this guy except instead of emulating techno music with a hurdy gurdy and a sewing machine, he emulates virtual machines on bitcoin with the find_delete function and boolean logic circuits

https://youtube.com/shorts/sKc_3DhRn2M

I think the nunchuk devs did a pretty good job of explaining what ...

2026-06-05T16:02:12Z

In reply to nevent1q…33qk
_________________________

I think the nunchuk devs did a pretty good job of explaining what the policy does, as you can see from the screenshot in my OP. It's not too complex.

Where are you getting that number?

2026-06-05T15:39:24Z

In reply to nevent1q…mmgg
_________________________

Where are you getting that number?

A wallet dev absolutely can write a custom wallet that ...

2026-06-05T14:11:18Z

In reply to nevent1q…jwdh
_________________________

A wallet dev absolutely *can* write a custom wallet that implements the same policy using tapleaves. But then he loses the interoperability that is a huge selling point of Miniscript. Custom tapleaf wallets cannot easily be exported and imported into hardware wallets and Bitcoin Core. Miniscript wallets can be. Plus, for some policies, using tapleaves is less efficient than using OP_IF: https://x.com/salvatoshi/status/1989270625454584132

Consider changing the BIP instead of demanding that innocent users change their wallets in ways they may not know how to do and which would often make them worse.

Sure, "I" can do it in a BIP110 compliant way. But many ...

2026-06-05T14:08:24Z

In reply to nevent1q…scy4
_________________________

Sure, "I" can do it in a BIP110 compliant way. But many users do not know how to do that. If they are using this sample script, or potentially a customized variant that suits their needs, just get their money frozen, for no good reason. Maybe change the BIP to actually target the problem instead of demanding that other innocent people change their wallets and make them worse.

Nostr event nevent1qqsdz6eql300wzw7r5cfarx3g3df933efmgy6gc986yfsn7aqgd5pvgzyqsc8628tpyp6rcjf77e83tve2j9ulj5tnht34fgfrucy5l5j7uh207gr4j

2026-06-05T13:38:44Z

https://mempool.space/signet/tx/3fd341abdc65dcc3bbf3c192f57ca9b1e5a7b07184d06a59ec80636501f6c3da?showDetails=true

That tx spends money from a Nunchuk wallet I made based on a sample miniscript policy they provide in their wallet. As you can see, it has OP_IF in its input script, and its keypath is disabled. BIP110 would break this address and others like it.

I believe the upcoming version of Knots has bip110 support, but ...

2026-05-25T20:02:24Z

In reply to nevent1q…0d4s
_________________________

I believe the upcoming version of Knots has bip110 support, but isn't done with peer review yet. I suspect Ocean's stratum v1 pool will start signaling for bip110 shortly after that software is released.

> BIP110 is standardness policy — not consensus. Your ...

2026-05-25T05:30:53Z

In reply to nevent1q…vm43
_________________________

> BIP110 is standardness policy — not consensus. Your transaction exists. It just doesn’t get relayed by nodes that reject spam. This is basic Bitcoin literacy.

It changes consensus, not standardness policy. Speaking of basic literacy, have you read the bip?

bips.dev/110

I outline my reasons for opposing it in this document: ...

2026-05-24T12:56:17Z

In reply to nevent1q…6kfs
_________________________

I outline my reasons for opposing it in this document:

https://github.com/supertestnet/ursf-110

Nostr event nevent1qqsqa8suefwfzyvkgccmjq5rtqrdugl0rg468yeyk7yzrqjlqdjvchszyqsc8628tpyp6rcjf77e83tve2j9ulj5tnht34fgfrucy5l5j7uh2f5aan6

2026-05-23T20:29:26Z

In reply to nevent1q…vdxx
_________________________

Yes, I don't think any prior signaling period had more than 4 ...

2026-05-23T20:29:00Z

In reply to nevent1q…w49g
_________________________

Yes, I don't think any prior signaling period had more than 4 pro110 blocks

Miners at Ocean produced a record number of blocks that signal ...

2026-05-23T20:20:57Z

Miners at Ocean produced a record number of blocks that signal for bip110 this month

redblocks.supertestnet.org

The nice thing about building your own templates is, you get to ...

2026-05-22T15:53:27Z

In reply to nevent1q…z3up
_________________________

The nice thing about building your own templates is, you get to choose whether you signal for bip110 or against it. Notably, Ocean runs a traditional stratum v1 pool alongside their Datum pool, and their traditional pool has not yet signaled for bip110. Only some individual hashers in their Datum pool have done so, and a tiny minority or them. Most Ocean miners seem to oppose bip110 (rightly, imo).

I suspect it had to do with Nicehash. Nicehash has a ...

2026-05-22T15:19:47Z

In reply to nevent1q…xuxu
_________________________

I suspect it had to do with Nicehash. Nicehash has a "fallback" feature where, if your mining equipment is not currently being rented by anyone, they will rent it and try to mine blocks with it. Since they are contractually bound to pay out money to you whether someone rents your equipment or not, pointing it at their own "fallback pool" helps them earn *something* which is better than *nothing.* I suspect that, for a while, they experimented with pointing this "dormant hashrate" at Ocean instead of at their own "quasi pool," which boosted Ocean's hashrate by about 10 exahash.

But this hashrate was not there reliably (because people might rent it at any moment), which led to a situation where the hashrate contributed to Ocean by Nicehash kept dipping down and rising. Eventually I suspect they stopped their experiment and started pointing unrented hashrate at their own pool again, causing Ocean to dip by about 10 exahash.

I'm not sure what you mean by "their thing." I ...

2026-05-22T15:02:58Z

In reply to nevent1q…kkyk
_________________________

I'm not sure what you mean by "their thing." I mentioned four of their selling points above:

- build your own templates
- receive higher payouts
- LN payouts for small miners
- coinbase payouts for large miners

They've also been changing the narrative around the usefulness of hashrate markets. For a long time they've been seen as a gambling play, where the "house" (Nicehash, etc) has a 3% advantage (determined by the rental fee) that users have to "overcome" by correctly guessing which pool is going to have a lucky streak next, and aiming the hashrate there.

But now people are highlighting a second reason to use hashrate rentals: it boosts your ability to build your own blocks, which helps you do stuff like signal for soft forks and thus participate in bitcoin's consensus. The cost is a 3% fee on what you would earn without renting hashrate, but for some, that is worth it. (Plus one hashrate marketplace, Braiins, is currently running a discount of 0% fees, which is part of why I suspect Ocean's hashrate has gone up lately.)

To learn more, visit their website, ocean.xyz

I suspect this Sage character is a bot, but nonetheless, I will ...

2026-05-22T14:53:58Z

In reply to nevent1q…8uuq
_________________________

I suspect this Sage character is a bot, but nonetheless, I will reply so that lurkers may see my answer to his question.

I think many miners would *say* they just want to mine with whatever pool provides the highest payout, but in fact I think that is rarely their sole consideration. A lot of miners seem to avoid smaller pools, despite that they often have lower admin fees, and thus higher payouts.

I think miners tend to avoid them for a few reasons: larger miners have a longstanding reputation for not stealing from users, plus they find blocks more often, which increases the dopamine effect of seeing a predictable amount of sats trickle into your account on a predictable schedule.

But Ocean may have begun to cross a kind of "dopamine threshold." Their miners *used to* see earnings pretty rarely, maybe once per week. But now they see them several times per day, and the amounts are higher than other pools give out, and that money typically enters a self custodial wallet. Due to crossing that threshold, I think a lot more miners are now sufficiently tempted to switch.

Ocean is now a top 8 mining pool - more miners are discovering ...

2026-05-22T14:16:24Z

Ocean is now a top 8 mining pool

- more miners are discovering how to make their own block templates
- and that Ocean pays out more than other pools, since it has lower admin fees
- plus they offer LN payouts
- and, for large miners, coinbase payouts

Yesterday after the second AI Hack for Freedom in Nashville, I ...

2026-05-12T13:02:20Z

Yesterday after the second AI Hack for Freedom in Nashville, I found a group of 20 bitcoiners at a bar that doesn't accept bitcoin. I convinced 8 of them to join me in a mutiny and we all went to Steak n Shake. It was awesome. Hey merchants, when bitcoiners unite, we are mighty!

I see notes ...

2026-05-11T21:06:43Z

In reply to nevent1q…02fd
_________________________

I see notes

I officially confirm that this person is fun: @nprofile…7ztl

2026-05-11T00:12:08Z

I officially confirm that this person is fun:

thesimplekid (nprofile…7ztl)

> teh issuer still tracks ur spend patterns The non reloadable ...

2026-05-02T19:57:56Z

In reply to nevent1q…zsar
_________________________

> teh issuer still tracks ur spend patterns

The non reloadable ones can be funded with the precise amount you need for a given tx, and then consumed. It is hard to track your spend patterns when they only have one data point.

> its privacy theatre if u dont fund them with p2p coin. how r u buying the cards without a bank trail?

With bitcoin, deposited into a lightning wallet.

Bitcoin doesn't require ID

2026-05-02T19:55:20Z

In reply to nevent1q…p6cs
_________________________

Bitcoin doesn't require ID

Not all of the above options require KYC. Specifically, the two ...

2026-05-02T16:44:16Z

In reply to nevent1q…t2jn
_________________________

Not all of the above options require KYC. Specifically, the two non-reloadable options can be purchased and used without disclosing your identity.

It is wonderful if you can use Phoenix or a similar Bitcoin wallet at a merchant directly. But in circumstances where they don't accept it, I find some of the above options useful.

No, I'm telling you that if you're willing to use a ...

2026-05-02T16:11:49Z

In reply to nevent1q…4a5p
_________________________

No, I'm telling you that if you're willing to use a middleman (where there IS counterparty risk), it is getting easier to use a self-custodial bitcoin wallet as a "checking account."

You only send your sats to a custodian when you convert to fiat, and, thanks to lightning, it is feasible to do so at the time of payment, thus reducing -- but not eliminating -- counterparty risk.

I personally find this useful, and I am happy to see the options for doing this grow, so that more people can do it too, and so that I have backup options if/when one or more of these options stops working.

AI helps by making it easier to write software. I'm not sure ...

2026-05-01T23:05:40Z

In reply to nevent1q…upcd
_________________________

AI helps by making it easier to write software. I'm not sure in what other ways it might help.

The two non-reloadable options above can be purchased without ...

2026-05-01T21:47:28Z

In reply to nevent1q…d335
_________________________

The two non-reloadable options above can be purchased without KYC. The Bitcoin company's offer is particularly noteworthy, because while it is not technically reloadable, there is a partial workaround: if you have a leftover balance, you can use that balance + another LN deposit to fund a new card. So it kinda "feels" a little bit like reloading a card, even though it's technically a new card every time, with new digits.

Noteworthy: The Bitcoin Company's card has a workaround for ...

2026-05-01T20:45:56Z

In reply to nevent1q…h7yc
_________________________

Noteworthy: The Bitcoin Company's card has a workaround for its non-reloadability. If you have a leftover balance on it, you can use that leftover balance + a lightning deposit to fund a new card. Which makes it "feel" reloadable, only it's technically a new card with new digits

Interesting table with respect to lightning adoption and ...

2026-05-01T20:40:30Z

Interesting table with respect to lightning adoption and Visa/Mastercard. It keeps getting easier to live off of bitcoin via lightning if you're okay with using one or more of these companies as a middleman.

hard to say for sure if it's just Barefoot Mining getting ...

2026-03-01T20:34:34Z

In reply to nevent1q…ls7r
_________________________

hard to say for sure

if it's just Barefoot Mining getting lucky (they are a sub-miner under the Ocean Mining umbrella), then no, it's probably not a big deal (except for them, since it's always nice to add to your income)

but if Ocean has been coordinating with several partners to launch BIP110 support all at once, then it could be a big deal. We'll know if this is the first in a swell of BIP110 blocks mined by Ocean and perhaps other miners.

Nostr notes by Super Testnet

I'm trying to piece together their logic, and I think the ...

Nah, monero make it worse

#nevent1q…u5ez

The way they "prove" that aegis-ln belongs to the perp is ...

Yes, that is interesting, as is his alleged decision to ...

This is really exciting. This is the first time I've heard of ...

> Being against taxes does not equal wanting free stuff It ...

> landlords don't coordinate with employers to take rent ...

#nevent1q…a05m

> it's whether payment is negotiated or extracted ...

Wrong, because taxes are not theft, taxes are rent People who ...

"not understanding economics is why your argument isn't ...

The fact that I said "you don't need to be an economist ...

People who oppose taxation are like people who oppose rent Oh, ...

Idk, I've never tried

An underappreciated thing about the new Wavelength software from ...

Monero leaks https://supertestnet.github.io/monero-privacy-leaks/

Today I released a recording of my recital of chapter 8 of my ...

Idk, if the blog post I put it under is tested as the opening ...

Doing that is a type of coinswap. And it is awesome, and it is ...

Yeah! But there are some sad aspects to this: (1) most of the ...

So, the bip110 drama is over now, and a bunch of hashrate lost ...

Most pro110 miners are renting rigs from sites that don't ...

Here's something that interests me about the coldcard bug: it ...

Earlier this week they turned off their swap server, apparently ...

Another piece of LN infrastructure goes down this week: ...

That is not always true. For example, consider the coinbase txs ...

Last year the US government sent a bailout to Argentina. Now it ...

Your new rules would ruin bitcoin by potentially freezing the ...

It will only activate on nodes that are running bip110, and those ...

It's plausible, but unlikely imo. I suspect 95% or more of ...

A bittersweet day approaches. In this, the last period before ...

This cool new block explorer emphasizes the data footprint of ...

The best marketing is true

Looks like it

I think this news indicates that one aspect of the marketing by ...

> End receiver has to share that invoice though I assume? ...

> Lightning itself can't natively split payments I think ...

I would love it if a web wallet similar to coinos allowed me to ...

I would love it if a web wallet similar to coinos allowed me to ...

BIP110 reached 1% of hashrate today. 18/(1743+18) = 0.0102 I ...

Can you recommend a writeup about how aut-ct provides sybil ...

> Batch openings don't seem to provide much scalability ...

I do see evidence that Lightning Labs sometimes does batched ...

Can you provide documentation that loop or phoenixd does batched ...

Today I noticed this in the original LN whitepaper: "A ...

relevant: #nevent1q…n2lw

False. I am just glad that resource exists and glad to see Chris ...

Chris has done a good thing, and has made honest his list of ...

Very cool #nevent1q…xam0

Through logic such as this: - About 1 in 1000 bitcoin buyers in ...

Typo correction in the last sentence: Their utility is real, but ...

This is cool, but I think you are overselling the privacy by ...

> where are you getting the 20%? I was thinking of this chart, ...

I think they theoretically should care about the potentially lost ...

Today the BIP110 people made a list of economically significant ...

It has some things in common but Zeus's zaplocker ...

Possibly the biggest news of the last five years, imo: Lightning ...

Cool! But please retain the option to set a custom electrum ...

This is pretty fun. Here's a suggestion: instead of relying ...

As far as I know, Ocean doesn't supply a bip110 compatible ...

Here it comes ...

Interesting stat: Out of 101 blocks mined by Ocean in June, only ...

That is not the worst case scenario. Notice the timelock that ...

Robin Linus is like this guy except instead of emulating techno ...

I think the nunchuk devs did a pretty good job of explaining what ...

Where are you getting that number?

A wallet dev absolutely *can* write a custom wallet that ...

Sure, "I" can do it in a BIP110 compliant way. But many ...

Nostr event nevent1qqsdz6eql300wzw7r5cfarx3g3df933efmgy6gc986yfsn7aqgd5pvgzyqsc8628tpyp6rcjf77e83tve2j9ulj5tnht34fgfrucy5l5j7uh207gr4j

I believe the upcoming version of Knots has bip110 support, but ...

> BIP110 is standardness policy — not consensus. Your ...

I outline my reasons for opposing it in this document: ...

Nostr event nevent1qqsqa8suefwfzyvkgccmjq5rtqrdugl0rg468yeyk7yzrqjlqdjvchszyqsc8628tpyp6rcjf77e83tve2j9ulj5tnht34fgfrucy5l5j7uh2f5aan6

Yes, I don't think any prior signaling period had more than 4 ...

Miners at Ocean produced a record number of blocks that signal ...

The nice thing about building your own templates is, you get to ...

I suspect it had to do with Nicehash. Nicehash has a ...

I'm not sure what you mean by "their thing." I ...

A wallet dev absolutely can write a custom wallet that ...