GNU Taler est un système de paiement entièrement libre. Il semble être utilisable aussi bien avec des monnaies bancaires qu’avec des cryptomonnaies (la FAQ parle du bitcoin). Le projet est encore expérimental.
Je n’ai pas encore bien compris son fonctionnement, mais à l’avenir il pourrait être intéressant de l’interfacer avec Duniter (apparemment ça ressemble à un lightning network).
Peut etre ma reponse est trop tot… mais en section « 13.2 Anastasis Cryptography »:
« … The account private key is derived from the user’s identifier using a computationally expensive cryptographic hash function. Using an expensive hash algorithm is assumed to make it infeasible for a weak adversary to determine account keys by brute force (without knowing the user’s identifier). However, it is assumed that a strong adversary performing a targeted attack can compute the account key pair. »
est un « show-stopper » pour moi. La posession de toute matiere-de-clef-privee par sa proprieteur est importante.
-Spencer971
p.s. bien sure, ce n’est que mon avis personelle… je suis QUI d’assigner valeur pour qlqchose qu’un autre humain-libre valorise.
En revanche, J’aime l’dée d’avoir la capacite de faire un swap-sans-confiance avec n’mporte autre systemme qui partage les memes fonctionalités de verification (hash, verify-sig, delai-de-temps), comme (si je ne suis pas confondu?):
Alice veut echanger ses X montant de G1 pour Y montant de XYZ de Bob.
Alice creer et garde un secret pre-image comme « un secret avec haut entropy » qui donne un sha2 hash comme « a241976417b574fd520944aff0c174241c3aafee94c4214c9f1ee3801eba6893 ».
et Alice publies, sur son noeud duniter, un document de « Transaction » avec 2 conditions comme:
et apres Alice informera Bob de la transaction ou idealement, le porte-feuille G1 de Bob lui notifies qu’il y a un paiement bien confirmé de X G1 s’il connais le sha2 pre-image de « a241976417b574fd520944aff0c174241c3aafee94c4214c9f1ee3801eba6893 »
pour que Bob puisse publier, sur son noeud de XYZ, une transaction complimentaire avec 2 conditions comme:
et en suite (apres la 2eme transaction est bien confirmée sur XYZ)…
Alice peut depenser le tx-swap de Y XYZ a son propre porte-feuille utilisant le secret pre-image qu’elle a crée… et Bob peut inspecter cette transaction sur XYZ pour apprendre que le sha2 hash « a241976417b574fd520944aff0c174241c3aafee94c4214c9f1ee3801eba6893 » etait fait avec le pre-image « un secret avec haut entropy » qui lui donne la capacité de depenser le tx-swap de X G1.
sinon… Alice recupera ses X G1 apres demain et Bob recupera ses Y XYZ demain.
@Spencer it’s very nice of you to try to post in French but personally I don’t understand what you’re writing 
Please can you post in English? I think you will be understood much better 
Thanks
In tuxmain’s original post regarding integration with GNU Taler, (a system which doesnt interest me), it certainly piqued my interest in having the tools available in G1 (I suspect they do exist… however friendly UI/UX may not, yet) to be able to atomic-swap G1 for any other crypto-currency which shares transaction-verification primitives; then I carried on doing my best to explain my understanding of how this might be done (if i understand the well-known construction) in a beautiful language that I regularly destroy, without intent. 
Suppose Alice wants to exchange X amount of G1 for Y amount of XYZ from Bob; Bob and Alice both agree to the terms and proceed to execute the swap on two separate blockchains in a trustless manner.
Alice creates and securely guards a secret like « a secret with high entropy » as sha256 input to create a shared hash-output like ‹ ffbf85d522ebf12fc5736ecfde2ed1c335693084b17aad2e8b9449aff87fe4ea ›
Alice publishes a non-standard transaction into the G1 network paying X amount of G1 to an output condition like
(
(SIG(Bob’sPubKey) && XHX(‹ ffbf85d522ebf12fc5736ecfde2ed1c335693084b17aad2e8b9449aff87fe4ea ›))
||
(SIG(Alice’sPubKey) && CSV(Now+48h))
)
…so Bob cannot do anything yet because he doesn’t have the sha256 input which outputs the XHX argument of his condition… however in 48h, Alice WILL be able to spend this transaction back to her G1 pubkey.
Alice informs Bob of the above G1 swap transaction, or better yet, Bob’s G1 wallet notifies him of a confirmed payment IF he can solve the XHX puzzle (and do so within 48hours otherwise it may no longer be unspent).
Bob confirms that the G1 swap transaction exists, and copies the same XHX puzzle so that he can create a complimentary transaction on the XYZ chain challenging Alice to reveal her secret. Bob then publishes his transaction into the XYZ network paying Y amount of XYZ with a similar condition (assuming that similar pseudo-code in XYZ does what happens in G1), it might look like:
(
(SIG(Alice’sXYZAccount) && XHX(‹ ffbf85d522ebf12fc5736ecfde2ed1c335693084b17aad2e8b9449aff87fe4ea ›))
||
(SIG(Bob’sXYZAccount) && CSV(Now+24h))
)
…unlike the first transaction on G1… Alice can immediately spend the XYZ transaction to her XYZ acount, because she can solve the sha256 puzzle… after all, she created the original secret… or, if through bad-faith she decides NOT to spend it immediately… then Bob can recuperate his XYZ tomorrow.
As soon as Alice spends the XYZ transaction, she reveals her solution to the XHX puzzle and Bob can learn this from the public XYZ blockchain, allowing him to use the same solution to spend the original G1 transaction to his G1 pubkey (before 48h), completing the trustless swap.
If the protocol fails to complete after Alice’s first step… she’s lost cash-flow for just 2 days. If the protocol fails to complete after Bob’s first step… same result for Alice and Bob will have lost cash-flow for just 1 day… but each can be made whole as long as they individually follow the protocol (which they both are capable to do) and without requiring trust between Alice and Bob.
Im sure there are much better english explanations of this online… I was just trying to give it a shot in french.
Thanks for reading this far.
Spencer971
@Spencer yes the Duniter protocol was voluntarily designed to allow swap exchanges (and many other things), this article should interest you: https://duniter.org/en/transactions-0-2-overview/
So Duniter already allows what you want to do. Anyone can develop swap exchange software by exploiting the Duniter BMA API
Thank you Elois for your links, especially the duniter BMA API which replaces my scribbles on floating papers always hard to find.
I sure hope that my comments yesterday morning did NOT supercede tuxmain’s initial post on GNU Taler which remain, at this point, un-adressed.
-Spencer971
I already have plan to enable it in Sakia client.
For now, you can already secure big transactions with the mode “refund after two weeks” in Sakia.
Like @Elois have said, it is already supported by Duniter, and “only” need to be supported by Duniter clients.