Nostr notes by Chris Guida

Literally me a few minutes ago "Hmm twitter is down, what do ...

2026-01-16T16:48:28+01:00

In reply to nevent1q…7spd
_________________________

Literally me a few minutes ago

"Hmm twitter is down, what do I do now?"

"I guess Nostr?"

Guilty as charged #nevent1q…xeq3

2026-01-16T16:46:01+01:00

Guilty as charged

quoting
nevent1q…xeq3
Incoming in 3…2…1…

How did you know

2026-01-16T16:45:48+01:00

In reply to nevent1q…8qx0
_________________________

How did you know

At the end of the day their rationale for the change is not ...

2025-09-17T17:33:09+02:00

In reply to nevent1q…96wg
_________________________

At the end of the day their rationale for the change is not "purely technical", nor should it be. The change is (purportedly) an attempt to change the economic incentives. So any economic arguments against the change should be addressed.

Bro you need to run knots, we agree on all of this

2025-09-17T07:14:28+02:00

In reply to nevent1q…pva8
_________________________

Bro you need to run knots, we agree on all of this

Thanks for filling that in for me.

2025-09-17T06:38:29+02:00

In reply to nevent1q…dsev
_________________________

Thanks for filling that in for me.

(Also posted on twitter: ...

2025-09-17T04:39:55+02:00

(Also posted on twitter: https://x.com/cguida6/status/1968117953871720463)

Several core supporters have pointed me to Pieter Wuille’s recent StackExchange post[0] explaining core’s rationale for raising the default opreturn limit 1250x from 80 bytes to 100,000 bytes in the upcoming bitcoin core v30. I don’t know where else to publish this response, because I don’t know what apps Pieter uses, and StackExchange does not seem like the right place for a constructive back-and-forth.

My goal here is to challenge Pieter’s explanations with claims and questions of my own, in order to:

1) find any pieces of Pieter’s rationale that I am misunderstanding or lacking,
2) inform the public as to what I believe to be the most compelling arguments against removing the opreturn limit, and
3) ultimately, to arrive at the real truth of the matter and help bitcoin follow an optimal path

So I’ve taken Pieter’s post and responded inline here (paragraphs with double arrows are the original SE question asker, those with single arrows are Pieter, and those without arrows are me):

>Given the debate around the issue I think this is probably an opinion-based question, but I'd still like to try to clear up some misconceptions.
>Disclaimer: I'm a Bitcoin Core contributor, argued in favor of dropping the OP_RETURN restriction, and co-authored a document on the matter that was signed by several other contributors and got published on the http://bitcoincore.org website (which I recommend you read). While I'm only going to give my own view below, I think I have a good idea on at least the proponents' opinion on the matter.

Yep, you definitely seem to be the most authoritative voice on the “pro-32406” side of the debate. You are also obviously one of the most important devs in bitcoin history, and your claim to being “a Bitcoin Core contributor” is a massive understatement.

>>I agree that Bitcoin is money, not a storing database, and strictly only monetary data should be on the blockchain.
>I agree with this, and have argued strongly in the past against developing solutions that relied on using the chain purely as a publishing mechanism for non-financial data. Blockchain space can be expensive, slow, unreliable, and costly (in terms of bandwidth/processing by nodes). It should be used for what it's good for: proving that censorship-resistant payments are valid to the world; a use case for which no better alternative exists, as opposed to many data-publishing use cases that have no such requirements.

Yes, I’m glad that we agree on this.

>I believe that in the long term, such (in my view) sub-optimal use will be driven to alternative solutions anyway as on-chain space grows more valuable, and that deviations to this, like we see now, are temporary convenience solutions driven by hype.

I think this is where we disagree. Greg Maxwell argued[1] in 2015 that “Demand for cheap highly-replicated perpetual storage is unbounded”. I agree with Greg. If we do not impose any additional costs on people trying to use bitcoin as a general-purpose database, such use will *absolutely* drown out payment use cases, especially merchant Lightning nodes which, at the moment, are bitcoin’s most important payment use case.

I think filters make it *look like* there is no demand for large opreturns, just as the fence around your house makes it *look like* there is no demand for trespassing on your property. Deterrents are often misunderstood, because you can’t see all the attempts that never happened, *precisely because of the deterrent*.

>It's worth warning people that they likely won't persist with changing economics, and provide some discouragement for it - but not when that discouragement becomes harmful on itself (see further).

I’m not sure what you mean here by “they likely won’t persist with changing economics”... if your assertion is that altcoin Ponzis will magically stop happening *just* because of on-chain fees… I don’t think that’s likely true at all; one look at the “crypto industry” outside bitcoin should be sufficient to explain why. But maybe that’s not what you were saying?

>However, as developers and community of node runners, we also do not really get to decide what people use the chain for, beyond agreeing on consensus rules(*). This is another point of disagreement. The noderunners *absolutely must* enforce bitcoin’s usage as a payment network and reject attempts to use bitcoin as data storage since, as I already mentioned, demand for perpetual, highly-replicated storage is infinite, and therefore there is no way the consensus rules *themselves* can prevent data use cases from drowning out payment use cases. Even with a fork to disallow almost all script types, there would still be people making crazy schemes on top of fake pubkeys or whatever in order to facilitate their token Ponzis. Ponzi participants are not particularly sensitive to fees, if the promise of getting rich quick is compelling enough.

Put more simply: bitcoin’s identity as money cannot be enforced at the consensus layer. Therefore, the only way to ensure that bitcoin stays money is if we enforce its usage as money at the social/mempool layer. The only reason bitcoin has stayed money thus far is because of its protective “bitcoin maximalist” culture, which ensures that its #1 priority is always to be the best money, and that other use cases are severely discouraged.

In the absence of strong mempool filtering (and possibly other social-layer mechanisms), I don’t see a way for data use cases *not* to gain such a dominant role that bitcoin ceases to be money entirely. It just seems inevitable to me.

The reason filters are effective at deterring unwanted data use cases is that the filter serves as a warning that is backed up by the noderunner community’s will. The warning says: “we don’t like transactions that store more than 80 bytes of arbitrary data, so if users attempt to work around this, we will take action to mitigate such usage. If our mitigations don’t work, we will continue escalating until the spammers leave.” This is exactly what we did in 2014[2], and is exactly what will work today.

>The contents of blocks is decided by miners, who are - by design - driven by economic incentives.

If you are implying that fees are the only “economic incentives” miners pay attention to, this can be easily disproven by considering the result of the block size war; larger blocks promised *much* larger fee revenues for miners than small blocks (and presumably number-go-up in the short-term because of perceived "scaling"), and yet the small blockers were victorious. Miners were forced to concede that a bitcoin with smaller blocks and segwit would be much more economically valuable in the free market than a bitcoin with large blocks and no Lightning Network.

(Similarly, a bitcoin that is easy for merchants to accept directly because their Lightning channel opens and closes aren’t being overrun by altcoin speculative manias is much more valuable in the free market than a bitcoin that is filled with spam.)

That is: miners must also pay attention to long-term incentives in addition to short-term incentives. Sometimes it takes some nudging from the user community in order to help them decide, but eventually the market will always converge on whichever version of bitcoin is the most valuable, and miners must pay close attention in order to make the right choice.

>And if people are willing to - hopefully temporarily - pay more for "dumb" data storage on chain than real payment activity, there is little that can be done about this, for a multitude of reasons:

>Data can always be disguised as payments,

Yes, this is precisely why the consensus rules are useless for making sure bitcoin stays money, and why we must react at the policy level rather than the consensus level. Only the most popular formats, which by definition are easily-identifiable, need to be filtered.

>making attempts to stop or even discourage it a cat-and-mouse game, which at best pushes those who pay for these use cases to slightly less efficient techniques (like encoding the data in addresses, amounts, signatures, ...).

No, at best the spammers *leave bitcoin entirely* and go to other chains, as they did in 2014 (again, see [2]). We won the cat-and-mouse game last time; why assume we would lose this time? This assertion has no evidence.

>Given enough economic demand for data storage, nothing prevents submitting transactions directly to willing miners (which fundamentally can't be prevented(*)), bypassing non-mining nodes, the software they choose to run, and thus ultimately, their influence entirely.

Of course, but the goal of spam filtration is not *the complete elimination of spam*; the goal of spam filtration is just to make the system usable for its intended purpose. On bitcoin, this means making sure bitcoin stays money by making sure that the majority of activity on the network is payments, not data. The opreturn filter is performing this role admirably, as can be seen by the 99% reduction in large opreturns[3][4] it causes.

>Philosophically, would you want a Bitcoin in which some (significant, but far from universal) subset of node runners get to decide which transactions are allowed or not, given that that, if effective, the same mechanism could be used to block "undesirable" payments, while providing a censorship-resistant payment system was the very thing Bitcoin was designed to enable?

This argument doesn’t make sense to me. You just argued that users can always submit transactions directly to a miner. So bitcoin is still censorship resistant, even if the relay network is entirely hostile nodes, entirely blocksonly nodes, or even if the relay network doesn’t exist at all. So I don’t see how a supermajority of noderunners running filters does anything to change bitcoin’s censorship resistance. Bitcoin is censorship resistant, period. So spam filtration is an entirely different matter from censorship.

Second, if a supermajority of noderunners is running a filter, *this is the only mechanism by which the user community can enforce bitcoin’s moneyness* since, as previously pointed out, bitcoin’s moneyness cannot be enforced at the consensus level. Thus, if a filter is being run by a supermajority of nodes (assuming no long-term sybil attacks), this must be considered the bitcoin network’s will, and going around it should be considered abusive. I very much doubt that a supermajority of noderunners could be convinced to filter OFAC transactions, for example. But again, if that does somehow happen, there’s always direct-to-miner submission APIs (and other more decentralized solutions such as gudnuf’s hackathon project, memcooler[5]).

>Of course, ultimately the agreement of all Bitcoin users (the consensus rules, see below(*)) determines what transactions are allowed, but this being hard to change is a feature, not a bug.

Again, if we require consensus changes in order to prevent spam, we will obviously lose to the spammers. There is no way consensus rules can keep up with rapidly evolving threats from Ponzi scammers. But modular filters[6] can easily keep up with such threats.

>>I still find it hard to understand the argument on favor to this change. As far as I understand the OP_RETURN will be relaxed from 80 Bytes to 100k bytes, allowing the storage of arbitrary data, like images and even small videos. Why ?
>>I hear often "Arbitrary data is already been placed on the blockchain", but then why the complacent attitude towards it ? and not fight the spam instead ?

>To be clear, Bitcoin Core v30 lets node runners configure the OP_RETURN size limit (the -datacarriersize config option). The only change is that its default value is increased (to effectively unlimited).

The change of the default is the important feature of this discussion. The fact that the control was left in is not significant in comparison. Up until recently, core had >95% share of the nodes, and this is more than sufficient for the default to be very sticky. Nodes that dissent from the default don’t have much effect on the actual incidence of transactions that get confirmed.

>It is marked deprecated, which means the option is expected to be removed in a future version, but given the current political dispute around it, I do not expect that will happen any time soon.

It is remarkable that it was even considered to remove the filter entirely. This would have meant that any miner wanting to filter large opreturns would need to either stay on core v29 forever or switch to knots. As it is, any miner wanting to disallow transactions with *multiple* opreturn outputs will have only these options once v30 is released. As is, the change is remarkably heavy-handed, but it would have been even more heavy-handed to remove datacarriersize entirely.

>The reason for changing the default isn't just that OP_RETURN is already used, and data storage through other means is already possible (including through ways that are cheaper than through OP_RETURN); it is that attempting to address this at the relay level is not more than a mild discouragement

According to the data, nonstandard opreturns are 99% less popular than standard ones. Calling this “mild discouragement” might be the understatement of the century.

>and given enough incentives to bypass it (as we've seen exist)

We’ve seen a few nonstandard transactions slip through here and there, but brc20 and runes were the worst recent spam attacks and both were built on standard transactions, not nonstandard ones. It is very doubtful that a token Ponzi launching on top of a nonstandard transaction type would be very popular.

>is harmful on itself, both for the ecosystem at large, and for individual node runners, in addition to being ineffective.

We’ve already established that they are effective for their purpose, which is severe ratelimiting, but let’s hear your reasoning for why they are harmful.

>The reason it is harmful for the ecosystem at large is mining centralization. Given enough demand for transactions that the network of nodes shuns (for whatever reason), large miners are incentivized to develop means for users and companies to submit these shunned transactions directly to them (this is already happening to some extent).

This is true only if mining nodes largely disagree with the rest of the network about which transaction formats are harmful. The only time the miners should win this disagreement is if the node network is being sybiled by an entity attempting to censor. The rest of the time, miners should heed the will of the supermajority of users, and miners should be considered hostile entities if they continue mining large volumes of transactions the rest of the network has deemed abusive.

>If these "out-of-band translation relay rails" end up becoming economically relevant enough (through the out-of-band fees they involve) that miners not using them become uncompetitive, the ecosystem has a huge problem, far bigger than some temporary JPEG hype drivel: the inability for new small miners to enter the ecosystem (because who would bother sending transactions to a tiny miner)

This seems to be a point of contention between the core and knots sides of this debate; personally I am skeptical that this is as big of a problem as you seem to, but I assume you have data/reasoning to back this up, and I would be interested in seeing it.

The question is: how big of a mining centralization risk is opreturn being left at 80 bytes, and why wasn’t the opreturn filter a mining centralization risk the entire decade it’s been in existence? Why suddenly now is there a huge mining centralization risk? Are there other filters that are mining centralization risks? Perhaps limits on future script versions or transaction size? If opreturn can suddenly become a mining centralization risk after a decade of minding its own business and doing exactly what it’s supposed to be doing, what other filters might do the same thing?

You seem to think that the risk is bad enough to risk bitcoin ceasing to be money by arbitrary data making bitcoin difficult or impossible to use for payments, so it must indeed be a large risk. I have repeatedly asked core devs and other supporters what problem/risk PR 32406 is attempting to solve[7], and no one seems to have an answer other than “Citrea is going to put 64 bytes into the utxoset”, which is of course incoherent.

>especially anonymously (the best protection the ecosystem has long term against miner censorship).

This can be done by identifying miners by their bitcoin addresses; see memcooler[5] and Ocean mining's user account model, plus tracking which blocks were previously mined to which addresses, for how this could be done.

>In addition, it incentives the development of one or a few centralized "payment submission network" companies that all big transaction creators and miners contract with (something we've seen in other blockchains), imposing a large censorship risk on this company, and making the entire goal of decentralization a shim of what it was supposed to be.

I’m curious what would stop this from happening if the government decided to sybil the bitcoin mempool relay network in order to attempt to censor certain individuals from transacting. You seem to suggest that direct miner submission schemes are *always* a bad thing, but it seems to me they could come in handy if there are ever any *real* censorship attempts.

>The reason it is harmful for individual node runners is that the entire point of participating in transaction relay is having a reliable view of what transactions will be mined in the future

You appear to be forgetting that mempool relay’s *primary* purpose is to relay payments to miners. Most noderunners I know are proud of providing this valuable service to the bitcoin network. This is why the suggestion by some core devs to “just run blocksonly” is confusing.

>for at least these reasons:
>For performing decentralized fee estimation (avoiding the need for centralized services for this).

Decentralized fee estimation works just fine without looking at the mempool. It is only necessary to look at the mempool if your goal is to get into the *very next block*. Since nobody has this need now that we have Lightning, I think it is perfectly acceptable to point users to centralized fee estimation services in the rare case where this is needed, at least until we have a way to retain transactions just for fee estimation (as we do for compact block reconstruction).

>For accelerating relay of blocks. When a node already has (most, or ideally all) transactions that are included in a block downloaded and/or validated, it does not need to redo those things when transactions actually appear in a block. The BIP152 compact blocks protocol relies on this principle. The faster the node network can propagate blocks through the network, the more it reduces the benefit of large miners over small miners (this is related to selfish mining), contributing to decentralization by not hurting new small miners entering the market.

Doesn’t the risk of having a spam-filled block orphaned because of slow propagation cancel out the risk that the miner will [accidentally] perform a selfish mining attack? This is another place where I’d love to see some actual numbers.

Also, blockreconstructionextratxn helps here.

>When miners accept transactions that a node shunned, the node is still required to download, process, validate, and store its result

Yes of course, but as the opreturn filter shows, if enough nodes are filtering, there is a 99% reduction in confirmed spam, so eventually the tradeoff is worth it

>forgoing any benefits related to moral stance or resource usage the shunning might have had in the first place.

That is a bold claim; again, I would love to see numbers that show how much an individual node runner is hurting himself by not relaying certain transactions… my hunch is that it doesn’t hurt much at all. I’ve been running Lightning on Knots for a long time and haven’t noticed any issues.

>Of course, nodes are in no way required to participate in transaction relay. They can use whatever policy they like, including not relaying transactions at all (the -blockonly setting), if they are uninterested in having a reliable view of future transactions.

Yeah, and if they are also uninterested in helping bitcoin function as a payment network…

>>I also hear the argument "Blocks are empty" so Miners need generate revenue. To which I also respond; Bitcoin mining is a free market and the difficulty adjustment helps miners set their output accordingly to balance their electricity bill. They could partially set their output off/on.
>Miners have huge capital investments in their hardware that needs to be paid off, the actual electricity costs of running the miners are only part of their bill. In the long term you're right of course that miners can and will shut down if they are unprofitable, and this will result in the difficulty compensating for it, making costs lower for the remaining miners. But even then, those remaining miners in the new equilibrium will prefer earning more fees over less fees!

Yes, and if everyone is filtering the same set of transactions, then no miner has an advantage here…

>And if people are willing to pay those, for whatever reasons, including ones you and I dislike, they'll find ways to do so.

Yes, and miners who include these transactions are hostile and as such will have additional costs, and there will be 99% fewer abusive transactions if we filter aggressively enough (again, see opreturn data)

>>So is this changed being pushed by people who want to put a storage business model on top of bitcoin, like the altcoins do ? What does will affect Node runners (like me) who don't want to store dumb JPGS and possible illicit material on their hard drives.
>Speaking for myself, I hope you believe me when I say that is not the motivation at all. I think these use cases are temporary hype cycles, and not rational use of blockchain space, but the market can stay irrational for a long time.

Agreed, they are temporary hype cycles, but they never stop. There is always another cycle, and our hostility to them is the primary deterrent that reduces their frequency and intensity.

>However, I believe that attempts to discourage these use cases through node relay policy, in the presence of widespread evidence that miners accept these transactions anyway, are ineffective, akin to making nodes bury their heads in the sand, and ultimately harmful to the decentralization of the system at large.

I disagree with all of these claims. See above discussion.

>(*) One small note however, the ecosystem does have an actual means of blocking transactions: consensus rule changes. If there is widespread agreement throughout the ecosystem that a certain class of transactions is harmful, the possibility exists in theory to adopt a consensus rule change that makes these transactions outright invalid, forcing miners to reject them (because otherwise they'd be producing invalid blocks, forgoing all revenue). This process is slow, should be used very carefully not to undermine fundamental properties (like censorship!) and is unsuitable for anything resembling a cat-and-mouse game like this, in my view.

Yes, this is the reason we should play the cat-and-mouse game at the policy level, and not at the consensus level. There is an army of thousands of noderunners who are eager to play the part of the cat. I honestly don’t see how we are going to lose against these invaders.

>However, I do want to bring this up to make it clear that in the presence of widespread, fatally-harmful behavior, node runners are not entirely powerless in this matter.

A consensus change would obviously be a last resort, as it is very easy to store arbitrary data in the blockchain, even with extreme measures like p2sh^2. The mempool is where we should focus our efforts.

Sincerely,

Chris Guida

[0]: https://bitcoin.stackexchange.com/a/127903/34855
[1]: https://gnusha.org/pi/bitcoindev/CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com/
[2]: https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/
[3]: https://x.com/GrassFedBitcoin/status/1931854732831977845
[4]: https://x.com/oomahq/status/1931856202511888465
[5]: https://github.com/gudnuf/memcooler
[6]: https://github.com/bitcoinknots/bitcoin/pull/119
[7]: https://x.com/cguida6/status/1965525597683060979

cc@murchandamus @sr_gi @pwuille @adam3us

A surprisingly tone-deaf comment from you, Rusty :/

2025-09-08T01:12:05+02:00

In reply to nevent1q…fj6r
_________________________

A surprisingly tone-deaf comment from you, Rusty :/

Gmax 😭

2025-05-16T17:02:58+02:00

In reply to nevent1q…yekq
_________________________

Gmax 😭

Same strategy as an immune system!

2025-05-15T03:24:20+02:00

In reply to nevent1q…2qal
_________________________

Same strategy as an immune system!

@nprofile…qft7 please consider funding this man! This is an ...

2025-05-14T02:37:03+02:00

In reply to nevent1q…mnun
_________________________

ODELL (nprofile…qft7) please consider funding this man!

This is an anti-spam machine gun for knots noderunners

https://github.com/bitcoinknots/bitcoin/pull/119

Also you can always bump the tx

2025-05-02T06:26:55+02:00

In reply to nevent1q…t55r
_________________________

Also you can always bump the tx

It would probably be straightforward to allow Lightning nodes to ...

2025-05-02T06:26:26+02:00

In reply to nevent1q…ql8e
_________________________

It would probably be straightforward to allow Lightning nodes to compensate for this a bit

Yes I know. I'm not surprised that my node is not publishing ...

2025-04-30T22:41:39+02:00

In reply to nevent1q…hzey
_________________________

Yes I know.

I'm not surprised that my node is not publishing zap receipts and I'm not super worried that other people can't see my zaps, but thanks for the heads up

If you need a lightning open or close to confirm in the very next ...

2025-04-30T22:37:43+02:00

In reply to nevent1q…4erq
_________________________

If you need a lightning open or close to confirm in the very next block, you're doing it wrong ;)

King 👑 #nevent1q…eg0w

2025-04-29T03:52:47+02:00

King 👑

quoting
nevent1q…eg0w
Starting out as a Maxi ⚡️⚡️

Bitcoin devs should do this more #nevent1q…4h0c

2025-04-28T05:13:55+02:00

Bitcoin devs should do this more

quoting
nevent1q…4h0c
Use your product.

Btw yes I got 6 1-sat payments on April 12. Thanks! ⚡

2025-04-28T05:12:03+02:00

In reply to nevent1q…drfz
_________________________

Btw yes I got 6 1-sat payments on April 12. Thanks! ⚡

Did I request this? Useful info... yeah I know my node ...

2025-04-28T05:03:56+02:00

In reply to nevent1q…sfz0
_________________________

Did I request this?

Useful info... yeah I know my node doesn't produce zap receipts, I'm using CLN with the clnurl plugin. There's another plugin I'm thinking of testing that claims to have support for zaps. How can I see if it's working?

I definitely don't want a cloud-based Lightning node, I'm fine self-hosting, thanks!

This is literally the opposite of the truth 😂

2025-04-12T15:57:23+02:00

In reply to nevent1q…nfer
_________________________

This is literally the opposite of the truth 😂

Interested, might not get time soon, I'm willing to ...

2025-03-11T19:37:12+01:00

In reply to nevent1q…ncan
_________________________

Interested, might not get time soon, I'm willing to contribute work or sats to the bounty ;)

start9.com

2025-03-11T19:28:47+01:00

In reply to nevent1q…2029
_________________________

start9.com

Whoa! A CLN plugin for controlling your node via NWC, written in ...

2025-03-11T19:24:31+01:00

Whoa! A CLN plugin for controlling your node via NWC, written in Rust! Now I'm aware of two NWC CLN plugins, the first was gudnuf (nprofile…r3ea)'s

quoting
nevent1q…3xak
https://github.com/thesimplekid/cln-nostr-wallet-connect

It depends on what you want to achieve, how much work you want to ...

2025-03-05T17:54:04+01:00

In reply to nevent1q…efkh
_________________________

It depends on what you want to achieve, how much work you want to do, and your level of skill.

If you want to run a full, sovereign Lightning node, run CLN/CLBOSS on s9 or Raspiblitz (depending on how much customization you want to be able to do).

If you just want something that works and is easy to maintain but requires a tiny bit of trust, use Phoenixd or Albyhub (both use LSPs, and are great). Albyhub is slightly more difficult than phoenixd but requires slightly less trust. I consider both to be beginner-friendly.

Think about what you want to do with the node as this will heavily influence the correct decision.

Well put! Bitcoin is the best way to organize humans to build and ...

2025-02-19T04:05:05+01:00

In reply to nevent1q…d2d6
_________________________

Well put! Bitcoin is the best way to organize humans to build and protect wealth, but it still needs humans to do the building and protecting!

Sort of having trouble following the conversation and ...

2025-02-13T16:11:38+01:00

In reply to nevent1q…e7je
_________________________

Sort of having trouble following the conversation and understanding why he was so triggered.

It sounds like your point is that segwit2x could have taken over bitcoin?

link to original post?

2025-02-09T01:03:30+01:00

In reply to nevent1q…cww3
_________________________

link to original post?

Yes, so many people forget that Lightning solves the UX for ...

2025-02-08T01:09:48+01:00

In reply to nevent1q…a803
_________________________

Yes, so many people forget that Lightning solves the UX for zeroconf payments.

No other coin has secure zeroconf.

And even if someone does do the analysis and it's favorable, ...

2025-02-08T00:50:07+01:00

In reply to nevent1q…us2a
_________________________

And even if someone does do the analysis and it's favorable, we should do CCV or TXHASH or something that actually does what we need, not CAT, which is an ugly hack.

Bro come on I'm looking for a real analysis As long as no one ...

2025-02-08T00:49:12+01:00

In reply to nevent1q…wjr3
_________________________

Bro come on

I'm looking for a real analysis

As long as no one provides actual numbers, CAT will never activate.

@nprofile…d6j2 might have something for that ...

2025-02-08T00:40:59+01:00

In reply to nevent1q…gwzm
_________________________

Start9 (nprofile…d6j2) might have something for that

https://router.start9.com

I didn't see any numbers in this response 😆

2025-02-03T00:03:32+01:00

In reply to nevent1q…hsl8
_________________________

I didn't see any numbers in this response 😆

1) runes and ordinals are spam, so this doesn't really help ...

2025-01-30T18:58:08+01:00

In reply to nevent1q…dtyq
_________________________

1) runes and ordinals are spam, so this doesn't really help
2) I'd need to head a convincing argument why you think this would work, based on numbers, not just speculation.

I want to hear a well-reasoned argument as to why

2025-01-27T23:41:59+01:00

In reply to nevent1q…948k
_________________________

I want to hear a well-reasoned argument as to why

You don't think it's achievable, but do you know ...

2025-01-26T18:57:49+01:00

In reply to nevent1q…2kdw
_________________________

You don't *think* it's achievable, but do you *know* it's not achievable?

AMMs are already deployed on Ethereum, work backwards from there.

2025-01-25T15:38:59+01:00

In reply to nevent1q…vz5z
_________________________

AMMs are already deployed on Ethereum, work backwards from there.

No need to deploy it, just make your argument using reasoning and ...

2025-01-25T14:20:06+01:00

In reply to nevent1q…r75r
_________________________

No need to deploy it, just make your argument using reasoning and math

Put a different way, who in their right mind would spend millions ...

2025-01-25T04:10:28+01:00

In reply to nevent1q…sdug
_________________________

Put a different way, who in their right mind would spend millions of dollars developing an AMM for a chain barely anyone uses?

Absolutely not. Those chains have very low usage volume.

2025-01-25T04:09:04+01:00

In reply to nevent1q…pkq8
_________________________

Absolutely not. Those chains have very low usage volume.

Do you have any first-hand experience that contradicts mine? I ...

2025-01-25T04:08:06+01:00

In reply to nevent1q…054x
_________________________

Do you have any first-hand experience that contradicts mine? I haven't heard of people switching from CLN to LND... have you?

>someone could just check lol

Go for it, then.

>nothing will stop users from using it if they want to The key ...

2025-01-24T16:37:11+01:00

In reply to nevent1q…jh8u
_________________________

>nothing will stop users from using it if they want to

The key question is, will they want to?

Even if the AMM takes a cut of every trade, if there are no traders, then the cost of building the thing in the first place will outweigh the revenue.

I hang out in circles of actual Lightning node runners and all of ...

2025-01-24T16:33:45+01:00

In reply to nevent1q…wyh4
_________________________

I hang out in circles of actual Lightning node runners and all of the new ones are using CLN, and I know several people who have switched from LND to CLN. I don't know anyone who has switched from CLN to LND.

>it would earn a profit, that's not really the issue, is ...

2025-01-24T04:20:28+01:00

In reply to nevent1q…nnmy
_________________________

>it would earn a profit, that's not really the issue, is it?

yes, that's precisely the issue because that means it would definitely get built and would definitely operate.

>The issue is mevil i.e. could miner make more money, "stealing" from users. Do you agree?

Yes, but MEVil is not an issue if the AMM is not profitable enough to operate.

>Seems that your first habd knowledge is social media posts ...

2025-01-24T04:18:49+01:00

In reply to nevent1q…xpm7
_________________________

>Seems that your first habd knowledge is social media posts

What? You just pulled that out of your ass 😆

As long as it can be shown that the design is optimally ...

2025-01-23T19:31:04+01:00

In reply to nevent1q…ktfy
_________________________

As long as it can be shown that the design is optimally efficient/profitable, and as long as it doesn't earn a profit, then yes.

Eltoo does not need CAT. Just CTV+CSFS or LNHANCE.

2025-01-23T19:28:43+01:00

In reply to nevent1q…5j4c
_________________________

Eltoo does not need CAT. Just CTV+CSFS or LNHANCE.

From my experience CLN is much more popular than a year or two ...

2025-01-23T15:39:13+01:00

In reply to nevent1q…hyns
_________________________

From my experience CLN is much more popular than a year or two ago.

But sure, I'm open to being proven wrong on that, though I'm very skeptical given my first-hand knowledge.

Correct, Lightning does not need CAT

2025-01-23T15:38:06+01:00

In reply to nevent1q…lj9c
_________________________

Correct, Lightning does not need CAT

Nostr event nevent1qqstlyn4fy28kylt0x82wd6s7m8c2c8kptwzeraut6ag0xxxsncrlsqzyq5ftsescglnsvvkcrhe3r0xm2pmsw69s0k4l8q7mv99t88v68usqgqkgft

2025-01-23T15:37:28+01:00

In reply to nevent1q…9dtx
_________________________

https://njump.me/nevent1qqsr0mldqkqurjwqd83xdh9ueyncemr2yd8m4q32axu3xvkth5ewhzcpzdmhxue69uhk7enxvd5xz6tw9ec82c30qgsz39wrxrpr7wp3jmqwlxydumdg8wpmgkp76huurmds54vuangljqqrqsqqqqqpydsryw

No, let's just end all central banks simultaneously.

2025-01-23T01:16:11+01:00

In reply to nevent1q…puva
_________________________

No, let's just end all central banks simultaneously.

They're the same picture

2025-01-23T01:12:02+01:00

In reply to nevent1q…uml7
_________________________

They're the same picture

Yes

2025-01-23T01:10:39+01:00

In reply to nevent1q…vrza
_________________________

Yes

Haha fair enough 🫡

2025-01-23T01:10:17+01:00

In reply to nevent1q…r5dr
_________________________

Haha fair enough 🫡

So someone needs to argue convincingly that it won't, ...

2025-01-23T01:09:30+01:00

In reply to nevent1q…xmhc
_________________________

So someone needs to argue convincingly that it won't, otherwise enabling CAT is epically dumb.

We just need bitcoin unilateral-exit L2s to scale to the world. ...

2025-01-23T01:08:36+01:00

In reply to nevent1q…3rjx
_________________________

We just need bitcoin unilateral-exit L2s to scale to the world. Not sure what "other networks" you're referring to...

Wherever you want? It doesn't need to go into production, it ...

2025-01-23T01:06:23+01:00

In reply to nevent1q…vwkc
_________________________

Wherever you want? It doesn't need to go into production, it just needs to be a credible proof-of-concept

Lol, that is not what I'm suggesting for Nostr. Read better ...

2025-01-22T20:46:59+01:00

In reply to nevent1q…5w0y
_________________________

Lol, that is not what I'm suggesting for Nostr.

Read better note1vpp7fyf3mynp9ep893dhdym792g2nfq25ctqj5wwhpzcjcafd4qsft4fmk

already done!

2025-01-22T20:45:34+01:00

In reply to nevent1q…cepy
_________________________

already done!

Terrible. This is why I voted RFK.

2025-01-22T20:43:04+01:00

In reply to nevent1q…k20l
_________________________

Terrible.

This is why I voted RFK.

Hellz yes!! 🙌 Do you guys think you might release an Android ...

2025-01-22T20:35:04+01:00

In reply to nevent1q…hdq9
_________________________

Hellz yes!! 🙌

Do you guys think you might release an Android client eventually? would love to be able to use clams there, I don't trust PWAs haha

By designing the most efficient AMM possible, and then proving ...

2025-01-22T20:33:11+01:00

In reply to nevent1q…ualk
_________________________

By designing the most efficient AMM possible, and then proving that it isn't profitable.

Most likely a majority still. But their share is rapidly ...

2025-01-22T20:20:05+01:00

In reply to nevent1q…jf4v
_________________________

Most likely a majority still. But their share is rapidly diminishing as they fail to implement basic improvements like bolt12, splicing, etc. The smart users have discovered that CLN is better.

Woohoo! Finally got my lnaddress working in both directions with ...

2025-01-21T22:16:36+01:00

Woohoo! Finally got my lnaddress working in both directions with no middlemen!

CLN with elsirion (npub1nc0…z5pa)'s excellent clnurl plugin for receiving https://github.com/elsirion/clnurl

Same node with gudnuf (npub1ce7…3d7m)'s cln_nwc plugin for sending 1-tap zaps https://github.com/gudnuf/cln_nwc

Now I'm zapping in style!

Next step: bolt12 and bip353 zaps :D

🤣

2025-01-21T20:52:53+01:00

In reply to nevent1q…y4kz
_________________________

🤣

Shocked, I tell you!

2025-01-21T20:43:22+01:00

In reply to nevent1q…qewv
_________________________

Shocked, I tell you!

surprise, surprise #note16f0…3f69

2025-01-21T16:40:45+01:00

surprise, surprise

quoting
note16f0…3f69
Wow, the first "Bitcoin President" made no mention of #Bitcoin in any speeches, priority lists, or executive orders.

The first "Bitcoin President" did not #FreeRoss on Day 1.

Can we please stop simping for politicians and get back to building?

What's great about a "premium relay"? And the other ...

2025-01-21T13:49:59+01:00

In reply to nevent1q…w00l
_________________________

What's great about a "premium relay"? And the other stuff

Thus*

2025-01-21T04:17:14+01:00

In reply to nevent1q…urdr
_________________________

Thus*

oh, neat! should I sign up?

2025-01-21T04:08:08+01:00

In reply to nevent1q…q6de
_________________________

oh, neat! should I sign up?

haha yeah primal. in amethyst we both just have purple check ...

2025-01-21T03:58:41+01:00

In reply to nevent1q…kqg9
_________________________

haha yeah primal. in amethyst we both just have purple check marks

Hey @npub18am…p424 how do I get a cool purple check mark next ...

2025-01-21T03:52:25+01:00

In reply to nevent1q…xyjq
_________________________

Hey Derek Ross (npub18am…p424) how do I get a cool purple check mark next to my name like you? I added my nip05 but I just have a boring gray check mark

Wallet of Satoshi is not permissionless.

2025-01-19T19:36:13+01:00

In reply to nevent1q…nm53
_________________________

Wallet of Satoshi is not permissionless.

So stop using mints that do this

2025-01-19T19:28:38+01:00

In reply to nevent1q…xd35
_________________________

So stop using mints that do this

Yeah but it makes no sense for a mint to censor transactions, as ...

2025-01-19T19:06:26+01:00

In reply to nevent1q…zztj
_________________________

Yeah but it makes no sense for a mint to censor transactions, as it cannot tell which token is which, as long as you don't use the same address as when you minted the token, or use Tor.

hmm zaps are broken on primal now too.. I wonder if the nwc relay ...

2025-01-19T18:35:55+01:00

In reply to nevent1q…rwls
_________________________

hmm zaps are broken on primal now too.. I wonder if the nwc relay isn't relaying my messages anymore? :/

1) how? 2) I wouldn't hold more money in Monero than I'm ...

2025-01-19T18:19:46+01:00

In reply to nevent1q…ad0y
_________________________

1) how?
2) I wouldn't hold more money in Monero than I'm willing to lose, either.

it's about 3-4 clicks for me... tap to zap, then tap 2 times ...

2025-01-19T18:18:39+01:00

In reply to nevent1q…hkgl
_________________________

it's about 3-4 clicks for me... tap to zap, then tap 2 times to confirm which wallet to open, then wait a few seconds to sync phoenix, then tap to actually send the payment. then hit back a bunch of times to get back into amethyst. it's like a 10x worse UX than primal. I like amethyst's push notifications though, and it seems to have better in-app notifications as well.

I don't see a reason to keep more than you're willing to ...

2025-01-19T18:16:21+01:00

In reply to nevent1q…4c3a
_________________________

I don't see a reason to keep more than you're willing to lose on any mint, anonymous or not.

pretty sure there's a way to do the swap atomically, but ...

2025-01-19T18:15:28+01:00

In reply to nevent1q…sx9t
_________________________

pretty sure there's a way to do the swap atomically, but maybe I'm misunderstanding

Yep, doing Lightning plugin stuff, helping people run nodes, ...

2025-01-19T18:14:02+01:00

In reply to nevent1q…gr0n
_________________________

Yep, doing Lightning plugin stuff, helping people run nodes, running meetups, the usual!

ftr I usually check in on Nostr every few months because every previous time it's sucked. this time was noticeably different.

how about you, what do you work on?

I'm down to join

2025-01-19T18:11:55+01:00

In reply to nevent1q…dnj9
_________________________

I'm down to join

does amethyst have a way to link a wallet using nwc? I love ...

2025-01-19T18:07:00+01:00

does amethyst have a way to link a wallet using nwc? I love primal's UX of one-tap zapping 🧡

OpenSats does great work, so I don't think it's ...

2025-01-19T18:02:59+01:00

In reply to nevent1q…fat2
_________________________

OpenSats does great work, so I don't think it's appropriate to recommend a boycott.

But yeah, donate your money where you like.

you can exchange them atomically for bitcoin, which makes them ...

2025-01-19T17:58:22+01:00

In reply to nevent1q…rp4l
_________________________

you can exchange them atomically for bitcoin, which makes them cool

They're not if you operate them purely over Tor

2025-01-19T17:57:06+01:00

In reply to nevent1q…lwhr
_________________________

They're not if you operate them purely over Tor

meme shamelessly stolen from @Kluckies_ on Twitter ...

2025-01-19T17:56:07+01:00

meme shamelessly stolen from @Kluckies_ on Twitter

sure, teaching people how to run Lightning nodes is one of my ...

2025-01-19T14:59:01+01:00

In reply to nevent1q…acvy
_________________________

sure, teaching people how to run Lightning nodes is one of my favorite activities!

I'll answer any questions people have! :)

why'd you think that? this time around Nostr sucks less than ...

2025-01-19T14:57:01+01:00

In reply to nevent1q…45jl
_________________________

why'd you think that? this time around Nostr sucks less than before.

much better than last time, though I'm still apparently ...

2025-01-19T06:32:33+01:00

In reply to nevent1q…z9aj
_________________________

much better than last time, though I'm still apparently struggling with the controls 😅

well that's not very nice.

2025-01-19T05:55:11+01:00

In reply to nevent1q…x4m6
_________________________

well that's not very nice.

My experience on Nostr was much better this time around than last ...

2025-01-19T01:11:05+01:00

My experience on Nostr was much better this time around than last time!

My I will come back tomorrow ;)

https://njump.me/nevent1qqspd59s6phk2j25n8h6clzqa66p45e3yhe0xzm39f0z3zc7cqm45wcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg8wd6sn4w07t39x36hekx35lcq55e45qytu2rhz5c20fndftxmwwspsgqqqqqqs946yss

quoting
nevent1q…v7vm
Hello Nostr!

Time for my twice- or thrice-yearly check in!

Anyone here yet?

Excellent! Looking forward to it 👌

2025-01-19T00:43:54+01:00

In reply to nevent1q…3nwn
_________________________

Excellent! Looking forward to it 👌

But yeah you need to buy the hardware. It's okay, it will get ...

2025-01-19T00:22:45+01:00

In reply to nevent1q…2c6x
_________________________

But yeah you need to buy the hardware. It's okay, it will get even easier over time.

Just sideload Phoenix, you don't need to use the pay store. ...

2025-01-19T00:14:24+01:00

In reply to nevent1q…xlwc
_________________________

Just sideload Phoenix, you don't need to use the pay store.

And CLN is totally entry-level if you use Start9 (nprofile…d6j2)

Phoenix Wallet and @nprofile…5fk2 Wallet (with CLN backend) ...

2025-01-19T00:10:39+01:00

In reply to nevent1q…6yr9
_________________________

Phoenix Wallet and ZEUS (nprofile…5fk2) Wallet (with CLN backend) have supported it since the beginning!

It's an absolutely miniscule change, basically just adding a ...

2025-01-19T00:04:29+01:00

In reply to nevent1q…rldf
_________________________

It's an absolutely miniscule change, basically just adding a field to kind 0

The code already exists, just needs to be polished haha ...

2025-01-19T00:03:17+01:00

In reply to nevent1q…x9z5
_________________________

The code already exists, just needs to be polished haha https://github.com/gudnuf/bolt12-covenant-zapper

It's long past due for bolt12 zaps! Anyone working on this ...

2025-01-18T23:34:51+01:00

It's long past due for bolt12 zaps! Anyone working on this already?

quoting
nevent1q…k7nl
Yeah I'm gonna spin up my own! I need a new lnaddress too... and then i need to fork in bolt12 zap support, this lnaddress thing is killing me haha

Yeah I'm gonna spin up my own! I need a new lnaddress too... ...

2025-01-18T23:33:54+01:00

In reply to nevent1q…g7x4
_________________________

Yeah I'm gonna spin up my own! I need a new lnaddress too... and then i need to fork in bolt12 zap support, this lnaddress thing is killing me haha

I'd say Google changed the world in ~2004. In 1998 no one had ...

2025-01-18T23:23:23+01:00

In reply to nevent1q…try2
_________________________

I'd say Google changed the world in ~2004. In 1998 no one had heard of it haha