Abdel
A₿del ∞/21M 🐺 - 🐱

https://github.com/AbdelStark

A₿del ∞/21M 🐺 - 🐱

Public Key

npub1hr6v96g0phtxwys4x0tm3khawuuykz6s28uzwtj5j0zc7lunu99snw2e29

NIP-05 Address

abdel@snort.social

NIP-57 Address

youngturkey7@primal.net

Profile Code

nprofile1qqst3axzay8sm4n8zg2n84acmt7hwwztpdg9r7p89e2f83v007f7zjcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgjwaehxw309ac82unsd3jhqct89ejhx7vy2ql

Publishing to

relay.primal.net

purplepag.es

nos.lol

Author Public Key

npub1hr6v96g0phtxwys4x0tm3khawuuykz6s28uzwtj5j0zc7lunu99snw2e29

Show more details

Last Notes

2024-08-09 16:46:40

- reply

Ah, not ultra instinct though ?

2024-08-09 15:14:28

Summary of my fun week playing with Cashu, that I discovered recently.
This week I did:
- try and tested Cashu.me wallet and loved the UX from the user perspective (sending some sats to my Cashu wallet directly from my Nostr client was also very fun)
- read the Cashu docs
- implemented first step of BDHKE in Cairo and wrote an article about potentially ZKfying Cashu using STARK proofs
- implemented the full BDHKE in Zig
- contributed to Moksha Rust implementation to add criterion benchmarks
- realised that my Zig implementation was 10x slower
- moved to using the libsecp256k1 in C instead of Secp256k1 from the Zig std lib
- managed to have better perf than the Rust version
- contributed to CDK to add criterion benchmarks

2024-08-09 11:52:55

Managed to beat the Rust implementation with a Zig implementation ⚡️
Initially it was slower, but, moving to use the same libsec256k1 C implementation for operations on SECP256k1 curve, now the Zig version is slightly faster.
113 micro seconds for the End to End BDHKE!
Zig is fast ⚡
#note1xjw…sdxj

2024-08-08 18:20:26

- reply

My pleasure!
But how did you notice haha ?

2024-08-08 13:25:30

Me today: write BDHKE scheme in Zig (https://github.com/AbdelStark/coconut).
Benchmark it: Oh wow it's super fast, 1 millisecond for the end to end scheme.
Find the Rust implementation (https://github.com/ngutech21/moksha) and benchmark it: it's about 10 times faster than my Zig implementation 😭
Gg Moksha folks! 🦀 is blazingly fast damn.
I suspect there might be a gap in terms of performance between the Secp256k1 implementation of the Zig std lib and the C implementation (the secp256k1 crate being a Rust wrapper library for Pieter Wuille's libsecp256k1 in C).
Zig benchmark:
https://m.primal.net/JsUV.png
Rut benchmark:
https://m.primal.net/JsUX.png

2024-08-06 13:09:03

What about Zkfying Cashu guys ?
https://hackmd.io/@abdelhamid/starknut-zkfying-cashu

2024-08-05 15:55:05

Implemented step 1 of the Blind Diffie-Hellmann Key Exchange (BDHKE) in Cairo.
This scheme is used in Cashu (ecash protocol for #Bitcoin).
Tested against the Nutshell reference implementation and got same results for blinding of secret messages.
Would be cool to implement the other steps to have a version of Cashu protocol that is provable with STARK proofs.
https://m.primal.net/JowI.png
https://github.com/AbdelStark/bdhke-cairo

2024-08-05 06:53:33

Macro is horrible, risks of escalation of war, Asian Stock Markets crashing like never, capitulation from large funds.
https://m.primal.net/JoXz.jpg
Nayib Bukele knows it well, Printer is coming.
That's why he was smart enough to bet the future of El Salvador on #Bitcoin, and history will prove him right.
No doubt about this.
https://x.com/nayibbukele/status/1820288907423977798

2024-08-02 22:18:00

- reply

I'd Buy That for a Dollar!

2024-08-02 14:29:05

- reply

this is so based!

2024-08-02 12:58:32

- reply

Totally makes sense yes.
I will work on documentation and examples.

2024-08-02 12:45:55

- reply

Yep mate you are right.
I had this in mind. The reason i did not do it yet is because for my POC the Job request kind is very specific to a single example which is the proving of a Fibonacci sequence. The parameters don't really make sense for a generic scheme.
I need to think about how to make a standard format for a Job kind that would be `ZK_GENERATE_PROOF` or something like this.
Or maybe it's better to have different kinds depending on the type of proof and implementation, so for my case it would be more: `ZK_GENERATE_CIRCLE_STARK_PROOF`.
Anyway, i am open to feedback and advise on this question.
https://github.com/AbdelStark/askeladd/issues/11

2024-08-02 11:49:08

- reply

Yes the overhead can be very big depending of the size of the computation.
Possibly it can be 2 order of magnitudes slower and more expensive.

2024-08-02 02:50:02

- reply

Webassembly directly I don’t think so.
However there are RISC Zero, SP1 or Jolt that enable to prove risc-v instructions (and so any language that can compile to risc v target, i.e directly)

2024-08-02 02:47:14

- reply

Thank you.
In general I would say there are 3 options to generate a ZK proof for a specific computation:
- build custom circuits: this is a very low level task that requires deep knowledge of moon math and cryptography, super hard to maintain.
- use a general purpose ZK VM like Risc Zero and prove the execution of your existing code you want to prove. The benefit is that you don’t have to rewrite the code you can use it directly as is. However there is a big performance overhead
- rewrite the code you want to prove with a specialized high level ZK DSL like Cairo (this is the technique I am using). Maximal efficiency.

2024-08-01 20:44:07

Provable Bitcoin Script VM is moving forward nicely, we implemented more than half of the opcodes in a week 🤯
https://github.com/keep-starknet-strange/shinigami
Of course in the remaining ones there are some that are much more complex to implement, but this is very promising.
https://m.primal.net/JlTF.jpg

2024-08-01 20:41:21

- reply

Yes 👍
Would bring privacy because you can compute over encrypted data

2024-08-01 16:52:40

- reply

I will try to come with more precise estimate with different scenarios to see if that makes sense in real word context scenario.I will try to come with more precise estimate with different scenarios to see if that makes sense in real word context scenario.

2024-08-01 16:44:57

- reply

Ahhh ok I guess I know why we dont understand each other now. This model is completely different thing. It's more to transform the L1 itself to a ZK L1, which is different that offloading computation to an L2 and maintain the integrity of the state root of the L2 on the L1 using ZK proofs verification.
In the model of a ZK L2 Rollup (let say Starknet on Bitcoin for the sake of the example), you would maintain the state root of Starknet L2 on Bitcoin L1, and you can move it only by submitting correct proof from moving to previous state to new state, and of course you need to submit DA as well.
But then if you submit only state diffs (which is what Starknet is doing), if you have a lot of traffic then it scales extremely well. And you can have a much bigger ratio than this.
It depends on the frequency of settlement and usage of course. But still we can achieve much bigger scale than this.

2024-08-01 16:17:49

- reply

Yes agreed!
Definitely FHE will play a big role in this future of decentralised trustless computation!

2024-08-01 16:14:47

- reply

> AFAIK it's well understood that rollups actually do a poor job of actually scaling though they have undeniable utility advancements.
What ? ZK rollups using state diffs (as opposed to sending compressed tx data) scale extremely well! It's the opposite, the more traffic you have on them the more efficient they are.

2024-08-01 16:06:17

- reply

> Using Bitcoin as a DA will make tx onchain strictly more expensive than on Bitcoin today the moment any sort of scale usage shows up.
Yes but in this scenario you assume that most of the traffic will still happen on L1 directly ? Assuming most of the traffic move to L2s then it's not the case.
> All of the gadgets you refer to are underexplored and add new layers of complexity that I don't think are fully appreciate because they've never been tested in real world environment.
Fair enough.
> What we know of rollups is that they are permissioned, likely very expensive to operate and consolidate into few service providers that can capture network effect. (observations from ETH).
Yes this is the current state of affairs today, I wont deny it. Everything is about the credibility of the path to decentralisation and to fix those aspects.

2024-08-01 15:45:39

- reply

> Precisely, yes. It's just another blockchain. Blockchain decentralization doesn't manifest in and of itself and every attempt other than Bitcoin are looking like failure so I don't see why it would be different here.
With validity proofs it's trustless. You're only giving up censorship resistance (up to L2 consensus), but gaining: scale (like lightning) and functionality. In fact, the latter also gives more security because you can do DeFi and self-custodial applications.
> Too expensive
It's less expensive than Bitcoin today. Bitcoin stores all tx on chain. This will store state diffs in the worst case which is much cheaper.
> That's an option but I'm not sure how it would play out in practice. Overall it just seems overarchitectured. Another example is I have no reason to believe at the moment that fraud proof economic games are actually sustainable. They seem quite capital inefficient and I've read pretty serious concerns around the long term game theory.
Validium prevents escape hatches, but it's not related to fraud proofs. Unlike fraud proofs, validiums make it imposible for operators to steal funds.
There is also the option of self-DA like Adamantium (it needs users to be live, but IMO, it should still be strictly better than Lightning).

2024-08-01 14:33:45

- reply

So in this case you would need a way to prove that the computation was done correctly. A hash is not the correct way to think about it, since a hash is about integrity of data but not integrity of computation.
What you need to generate is a Zero Knowledge Proof, there are many different type of proofs (SNARKs, STARKs, and many variants in each family etc).
You have multiple approaches to prove a computation. either you build specific circuits / AIR for the computation you prove, or you are able to prove a higher level language, where you use a VM that is provable, and then you dont have to write custom circuits for each computation.
This is the approach i am proposing here. Basically you can write your computation in Cairo language, which is a language that enable you to build provable program.
So in your example the flow would like this:
- write a program in Cairo that performs the sum and return the result
- run the program with the Cairo VM to generate the execution trace (something needed to generate the proof)
- run a prover (like STWO) to generate the STARK proof
- then on the client side you verify the proof instead of re doing the computation yourself
Of course on small programs like this example it does not really make sense because you would just do a naive re execution and compare the result. But on complex programs it makes sense because the verification is exponentially faster and cheaper as the program complexity grows.

2024-08-01 13:02:01

- reply

Gotcha, i get your points.
> I just don't believe in decentralized sequencing.
What bother you the most about this is the need of having a consensus and hence economic security needs ? Or accessibility of running a sequencer ?
> Nor do I believe you can trust DA layers.
And you don't believe that Bitcoin could be used as DA layer ? And what about Validium ? You said that you are willing to concede trust where needed, wouldn't it be the same in the context of a Validium ? (assuming you can force exit the system at a reasonable cost)
> fragmentation is my biggest concern
Fragmentation of liquidity ? Fragmentation of UX (i.e interop) ?

2024-08-01 12:43:21

- reply

Thank you sir!
> DVMs and zero-knowledge computation seems like a match made in heaven.
100% man! The more I think about it the more obvious to me.
> I'm personally not a big fan of ZK as a scaling solution for Bitcoin.
Could you give a TL;DR on why ? I haven't seen you expand on the reasons why. You can point me to existing content where you expressed your sentiment on this topic if you prefer.
Let say it's possible to completely remove trust assumptions and have decentralised sequencers and provers, fully permissionless, with escape hatches etc. Even in this scenario you would not be fan ?
What are your concerns ? Security ? Garbage usage of Bitcoin ?

2024-08-01 12:35:04

Powering Verifiable Computation for the Nostr Revolution:
https://hackmd.io/@abdelhamid/nostr-dvm-verifiable-computation
#Nostr #FreedomOfSpeech #Integrity

2024-08-01 12:34:21

- reply

Sorry I dont get your question. Can you expand ?

2024-08-01 09:58:10

- reply

The why is simply: Don't trust, verify.
What I mean is that yes DVMs are super cool, but i think we should start thinking about a way to provide verifiable computation for sensitive services.

2024-08-01 08:31:22

Verifiable computation for Nostr Data Vending Machines.
Nostr DVMs are the future:
- free market
- censorship resistant
- standardised
What if we could bring ZKPs to make the computations of DVMs provable ?
Here you, with Askeladd :
- NIP-90 compliant.
- Uses STWO prover to generate Circle STARK proofs.
- In-browser proof verification using Web assembly STWO verifier.
For the user it's very simple:
- Submit the job via a web page signing a Nostr message (with any NIP-07 compatible extension)
- Get the result and verify the proof in the browser directly
https://m.primal.net/Jkvk.mp4
Try it yourself: https://askeladd.org

2024-07-31 11:31:39

Starting a new #Bitcoin exploration project: Raito - a Bitcoin ZK client written in Cairo.
https://github.com/keep-starknet-strange/raito
It aims to provide trustless validation of the Bitcoin blockchain through STARK proof verification.
Yes, it's similar to ZeroSync (for those who are familiar with this project) but in the new version of Cairo language.
Design goals:
- Usability: One-click install and run. WebAssembly compatibility for browser-based execution.
- Maintainability: Emphasis on simplicity and clean code structure.
- Performance: Optimized for speed and efficiency, leveraging STWO's next-generation prover.
It will work well in tandem with Shinigami (https://github.com/keep-starknet-strange/shinigami), the other recent exploration project we started.
https://m.primal.net/JkJS.jpg
Basically when you combine the two you have:
- Raito: Verification of Consensus Rules.
- Shinigami: Verification of Execution of Bitcoin Script programs.
Verifiable Computation is going to change the world.

2024-07-29 21:32:27

- reply

Done

2024-07-29 19:07:12

- reply

Have Fun Staying Censored ?

2024-07-29 19:03:45

Bonus side effect of building this POC: I was able to catch and report a bug in the Nostr Rust SDK. Shout ouf to the maintainers who fixed it few hours later.
I may be the one who implemented the first NIP-90 compatible DVM in Rust 😜
https://github.com/rust-nostr/nostr/issues/512
#note15yu…d7ws
https://m.primal.net/JiJK.png

2024-07-29 15:39:09

- reply

- client side proving
- ZK rollups that need to decentralize provers without a blockchain consensus
- offchain ZK use cases (could be generating and gossiping proofs for ZeroSync to improve IBD process on Bitcoin)

2024-07-29 14:08:11

ZK Proof Generation Data Vending Machine.
My POC is now NIP-90 compatible.
Check out demo video.
- Running Nostr relayer
- Running the Prover Agent DVM service provider
- Running the DVM customer, requesting the ZK proof generation
Customer gets the STARK proof as part of the payload of the DVM job result, verifies it, voila!
Nostr is amazing. Simple, elegant, powerful.
https://m.primal.net/Jhxl.mov
#note1hu6…r0k2

2024-07-29 08:32:31

Let's build a Bitcoin Script VM interpreter that enable to generate ZK proof of the integrity of a computation of a Bitcoin script program.
If you combine this to ZeroSync then you can prove both:
- Bitcoin block header consensus
- Execution of Bitcoin Script programs
Can be useful to improve IBD, reduce trust assumptions on bridges, build atomic swaps, etc
https://github.com/keep-starknet-strange/shinigami
https://m.primal.net/Jhmu.png

2024-07-24 16:36:49

When ZK proof generation Data Vending Machine ?
NIP-90 is very cool. I will try to incorporate it in my Global Proving Network using Nostr POC.
Imagine being able to request proof generation as easily as a translation. And you can use zap to pay the fees to the prover agent.https://m.primal.net/Jcth.png
https://github.com/AbdelStark/askeladd

2024-07-22 20:57:29

- reply

💪

2024-07-22 18:50:42

- reply

Yeah that’s a wonderful idea! Let’s work on it together?

2024-07-19 23:38:10

- reply

Yes indeed. I discovered NIP-90 thanks to some folks mentioning DVM. You are absolutely right.
Yes STARKs can be used completely offchain.

2024-07-19 23:37:01

- reply

No specific use case in mind for now but I feel that the demand for decentralized proving will constantly increase in the future.
AI might be a big vertical needing this.

2024-07-17 13:41:05

- reply

Oh my! that's huge and super exciting

2024-07-17 13:18:00

What about building a Censorship-resistant global proving network using Nostr ?
I built a small Proof of Concept using Nostr for the coordination layer and STWO for the generation of validity proofs.
Typical flow:
1. User submits a proving request to the network using a Nostr client.
2. A prover agent picks the request and generate a STARK proof using STWO prover.
3. The proof is published to the Nostr network.
4. The user can verify the proof using the STWO verifier agent.
The POC for now is only able to generate a Circle STARK proof for a Fibonacci computation, using STWO and a custom AIR.
Open questions:
- Fee mechanism (could leverage NIP-57 with Lightning Zaps).
- Spam protection (could be cool to use NIP-13 Proof of Work and try to reuse the grinding part of the STARK protocol,
Weikeng Chen
has started to draft idea on how to potentially do this).
- Standardisation and serialisation of proofs.
- Generalisation to arbitrary programs using Cairo.
- Batching & aggregation of proofs.
I am big fan of Nostr and it's potential. You can imagine a lof of different applications and use cases that can leverage the simplicity and censorship resistance of Nostr. I am pretty sure that ZK will play a big role in this, both for scaling of computation and also for privacy.
https://m.primal.net/JTyw.png
https://github.com/AbdelStark/askeladd

2024-06-26 16:51:32

- reply

I am

2024-06-21 08:05:44

- reply

I personally like primal.net more and more.
I have been disappointed by Damus so far.

2023-01-27 17:55:11

@npub1teawtzxh6y02cnp9jphxm2q8u6xxfx85nguwg6ftuksgjctvavvqnsgq5u Verifying My Public Key for telegram: "abdelhamidbakhta:1392886154"

2023-01-27 17:54:50

@npub1teawtzxh6y02cnp9jphxm2q8u6xxfx85nguwg6ftuksgjctvavvqnsgq5u Verifying My Public Key for telegram: "abdelhamidbakhta:1392886154"

2023-01-27 17:47:00

@npub1teawtzxh6y02cnp9jphxm2q8u6xxfx85nguwg6ftuksgjctvavvqnsgq5u Verifying My Public Key: "dimahledba"

2023-01-27 17:44:12

#[0] Verifying My Public Key: "dimahledba"

2023-01-27 17:40:24

#[0] Verifying My Public Key: "dimahledba"