Super Testnet

Open source dev w/ bitcoin focus | supertestnet.org

bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

Profile Code

nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhkummnw3ezummcw3ezuer9wcqs7amnwvaz7tmwdaehgu3wd4hk6qg5waehxw309aex2mrp0yhxgctdw4eju6t0kr76nh

Publishing to

Author Public Key

npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s

Show more details

Last Notes

2026-02-08 03:27:02 UTC

- reply

Oops, I forgot to say how to connect to them first, lol! It's a simple one-liner:
var socket = new WebSocket( "wss://blackie.c3-soft.com:57012" );
then you can run the var cmd line above to test them

2026-02-08 03:24:59 UTC

- reply

You can test the connection with this javascript codeblock:
var cmd = {"id": "test","method": "server.version","params": [ "", "1.6" ]}; var handleFunction = async msg => {console.log( msg.data );}; socket.addEventListener( 'message', handleFunction ); socket.send( JSON.stringify( cmd ) );

2026-02-08 03:19:26 UTC

- reply

h/t @npub1u8l…turz for adding websocket support to mutinynet today after I requested it!
I was also proud to show him some software to use for bridging TCP to WSS and I helped him debug it for about half an hour
@npub1ywj…6ejf also added websocket support to mempool.guide per my request and indicated he has plans to add WSS support to his own custom signet and his testnet4 electrum server

2026-02-08 03:10:03 UTC

Electrum WSS:
- mainnet - wss://mempool.guide/electrum-websocket/
- test3 - wss://blockstream.info/testnet/electrum-websocket/
- test4 - wss://blackie.c3-soft.com:57012
- signet - wss://blockstream.info/signet/electrum-websocket/
- mutiny - wss://mutinynet.com/electrum-websocket
That is a list of electrum servers that expose their TCP api over websockets, meaning even web browsers can use them for validating info like a p2p node would do. Electrum servers are, of course, not exactly "peers" to most of their users, but if you validate their data they are.

2026-02-01 20:28:28 UTC

- reply

I don't think you believe the former
As for the latter, it seems like a complete concession that rate limits do apply

2026-02-01 19:25:01 UTC

- reply

> No APIs. No rate limits
Nostr relays have apis, that's what most of the nips are. And all relays I know of have rate limits too

2026-01-31 02:15:37 UTC

- reply

> we have lightning payments but there is no privacy
I can't agree with a statement like "lightning payments have no privacy." Lightning provides a pretty strong baseline for privacy. It's not perfect (it's not even good, absolutely speaking), but it's not nothing, and if used carefully (e.g. if you run your own lightning node on tor and learn how to manage channels) I think it's better than alternative solutions such as monero. Still, lots of work to do, and I'm glad it's being done.

2026-01-30 18:09:40 UTC

- reply

Running whatever version you want is exactly what the loud noises are all about

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-30 01:10:22 UTC

- reply

he has been near bitcoin since 2010 so what does that make bitcoin?

2026-01-30 00:30:01 UTC

- reply

if you're running Zeus and not running a full node then you're trusting whoever *is* running a full node. In Zeus's case, this means you're trusting the nodes your Zeus wallet reaches out to for bip157 filters.

2026-01-30 00:07:44 UTC

- reply

I guess bitcoin can't be good then

2026-01-30 00:06:48 UTC

- reply

> Will the big nodes execute it? How do we know they're executing it? Are we turning privacy into a matter of faith?
I think this gets really interesting if/when routing nodes start publishing privacy policies, e.g. "we do not log payments." Then you can start to build routes that *do* have some cryptographic guarantees. E.g. "if I route my payment through N nodes with zero-log policies, then even if only 1 is honest, an attacker gets subpoenas records from every node on my route *still* won't find full records of my payment."
Many cryptographic protocol rely on assumptions like that one. Tor works like this and Dandelion++ works like this, for example. Lightning has always had privacy assumptions that work best when routing nodes don't collude together, but these assumptions are undermined if attackers can easily access node logs and thus effectively *force* them to collude after-the-fact. If every node has the ability to easily delete logs, that makes lightning's privacy assumptions stronger, because it makes it more likely that an attacker who tries to acquire those logs won't be able to get them.

2026-01-29 19:32:53 UTC

- reply

https://image.nostr.build/49b32cf0ec9e2c324bf0c3ca6071d89f197dc3938aae2e1cea1896306a9f019d.jpg

2026-01-29 19:08:44 UTC

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

2026-01-29 16:13:22 UTC

- reply

On a related note: #nevent1q…7swu

2026-01-29 15:58:04 UTC

- reply

Yes, there is still work to do. The docs mention the possibility of adding "Automatic Scheduled Deletion" as an enhancement. I hope they do, and I hope they turn it on automatically.
There's another enhancement that I hope to bring up after the DeleteFwdHistory command goes live (one thing at a time): besides forwarding logs, LND has two other log files, "normal" logs and "revocation" logs, and whenever a payment gets logged in the forwarding logs, those *other* logs *also* get an entry containing similar information.
But the new command does not delete records from those other log files, it only deletes records from the forwarding logs. So even after DeleteFwdHistory goes live, an attacker who gains access to your node could still reconstruct past payment flows even if you ran DeleteFwdHistory on a regular basis.
The docs mention two mitigations for this: you can set up automated systems to manually purge your normal logs, or tell LND not to keep normal logs at all. That can be used in conjunction with DeleteFwdHistory to delete 2/3s of the sensitive records about forwarding history.
But that doesn't fix the problem with revocation logs. LND doesn't let you easily delete those log files because they contain information that it "needs" in order to safely perform force closures if needed. The docs only mention one solution for deleting sensitive information from those logs, and it's a pretty nasty one: if you close any channel, that channel's revocation logs automatically get deleted.
A node operator with a 90 day retention policy (for example) could schedule their computer to run DeleteFwdHistory every 90 days (which would solve 1/3 of the problem) and tell their node not to keep normal logs (which would solve an additional 1/3 of the problem). To delete the last 1/3 of the logs (the revocation logs), the node operator could schedule their computer to close each channel in their node 90 days after it is created. But that would make such nodes less competitive, as channel closures cost money, and they'd have to pass on those costs to their users.
So after the DeleteFwdHistory command goes live I plan to ask them to "enhance it" so that it *also* deletes sensitive info from the revocation logs. The revocation logs do not need to retain "all" info about past payments; they need to keep something called a "revocation key" and they need to watch for a certain transaction id to appear on the blockchain (or in the mempool). The DeleteFwdHistory command could safely delete all other data in old revocation logs, and then node operators would no longer need to close any channels in order to automatically delete all of the sensitive information from their old records.
But one thing at a time! I'm glad the new feature is almost ready and I'll wait til it goes live before I request this enhancement.

2026-01-28 21:22:41 UTC

- reply

This feature is expected in the v0.21 release of LND, which itself is expected around April 2026
Note this advisory for any node runners who want to use the new feature:
What Deletion Doesn't Protect
The revocation log for active channels contains information that can be used to reconstruct transaction flows. Once channels are closed, this data is automatically deleted.
The normal logs of a node also contain information that can be used to correlate transactions. Users can set up automated systems to manually purge logs, or configure the logging directory to a purely in-memory file system.
-----
End of advisory.

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 17:08:22 UTC

- 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:33:11 UTC

- reply

when I see a good one I post it (well, except I'm often not thinking about this particular issue, so I don't always make the requisite association)

2026-01-28 12:59:25 UTC

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

2026-01-27 00:28:20 UTC

- reply

In the end, the prompters become the prompted
Maybe you could write another agent to answer their questions on your behalf

2026-01-26 22:17:38 UTC

Second BTC announces support for a new variant of Ark called Hark:
https://docs.second.tech/changelog/changelog/
I'm a big fan of providing users with options, and it looks like Hark is opt-in, so I'm a fan. However, I think it sadly doesn't count as a layer 2 protocol. Here's why:
Hark is designed for users who don't want to run Ark's interactive signing protocol. Therefore, such users will not have a unilateral exit even in the best case. Ark has a single-honest-party trust assumption, and it was designed so that anyone can "be" one of those parties by (1) onboarding and (2) running the interactive signing protocol—which means you are one of the parties in the single-honest-party trust assumption, and are thus trusting *yourself* to be honest.
But Hark users opt *not* to run the interactive signing protocol. As a result, they cannot be one of the parties in Ark's single-honest-party trust assumption, so they must trust someone who *is* one of those parties.
At least to me, that means, sadly, Hark is not a real layer 2 of bitcoin. My definition of a layer 2 requires the availability of a unilateral exit. Ark is a layer 2 only for users who run the interactive signing protocol and do refreshes as needed. In Hark, you don't run the interactive signing protocol, so you're essentially trusting a federation to sign transactions on your behalf without stealing from you, and that makes it not a layer 2 (by my definition).

2026-01-24 20:01:29 UTC

My latest essay is not about bitcoin, it's about hot air balloons, airships, and the surprising story of 5 companies in the 1800s that tried to launch commercial airline ventures before airplanes existed
Timeline of Commercial Air Traffic in the 1800s:
#nevent1q…7d6x

2026-01-24 19:50:32 UTC

Timeline of Commercial Air Traffic in the 1800s
In the 1800s, 5 private corporations launched ventures to transport goods and passengers between cities on hot air balloons, airships, and airplanes. (One of the ones below technically didn’t, but I think what they *did* do is close enough to count.) Here is a timeline:
In 1843, the Aerial Transit Company was a British corporation that sought investor funding to build an airplane for transporting goods and passengers between cities. However, their science was bad, and they were widely mocked. They did not receive sufficient funding to build their airplane, which wouldn’t have worked anyway without serious design modifications, as no one really knew how to build airplanes yet. Some scientists at that time were not even sure it was possible. The company went bankrupt, and the venture was not revived.
In 1859, the United States Express Company was a package delivery corporation that once hired hot air balloonist John Wise for an experiment to test the feasibility of transporting packages between cities by air. The test flight carried real, commercial packages, meant for shipment from Missouri to customers in New York, and it was also meant to test if a balloon could travel the kinds of distances required for transatlantic flights. Mr. Wise dreamed of a company specializing in cross-oceanic transport, and the United States Express Company was one of his chief sponsors (perhaps hoping one day to *be* a trans-oceanic transport company). Sadly, during the flight, in an effort to avoid crashing, Wise decided he must jettison the commercial packages as if they were ballast. The company decided not to pursue further tests, though the venture was somewhat revived in 1873; keep reading for more on that later.
In 1863, the Aerial Navigation Company was an American corporation founded by an airship pioneer named Solomon Andrews. I think he is praiseworthy for this thing, among others: he built his airship *before* founding this company, pitched investors on his “big idea” *after* demonstrating to their satisfaction that his machine worked, and only *then* received funding from them. His big idea was (as with prior attempts on this timeline) to use the airship in a commercial enterprise involving the transport of goods and passengers between cities, with profits to be shared with the investors. The company used the investors’ money to build a new aircraft and then they made several successful test flights in 1866, but before they did any *commercial* flights, the bank holding their money collapsed, and the company filed for bankruptcy. The venture was not revived.
In 1873, the Daily Graphic was an American newspaper which, after a pitch by balloonist and entrepreneur Washington Donaldson, attempted to revive John Wise’s transatlantic transport idea by sponsoring the construction of a hot air balloon meant to be employed by Mr. Donaldson in transporting goods and passengers from America to Europe for profit. Mr. Wise was allegedly consulted on the project since he had previous experience trying to do this with the United States Express Company as his sponsor. The newspaper expected to benefit from this venture through enhanced publicity for their newspaper, e.g. the first balloon in Mr. Donaldson’s fleet was named after them (his "fleet" never had more than this one balloon), and they had a deal to get a scoop about its maiden voyage. Sadly, the balloon was torn during a test; after repairs, a test flight commenced, where the balloon flew 60 miles before it crashed and was destroyed. The venture was not revived, partly because Mr. Donaldson died in a crash while attempting another long-distance flight in 1875; this time the operation was sponsored by the P.T. Barnum circus, and was not intended to test the feasibility of a long-distance flight company; it was a daredevil act to attract publicity for the circus.
In 1898, the Society for the Promotion of Airship Flight was a German corporation founded by entrepreneur Ferdinand von Zeppelin to seek investor funds and then build the first Zeppelin airship. It worked, leading to Mr. Zeppelin receiving more financing for further efforts, so he built more airships. A few years later (i.e. in the early 1900s), after more designs and tests, he founded the Zeppelin company to use his airships for commercial transport of goods and passengers around Europe and eventually across the world – as well as for military usage. The Zeppelin company is widely regarded as the first airline company, and this timeline is partly intended to show that they were *actually* the first *successful* airline company. Four others preceded them but without the Zeppelin company’s smashing success.
Also noteworthy: there were 2 government-sponsored “quasi corporations” – the French Postal Service and the US Postal Service – which successfully contracted with balloonists several times in the 1800s to experiment with delivering real, commercial mail between cities via balloons. These tests were mostly publicity stunts meant to draw crowds who sent needless postcards and such with expensive balloon stamps, and they happened in 1859 (in America), 1870 (in France), and 1877 (in America again). Arguably, such a test even happened in 1793, when President George Washington gave a balloonist a document greeting the owner of whatever land the balloonist would happen to land on. The document was arguably a type of mail, so some say *that* counts as an early example of balloon airmail too, though it’s somewhat different since the document’s intended recipient wasn’t exactly known in advance, and so there was no specific delivery address.
Anyway, these experiments demonstrated the commercial potential of air traffic, as most of the tests were not failures, had paying customers, and sometimes got the mail to its destination faster and cheaper than alternative methods. Nonetheless, the Postal Services did not think balloonists saved them enough time or money to justify contracting their services regularly. Especially when some of the tests *did* experience failures and thus risked further damaging each Postal Service’s already imperfect reputation for reliability.
Also noteworthy: many balloonists formed “informal” commercial ventures throughout the 1800s (and even the late 1700s) where people paid them for individual flights in their balloons, especially at circuses and carnivals. These ventures technically count as commercial transport of passengers, and some of them sound like they were part of formal for-profit corporate entities (like circuses). Moreover, a few people even ventured to contract with such balloonists to charter a flight between two cities, so some people might question why I failed to include such examples in my timeline. The reason is, based on my research, I don’t think these flights counted as transporting customers or freight with an *economic* or even a *vacation-y* interest in quickly getting to another location on a regular schedule. The passengers mostly just wanted to break records and get a thrill from the very act of flying a long distance (or, at circuses and such, a rather short distance).
That’s important too, but in this timeline I wanted to focus on “business” travel (or even “vacation” travel) rather than flying-for-adreneline’s-sake. I wanted to find ventures that experimented with flights between cities for the purpose of assessing the economic feasibility of doing them on a regular basis for passengers and freight, like modern airlines do. I think the “adreneline-junky” purpose is less interesting, for me, even though companies supplying *that* demand were almost the only ballooning ventures that really succeeded in the 1800s. It is notable that the only venture on my timeline that *was* successful was Mr. Zeppelin’s 1898 company, which had a very limited purpose of just building a functional airship. This success led Mr. Zeppelin to further successes down the road – a reminder that setting a very *attainable* goal can be massively rewarding.
Also noteworthy: several balloonists in the 1800s contracted with various militaries to provide reconnaissance services for a fee. At least one public-private partnership did this: the Union Army Balloon Corps of 1861 was an official military entity, but the pilots were all civilians under private for-profit contracts. I think that technically counts as a commercial venture, at least for the pilots, but the military connection and the absence of any attempt to use balloons to travel between cities makes it not quite what I was looking for when I started this document, so I did not include it in the main timeline.
But I do think it’s really interesting in its own way; e.g. the success of that public-private partnership eventually led to the government (in 1892) creating an official “not-private” division of the military called the Signal Corps Balloon Service, staffed with pilots who were sergeants and colonels and such, rather than ordinary civilians. Through a series of rebrands and mergers, this group eventually became the US Air Force. I find that fact both funny and really cool: in a very real sense, the US Air Force has its organizational origins in a few soldiers who scouted for enemy troops from the high vantage point of a hot air balloon.

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 23:44:29 UTC

- reply

Oh yeah, and I forgot to mention:
- steam powered trains to move soldiers around
The US train system only came into existence about 30 years before the civil war broke out, and most lines were new. I'll bet many soldiers had only barely "heard of" trains when they were suddenly shipped off on one to shoot, kill, and die

2026-01-20 23:08:16 UTC

- reply

Steampunk aspects of the US civil war:
- telegraphs for nearly instant communication
- submarines for underwater naval battle
- hot air balloons for midair reconnaissance
- propeller ships to replace giant sidewheelers
- steam-powered, iron warships with revolving turrets
- the first use of machine gun weaponry
- the first appearance of trench warfare

2026-01-20 22:56:08 UTC

- reply

I read the Memoirs of Ulysses S. Grant and I was glad that he had some pretty long sections about the importance of technology to the war effort. Specifically, he was very amazed by the telegraph, and recalls staying up late at night to communicate by wire from the front lines with President Lincoln or other generals, to coordinate and plan their strategy.
He also got to see the creation and deployment of propeller powered naval vessels, and was floored by how much deck space was saved by not having a huge wheel in the middle powered by a giant steam engine. The engine could be a lot smaller because propellers were so much easier to turn. And these boats were faster to boot! What amazing progress in such a short time.

2026-01-20 21:45:40 UTC

- reply

I also learned that after the Balloon Corps stopped service in 1863, the Signal Corps Balloon Service was established in 1892 by an officer who had witnessed the Balloon Corps in action and thought it was underused. This group used a hot air balloon for a reconnaissance mission in 1892 during the Spanish American War, flown by the first non-civilian pilot, Sargeant Ivy Baldwin. The Balloon Service continued training pilots through 1907, when it got replaced by the Signal Corps Aeronautical Division, the forerunner of the U.S. Air Force.

2026-01-20 19:46:50 UTC

- reply

I would watch the cutscenes

2026-01-20 19:38:50 UTC

- reply

It was a naval vessel, the USS George Washington Parke Custis, which was originally a civilian boat (a coal barge) that the Union Army purchased in order to convert into a vehicle for the transport and launch of Lowe's balloon corps (and thus an aircraft carrier).

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-18 01:40:19 UTC

- reply

> Rootstock already solved DA
I think my proposal is superior to theirs because it also solves the DA problem but puts less data on the blockchain
> you can't just make smart contracts by promising that you can ask for your merkle proof before a contested withdraw... You need data availability all the time
My proposal gives you data availability all the time. The moment the sequencer tries to withhold data, that's the moment when you issue the challenge and force them to reveal the data or get slashed. They can never withhold data without undergoing such a challenge, whereupon it gets revealed or you get your exit. Since they can never withhold data, the data is always available.

2026-01-17 19:14:26 UTC

- 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 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 20:48:00 UTC

- reply

> if you take your DA challenge idea to its extreme you will find that it devolves to exactly always embedding blocks on Bitcoin
I disagree for reasons about to be discussed
> either there is no cost for the challenge in which case I will personally challenge everything just to prove a point
That seems unworkable and I think we agree on that
> OR there is a high cost for challenging, which can't be refunded because you can never prove the data was withheld so you will just have to pay it
That seems reasonable and does not result in always embedding blocks on bitcoin. Users select a sequencer optimistically. If he attempts to withhold data, users can pay a higher-than-normal cost, which is effectively the cost of a unilateral exit.
The unilateral exit sequence forces the sequencer to reveal the data he tried to withhold or get slashed. Either way, the users exit unilaterally. That bankrupts the bad sequencer, because all his users unilaterally exited to avoid being victims of the data withholding attack. Then those users pick a new sequencer.
Eventually, this process leads to only "good" sequencers remaining. Due to incentive alignment, the process will probably "begin" with only good sequencers as well, since no one wants to go bankrupt, and the only way *not* to be bankrupted is to start out as a good sequencer and remain good.
And the great thing about good sequencers is, they don't need to be challenged, because they don't withhold valid data, so no extra "challenge" data goes on-chain -- or, if it does, it's because of a troll user, who pays the price for trolling due to the higher-than-normal cost of initiating the unilateral exit sequence. Thus only trolls pay that cost, which is desirable, as that eventually bankrupts them, leaving only "good" users and "good" sequencers.
> So if you want a chain to do things that require people to be aware of what is going on...then you will need to keep posting the data all the time
I think the above analysis demonstrates why I think that is incorrect. You can align the incentives properly to bankrupt "bad" sequencers and trolls, such that only "good" sequencers and "good" users are left -- i.e. the ones who follow the protocol in part to avoid going bankrupt.
> No Stablecoins backed by Bitcoin are not mere tokens... There is a whole lending contract necessary to mint them, not just a token you mint and transact with RGB without need for observable chain.
I didn't say bitcoin-backed stablecoins are "mere" tokens. I just said they are tokens, which you seem to admit.

2026-01-16 19:12:31 UTC

- reply

> I don't want to create tokens. I...care about...satisfying the demand for Stablecoins while still using Bitcoin as backing...
Those two statements sound incompatible. Bitcoin-backed stablecoins are tokens. Unless they currently exist, they must be created.
> let's just start with the data witholding
If someone embedded a hash of sidechain block X into bitcoin using an RGB-like piggyback scheme (so that it doesn't take up extra space), but then withheld the data of block X, you could first challenge them to reveal the hash for block X (if they haven't already done so), and then, if they DON'T reveal it, they get slashed, and if they DO reveal it, you can then further challenge them to reveal any transaction relevant to *you* by means of merkle proofs. Once again, if they DON'T reveal it, they get slashed, and if they DO reveal it, the data withholding problem is solved.

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 18:28:34 UTC

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

2026-01-09 12:07:11 UTC

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

2025-12-30 16:22:46 UTC

My latest invention is SSB Playground: play with the bitcoin bug commonly called the Sighash Single Bug. I demonstrate that it lets you do a basic form of transaction introspection and even enforce restrictions on the output count of future transactions.
https://youtu.be/Op9p3LR68fE
Play with it here: https://supertestnet.github.io/ssb_playground/
Or check out the source code: https://github.com/supertestnet/ssb_playground

2025-12-30 09:16:40 UTC

- reply

A complete list of affected utxos are provided in the stack exchange post I linked to. You would spend them before bybprovoding the preimage to the hash160 hash as the only thing in your redeem script. After the change, you also have to hope the preimage is a valid bitcoin script and then hope you can provide any requisite arguments required by that script to make it return true, and provide those in your redeem script as well.

2025-12-29 16:42:22 UTC

- reply

This means bitcoin has two different types of timelock errors it can throw. It can say "your timelock isn't passed yet, so your tx is invalid" or "your timelock passed according to your system clock, but the network hasn't confirmed this, so your tx is non-standard"
It seems weird to have such a similar error be part of the validity check AND the standardness check. But as pointed out in the post I linked, this is because "transactions that are still time-locked are not just invalid, they’re also non-standard."

2025-12-29 16:36:38 UTC

Here's a cool piece of bitcoin script lore about an obscure difference between two ways to use timelocks:
"height-locked transactions are standard before they’re valid, but timestamp-locked transactions don’t become standard until they’re valid"
Source: https://medium.com/summa-technology/the-bitcoin-non-standard-6103330af98c

2025-12-25 15:46:08 UTC

- reply

You and I can help change that!

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-25 14:58:54 UTC

- reply

I think they show yellow if they detect evidence that some miners in that pool are refusing to mine some valid transactions that mempool.space's tx selection algorithm says it expects to get mined

2025-12-25 02:00:23 UTC

- reply

Merry Christmas!

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 14:57:58 UTC

- reply

> when Robosats does ANYWHERE near the volume paxful was doing
then you can talk about similar threat models. not before.
If they did not apply the threat model when small, then the operators' personal information would be compromised before they get big.
> shopstr does essentially zero volume
Where are you getting those statistics?

2025-12-19 14:36:43 UTC

- reply

> which is bullshit
If "create an entirely new wallet for every tx" is bad advice then maybe submit a PR to withdraw that advice from the monero project's website
> most LN users transactions [are] trivially linked together by their custodian or the one or two LSPs they have a channel with
I acknowledge that most LN users are not using it in a privacy preserving way. Do you acknowledge that most monero users aren't?

2025-12-19 14:31:32 UTC

- reply

There's more to it than that: #nevent1q…886k

2025-12-19 14:29:17 UTC

- reply

> Is that difficult?
Yes, for most people. Manipulating configuration files requires a lot of background knowledge that most people don't have. Using command line arguments too. You also neglected the part about installing linux in the first place, and then installing tor.
For most people, I suspect they would assume "installing tor" means "installing the tor browser," not running "pkg install tor" or "sudo apt install tor" or whatever it is since it depends on which linux operating system you're using.
And if someone gets past all that, then you have to somehow find out that (1) you have to keep it running (2) the port switches from 9050 to 9150 if you're using tor browser -- and if you're on Windows, everything is different there too.
So yeah, it's difficult. Not for me or you, but we've got a lot of background knowledge that you can't assume for most people.
> Making a new wallet per transaction is schizo IMO
Yet -- according to the monero website -- that's the only way to get transaction unlinkability in monero. You think *lightning* has a UX problem? Meet monero.
> your criticisms about having to make new addresses and the like are all REQUIREMENTS for bitcoin on-chain even to the same vendor. You can reuse the same address with the same person with Monero's and there will be no on-chain link
There will be no "on-chain" link, but that person will have an off-chain link that is just as provable. An identical thing is true for monero's addresses and bitcoin's xpubs: if you trust the sender with your privacy, you can give him a monero address or a bitcoin xpub (or a bitcoin SP address, more recently) and if he reuses it, then "on-chain" there will be no link between different transactions sent by that person. Unless the sender makes mistakes too. But even if he does everything *else* perfectly, he made this mistake: he kept your address or xpub and reused it -- and that means he kept a record or proof that links multiple transactions together. If the address or xpub leaks to untrustworthy people, e.g. if he is subpoena'd for that information, your adversaries learn those links and can prove them in court. I think that's a terrible for privacy. Do you? Or is it only bad when it applies to bitcoin, and perfectly fine in the case of monero?
> Please do proper journalism by using the protocol you describe
I've used monero plenty and I think it sucks.

2025-12-19 00:10:12 UTC

- reply

Oops, I meant "your LN transactions to me"

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:11:44 UTC

- reply

To get decent privacy on monero, you have to install and configure a monero node
Might as well get superior privacy by installing and configuring an LN node instead

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:58:43 UTC

- 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 19:46:38 UTC

- reply

> You need to look into timing analysis and BGP vulnerabilities in the Tor protocol
While looking at that, also look at how those vulnerabilities apply to monero's Dandelion protocol: https://arxiv.org/abs/2201.11860
Key quote: "our analysis of Dandelion and Dandelion++ indicates that they do not offer high anonymity either…an adversary that controls 20% of the nodes…[can] intercept [enough] transactions [to where] the median entropy is about five bits…equivalent to 32 possible originators per transaction."

2025-12-18 19:40:59 UTC

- reply

> These are NOT dnms and he knows it
They are per the definition used by law enforcement and by wikipedia. If you've got a strange stricter definition of "it only counts if drugs are widely sold there," that's a you-problem
> These onion services have completely different threat assessments than a DNM
Nope. They have very similar threat assessments, for the following reason:
https://www.justice.gov/archives/opa/pr/paxful-inc-co-founder-pleads-guilty-conspiracy-fail-maintain-effective-anti-money-laundering

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 19:25:17 UTC

- reply

> he complete REFUSES to ever acknowledge the UX problems
I acknowledge that UX problems exist in LN. I deny that similar problems are absent from monero.
Per the monero website, here are some UX problems with monero:
- Users shouldn't reuse a monero *address*
- Users shouldn't even reuse a monero *wallet* (i.e. you should delete your wallet after each use and make an entirely new *wallet* for the next use, according to the monero website)
- Users should run a monero node, not a phone wallet
The website doesn't say the following thing, but users should also use tor/i2p/vpns if they use a monero *node,* but it's needlessly difficult to do so because many important people in the project basically disagree with that. The monero github even says in its readme "Monero isn't made to integrate with Tor" and discusses the hoops users need to jump through to get it to work with tor. It's got serious UX problems and most monero influencers just don't want to admit that because the phone wallets are easy -- and the monero website recommends not to use those!

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-18 18:07:57 UTC

Here are three interesting pages on the bitcoin wiki:
P2SH votes - https://en.bitcoin.it/wiki/P2SH_Votes
Segwit support - https://en.bitcoin.it/wiki/Segwit_support
Covenant support - https://en.bitcoin.it/wiki/Covenants_support
All three gauge developer support for various fork proposals around at the time. Kind of like a vote.

2025-12-17 18:19:46 UTC

Core fans lately
https://image.nostr.build/a1e104dc12c6dfb73ee31724caa5be6d5c491b7d4bbd1c5750044557901acd27.png

2025-12-17 14:51:24 UTC

- 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 14:49:52 UTC

- reply

Seems like it sets a precedent for setting confiscation deadlines in new bips

2025-12-17 14:48:46 UTC

- reply

Even bip16 seems to create a confiscation deadline. It says all txs created after the deadline should have the new rules applied to them. So the ~5 people who previously used hash160 hashlocks would have to move those utxos before the deadline or else their outputs would become unspendable. Which is exactly what happened; one such output was already moved, the rest did not move and became unspendable.

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-17 03:02:18 UTC

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 00:44:16 UTC

- 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-16 22:14:24 UTC

- reply

Perhaps whoever posted that should be corrected, then. Also noteworthy: there are transactions from before bip16 with outputs that match the bip16 template, like this one: https://mempool.space/tx/9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6
And some of them were spent, including that one: https://mempool.space/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192
Per BIP16, I think they should be treated as simple hashlocks, i.e. if they have a redeemscript, it should not be evaluated, as bip16 wasn't active yet. But block explorers like mempoolspace display these txs as if they are P2SH spends, i.e. they DO evaluate their redeemscript. (See screenshot.) I suspect that's a bug.
https://image.nostr.build/bc1e2abf05b195cdd328b409aba0cf700d0bce842e7201e9356994962f2331e9.jpg

2025-12-16 21:26:30 UTC

Interesting, was the P2SH upgrade confiscatory? https://bitcoin.stackexchange.com/questions/115803/did-the-p2sh-bip-0016-make-some-bitcoin-unspendable/115804
https://image.nostr.build/45567020015c3ff443ee0cde84f688c18b289477f90a2bd3038a800caddbb698.jpg

2025-12-16 17:32:01 UTC

- reply

An LLM told me it's because the pre-segwit sighash algorithm predated the bip process, but it still seems appropriate to me for an informational bip to specify how to do such things

2025-12-16 17:24:59 UTC

One of the things I like about bip143 is its detailed specification of the segwit sighash algorithm, screenshot attached. Why isn't there a bip that outlines the corresponding specification for pre-segwit (legacy) transactions?
https://image.nostr.build/874aa9750886dabc66244a1e4538313498f7938e6ee29b6c21124063056e2fa0.jpg

2025-12-12 19:05:32 UTC

My latest invention is Lotto Miner, a webapp where you can attempt to mine a bitcoin block in your browser and put the block reward directly in a bitcoin address of your choice. You can also mine on regtest, where you are more likely to succeed.
Try it here: https://supertestnet.github.io/lotto_miner/
Video demo: https://www.youtube.com/watch?v=1w8Fq8HejhU
The difficulty setting is low at first, but you can increase it til it matches that of the real bitcoin network. Raising the difficulty will take increasingly more work and, probably, more time.
The source code is: https://github.com/supertestnet/lotto_miner
I made this to help folks learn how bitcoin's difficulty assessment algorithm works and gain an appreciation for how much work goes into mining bitcoin blocks. Also, I'm not aware of any open source tools for creating custom bitcoin block templates on regtest, and this is a starting point for such a tool. The codebase is pretty small and since it produces valid regtest blocks, devs should be able to customize it to suit their regtest needs.
Try it out and have fun!
https://supertestnet.github.io/lotto_miner/

2025-12-08 17:46:55 UTC

- reply

In its current version, this block explorer *does* need electrum, because that's where node_faker gets its block data from, which it passes to wild_explorer.
However, I *could* make a version that talks directly to a real instance of bitcoind instead of node_faker. The would node would need txindex=1 enabled, but it could work.
That said, there is already a project that's designed for that use case: https://github.com/janoside/btc-rpc-explorer -- so check that out if you're interested in an electrum-free block explorer

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-07 17:00:15 UTC

- reply

But why is that rule there in the first place? Answer: for moral reasons -- because doublespending enables fraud

2025-12-07 16:58:17 UTC

- reply

> Nowhere did the white paper mention the word "fraud"
It uses it three times
https://image.nostr.build/437e4c506f88dddb35101d1a04254da8fb13ead4f717a55f5c174aa0bd36d95f.jpg https://image.nostr.build/e91face6ac646cc4f0bc0d14900064eeda3b4081dcba1c4e6999ec9b3c47b7ab.jpg

2025-12-04 18:52:45 UTC

- reply

> Miners can do whatever for whatever reason
Can they create more than 21 million bitcoins? No? Then they can't "do whatever for whatever reason." The consensus rules stop them. So node runners can modify their behavior by changing the consensus rules.
> You might have thought framing it morally was cute or whatever, but its all practical
Are you saying the consensus rules I listed are not there for moral reasons? If so, then why are they there? Why is there an anti-doublespend rule except to protect against fraud?

2025-12-04 18:36:16 UTC

- reply

I am happy to discuss the effectiveness of spam limits in another thread. In this thread, my aim is to get consensus on this proposition:
it's sometimes okay to block other people's transactions based on moral objections
Got a problem with that?
Then you'll have to get rid of the 21 million cap, doublespend prevention, and proof of work. Because those all exist to block other people's transactions based on moral objections.
So what do *you* think? Is it sometimes okay to block other people's transactions based on moral objections?

2025-12-04 18:35:12 UTC

- reply

Are you saying it's possible to construe "fraud" as if it was a non-moral term? How so? In what sense is fraud ever not a moral thing (specifically, a very immoral thing)?

2025-12-04 16:22:37 UTC

- reply

No, I'm saying some of the technical specs, including the 21 million limit, exist to enforce an anti-inflationary system of monetary morals. Some people on the Core side argue that bitcoin should not block transactions if the reason for doing so is moral; if they were right, the 21 million limit should be dropped, because it exists to block inflationary transactions for moral reasons. Inflation is frequently used by governments to effectively steal from their populace by printing money without honest work, and that is bad, so such transactions are not allowed in bitcoin.

2025-12-04 16:05:23 UTC

- reply

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

2025-12-04 12:30:46 UTC

- reply

> Are morals objective in this proposal?
As objective as the other morals enforced in the consensus rules, such as the anti-doublespend rule, the supply cap, and the proof of work requirement
To me, asking "What if the spam limits lose consensus in the future" is similar to asking "What if the 21 million cap loses consensus in the future"?
I think that would be a bad thing, and I would advocate for restoring it

2025-12-04 11:45:57 UTC

- reply

I oppose bip110 for that very reason, alongside some objections to how it handles OP_IF. But in this thread I am not trying to convince people to support bip110; I'm only trying to convince others to stop saying "BuT yOu'Re TrYiNg To EnFoRcE yOuR mOrAlItY" as if that's a no-no in bitcoin instead of a large part of why it exists.

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?