<unnamed>

Public Key

npub1cev2qfuqv5s9jm5a6yvhc8ne8cdl9mh459m5g8zz759s7pw9fayqnketlq

Profile Code

nprofile1qqsvvk9qy7qx2gzed6wazxtureunuxljam66za6yr3p02zc0qhz57jqpz4mhxue69uhk2er9dchxummnw3ezumrpdejqz9mhwden5te0dehhxarj9enx6apwwa5h5tnzd9aqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qyf8wumn8ghj7mmxve3ksctfdch8qatzqyxhwumn8ghj7mn0wvhxcmmvvlyvfm

Publishing to

eden.nostr.land

nostr.fmt.wiz.biz

relay.damus.io

nostr-pub.wellorder.net

offchain.pub

nos.lol

Last Notes

2026-03-05 05:50:22 UTC

- reply

Cypherpunks don't send everything they think of to a saas company to analyse though.
"Sofapunks prompt claude" probably works though

2026-03-02 05:27:54 UTC

- reply

Give it more of a "as an experienced ----- you are predisposed to think this is a stupid idea. Please come up with all the flaws you can think of and don't accept claims from me until they're bulletproof." prompt? There are plenty of smart, cantankerous people on the internet and therefore in its training data for it to mimic.

2026-03-01 03:29:10 UTC

This is mstr's philosophy: the only good txs are ones that send money to me. Anything else, even me ever using that money, is bad!
#nevent1q…0ets

2026-03-01 03:25:18 UTC

- reply

You need to hash the annex to calculate the wtxid, which goes into the witness merkle root in the coinbase, which you check when validating a block though. You also hash it as part of taproot witness signature valuation, which is different from other witness data (eg inscriptions).

2026-03-01 03:20:06 UTC

- reply

If OTS ever implements sign to contract, it could just be an ordinary 1in 1out payment, which would be less than a tx with a 40 byte opreturn. https://github.com/opentimestamps/python-opentimestamps/pull/14

2026-02-25 00:34:15 UTC

- reply

You have a problem: calculating the nth Fibonacci number. You decide to use recursion to solve it. Now you have two problems.

2026-02-01 09:51:09 UTC

- reply

Info from blockchair.com, originally posted on twitter.
https://x.com/i/status/2017813697255891246

2026-02-01 09:50:18 UTC

- reply

Less difference between eth and btc than I would have expected, not really much out of the segwit plus 1/2/4 doubling plan that's was considered prior to segwit becoming super controversial.

2026-02-01 09:47:42 UTC

- reply

Bigger chains:
https://image.nostr.build/3f36c752e69f23ef6b26afeb8f773982ca83570948df371938ee607e5710ec8f.jpg

2026-02-01 09:46:20 UTC

Annual blockchain growth (GB per year):
https://image.nostr.build/50bf62c9720cbcc22754d02e8e9c5c341002d033768bc0ba0fd8113c0f1a3fdb.jpg

2026-02-01 08:43:47 UTC

- reply

And by seeking truth they gain your approval?

2025-11-26 02:18:59 UTC

- reply

You might not think bip editors have that responsibility, but lots of people do, and will react pretty negatively if they don't appear to live up to that responsibility.

2025-11-25 17:48:51 UTC

- reply

The point is to allow editors to reject ai "slop" without having to treat it as if it were a serious contribution, and without getting blamed for being overly controlling, unpredictable or arbitrary.
Using the same approach as for onchain spam -- only N prs will be accepted per week and whoever pays the editors the most will have their prs prioritised -- probably doesn't have the right incentives.

2025-10-31 16:40:14 UTC

- reply

Coins under those rules go to zero for sure, don't see how that had any effect on bitcoin though...

2025-10-26 12:13:41 UTC

- reply

Oh I thought you had a format string where you just wanted a literal. Null termination should still be handled by types (string vs span perhaps) rather than format spec, though i guess that's straying further from C.

2025-10-26 09:52:36 UTC

- reply

tinyformat does compile time checks that catch that, for C++ anyway. At least if I'm not misunderstanding the bug.

2025-10-25 16:13:59 UTC

- reply

Feel like I've had a similar experience on some throwaway sqlite db, but didn't commit the result to my long term memory...

2025-10-25 09:43:39 UTC

- reply

Did you try batching the additions (begin..commit)?
O(0) algorithms ftw. There has to be a tshirt idea there. Maybe a -420+0 diff on the back?

2025-10-19 02:53:45 UTC

- reply

It's also a floor on what it would take to buy all existing supply.

2025-10-08 19:13:47 UTC

- reply

Who are you seeing doing any of those things? As far as I can tell you're arguing about strawman.

2025-09-08 03:03:39 UTC

- reply

They want to shoulder the load: replacement is the goal. Why send your PRs to an open repo and have to deal with public review when you can push people to switch to a repo you control, with the ability to both block changes you disapprove of and force through changes you like? The technical and economic disagreements are a useful justification, but they're not the fundamental motivation.

2025-09-05 03:06:14 UTC

- reply

You mean cryptographically signed proof that you've evicted the censor that used to live in your own head?

2025-08-30 13:53:40 UTC

- reply

Annoying you is the goal. Goading your enemies into becoming emotional and making mistakes is a classic tactic.

2025-07-04 04:39:29 UTC

- reply

Broadly defined limits: the way this is designed is that each element has a strictly defined memory usage (16 bytes overhead for cons' two pointers, 16+size bytes for vector, plus 8 bytes overhead for type info and refcount in both cases), and a strictly defined lifetime. bllsh currently tracks the limits (ALLOCATOR.alloc() and .free() and alloc_size() in Element subclasses). Actual implementations might use less space (4 byte pointers vs 8?) or more (allocate space in powers of 2?) but should only be a factor of 2 or 4 or so off.
Enforcement of memory and execution cost limits is pretty preliminary: there's checks in symbll/WorkItem/step for no more than 100k steps (with no weightings applied) and no more than 400kB of memory used. This really should be using Allocator/record_work and over_limit to ensure intermediate state didn't go over the limit, and it all should apply to bll as well, but currently doesn't.

2025-07-02 09:21:36 UTC

- reply

Forums or email seen better for long responses....
re: optxcollate as a separate opcode / auto hashing - I guess I'm thinking that [txcollate+sha256] could be added as a new opcode to existing tapscript without requiring varops budgeting to be applied to existing opcodes, so might be interesting to separate out and explore more immediately.
I think you could exhaust 4MB of stack with a tx spending 400 inputs each with a 10kB scriptPubKey ([1SUB DUP NOTIF p CHECKSIGVERIFY ENDIF]*250 or so for a 1 of 250 multisig maybe) and specifying input_scriptpubkey. Hashing as you go with collate would make that okay.
re: output order, "push a new element under .. last output will be on top" seems contradictory to me. The last/most recent element will be under everything which is the bottom? First/oldest output should be the top and first to be popped afaics.
You might consider moving the witness data to the end of the output and including a flag byte do that you can construct the wtxid correctly with only a single txcollate invocation.
I don't think scriptsig or witness in general is a good thing to introspection, it has too high a risk of making spending utxos together incompatible (already a problem with nlocktime). Pulling out any data requires knowing the script structure and execution path (and also requires DROPN afaics particularly if the other script is using optx or checkmultisig or opmulti), which is hard to get right and easy to get wrong, as occurred with the ctv-bitvm idea recently.
The intent with the annex is to apply some simple structure to it as consensus, so that pulling data from it can be done easily and safely. [X I ANNEX] to get the entry tagged X from the annex for input I (I=-1 for current input perhaps) would be a thought. That would imply the annex should only include a single entry per tag (not clear to me if multiple entries for a tag is desirable or not). I'm leaning towards individual annex entries being limited to perhaps 127 bytes - if you want longer, [SHA256 X -1 ANNEX EQUALVERIFY] lets you put the long thing on the witness while still committing to it.
One reason to limit how much you can introspect other inputs is the costing - in a coinjoin eg you can know in advance what the pubkey etc is but the witness could be arbitrarily large and examining it could increase your script's costs more than you might expect. That has some risk of an O(n^2) blow out, which isn't a consensus risk due to the budgeting, but still seems undesirable if it forces your costs to go up in unexpected ways that you can't really know until you see how the other guy is going to authorise.

2025-07-02 01:25:19 UTC

- reply

Is this some "motion is relative" thing? The only way to stop this train is to join its frame of reference?

2025-06-19 02:51:09 UTC

- reply

Wish you'd at least take a look at the lisp approach...
Anyway, a few quick comments on the op_tx part: a) if the selector is meant to be scriptnum compatible, would be good to make that clear (ie 513 on the stack is interpreted as outputscript+collate not as 0x0102 and tested as outputamount+version. b) please use hex for the selector values...c) you might consider two separate functions [op_tx and op_txcollate] instead of using a bit selector; makes it slightly easier to statically validate expected stack depth, though still not great. d) not sure the ordering of collate-vs-noncollate makes sense - should "output" just always put the new data at the start of the buffer or the end of the stack do you consistently get the last output thing first? e) input(num)witness seems like a bad idea to me, constraining how other inputs are spent just seems like asking for complexity and bugs. f) having a way to pull info from other inputs' annex (and your own) would be a win though, but maybe that should be an op_annex getter. g) personally I don't think upgradability is a win here, better to upgrade by defining a new opcode than have weird semantics that people will forget to check. h) the ctv comparison at the end is inaccurate - ctv also commits to scriptSigs. i) automatically hashing it as you go rather than pushing the whole thing to the stack then hashing it seems worth considering
Hmm maybe gmax is right it abbreviating as txn instead of tx which is also transmit (he says after correcting an op_rx typo)

2025-06-08 23:25:09 UTC

- reply

Require a zap or pow for comments from outside your social graph, and automatically add people to your social graph (and refund the zap) when you like a comment from them?
Bonus: will make moderating your comment threads feel like watching Adam West's Batman: Pow! Zap!

2025-06-03 02:39:56 UTC

- reply

Scifi, and being a small target was the intended allusion.
For ancient fortifications, would it be referring more to a drawbridge or a portcullis?

2025-06-02 12:18:52 UTC

- reply

The enemy's gate is down.

2025-05-25 14:25:08 UTC

- reply

Lower the block size?

2025-05-21 07:08:03 UTC

- reply

Okay, should have read this reply first.
> I have no idea what individual motivations might be
Given I've been explaining mine to you, that's either dishonest or wilful ignorance. Have fun with knots.

2025-05-21 06:59:21 UTC

- reply

No I mean what real goal are you trying to achieve here that spam is making difficult - like presumably it's possible that we drop the pr entirely, but that doesn't actually do enough and there still ends up being "too much" spam. Or maybe the pr does go in and it turns even with it, there isn't a market for this nonsense and bitcoin doesn't end up with "very much" spam. What's the "business goal" that's affected by success or failure here, as far as you're concerned?
(For me the primary metric is "can a cheap node keep validating the blockchain", and to a lesser extent "is the long term tx fee rate level and its variability reasonable". I could probably put numbers on the first, though the layer is, at best, "i know it when i see it")
The first two of your metrics above have been met in the past month, I believe; is there some way in which bitcoin had been unusable for you in the past month?

2025-05-21 06:40:02 UTC

- reply

The only (informed) argument I see for that position is something along the lines of "this acts as an endorsement that such data storage is fine, and will encourage people to do more of it. You can observe that this effect has already happened with a large increase in op_return activity since the pr was opened, and the creation of a new "op20" token scheme. That endorsement will flow over to schemes that use witness data, increasing their use as well. That will make it less likely that will have non-full blocks (due to more token usage of either type) and increase the data storage requirements of non-pruned nodes due to increased witness usage"
Personally, I think the immediate observable effect is due solely to the publicity the issue has generated and will disappear when attention moves elsewhere.

2025-05-20 07:30:20 UTC

- reply

Oh, a question I missed. What's your goal that makes you opposed to spam, rather than being willing to merely ignore it? Or what's the success condition that would let you happily move on from this issue?
Some might be:
* you're sure your node will keep working for 10 years on current reasonably priced hardware?
* the mempool is generally empty and blocks are rarely full?
* that you feel like you've taken a stand and sent a signal, even if 99% of blocks are 99% spam and fees are sky-high? ("they may have won the war, but i bloodied the Kaiser's nose, that's for sure" eg)
* it's cheaper to pay for a coffee on chain than it is to inscribe a jpeg?
* that the spam and transfer tx fee markets are decoupled somehow, so that any spikes in people wanting to spam the chain don't cause your fees to spike, even though more monetary txs will still cause your fees to spike? (Or have less effect than they do today, rather than none)
* nobody on the internet is ever wrong ever again?
* something else?

2025-05-20 06:50:42 UTC

- reply

"You can reduce spam by discouraging it" is a question of incentives, not one of fundamentals. I don't think we've finished the fundamental debate that you wanted yet.
Do you agree that core devs in general are trying to make bitcon work as a monetary network with a similar/compatible definitively to yours? That is, that we are actually on the same side here, even if we have different thoughts on how best to achieve that goal?
Do you accept that reasonable people can disagree on what constitutes "spam"? Both in thinking things you think aren't spam actually are, and in thinking stuff you think is spam is fine?
Do you accept that bitcoin is not your network, to rule as you wish, but that rule changes require near unanimous consent, even from the reasonable people who disagree with you, and potentially even from people doing the spamming?
Are you trying to ban spamming from bitcoin entirely?
Are you merely trying to discourage spammers? Are you aware that that might have no effect, or the opposite ("how dare you tell me what to do, I'll do it to spite you")?
Do you believe that going into technical details on this topic, to work out how best to make bitcoin sustainable as a monetary network in the long term is a valuable thing to do, or is that just a way for experts to attempt to close down the discussion and exclude non-experts?
I notice you're gong straight back to personal attacks ("would you rather people question your competence rather than your intent") and justifying it with fairly specific thoughts about current approaches, rather than sticking with the fundamental principles you claimed to want to discuss.

2025-05-20 06:32:17 UTC

- reply

If I'm saying that my opinion is not 100% but only 50% that they're not worth thinking about, what does that imply for the remaining 50%?
If I'm spending time debating the issue, is that not already clear evidence that I do think about the issue?
If you're going to make tenuous conclusions about what my thoughts are opinions are, how about applying some logic in there rather than just your prejudices?

2025-05-19 09:16:25 UTC

- reply

> irrelevant transactions are spam
The definition of "spam" here would be "you send me megabytes of data where I only care about (at most) few bits of information".
In this case the data I'm interested in is "how much btc can I spend, can anyone else spend it and if so who, and what is the total supply of bitcoin". The daily updates of information can be encoded in a lot fewer than the 300MB we expect from a day's worth of blocks. Unfortunately we don't currently have a way of doing that encoding that doesn't allow cheating, so to run a node we have to accept and store a large amount of data that we don't really want.
That is something that attackers/scammers do exploit: you were even around for the 2015 stress tests that flooded the mempool and filled up blocks, and were not done for any underlying transfer of value, not even the de minimis value in selling a random memecoin.
There's no meaningful difference between data spam and transfer spam's effect on your node - you have to validate both, and both take up roughly the same capacity requirement (data can take up more bandwidth and disk per week, though not if encoded via an op_return; transfer validation required more cpu/processing time). There's also no difference between transfer spam and real transactions.
If either of those are causing actual problems, then those problems will reoccur with real transaction load, so need to be fixed independent of whether the current cause is spam or not. We've fixed one set of such problems during the 2015 stress tests and another early in the inscriptions fad, but I don't think there are any known issues remaining.
I realise it's not pleasant to put something you hate (data spam) and something you like (other people using bitcoin as a MoE) into the same category, but as far as technical impact on your node's operation, they really are fundamentally the same, affecting your node in the same way, subject to the same global limits, impacting the same global marketplace in the same way (ie the blockspace fee market), having the same solution (move the substance off chain so you're mostly not subject to the limits or fees; eg via lightning).
I'm not saying this to get you to agree on this point, by the way, just to explain my views on this topic at the fundamental level, before getting into the economic details or the technical ones. You've accused devs of both bullying you and avoiding discussing the fundamentals.
Your claim that "failing to continually deprioritise things I dislike is actually the same prioritising them" isn't a reasonable use of those words. Ceasing to forbid/discourage something isn't the same as encouraging it, and the continued implication that this is all about devs wanting to encourage spam continues to be unappreciated, unfair and incorrect.

2025-05-19 08:39:00 UTC

- reply

> analogy is off
That's precisely what I was claiming, not more, not less. In your own home, you get to set the rules, either as the patriarch, or as a family, and guests have to abide by those rules, or get kicked out for trespassing. That attitude doesn't work somewhere that everyone owns and no one is a guest. If a significant and influential group wants to encourage some standards, despite not being able to enforce them, that's one thing; another is if everyone is willing to enforce a new set of rules. But working out whether those things will do any good means looking into the technical details.
The problem isn't confined to a small group being able to veto, it also applies to a large majority being able to veto: if most petiole in the US or Canada don't mind you being debanked for being (legally) involved with drugs, porn, guns, or opposition politics, that shouldn't be enough to prevent you from using bitcoin. Likewise if 59000 node operators decide they dislike you or your activities.
The exact same mechanisms that allow unpopular citizens, activists or revolutionaries to use bitcoin are also deployable by the people you dislike when they want to use bitcoin in ways you dislike.

2025-05-19 08:26:59 UTC

- reply

The stats you've seen probably came from me, via https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-2659802629 . So perhaps cut it out on pretending it's something I'm not thinking about. The utxo growth is a real attack vector, and discouraging unnecessary utxo growth is precisely why we don't want monetary users like Citrea and its bridge idea to bake permanent increases that can never be removed into their protocol.
There are devs explicitly working on projects to prevent utxo growth being a problem, and the dust limit which is explicitly focused on discouraging that use case is widely supported by devs despite not totally preventing it.

2025-05-18 15:14:42 UTC

- reply

I'm happy enough with that definition, though I'd phrase more broadly, perhaps as "managing control of coins" - setting up a lightning channel doesn't transfer funds, but it changes how the funds are controlled. Note that the trigger for this, Citrea wanting to commit 160 bytes into a txid as part of a many kB penalty process, it's also about transferring bitcoin (moving funds that were custodied by the bridge or moving funds a a penalty for cheating) and/or establishing control of funds.
I do have mixed feelings about people doing NFTs and memecoins: 50% that they're idiots, 50% that they're not worth thinking about. At least the stress tests they've provided now and then do have some positive value though in increasing the network's robustness.
Where I disagree above comes when you start calling bitcoin "your" house, or saying (iirc, something like) "we should prevent spammers from using bitcoin". If bitcoin's going to go anywhere, it can't be something where some select individuals can exercise outsize control over the network as a whole based on their personal dislikes. If you're in a position to stop people from spamming, governments are in a position to stop people funding opposition parties. Bitcoin can't be your house with your rules for the same reason it can't be some govt's house under its rules.
If you want to dissuade people, rather than forbid them, that's a different question, that needs a different metaphor. For example "let's keep our neighbourhood nice, so we all benefit" rather than "so long as you live under my roof, ..." one.
But before we drop into figuring out in technical detail if either forbidding/dissuading has any chance of being effective, there is a different point I would make at a fundamental level.
The issue with a global public ledger is that **every** entry in it other than those relating to your personal coins is fundamentally spam as far as you're concerned. If there were any way of making bitcoin where I don't need to be told and record how much someone in Alabama is withdrawing from coinbase to self custody, that would be an improvement. Eg, my view of the blockchain could be perhaps 12kB of headers a day and perhaps 1kB per on chain transaction I make, which would be much better. Unfortunately that's not possible, so we instead give everyone's txs to everyone, and put a limit on how much data that is.
But the limit we apply to prevent that from getting out of hand is exactly the same as the limit we need to prevent on chain spam from getting out of hand. This is already a solved problem, though of course it's possible it might be better if the limit were raised or lowered. In particular, it's not a problem that needs us to distinguish between transfer/control data and spam data.

2025-05-17 00:23:47 UTC

- reply

I'm sorry, I thought you were insisting discussing the fundamentals, not the technical details, whether software or economics. You said "If we were having a real, serious conversation, it would be not be at this level, it would be about what we think Bitcoin really is. Is it a monetary network or is it something more? Do spammers have as much right to Bitcoin block space as monetary people?" You obviously think people who've been disagreeing with you, of which I'm one, have a different view on that fundamental question that they, including me, are disguising behind technical gibberish. Let's have the real serious conversion about fundamentals you claim is lacking before backing down to a "but it's bad communication" cop out.
Do you accept that we both agree that Bitcoin should be a monetary network? Do you agree that's also true of the vast majority of regular contributors to Bitcoin Core?

2025-05-16 18:43:23 UTC

- reply

There's not much point talking to people who think they know your values better than you do, and just claim you're lying when you disagree. The entire point of bitcoin is to be a monetary network, and this change is a deliberate step forward in achieving that goal. As far as patronising goes, check for the log in your own eye.

2025-05-14 23:42:15 UTC

- reply

What if what you think is a fundamental disagreement is just a lack of understanding? Would it be better to spend time talking and listening, rather than developing a long term schism or grudge?

2025-05-14 15:47:15 UTC

- reply

Corollary: if you want someone out of the kitchen, turn up the heat.
#nevent1q…rn2w

2025-05-14 15:01:43 UTC

- reply

I don't think this is really an honest/fair criticism, personally - it was only poor communication if you were expecting it to have been able to overcome a concerted disinformation campaign from all the usual suspects. On the other hand, if it works as motivation for you to do more good stuff, though, carry on.

2025-05-12 17:42:36 UTC

- reply

Eh, there's always the option of backporting fixes to of versions yourself if you really want, or, I guess, paying someone to do that. Or just run the old software and mitigate the risks in some other way - just not being a listening node is often pretty good.

2025-05-12 04:38:49 UTC

- reply

It's ethereum's difficulty bomb but for bitcoin! Introduced specially for knots users in 2017, without even a PR, let alone any review.
#nevent1q…2mq2

2025-05-12 04:32:19 UTC

- reply

Anything with COPYRIGHT_YEAR=2023 expired Nov 2024, including knots 25.x. Versions 26.x and 27.x will expire Nov this year. So every other knots release is a hardfork by default (newer versions will accept blocks that older versions would reject), neat!

2025-05-11 17:32:08 UTC

- reply

So 23.x? Knots 25.1 isn't 2 years old yet...

2025-05-10 05:54:14 UTC

- reply

Antoine posted to the mailing list about fixing a problem with an L2 Citrea was developing (" I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour"), then Peter refiled his previously rejected PR to immediately lift all related restrictions and immediately remove related configuration options. That then engaged people, and got Peter invited onto conference panels to talk about himself.

2025-05-09 18:00:17 UTC

- reply

(The utxo set is the database - it tells you the current state of how the bitcoin supply is controlled; the blockchain is the audit log of the database - it tells you every change that got us to the current state)

2025-05-02 11:23:22 UTC

- reply

Supposed to be a spec update any day now maybe?

2025-05-02 11:22:43 UTC

- reply

It's easier for a light client to obtain data in an OP_RETURN too - you only need the block merkle root, for witness data you'd need to get the coinbase tx and the witness commitment as well.

2025-03-27 04:56:16 UTC

- reply

The advantage of decentralisation is that everyone gets to have their guy in charge; the advantage of centralisation is some get to have their guy in charge of even more.

2025-03-15 04:51:18 UTC

- reply

I feel a little like a positive goal of "move to having thread X own the block tip info and mempool and communicate that to other threads via a message queue/atomics" or similar might be better than a negative goal of "use less cs_main"...

2025-02-18 21:58:44 UTC

- reply

Your audio is pretty echoey 😟

2025-01-28 14:57:54 UTC

- reply

Would have been fine/sensible to change it beforehand too though. Muhash calcs were already fast, though being even faster is better of course.

2025-01-28 14:38:46 UTC

- reply

Afaik assumeutxo doesn't use muhash, https://github.com/bitcoin/bitcoin/issues/27669 ?

2025-01-28 13:09:31 UTC

- reply

But it's already a possibility? coinstatsindex works fine?

2025-01-18 17:20:46 UTC

- reply

100% premine is just an IPO. Of shares with no voting rights, and no claim on assets or profits. But even the latter isn't that far off what tech stocks do.

2025-01-17 19:45:48 UTC

- reply

Busy. Think it's a combo of fiamma and someone deliberately trying to push fee rates up. Also blocks are artificially small. (Inquisition enforces fewer rules for relay/block template inclusion than core, not more) Some txs in mempool.space are missing from my nodes and don't seem to be being rebroadcast though.

2025-01-16 07:13:16 UTC

- reply

I thought you were going for some "Twitter : twits :: Nostr : nuts" analogy

2025-01-15 12:54:05 UTC

- reply

https://mempool.space/signet/address/tb1qd4lew8fntrpma2hmpnm0h8yca6yltzlu2xnd5s
People are pushing up minfee a bunch, so you might have to be careful of that

2025-01-11 22:28:31 UTC

- reply

Shoot an address if you want some signet coins for playing with, or if you want enough to setup a faucet. Faucets get drained pretty quick once they get noticed, it seems, so it's hard to be generous and anonymous.

2024-12-18 13:33:59 UTC

- reply

Governments are financed by debt these days, having valuable assets that creditors can claim if you default on repayments makes it easier to sell debt cheaply. So the reserve just sits there until the US defaults, at which point they give out BTC from the reserves to a subset of bond holders in order to avoid a larger collapse of the financial system. Social security forecasts probably means that's coming in the medium term? If the gov weren't debt financed (DOGE succeeds scenario) then you could build up the reserve 9 years out of 10, and use it to smooth out recessive in the remaining year. Requires an implausible amount of political discipline though.
Public companies buying bitcoin is just that it's a better savings vehicle than treasuries, and for tax reasons, distributing profits via issuing dividends or stock buybacks can suck
IMHO anyway.

2024-12-15 16:33:52 UTC

- reply

https://image.nostr.build/abec0f100def3b55ba2cee7e89ebbe54cc8c7ccd3bab1587142b9fbfeea4fe76.jpg

2024-11-30 11:33:39 UTC

- reply

Unzapable is what happens when you're grounded, maybe?

2024-11-30 03:27:15 UTC

- reply

Wow, that's a high quality bug report, especially for such a frustrating, long term, hard to fix issue. Kind of inspiring.

2024-11-27 09:11:35 UTC

- reply

The ruling mentions validators, but seems confused about it, saying "The second type of account, a smart contract, is a software or computer program that is uploaded onto the blockchain network. These accounts do not require validators."

2024-09-19 12:55:02 UTC

- reply

Not wireshark, this is FIRESHARK!

2024-09-19 03:03:29 UTC

- reply

In this system, can't I create a taproot key with pubkey (xG+tH) contributing (xG+(t+v)H) to the curvetree, and use that to provide a false proof that I have t sats more than I ever had (and t+v sats more than I can spend, since such a pubkey is unspendable)?

2024-09-05 00:09:08 UTC

- reply

It's equivalent to grinding through unhardened paths in an HD wallet whose xpub you know, then telling the wallet owner "wpkh(xpubBLAH/3568/4528/6426) has a nifty pubkey"

2024-09-01 09:45:56 UTC

- reply

Okay I'm convinced, switching back from iris.

2024-08-30 01:58:22 UTC

Anyone have an android nostr client to recommend for a (roughly) twitter-like experience?

2024-06-07 09:26:08 UTC

Hmm, failed to lose my nsec and still kind of have access to my account. Seems like I lost whoever I was following though.

2023-09-23 17:13:40 UTC

- reply

The season where Americans celebrate Lucifer, bring hell's fires back into their homes, and have holidays focusing on witchery, lust, death and gluttony. Also, pumpkin spice!

2023-06-06 06:49:08 UTC

- reply

So\/rce - the source is open like a book

2023-06-01 04:36:13 UTC

- reply

The question is which is to be master, that's all.

2023-05-13 02:36:38 UTC

- reply

The nips are pretty easy to read