I proposed to put internship offer to hire interns from university and schools. Some have very good blockchain departments and i am sure some students there would have a very good experience doing a project for grin and making an impact on a codebase that has very good reputation and honest history
When Grin LinkedIn : )
very good idea…many brlliant minds who knows…
Yeast took a much deserved vacation after working hard without one for some time. Antioch might want a break from the node. The consensus changes that are necessary (and the wish list changes) might take some time to implement and implement well (both efficiently, correctly and securely). Either way, just an idea, whatever is chosen works for me but I feel like delaying hf5 and optimizing things might be better than having the unannounced hf6 come not too long after
I don’t want to seem angry or bad, if you need a break, take a break for half a year, I don’t think anyone will mind.
But I want you to prioritize the development of a wallet on windows and mac os. official wallet on QT or flutter-it supports any operating system plus mobile devices.
I’m trying to explain to you why an unofficial wallet is bad but you’re not listening.
Wallets that people have developed they are only temporary, when they deal with your technology, find investors, they will make their fork and leave and you will be left with nothing without an official wallet.
People will not use an unofficial wallet that is not updated, and you will not update it because you do not know how it is written.
You should understand that the official wallet must be very important.
“I don’t want to seem angry or bad, if you need a break, take a break for half a year, I don’t think anyone will mind.”
I don’t think you can say that for Yeastplume. It seems he never took a break yet. Let breathe. Not everyone is surhuman and it should not be expected. Holidays are healthy. Otherwise I would also love an official wallet, but with current resources it seems impossible. An official wallet is relevant if a lot of work is involved to keep it updated and beautiful. Grin++ has reached a very good level. Otherwise we could think of recruiting people. The funding will expire anyways and our only chance to get further funding when it will be expired is probably to have quite more momentum than we have currently. So we will probably need to think on how we can make Grin more popular. This could start with a usable Atomic Swap, that everyone will be happy to use to wash their Bitcoins into Grin. This could be with lightning fast sync with PIBD (Parallel sync). This could be with anything that would make this community more vibrant and hopeful of a good future despite the challenges we face. Twitter, media, dialog with exchange to propose help in case they need. In brief we have a clock above our heads, and I hope we will have more funding or that we will be ready to have a sustainable coin when fund dries out
The ideas I proposed all stem from the idea of using hierarchy in keys like BIP32 does for HD wallets. The parent can sign for any derive children key, but not the other way around. Meaning a child key can be used to sign for receiving a transaction, but a second proof (from the master private key) is needed to spend the UTX0. I do understand the Grin blockchain and mimblewimble are technically very different from Bitcoin, so to check if these ideas make any sense, I do need to make time to read up and watch those nice videos that were send on Keybase.
Hopefully, I will be knowledgeable enough to fact check my own ideas myself in due time.
I think child wallets are possible, but right now the knowledge needed to create a utxo from nothing has all the information for spending it.
One option that I am proposing here is to make concrete progress toward enabling additional flexibility in transaction construction in the wallet -
I know others have discussed interest in implementing payjoin and “mostly” lock free transactions. My interest here is making sure we are not “over fitting” any of these implementations and that whatever foundation we build around this can be reused easily for similar needs around payment channels.
If I can help others to implement one of these (payjoin or lock free transactions) in such a way that it indirectly makes progress toward a subsequent payment channel implementation then that will personally feel like an achievement.
Alternatively if we can get to the point of being able to robustly build multi-party outputs via the wallet (and we have convinced ourselves we can do this securely with the current signature scheme) then that will be an achievement.
@lehnberg raises a good point though about maybe needing to focus more time on node and less on wallet given the balance of current contributors. So I may end up not shifting maybe as much as I’d like. In this case I would probably be focused on helping get parallel IBD implemented and deployed.
No. This was simply an example use case to illustrate why we need more flexible transaction building support in the wallet. My interest here is more in the foundational work required to get closer to this.
All good points. We definitely need to discuss the runup to the final scheduled HF. And this may result in continued focus on node over the next few months. My understanding is “duplicate UTXOs” is one area of consensus breaking work that we may decide to tackle prior to HF4. I’m not sure if there are others being discussed currently.
tl;dr Prerequisite for payment channels is robust multi-party output support in the wallet. So this would fall under work required prior to activating NRD on mainnet (itself a consensus breaking change). That said there is a lot of work to get to full payment channels (with nice associated wallet UX) so this needs to be weighed against other work that can potentially be done for HF4.
The work that you will do for GRIN in the upcoming year is very important for the future of Grin. All the results and advancements will be seen by persons that are interested in Grin and they will shape the direction for the coin. The choice in the items to deliver is important. do we want to show that we are interested in making Grin base layer robust and more efficient (for example PIBD or unique kernels, but there are probably others) or do we want to show that we focus on non-urgent needs to satisfy the technical preferences of a few, against the common sense (according to me), for example payment channels, as we are so far away to get at least grin blocks only 10% full. 10% full would be 100 kernels per block, and we are at 2 or 3 per blocks on average. the direction that we take will motivate, or not, future investors to fund the development of Grin, just because any funding is based on the belief that we are going into the right direction, with clearly defined steps and philosophy. So yeah, it would make sense to take things step by step, not doing 5 things at the same time and delivering none of them after one year, but rather show concrete results on the base layer, that make grin experience nicer together with improving the long term of the coin on a practical level. So, I hope we are careful and take the decisions using reason, common sense, whether at the cost of making personal technical preferences be something that is not the number one priority
Thanks, that’s clear to me, and I’m generally supportive of this.
I definitely see the value in thinking more thoroughly about (advanced) wallet use cases. There’s not been a lot to work in that area so far, and as a result you might uncover needed consensus changes, simplification opportunities, or things we just haven’t thought about yet. Also agree it makes a lot of sense to look at a lot of these things together to avoid “over fitting” as you say, and that we’re keeping things as minimal as possible.
I’m worried about us being spread out too thin, perhaps missing needed work on node as a result. But as you point out, we would first need to identify what that node work would be and we’re not quite there yet I think.
It may be that we end up focusing on one of these wallet related features. I suspect “almost” lock free transactions would provide the most impact and immediate benefit. And would push us down the path of starting to think about more flexible wallet interactions.
If we can do this then we can take in progress transactions and “translate” them to use alternative inputs and potentially outputs. We will also be able to adjust the kernel offset per participant as necessary.
I know several people are already thinking about this so I can definitely make some of my time available to help here.
There is also potentially node related changes here in terms of identifying a “locked” transaction during initial push to the node, to allow the wallet to adjust a tx and re-push if necessary. I have not thought this through so this may not actually be the case, maybe all this should be isolated in the wallet itself.
Avoiding taking on too much at the wallet layer would free time up to continue to focus on node as you say.
There is also this - https://github.com/mimblewimble/rust-secp256k1-zkp/issues/72
Which leads into a larger task around pulling in the latest upstream changes to the rust-secp256k1-zkp libs and getting everything compiling and running cleanly against them.
We are significantly behind and missing a lot of changes that exist on upstream.
This is node related but also wallet related as these libs are used extensively behind the scenes during transaction creation, commitment building, rangeproof generation etc.
It may be useful and valuable to spend time updating these libs with a view to getting more familiar with what flexibility we have with transaction building.