Request for funding @antioch, Feb-Mar 2021

Governance
1

[This is all with the understanding that I am walking straight into the middle of various active conversations around the funding of contribution to the grin project. I am only speaking for myself here.]

January was an unpaid “sabbatical” and I was not actively involved or contributing in any meaningful way. I was originally going to request a shortened two month period of funding for Feb/Mar to sync back up with the quarterly schedule. Given the somewhat heated and ongoing discussion around deliverable based funding vs. time based funding I am rethinking this. I am requesting funding based on successful delivery of a couple of new features. I think there is the opportunity for alignment here with some uncertainty around how much time I can dedicate to grin over the next couple of months. I would like to experiemt with this if people are in agreement.

Short summary of the features I am considering (across wallet and node) -

We support enabled/disabled features and p2p protocol versioning and I think it is entirely feasible to introduce opt-in support for serving up historical blocks via the existing block p2p message. We sync recent blocks during IBD, this can be extended to “in the background” sync all historical blocks from peers that advertize support for this. It may not be fast and it may not be a perfect solution initially, but I think there is value there in aiming to support this feature.

The two wallet related features are I think good candidates for deliverable based funding. They are relatively self-contained and hopefully small enough chunks of work to see through to completion in a constrained amount of time.

My intention would be to continue to work on improving the codebase, general maintenance, cleanup, testing, etc. in addition to delivering the above feature(s). I would preferably like to account for this in the funding request, but not necessarily call these activities out as separately funded items. I think we need to discuss approaches to this.

All of this leads to the queston of assigning “value” to these deliverables. In the interest of keeping everything as simple as possible and in an attempt to avoid getting into endless conversations around relative values I’d like to propose the following -

  • late locking pre-generation of transactions: 5k EUR
  • late locking coin control: 5k EUR
  • full archival node support: 10k EUR

The intent here would be for payment on successful completion of a given task with the understanding that having “claimed” these tasks in advance (for the specified period of time) that these are not “open bounties” available for others to claim.

And to be clear, “delivery” here is not just writing the code and would cover testing, evaluation, revision/rework, documentation, rollout etc. Presumably we would want to define success criteria reasonably explicitly as part of this.

I believe these numbers provide a starting point for the discussion. This would take into consideration the various ongoing tasks and activities that I would continue to be involved in and contribute to. The expectation would be that this is not an exhaustive list of what I would be working on over the next couple of months.

I believe the next governance meeting is on Tuesday. I’d like to set some time aside in that meeting to at least start a discussion on this. I believe we ask for at least 7 days notice before making funding decisions, so not expecting a final decision on Tuesday.

Thoughts? Comments?

24 Likes
2

I fully support this request.

You should, those activities are time consuming. Maybe you will need to invest time on others unrelated things while you’re working on delivering these features.

I don’t know the exact amount of effort require, but if you let me… have you considered that maybe from February to March is too optimistic? We will be already on February after this request is discussed.

2 Likes
3

We don’t always agree (in fact, we almost never do), but you’ve proven yourself to be a passionate and reliable dev, so I’m glad to see you’re back from your well-deserved sabbatical.

I really like the idea of project-based funding, but I also think it makes sense to still keep a full-time developer around. If a critical issue comes up that could take weeks of work, do we have to hand it to someone else because you’re busy with your funded tasks? I think that would be a mistake. You’ve always been the catch-all that would cover many of the various tasks that come from supporting a project of this scope, and I think it’s beneficial if you are willing to continue in that capacity.

Either way, whether we do project-based or full-time, you have my support.

7 Likes
4

I totally agree with @david, @antioch is doing some great things for grin. You got my support also!

5

I fully support this detailed request with specified and communicated deliverable.

And as you perhaps know, I am wanting to see the late-lock improved.

1 Like
6

In support!
I like to see both @antioch and @jaspervdm work on Grin. I think in the end a fixed employment with clear deliverables and deathlines/time-estimates (this is the first part to improve) should work for regular devs. Bounties based compensation might be more suitable for anyone who wants to work on any specific functionality and onlhy work part-time.
However, I do not have a strong opinnion on these matters, the exact format of payments and deliverbales is best discussed in the next Grin meeting. Most important is to keep going full steam ahead with Grin since the train is going in the right direction.

7

I have been waiting for this option for a long time. Having a full history is a must for research and blockchain analyses purposes.

8

why blockchain analyses purposes? to help chainanlyses tool? isnt bad for privacy?

9

Blockchain analysis is always possible, so best to actively research it ourselves so we can improve.
If I can run a full node with history, I can convert it to a graph database and scan for change and cut troughs (not sure if this can be seen, but I definitely would like to investigate).
The knowledge we can extract ourselves can be used to improve the privacy for Grin users by for example using coin-swapping, coin-joins, randomizing the payment threshold from mining (the regular interval of these transactions might make them identifiable as such) etc. The more we know about what can be derived from on-chain data, the more we can work towards true privacy.

7 Likes
10

i see.thnx. i hope it is not bended in bad way.

11

Perhaps. In the end it don’t think it is a bad idea to introduce a hybride function between fully private and fully supporting transactions, but all should be user / exchange options. This way exchanges can chose because of regularities to only support the transparent grin and not the privacy grin.

In the end the same coins, but with different goals.

12

no privacy shohuld be default,not optional.

1 Like
13

Why though? At this point, the user is already KYC’d if the exchange is regulated and there is no need to make the transaction transparent. For the exchange it is only important to be able to prove that it sent coins to the user, which can be done with payment proofs instead of transparent transactions. If there is a dispute around deposits, the user needs to provide a payment proof.

1 Like