Funding request are discussed and decided on in the next governance meeting after the request has been up for a week.
3 Likes
relevant rust btc/grin atomic swap
mw-btc-swap (github.com) 5
@jabfalter
Thanks for posting this @gringineer, I wasn’t aware of @jabfalter’s work.
@jabfalter nice work on the atomic swap tool. It looks like you’re using adaptor signatures, too.
What state would you say your tool is in? Do you have a working PoC swap on testnets already? I would hate to duplicate any more work, and waste people’s time and money if Grin-Bitcoin atomic swaps using adaptor signatures is already implemented.
I see that you use a function grin_core::ext_witness for adapting signatures to reveal the witness, were you planning to make a PR upstream? AFAICT, this function doesn’t exist on your fork of the grin repo, nor on the main repo. Is it local only?
Also, I would be very interested to read your master’s thesis, is it online anywhere?
2 Likes
Hi @gene
First of all thanks @gringineer for mentioning my project. 
I am currently working on my master’s thesis in which I am formalizing Bitcoin Mimblewimble atomic swaps and proving security of the two-party adaptor signature used during the swap, as well as proving security of the different kinds of Mimblewimble transactions used during the swap. As part of the thesis, I implemented a POC in Rust jafalter (Jakob Abfalter) · GitHub .
The implementation is already working on the testnets, it is using fixed witness adaptor signatures on the grin side. (which are aumayrs adaptor signatures, but adjusted to the two-party signature protocol used in mimblewimble)
Some parts of the implementation (for instance the MP Bulletproof computation) were taken from Jaspers GitHub - vault713/grinswap: Cross-chain Atomic Swaps in Grin that was done by him some time ago.
On Bitcoin side I am using a CHECKMULTISIG with CHECKTIMELOCK_VERIFY P2SH script to allow refunding the funds if the swap fail after a timeout.
In my repo I am using my own forked version of grin-wallet, however the changes I did, I also posted as PRs to the repo, one of them is already merged, the second one will probably be soon as well.
Other then that I don’t use anything special. (I also have a module inside the repo called grin_core which might be what you have seen, but it has nothing to do with the actual grin core repository, I admit that was some bad naming from my side )
Notice that this was my first ever Rust project, so I am not an expert in this language, also some of the code is not suitable for production, for instance, I am storing private keys etc. simply in an unencrypted file, also the inputs used on bitcoin as well as on grin side have to be first imported before the swap can start.
Communication between the two parties currently happens via TCP Socket, one also needs to have access to a running bitcoin core and grin node to send JRPC requests via HTTP. I have provided some docker-compose configuration such that it can be tested rather easily.
My thesis document is almost finished, I will probably be able to finalize it in April, if you want I can send you the current version.
Anyway, I think it would be really cool if you build a production-grade version of the Atomic Swap. I believe you can reuse large parts of my implementation and if you build the protocol as it is specified in my thesis you can point to my formalization and security proofs.
If you want to receive my thesis document or have any more questions about my code please reach out to me via jakobabfalter@gmail DOT com
6 Likes
In my repo I am using my own forked version of grin-wallet, however the changes I did, I also posted as PRs to the repo, one of them is already merged, the second one will probably be soon as well.
Other then that I don’t use anything special. (I also have a module inside the repo called grin_core which might be what you have seen, but it has nothing to do with the actual grin core repository, I admit that was some bad naming from my side
Ok, I must have been looking in the wrong places, thanks for clarifying. No worries about the naming. For a first Rust project, your work is really impressive.
My thesis document is almost finished, I will probably be able to finalize it in April, if you want I can send you the current version.
Awesome, good luck on it! I wasn’t sure if you were already done is why I asked. I can wait to read the finished product 
Anyway, I think it would be really cool if you build a production-grade version of the Atomic Swap. I believe you can reuse large parts of my implementation and if you build the protocol as it is specified in my thesis you can point to my formalization and security proofs.
Definitely, as I progress with the project I was planning to also look at @jaspervdm’s work more closely, as well. (Have done a basic review, but nothing in-depth). Having more work as a reference would be great.
Our approaches and goals are different, but there is definitely enough overlap for the projects to be beneficial to each other.
Thanks for choosing to do academic research on Grin 
5 Likes
Added to the agenda: Agenda: Governance Mar 30 2021 · Issue #410 · mimblewimble/grin-pm · GitHub
4 Likes
I’m not sure how to edit the original post, but have a small update on the zk-PoK of exponent used for partial signatures.
In Aumayr et al. they describe using a Fischlin transformation style proof to prove knowledge of exponent used in the partial signature public key:
y in Zp ^ Y in G ^ g in G ^ Y = y*g
A separate proof (not necessarily needing Fischlin proof with an extractor), is needed for proving knowledge of an additional exponent and relationship:
k in Zp ^ K~ in G ^ g in G ^ K~ = k*g ^ Y in G ^ K in G ^ K = k*Y
In the Bulletproofs paper by Bünz et al. there is a section dedicated to proofs of generalized arithmetic circuits. This section seems to directly apply for both of the above proofs.
The second proof might be achieved with a more simple Schnorr-style proof using the Fiat-Shamir heuristic to make it non-interactive. However, the first proof explicitly cannot use Schnorr proofs due to the need for what Fischlin calls an “online extractor.” Bulletproofs seem to fulfill the need, though they also use the Fiat-Shamir heuristic.
Do more experienced cryptographers think this is a good line of research to pursue? Without having implemented yet, my impression is that Bulletproofs would be more efficient than Fischlin. Since Bulletproofs are similar in structure, they seem to carry similar security properties. Bulletproofs also solve for communication inefficiency of sending t hash queries + responses from the prover to the verifier.
Would one of the more experienced cryptographers be interested in working on a proof construction with me (even if it is just providing guidance)?
Will likely begin by implementing Fischlin proofs anyway, since I will need them for performance benchmark comparison. The theoretical work is also already there, so the work will go quicker. However, I think for future implementation, a Bulletproof construction will be much more efficient.
Request for continued funding for June 2021
Over the past couple weeks, a couple road blocks have come up in the atomic swap implementation. I made some incorrect assumptions about parts of Succinct Atomic Swaps I could replace with current Grin documentation atomic swaps, and didn’t realise the need for mutlitparty outputs.
Multiparty outputs are similar to multisignatures in other blockchains, where multiple parties control UTXO(s). For atomic swaps, these will be equivalent to 2-of-2 multisignatures over the output(s) produced by Grin Fund, and used by Grin Success, Grin Revoke, Grin Refund, and Grin Timeout transactions.
Originally, I thought Grin’s mutlisignature kernels were sufficient for a secure protocol, but multiparty outputs are needed to ensure shared control of outputs in both the Grin docs atomic swaps and SAS.
To implement multiparty outputs, multiparty range proofs (bulletproofs) need to be exposed to the rust-secp256k1-zkp library. Thankfully, the implementation is already present in the C secp256k1-zkp used by Grin. The rest of the implementation will consist of adding CLI/RPC APIs to allow grin-wallet users to construct an aggregate commitment and rangeproof over an output.
The Grin Refund and Grin Timeout transactions also need to be added, along with verification of the correct ouputs being used (i.e. Grin Success + Grin Revoke spend the output from Grin Fund, and Grin Refund + Grin Timeout spend the output from Grin Revoke).
Hopefully, I should be able to get a MVP implementation done by the end of June, and have something ready for the community to review.
I’m open to any questions and/or concerns the community has, so please feel free.
I am requesting continued funding for June 2021 at the same rate of 10k euro in Bitcoin (using 60-day rolling average).
Thank you for all the support the community has shown for my work so far, I look foward to contributing to the Grin ecosystem.
PRs of current work:
11 Likes
I’m glad to see progress on Atomic Swaps, I think this is something that a lot of people are asking for a long time. The work done and the commitment to delivery Atomic Swaps is undeniable.
I do remember that the funding request was discussed and approved during the past March 30th meeting, but the request changed a bit during the meeting, would you mind to clarify how was approved, please? it was approved as 10k monthly month by month?
Thanks.
8 Likes
The original request estimated 3-4 months for completion, which is looking more like 3 months now (by end of June). Time estimates are hard, and I’m trying to adjust expectations the deeper I get into implementation.
We agreed to work on month-to-month funding approval and payouts. Partly due to me being new to the community, partly due to the uncertainty of the timeline. The next month of funding is considered for approval at the beginning of the month, payout approval/denial comes at the end of the month.
3 Likes
After a conversation with @joltz. I am posting to request a payout for May and June of 2021.
Logs approving May and June funding:
keybase://chat/grincoin#general/34895
2021-06-08 joltz: Does anyone have any opposition or concern related to Gene's request that they'd like to share here?
keybase://chat/grincoin#general/34905
2021-06-08 dburkett: It's good to have @geneferneau around. I've been reading his updates, but haven't been following the RFCs & code as closely as @tromp and @phyro. If they are happy with his progress, then I am on board with continuing his funding :+1:
keybase://chat/grincoin#general/34919
2021-06-08 tromp: i'm ok with continued funding but do want to see more work on the RFC that are still lacking in detail
keybase://chat/grincoin#general/34915
2021-06-08 joltz: Ok it sounds like we will complete Gene's payment for May and continue funding for June :+1:
I never received funding for May or June, the only payout I have received was for April.
We were supposed to have a meeting at the beginning of July to discuss my funding for that month. No main governance meeting happened, and I can only find logs for community council meetings after the June meeting.
I still continued to work into July, without guarantee/expectation of pay Grin-Bitcoin Adaptor Signature Atomic Swap update thread - #36 by gene.
Over the few months working on atomic swaps, I did my best to go above and beyond for Grin. Please pay me for the work I have completed, and the Grin council agreed to fund.
10 Likes
Definitely! I thought this was solved.
@stakerV would you mind to add this to today’s meeting? We need to find a resolution to this ASAP.
2 Likes
May to October. it is almost 5 months.
I agree payment is overdue.
Regarding the deliverables, I was under the impression that funding was for an implementation of Succinct Atomic Swap, with the distinct advantage of needing only 1 tx on the bitcoin side. You abandoned that approach and went with the inferior non-succinct atomic swap.
I didn’t have time to review the new RFC until recently, but found its protocol description rather unclear. Could you address my comment on Atomic Swaps by GeneFerneau · Pull Request #83 · mimblewimble/grin-rfcs · GitHub ?
3 Likes
Ugh, it’s a shame you didn’t mention this earlier! I guarantee you this was missed and was not forgotten on purpose with the hopes you forget, leave it undone or something similar.
It’s a bit unfortunate that right now we don’t have enough manpower to properly review your contribution. I hope you stick around and perhaps do some work on the wallet if you find any improvements and have the motivation to do it.
3 Likes
Confirming receipt of payment, thank you very much for handling this so quickly once I brought it to attention.
Admittedly, it got lost for me as well, and I could have reached out sooner.
All is well now.
I saw @scilio is working on CoinSwaps for Grin. I’m currently focusing on CoinSwaps for Bitcoin. Would be happy to help how/if/when I can.
7 Likes
I can go over your comments, doing a partial rewrite to clarify the issues you brought up.
I really need to re-review the Succinct Atomic Swap protocol again. The fact that one failure path leaves one party with the traded funds, and the other funds burned doesn’t sit right with me. Maybe there are things about the game theory I’m not taking into account.
Either way, I need to take a deeper read of the spec.
6 Likes
I have that exact worry about your form of atomic swap, while I convinced myself that S.A.S. is safe as long as parties don’t get close to the time-out.
Likewise I need a closer look at your protocol, but the current write-up makes that hard, as it doesn’t show in what order txs are constructed, pre-signed, and broadcast.
3 Likes
You have yet to provide a clear and correct description of the protocol steps, which is crucial for reviewing your work…
2 Likes