OrangeSurf

Public Key

npub18h0w55nsp839ezxnggf00jd2xc6yl0ht62mf5p8wwllu8s80wdcs83ws8m

NIP-05 Address

Profile Code

nprofile1qqsrmhh22fcqncju3rf5yyhhex4rvdz0hm4a9d56qnh80l7rcrhhxugpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq32amnwvaz7tmjv4kxz7fwdehhxarj9ehx2aq908zhp

Publishing to

Author Public Key

npub18h0w55nsp839ezxnggf00jd2xc6yl0ht62mf5p8wwllu8s80wdcs83ws8m

Show more details

Last Notes

2026-04-01 11:23:16 UTC

There's only two charts in bitcoin that matter, and price isn't one. The first is the hashrate and the second is the number of @nprofile…jemv merchants - @nprofile…gyz0 at @nprofile…5rn6
https://blossom.primal.net/b1ca764c18d4d6843826a6ca3342ce752ec2748664f10de3a4095e58f694b0c2.png

2026-03-30 22:44:42 UTC

- reply

Glad I held off using the integrated primal wallet until now, I’m sure it was great UI but this is the way 🫡
It’s seamless, Phoenix > Primal in under 5 seconds, super clean design, and crucially zapping Just Works
#nevent1q…eq5p

2026-02-15 18:04:09 UTC

There's been lots of debate about Core v30 removing the OP_RETURN size/count policy defaults, so I ran the numbers for the latest mempool research report: https://research.mempool.space/opreturn-report/
There were three big waves of OP_RETURN usage: 2019, 2024, 2025. Nearly all standard transactions. The nonstandard ones are so rare you can hardly see them on the chart.
https://blossom.primal.net/e653b32fb6281c2c8f61252dbd72d1b3c2c66e57059573a06eb72d5d66812da0.png
The 2019 Veriblock wave actually put more data on-chain than anything since. People talk about recent OP_RETURN usage like it's unprecedented, but surprisingly it isn't.
https://blossom.primal.net/a21d64ede3043825d6df2f08c7c5c6109904b6f5d5b07514488c3e69ce4f405a.png
The important thing is that the spikes in nonstandard OP_RETURNs were in Mar 2024, May 2025, Aug 2025. All before v30 shipped in November 2025. The rate hasn't gone up since. At all. In fact it's come down
https://blossom.primal.net/085a690b1081921e41b84e7c2749adc66eb3ad578f4e44e8bd8135551a7384d8.png
Runes transactions were standard under the old rules and would even still be standard for #BIP110 (the proposal that's supposedly aims to curb data embedding). If these guys are serious about stopping data they should block runes.
https://blossom.primal.net/7634c6534ecbdc21a9e51468daa12ab9c989985b33a232b8e7035f22bfaff58e.png
TL;DR: v30 recognised what was already occasionally happening on-chain. Nonstandard OP_RETURNs are vanishingly rare, haven't increased post-v30, and the current wave is already cooling off. The data doesn't support the panic.
Read the full report linked below 👇
https://research.mempool.space/opreturn-report/

2026-02-12 13:28:17 UTC

- reply

(A draft PR, but you can build yourself / use the emulator)

2026-02-12 13:27:29 UTC

- reply

Fast work by @nprofile…0dst who added this within 5 hours of receiving my suggestion.
https://blossom.primal.net/295b07dcbed266df63db67a24372a060d34dc34468ea99db40d378f21ceb3764.png
https://blossom.primal.net/740248205ea47005516bfa6b9a36857d5f925f8ac9cec425c2754169141a4d75.png

2026-02-12 13:26:08 UTC

As signing device developers begin to add support for BIP322 it would be great to have on-device message viewing. I've sketched out an idea of how this could be done with QR & vis SD.
https://blossom.primal.net/859ba3fe01a6a25a2a6177fa0d15aedba0d8f15fd579c17c2117c8b1a778ac60.png
https://gist.github.com/orangesurf/0c1d0a31d3ebe7e48335a34d56788d4c

2026-02-12 11:46:15 UTC

- reply

https://lightning.engineering/posts/2026-02-11-ln-agent-tools/

2026-02-10 12:49:20 UTC

Sparrow just added address chunking which is really nice, I've made an extension to experiment with this on mempool, try it out and let me know if you have any feedback
📂 Get Extension Here:
https://github.com/orangesurf/mempool-chunker
https://blossom.primal.net/f9c9cd0aad88f0c0ff1fab2058a09e0ac2135990dace1ea37d439dc290d0cc99.png

2025-12-22 14:54:51 UTC

- reply

https://blossom.primal.net/e82c5f7538583e90be0c1ddc9216008042d67eebfc073309447824666889c55f.png

2025-12-22 14:45:32 UTC

- reply

Would you expect to know if a government was making advancements towards a CRQC?

2025-12-14 04:12:21 UTC

Instead of copying long invoice strings, let’s use payment method cards
https://primal.net/orangesurf/bitcoin-payment-method-cards

2025-11-06 06:07:02 UTC

The much discussed bitcoin stale block rate, visualised
https://blossom.primal.net/e86a2c338807b03a1117b0060517b5ec6320b0fa0e69d2b2b896a6b9d9149959.png

2025-11-02 08:39:31 UTC

Just noticed someone taking advantage of low fees by consolidating 59000 tiny utxos at 0.2 sat/vB across 40 transactions.
That's 4 blocks worth of transactions (3.999 vB) in total!
bc1q3k0swnar7s4w3lcp4u3vys826z8vc2f2t87hu5
https://blossom.primal.net/f082c8f76a8625ef87617d72b6262a2aa804a8cb273086f4ec73bce4d3513dde.png

2025-10-31 04:39:20 UTC

wallet devs, are you ready to embrace sub-sat winter?
https://blossom.primal.net/a6070fe78f9837569b8b48e0f5fc16119a89d7aab205a80cfa257301108c62fc.png

2025-10-28 03:55:14 UTC

It's times like this that I'm glad I spent 2 minutes vibe coding a button to expand all hidden messages on the bitcoin github repo.
https://blossom.primal.net/1d159627ea79b723b5bbb61a8133b2dfa02266075aac5226a5dde8ddec275136.mov
Code: https://github.com/orangesurf/github-unmoderated

2025-10-13 02:33:03 UTC

opreturn stats for last month, you might be able to spot the previous default limit. What do you think October will look like?
https://blossom.primal.net/2dde6aa19c236642ba11afafcdfec6a5ebaaace508b83a84281336c66c077751.png

2025-10-08 09:21:55 UTC

Sub 1 sat/vB summer will be studied by generations to come
https://blossom.primal.net/49ec8b87e1d0f601fcfe9efb7dfd1a4a8d106509ccaaaa78f36ba501fd27c7e3.png

2025-10-06 08:41:14 UTC

- reply

Done, good idea
https://stacker.news/items/1249538

2025-10-06 07:53:11 UTC

Seeing a few comments asking what can be done about data embedding with unspendable UTXOs (an issue which has been around for a long time).
This is a bit long, but hopefully it will be useful as a reference to the more general question of whether you can address protocol level “problems” at the miner / policy level.
Realistically, short of a soft fork there is very little that can be done technically, and even that would have serious limitations & fallout (that’s the whole point of this gross protocol design).
The obvious first reaction is ask miners to stop mining things like this. There are a few ways, but one would be to increase their -dustrelayfee
By default it’s 0.00003 BTC/kB (3 sat/vB) resulting in a dust output limit of 330 sats for P2WSH.
For this transaction with 1859 such outputs the total locked in unspendable outputs is 1859*330‎ = 613,470 sats ($736 @$120k/BTC)
Lets say you successfully lobby the vast majority (95%) of miners to 10x this config value, the sender would have to choose between paying 6.1M sats ($7k) or sending as is and waiting until the small proportion of miners (5%) using the old default. They would probably do the latter because that’s enough hashrate to find 7 blocks/day on average, and what’s the rush?
Having failed to stop this at the miner level you may now be tempted to lobby node runners to change their default and/or change the default in core v31.
Say you were successful, and core v31 contains a higher default. The sender can just preferentially peer to try and reach miners in protocol.
So you double down and you spoof preferential peering such that it’s not sufficiently reliable.
The sender now has no choice but to pay a miner OOB - if they are to do this they might as well make each output be 0 sats. This could actually be mutually financially beneficial for the sender and miner, because instead of sats being burned as fees they would flow to the miner / be saved by the sender.
Now to be fair it would take effort to establish these direct rails to miners who are exclusively financially motivated, but this is a fixed cost, and I have no doubt it would be done, and then integrated via API to centralized minting services.
Thus, the problem would likely end up being worse than the situation we have today.

2025-09-30 10:30:09 UTC

Inscriptions & OP_RETURN transactions still make up 40% of bitcoin transactions by count, 10% by fee and 28% by weight.
https://blossom.primal.net/3996e69b2ee6c03ebd34ef4a83c1300af0be076503a1a2e1e96b1cb91f359857.png

2025-09-25 08:21:59 UTC

Everyone can agree that we need more decentralized block template construction.
Core sees private tx broadcast as a threat to that (which is fair imo), which is part of why they are widening default policy rules.
Most filter proponents are vocal ocean supporters. Ocean have already materially increased the number of entities (who are actually finding blocks) doing template construction with DATUM, currently I imagine most of these individuals are using knots, and interestingly many don’t filter out all “spam”.
Knots has (iiuc) a single individual who decides what gets merged, and no doubt eventually there will be something he does / doesn’t do that will be perceived as an artificial restriction on user choice.
Ultimately, the only way miners will have sufficient choice without restriction will be if they can construct their own policy (with ease) and we have already seen an example of this (Knots Lua Pull) and a more recent BIP draft to do the same in Core (see mailing list, not received well)
The (perceived) threat with anything like this, is that “actual censorship” is as easy as mandating the inclusion of a filter file, and template construction is sufficiently centralized currently that IMO this is a reasonable concern.
Which brings us back to the point on which we have unanimous agreement: there is a pressing need to decentralize block template production.
Any action to decentralize block template production should be celebrated.
Knots Lua Implementation
https://github.com/bitcoinknots/bitcoin/pull/119/files
JS BIP Draft
https://github.com/dr-bonez/bips/blob/mempool-policy-scripts/bip-mempool-policy-scripts.md

2025-09-19 22:34:50 UTC

We must stop people putting data on Bitcoin, it’s a payment network
Meanwhile: every lightning commitment transaction encodes a 48-bit commitment number across nLockTime & nSequence

2025-09-12 18:54:26 UTC

Someone is consolidating large batches of UTXOs at erroneously high fee rates.
In the last 7 days they have overpaid by over 5 BTC ($580k) 🤯
They could instead just use 1 sat/vB and RBF if needed (or use Mempool Accelerator Pro and avoid any complexity😉)
196 tx match the following pattern between block heights 913374 - 914379 (past 7 days).
- Minimum Input Count: 100
- Output Count: 2
- Fee Rate: Between 101.6 and 101.7 sat/vB
Total fees: 5.43388700 BTC

2025-09-11 10:12:59 UTC

1 sat/vB is clearing but someone just made a consolidation at 102 sat/vB 🫥
https://mempool.space/tx/23b87e424aa51d4900267350c1ad88995c4c132c706c0d6cb80e3cd31971e00e?mode=details
https://blossom.primal.net/4a0790a38fe7075141346589f490a740b87ddcd0a75b1b19069fa7a33a9c6104.jpg

2025-08-28 20:36:23 UTC

Sense check
Despite a dip in activity there are still 267k “legit” transactions per day.
(Average non OP_RETURN related/Inscription over the past 90 days)

2025-08-21 21:24:37 UTC

Over the past 1000 blocks, more than 30% of transactions have been below the longstanding1 sat/vB default min tx relay fee limit.
https://blossom.primal.net/23e9b2ea50fc23f31a7cf59863a331e95919a06d2a85c56383e67e342d47a416.png
If we plot the actual data, we see spikes around round feerates (1,2,3,4 sat/vB) and a (surprisingly ?) large spike in the sub 1 sat/vB fee rates on the right hand side.
https://blossom.primal.net/a18143c5598bf9fa09f54dc026bae5d750285ddc3216188a3cb89732c1e282bc.png
We can animate this graph with a 1000 block sliding window for the month of August.
https://blossom.primal.net/c69fc3f5061f620e604bb0363f8ad03ecb0d2195ab964840f3cfae57b369a17e.mp4
There is a wide range in the proportion of blocks which are < 1 sat/vB, but the 144 block rolling average has been on an uptrend in recent months (shown here is data since June, block 900000)
https://blossom.primal.net/aa1cd802fc42a8cfc8cf32b99c41d0babedf8270f9ed3b5112db05ed26ff4772.png

2025-06-15 19:25:07 UTC

grid.orange.surf
https://blossom.primal.net/92c50ef20078fd2b9df660e46b9cdbbab7f73a5e66ca666b9aa1417c92aaa574.png

2025-06-15 13:43:39 UTC

> it only takes one determined spammer to make a tool to allow the less determined to spam. - @npub1zfy…m60l
This is the asymmetry that many filter proponents seem to miss.
Most of the kind of transactions they wish to filter out are created using dedicated software (services / tools / platforms).
Developers of such software can rapidly bypass any restriction using open source software like libre relay, which will get their transactions to miners.
We already see this, with some platforms offering the ability to select broadcast method from a drop down, including direct broadcast to some miners.

2025-06-14 21:29:28 UTC

- reply

Both! Either?

2025-06-14 12:33:00 UTC

- reply

yeah, it's useful as a data source, you are not really using core as a wallet (signing, key management etc). but due to the design of core a watch only wallet file is created to track the addresses

2025-06-13 08:05:25 UTC

Did you use the bitcoin core wallet in the last year?

2025-06-10 13:41:38 UTC

@nprofile…2xpe and I are arriving early for @nprofile…py4c.
Get in touch if you are around from the 14th and want to meet up!
https://blossom.primal.net/a9b67cad3adec53c0b7ee6f88d73c1e949dff0ae8b4a2dc7e5f2f96157b87664.png

2025-06-09 15:37:28 UTC

Which filter do you think core will drop / change the default for next?
- Max Transaction Size
- Minimum Relay Fee
- Minimum Output Size

2025-06-08 22:50:09 UTC

What do I do?
Research: I publish chart filled data-driven reports on technical Bitcoin topics. Read at http://mempool.space/research
Business inquiries: I lead strategy and business development at
@nprofile…wnpf. Reach out directly for questions about Mempool Enterprise & Accelerator

2025-06-08 22:15:18 UTC

So many based bitcoiners at bcc8333 unconference.
If you are in Barcelona check out their meetup
https://www.meetup.com/bitcoin-barcelona/

2025-06-06 06:01:42 UTC

Block 900,000, had room to spare despite a celebratory meme inscription.
https://blossom.primal.net/f7c2687117af5b42eb58afea1e2d4dc4d1de665aaf879704db941fedf40bca3f.jpg
https://blossom.primal.net/06bb60cdc53624b786f6f22398af86bc1945f57b927b14cc5bb68fb42cc548c4.jpg

2025-06-04 07:13:21 UTC

- reply

This works really well

2025-05-29 19:55:43 UTC

- reply

love to see it, we should talk 🤙

2025-05-28 12:41:23 UTC

Unbelievable lack of use
https://blossom.primal.net/e77e78cfb71c4b0ee85d6b29da9dca927a872e3ecb6ed43bd6229f5591b355c3.png

2025-05-23 14:52:13 UTC

- reply

Thank you 🙏

2025-05-20 04:21:20 UTC

41.65% of the UTXO set is dust amounts precisely at the implied default core policy dust limits for various script types.
note: p2tr is the most popular 546 sat script type (68% of all 546 sat outputs). I guess degen wallets don't compute the actual dust limit?
https://blossom.primal.net/b0820294e04b9bf195d7084d033cacd0ba3e21ca8bc7b8296347fd903205ab0e.png

2025-05-19 23:12:14 UTC

Surprising facts from my new report on Bitcoin's UTXO set:
- 49% of UTXOs are sub 1000 sats
- 30% of UTXOs are inscriptions related
- 100k+ 10-year-old counterparty UTXOs store arbitrary data with fake multisig pub keys
Read it in full here:
https://research.mempool.space/utxo-set-report/

2025-05-19 05:16:36 UTC

- reply

Fee

2025-05-19 04:45:58 UTC

https://blossom.primal.net/76a21bc9a4a4e5d7123e4050a7081cbe080097e4ca17557628eeed15ffdcc7b0.png

2025-05-19 04:31:52 UTC

By popular request, here is the last years bitcoin transaction data with rune & BRC20 split out from other OP_RETURN and Inscription transactions.
Runes & BRC20 = 51% of transactions over the past 12 months
https://blossom.primal.net/745e98bf3be0796f038d8cae5dae76898f94d8f5f11ed419afaef19fce80893b.png

2025-05-19 03:02:51 UTC

https://blossom.primal.net/57f1e53e32604fe146d2268589703e1dc4c492c4827dfcc4c9f6499f3083a325.jpg

2025-05-18 16:43:42 UTC

Over the past year bitcoin there have been more data storage transactions (inscriptions & OP_RETURN) than other transactions.
https://blossom.primal.net/296f78229a504abba9e1f8f0867037065049fcc7c2a1d2a6dfe315cee1f6e8e1.png

2025-05-08 11:48:29 UTC

The most entertaining outcome is the most likely. Bookmark this.
https://blossom.primal.net/690f3e9253f872b1b5da9c0ea90a9317ab465771a23d2ce87e6273bf5b28d1c9.jpg

2025-05-08 11:32:34 UTC

Get yourself to a @npub1dwa…7c52
event, what @nprofile…dtke and the team have built is truly special.
The difference between online and IRL discussion is stark.
Online we only see differences.
IRL people celebrate similarities.

2025-05-06 01:59:21 UTC

- reply

What has changed since 2023, when pull 28130 was closed with the justification that “it's unlikely that Bitcoin Core is going to make any changes in regards to OP_RETURN”?

2025-05-06 01:47:02 UTC

I’m seeing lots of speculation around the financial motivations with regards to modifying OP_RETURN standard core policy.
In 2023 Peter Todd was transparent with his financial incentive ($1000 from Christopher Allen) for making pull request 28130, which was ultimately closed
https://github.com/bitcoin/bitcoin/pull/28130

2025-05-05 20:51:41 UTC

🎲 In 2014 Luke Dashjr described mining policies such as OP_RETURN size limits as not being a development topic, and suggested randomizing the default value.
https://gnusha.org/pi/bitcoindev/[email protected]/

2025-05-05 12:54:43 UTC

- reply

The conversation is still locked. My guess would be a push behind a new pull which doesn’t remove configuration options and only changes defaults

2025-05-05 02:22:40 UTC

The latest OP_RETURN war kicked off days prior to @npub1dwa…7c52 mempool edition. very sus. In Austin to get to the bottom of this 👀

2025-04-30 17:41:36 UTC

- reply

lol wut

2025-04-30 12:32:14 UTC

- reply

The legend didn't render correctly
https://blossom.primal.net/7c315d9b2ab8bab17e645f2737af639a067a63f28e40344acc49bef07cfbced9.png

2025-04-30 11:52:06 UTC

I've put some numbers together to help you determine whether the horse has already bolted regarding the use of bitcoin for non financial transactions.
49% the UTXO set is sub 1000 sat outputs
43% of transactions in the past 2 weeks had an OP_RETURN or were inscriptions.
https://blossom.primal.net/be33911765f6d7dc5f61fc459eb0415dc0966c9a113d33115e8b042b5b0f2612.png

2025-04-30 09:57:34 UTC

I think there is a strong argument to be made that even if you hold the opinion that bitcoin is for financial transactions, not arbitrary data storage, the figurative horse has bolted and efforts to close the stable door are currently futile. The argument looks like this.
1) There are people who want to encode arbitrary data, and are willing to pay for this. Systems are being developed which use arbitrary data pushes to enable bitcoin financial transactions to happen on sidechains/layers, blurring the line between financial transactions and the arbitrary data most people think about (jpegs on the blockchain).
2) Blocking arbitrary data at the relay layer is a sisypheancan task which nobody has succeeded to do for a prolonged period of time.
3) Even if successful the relay network can and will be trivially bypassed if block template builders wish to accept these transactions which encode arbitrary data. So you need template builders to be on board (the more the better).
4) The current block template builders are not likely to be on board, as it goes against their short-mid term financial incentives. This is because they are typically
(a) disengaged / ambivalent about bitcoin development (see radio silence regarding new soft fork discussions)
(b) In favour of any and all use of blockspace which will increase revenue (see the direct submission services, use of librerelay, prevalence of side chain mining)
(c) Of the opinion that their fiduciary responsibility is to construct blocks containing valid transactions which generate the highest possible revenue for their customers.
4) Even IF you were able to successfully persuade template builders to filter these transactions (say by decentralising template construction into the hands of more ideological lower time preference miners) there will be disagreement about what level of data encoding is acceptable, with some arguing that it is permissible in certain formats, and with hardliners arguing that all arbitrary data should be eliminated. The fragmentation will result in some arbitrary data being trivially pushed into the chain.
5) Even IF you were able to persuade the overwhelming majority of hashrate to reject arbitrary data inclusion it becomes difficult to reliably get transactions which clearly encode arbitrary data into blocks, the data would end up being encoded in a slightly less efficient manner with a 2x cost burden.
6) If 2x cost burden is sufficient to stop arbitrary data encoding then it can easily be priced out. If not, all that effort would be wasted because it wouldn't achieve the desired outcome.

2025-04-29 16:59:43 UTC

- reply

Knots does much more than a “simple” filter fix, and personally I don’t think it has enough reviewers to recommend it’s use

2025-04-29 13:21:04 UTC

A message to those on team #fixthefilters - your time would be better spent earning sats, which you can then use to fund development of a bitcoin node implementation which implements your desired configuration options. It's a cat and mouse game and the cat is currently asleep.
https://blossom.primal.net/a9c918c311720b1ce59254e5d4d592fec6638555bc5ac026b664d7c35d09f09f.png

2025-04-29 13:02:09 UTC

adding policy rules as a non mining node makes about as much difference as posting your opinion on the github pull request
both sides agree on this 😂

2025-04-29 09:32:50 UTC

- reply

Call for transparent development
In my opinion it is critical that bitcoin developers have an opportunity to verify that these nonstandard transactions don't pose DOS risks. With that in mind, it would be great to be able to perform benchmarking on these transactions prior to them being widely deployed on chain.
If you are building systems which use nonstandard transactions, I would love to discuss this with you!
I will post more about this in the future, if anything was unclear please comment below!
Note: There is also the set of transactions using upgrade hooks, where pretty much everyone benefits from not including certain transactions. Ideally we can ensure that there is no economic demand for these, because they make upgrades much easier.

2025-04-29 09:32:33 UTC

- reply

If economic demand for these transactions grows, it is reasonable to expect that some miners will relax the policy rules on their blockmaker node to earn this extra revenue.
These transactions won't relay over the standard bitcoin core p2p relay, so they will either be submitted directly to the miner (e.g. slipstream) or over an alternate relay path (e.g. opreturn bot using libre relay). Once mined they will be downloaded by all nodes in the network.
From my perspective, it's inevitable that systems will be built to get valid transactions to miners if they can't be relayed p2p. This has already happened, and will likely continue to happen as people develop systems which require the use of nonstandard transactions.

2025-04-29 09:32:14 UTC

- reply

Ideally the standard transactions & DOS transactions sets don't intersect, that's the intention of most policy rules.
Note: There are some who believe that policy rules should be used to guide the use of the permissionless network. Personally I think this is a folly when there is an economic incentive.
It's relatively simple to ensure that the standard transactions and known DOS transactions don't intersect because they are both well defined. It's harder to know whether the standard transactions and the unknown DOS transactions don't intersect, but we can reason about how we would construct a DOS transaction and then add some policy rules. For example, we can set a limit on the total size of a transaction, which will presumably mean some unknown DOS transactions are now non standard (and our node is protected).
So to be prudent we can add in lots of policy / standardness rules to protect us from unknown DOS transactions, which makes our node less vulnerable. The tradeoff is that in doing this we also make some safe (non DOS) transactions non standard. Arguably this is what happened over the years with bitcoin core, and for good reason.
This is a key point when considering policy rules. Our understanding of what transactions potentially result in a DOS risk is undoubtedly incomplete, and the widespread adoption of current bitcoin core standardness rules might be protecting the network more than we realise. But, having strict policy rules is also making some perfectly safe transactions non standard. For miners, these non standard, known non DOS transactions represent a safe source of extra revenue.
https://m.primal.net/QhEf.jpg

2025-04-29 09:31:40 UTC

- reply

Another subset of valid transactions are Denial of Service (DOS) transactions, which for one reason or another will cause a node to have a bad time. For example a DOS transasction might crash the node, or cause it to take a very long time to validate. We know about a number of DOS transactions, but presumably there are some DOS transactions which we don't yet know about. So we can add to our diagram two circles, one for all DOS transactions, and within that a smaller circle for the known DOS transactions.
https://m.primal.net/QhEe.jpg

2025-04-29 09:31:17 UTC

- reply

Next we have standard transactions, which are the transactions permitted into the mempool of a node according to it's policy rules.
The default policy rules which come packaged with the latest bitcoin core release are generally adopted by the network within a year. Each release with new policy rules will result in different set of standard transactions, so it's a moving target, but on any given node the rules are set at any given time.
Each node can configure it's policy rules as it sees fit (in theory, more on this later) and transactions must first pass consensus rules before considering policy. This means that there is no risk that using different policy rules will break consensus. Another way to say this is that standard transactions are a subset of valid transactions.
https://m.primal.net/QhEd.jpg

2025-04-29 09:30:50 UTC

- reply

Here is a quick introduction to what bitcoin policy rules are
We start with (consensus) valid transactions. These transactions abide by the bitcoin consensus rules which all nodes on the network enforce. For example, a non coinbase transaction can't spend more than the sum of the inputs.
https://m.primal.net/QhEb.jpg

2025-04-29 09:30:20 UTC

The recent pull request to bitcoin core made by peter todd (pull 32359) removes the code to enforce a policy limit on the size and number of OP_RETURN outputs. Additionally, he proposes the removal of the configuration options to allow node runners to modify the maximum size of data carrying transactions.

2025-04-28 19:41:20 UTC

If bitcoin core doesn’t have the functionality that you want you can build it, and share it with the world.
If other people share your views they can also run that code.

2025-04-25 09:35:40 UTC

- reply

Examples of users
The High-Ticket Merchant
Sells expensive goods with incoming funds straight into cold storage. Can’t (or won’t) leave a hot key online for CPFP, and asking the customer to bump the fee is awkward. An auto-accelerator guarantees confirmation so the product can ship without delay.
The Multisig Treasury Custodian
Manages a 3-of-5 vault for a family office. Gathering three signers to recreate an RBF transaction is slow and costly; the automated bump removes that operational friction.
The Air-Gapped Solo Stacker
Signs a single-sig transaction on an offline device just before boarding a long flight or going off-grid. With no way to reconnect, the auto-accelerator acts as a safety net if the initial fee estimate was too low.
Payroll Controller
Payroll is broadcast on Friday and the finance team is away for the weekend. If the mempool spikes, the auto-accelerator silently bumps the fee so employee pay doesn’t wait until Monday.

2025-04-25 07:39:51 UTC

You are making a transaction, you check mempool and set what seems like an appropriate fee, but then a new degen mint drops and your transaction gets buried. New transactions coming in push your transaction further back, and 24 hours later it's 10 blocks deep.
Fortunately you used Mempool Auto Accelerator with a 24h Time Delay trigger, and your transaction confirms in the next block.
I have 10 beta access spots, dm me.
https://blossom.primal.net/cb304169e7a2a3f54542da15f0695a1109f21a5ed9c3ee10fb75fc137f990576.png

2025-04-23 18:18:37 UTC

- reply

Thanks for the mention!

2025-04-23 07:19:44 UTC

If you are building something on bitcoin and use @nprofile…wnpf every day I want to hear from you, drop me a message.

2025-04-15 06:58:55 UTC

"solo mining" is currently confusing as a term because it's being used to mean different things by different people (often with an agenda).
Sovereign Mining: You select the transactions
Lotto Mining: You get the full block reward

2025-04-08 10:26:51 UTC

The Mempool Open Source Project® v3.2.0 is here 🚀
Highlights:
- Support for v3 transactions
- Support for anchor outputs
- New UTXO bubble chart on the address page
- DATUM miner tags
- Tags to identify runestone messages and inscriptions
- Package broadcast
- Stratum job data visualizations
- Taproot multisig labels
- Transaction & PSBT preview feature
- Address poisoning detection
https://github.com/mempool/mempool/releases/tag/v3.2.0

2025-04-01 01:58:17 UTC

Even with the mempool this empty, it's possible to get your transaction stuck for 1 hour by using 1 sat/vB instead of 1.1 sat/vB
https://m.primal.net/QABv.png

2025-03-22 17:38:38 UTC

A third of all transactions in the past 30 days were BRC20

2025-03-18 20:56:02 UTC

- reply

viewers might find this of interest
https://orange.surf/bitkey-notes/

2025-03-09 16:32:07 UTC

What is the best long form criticism or caution regarding the strategic bitcoin reserve?

2025-02-02 18:49:29 UTC

Q/ Wait how is the Mempool now 22 blocks deep!!?
A/ Well this one address (
Possibly “CoinCola” from a quick search) is associated with 926+ chunky consolidation transactions which are now in the mempool. Nature is healing.
https://mempool.space/address/1PM46U2c5LhkcQXnHwfwQU6V1y4F4L7Ct4

2024-09-07 13:53:36 UTC

- reply

Thought the video was attached to your post for a moment.
🤙
https://m.primal.net/KiFg.png

2024-09-06 18:42:32 UTC

Have you ever used testnet?

2024-09-05 17:32:11 UTC

- reply

When you find out add to https://testnet4.com 👍

2024-09-05 15:44:05 UTC

There’s a two tier block space market
You’d best hope your fee estimator is legit
https://m.primal.net/KfeR.png

2024-09-05 10:02:52 UTC

- reply

That's annoying, I have had other people successfully zapping. What app are you using?

2024-09-05 09:05:42 UTC

- reply

Thanks Dean ⚡️Would you use this?

2024-09-05 08:21:45 UTC

Concept: VIP MODE
Show one post from each person you follow first.
Why? Today, unless people post and interact regularly they just disappear from their followers feeds. IMO this results in larger amounts of lower quality content.
What do you think? Which nostr client do you think will be the first to add VIP MODE ?
https://m.primal.net/KfEo.mov

2024-09-05 08:04:20 UTC

- reply

Thanks, fixed

2024-09-05 08:04:09 UTC

- reply

Thanks, fixed

2024-09-05 08:03:41 UTC

- reply

Why would I want custodial?

2024-09-05 08:02:51 UTC

- reply

Thanks Matt, done

2024-09-04 23:11:20 UTC

Self sovereign zaps are back ⚡️
Thanks for the push!
https://m.primal.net/Kecb.jpg

2024-09-04 10:53:53 UTC

- reply

Thank you for taking the time to write a thoughtful reply.

2024-09-03 17:44:08 UTC

I want to use nostr more but it feels like I am shouting into the void, probably a skill issue

2024-08-27 20:17:56 UTC

- reply

How about an onboarding option to disable the wallet, which remains hidden unless reactivated in settings @miljan ?

2024-08-16 12:49:01 UTC

What is the nonce key exfiltration attack?
When signing a bitcoin transaction a number is used to generate the signature, this number is used once, and is therefore called the nonce.
This should be a cryptographically secure random number, which is never reused.
Suppose an attacker compromises your signing device, and can get it to use a particular nonce, rather than a random number.
If they use part of your private key as the nonce, they can leak part of your private key out of your signing device with each transaction you sign and broadcast.
If you make enough transactions, they can reconstruct your whole private key, and steal your bitcoin, just by watching the bitcoin transactions being made and decoding each part of the private key.
They don't need to compromise your computer, or physically access your device, and all the while your signing device appears to be working correctly, up until all your bitcoin is stolen.
There have recently been two new papers expanding on this attack.
- Dark Skippy by Lloyd Fournier, Nick Farrow of FrostsnapTech and Robin Linus of ZeroSync and BitVM.
- Engineering a backdoored bitcoin wallet by Adam Scott and Sean Andersen at block
I think it's great that these researchers have raised attention to this previously known attack vector.
Now, there are two types of reaction in my x feed on this issue, panic and ambivalence.
⚠️ Reaction 1 - Panicked
Nonce key exfil would enable theft at a distance, on all devices that update to malicious firmware & make 12 transactions. The attack doesn't require compromising the online device the signer talks to. The attack is not mitigated on most signing devices, and therefore large amounts of bitcoin are potentially vulnerable. The attack would be undetectable until the thieving begins
🤷‍♂️ Reaction 2 - Ambivalent
This attack requires getting malicious firmware onto a device. Competent signing device firmware devs secure firmware signing key(s) appropriately. Provided the firmware signing keys are not compromised this attack is mitigated because most signing devices check new firmware signatures before upgrading. Malicious firmware would enable many other attacks like generation of compromised wallets or exfiltration of keys in other ways (via screen, microSD or USB).
I think both Panic and Ambivalence are extreme.
❌ Panicked - Most hardware wallets verify firmware signatures so this attack requires either malicious firmware or a compromised firmware signing key / build pipeline and for many transactions to be signed with that firmware. Anti-klepto requires the online wallet to participate and adoption is limited. Creating panic leads uninformed users to rush to move their bitcoin to a new setup and this is when mistakes happen.
❌ Ambivalent - This attack is particularly nefarious because it can be done at a distance without needing to compromise any other user devices which makes it very scalable. If any firmware release is compromised all devices that run that version will be compromised. How secure is your signing key? How secure is your build pipeline? If anti-klepto was widely supported you would probably use it, so let's get it widely supported.
💡 Constructive - Focus effort into adding anti-klepto to a new version of PSBT instead of taking shots at each other or dismissing concerns.

2024-08-13 14:40:45 UTC

Using the public @npub18d4…6lt3 accelerator API you can now fetch a lightning invoice to boost any transaction.
Integrate into your app / service today.
https://m.primal.net/JyUE.mp4

2024-07-26 12:36:00 UTC

A very limited batch of the display stand I designed for @npub1s0v…pq6j Passport is available for purchase at BTC2024 in Nashville for $20.
Pick one up at booth 211. If you are not at the event and want to get your hands on one register your interest at the link below or send me a message.
https://tips.orange.surf/apps/37e8jKpHw5g7fmS5csD5bBLeg53r/pos
https://m.primal.net/JfCr.png

2024-05-11 19:04:39 UTC

- reply

Thank you!

2024-05-10 21:40:22 UTC

https://orange.surf/dude-wheres-my-block/