steepdawn974

Ok i see, but what's and how things are getting clustered into a certain AS is important. These are all just heuristics; for instamce just because several nodes share the same AWS region doesn't mean they are one AS, and that you shouldln't connect to more than one.

2025-07-13 12:01:30 UTC

- reply

Not every single, just the big ones - which most users subscribe too. Probaly less than 20. It's not impossible.
Ideally ppl would publish to their own respective relays, and clients would find them via DHT-style discovery. But that doesnt scale I guess. Hence the current middle ground (some big relays as central access point for 95% of notes)
#nevent1q…tec0

2025-06-11 05:43:47 UTC

Bitcoin Core dev proposes to convert Core into a walled garden, membership-only repo.
🤷
All because every once in a while there is actual work to be done moderating a PR (btw something, for which already a full-time paid grant by @nprofile…uazd exists)
The more I read such nonsense coming out of Core, the more I think that giving Devs effectively a tenure (through Chaincode, longterm grants Brink, OpenSats etc) is part of the problem, not the solution.
"We want to do our thing, amongst ourselves, not be subject to public scrutiny. But please keep paying us."
Discuss.
---
cc @nprofile…f670 @nprofile…jsen @nprofile…tacz
https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/T/#u

2025-06-05 18:03:19 UTC

- reply

Via @nprofile…3478?

2025-05-17 19:50:40 UTC

- reply

I mean, I wouldn't mind some more intelligence in bitcoin, and Core 😝

2025-05-10 17:32:11 UTC

- reply

There is a clear separation between 1)consensus and 2)policy. The latter being each client's decision - this has at least been the argument of Lopp & co on why they can bypass "broad consensus ™️" in the ecosystem.
Let's entertain that thought. It works perfectly well in Lightning land: multiple implementations, adhering to the same base protocol rules ("consensus"), but differ in certain features ("policy").
Why is that/or not a model in Bitcoin mainchain land?

2025-05-01 06:29:21 UTC

- reply

Bitcoin Core is the dominant (really only) client in the ecosystem. It's maintainers this have the additional duty of being good stewards of the network/project as a whole - of they want it or not.
1) With that market dominance default configs matter as much as consensus rules.
But they are not just proposing to change/disable data carrier, but to remove this option completely -stripping users of the very choice to configure their mempool if they do choose.
2) What about miners? Adam Back correctly points out that through mempool policy miners construct their block template. Core physically removing this option will have make impact. First miners realize this, and speak up like Bob Burnett. Maybe @nprofile…xafw also cares. https://image.nostr.build/98f8088b2694caf9055bf779eff6e51ce9a9181bf2ae98eb19bfc10bb932808c.jpg
3) Loop and others made it clear that user concern *does not matter* - that Core contributors *alone* can discuss on this!
Plebs are to shut up and dribble.
Before the GitHub comments were locked there was a clear 4:1 ratio of commenters REJECTING this change. But Mr @nprofile…8lp0 says they don't get a say.
This is a violation of the (unwritten) rule of being good stewards.
How does Ten31 see this? Are you supporting and endorsing such behavior?

2025-04-29 17:30:23 UTC

- reply

Not sure you guys realize how arrogant, snobbish and elitist this comes across.
"Shut up and dribble you plebs! The Pros will handle this. This is Devs-only business!"
You *will* the support of the user base, if such important changes are just pushed through by a handful of ppl - while other changes (which you may not like) are filibustered for yearz.
And snarly sentiment a la "Good luck with your fork" just confirms this. Disappointing.

2025-04-29 10:51:46 UTC

- reply

So since stupid drama is out now, we're can finally get CTV+CSFS done, right??

2025-04-29 09:32:34 UTC

- reply

Thank you for the response.
Re Citrea. While they might be further along, it's still far from the usual rigid requirement, and certainly not an operational product.
This just makes the whole reference to and argument for Citrea in the OP mailing list incredibly weak (and dangerous imho)
Re: GitHub
First, I disagree that this qualifies already as "harassment". It's a valid, albeit dissenting argument, which should be able to be presented at the main stage.
Second, resorting to fine print bureaucract arguments for blocking ("Oh you should not have discussed this here's but in the line over there") makes Core look incredibly weak and insecure. Especially without warning/notice.
You must see that.
This is not the way trustworthy stewardship of a critical FOSS project looks like.
Even benevolent dictators must be benevolent to not lose support from Us the People.

2025-04-29 08:27:35 UTC

- reply

Citrea publishes some whitepaper(!), for a bridge that would benefit from relaxed OP_RETURN limits.
Immediately everybody at Core: "yeah let's DROP the limits - they're useless anyway. LFG 🚀"
All the while other major changes (e.g. CTV) there's years of filibuster: Where is your signet implementation? Where is your documented user demand? Where is the documented consensus? etc etc etc
[Ironically, something like CTV would have done away with the interactive presigning ceremonies that particularly hinder 2way pegs such as said Citrea's bridge]
You see the point why people are confused by how Core is handling that, don't you???
Besides, blocking dissenting voices from GH for the slightest of disagreements is absolutely disgusting 👎
This may break the straw for many ppl

2025-04-03 17:26:56 UTC

- reply

I literally thought at first he is farting the rhythm..

2025-03-18 11:47:37 UTC

- reply

Es ist eben nicht nur diese "kommunistische Missgeburt", sondern das Land, und Millionen von Menschen. So ein Staatszusammenbruch (und machen wir uns nicht vor, das ist es was es bedeutet) ist kein Zuckerschlecken..
Aber hey, Nach dem Krieg sind Alle gleich
(das ist ein 📖..)

2025-01-19 18:23:31 UTC

- reply

You assume the case where they'd want to single out a certain user.
It's much more likely they would (have to) apply much more broad/global action - such as enforcing authentication for *all user*. Or suspending Lightning swaps for non authenticated users.
These mints are custodians, and this CASPs (crypto asset service providers)/money transmitters etc under virtually any jurisdiction - who are under these rules required to KYC.
So it's just logical that Marty's asking the state for permission to let them operate. Because by the letter of the law, these mints would not be allowed to operate the way they do now.

2024-08-11 17:32:29 UTC

- reply

LOL. Bitcoin has some 10,000 nodes, which all constantly replicate all data amongst each other.
With Nostr I publish data to a set number of relays (11 in my case), and the data is not rebroadcast. If they delete it, it's gone forever (and I dont even notice)

2024-08-11 08:44:59 UTC

I learned 'the Cloud is just someone else's server' (which can't be trusted/relied on). How is Nostr any different ?
#askNostr

2024-04-01 20:14:29 UTC

- reply

And more is coming: (sorry, in German only but translator should do)
https://www.heise.de/hintergrund/Neuer-ETSI-Standard-zur-Ueberwachung-von-Fahrzeugdaten-in-Arbeit-9181896.html

2023-04-29 15:17:49 UTC

- reply

Well, you *can* build pretty much everything yourself in EC2 (VMs) or Containers. But the recommended approach (more scalable, secure, cost effective) is to use the various managed services: API Gateway, Dynamo, Cognito, Compute engine (Lambda) and what not.
Don't really know your exact requirement though. The above is the "generic" advice.. 😉