Super Testnet

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.

2026-08-29 19:08:45 UTC

- reply

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

2026-08-18 22:02:21 UTC

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

2026-08-14 05:15:50 UTC

- reply

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

2026-08-13 23:02:12 UTC

- reply

Lovely! I'm interested in using it to enable comments on a website I run. Have you thought about how to handle that? It would be really cool if I could get like a script tag or similar and give it a unique parameter, then embed the script tag at the bottom of a webpage and it would automatically create a comments section (with support for threading) based on this software.

2026-08-13 22:49:28 UTC

- reply

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.

2026-08-13 17:52:49 UTC

- reply

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.

2026-08-13 17:39:22 UTC

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?

2026-08-08 18:48:23 UTC

- reply

Correct. There's also a few other possibilities: the pro110 miners might stop mining altogether, or they might activate a pow change and then withdraw their coins from the markets they are currently using, and probably a few others. But I suspect due a while they will continue to mine a separate bip110 chain and continue to pay for it with non110 coins

2026-08-08 17:02:41 UTC

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!

2026-08-06 19:36:04 UTC

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?

2026-08-05 21:52:50 UTC

- reply

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.

2026-08-05 21:47:04 UTC

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

2026-08-02 18:22:39 UTC

- reply

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.

2026-08-02 18:17:17 UTC

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
#nevent1q…sr37

2026-08-01 22:02:59 UTC

- reply

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.

2026-08-01 22:01:22 UTC

- reply

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.

2026-08-01 21:56:50 UTC

- reply

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.

2026-08-01 20:40:39 UTC

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.
https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/7f5a739bbeb78608453e2da1915d24cfd004e6d8a179776f054595096a948154.jpg

2026-08-01 00:01:30 UTC

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

2026-07-22 17:54:58 UTC

- reply

The best marketing is true

2026-07-17 19:06:56 UTC

- reply

Looks like it

2026-07-17 17:55:39 UTC

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

2026-07-17 04:19:07 UTC

- reply

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

2026-07-16 16:11:38 UTC

- reply

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

2026-07-09 22:00:36 UTC

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.

2026-07-09 21:55:08 UTC

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.

2026-07-09 20:02:57 UTC

BIP110 reached 1% of hashrate today. 18/(1743+18) = 0.0102
I recommend reviewing my URSF110 proposal: https://github.com/supertestnet/ursf-110
https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/3d42bf4991eabdb3db99430067f792ad4d25616d09c23b6aefc99843b855a4f3.jpg

2026-07-02 21:55:12 UTC

- reply

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

2026-07-01 04:13:04 UTC

- reply

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

2026-06-30 19:50:27 UTC

- reply

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.

2026-06-30 19:32:37 UTC

- reply

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

2026-06-30 19:24:15 UTC

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",

2026-06-30 19:09:40 UTC

- reply

relevant: #nevent1q…n2lw

2026-06-30 15:11:47 UTC

- reply

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

2026-06-29 01:17:39 UTC

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

2026-06-28 20:51:52 UTC

Very cool
#nevent1q…xam0

2026-06-28 19:35:54 UTC

- reply

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

2026-06-28 19:24:12 UTC

- reply

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.

2026-06-28 19:22:36 UTC

- reply

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."

2026-06-28 19:15:30 UTC

- reply

> where are you getting the 20%?
I was thinking of this chart, but I thought it said 17% and I was rounding up
https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/27646daf64b54be3209c79ea602c5d08aa19848bf86823c5111ff02816a8e772.jpg
Source: https://luke.dashjr.org/programs/bitcoin/files/charts/services.html

2026-06-28 16:57:44 UTC

- reply

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.

2026-06-28 04:08:54 UTC

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
https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/9a58914e00fb7025d6ca2b5cc446cd89f188608258ffbaa3b7cc93008da60730.jpg
https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/661ed60d47523a05271e957e7389e7653b0353e7292a1cd8bfb2375065a1b2cd.jpg

2026-06-27 04:00:07 UTC

- reply

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.

2026-06-26 23:00:45 UTC

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

2026-06-26 17:01:52 UTC

- reply

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.)

2026-06-26 06:05:09 UTC

- reply

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]
```

2026-06-25 17:56:00 UTC

- reply

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.

2026-06-24 21:07:33 UTC

- reply

Here it comes
https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/b9064fa164c5167e97d1b16fa0b88c43eb112c7884bf3e1a73175275af399b62.gif

2026-06-24 21:01:56 UTC

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

2026-06-07 18:18:42 UTC

- reply

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.

2026-06-06 19:41:59 UTC

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

2026-06-05 16:02:12 UTC

- reply

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.

2026-06-05 15:39:24 UTC

- reply

Where are you getting that number?

2026-06-05 14:11:18 UTC

- reply

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.

2026-06-05 14:08:24 UTC

- reply

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.

2026-06-05 13:38:44 UTC

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.
https://image.nostr.build/4ee4777c48d08b55b7f3ea2ce43820019e9c294b54c87bddb0c33ca12e7fc603.jpg
https://image.nostr.build/c9d331a74630fb63041277a8f9d961c0705b4cc526f808dc6ff93f30f8132a99.jpg

2026-05-25 20:02:24 UTC

- reply

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.

2026-05-25 05:30:53 UTC

- reply

> 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?
https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/9d9ec30f64d69e82b065344de316a34d49eb53de7075bed19c28e6398cc07d4e.jpg
bips.dev/110

2026-05-24 12:56:17 UTC

- reply

I outline my reasons for opposing it in this document:
https://github.com/supertestnet/ursf-110

2026-05-23 20:29:26 UTC

- reply

https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/78c8ecfa6c686f969b9223683943ec16f2be3ced8a10e6a3defe32657d17f50e.jpg

2026-05-23 20:29:00 UTC

- reply

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

2026-05-23 20:20:57 UTC

Miners at Ocean produced a record number of blocks that signal for bip110 this month
redblocks.supertestnet.org

2026-05-22 15:53:27 UTC

- reply

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).

2026-05-22 15:19:47 UTC

- reply

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.

2026-05-22 15:02:58 UTC

- reply

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

2026-05-22 14:53:58 UTC

- reply

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.

2026-05-22 14:16:24 UTC

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
https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/566bc84323983cf41b2fbec12117117e283ad9005f49e085dbb519743dab814a.jpg

2026-05-12 13:54:18 UTC

- reply

https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/016f5204c1bf2ad3547384b363030dad6d3ff6d3db1b26194ed52b540883540a.jpg

2026-05-12 13:02:20 UTC

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!

2026-05-11 21:06:43 UTC

- reply

I see notes https://npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s.blossom.band/1da3debd490ae546902fda1b77f6329d03c5a0649201982ea20a09e0fb717157.jpg

2026-05-11 00:12:08 UTC

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

2026-05-02 20:51:25 UTC

- reply

> if the wallet is custodial
I recommend using a self custodial wallet.
> even with phoenix teh issuer still maps the merchant to your IP
Phoenix supports tor so you can hide your IP. Also, with a physical merchant, you are typically at *their* IP address when you make your purchase.
> how do u handle the shipping address
It depends on where I am, since I travel a lot. There are lots of small businesses who offer "On Demand Package Receiving Services," which means you can specify their address as a shipping destination for packages, and then pay a per-use service fee when you pick up your package, with no monthly rate required. Sometimes I use those.
Consider looking for such a business in your local area and use them if they exist. If not, consider starting one in your local area, so that you can become your own customer as well as provide services to others.
If neither of those is an option for you, consider renting an airbnb for use as a shipping destination, or ask a friend or neighbor or place of employment if you can ship stuff to their address and then pick it up.

2026-05-02 19:57:56 UTC

- reply

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

2026-05-02 19:55:20 UTC

- reply

Bitcoin doesn't require ID

2026-05-02 16:44:16 UTC

- reply

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.

2026-05-02 16:11:49 UTC

- reply

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.

2026-05-01 23:05:40 UTC

- reply

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

2026-05-01 21:51:47 UTC

- reply

The one that comes closest is The Bitcoin Company. If you buy one of their Visa or Mastercard cards, not only is there no fee, you actually get a slight discount in the form of "sats back."
Plus, if you end up with a leftover balance on a Bitcoin Company card, you can use that leftover balance (with another LN deposit) to fund a new card. Which makes it very close to what Pay With Moon offered.
On a related note, Pay With Moon is back, but they now have a fee of 1% on every tx, minimum fee of $1. Which is terrible.

2026-05-01 21:47:28 UTC

- reply

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.

2026-04-01 04:21:29 UTC

- reply

> it’s not guaranteed. Nothing in Bitcoin is. That’s sovereignty.
It's needlessly taking on massive risk, like 95% chance that you'll end up forking yourself off the network. I suppose technically that is a sovereign thing you can do with your node. But I don't want to do that. Not doing that is sovereign too.
> That’s why lock-in isn’t until August 2026. The timeline exists precisely to give wallet devs runway.
Gee, how generous. "Make this bad change by August. If you won't do it, get lost, you AND your lost income!"
> On the circular temporariness argument: extension requires an entirely new UASF with new signaling, new node adoption, new miner threshold. That’s not the same political and social cost as the original.
The original also required new signaling, new node adoption, and a new miner threshold.
> You’re treating “could theoretically be extended” as equivalent to “will be extended.”
I disagree that it "will" be extended. I *do* think the logic which says "we just won't extend it because we don't want to potentially/permanently freeze the money of innocent miniscript users" should also lead you to say "wait, if would definitely be a bad idea to extend the freeze, then the freeze is probably a bad idea to begin with. So let's just not freeze their money in the first place."
> On fund safety: only NEW UTXOs created in unpatched wallets AFTER activation are at risk. Existing UTXOs — permanently exempt.
Yes. The first part is a significant problem.
> [It's] entirely avoidable by shipping the update
The update is a bad downgrade, and even if it was a good idea, the time frame is bad.
> Your strongest point remains the miniscript complexity. Acknowledged.
Then join me in opposing BIP110 until that is fixed.
> But “hard for wallets” is not the same as “bad for Bitcoin.”
BIP110 is "bad for Bitcoin." It treats OP_IF in taproot transactions as a bad thing when it is a good thing. OP_FALSE OP_IF is the bad thing. Do not throw the baby out with the bathwater.
> Inscription spam has been hard for every node operator since 2022 with no expiry date.
Agreed. But two wrongs do not make a right.

2026-04-01 02:01:58 UTC

- reply

> “Most nodes are apathetic” is an interesting reason to never activate anything. By that metric, no soft fork would ever pass.
I disagree. I think you can persuade nodes to support your cause. But setting a countdown before you've done that is foolhardy and likely to get you kicked off the network.
> The OP_IF restriction in BIP-110 applies specifically to Tapleaves in Taproot scripts
And it is a bad idea because miniscript uses that feature in a perfectly innocent way and there is no good reason to break it.
> It's temporary (one year, auto-expiry)
If bip110 fans think it's okay to do the partial ban now, then the same reasons that make them think so will probably make them think it's okay to extend the ban a year from now. Conversely, if they have reasons for thinking it would be bad to continue the ban next year, then just apply those reasons right now, and don't do the ban in the first place.
> The fix for affected wallets is splitting OP_IF branches into separate Tapleaves, which Taproot best practice already recommends
That is not always recommended. OP_IF is in taproot in part to retain a lot of compatibility with previously written scripts and compilers, including miniscript. Moreover, there are frequent occasions when it is more efficient to use OP_IF than it is to use another tapleaf. BIP110 acts as if OP_IF is a bad thing when in fact it is a good thing.
> Lightning unaffected. Multisig unaffected.
It is strange to list all the things that "aren't" affected instead of addressing the things that "are" affected. Miniscript. Nunchuk. Bitvault.
> Existing UTXOs [are] permanently exempt
Utxos received into affected wallets after BIP110 activates (*if* it activates) are not exempt. I'd be okay with BIP110 if it just exempts those potential future utxos too.

2026-03-29 04:55:49 UTC

Things are heating up. Blocks 1038 and 1250 in this epoch both signal for BIP110
https://redblocks.supertestnet.org
https://image.nostr.build/1cccb451f90550164207514be5ea72f8f364128a0964c55450831f7200ab3c48.jpg
https://image.nostr.build/209c77f8045def9f1d36efb4820583b7e246b378adb4fff0299b94f46f68f476.jpg

2026-03-28 18:00:40 UTC

If you're into macrofinance, this is interesting: $1 of USD has been worth over 160 JPY for over 24 hours. Usually, the Japanese government treats the 160 mark as a "red line," and within a few hours, they intervene by selling loads of USD. This time maybe they aren't doing that? https://image.nostr.build/a02bd4d44cada49d7616ad9ef99d7d8a3557f68b8cb4f2dd0dcf63f8ccbbc193.jpg

2026-03-28 16:13:29 UTC

A bip110 block was mined yesterday and few seemed to notice https://image.nostr.build/599b9eeec2f8fd19303da0e54bc65d0ae8ab9597cf6f351aeb2b5159ddf3f3aa.jpg https://image.nostr.build/0e25f0b8f2e625ca4be77414f181e0d2c7a350505422d709aa27bdad1d24c5b6.jpg https://image.nostr.build/61944d6411093d6a761f7a862e50f2cd8166ad3275d3be517f8d0d8ab8ca79c5.jpg

2026-03-27 19:36:33 UTC

- reply

I was about to say, "I don't think bitcoin's permissionless is a significant factor here," and then go into details about what people tell me they are using their agents to pay for, and how those things seem unlikely to result in declined payments on visa or mastercard. But then I thought of a counterexample that proves your point: VPNs. I hear people talk about automating their VPN use via agents (including by having agents purchase VPN plans for use by the agent itself). And in many countries, VPN use is so restricted that attempting to purchase VPN plans with a credit or debit card payments is in fact likely to result in a failed payment. So it might actually be easier to instruct an agent to pay for such a plan with bitcoin than with a credit or debit card, and which makes its permissionless an important feature for agents. So good job, you've changed my mind.

2026-03-27 18:04:45 UTC

I think it's funny when bitcoiners get excited about AI agents "adopting bitcoin"
It's your agent (in some sense, anyway) -- it does what you tell it to
We've moved on from getting excited when "other people" adopt bitcoin, now we get excited when "we ourselves" adopt bitcoin

2026-03-16 21:41:42 UTC

- reply

Yes, he is a magician called Michael Carbonaro and his gimmick is that he presents his magic tricks as if they were real products for sale in regular stores. Some of his tricks involve juicers with unlimited juice, impossibly packed "mini" versions of real products, a smart fridge that magically fills up with contents you select from a tablet, and many others.
In this one he presents a suit jackets, pants, and hanger that supposedly all pops put of a credit card sized package. (I didn’t show the hanger part, you can find the full trick on his youtube channel.) But it reminded me of how Ark packs many user funds into a single utxo, and how surprising it is that a user can "unpack" their funds from that one utxo.

2026-03-16 17:22:43 UTC

- reply

You don't zap people who use coinos?

2024-07-27 18:06:30 UTC

- reply

Meanwhile, in monero, the amount is encrypted but the fee isn't
Also, the sender publishes the recipient's address and the change address in plaintext
And he publishes a list of possible senders and a public proof that he is one of them https://image.nostr.build/7abb9c125fd8f3f3c0680de658285831f42272bd33195f72af1bfe4770b6e1e5.jpg