Pinging nostr:npub148jz5r9xujcjpqygk69yl4jqwjqmzgrqly26plktfjy8g4t7xaysj9xhgp .. is there any kind of paper or spec I could refer to to better understand Ark? I'm reading arkdev.info/docs but it's too general/broad for me.
Discussion
Ruben's old gist was extremely helpful at least for the basic mechanism:
https://gist.github.com/RubenSomsen/a394beb1dea9e47e981216768e007454
Now I'm wondering, why would you ever use connectors when you can just use the standard atomicity tricks ( adaptors or hashlocks). Naively it seems like a worse choice, am I missing something?
The UTXO you are trying to swap for doesn't yet exist.
How would that work?
I think I got it, though it took a while ... for the relationship between forfeit transaction F and round transaction R, you want a *unilateral* constraint. That is, the server can get F only if R; and Alice (the participant from previous round) doesn't need to play a role in that round creation process (well apart from actually providing an F of course).
To have it work the "atomic swap" way it would have to be the counterparty (Alice) that was broadcasting the R, unlocking a secret for F. But that's not how this works, the action is all controlled by the Server.
Especially because there is more than one Alice :)
I have requested tiero to help with more documentation. Although I think you will find some difference between specs and implementation.
I'm not sure who the intended audience is; for a casual reader who'll never write code, it's probably way too detailed. For an engineer who needs to understand mechanisms, it's too abstract. We need scripts (to be fair these are given), transactions, utxos and signatures, and we need the sequence of steps, between the parties. So the 'Payment diagram' on 'payments' is good, e.g.
It's always great to have abstract descriptions to gain insight, but for a new and complex system that has to come after writing the *exact* mechanism. Imo.
Thanks for the honest feedback. We're definitely working towards making the documentation more developer friendly.
there is no spec
The Developer Hub is indeed for… developers, not protocol researchers. I hear you regarding having a “formalized” paper, but is intentional to NOT focus on that at this stage. We are still iterating and discovering new emergent properties as we speak. That being said we may pickup this work pretty soon.
