Abdel
A₿del fgu

Ok I will be back more often. Fucking network effect of X is hard to fight.
Time to do my part for real and bring more folks to the freedom of speech protocol

2025-10-14 10:37:23 UTC

Proposal: OP_STARK_VERIFY - Native STARK Proof Verification in Bitcoin Script.
https://delvingbitcoin.org/t/proposal-op-stark-verify-native-stark-proof-verification-in-bitcoin-script/2056

2025-10-07 08:27:40 UTC

- reply

Check this sir @nprofile…2nqv . Michael is from my team. We are cooking some cool shit that might unlock this in the future.

2025-10-06 05:41:50 UTC

- reply

Always looking for more ways to leverage ZK for Bitcoin and Nostr. What is the need exactly ?

2025-09-22 08:26:51 UTC

- reply

Oh ok cool. We did not finish yet. We will complete it when we reach the next milestone on Raito. Because right now the way we verify non spending of UTXO in zkpoor is naive and extremely inefficient which makes it impossible to prove on a large range of blocks.
Once we have proving of utreexo it will be much easier.
Also we found a way to couple the proof to the legit owner of the coins after the hackathon that we did not implement yet. Simply passing a public key as argument when generating the proof and adding it in the output of the proof. Only legit owner is able to generate a valid proof of ownership of the input UTXOs so then the owner can just send a message off chain to prove they generated the proof. To avoid someone just taking the proof and claiming to own coins they don’t own.
https://github.com/starkware-bitcoin/raito

2025-09-22 08:23:31 UTC

- reply

Here you go: https://github.com/AbdelStark/zkpoor

2025-09-18 13:49:26 UTC

- reply

I understand your concern here. This is fair criticism

2025-09-18 06:59:30 UTC

"If I wanted to destroy bitcoin I would just fund infinite developers who are very talented and tell them to make it better."
- Michael Saylor on op_return
I think he is not completely wrong, there is a risk. A risk of distraction, a risk of wanting to work on cool stuff because they are exciting, etc. those risks exist.
BUT, in my opinion, what Michael Saylor actually thinks is closer to this:
“If I wanted to destroy Bitcoin I would just scare people so that no one touches it and address the remaining issues and challenges that prevent Bitcoin to truly become P2P cash at the planet scale. It will make it easier for us to capture it and just hammer the NGU and digital gold narratives. Fuck their cypherpunk values and their hope of freedom.”
Who benefit the most from scaring people from ever touching Bitcoin again to try to improve it and fulfill its promise ? I think that considering Bitcoin final now is the biggest gift to governments or any powerful adversarial forces that would want to capture Bitcoin or prevent it from being adopted widely as money, and not just as digital gold.
Complacency also can kill Bitcoin. Job is not finished. The real fight has barely started.
https://blossom.primal.net/04dbdf0f6a405f0658a0d64a4773505be5812e89950928b43ea5498725e781c1.mov

2025-09-09 21:18:50 UTC

- reply

Seeing some of the comments, I realize there might be some confusion or misunderstanding about what this means. I confirm and re-iterate that this is an incredible performance and that no other proving system in the world today can achieve such feats with this level of cost-efficiency, trustlessness, and soundness. We're pushing the boundaries of ZK tech to make Bitcoin's history verifiable in ways that were unimaginable before.
First, some comments suggested sarcasm like: "They got it all the way 'down' to 6.5 hours", implying it's slow or underwhelming. Hmm, I think there's a huge confusion here! The 6.5 hours is the time to generate the FULL RECURSIVE PROOF for the entire chain. This is done ONLY ONCE, by ONE machine (and we're optimizing to bring costs down further).
LETS FOCUS ON THE REAL DEAL => Verification takes just 50-100 MILLISECONDS, even on small devices like phones. It's not about proving time, it's the asymmetry STARKs provide: proving is compute-intensive but one-off; verifying is blazing fast and scales infinitely. As we work hard to be able to prove full block execution (scripts, txs, etc.), verification will still be ~100ms for the whole chain. That's the game-changer!
Next element: "Proofs don’t validate." Actually, verifying the proof does validate! Instead of re-executing everything (the slow, traditional way), you verify the STARK proof, which cryptographically guarantees the same result, but exponentially faster and with less computation. It's like compressing validation into a tiny, efficient check without sacrificing security.
To explain further, here's a high-level workflow for our Compressed SPV Proof (using STARKs via Cairo+Stwo):
- Batch Execution: An executor processes batches of Bitcoin block headers (e.g., 1-10k, then 10k-20k) with bootloader and assumevalid Cairo programs, generating traces and execution inputs.
- Proof Generation: A prover creates a STARK proof attesting that block validation logic was correctly executed over those headers.
- Verification: The compressed proof + current chain state + MMR root goes to an on-chain/off-chain verifier, which trustlessly confirms:Validity & linkage of all headers back to genesis.
* Target block's inclusion (via MMR proof).
* Sufficient cumulative difficulty/work.
* Correct timestamps & consensus rules.
* Target tx inclusion (via Merkle/SPV proof).
See more details: https://github.com/starkware-bitcoin/raito

2025-09-09 21:16:58 UTC

- reply

This is for the proof generation of the whole header chain. Not for the verification. The verification of the proof takes 50-100ms even on a small device.

2025-09-09 21:15:47 UTC

- reply

Yes 👍

2025-09-09 21:15:32 UTC

- reply

As for the non interactive part, it’s being obtained using Fiat Shamir, which enable to simulate some random oracle and queries of the verifier without interactivity

2025-09-09 21:14:34 UTC

- reply

The zero knowledge part is from the verifier perspective. The prover needs of course the knowledge of the chain in this case. Btw note that we use a STARK proof here for the scaling properties and not for the privacy aspect. The goal is then to be able to verify in 50-100ms the validity of the entire header chain even on a small device like a phone

2025-09-09 07:07:34 UTC

- reply

Machine: c4-highmem-32
32 vcpus 248 GB RAM
Actual usage is 190/248, in "real-time" mode <100GB
proof size: ~1MB
on-demand hourly cost is $2.085424 USD
total cost: 2.085424*6.5 = $13.55
and this is not even the final form! (this is WITHOUT SHA256 builtin, Cairo M31, GPU acceleration, Proving parallelization)
https://github.com/starkware-bitcoin/raito
https://blossom.primal.net/3774da323d06efabe58d7cac88be81bc44732bfa3475581ea5732d1eec6bacbc.jpg

2025-09-09 07:06:40 UTC

NEW WORLD RECORD.
WE CAN PROVE THE WHOLE BITCOIN BLOCK HEADER CHAIN IN 6.5 HOURS.
FOR $13.5.
YES, WE HAVE PROVEN 16 YEARS OF BLOCKCHAIN HISTORY OF A $2 TRILLION ASSET FOR LESS THAN A BIG MAC COMBO MENU.
STWO, FASTEST PROVER IN THE WORLD, BACKBONE OF STARKNET.
https://blossom.primal.net/675f25bd8a9a380a9e2abf75c5c928db75c9045334944d3553c70f75b9068c1a.jpg

2025-09-01 13:20:28 UTC

One day you will pay using fiat currency for the last time without even realizing it.
Bitcoin.
https://blossom.primal.net/5cd852e1d9bc01c0adfc632d4055748138b3d3b15587bbe307353d06f4778167.png

2025-08-26 23:53:26 UTC

- reply

Welcome to the freedom of speech protocol

2025-08-06 14:16:50 UTC

- reply

Check demo video and info and repo here:
https://github.com/AbdelStark/pons/discussions/1

2025-08-06 14:16:08 UTC

Hear me out, PONS: Proof Of Non-Spam for Bitcoin!
I was discussing with @nprofile…a8pz about various usage of ZKP for Bitcoin, and he came with this intriguing idea to use Zero Knowledge Proofs to fight spam on Bitcoin (without breaking some designs such as BitVM).
Initially I was sceptical, but the more I think about it, the more I am convinced that it could be a very interesting idea to explore.
Just to be concrete, here are some examples of valid / non spam materials that could be theoretically proven via a system like PONS:
- Schnorr public keys: Prove knowledge of corresponding private key
- Hash preimages: Prove knowledge of data hashing to claimed values
- Taproot scripts: Prove leaf scripts are valid Bitcoin Script, not arbitrary bytes
- Merkle roots: Prove correspondence to actual Merkle trees of valid elements
As usual, I like to experiment and play with ideas, so I started to implement a proof of concept of this idea, for the minimalistic simplest example here that is: prove that a public key is "real" and not a "fake" public key.
You can see in the demo video below the following flow:
- Generate a Schnorr public key and its corresponding private key
- Create a digital signature of an arbitrary message
- Run a Cairo program that verify the signature against the public key
- Generate a STARK proof of the Cairo program execution using STWO prover
- Verify the STARK proof using STWO verifier
Sorry Luke Dashjr I know that you consider Rust as a woke language haha, but for now we have the STWO prover and verifier only implemented in Rust, so I used it for the demo. We can easily integrate the STWO verifier in Bitcoin Core or Knots via ffi though (as we already did in another POC).
So of course here it's completely overkill to use a STARK proof for this and you could do it much more efficiently without a ZKP, but it is to show how the architecture could look like end to end.
There are many interesting design questions, like how to make nodes / miners play nicely and prioritise transactions with valid proofs, how to incentivise the generation of proofs, how to make it efficient and not bloated, etc.
I am curious to hear your thoughts on this idea, and if you think it could be a good idea to explore further.
https://blossom.primal.net/b70cbd29c91b29df996b51bcc0365fa9c3ef3675f0e9335803020f42987c6d94.jpg

2025-07-30 16:56:37 UTC

- reply

I see your point and understand your perspective. Does not change my point about the fact that the tech that powers Starknet is orthogonal to this

2025-07-30 14:45:58 UTC

- reply

Thanks 🙏

2025-07-30 14:40:00 UTC

- reply

Starknet is a scaling solution. It’s a ZK rollup.
And it’s back by STARK proofs which themselves are a fundamental breakthrough in computational integrity.
I am taking about the tech here and that’s it.
And all Starknet stack and proving tech is open source and its security is guaranteed by math.

2025-07-30 14:14:37 UTC

Breaking news coming from El Salvador today, let me introduce you the first Starknet powered Bitcoin ATM in the world! Edgar did the first ever Bitcoin purchase from a K1 ATM where the funding is coming from a Starknet wallet via an atomic swap to Lightning!
https://blossom.primal.net/eeca9ad176f79645bfbe0d40414e866aedf8e6b9bd6cc1026d2046fc6a1ec9cb.mp4

2025-07-23 02:20:48 UTC

- reply

Thanks! I was there actually!

2025-07-22 20:32:19 UTC

Spending some time with the great folks at @npub17cy…4ml3 working on such an important mission: Bitcoin education in El Salvador and all over the world.
As I was told here: Mi Primer Bitcoin is a MOVEMENT!
https://blossom.primal.net/bfb878560fe82319e880a4b14c3b2bbd850c3e6a246fc4319e731f6898277a4a.jpg
https://blossom.primal.net/b073fee584fe246d2a3568df8c27a569a4854d981bcacb9e3e00e4a4e8e323d7.jpg
https://blossom.primal.net/b543d09f506a2d33a3a5dc52a9549c474703f13bc3b7645b440729d25b918f9d.jpg
https://blossom.primal.net/580e50b424433a8fd8967254da253adcfe7efcf11c15e86b551e8ee02708086f.jpg

2025-07-21 14:08:25 UTC

Yosh Nostriches, I am in San Salvador this week. Any recommendations for Bitcoiners to meet there or cool places for Bitcoiners in general.

2025-07-17 16:43:48 UTC

I was chatting with the Alby wallet team about their Lightning MCP server using Nostr Wallet Connect. Forked it to integrate Lightning <> Starknet atomic swaps via Atomiq Labs SDK.
In the demo, I fired up Claude Code (also did it with Goose) and asked it to handle an end-to-end swap: "swap 311 sats to STRK". It executed perfectly, pulling from my Primal wallet via NWC connection string and performing the swap.
Fully trustless (HTLC reverse submarine swap).
Exciting times for building Bitcoin apps with AI. 🧡
#Bitcoin #BitcoinAI #ClaudeCode #Goose
https://blossom.primal.net/3cdb822eac41849d32f57a22d79257f5c5987cea925e15a8d17d169cb8c18c53.jpg
https://blossom.primal.net/0e15fd66dba1457aa22ae37031df8526f0a7a62fbab8c874dc7f7d8a3c609439.jpg

2025-07-15 09:15:13 UTC

Bitcoin covenant toolkit: A deep dive into CTV and CSFS
https://hackmd.io/@AbdelStark/bitcoin-covenant-toolkit-ctv-csfs

2025-07-15 07:36:45 UTC

- reply

Beau jeu ça

2025-07-11 14:54:43 UTC

Built a proof of concept of Bitcoin vaults to showcase CTV & CSFS on Mutinynet signet.
Basic vault: Funds locked to a P2TR output with a single leaf CTV script committing to a trigger tx template. Trigger moves to a conditional P2TR: IF branch requires CSV delay + hot key sig; ELSE is CTV to cold address (immediate, no sig). NUMS internal key forces script spends.
Hybrid vault extends to two leaves: One for CTV path (same as basic). Second for CSFS: Verifies a Schnorr sig over a delegation message (e.g., "EMERGENCY_DELEGATION:AMOUNT=...:RECIPIENT=...:EXPIRY=...:VAULT=...") from treasurer key, allowing direct spend to recipient (escape hatch).
Demo flow 1: Cold clawback via CTV. Fund vault P2TR. Broadcast trigger (satisfies CTV from vault). Then broadcast cold tx from trigger (ELSE branch, satisfies CTV to cold). No delay. Works as emergency response if trigger detected (e.g., hot key compromise).
Demo flow 2: Delegation via CSFS. Treasurer signs message authorizing ops team to spend X sats to Y by Z block (though the amount and other dynamic transaction params are not enforced in the demo, would require OP_AMOUNT, might be possible forcing the spender to provide the transaction data in the witness, check the signature of the tx data with CSFS, and then introspect the transaction elements we want like the amount, but not sure the parsing / splitting of the transaction elements would be practical). Spend vault directly via CSFS leaf: Witness includes sig, message hash, treasurer pubkey, script, control. Bypasses CTV/timelock for authorized emergencies.
https://github.com/AbdelStark/doko
https://blossom.primal.net/8f73b8b148dc7ceadd07e96f2fe28f235f4dbd303025c1b1f60fe31e5c23680c.mp4

2025-07-02 05:45:38 UTC

- reply

Yes 🙌

2025-06-25 04:23:42 UTC

- reply

Btw being able to generate the proof on a normal desktop is not really required in the sense that as the node what you need to do is to verify the proofs and this is very efficient and fast in a small device. For the proof generation it’s still better to delegate it to bigger machines and have them aggregate the proofs and do the recursion to amortize the cost. It remains trustless anyway.
But still we want to lower as much as we can the requirements to be able to generate the proofs

2025-06-25 04:09:49 UTC

- reply

Depends what you call a decent time window. It’s still a challenge today mostly because of sha256 which is horrible to prove and of course we have a prove an insane amount of sha256 hashes.
We will likely have at some point to built a sha256 built in to speed things up drastically.
Right now the proof is only the block header not the full block, we need to remove the sha256 bottleneck to be able to do this efficiently for the full block.

2025-06-24 16:12:26 UTC

Running Bitcoin ZK Knots, baby!
We've successfully run a POC verifying a STARK proof of Bitcoin's mainnet block #1 inside a modified Bitcoin Knots client.
The proof validates critical consensus rules:
- Timestamp
- Chain difficulty
- Block difficulty
- Proof of Work
Here’s the technical flow:
- A Cairo program defines the block header consensus rules & generates the execution trace: https://github.com/starkware-bitcoin/raito/blob/1cca29f0435ef74b34c8cca29f76393c7079b898/packages/assumevalid/src/lib.cairo#L49
- The STWO prover generates the STARK proof from the trace: https://github.com/starkware-libs/stwo-cairo
- A modified ProcessNewBlockHeaders function in Bitcoin Knots performs the proof verification: https://github.com/starkware-bitcoin/bitcoin/blob/c2505b4c9a3a420634de651220f76285e0b7ee64/src/validation.cpp#L4690
The main purpose of this POC was to test the integration of our Rust-based proving stack into the C++ codebase.
The ultimate vision? To improve Initial Block Download (IBD) dramatically by allowing the entire chain's validity to be verified with a single recursive proof.
Once Raito is fully equipped with recursive proving and strong performance, we'll be back to implement a full, real-world IBD with ZK verification enabled. Stay tuned!
Follow our StarkWare Bitcoin Github for updates: https://github.com/starkware-bitcoin/
https://blossom.primal.net/3656c71afab40e3e83775852f8ed7e8e08a79d6024f7c77c5ea5bb698f611801.jpg
https://blossom.primal.net/2e2354ac26e7e9d047ebb256522b9ece0fb6fa9f8781156641a5fa4d22cd49be.jpg
https://blossom.primal.net/dae66e7677756043a10dd3cedd1a0753070669ab27af1b7abc47a82dc5eb1e9c.jpg

2025-06-19 11:06:28 UTC

- reply

🧡

2025-06-19 08:11:00 UTC

Decentralized mining on Bitcoin is an important area. We've developed a prototype within Stratum v2 that leverages STARK proofs to achieve a more trustless system and better preserve the strategies of individual miners.
Our demo shows the individual miner (JD client) generating a STARK proof for the validity of the coinbase transaction and the total fees of the block template, all without disclosing the list of transactions. The JD server can then verify this STARK proof, confirming the block template's validity and the claimed sum of fees, without gaining any knowledge about the specific transactions.
This also provides an advantage for mining pools from a regulatory perspective due to plausible deniability, which in turn improves the network's censorship resistance. While this is currently a proof of concept, our goal is to extend it to include full transaction validity in the future. We're keen to collaborate with teams working on decentralized mining and will also be exploring this with Datum.
#Bitcoin #DecentralizedMining #StratumV2 #Datum #STARKs #ZeroKnowledgeProof
https://blossom.primal.net/9948a4c329bd2ab346e53fa93cc97e4c68b6f7a62d1ffdb327b0e63f071b4269.mov

2025-06-18 09:07:34 UTC

- reply

Just prove it

2025-06-17 16:59:56 UTC

- reply

🫡

2025-06-17 14:06:03 UTC

- reply

@nprofile…hp6j are you down to meet some folks from StarkWare ?

2025-06-17 13:52:18 UTC

Hey, any Bitcoiner in Prague tomorrow? I won’t be there but have few colleagues from StarkWare who will be there and would love to meet more Bitcoiners.
If you wanna hang out with them and chat about Bitcoin in general and / or zero knowledge proofs let me know.

2025-06-09 16:23:42 UTC

- reply

There is actually no better way to fight spam and mitigate shitcoinery on Bitcoin than actually improving it as money and payment system.
CTV + CSFS enhance Lighting and other scaling designs, and it improves self custody for the masses.
Stop trying playing cat and mouse with the filters and let’s actually make Bitcoin fully usable for payments, a true p2p electronic cash unstoppable system.
#FixTheMoneyFixTheWorld #Bitcoin #CTV #CSFS
#nevent1q…c7um

2025-06-09 14:25:29 UTC

Posting here for more visibility on Nostr.
CTV + CSFS: a letter to the technical bitcoin community from 43 engineers
Full text at ctv-csfs.com
Let’s accelerate and improve Bitcoin as money and as a tool that people can use to take back their sovereignty.
CTV and CSFS can improve significantly Lightning network and have many other benefits.
Study them, discuss them, share your opinions, debate.
Hyperbitcoinization intensifies.
https://blossom.primal.net/7462ef0a619ed12f52be04d62b9431b2284a93c61d9915d5bb0ad47791f72659.jpg

2025-06-05 09:31:31 UTC

Feeling cute, might find hash collisions later.
We can do covenants today, we are just negotiating the price now.
https://collidervm.org
#Bitcoin #Covenant
https://blossom.primal.net/6338ebcea8bcd106d5492eec505c30bc514cb0b15586e67052ea582f864a94ba.jpg

2025-06-04 09:52:28 UTC

- reply

This is the way brother. Keep up building relentlessly

2025-06-03 11:06:49 UTC

Stateful computation on Bitcoin mainnet without Fraud Proofs has been achieved internally with ColliderVM .
It's a toy implementation to demonstrate the concepts.
We can already do covenants on Bitcoin, now we are simply negotiating the price 😘
What are the interesting properties that ColliderVM could bring on the table:
- Capital efficient: no fraud proof windows
- 1-of-n security model for safety and liveness
- No protocol upgrades / soft fork required
- Immediate settlement without challenges
The problem: Bitcoin's scripting language is intentionally limited, making stateful computation challenging.
In particular:
- No native statefulness: Bitcoin Script lacks loops, has size restrictions, and can't persist data across transactions
- Capital inefficiency: Existing solutions like BitVM2 require operators to lock capital during fraud proof windows
- Trust assumptions: Current approaches often require trusted setups or weaker security models
In short, what you need to achieve stateful computation on Bitcoin is really those 2 properties:
- Logic persistence (the code of the program / computation must remain consistent across transactions)
- Data persistence (otherwise you are vulnerable to the inconsistent input problem)
ColliderVM is an attempt to overcome those challenges in a different manner than BitVM. But before going deeper, let's be clear on the current status of ColliderVM:
ColliderVM is currently a research project and should not be used in production environments. The protocol is in active development and exploration phase.
While the theoretical foundations are promising, it remains unclear whether ColliderVM will prove practical for meaningful real-world use cases. Significant research and development work is still required to determine its viability.
Ok, now that this important disclaimer is done, let's explore more the context of this demo on mainnet.
In short, ColliderVM combines presigned transactions with hash collision puzzles to enable stateful computation without fraud proofs.
- Presigned flows: Create 2^L parallel transaction flows during offline setup phase, each corresponding to a unique flow identifier.
- Hash Collision Puzzle: Operators find nonce r such that H(x,r)|_B matches a flow ID, ensuring input consistency across transactions.
- Immediate Settlement: No fraud proof windows or capital lock-up.
So, what did we do for this Mainnet demo ?
Real Bitcoin transactions demonstrating a ColliderVM's two-step range check computation: verifying that 100 < x < 200 across separate onchain transactions.
The range check computation was split in 2 functions (F1: x > 100, F2: x < 200). The onchain hash function used is blake3 (BitVM implementation).
Here is the transaction flow of the demo:
- Funding transaction: Initial funding transaction that provides the UTXO for the ColliderVM computation sequence.(https://mempool.space/tx/3b42fd759eb68ebcbcd10e7f3a0635aef92ecd7efefc6cdc3f48b967eb38826b)
- F1 transaction: validates that the input value (114) is greater than the lower bound (100) (https://mempool.space/tx/86a7fdf5c614d2d8fdb2fa6353ca4b277ce877a250449736a87d3906754e2a82)
- F2 transaction: validates that the input value (114) is less than the upper bound (200). Larger due to hash collision verification. (https://mempool.space/tx/e576d63343865cbf4e66846dca0a6689aad9f428738d75391c5cbc049fd34d27)
- Spending transaction: Final transaction that releases the funds after successful verification of the range check computation. (https://mempool.space/tx/27a4d470a3b2d39862cb310ca1be7eb20030c1721844d2e7eb275d8ffafe61b3)
ColliderVM parameters used for the demo (very low security):
- L: 4 bits, set size of 16 possible flows
- B: 16 bits, hash prefix length for collision puzzle
- Security gap: 6 bits (B - L/2 = 16 - 2 = 14 vs honest 12 bits)
Total transaction fees: 172,126 sats (~$179 at demo time).
~136 kB of total onchain data.
ColliderVM toy code: https://github.com/AbdelStark/collidervm_toy
ColliderVM paper: https://eprint.iacr.org/2025/591
https://blossom.primal.net/b4c09d224035b3fa7a99d175856a908b545a117cda7c05bdcf74a8ef6e74c059.jpg

2025-05-26 15:53:07 UTC

- reply

True that

2025-05-26 15:52:52 UTC

- reply

Yes 💯

2025-05-26 15:52:37 UTC

- reply

Yes this is what I am saying through the lines. With still some objective criticism on the current state of Knots (which is not something that cannot change)

2025-05-26 11:12:12 UTC

- reply

It’s a worst version of Core by all metrics and ways to measure in terms of open source practices. Not saying it cannot change but today it’s the case.
It’s an accumulation of patches mostly reviewed and merge by a single guy.
I think there is value in client diversity, but should be done in a better way. And maybe it was a chicken and eggs problem and the reason that Knots is in this situation was because not sufficient demand. Let’s see if things change with the growing demand.

2025-05-26 09:47:35 UTC

Just run a node anon. And yeah you can choose whatever implementation you want. That’s good.
Personally I prefer running Core and I don’t consider Knots being a production grade serious alternative on par with Core in terms of open source and software best practices (and there are obvious reasons for this to be the case, and it does not mean it could not change), but the choice is yours and it’s fine if you switch to Knots as a voice of protest. I think client diversity is a healthy debate to have at the end of the day, so maybe the filters drama was a good excuse to put it on the table I don’t know. I think there is a lot of bad faith arguments from some people pushing users to switch to Knots but that’s fine, Bitcoin is resilient and does not care about those drama.
But yeah, just run a node, it really matters.

2025-05-23 09:29:42 UTC

- reply

Wen Cashu ?

2025-05-23 09:29:10 UTC

- reply

StoRe of ValUe buy mY StonKs bro

2025-05-21 10:41:01 UTC

Bitcoin decentralised mining: pools should trust the math, not the miner, and miners should gain privacy for their transaction selection which improves censorship resistance of the network.
Stay tuned.
Stratum V2 + STARK proofs 👀

2025-05-19 09:34:10 UTC

- reply

Very cool!

2025-05-15 10:09:36 UTC

Gm to those running a well maintained software following best practices of open source development.

2025-05-09 19:36:28 UTC

Filters are cool but have you tried verifying a STARK proof with OP_CAT on a signet.
Peak spam at its finest.
https://blossom.primal.net/f94ac22bd5802544bd7d149daef42c7d9f707f37982d347557275354d10bf2c4.jpg

2025-05-09 19:10:34 UTC

“To be truly radical is to make hope possible, rather than despair convincing.” - Raymond Williams
Bitcoin is radical hope for the world, seriously.
Let’s fight, TATAKAE!
https://blossom.primal.net/18c3e3264d53198e7302fe2a6fdb987f71ea14a3c3e54ab26fc94ac81158d481.png

2025-05-02 10:29:03 UTC

- reply

What?!!! That’s very weird haha

2025-04-30 03:56:52 UTC

- reply

Weird. Works for me both on desktop and mobile. With and without VPN.
https://m.primal.net/QiAJ.jpg

2025-04-29 04:57:27 UTC

- reply

Yes I believe so

2025-04-25 09:42:24 UTC

be me: yesterday I found randomly a paper about 2 Circle STARK friendly hash functions working with Mersenne M31 (RPO-M31 and XHash-M31: Efficient Hash Functions for Circle STARKs by Tomer Ashur1 and Sundas Tariq)
then i was: ohhh wow, looks interesting. then: write a rust implementation
then start thinking: wait, maybe it could be a good candidate for a Circle STARK friendly AND Bitcoin Script friendly hash function
then: start doing analysis and cost estimate
then realise that they would NOT be practical to implement in Bitcoin Script...
It's a pity for this but still it's very interesting hash functions, and the fact that they natively work with M31 is super promising.
Maybe it's worth building a Cairo and Solidity implementation and benchmark the costs. They might be more interesting to use than Poseidon for Circle STARKs M31.
Paper: https://eprint.iacr.org/2024/1635.pdf
Rust repo: https://github.com/AbdelStark/rpo-xhash-m31
https://m.primal.net/QchI.jpg

2025-04-17 14:38:26 UTC

- reply

Welcome to the freedom of speech protocol

2025-04-10 14:37:59 UTC

- reply

https://primal.net/e/nevent1qqspyuy5nlmaxsfrzja50nhaeg7tzrhszk89xccgv9es5t5xzzl86kqyk8dqf

2025-04-10 14:37:06 UTC

- reply

I think you should add the number in BTC terms it's better. Fixed it for you.
https://github.com/block/bitcoin-treasury/pull/10

2025-04-10 01:44:59 UTC

- reply

Nice 💪

2025-04-06 14:41:40 UTC

- reply

Welcome to the freedom of speech protocol

2025-04-06 10:03:10 UTC

Gm from Hong Kong Nostriches.
https://m.primal.net/QGEJ.jpg

2025-04-05 11:30:02 UTC

Bitcoiners in Hong Kong, register and come to our event on Monday.
We will discuss covenants, Rollups, STARKs, Cashu, Lightning network and more.
https://lu.ma/3q2zemn9?locale=en-GB
#BitcoinEvent #BitcoinConference #BitcoinDevsGathering

2025-04-03 17:19:27 UTC

- reply

💯

2025-04-03 16:29:26 UTC

- reply

Thanks bro

2025-04-02 17:13:23 UTC

- reply

Nice to meet you and thanks for

2025-04-02 16:33:43 UTC

What can you do with Monero style ring signatures for Nostr ?
You can build an Anonymous Voting platform using Nostr identities to vote.
Thanks to the Back's Linkable Spontaneous Anonymous Group, you can detect double voting without leaking identities.
Check Ringable demo 👇
A client-side anonymous voting platform using Nostr-compatible ring signatures.
Ringable allows users to create proposals and vote anonymously as part of a predefined group (a "ring" of public keys). It leverages the cryptographic power of bLSAG ring signatures to ensure that while votes are verified as coming from a valid member of the ring, the specific voter's identity remains hidden.
The cryptographic functions are powered by the Nostringer Rust library, compiled to WebAssembly (WASM) for use in the browser.
Live demo: https://ringable.starknetonbitcoin.com
Ringable rep: https://github.com/AbdelStark/ringable
Nostringer: https://github.com/AbdelStark/nostringer-rs
https://m.primal.net/QBwR.mov

2025-03-28 16:37:05 UTC

- reply

Yes very acceptable!
I did not benchmark but I suspect the ts execution times would me much higher.
Btw I will add wasm compatibility for usage of the rust lib in browser and in JavaScript projects

2025-03-28 16:03:37 UTC

- reply

By popular demand (from 1 person), I added a BLSAG (Back's Linkable Spontaneous Anonymous Group) variant in Nostringer, similar to Monery scheme.
bLSAG signatures are linkable but still anonymous.
Can detect duplicate voting or track usage of a credential.
https://github.com/AbdelStark/nostringer-rs?tab=readme-ov-file#blsag-backs-linkable-spontaneous-anonymous-group
#nevent1q…8axp
https://m.primal.net/PwPZ.jpg

2025-03-28 13:59:43 UTC

- reply

Nostringer in Typescript was fun, but did it again in a serious language this time: nostringer-rs is born, a blazing fast unlinkable ring signature scheme, written in Rust 🦀
Try it with the cli: cargo install nostringer_cli && nostringer_cli demo
https://github.com/AbdelStark/nostringer-rs
#nevent1q…wsca
https://m.primal.net/PwKv.jpg

2025-03-28 07:58:16 UTC

- reply

It’s basically equivalent to the size of the ring.
Its ring size multiplied by 32, and add 32 bytes.
So if ring size is 10 it’s 342 bytes.
If ring size is 100 it’s 3232 bytes.

2025-03-28 04:39:15 UTC

- reply

Hey. I don’t know if/when I will have time to do it myself but if someone wants to work on that and submit a PR that would be cool.
It would enable interesting use cases.

2025-03-27 18:00:47 UTC

- reply

Let’s do the opposite. Find devs to contribute and we will help to fund them to work on this if there is demand

2025-03-27 16:54:00 UTC

- reply

Yes

2025-03-27 16:37:01 UTC

- reply

Ohhh you like it. Noice!

2025-03-27 16:23:38 UTC

- reply

🙏

2025-03-27 16:22:12 UTC

- reply

👀

2025-03-27 16:21:56 UTC

- reply

I lacked inspiration haha.
Thanks mate

2025-03-27 15:49:52 UTC

- reply

https://primal.net/e/nevent1qqsxssyqgz0znnlkqyh72948e5x4m6xtktsng3x6pg0z85uqrwmzakq3nuh2v

2025-03-27 15:48:12 UTC

- reply

Thanks

2025-03-27 15:47:52 UTC

- reply

🫡🙏

2025-03-27 15:29:08 UTC

Introducing Nostringer - unlinkable ring signatures (SAG) for Nostr pubkeys.
Instead of doing some Ghibli stuff I implemented a prototype of unlinkable ring signatures for Nostr.
It's using Monero style Spontaneous Anonymous Group signatures (SAG).
What does it enable ?
Ring signatures allow multiple members of a group to sign a message without revealing which member actually signed it.
I explored this after chatting with @nprofile…nqad who wants to use this concept for WalletScrutiny. Basically his idea would be to let users write reviews as accredited wallet developers. Because of the competition between wallets it's better to not disclose who posted a review.
It would be sufficient to know that it was posted from someone belonging to a group of accredited developers.
Checkout the demo and repo in the links below.
Live demo: https://nostringer.starknetonbitcoin.com
Repo: https://github.com/AbdelStark/nostringer
https://m.primal.net/PvLL.mov

2025-03-26 06:57:35 UTC

- reply

For now it has only basic event publishing. If there is demand maybe we can join forces and build a fully fleshed Nostr MCP server

2025-03-25 15:17:40 UTC

- reply

Yep works too haha

2025-03-25 15:11:56 UTC

- reply

I sent you a dm on telegram mate

2025-03-25 15:10:58 UTC

- reply

Yes. With the new version that is deployed you can pay directly with any wallet compatible with Alby Bitcoin Connect lib

2025-03-24 10:46:49 UTC

L402 is HTTP for payments, literally, and it's cool!
Built a Rust implementation for an API paywalled with the L402 protocol, as well as a demo frontend.
Try it yourself: https://l402.starknetonbitcoin.com
Pay with Lightning and query the latest Bitcoin block.
L402 protocol: https://l402.org
Rust L402 server repo: https://github.com/AbdelStark/l402-server-example-rs
L402 demo frontend using Nextjs repo: https://github.com/AbdelStark/l402-shield
#bitcoin #lightningnetwork #payment #mcp
https://m.primal.net/PrNA.mov