Spam is flooding Bitcoin with useless transactions. This clogs the network, makes fees expensive, and pushes real payments out. Spam wastes resources and harms #Bitcoin 's usefulness as money.
Spammers say "spam is subjective" and "a valid transaction is valid." But spam has clear traits: it wastes space inefficiently and exploits #Bitcoin functions in malicious ways. High fees also don't justify spam, since demand should drive fees up, not attacks.
Spammers claim #Bitcoin can thrive with greedy miners only caring about money. But miners need Bitcoin to stay useful long-term to profit. If spam ruins Bitcoin's utility as money, that hurts miners too. Letting spam dominate blocks devalues #Bitcoin.
Some say you can't fight spam, but that's false. Bitcoin users have coordinated to fight spam before. Updating filters and getting miners on board sends a message about undesirable activity.
Making payments cheaper doesn't justify spam either. Cheaper fees reduce miner income, same as spam filters. But efficiency improves network value, benefiting miners long run. Spam to push scaling changes also dangerously rushes upgrades without proper testing.
"Satoshi embedded data on-chain, so spam is allowed." But Satoshi didn't bloat or exploit #Bitcoin . Reasonable data inclusion doesn't equal endorsing spam attacks on the network. What matters is intent and responsible use of resources.
"High fees will stop spam eventually." No - spammers currently pay the highest fees. They'll keep raising budgets to clog the chain. Real demand should drive fee prices, not attacks. Relying solely on pricing spam out fails to address the root problem.
"Everything is good for #Bitcoin." Not true - #Bitcoin has flaws and vulnerabilities like any system. Attacks can impair functionality. Defenses are needed to protect network reliability and user experience. This requires proactive effort from Bitcoiners.
You can fight spam by running updated node software (i.e. #BitcoinKnots or Ordirespector) , setting policies against spammy transaction types, asking developers for better defaults and UI controls, pointing hash rate at filtered mining pools like OCEAN MINING and staying vocal about protecting #Bitcoin .
#Bitcoin once had strict anti-spam rules that got relaxed over time. Spam isn't new - previous incidents led to things like Blockchain DNS and Counterparty flooding the network. But coordinated action reined these in. With motivation, spam can be mitigated again.
For more information, check out below website
https://wtfhappenedinfeb2023.com/
cc nostr:npub1wnlu28xrq9gv77dkevck6ws4euej4v568rlvn66gf2c428tdrptqq3n3wr nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk nostr:npub10vlhsqm4qar0g42p8g3plqyktmktd8hnprew45w638xzezgja95qapsp42 nostr:npub1au23c73cpaq2whtazjf6cdrmvam6nkd4lg928nwmgl78374kn29sq9t53j
As much as i might agree that inscriptions are spam and should be blocked, the reality is that there's no way to actually enforce this. Even if we used mempool filtering, inscribers would simply send their txs direct to the miners (who are happy to take the fees) or they can use obfuscation techniques like Inviscriptions ( https://conduition.io/bitcoin/inviscriptions/ ) to bypass the filtering in an endless cat & mouse game.
Please take a look at https://dev.risczero.com/api
It basically lets you write your rust code and generates a STARK proof from it. You can use almost all existing crates. It also allows you to wrap the STARK proof into a smaller size SNARK later.
...Aaaaand their docs site is down 🥲
Please take a look at https://dev.risczero.com/api
It basically lets you write your rust code and generates a STARK proof from it. You can use almost all existing crates. It also allows you to wrap the STARK proof into a smaller size SNARK later.
Thank you! Their zkVM seems like exactly what i'm after
Anyone with STARK experience know how to build and validate a simple proof of secp256k1 discrete logs and SHA256 hashes?
I know ZeroSync must be doing this as part of their blockchain sync proofs. But i'm looking for a self-contained way to build and validate the proofs in rust.
nostr:npub1j8d6h8mzvc8f2fvysrf09nlkmn7m2ylj32zl5na4tm5e8fd5dqysrg26k2
nostr:note1pr9682453najqgfrc746pgu6rtntd3ugnyy4srt5cesapnf42nuspfmkpy
This question was too tempting.
nostr:note15nsyy4d5ck4804w0tp75v5sjd3raq68rsqxc3jjztkg3kselnfpqvkqpgn
So I wrote this:
Yep! I have some links to some more beginner-friendly ECC stuff here:
My pleasure 😄 i wonder if the DKG could be run securely (incl commitment round) if the participants sampled random evaluations instead of random coefficients when building their keygen polynomial f_i(x)...
Damn, times like now, i really wish nostr had LaTeX support 🥲 stay tuned and maybe i'll write something up for this
You sit down, put pencil to paper and work it out!
There is likely a way to do the DKG so that some cosigners have fixed keys and others have fresh random keys. It'd probably just take some clever math and a security proof that malicious cosigners couldnt bias the DKG to do evil stuff like backdoor the group key.
Actually bringing your own key is possible, but there are limitations.
A FROST signing share is a polynomial evaluation. If, say, 3 people join together each bringing their own fixed signing shares, there exists some quadratic polynomial that interpolates their shares. However, it's impossible to find a linear (degree-one) polynomial which does the same.
In practice, this means if `n` people BYOK, they can definitely create an `n` of `n` threshold key with FROST. They can then issue new shares to add more people to the FROST group if they wanted, to make it an `n` of `m` threshold.
I'm not sure about the security implications of what a DKG would look like if only SOME keys are fixed and others can be variable. That's a different ball game 😅
Pixels prove nothing anymore. KYC is useless. Wait till someone designs a 3d printer that can print convincing passports or ID cards.
Want me to share an image of a piece of paper so i can use your exchange? Sure, here's an image.
Want me to show you a shiny piece of plastic so i can board this plane? Sure, here is one.
The only way to rigorously prove something is to do so mathematically. In the age of AI, anything else can be faked. Identity is about what you know, not what pieces of paper you have (Debate me).
Reverse engineering is a blast, I've been on a bit of a binge with it lately 😇
⚠️ Technical article ahead!
I reverse engineered TicketMaster's rotating barcodes for fun and profit. They're actually very easy to pirate.
I'm now mostly convinced that the ordinals/inscriptions crowd just don't care about efficiency. I made some simple constructive suggestions which could save millions of dollars a year in wasted mining fees. All are being ignored.
https://github.com/ordinals/ord/discussions/2879
nostr:npub1mutnyacc9uc4t5mmxvpprwsauj5p2qxq95v4a9j0jxl8wnkfvuyque23vg I see you guys are working on some fun DLC-based features!
Do you have any interest in giving your users the option to buy into DLC wagers off-chain using Lightning? If so, my 'Ticketed DLCs' concept might be of interest.
https://conduition.io/scriptless/ticketed-dlc/
https://delvingbitcoin.org/t/off-chain-dlc-ticketing-systems/214/3
Clever 'coiners cooperate instead of clashing.
Forget fruitless debates about whether inscriptions _ought_ to be used or not. I want to start concrete technical action to reduce the burden of inscriptions on the bitcoin mempool and fee market by going directly to the source.
We should be spending our effort streamlining the actual apps and protocols which are pushing all this data into the mempool in the first place. Who wants to help?
I wanna hear your ideas on how to make ordinal #inscriptions more efficient, and less onerous on bitcoin's fee market.
I can see #inscriptions are causing a lot of debate in the Bitcoin community, particularly regarding whether they should be "filtered" or "censored" at the mempool level by labeling them non-standard.
I'm here to tell you that this moral/ethical tennis match is irrelevant. Inscriptions can be pushed to the blockchain invisibly, by disguising the data inside normal-looking transactions. The true plaintext data is revealed only after the inscription is mined. I call these, "Inviscriptions", and they cannot be censored without resorting to flimsy heuristics.
https://conduition.io/bitcoin/inviscriptions/
Have comments? Suggestions? Hit me with a review!
The whole point of a standards spec document is that it is STANDARD. Saying "everyone should define their own standards" (especially for a network communication protocol) is like telling vehicle drivers to choose their own traffic bylaws.
Relevant XKCD. 