Hi everyone, I’m a long-time lurker and experienced developer hoping to get more involved with GRIN.
@tromp’s CoinSwap Proposal appears the most promising attempt to solve transaction linkability in MW. Sadly it seems GRIN is temporarily short on developers capable of implementing such a complex system. Luckily I’m in a position to dedicate time to this project throughout the remainder of the year.
Project Plan
This is a large project, so in order to facilitate incremental incremental evaluation and funding payouts, I’ll be breaking the project into smaller deliverables.
Milestone 1: Server & APIs
Define & document all public APIs
Using JSON-RPC
Create server project
There are GRIN libraries in rust, c++ and golang, so I will evaluate each and then decide on language to use
Implement APIs
APIs will return basic success responses when requests are valid and errors for invalid requests
Test framework will be written to spin up a local server and query the APIs
Milestone 2: Single Server (Trusted) CoinSwap
Support a single server that users can submit self-spends to which will be aggregated daily with all other submitted self-spends. This includes at minimum:
Validation of all incoming data against a live node
Daily aggregation and broadcasting of the finalized transaction
Basic reorg protection
Automated e2e testing
Milestone 3: Multi-Server (Trustless) CoinSwap
Support a fixed set of CoinSwap servers for trustless swapping.
Data provisioning using encrypted bundles
Inter-server communication
e2e tests that spin up local servers 1-n, demonstrating the workflow against a mock GRIN node
Future Plans
Add better protection against spam, reorgs and other attacks
Add wallet support in grin-wallet or grin++
Project Timeline
Estimating the time for a project of this size can be challenging, but I’ve chosen milestones that I believe can be implemented in about two months’ time. Thus, this project is expected to be delivered in 6 months.
Funding Request
I am requesting to be funded £50,000 for the total completion of the project, with regular payouts. I have not yet established a reputation with the GRIN community, so I propose weighting the later milestones greater than the earlier ones in order to prove myself and to incentivize completion of the project. My request is to be funded for each milestone upon completion and acceptance by the funding council in the following amounts:
£10,000 for Milestone 1
£15,000 for Milestone 2
£25,000 for Milestone 3
I am of course open to suggestions for changes to any of the above details. Regular updates will be provided on the forum.
Can you elaborate on what you mean with Basic reorg protection? My idea is that full reorg protection for X blocks would mean that coinswap server 1 (the one getting the data from users) would need to hold all the coinswap data he got in that time (and a little back to recreate the first coinswap tx that occurred after the reorg) + would also need to keep all of the transactions that he saw in his mempool in the last X blocks (to handle cases such as Utxo1 is sent to Coinswap to get Utxo2 and then make Tx1 which spends Utxo2 to get Utxo3 which is then sent to coinswap to get Utxo4 → to recreate all of this you need to remember Tx1).
What kind of communication would the servers use? (I don’t think we’ve talked about this before, am just curious)
Does Validation of all incoming data against a live node mean “validate that the received input is in the utxo set”?
Awesome to see this request!
May I ask if you have any open source projects you could share with us so we can get the feel of your experience?
Regarding reorg protection, I agree with @vegycslol . It seems binary in the sense that the mwixnet can either handle a reorg of N blocks or it can’t - where we define “handle” as minimizing transaction graph collapse. Partial handling of this is still bad because graphs that should be there are no longer on the chain. There are different ways to handle this.
We could define an input as valid only if it has been on the chain for at least 6 hours. This is similar to having a 6 hour reorg protection because a reorg that is less than 6 hours deep can’t affect such coinswap transaction - everyone that saw this transaction can replay it. That’s not that resilient unfortunately because if someone spends an input before the coinswap transaction is replayed, it’s a disaster because then the coinswap transaction is no longer valid and the whole transaction graph forming from it disappears. There are of course better ways to solve this which includes coinswap nodes replaying the coinswap computations and keeping the mempool history around like @vegycslol mentioned above. Let this not discourage you, I’ll be more than happy to help think through these scenarios - whichever path we decide to go first.
That’s what I meant by basic reorg protection. It will support reorgs of the last X blocks and rebuild the transaction if needed. I called that “basic” reorg protection because there could be more complex attacks that I’m not aware of and don’t intend on guarding against in the first release of CoinSwap.
The server that wallets communicate with would use JSON-RPC over http, probably using tor.
Yes, along with rangeproof validation, signature validation, excess sums, and whatever else is needed to ensure the transactions are valid.
I don’t have anything I’m able to share right now, which is why I am only asking for payment after approval by the funding council. I’m not expecting anyone to trust me.
Open sourced the project since day 0, maybe we could create a repository on grincc github account.
Milestone 1 includes the definition and documentation of all public APIs, I would like to suggest to do only that in a Milestone 0, including a architecture design before starting. Why? to have a better idea of how a deliverable will looks like.
I found 6 months too optimistic.
A CoinSwap Implementation is a ton of work, and I think we all agree on having this done; Now, I would like to see a more detailed planning; perhaps, maybe it is better for @scilio to have an atomic plan and evaluate if you are ok with working on payments based on progress made. I think this is a better fit when it is hard to estimate due to the big amount of work.
I have no authority to say how much anyone’s time costs, I’m just trying to find a more fair way to bring @scilio aboard.
That was my intent with breaking up the task into 3 milestones. I would finish milestone 1, submit the code for council approval. Once approved, I would then be compensated for it (£10,000) and begin working on the next milestone. Can you clarify what you think I should change about that plan? I could possibly split milestones 2 and 3 up into smaller sections, though I do worry that the additional overhead will just result in more delays waiting for review, votes and payment.
In that case, I would suggest to combine the first two milestones, and receive the first payment after the second milestone is complete. This is because the M1 deliverable (an API that just returns success while only validating input) is not necessarily worth much to the Grin project.
I agree with this .
Personally, I would even prefer to make this funding request a single bounty, in which case I would most certainly support this funding request.
What do you think @scilio would that be workable for you or do you have a strong preference for individual milestones? If so, I agree with @Chronos that it would be best to merge the first two milestones.
I understand your position, but I require more incremental payments. Working for 4 or more months before receiving any payment would put me in a bad spot financially.
I think the advantage of more of smaller milestones instead of fewer larger milestones is that there is more atomic work that could potentially be continued by someone else, especially if code is reviewed and properly documented. I like @davidtavarez suggestion a lot.
I agree with this. There’s no reason to make those that take on funding requests wait for payment for many months just because the project is a bit bigger. This would probably shrink the pool of possible contributors - they also need to pay the monthly bills. The “one time payment” may be suitable for bounties, but this isn’t one. If we agree on the milestones, then nothing is lost if we don’t reach the last milestone, we’re still closer to the goal. It’s also better to get more smaller PR reviews to get the feedback sooner rather than later.
You don’t have a github profile, we don’t know you, we don’t know who you are, we don’t know nothing about you, why should we trust you? there is not a single reason to do that, and you’re aware of that. I respect your choice to remain unknown, and I support it. I don’t know if you will be working alone on this or how many hours you are able to invest on it, you or your team in case you’re requesting funds in behalf of someone else. We’re breaking our own rules by funding unknowns. That was not supposed to be like that, but it seems that the Community likes to selectively ignore rules, but that’s another topic.
Now, since we don’t know nothing about you, and even if we do know, we’re not sure that you will deliver, but since this is a need that the Community seems to agree on, I think we are willing to take the risk. How can we mitigate the consequences of you disappearing in the middle to the process? simple: we need to make sure anyone could finish your work if you disappear.
I won’t put a price on your time, ask for £60,000 if you want, split it however you want, I don’t care, but if we’re going to take the risk, we need to make sure anyone could finish your work if you vanish, first, and second, if you do your job we must compensate you properly in a fair way for both sides.
Before paying, we validate the chunk, ask for changes etc. until we’re ok with it
When we pay, we know exactly what we’re paying for. The setup @scilio suggested doesn’t require trust. The only difference is if we are paying for progress in between or for a complete delivery.
We also discussed this in the last Community Council General meeting, but there is also the option for you @scilio to reveal you identity or share you credentials with one or a a few community members who then can vouch for you capabilities. I could be such a contact person for you.
Otherwise working with milestones is acceptable to me, but indeed, each milestone needs to be scrutinized very well since we do no know anything about you. I think @oryhp and @davidtavarez suggestions are spot on, since receiving feedback will also help in the process. I still I would prefer to merge milestone 1 and 2 if that works for you.
This is a different situation since previous funding requests were for payment in advance iirc. I see no real downside in evaluating the work done after each milestone and paying when it’s done properly as long as the milestones form a complete part so that if he doesn’t manage to do all of them someone can continue from where he has finished. @scilio are you planning on completing all or do you think you probably won’t be able to do them all?
Look at the PIBD work, we ended up without neither an implementation nor a RFC nor even a work-in-progress Pull Request. In advance or not, for me that is irrelevant if we can’t find a way to get this thing, or anything else, done. It is not hard to understand. Do we want to be in the same position again where we are left with nothing? I think we don’t.
I don’t want to be an obstacle here, I want to find a win-win situation for @scilio and for the Community.
I think Gene had a similar funding model. Scilio mentioned in the beginning
The sooner he/she starts, the more likely that all of the milestones are finished. I suggest we agree on something asap so they can start working and show the first milestone.
This funding request will create the coinswap service, but to use it, the wallets will need an upgrade to create 1-1 self spends and possibly label these outputs. This is a milestone that is not mentioned here so we can start with the assumption that not all milestones will be completed to have everyone using the coinswap service. Someone will have to do the wallet part in the end to finish it off.
The model where people don’t get paid for months doesn’t work for projects that require months of full time work for many reasons:
people need money
life can take unexpected turns and make someone unable to work on the project (something happens to you or your loved ones)
The method where someone gets paid after 5 months makes them take these risks. No person should have to do this, nor do I think we should encourage them to. If something happens and you can no longer work on the project, that’s fine. These things are more important than PIBD or whatever else. Shit happens, and someone will have to continue the implementation. We can only hope we don’t get to such situation where things are stale, but I wouldn’t want us to try to control this at such expenses.
Yes, but not only need, people want money and that is totally fine, and like I said:
Exactly, that’s my point and I want anyone to be able to continue the implementation if something bad happens. For the PIBD work we spent donations on that, today we don’t have neither the funds or a single RFC, no one will be able to finish that work. I’m not sorry for not wanting to be in the position of not being able to complete the job.
I think this is something else, but we don’t want to encourage one-time contributors either. It is completely unhealthy for Grin to rely on sporadic contributions, but if we’re going to take that path, which I’m against of, because life is a joke, we must make sure the code can be maintained and upgraded, not just by the authors but by anyone at any moment in the Community.
Grin is a decentralized open-source project, what we do want is to compensate passionate contributors. I don’t mind if someone sees an one-time opportunity to make money contributing to Grin, that is totally fine. Now, donations spent on unfinished work, donations that are not going into people’s pockets who truly care about Grin. If we’re going to take the risk of having unfinished work, at least, we need to make sure that those donations are not wasted.
Let’s put it like this: let’s say we allocate £50k to this project, or £60k or £80k (again, I don’t care), and for whatever reason (legit or not it doesn’t matter) @scilio has to stop working on this at the 3rd month, what I think we want is to compensate him/her for the work done, and at the same time, we can leave the offer open for anyone to finish the work with the budget left.
.