Well yes, you can have a wallet, query its content and publish that online. The problem is that it is not more transparent since you cannot confirm yourself, you are still relying on a third party.
I think it would be best to work towards support import and export of view keys as well as having addresses on the account level. In this way a user can naturally compartmentalize funds.
The major challenge is to have all these accounts with their slatepack-address/tor-address online at the same time. We discussed this during the last CC meeting on KeyBase. Maybe a bullet board system would best solve this since running multiple instances of tor is difficult if not impossible. David T will work on this if his funding request gets granted (I assume it will be), as well as community we can brainstorm on such solutions.
Well if it is a fundraising platform that provides one API to view wallet contents of projects, then either all of the projects would be wrong or none of them would be. The API wouldnāt return a wrong result for just one single project, for example
That is right, unless the third party is malicious and for example filters out transactions for a specific project, or worse, show those transactions as being donated to another project. In any case, if such a wallet would be run and occasionally verified by for example the CC, it would be a nice improvement.
The current bottleneck is still having multiple accounts online to segregate donations to different projects. Another way to solve this is by barcoding in the transaction itself. E.g. donating 1.000001 would mean donation to project 1 donation 42.000002 would be to project 2. This is a simple but non ideal solutions/workaround that works with the current wallet softwares. Preferably we first build in support for multiple accounts and then build such an APP and/or support import and export of vieuw-keys.
Lastly, we should question if such a system is needed at this stage of the project. With the current number of donations, people can already indicate to us they donate for a specific purpose before donating the amount. We already provide descriptions labels to transactions. As long as there are not massive numbers of donations coming in, this system works fine. Although I fully agree such a system should be build in the long term, it is not solving a problem we have, since the few monthly donations coming in can be manually labelled just fine.
thatās why it would be best for something like grinnode.live to provide a general API endpoint for this. the fundraising website / app wouldnāt need to make their own API then.
A product that I would like to see, would be decentralized WI-FI hotspots payable with grin. That would give people the opportunity to earn some grin similar to mining, by offering a service. Or pay for internet access just by POW.
Platform Hardware could be an modified open-WRT Router or a raspberry PI.
To make the service anonymous the WIFI hotspot might use TOR and rotate MAC-Address regularly.
To reduce the need for trust in the service and on-chain-data, a payment channel based āstream paymentā with small payment chunks would be helpful.
grin related data, like blockchain synchronization and payment channel updates could be prioritized since it is already local data.
We need to get rolling on some of the wishlist items SO THAT products can actually be built with Grin.
I understand that there is some hesitance to attach bounties to wishlist items. Maybe people think that it would lead to shoddy work. But we do not have the luxury of the Bitcoin flywheel (dev improves UX ā more adoption ā devās bags are more valuable). It doesnāt work like that in Grin. So how else can we incentivize developers other than bounties?
I can see how the CC running the bounties isnāt ideal, but until Grin is actually CAPABLE of having something like crowdfunded bounties (need wallet view keys etc) there isnāt another option, is there?
Suggestion: the CC attached bounties to key wishlist items that would at least enable the creation of a decentralized crowdfunding app to be built. Thoughts?
Btw, the view key is just one example. Many things on the wishlist are genuine roadblocks for products being built with Grin. Iād like to identify the roadblocks and put bounties on them.
I just tested it in one of the latest builds. rewind_hash is not recognized as a command.
I guess it broke somewhere along the way and was disabled.
I did not know it worked in the past until I found this tutorial today. Since it does not work anymore it should still be on the Wish-list unfortunately.
Regarding putting bounties, there have been a lot of discussions on whether Bounties are or are not a good idea. Below I will give a short recap of these discussions:
Items on the wish-list that require adding functionality to grin node or wallet do not work well with bounties because it is always the OC and Michael who end up having to implement it in the core code making the bounties ineffective in lifting their burden. It is always the same people who end up doing the heavy lifting unfortunately. ā Ideal solution, find someone who is willing or already knows some of the core code, who can support Michael and who can add extra functionalities that are on the wish-list. These could be lower hanging fruits/simpler tasks as long as they are implemented directly in grin and grin-wallet.
Bountis can work for anything ecosystem related, things build on top of grin, grin-wallet, grin++ via their APIās. An examples of such bounties could be a payment plugin. Alternatively bounties could work for independent projects and tools that do not require implementation in the core code but which can empower ecosystem developers, e.g. Mimblewimble-py, the grin.mw.py API wrapper for Python, open block explorer by @vegycslo, vanity address generator etc. Note thought that these examples are all projects that were developed out of for grin and not for a bounty.
So bounties can work, but they are not the best solution for all items on the Wishlist.
Just an update, I tested viewkey/rewind_hash on 5.2.0-alpha2 and it works just fine .
When I tried it earlier, I accidentally used an old version which was before the rewind_hash function was implemented
In any cases it works, so I will update the wishlist accordingly .
One thing missing is to add it to the wiki.
When has money ever not helped someone? At the least it would make the work seem less thankless. At the best, it would signal to others that we value the work and they, too, could get money if they wanted to contribute.
What I mean is that the limited number of long term dedicated and available core developers is more limited than the funding we have. For example we, have finances to hire @Yeastplume for another 40 hours, but his working hours are already spoken for and he needs his . We cannot ask him to work 80 hours per week. So truely, the biggest āgame changerā would be to convince more devs to long term commit to grin. For example Devs who helped out in the core repositories in the past years. So far, bounties have failed to pull in people who know the core repository, who want to stick around and who are doing it at least partly out of .
Perhaps we should advertise a 0.5-1 FTE semi permanent core position, but limited it to those who have shown to ācommitā to the repository in the past and have at least partly proven their mettal. Funding can be done via Funding Requests or we can still discuss the funding method. This would be a solution to items on the Wishlist that are integral to Grin.
Items on the wish-list that are stand-alone or build on top of APIās, those we can discuss where there are opportunities for bounties and where we should take a passive approach, e.g. let community members build solutions whenever they feel like it.
Lastly it is important to mention that anyone at any time can make a Funding Request or start a discussion about funding any item whether it is on the wishlist or not. So in that sense funding is always available for whoever needs it as long as they can bring the proper arguments to the table to convince the community to support their request.
I like the idea of having a plug-and-play USB-style wallet that I can use to store my Grin. Then I can keep this USB in my bank vault for safety.
Another idea is similar but a plug-and-play USB-style miner. The Gps rate would not be very good but it may help with decentralization or getting people interested. A good example of this would be the bitaxe miner
Iām getting also started on some Grin related projects soon too. Excited to see what I can come up with.
for grin and not for a bounty.
.
.
. We cannot ask him to work 80 hours per week. So truely, the biggest āgame changerā would be to convince more devs to long term commit to grin. For example Devs who helped out in the core repositories in the past years. So far, bounties have failed to pull in people who know the core repository, who want to stick around and who are doing it at least partly out of 