Super Testnet

Open source dev w/ bitcoin focus | supertestnet.org

bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

Profile Code

nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3zamnwvaz7tmwdaehgun4v5hxxmmdqy8hwumn8ghj7mn0wd68ytnddaks3yy38p

Publishing to

Author Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

Show more details

Last Notes

2026-03-10 17:10:32 CET

- 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 17:00:03 CET

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-05 20:52:37 CET

- 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 20:33:27 CET

- reply

It's annoyingly hard to use bitcoin's p2p layer from browsers. BTC nodes don't understand the handshakes browsers do when they make GET/POST requests, unless you use RPC, which is permissioned. It's cool that Webcoin found a way, but it only works if folks run the bridge software

2026-03-05 20:29:45 CET

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-04 18:23:10 CET

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 01:04:05 CET

- 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 21:52:58 CET

- reply

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

2026-03-01 21:39:30 CET

- reply

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

2026-03-01 21:32:20 CET

- reply

try refreshing the page, I am also on librewolf

2026-03-01 20:23:19 CET

- 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 20:13:08 CET

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

2026-03-01 20:08:12 CET

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

2026-02-26 20:41:53 CET

- 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 20:32:55 CET

- 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 20:09:26 CET

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 16:20:55 CET

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 20:41:59 CET

- 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 15:36:21 CET

- 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-21 03:07:01 CET

Here's a thing I wanna *use* but don't wanna build myself. These stores let you pay with L1 bitcoin if you use one of their partner apps to generate something called a Flexa Payment Code:
- Chipotle
- Home Depot
- Gamestop
- Barnes & Noble
The user needs a wallet with btc or another cryptocurrency in it, you use that money to fund what is essentially a gift card that works at any Flexa-supporting merchant, the merchant scans it, and you enjoy your product.
But there is no "web" interface for doing this. You can't just pay a lightning invoice and get a Flexa payment code out of it to present at Chipotle, etc. And Flexa's API is also permissioned, which is a turn-off for me.
But there's a potential workaround: at least three of their partner apps ARE permissionless. Nexus Wallet, Nighthawk Wallet, Zashi Wallet, and Coinbase Wallet are self-custodial wallets, and *can* generate Flexa payment codes.
So I'd love it if someone used an emulator, a scraper, and lightning to make a website where anyone can generate a Flexa code and pay with LN at Chipotle et. al.

2026-02-20 21:43:41 CET

- 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 21:17:53 CET

My latest invention is Red Blocks: track the status of BIP110 activation
redblocks.supertestnet.org

2026-02-20 14:48:46 CET

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 05:35:21 CET

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 05:01:40 CET

- 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 04:29:38 CET

- reply

I don't think it means that

2026-02-20 04:28:45 CET

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

- 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 23:02:59 CET

- 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 22:54:40 CET

- 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 22:45:24 CET

- 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 21:52:56 CET

- reply

I support running Knots because I think filtering out spam is a good idea. I could also theoretically support a soft fork *similar to* BIP110 that removes known spam vectors. But when it comes to BIP110 *specifically,* I do not support it for reasons I outline in this repo: https://github.com/supertestnet/URSF-110

2026-02-19 21:49:40 CET

- 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 20:38:44 CET

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-19 00:38:57 CET

- reply

BIP110 does two bad things. First, in certain circumstances, it freezes the funds of wallets that use the miniscript language in a certain way. Miniscript is a bitcoin smart contracting language with a bunch of built in functions, and it is designed to "compile" a bitcoin wallet that uses one or more of those functions as selected by users and/or developers. Some of those functions sometimes violate one of BIP110's proposed rules (the rule against using the OP_IF function in taproot wallets), which could cause users of some miniscript wallets to lose funds, depending on how they use it.
This potential problem was brought up before the BIP110 software was written, including by me, and a fix was proposed, but the BIP110 devs decided to move forward without fixing it. I think it is a bad idea to potentially freeze the funds of innocent miniscript users. I think it would be better to provide wallet devs with a variant of miniscript that doesn't violate BIP110's proposed rules, and enough time to upgrade. Alternatively, BIP110 itself could be modified so that it doesn't break current versions of miniscript, but BIP110's developers have rejected that option because one of the most popular spam formats uses OP_IF in taproot transactions and they want to be sure to block that.
Apart from breaking miniscript in certain cases, there is another reason I do not like BIP110: I think most bitcoin node runners are currently largely indifferent to the forms of spam that BIP110 tries to block, and are therefore unlikely to run BIP110 on their nodes. With insufficient support from node runners, I think BIP110 will fail to sway miners to enforce its rules, and the small number of people who do run BIP110 will probably fork off the bitcoin network sometime close to September. I would prefer to continue winning people over to the anti-spam movement, and only do an anti-spam soft fork once there are more signs that a sufficient number of people will run it, including economic signals.

2026-02-17 19:32:23 CET

- 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 19:03:14 CET

- 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 18:31:35 CET

- 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 18:26:24 CET

- 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 18:10:25 CET

- 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 17:36:21 CET

- 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 17:28:51 CET

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-13 19:49:07 CET

- reply

Relevant: #nevent1q…trt4

2026-02-13 18:46:57 CET

- 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 18:07:41 CET

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

2026-02-10 06:47:21 CET

- 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 04:10:05 CET

- 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 21:28:46 CET

- 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 17:52:03 CET

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-28 22:00:09 CET

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 18:08:22 CET

- reply

Diary of a Wimpy Kid 2010
Haven't seen it so I don't know if it's any good but this 30 second clip is funny

2026-01-28 13:59:25 CET

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

2026-01-22 10:29:25 CET

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:44:12 CET

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 20:14:26 CET

- reply

> you think people are trying to add scalability... No, people are trying to have usuable smart contracts
I thunk they are trying to do both, and I think my proposal is the cheapest way to do both proposed so far, and as a result, also the least spammy.
> [they want an] actual smart contract language that is not as awful as BitVM
Bitvm allows you to use any smart contract lamguage you want. Normal devs are not expected to write their programs in binary circuits, that's what compilers are for.
> [bitvm] forces people to use ZKVMs that are far from water tight
I am unfamiliar with this criticism, do you have more details or a link to where I can read more?

2026-01-17 20:09:09 CET

- 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 09:44:26 CET

- 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 17:01:26 CET

- 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-09 19:28:34 CET

My latest essay is "Connector Swaps" -- a new proposal for swapping from LN to L1 in only 1 transaction
I compare the new proposal with alternatives including Splices, Submarine Swaps, and my own Papa Swap protocol that I implemented last year
https://gist.github.com/supertestnet/1844b927ec6e9e17d476a5fc2d691668

2025-12-24 21:42:38 CET

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 01:09:51 CET

- 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 23:14:59 CET

- 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 23:07:21 CET

- 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 23:03:35 CET

- 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 20:58:43 CET

- reply

> I don't understand why it's worth the effort to make a big deal out of the address reuse mistake
Because address reuse is bad for privacy (the monero website recommends against it) and yet most monero wallets are designed to encourage it
> does lightning not have bolt12 and lnurl? if you reuse these, the sender will infer that it's you both times
Yes, that is equally bad for user privacy

2025-12-18 20:33:09 CET

- 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 19:12:56 CET

- 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 15:51:24 CET

- reply

If it was exactly 7%. But it's not, it varies higher and lower than that. 7% is just the average

2025-12-17 08:17:28 CET

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-17 04:02:18 CET

I looked into it further, and it looks like bitcoind actually does confiscate some pre-P2SH outputs. For the sake of "simplicity," it applies the p2sh rules to all transactions in all blocks (including pre-P2SH blocks) except ones occurring in one specific block that the devs made a single exception for. Thus, the other exceptional outputs are now unspendable.
Source: https://github.com/bitcoin/bitcoin/blob/13891a8a685d255cb13dd5018e3d5ccc18b07c34/src/validation.cpp#L2305
https://image.nostr.build/49d62524f826f88431814da109066ff8ca711194986a5089b96fb9443659aa88.jpg
#nevent1q…cgz5

2025-12-17 01:44:16 CET

- reply

I looked into it further, and it looks like the codebase actually does confiscate those outputs. For the sale of "simplicity," it applies the p2sh rules to all transactions in all blocks (including pre-P2SH blocks) except ones occurring in one specific block that they made a single exception for. Thus, the other exceptional outputs are now unspendable.
Source: https://github.com/bitcoin/bitcoin/blob/13891a8a685d255cb13dd5018e3d5ccc18b07c34/src/validation.cpp#L2305
https://image.nostr.build/49d62524f826f88431814da109066ff8ca711194986a5089b96fb9443659aa88.jpg

2025-12-08 18:35:26 CET

- reply

can you give an example of another type of node?

2025-12-08 18:16:35 CET

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 17:05:23 CET

- reply

More insults and ad hominems from the core camp. Sad! But typical. When you have no arguments, use insults, eh?

2023-07-05 05:52:34 CEST

- reply

Sure you can
I just need to make it easy
But you can already do a coinjoin to crowdfund it