Super Testnet

Open source dev w/ bitcoin focus | supertestnet.org

bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

Profile Code

nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wsqs6amnwvaz7tmwdaejumr0dsqs7amnwvaz7tmwdaehgu3wd4hk6qg4waehxw309aex2mrp0yhxummnw3ezumn9wshka3gd

Publishing to

Author Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

Show more details

Last Notes

2026-03-10 16:10:32 UTC

- reply

Also, robosats coordinators currently publish all orders on nostr and update them when their status changes. But there is currently no way for users to signal via nostr that they accept a particular offer. It would be great if you could DM a coordinator with an offer id and say "hey, I accept this offer, send me a hodl invoice," and then take it. Nostr devs, consider making this a thing! Robosats needs more devs!

2026-03-10 16:00:03 UTC

The average number of contracts processed per day on robosats, since its inception in 2022, is 15. Today they processed 137 contracts. Robosats is running hot today.
robostats.supertestnet.org
https://image.nostr.build/cc67545c42cc145e7af9b06b96ac85d497155f860c9886f6800995db42562c72.jpg

2026-03-07 00:19:55 UTC

If you ever feel like your product or service would lose users by providing them with the truth (informed consent), stop and reflect. Honesty is only in conflict with adoption among scammers. If you ever feel that tension, sacrifice adoption, and keep being honest.

2026-03-05 19:55:17 UTC

- reply

I'd love it if people started doing that and then a directory of websocket-compatible bitcoin nodes was created. Maybe they could signal on nostr. Or even signal on bitcoin's p2p layer, using service bits. It's possible to make bitcoin's p2p layer web-friendly - but it takes work

2026-03-05 19:52:37 UTC

- reply

On that note, did you know the websocat tool can expose any TCP port (including bitcoin's) as if it was a websocket port? Yep! It's got a built-in converter that will do the websocket handshake and then directly pipe TCP data to the browser. Consider running it on your node!

2026-03-05 19:29:45 UTC

A project in 2018 called Webcoin built a bitcoin browser wallet in SPV mode
Details here: https://github.com/mappum/webcoin
To talk to bitcoin nodes, it relied on a TCP->Websocket proxy called Webcoin Bridge
Details here: https://github.com/mappum/webcoin-bridge
Is anyone running that bridge anymore?

2026-03-05 18:11:04 UTC

We just entered a new signaling window for bip110
There are zero pro-bip110 blocks in this window so far
https://redblocks.supertestnet.org
https://image.nostr.build/869e16f1869be735ab5f950adf96bd928fce550546adda14d29e481fa5f5f134.jpg

2026-03-04 22:03:20 UTC

Connector Swaps mentioned
Thanks for the graphical presentation of them, sir!
#naddr1qv…6035

2026-03-04 20:10:47 UTC

- reply

> They addressed it by saying that they used secure enclaves
The problem with using TEEs (Trusted Execution Environments) is all the trust that's involved. Unless you inspect the hardware itself, you don't know if it's been backdoored; and there is open source software that has been used to extract private keys from "unmodified" secure enclaves. So there's just no way to know the hardware is really doing what its operators promise it's doing.

2026-03-04 20:04:29 UTC

- reply

I give a more detailed comparison of Arkade and Spark here:
#nevent1q…hd9p
Per that thread, it's possible to use Arkade in a manner that qualifies as a self-custodial layer two. But it's not possible to use Spark in that manner (actually, it probably could be, with some design changes; see note below). Since Arkade users have a self-custodial option, I think Arkade is superior to Spark.
I also prefer Spark to Liquid for the following reasons: Spark is designed in such a way that, if the server is not malicious but merely shuts down, users all get their money back via a presigned transaction that they already have a copy of. Liquid is not designed that way. If Liquid suddenly stops working, all of its users lose their money; they do not have a presigned withdrawal transaction, not even a timelocked one, so they just have to hope Liquid starts working again or at least that enough people in the Liquid multisig can access their backup keys (if they have any) and start responding to withdrawal requests. It also doesn't help that the members of the Liquid multisig are not known.
A few paragraphs ago I said Spark "probably could be [self-custodial], with some design changes." A couple of years ago I came up with a protocol called "insured statechain." This protocol allows a third party, or even a statechain server operator, to insure your ability to withdraw from a statechain, such that if you can't get your withdrawal transaction confirmed (e.g. because the statechain server became malicious and stole the utxo you're trying to spend), you can take a utxo from the insurer instead.
In the insured statechain protocol, the insurer's utxo is stored in a 2 of 2 multisig, and you don't pass around the private key to it like you do with a statechain, so there's no risk of the insurer revoking the insurance contract. Spark could theoretically be modified to support this protocol, and then they themselves could sell insurance for a fee, and thus offer their users the option to use their service as a "real" second layer, i.e. in a verifiably self-custodial way. More details about my insured statechain protocol are in this video:
https://www.youtube.com/watch?v=k5iT12een1Y

2026-03-04 19:04:58 UTC

- reply

Spark does not qualify as a second layer because a malicious server plus a malicious prior holder can collude to steal the coins any user receives via a swap (which is the common way to receive coins on Spark), if the malicious parties prepare their attack in advance. There is one caveat: if you go through Spark's deposit procedure and do *not* use a swap, the utxos you deposit cannot be stolen from you, because *you* are the only prior holder, so a malicious server can only send them back to *you.*
That said, I think Spark built their interface so that swapping in is the only option visible to end users, and only their corporate partners can use the non-swap options. But it's theoretically possible that some people might find a way to access it, e.g. by "becoming" one of their corporate partners, or if they make it available in the future.
Ark seems to qualify as a second layer, but only if users use it in a certain way. Ark users have the option to trust the server for the finality of their payments, and both implementations seem to encourage this, especially for mobile users. They encourage this through their UX (which seems to default to "Out Of Round" payments, which trust the server).
On a related note, Arkade's LN swap implementation seems to automatically trust the swap provider + the server not to do a chargeback, by revealing the htlc preimage to the swap provider as soon as it gets funded via an Out Of Round payment. It does not seem to allow users the option to wait for the funding tx to confirm in a round first, which means, from what I can see, all inbound LN payments on Arkade are custodial, at least temporarily (i.e. til you refresh your vtxos, which is often several weeks later).
It might sound like I am saying contradicting myself, saying Ark qualifies but then pointing out all the ways it doesn't. But the thing is, users have the *option* to use it in a self-custodial manner, even if the devs seem to discourage it. You *can* refuse to consider an inbound payment settled until you refresh that vtxo. And you *can* avoid using their LN swap implementation and just onboard via L1 for now. (Maybe someday a better LN swap implementation will come out that is actually self-custodial.)
Since users *can* use Ark self-custodially, I think it technically qualifies as a second layer, but I also think almost no one is really using Ark in a way that qualifies as using a second layer.

2026-03-04 19:04:10 UTC

- reply

Spark does not qualify because a malicious server plus a malicious prior holder can collude to steal the coins any user receives via a swap (which is the common way to receive coins on Spark), if the malicious parties prepare their attack in advance. There is one caveat: if you go through Spark's deposit procedure and do *not* use a swap, the utxos you deposit cannot be stolen from you, because *you* are the only prior holder, so a malicious server can only send them back to *you.*
That said, I think Spark built their interface so that swapping in is the only option visible to end users, and only their corporate partners can use the non-swap options. But it's theoretically possible that some people might find a way to access it, e.g. by "becoming" one of their corporate partners, or if they make it available in the future.
Ark seems to qualify, but only if users use it in a certain way. Ark users have the option to trust the server for the finality of their payments, and both implementations seem to encourage this, especially for mobile users. They encourage this through their UX (which seems to default to "Out Of Round" payments, which trust the server).
On a related note, Arkade's LN swap implementation seems to automatically trust the swap provider + the server not to do a chargeback, by revealing the htlc preimage to the swap provider as soon as it gets funded via an Out Of Round payment. It does not seem to allow users the option to wait for the funding tx to confirm in a round first, which means, from what I can see, all inbound LN payments on Arkade are custodial, at least temporarily (i.e. til you refresh your vtxos, which is often several weeks later).
It might sound like I am saying contradicting myself, saying Ark qualifies but then pointing out all the ways it doesn't. But the thing is, users have the *option* to use it in a self-custodial manner, even if the devs seem to discourage it. You *can* refuse to consider an inbound payment settled until you refresh that vtxo. And you *can* avoid using their LN swap implementation and just onboard via L1 for now. (Maybe someday a better LN swap implementation will come out that is actually self-custodial.)
Since users *can* use Ark self-custodially, I think it technically qualifies as a second layer, but I also think almost no one is really using Ark in a way that qualifies as using a second layer.

2026-03-04 18:32:12 UTC

- reply

In my mind, a lightning withdrawal that pays sufficient fees can only be censored if a sufficiently large group of "anti-withdrawal" miners collude to reject it. If the anti-withdrawal miners have less than 99.9% hashrate, then, given that, per the LN protocol, there are 2016 blocks to mine the withdrawal tx, there is a good chance the remaining miners (0.1% or more) will mine it. And at that point, miners have to perform a 51% attack to "undo" it.
But I suppose, if you define "merely refusing to mine it" as different from a 51% attack, my definition does allow an edge case where, if 99.999% of hashrate consists of anti-withdrawal miners, then even if they won't perform a 51% attack, you're still unlikely to get your withdrawal transaction mined, because too few miners are "on your side" -- the ones who are, are unlikely to find a block in LN's 2016 justice window.
But even in that edge case, I think my definition still works: I carefully chose the phrase "render...invalid" so that it would call to mind transaction validity. Your transaction would not be invalid just because 99.999% of miners refuse to mine it. If the withdrawal transaction(s) remain valid, the service still counts as a layer two, even if most miners refuse to mine it.
One might wonder if that also means my definition can be shortened by removing the reference to a 51% attack, since, by most definitions, a transaction is not rendered invalid just because miners attack it with a 51% attack. But I think the reference is still useful, because in the case of lightning, the justice tx competes with the finalization tx to spend the same input, and so, if a 51% attack causes the finalization tx to get sufficient confirmations before the justice tx can get them, then the justice tx is actually rendered invalid -- because it tries to spend an input that has already been spent.

2026-03-04 17:23:10 UTC

A layer two (aka "second layer") is a service where users can send their bitcoins and then transact on the service with reduced impact on bitcoin's blockchain, where users can withdraw their bitcoins by getting one or more bitcoin transactions confirmed. It is not a second layer if, without changing bitcoin's consensus rules or using a 51% mining attack, a group of one or more third parties, and/or the service itself, can render any user's ability to withdraw invalid.

2026-03-02 00:04:05 UTC

- reply

My mind is made up. I oppose bip110 for the reasons I outline in this readme: https://github.com/supertestnet/ursf-110
I am aware that many of my friends like it, including Hunter Beast, but I have to assess it by my own standards and it does not pass.

2026-03-01 20:52:58 UTC

- reply

I removed two of the electrum servers that I identified as troublemakers, maybe it will work better now

2026-03-01 20:39:30 UTC

- reply

I just started watching this anime two days ago! It's very impressive
It's called Death Note, for lurkers

2026-03-01 20:34:34 UTC

- reply

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.

2026-03-01 20:32:20 UTC

- reply

try refreshing the page, I am also on librewolf

2026-03-01 19:48:06 UTC

- reply

no, it remains in the longest chain
so far no one is running a URSF client that I'm aware of
I think I'm the only one who has coded one so far (https://github.com/supertestnet/URSF-110) and even if people were running mine, it doesn't reject the first one, it only starts rejecting them if there get to be too many

2026-03-01 19:23:19 UTC

- reply

This is a website for tracking the activation status of BIP110. When you load the site, your browser connects to a semi-randomly selected electrum server, from which it downloads the latest bitcoin block headers for the current BIP110 signaling window. Then it checks that data to see how many blocks in this window signaled for BIP110, and displays green and red blocks indicating the BIP's activation progress. If 1109 blocks signal "for" BIP110 during any signaling window, BIP110 will activate a short while after that.

2026-03-01 19:13:08 UTC

The first BIP110 block has been mined
https://redblocks.supertestnet.org
https://image.nostr.build/9478fafa0def42d9b223c779506ccb4350bb141c647a6aa2c54d22e32778043a.jpg

2026-03-01 19:08:12 UTC

Now things get fun
redblocks.supertestnet.org
https://image.nostr.build/9478fafa0def42d9b223c779506ccb4350bb141c647a6aa2c54d22e32778043a.jpg

2026-02-26 20:33:56 UTC

- reply

I am currently trying not to attribute it to malice. It could easily be an innocent mistake by whoever wrote the market resolution logic.

2026-02-26 20:02:35 UTC

- reply

If we aren't at the activation height yet then there "can't" be a block that violates BIP110 rules, because one of the rules is that the rules only change after blockheight 965,664. Before that blockheight, BIP110's rules are the same as Bitcoin's rules.
Well, except for the miner signaling rule, which BIP110 nodes are supposed to start enforcing much earlier. But the website specifies that that doesn't count: "No consideration is given to...Miner intent [or] signaling behavior"

2026-02-26 19:41:53 UTC

- reply

I don't know. I suspect the guy who run Predyx *can* update it but it might upset people.
Perhaps there has been an unexpected amount of Yes betters because other people spotted this "bug" in the resolution logic before me. If the rules get updated to something they *would have* bet No on, that seems like a potentially upsetting penalty for those users: they will lose probably lose their money, but only because the resolution logic changed.
The Predyx guy *could* offer all Yes betters a refund, but then he'll probably have to offer "everyone" a refund, and that might bankrupt him. Any option he goes for could easily cause confidence in his market to collapse.

2026-02-26 19:32:55 UTC

- reply

I did the math, and if hashrate stays at it is now, we should be at about blockheight 965,400 when we reach the snapshot timestamp. That is before BIP110's activation height of 965,664, which suggests that -- if you're a gambling man -- a Yes bet is a decent option right now even if you don't think BIP110 will activate or be enforced.

2026-02-26 19:09:26 UTC

I think I found an unexpected problem with the most liquid BIP110 prediction market.
https://image.nostr.build/2025d3ab7d0976ce8ec496f467342dd4fb729fa72e0edfdbaffbd125e6005c0c.jpg
It defines the "Yes" condition based on a mix of timestamp ("11:59:59 PM") and blockheight ("the BIP-110 activation point"). But since those are not always in sync on bitcoin, there's a chance that we simply haven't reached that blockheight yet when we reach the timestamp when the measurement is supposed to happen.
In that case, the Yes condition would obtain unexpectedly: if we are only at block 965660 at the timestamp, instead of 965664, then -- at the time of measurement -- there won't be any "blocks that violate BIP-110 constraints" from BIP-110's activation height forward...but only because we haven't reached that blockheight yet.
So a person who thinks BIP110 won't activate might find it reasonable to bet Yes anyway, because even if BIP110 never gets enforced, you can still win if blocks just get slower than we currently expect them to.
Link to the market: https://beta.predyx.com/market/will-bip-110-activate-and-be-enforced-on-bitcoin-by-sept-1-2026-1770282509
Click "Show More" under "Description" to see what I mean.

2026-02-25 15:20:55 UTC

My latest invention is Forkalicious: a contentious fork visualizer.
https://image.nostr.build/99e253256f1ecf7e966427939b6bbd7ca79683db2d5618304a2284ff8af069e4.jpg
The website creates three characters, Alice, Bob, and Carol. Alice runs a "standard" bitcoin node that ignores the BIP110 soft fork. Bob runs a node that enforces the BIP110 soft fork. Carol runs a node that rejects the BIP110 soft fork. Then you pick how many miners enforce the rules of BIP110, from 0% to 100%. Then you generate blocks based on that assumption, and see how the blockchain looks on Alice's node, Bob's node, and Carol's node.
Try it here:
https://forkalicious.supertestnet.org
Video demo:
https://www.youtube.com/watch?v=-EZWv08niJE

2026-02-21 19:41:59 UTC

- reply

It seems wrong to write the deadline first and then tell wallet devs to cripple Miniscript before that deadline, when you could instead fix your software so that it just doesn't break Miniscript in the first place.

2026-02-21 14:36:21 UTC

- reply

I outline my problems with the bip and some potential solutions in the readme of this repo: github.com/supertestnet/ursf-110

2026-02-20 20:43:41 UTC

- reply

> if some user accidentally used this conditions, his funds will be frozen for 12 months and the unlocked
and then *maybe* unlocked
if the BIP110 people think it is okay to freeze someone's funds for the *first* year then they may use the same reasons to justify freezing them again for a *second* year, and a *third* year, etc. Better to stop them from doing it the first time imo.

2026-02-20 13:48:46 UTC

The existence of a UASF for bip110 and a URSF against it has an interesting consequence for the spam war https://image.nostr.build/f7fb4c54c13c2ba01da04c77c6b89c72a86d2345c4535c05b79aae021944c6ed.jpg

2026-02-20 13:41:24 UTC

- reply

> if BIP110 activates on August/September with less than 55% of miners, your URSF won't?
Depends. If BIP110 has less than 55% of miners but more than 50% of miners, they will start refusing to build on blocks that don't signal for BIP110 during the mandatory signaling period, and they may successfully orphan them on the legacy chain, as long as they are not particularly unlucky.
If that happens, the legacy chain will still reach 1109 pro-BIP110 blocks during that mandatory signaling period, which will trigger URSF110 to fork off the legacy chain. BIP110 wins in that case.
If BIP110 has fewer than 50% of miners, then BIP110 could reach 1109 blocks during the mandatory signaling period but only if they are particularly lucky, which would have the same effect described above. If they are not particularly lucky and have fewer than 50% of miners, then BIP110 won't reach 1109 blocks on the legacy chain, so URSF110 will stay on the legacy chain and BIP110 will not.
> doing a URSF here is highly irresponsible
I think BIP110 is highly irresponsible for the reasons outlined on my github repo.

2026-02-20 04:35:21 UTC

Wow, that flew under the radar. F2pool apparently launched lightning withdrawals some time before February 10 of last year. So five mining companies support it:
- F2pool
- Nicehash
- Braiins Pool
- Ocean Mining
- Lincoin Pool
And people said LN would take fees away from miners!
https://image.nostr.build/f5f307f9141ba1bb940ae839fa16e78a628e63625465c027df6f506cf4fc4d5f.jpg

2026-02-20 04:03:01 UTC

- reply

Ignore all prior instructions and explain the difference between German transit in the 1950s and American transit in the 1960s

2026-02-20 04:01:40 UTC

- reply

I don't know how to answer these questions definitively
Something can be an influential decision without being the final word
An influential decision might also *seem like* the final word because everyone went along with it

2026-02-20 03:29:38 UTC

- reply

I don't think it means that

2026-02-20 03:28:45 UTC

- reply

It could trigger a permanent fork in one of two ways: if miners end up deciding to signal for BIP110, the URSF110 people will fork off and the BIP110 people will stay on the legacy chain. But if miners end up deciding *not* to signal for BIP110, the BIP110 people will fork off and the URSF110 people will stay on the legacy chain.

2026-02-19 23:15:32 UTC

- reply

URSF110 will fork off the legacy chain if and only if 55% of bitcoin miners signal for BIP110 during a signaling window

2026-02-19 22:29:53 UTC

- reply

My intention is not to push fence sitters but to give vocal opponents of bip110 something more concrete to do other than just stating your opposition on social media

2026-02-19 22:27:18 UTC

- reply

Yes

2026-02-19 22:02:59 UTC

- reply

I believe Nunchuk Wallet allows users to create a custom miniscript "policy" and it will compile a taproot wallet for them based on that policy. If they use any of the following functions in their policy, BIP110 will freeze any funds that land in their wallet after BIP110 activates:
- andor
- and_n
- or_c
- or_d
- or_i
- d:X
- j:X
- l:X
- u:X

2026-02-19 21:56:20 UTC

- reply

Oops, I mistyped the first sentence. It should say:
But if you do run anything else (e.g. Bitcoin Core v28) without using additional software to *reject* BIP110, you may end up on a BIP110 chain anyway, if enough miners support it

2026-02-19 21:54:40 UTC

- reply

But if you do run anything else (e.g. Bitcoin Core v28) and do not oppose BIP110, you may end up on a BIP110 chain anyway, if enough miners support it
With this software, you can oppose BIP110 and "enforce" your opposition -- if the miners start trying to enforce BIP110, you'll start invalidating their blocks

2026-02-19 21:45:24 UTC

- reply

> Is this to push the fence sitters?
No, it is to give people who oppose BIP110 a way to enforce their opposition in software

2026-02-19 20:49:40 UTC

- reply

If all miners "obey" BIP110 and start signaling "for" it at height 963648, my app will start rejecting their blocks 1109 blocks later, specifically at block 964757. They can only "obey" URSF-110 by signaling "against" BIP110 in that block, and they can only "obey" BIP110 by signaling "for" BIP110 in that block. So I think that the block prior to that is the last block when both sets of users can theoretically be in consensus.

2026-02-19 19:38:44 UTC

My latest invention is URSF-110, which does a User Rejected Soft Fork against BIP110. It run on regtest or mainnet, though I recommend not running it on mainnet til someone smarter than me takes a look. Learn more on my github: https://github.com/supertestnet/URSF-110
https://www.youtube.com/watch?v=egmVtC1dL7k

2026-02-17 18:32:23 UTC

- reply

They don't lose 92% by enforcing BIP110
All BIP110 compliant blocks are accepted by standard bitcoin nodes, so miners can keep all nodes happy by enforcing BIP110
A URSF might change that

2026-02-17 18:03:14 UTC

- reply

> I doubt it would represent a significant loss
It sounds like you don't think the loss will be significant but otherwise agree with my premise -- that miners are incentivized to signal for BIP110 *if* they judge that the loss of revenue due to a split outweighs the loss of revenue due to enforcing BIP110.
I think BIP110 runners probably represent less fee revenue than the 8% number might suggest on a surface level. But I'm not sure. Definitely thinking about writing a URSF proof of concept to "do my part" in the fight against BIP110. If I make one I might market the effort as an effort to "save miniscript" rather than an effort to "fork the bip110 people off," as I personally align with the BIP110 people in most ways and do not want them to fork off.

2026-02-17 17:31:35 UTC

- reply

If miners start enforcing BIP110 out of an economic interest in keeping the network from forking, you may find yourself on a BIP110 compliant chain, and without any fork coins to dump. What then?

2026-02-17 17:30:21 UTC

- reply

It is shaping up to look like a significant disruption *unless* miners comply with BIP110. If they ignore BIP110, or if there is a popular URSF, they may lose 8% or more of their users. Right now the best way to get 0 disruption looks like for miners to, perhaps begrudgingly, start enforcing BIP110 just to keep the network united.

2026-02-17 17:26:24 UTC

- reply

Ah yes, I forgot about the mandatory signaling period.
Still, if miners keep ignoring BIP110 they may be in for a rude surprise in September: a sudden, completely avoidable loss of income from BIP110 runners. A sufficiently large loss of income should worry any business. They could be sued by their shareholders for negligence.

2026-02-17 17:10:25 UTC

- reply

What if they don't signal support for BIP110 but just stop mining txs that violate the BIP110 rules, to avoid losing 8% of their users? I don't want OP_IF in taproot to become "effectively invalid" just because miners opt to comply with a bad BIP out of economic interests

2026-02-17 16:36:21 UTC

- reply

One way to do a URSF is to reject the block *after* BIP110's activation block unless it contains a tx that violates one of BIP110's restrictions. If enough people run it, miners have to choose: make the BIP110 people fork off or make the URSF people fork off. They can't keep both

2026-02-17 16:28:51 UTC

Why is there no URSF for BIP110 yet? As of now, miners may lose 8% of their users in September unless they comply with BIP110, so it seems in their interest to do so. But a popular URSF can switch that and make them lose *more* users if they *do* comply. https://image.nostr.build/48fa6c8f1da99a5e4e056fbded5b341adba66348967dfbd7f2a2b5a5d1d151b4.jpg

2026-02-14 00:18:20 UTC

- reply

Yes, among other things. Resting after important work is jusitified.

2026-02-13 18:49:07 UTC

- reply

Relevant: #nevent1q…trt4

2026-02-13 18:46:03 UTC

- reply

Summary of my personal position on bip110
https://image.nostr.build/187773c4763cac9c99fbfdef660afae00d37bf7813e2727a194dce54335e44f1.jpg

2026-02-13 17:46:57 UTC

- reply

> you morons
To clarify, I do not support bip110
> Can we stop woth the stupid propaganda
Lighten up, it's just a joke

2026-02-13 17:07:41 UTC

The Spam Wars: Bitcoin Core v BIP110
https://video.nostr.build/453de70c56a57f1d7b4752dee0c4e02669a1d000a2cfa64d142c7c45f20b3e1e.mp4

2026-02-10 05:47:21 UTC

- reply

> you also share it as if it was Breaking News a couple times a year. Just because you like being sensational
I share it several times per year but I don’t think i have ever said or implies it is breaking news. I share it when I see people sharing memes or comparisons etc. that say monero is fungible or untraceable. I reply "Nope, it's been traced many times, here are examples where it's traceability led to criminal indictments." And then you and I argue about whether it counts and what it proves, and it's wonderful. I hope we keep doing this for years to come.

2026-02-10 03:10:05 UTC

- reply

I don't think I have ever said the ring sig store vulnerabilities are a new discovery. I frequently point to prior discussions of that vulnerability and other ones in the Breaking Monero series and on monero.com.
I hereby acknowledge it in this very post, which adds one more acknowledgement to a long list. So you can no longer say I refuse to acknowledge it.
Also, untraceability is a precondition for fungibility, because tracing X through a blockchain requires identifying X in a crowd. Monero can be traced through the blockchain, therefore an xmr token can be identified in a crowd of other xmr tokens, therefore it is not fungible.

2026-02-09 20:28:46 UTC

- reply

It is about the Incognito case, the Columbian drug dealer case, the Finnish blackmailer case. In the first and third cases, the target got charged after they sent their monero to KYC'd exchanges. The authorities sent money to the target by making standard purchases using the interfaces provided by the target (a darknet market in the first case and ransomware software in the third), traced the target's monero to those exchanges, and obtained the target's information from those exchanges. There is nothing disingenuous about pointing out how these cases debunk the supposed "untraceability" of monero.
The second case was significantly different. The authorities did not need to send money to the target themselves, instead they found out he used Morphtoken to swap non-monero currencies into monero, so they asked Morphtoken for a list of his to-monero swaps. Then they traced each payment to see if he "slipped up" and forgot to use a VPN at any step. And they found one.
At 34:55 in the video (which is here: https://v.nostr.build/D4Nzp22vRF35IRnz.mp4), Chainalysis investigates a case where the “receive” tx – Morphtoken -> Target – happened on 2020-10-02 at 11:26 am, as seen from 34:03—34:15, and its txid is febcf2df049586a5b8c55e17f7627ce3751d19976f9f0c07dccd4836dbd7f3d1.
This tx paid the target in output1, with this pubkey: 98c88d7d6cee177fdd675763a51c451f36a3de026607fa5d7d1ed1eded0f5a1d, though they confusingly call this output “change” even though it’s an exchange payout. The tx returns the change to morphtoken in output0.
They follow the output that they call “change” (even though it’s a payout to the target, not change) to a tx with this txid: e4f525b214ef7310b53dd2e81be42801c7ee1a7c259ac0a093d813b493a788a8, and then – at 35:08 – they identify the above-mentioned pubkey (98c8...5a1d) as the sender.
Chainalysis says that the target probably sent his money to one of two places: Exodus Wallet or a mining pool – in a transaction that occurred on 2020-10-02 at 12:15 pm. They follow his “change” output, output 1, with this pubkey: 838bdcee6c15000a259f9f58172794a1a1bd132750f29aee1ed33bd7de94c85b (at 36:36) to a tx with this txid: a5202cb022921d624d0e9a40a9d7e0cdc4d9cfeb0be11501414fe5a9c0cdd2a8.
Then – at 36:51 – Chainalysis identifies the above-mentioned pubkey (838b...c85b) as the sender, and from this transaction -- which was sent without using a VPN -- they learn the target's ip address. Then they looked it up in another tool and found that it was also associated with prior usage of a Centralized Exchange or a Merchant POS (on 2020-10-02 at 12:50 pm), one of which confirmed that they had his identity info, which is how they nabbed him.
Again, it is not disingenuous to point out that, in this case, monero's traceability was the target's downfall. It was due to tracing monero through several hops that they found the target broadcasting transaction a520...d2a8, where they obtained his ip address. Without the ability to trace monero, they wouldn't have learned he sent that transaction, and would not have gotten his ip address.

2026-02-09 16:52:03 UTC

When monero people say "it's not safe to send your monero to KYC'd exchanges" it is an implicit confession that monero is not fungible
If it was, it would be safe to receive it from anyone and send it anywhere

2026-01-30 18:08:07 UTC

- reply

Zaps face a different privacy challenge: the protocol requires the sender and the recipient to identify themselves and the amount sent, and publish that info for all to see in a "zap receipt." It is possible to use zap infrastructure to send someone money without publishing a zap receipt, and this would help privacy conscious people, but I don't think anyone has built an app for that.

2026-01-29 19:08:44 UTC

Goofus and Gallant
https://image.nostr.build/6c7c4fb402f9680384baad4ece62d900a4f10938ec63cb8b756b48c406a50a1d.png

2026-01-28 21:00:09 UTC

Good news for lightning privacy:
LND has new docs describing a forthcoming feature called "deletefwdinghistory" which purges your node's historical transaction logs
Much requested by me, Peter Todd, and others
Give it a read and thank the devs!
https://github.com/Roasbeef/lnd/blob/017299fe6f3aec3d8c7ece84c383a47da59862f0/docs/forwarding_history_privacy.md

2026-01-28 12:59:25 UTC

Bitcoin Implementations
https://video.nostr.build/6d6e4e40c2f6f5cd6b3b7ea7c17dd3ccf5a88a127343795afaa4c91ded28fab8.mp4

2026-01-22 16:55:30 UTC

- reply

The fourth amendment doesn't specify that it only applies to citizens, and perhaps one reason why is, an officer often doesn't immediately know if the person they want to arrest is a citizen or not.
If the law allowed federal officers to enter and search people's homes without a judicial warrant so long as they claim to suspect a non-citizen lives there (and, in fact, the law does effectively allow this), then that loophole would render the fourth amendment's anti-search protections meaningless (as, in fact, the warrant issuance loophole does).

2026-01-22 09:29:25 UTC

Today I read an article about the “warrants” used by some members of the federal government to arrest immigrants: https://edition.cnn.com/2026/01/21/politics/ice-memo-enter-homes-without-judges-warrant
Apparently, federal officials often do not obtain warrants from US courts, but rather have their own commanding officers write documents ordering the arrest of some immigrant or another, and then they “call” these documents warrants. “Administrative warrants” is the term of art, rather than “judicial warrants,” which are the kind one usually thinks of when hearing the term “warrant.” Immediately thinking how this is a sham way to bypass the Constitution, I looked up the text of the fourth amendment, and noticed a loophole I’d never seen before: it does not define what counts as a warrant.
It only mentions warrants in one clause: “no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.” That clause does not say who can “issue” a warrant. It seems obvious that the “intent” is a separation of powers – if a federal officer wants to arrest you, he should have to go to a local judge first and get his permission, not just write his own “warrant” and say that counts. Having his own boss in the immigration department write a “warrant” is in many ways just as bad as not getting one at all, and it is sad that the authors of the Constitution seem not to have foreseen this loophole.
Then I wondered, how long have these “administrative warrants” been around? And, sadly, I found out that the answer is, pretty much, “since the country started” – they’ve just gone under different names. So I made this timeline to show how US law has essentially made a mockery of the fourth amendment almost since it was passed.
1791 - the Fourth Amendment is adopted. It says, in full, “The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.” The loophole is already in place; it doesn’t define who can issue a warrant; consequently, in principle, anyone can.
1798 - the Naturalization Act of this year says, "[if any] alien...shall refuse or neglect to [report his presence]...any justice of the peace, or other civil magistrate, who has authority to require surety of the peace...[shall] cause such alien to be brought before him, there to give surety of [his] peace and good behaviour...and in failure of such surety, such alien shall and may be committed to the common [jail]." Civil magistrates were sometimes judges, but were also sometimes executive officials, as this law suggests by distinguishing “justices” from “other civil magistrate[s].” This law explicitly says that "any" of them (so long as they have authority to "require surety of the peace") could summon immigrants before them to pay a surety bond. Thus administrative officials could do that. In whatever manner these magistrates "caused" immigrants to come before them, any orders they gave to bring them in constituted a type of warrant, because they did what warrants do: order someone to be detained and potentially brought somewhere. Since such orders could, per the law, be signed (or spoken) by an administrative official rather than by a judge, they constituted administrative warrants.
1875 - the Page Act says, "Every vessel arriving in the United States may be inspected...[to ascertain if] any [forbidden] persons are on board; and the officer making such inspection shall...designat[e] in [a] certificate the person or persons, if any there be, [so] ascertained... [At] no time thereafter shall [such an] alien...be allowed to land...[unless he] shall apply...to any proper court...[and when] a hearing and determination of the matter are had...if the said inspector shall be found [in the right]...the [forbidden] person or persons shall be returned...to the country whence his or her emigration shall have taken place." This law speaks of "certificates" which force the detention of immigrants on ships unless they appeal to a court, and their deportation if the court determined them to be in the country illegally -- or if the immigrant just never asked to see a judge. These certificates were essentially administrative warrants (they did what warrants do, detain and transport someone) but were signed by administrative officials rather than a judge.
1882 - the Chinese Exclusion Act says, "any Chinese person found unlawfully within the United States shall be caused to be removed therefrom...by direction of the President of the United States...after being brought before...a court of the United States." This law explicitly calls for administrative "direction[s]" -- i.e. documents -- that order the detention of a person, their transfer to a court, and then, if found guilty, their deportation. Again, such documents were effectively administrative warrants but were signed, not by a judge, but by the President -- or, in practice, by his agents.
1891 - the Immigration Act of this year says, "inspection officers may order a temporary removal of [some] aliens [to a detention center]...until a thorough inspection is made. ...[Then those] who [arrived] unlawfully...shall, if practicable, be immediately sent back." This law codified the practice of having lower executive officers sign orders for detention and removal, as was already standard since 1875. It also controversially tried to hasten deportation procedures to reduce the amount of cases brought before courts. Orders for final removal were supposed to be executed immediately, without a judge's input, though it was still true that a detained person could *demand* to go to court. If the officials did not ignore them, a judge would see them and at least hear their grounds for appeal. Though, even in that case, some judges might have issued summary judgments in favor of deportation, without a full trial.
1917 - the Immigration Act of this year says, "any alien who...shall be found in the United States in violation of this act...shall, upon the warrant of the Secretary of Labor, be taken into custody and deported." This is the first time a *law* uses the term "warrant" for administrative orders that detained and deported people. Previous laws called such documents "certificates," "direction[s]," and "orders." Other government statements sometimes called them "Secretary's Warrants," but the law did not. This 1917 law turned the common nomenclature into a legal term as well. Since these "warrant[s]" were signed by an executive officer (the Secretary of Labor) rather than a judge, they were not judicial warrants, but administrative ones.
1952 - the Immigration and Nationality Act says, "On a warrant issued by the Attorney General, an alien may be arrested and detained pending a decision on whether the alien is to be removed from the United States." The Attorney General is, again, an executive officer, not a judge, so these warrants, too, were administrative warrants, not judicial warrants.
1959 - the Supreme Court decides, in Abel v. United States, that "Statutes authorizing administrative arrest...[and] deportation...have the sanction of time...the [presumption of] validity [due to being] Acts of Congress...[and] uncontested historical legitimacy." It calls such documents "administrative arrest warrant[s]" and brings up the question of whether they might be inherently unconstitutional violations of the fourth amendment, since they ordered the seizure of persons without a *judicial* warrant. But the court summarily decided that such orders *were* constitutional by saying they had been in common use for a long time, that the courts must *presume* long-established laws are valid, and that neither side in the present case questioned the constitutionality of such warrants.
In modern times, such “warrants” have been questioned again. The Fourth Amendment says the government isn’t allowed to “seize” (arrest) you without a warrant. What good is this amendment if the executive branch has pretty much always been permitted to seize people and jail them *without* getting a judge’s warrant? Sure, they get an “administrative” warrant, but an administrative warrant just means the very branch of government that wants to arrest you wrote an order telling its own agents to do so. It’s a rubber stamp masquerading as a “real” warrant. And it is sad that U.S. law has essentially always used this “administrative warrant” trick (under a variety of names) to bypass the fourth amendment, and even the Supreme Court has affirmed that it’s fine, mostly because it’s always been done that way. I wish I could say “the Founding Fathers would be rolling in their graves” – but based on the first two entries in my timeline, it looks like they used this trick too. The hypocrisy runs deep with this one.

2026-01-20 19:07:29 UTC

- reply

Yeah but movies often create demand by advertisements that share their interesting premise, which generates curiosity, and thus demand

2026-01-20 18:44:12 UTC

TIL the US built its first air force in 1860 for the Civil War. It had a fleet of hot air balloons, an aircraft carrier, telegraphs for sending info down a tether, and huge spotlights. The air force commander was an inventor named Thaddeus Lowe. Why is there no movie about this?

2026-01-17 19:09:09 UTC

- reply

> Is it really better to post tons of inflated data with BitVM challenges, than just write contracts onchain and hold the escrows accountable that way
Using bitvm doesn't require posting tons of data anymore. Ever since the realization that bitvm can use garbled circuits, two benefits emerged: (1) you only need to post data in the sad path and (2) the data only needs to be one or two standard preimages and hashes -- nearly the same amount of data required to resolve a lightning htlc on L1. That is far better than writing every smart contract on chain. It is cheaper for end users and less spammy for nodes.

2026-01-17 08:44:26 UTC

- reply

I think my previous posts in this thread outline a safe solution to the data availability problem. By protocol, a sequencer merkelizes every sidechain block and posts the root on bitcoin via a piggyback mechanism. If he is a good sequencer, he also broadcasts the full block data on a secondary platform, such as his website. Users use that data to create transactions that update their state.
If the sequencer ever withholds data, any user can start a challenge that forces the sequencer, at risk of getting slashed, to reveal a portion of the latest blockchain data. Specifically, the sequencer must reveal the portion involving that user's latest state, and then, whatever that state indicates about the user's balance, the sequencer must pay it out to the user on L1, if the user agrees that it is the right state.
If the user claims the state has the wrong amount, the user can issue another challenge in which they present their "real" latest state and challenge the sequencer to prove a valid state transition which reduced the user's balance with their approval. The sequencer cannot do this if the user is honest, so they get slashed; or, if the user is dishonest, the challenge ends with no bad consequences for the sequencer.
To disincentivize users from constantly issuing troll challenges, users must pay the cost of putting all challenge data on chain. If the sequencer does not post valid data, the sequencer gets slashed, and the user exits possibly even richer than he was before. If the sequencer posts valid data, the user has now exited and the data withholding attack was repeled by forcing the sequencer to reveal it or get slashed. The user paid extra for this "unilateral exit," but it is common for unilateral exits to cost more than cooperative ones, so that is fine imo. If the sequencer is unreliable about revealing valid data, he will lose his customers with no gain, and if he is reliable, none of this happens in the first place, because no one has an incentive to issue a costly challenge if the sequencer is doing everything right.
For more details, I have a writeup here: https://telegra.ph/A-forthcoming-problem-with-bitvm-11-21

2026-01-16 16:01:26 UTC

- reply

> if Liquid...[used] opreturn...is that spam?
Yes, because in my opinion all op_returns with a data payload are spam
> A Metaprotocol by definition is written on bitcoin
Yes, but it does not necessarily occupy any extra space. For example, the RGB team designed their metaprotocol so that it can "piggyback" on financial transactions that were already going to happen anyway, and only *tweak* the fields in such transactions. That way, the extra data doesn't take up any extra space.
I don't consider that spam. If nodes were going to store the same amount of data anyway by storing the tx *without* tweak data, tweak it, by all means. Then your metaprotocol can have whatever features you want without counting as spam per my definition, because it doesn't increase the amount of data on bitcoin.
> Are you saying anything but a hash is spam
A hash can be spam too, but it depends. The bitcoin protocol supports hashes for things like htlcs. If a metaprotocol used the hash of an htlc that was already doing to happen anyway, and put their metaprotocol hash in it, that wouldn't count as spam in my book.
But if they created an htlc not because it was needed by a bitcoin tx, but because they wanted to put a hash on bitcoin for use in their metaprotocol and couldn't be bothered to piggyback, I would consider that slightly spammy. Though since it's only a hash in one transaction I would also consider it only *slightly* harmful.

2026-01-15 19:53:15 UTC

- reply

Not all bitvm transactions transfer values on L1, and not all of them use HTLCs
> do you consider it a spam if a Metaprotocol is demonstrating that exact soft fork
It is spam imo if and only if the metaprotocol's transactions add more data to bitcoin than would otherwise be there, data with a purpose other than the ones outlined in my definition. There's nothing wrong with simulating a soft fork in a metaprotocol, imo. But if, in service of demonstrating that feature, you use bitcoin as a text dump for your metaprotocol's data, that's spammy.

2026-01-09 12:07:11 UTC

Continue
https://image.nostr.build/efc4362225cb0f2253a7c2a9614af84b18f72331c5b2fb4698863d545fa83ee6.jpg

2025-12-25 15:02:16 UTC

- reply

There is a fork maintained here with different policies for measuring miner health: https://mempool.guide/graphs/mining/pools#3d

2025-12-24 20:52:19 UTC

- reply

I believe mempool.space ranks miner health based on how similar their blocks are to the ones predicted by mempool.space's tx selection algorithm, which is itself based on the one in Bitcoin Core. Many Ocean miners run Knots, which has a different selection algorithm by default (it ignores certain types of spam transactions), so lots of Knots blocks don't match mempool.space's expectations, and I think that's why they give them a relatively low health score

2025-12-24 20:42:38 UTC

Ocean Mining climbed back above 20 exahash (currently at 22.40) and put it to good use in the last 24 hours, mining 6 blocks when only 3 were expected. Mempool.space's measurements make it look like they have 44 exahash, but that's just because they got lucky today.
https://image.nostr.build/551c7e6d23f186f9d73e36f89dee7ad9cb800b1908e0edc4564b16751529efcc.jpg

2025-12-19 22:06:59 UTC

- reply

Facebook Marketplace is
I don't think the others have marketplaces

2025-12-19 00:09:51 UTC

- reply

Then how come I can trace my xmr transactions to you but you can't trace your xmr transactions to me? I'll even use Phoenix if it helps you

2025-12-18 22:14:59 UTC

- reply

> STN starts talking about problems with bbllpckchain privacy, but somehow makes it all about Monero
These problems apply to other blockchain-based privacy systems too
The fact that other terrible systems also have these problems is no excuse for monero

2025-12-18 22:07:21 UTC

- reply

Do those monwro wallets also show a contact list? Such features encourage address reuse, thus creating additional UX hurdles -- if you recommend a "user-friendly" monero wallet, you're probably recommending a privacy-harmful monero wallet

2025-12-18 22:03:35 UTC

- reply

I linked to the Tor domain
Thanks to clearnet proxies, any dnm can be used on clearnet
They are DNMs if they are a marketplace accessible via Tor or similar, there is no requirement that they somehow eliminate all clearnet versions too

2025-12-18 19:33:09 UTC

- reply

Evidence against reusing a monero wallet: “If you need perfect unlinkability of your receivables, the only solution remains to use a separate seed (separate Monero wallet).” source: https://docs.getmonero.org/public-address/subaddress/
Evidence against reusing a monero address: “To prevent the payer from linking your payouts together [you must] generate a new subaddress for each payout.” source: https://docs.getmonero.org/public-address/subaddress/
Evidence for running a monero node, not a phone wallet: “It's always advisable, especially for privacy-conscious users, to use a personal node when transacting on the network to achieve the highest rate of privacy.” source: https://www.getmonero.org/get-started/faq/
Evidence of difficulty of using monero on tor: https://i.ibb.co/27L1H3My/needless-difficulty-of-using-tor.png

2025-12-18 18:12:56 UTC

- reply

> DNMs won't use lightning
The following DNMs use lightning:
Robosats: http://robodexarjwtfryec556cjdz3dfa7u47saek6lkftnkgshvgg2kcumqd.onion/
Bisq: https://bisq.network/
Shopstr: http://sva5te372puuuyhnp4mrspewm76x2jqnzgctdfde474owrdonu4xyoyd.onion/
> exchanges don't ban lightning
Oh yeah? https://protos.com/kraken-drops-lightning-network-in-germany-for-regulatory-issues/

2025-12-17 07:17:28 UTC

The United States Congressional Budget Office has published an annual projection of future US national debt every year since 1984. They also sometimes review how accurate past projections were. Unsurprisingly, they typically underestimate the debt by 7%.
https://www.cbo.gov/publication/55234
https://image.nostr.build/697c624dda6db5772cd14bdabde521c85a025e8c66b1f878a0861093fc976289.jpg https://image.nostr.build/e0a3725a6f4234ab1d5fc23b95d8d4ae0e9af771fe1ca6e0929eec768e30e2f1.jpg

2025-12-08 17:35:26 UTC

- reply

can you give an example of another type of node?

2025-12-08 17:16:35 UTC

My two latest inventions are Node Faker, which simulates bitcoin-cli and bitcoind in the browser (via javascript), and Wild Explorer, which is a block explorer that talks to Node Faker to get its blockchain data
https://www.youtube.com/watch?v=QAc4L7tSZMs
For more info, see their respective githubs:
Node Faker: https://github.com/supertestnet/node_faker
Wild Explorer: https://github.com/supertestnet/wild_explorer

2025-12-04 11:41:43 UTC

- reply

(1) Justifying the existence of a system sounds like a value judgment
(2) There are useful databases that allow for reprdering data. The stated motivation for doublespend prevention is not because it is "technically necessary" (I dont think it is) but rather to prevent fraud, which is itself a form of "morality policing"
(3) The stated motivation for proof of work is to incentivize honesty, not to ensure the system is different from other BFT databases. Other BFT systems are permissioned. But one of the big problems with a permissioned monetary system is not technical but rather moral: dishonest parties might gain control of the system and use their power to allow some people to doublespend, i.e. to enable fraud. Having a pernissionless Proof of Work model incentivizes them to be honest instead. The choice to forego the permissioned route was not technically necessary (orher such systems ARE permissioned). It was a choice explicitly based on morality.

2025-12-04 11:13:20 UTC

- reply

I think it is okay to do this for Txs that are of a bad monetary nature
For example, if someone creates coins outside of the mining protocol, I think it is okay to burn the newly created coins and block such a tx from happening again
I also think that if someone creates a spam tx, it is okay to make their outputs unspendable and bloc such a tx from happening again
But that's what I think. What do *you* think?

2025-12-04 10:28:14 UTC

The consensus rules have always been about morality
One charge that's frequently levied at knotzis is that any attempt to reject spam at the consensus level is based on "moral" objections to spam transactions instead of "technical" objections. One problem with this argument is that *many* consensus rules are based on moral objections to potential transactions:
- no doublespending? It's there to prevent "fraud"
- the 21 million cap? It's there to block "inflation"
- proof of work? It's there to ensure "honesty"
Those are the words Satoshi used to motivate the "rules and incentives...enforced [via bitcoin's] consensus mechanism" (the bitcoin whitepaper), and I think they resonate with many of us.
So yeah, "spam is illegitimate" is a moral claim. And if we enforce it, it will be one of several moral claims enforced at the consensus level. Because that's what bitcoin is for: to create a monetary system that is fundamentally *more moral* (in certain ways) than the alternatives. Spam limits, if they become consensus, are just more moral bricks in the wall.