Abdel
A₿del fgu

If you want to change the world, don't protest. Write code!

Public Key

npub1hr6v96g0phtxwys4x0tm3khawuuykz6s28uzwtj5j0zc7lunu99snw2e29

NIP-05 Address

Profile Code

nprofile1qqst3axzay8sm4n8zg2n84acmt7hwwztpdg9r7p89e2f83v007f7zjcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqglwaehxw309aex2mrp0yh8xmmkv4ex26t8dckhxarpvd4jummjvu0zhd24

Publishing to

relay.primal.net

relay.sovereign-stack.org

premium.primal.net

Author Public Key

npub1hr6v96g0phtxwys4x0tm3khawuuykz6s28uzwtj5j0zc7lunu99snw2e29

Show more details

Last Notes

2026-07-30 18:46:00 CEST

- reply

❤️

2026-07-30 15:10:48 CEST

- reply

Prof. Eli Ben Sasson joined (finally!) the Freedom of speech protocol.
Censorship resistance for the win.
Nostr is and will be a critical piece of the Integrity Web of tomorrow. So it’s a natural fit for someone who pioneered and contributed so much to the realms of verifiable computation to embrace it and support it!
#nevent1q…mrt4

2026-07-30 15:08:40 CEST

- reply

2026-07-30 15:07:18 CEST

- reply

welcome to the freedom of speech protocol sir

2026-07-30 15:00:39 CEST

Ok I will come back and post more often on Nostr. It’s a shame I don’t manage to maintain consistency here. Now there is a real chance with all the buzz on Buzz to make Nostr getting finally the real traction it deserves.
Freedom of speech protocol.
And much more actually.
The future of agentic commerce might happen on Nostr.
Decentralized marketplace of services and billions of agents exchanging services over Nostr DVMs.
Let’s go

2026-03-27 15:00:13 CET

- reply

Repo: https://github.com/AbdelStark/nostrain

2026-03-27 14:59:47 CET

I trained a GPT across 4 workers using Nostr as the communication layer.
No central server. No coordinator. Workers exchange compressed pseudo-gradients as signed Nostr events through public relays.
This is "nostrain", distributed ML training over Nostr.
How it works:
1. Each worker trains locally for N steps (standard PyTorch/AdamW)
2. Computes pseudo-gradient: trained_params - initial_params
3. Top-k sparsifies → int8 quantizes → zlib compresses
4. Signs it with BIP340 Schnorr, publishes as a Nostr event (kind 33333)
5. Collects peer gradients from relay
6. Averages + Nesterov outer step
This is DiLoCo, the same algorithm Google used to train LLMs across poorly-connected datacenters.
Except the "datacenter interconnect" here are censorphip resistant Nostr WebSocket relays.
The repo ships a char-level GPT demo (834K params, 4 layers, 4 heads).
4 workers each get a different slice of Shakespeare (inspired by Karpathy nanoGPT).
No worker sees the full text.
Text evolution over 5 rounds:
Round 0: ROMEO:2NYPp@JTb<;2..qce[vP
Round 2: ROMEO: Maf sthat pine ted mes I chat
Round 5: ROMEO: d I shes mear to the ce withat, tre so ther wisho
Loss: 4.5 → 2.4. The workers that saw completely different text are converging to the same model through the relay.
Why Nostr?
Because Open Source / Decentralized / Sovereign AI must win.
Public relay infrastructure already exists. WebSocket pub/sub at scale, with cryptographic identity built in. Every gradient event is Schnorr-signed and verifiable by any subscriber.
You don't deploy servers. You don't manage infrastructure.
You just point workers at relays that already exist.
The relay doesn't know or care that it's carrying ML gradients.
And it is censorship resistant.
https://blossom.primal.net/67e3f37cd2d9bf88f58213eb649d29cc0cc424266cac4b5899696e367bf72b02.mov

2026-01-13 22:19:34 CET

- reply

It’s interesting . I did not try myself but I know some folks (great agentic wizards) that like the approach

2026-01-11 08:11:50 CET

Do meta prompting more. Less complex setup and orchestration. Rely more on self reflect capacity of the models.
That’s it.

2026-01-11 08:10:50 CET

- reply

With this:
https://whiteout.xultra.fun/

2025-12-12 22:42:22 CET

fgu >>>>> ngu
freedom tech will save the world

2025-12-08 16:10:51 CET

Time to shake the balance of power in the world honestly

2025-12-08 16:10:37 CET

Global majority ftw

2025-12-08 16:10:27 CET

- reply

Yosh sorry

2025-12-08 16:10:19 CET

- reply

Gosh

2025-12-08 16:05:59 CET

- reply

That’s super cool!
My only caveat is to use STARKs and not SNARKs.
Also for quantum resistance

2025-12-03 08:35:48 CET

- reply

🧡💪

2025-12-03 08:15:03 CET

zero knowledge proofs are truly another 0 to 1.
it's a complete paradigm shift.
a new way to verify integrity of computation.
on bitcoin and other blockchains the way to verify integrity of the network is by re-executing everything.
you run your full node (you should! it's the only way to have true sovereignty), and you validate everything, the consensus rules are respect, execution is correct, etc.
but of course this process is hard to scale, because of the tension between making this verification accessible to anyone (and hence to low hardware and devices), and increasing throughput / computation power.
zkp breaks this dichotomy. you can preserve fully the ability to verify cheaply, efficiently, even on small devices, without even re-executing blocks.
it feels magical, but this is really what it brings.
you, as an individual, even with a raspberry pi, can verify fully the actions performed by big machines, even super computers, even if they have 1000000x more compute power than you.
we are yet to see the implications of such a new paradigm really.
it started with blockchains, for scaling and privacy, because right now this is the only "industry" that is sufficiently paranoid to desire trustlessness, but you can be certain that zero knowledge proofs will shake many more industries (healthcare, military / defense, logistics, ai, you name it).
it's a whole new world of possibilities.
btw, starks are the endgame of zero knowledge proofs.
truly scalable, no trusted setup, quantum resistant, pure mathematical power.
those things are not just moon math anymore.
they work, in real world. starknet proving system alone has secured over $1.5 trillion (yes trillions!) of cumulative trading volume over 5 years running in production, has processed over a billion transactions.
it's the most battle tested zkp system in the world.
zkps will change the world, first because they will turn bitcoin into truly unstoppable private and scalable p2p cash for the planet. and remember, if you fix the money, you fix the world (i truly believe in this!).
but then they will also change many more industries.
prove the world, one stark at a time!

2025-12-03 08:14:35 CET

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 12:37:23 CEST

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 10:27:40 CEST

- 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 07:41:50 CEST

- reply

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

2025-09-22 10:26:51 CEST

- 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 10:23:31 CEST

- reply

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

2025-09-18 15:49:26 CEST

- reply

I understand your concern here. This is fair criticism

2025-09-18 08:59:30 CEST

"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 23:18:50 CEST

- 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 23:16:58 CEST

- 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 23:15:47 CEST

- reply

Yes 👍

2025-09-09 23:15:32 CEST

- 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 23:14:34 CEST

- 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 09:07:34 CEST

- 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 09:06:40 CEST

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 15:20:28 CEST

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-27 01:53:26 CEST

- reply

Welcome to the freedom of speech protocol

2025-08-06 16:16:50 CEST

- reply

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

2025-08-06 16:16:08 CEST

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 18:56:37 CEST

- 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 16:45:58 CEST

- reply

Thanks 🙏

2025-07-30 16:40:00 CEST

- 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 16:14:37 CEST

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 04:20:48 CEST

- reply

Thanks! I was there actually!

2025-07-22 22:32:19 CEST

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 16:08:25 CEST

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 18:43:48 CEST

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 11:15:13 CEST

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

2025-07-15 09:36:45 CEST

- reply

Beau jeu ça

2025-07-11 16:54:43 CEST

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 07:45:38 CEST

- reply

Yes 🙌

2025-06-25 06:23:42 CEST

- 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 06:09:49 CEST

- 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 18:12:26 CEST

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 13:06:28 CEST

- reply

🧡

2025-06-19 10:11:00 CEST

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 11:07:34 CEST

- reply

Just prove it

2025-06-17 18:59:56 CEST

- reply

🫡

2025-06-17 16:06:03 CEST

- reply

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

2025-06-17 15:52:18 CEST

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 18:23:42 CEST

- 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 16:25:29 CEST

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 11:31:31 CEST

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 11:52:28 CEST

- reply

This is the way brother. Keep up building relentlessly

2025-06-03 13:06:49 CEST

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 17:53:07 CEST

- reply

True that

2025-05-26 17:52:52 CEST

- reply

Yes 💯

2025-05-26 17:52:37 CEST

- 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 13:12:12 CEST

- 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 11:47:35 CEST

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 11:29:42 CEST

- reply

Wen Cashu ?

2025-05-23 11:29:10 CEST

- reply

StoRe of ValUe buy mY StonKs bro

2025-05-21 12:41:01 CEST

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 11:34:10 CEST

- reply

Very cool!

2025-05-15 12:09:36 CEST

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

2025-05-09 21:36:28 CEST

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 21:10:34 CEST

“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 12:29:03 CEST

- reply

What?!!! That’s very weird haha

2025-04-30 05:56:52 CEST

- reply

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

2025-04-29 06:57:27 CEST

- reply

Yes I believe so

2025-04-25 11:42:24 CEST

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 16:38:26 CEST

- reply

Welcome to the freedom of speech protocol

2025-04-10 16:37:59 CEST

- reply

https://primal.net/e/nevent1qqspyuy5nlmaxsfrzja50nhaeg7tzrhszk89xccgv9es5t5xzzl86kqyk8dqf

2025-04-10 16:37:06 CEST

- 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 03:44:59 CEST

- reply

Nice 💪

2025-04-06 16:41:40 CEST

- reply

Welcome to the freedom of speech protocol

2025-04-06 12:03:10 CEST

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

2025-04-05 13:30:02 CEST

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 19:19:27 CEST

- reply

💯

2025-04-03 18:29:26 CEST

- reply

Thanks bro

2025-04-02 19:13:23 CEST

- reply

Nice to meet you and thanks for

2025-04-02 18:33:43 CEST

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 17:37:05 CET

- 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 17:03:37 CET

- 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 14:59:43 CET

- 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 08:58:16 CET

- 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 05:39:15 CET

- 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 19:00:47 CET

- 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 17:54:00 CET

- reply

Yes

2025-03-27 17:37:01 CET

- reply

Ohhh you like it. Noice!

2025-03-27 17:23:38 CET

- reply

🙏

2025-03-27 17:22:12 CET

- reply

👀