Pleas help, good NOSTR neighbors!
Can you point me at some best practice for sharing a NOSTR profile? Is the gold standard for that still just sharing the same private key, or is there any NIP for some more elegant form of delegation?
Dishonest shitcoin shills, ranked from the most to the least annoying, as of now, top 10:
1) XMR
2) KAS
3) LTC
4) BCH
5) ETH
6) BSV
7) XRP
8) SOL
9) BNB
10) DOGE
ETH and BSV shills used to be on top of the shortlist 2 years ago. XMR & LTC used to be on the bottom 8 years ago.
Nothing against Amethyst, still great. But slow enough that I wouldn't open it just to check notifications on a random free second between doing stuff.
Incredibility well-designed and well-realized game by D++! Masterfully hosted by Martell!
I managed to rug some money from @UNCLE ROCKSTAR, which is always my main goal in life!
https://m.primal.net/KKii.jpg
I joined nostr before most bitcoiners tbh. Before Jack made it cool. :)
But I just don't have the habit yet to check amethyst as often as I do X. I guess it has to do with drama/controversy.
There's a disgusting gaslighting operation going on, coordinated by retardinal shitcoin scammers, seeding around several factual lies:
1) "Valid or expensive things can't be spam: spam is always free and protocol-level-invalid"
2) "Most Bitcoin developers have always been against using mempool filters to fight spam, Core never did it"
3) "Core's mempool filters are working as always intended, there never was an unintentional and unforeseen behavior of the datacarriersize parameter in tapscripts"
4) "The block-increase via witness-discount shipped with Segwit to appease big-blockers didn't end up incentivizing spam over real transactions"
5) "Mempool filters are anti-free-speech and anti-free market censorship, a precursor to OFAC compliant blocks"
6) "Mempool filters can be, contemporarily, totally ineffective in creating friction to spam AND ALSO extremely hurtful for fee prediction
7) "Ordinals and Wizards are not a typical and overt shitcoim grift (with negative effects on privacy and UX for Bitcoiners) but legit technical innovation for Bitcoin"
All lies. Absolute, clear, literal, evident, verifiable lies.
I'm skeptical of filters as a long-term sustainable solution for spam attacks, where the attacker is well-funded enough to bribe miners into behaving maliciously. I think the only structural and long-term solution can only be increasing economic density of L2s, to fight L1 censorship and spam with fee pressure. I believe covenant SFs in general and LNHance in particular would greatly help towards such goal. But I don't tolerate the above lies. And sadly the LNHance campaign is now deeply entangled with promoting them.
THE GASLIGHTING NETWORK:
- "Don't believe your own memories of using LN non-custodially on a daily basis for countless times in the last few years, but believe fraudulent marketing claims by shitcoin scammers about you never actually doing what you actually did and do"
- "Don't compare LN to existent, realistic and sustainable alternatives, including its own future iterations and evolutions, but to imaginary born-perfect, silver-bullet, turn-key solutions like gigameg-blocks, miraculously brought to you by the Second Coming of Bitcoin Jesus, resurrected to bring you with him in the Hard Fork Heavens"
- "Don't think about real-world economic/monetary dynamics, pushing most actual users for much of the foreseeable future to prioritize their concern over inflation and confiscation of their long-term savings, over coffee-paying costs or risks, but make up imaginary millions of people with no fiat but somehow lots of sats to spend in billions of fast/cheap transactions starting tomorrow"
- "Don't engage in nuanced and honest discussions about the actual security-model spectrum for different use-cases, but pretend that those millions of imaginary sat-spenders somehow always need, for their imaginary fast/cheap transactions, the very same trustlessness models than slow/huge ones."
- "Don't acknowledge the fact that Bitcoin's usability for normies has been brought from nonexistent to mediocre over 15 years of hard work, but pretend its layer1 was born perfect, without inherent issues like chain-anal/coin-selection/fee-estimation issues"
Thanks man. But I prefer to cut ties with Shitcoin Magazin completely at this point. But I absolutely respect that the threshold is personal and not clear-cut.
Did you know? When you pay sats to an orange-pilled taxi-driver, but you only do that at the end of the ride, without having written on global-consensus blockspace at every unit of Plank-time, you are being a CUSTODIAN, and custody-Bitcoin is NOT real Bitcoin!!!
STATIST LARPER!!!
Or maybe, just maybe, you should chill out a bit, and accept the existence of a security-model spectrum, while always aiming at the best extreme (that of total trustlessness) whenever possible, within reason, improving the improvable, without selling impossible dreams. Maybe.
Uh? The only radical mempool policy change proposal I see (removing incentive-incompatible filters entirely) are from Peter Todd and Ben Carman, but don't seem to have much following. Milder, more conservative proposals come from Luke Dashjr in Knots & disrespector-patch promoters in Core (extending to tapscript the very same datacarriersize policy that Core uses for pre-taproot txs) and Mark Erhardt (filtering out bare multisig in Core as well, as Knots already does since year). All minority views. Do you hear about anything else?
Matt, which of the people listed below do you think are misunderstandings higher order effects? Or there are others?
nostr:nevent1qqsy0tl2e27wfz9gl5qk7r2jtpgqqrr83dseczv75uccld9lw6aq0xcpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qgsw79gu0guq7s98t473fyavx3akwaafmx6l5z4rehd50lrcl2mf4zcrqsqqqqqp7zg45k
Thank you for answering one-off even if blocked elsewhere (I block very liberally on Twitter, here it's neither possible nor needed).
The proposal you list is the second "type" I mention in my brief list. The higher order effect you mention (increasing already present offband auctions of blockspace) would be common between that and the third "type" (Much's proposal to filter out bare multisig, apparently popular among Core devs). But since Core already filters high-fee-paying valid txs, it seems to me that, at least in principle, the first "type" is the only proposal that would avoid that higher order effect completely...not the status quo. Even if I find it likely that the umprecedented move to a total lack of mempool filtering could produce way more/bigger higher order effects.
I mostly see people yelling because he's claiming that even in the case of the inflation bug, it would be legit bug fixing to change the documentation to align with the (buggy) code. But maybe we have a different follow-list so we see different yelling.
I think that both "filter teams" I mentioned (OCEAN-led datacarriersize proposal and Chaincodelabs-led bare-multisig proposal) are skeptical of important higher order effects of updating current Core's filter due to the fact that current Core's filter seamingly didn't produce such effects, and the new proposals don't change their fundamental logic. The stronger arguments I've seen about why these new updates would be worse are actually by the team proposing to remove non-fee-based filters from Core completely. But I'm quite sure that would have important higher order effects as well.
I'm not sure Luke or Murch want to wish away any economic game theory, but it's clear it's not a game theory "that makes Bitcoin work", since Core currently filters away high-fee-paying txs from mempool.
I think is entirely reasonabe on their part to suggest only mempool-level upgrades and not soft fork: mempool policy is a matter of local preference, relatively safe & dynamic, block validity is a matter of global consensus, very risky, hard to change and very hard to change back once changed. So far the only one I've seen suggesting a consensus change was a malicious troll by an "ordinals" developer, trying to lure anti-spam users into running a disastrous fork without even an activation date (I don't remember his name, but he's friend with some Bitcoiners so he gets a pass for such irresponsible behavior, sadly). In general, managing something as dynamic as spam with consensus rules seems frankly crazy to me. Spam attacks and DDoS are preferable to consensus failures and splits.
Bitcoin deva always advocated for whitelisted script templates, nothing new: currently Core stansardness rule explicitly whitelist 5 types of txs, while all the other possible types are nonstandard, regardless of the fees. Not having whitelists in mempool policies is *most definitely not* "what makes Bitcoin bitcoin".
I can't prevent malicious or apatic miners get their massive stack of fees coming from "NFT" frauds and spam attacks: I can just refuse to cooperate actively and shame them publicly.
I absolutely agree with you that one can think all of the inscriptions are spam, and accept nothing can be done about it. It may be the case. One could also think that something may be done to some degree (as I suspect) but that it's still better to focus efforts on other things: totally honest and respectable take.
True. It would also be less useful to do so, as of now:
- I post less frequently, so there wouldn't be much of my content I can ban you from anyway
- I don't get tagged frequently, either by friends or foes, so I don't have to prevent that very aggressively
Actively proposing block templates that hurt Bitcoin users is not something that we can ask Luke to do. But that's irrelevant to the actual Ocean's plan, which is to move such decision to adult miners, instead of leaving it to daddy pool. The possible negative revenue diff for miners (still to be demonstrated, since for example Luxor's "wizard" blocks were paid offband by shitcoin spammers and paid nothing to workers) just needs to be small not to overshadow positive revenue diffs.
Oddbean new post about login | logout
Notes by giacomozucco | export