Create Gluon_decentralized_hardware_crypto_wallet_services.md #182
Conversation
There was a problem hiding this comment.
Thanks for the application. It looks like you put a lot of effort into it, but to be honest I have a lot of concerns regarding the sharing of private keys. There are a lot of things that could go wrong (e.g. hardware, software or sybil attacks). I personally think that the combination of the Recovery Pallet with a nicer UI and promotion might be a better approach. Would you be interested in working on something like this? Regarding the application itself, it would be nice if you could focus on KSM or DOT instead of BTC.
|
Hi David, thank you for your comments. Your concerns are absolutely within my expectation. Believe it or not, almost everyone asked the same questions when they heard our project for the first time. Bear with me, and my answers could be pretty long. Before answering your concern, we decided to focus on DOT as our first protected cryptocurrency instead of BTC. We will use Recovery Pallet as designed before but much more. Please stay calm and read till the end. I bet you are not wasting your time by reading the detail, considering we have spent years on this project dealing with all possible attacks. Since you have not specified which attack you care about the most, I would like to explain most attacks we have dealt with. HardwareTEE is the most common solution for trusted computing. Although there are side-channel attacks that exist, I still consider it one of today's best solutions. We choose a very different approach not because TEE is not secure, but trying to make it a much larger scale. You can see the differences from the diagram above. Is the TCB(Trust CodeBase) too big to protect?Inside our HSM, there is a "minimized" computer. This computer is not a general-purpose computer like a PC or Mac. It is more like a hardware crypto wallet that can do much more. We are developing a special-purpose Linux OS with one goal - securely loading the waSCC (wascc.dev) based WebAssembly runtime. Everything else not related was ripped off. For example, the keyboard, mouse, video, USB are all gone. The only external IO is the Ethernet. The final product could have only one power port, one RJ45, and one LED, nothing else. A "so-called" black box. (Can we still call it a Tea Box?) Is TPM secure?TPM protects the box itself with the self-destroy feature, which will be trigger by brutal break activities. Once destroyed, no data can be recovered. To do this, there is a backup battery installed. Is the hardware expensive? Can I utilize my existing computer as a mining machine?TPM itself is very low tech and low power chip. Since our code runs at native speed. There is no performance penalty on security caused by cryptography. Any computing device can be used as a TEA mining machine as long as it can install TPM and provide PoT to get verified by blockchain consensus. Hardware performance compare with today's blockchainIf we pick any task that today's highest performance blockchain can do and run it on the $20 Raspberry Pi TEA mining machine, you will find it runs much faster! This is not magic. The only reason that our consensus - PoT goes a very different approach. We do not consent to the result but the execution environment. This is similar to TEE, such as Intel SGX. The differences are that we need consensus on the blockchain, but Intel is centralized. If you trust Intel, everything goes smoothly. We do not require you to trust anyone but the blockchain consensus. Fake TPMEvery TPM has an endorsement key burned into the chip when manufactured. Unless the manufacture intended to produce faked TPM chips, it is almost no way to fake TPM chips. This is almost like the Ledger makes hardware wallet with malicious code built-in, or Intel makes CPU with a backdoor to steal user secret. I highly doubt this would happen. SoftwareOnce your TEA node starts running, you still physically own it, but technically you do not. The TEA consensus fully controls the node. The consensus decides what code to be installed, run, or removed on your node. Any attempt to alter the hardware or software will cause the node quarantine and loss of your deposit and credit score. Delegation ChainNo one knows what task is done by which node. We designed "Delegation Chains" to scrambled or encrypted such knowledge. From outside of the HSM, we can only see encrypted traffic in and out from a TEA node to other TEA nodes. There is no way to determine if a TEA node is running a valuable task. Even the size of traffic and destination IP address won't expose too much useful information. By doing this, attackers can hardly distinguish the high-value targets from those idle ones. In most cases, we run BFT or similar consensus for higher-value tasks. Even some TEA nodes are compromised and not quarantined in time, the damages and chances are minimal. This knowledge will be released to the public only when tasks are done and posted on the blockchain. At that moment, all traces have been wiped out. There is no value to attack an empty node. Use the Gluon Wallet as an example: Assuming there are thousands of nodes running. Unless you can hack into 2/3 of those nodes simultaneously, you probably won't get any useful data. Given all TEA nodes are running different hardware architectures, it is not that easy to find a common vulnerability. Never Store Secret PersistentlyThe TEA node HSM does have storage (SD, SSD, HD), but only executable code and non-secure temp data are allowed to save to the storage. All secrets will stay in the RAM of all running nodes. It can transfer between TEA nodes when encrypted. When entering the destination node, the secret is encrypted and stored in RAM only. When any reason causes the TEA node to lose power, no secret remains in this hardware unit. It needs to run the secure "Repin" protocol to reconstruct the secret from other healthy nodes. Because every secret has many replicas on many "repin nodes" at any given time, there is a meager chance that a secret is lost forever. This design eliminates the chance that any secret is stored in an abundant hard drive. NetworkWe currently run our network communication based on the IPFS libp2p protocol. We choose Libp2p because we happen to use IPFS as our blob data storage. The communication between TEA nodes is end-to-end encrypted. No matter IPFS nodes, or any sniffer will get the content. A nonce is also used to defeat man-in-the-middle attacks. DDoSFrom my point of view, DDoS or Sybil attacks can never be avoided in the long run. What we can do is duplicate. There will be many TEA nodes running in the network. From the outside world, due to zero-knowledge protection, they all look the same. It is tough to identify any valuable target to attack. As long as less than 1/3 TEA nodes down due to DDoS, our network won't get affected. Sybil AttackTEA nodes only talk to other verified TEA nodes. Based on the TPM hardware protection mentioned above, a bad actor cannot pass the remote attestation unless more than 2/3 TEA nodes are compromised. Although TEA node is generally less expensive, getting a piece of hardware won't cost much, but having it pass remote attestation is not an easy job. Code InjectionIf attackers try to convert a good node into a bad actor, the only way is to inject malicious code or alter existing code. This will cause the chained-up hash value mismatch with PCR records, therefore cause the remote attestation failure. The only way to pass remote attestation with compromised code is to hack the TPM chip. TPM is designed to be very simple and stable. It is not too much to be hacked in such simple silicon. Gluon Wallet Specific ConcernsAmong all TEA projects, Gluon is one of the simplest. It sounds scary because it stored private keys. However
PrinciplesWe know no one can design 100% secure system. We are doing to reduce the benefit as well as increase the cost of attack so that economically hacking TEA project is not profitable. There are too many design details to be explained here. If you have more specific concerns, we can continue the discussion. I hope we can find any threat model out of my preparation to improve our security design. I hope my explanation can make you less stressed about Gluon Wallet Project. |
There was a problem hiding this comment.
Thanks for the detailed reply. The application still mostly mentions BTC in the milestones. Could update this with DOT? What do you mean with zero-knowledge and modern cryptographic algorithms to increase the security or “zero-knowledge protection”? Implementing zkps correctly is already not an easy task and can open a lot of attack vectors. What’s so difficult about the “remote attestation” that prevents sybil attacks? Let me also share this application with Robert Hambrockwho might have additional input.
|
Thank you for your quick feedback. I just updated BTC to DOT and other small changes. Let me explain your concerns one by one.
ZKP is not an easy task for sure. However, like we did to improve our consensus by introducing hardware as a new Root of Trust, we did the same to zero-knowledge protection. BTW, our ZKP means zk protection, not zk proof as ZKSNARK did, although we need proof as well. On the one hand, because we use hardware to protect the secret, we can assume what happened inside the hardware enclave is secure. We will not store any secret on the open blockchain. We store a hash of a secret, a signature, or an encrypted text while keeping the key inside TEA nodes (enclave as usually called). If Alice wants to know if Bob has a secret, she asks Bob to send the secret to any TEA node to run a SHA256 or signature verification algorithm inside. Because the TEA node is trusted, it can tell Alice that the hash matches or signature verified. Alice doesn't know what happened inside the TEA node, so she doesn't know Bob's secret. Of course, the trusted node is the mutually trusted party between Alice and Bob. Both Alice and Bob can trust the TEA node due to the PoT consensus I mentioned in my previous comment. On the other hand, we use a lot of one-time-use disposable proof stored temporarily in the blockchain. Just like the commonly used "nonce," once the evidence is verified, it is useless. One example is in the social recovery feature. The sequence of the friends to sign the recovery transaction is one of the secrets. Once the transaction is approved, the secret open to the public in the blockchain. However, since all assets have been relocated from the old account, it doesn't matter if this secret is no longer secure. I can give another example—the fact of which node is selected as the "Executor" processing a valuable task is a secret. It could be vulnerable if attackers know this secret when the node is running this valuable task. This secret is kept unknown until the job is completed. At that moment, this secret is open to the public on the blockchain so that everyone can verify if it is a valid transaction. Since it has been completed, there is no value in attacking this "Executor" node at this moment. Regarding the modern cryptographic algorithms, we mean Shamir Secure Sharing Schema and newer BLS(https://en.wikipedia.org/wiki/BLS_digital_signature#:~:text=A%20BLS%20digital%20signature%E2%80%94%20also,that%20a%20signer%20is%20authentic.&text=of%20the%20pairing)%2C%20allowing%20shorter,a%20similar%20level%20of%20security.), and Fast Secure Multiparty ECDSA (https://dl.acm.org/doi/10.1145/3243734.3243788). We are currently implementing Shamir Secure Sharing in our plan while researching new alternatives. Shamir Secure Sharing is very fast but has its limitations. Others have performance concerns, even running in native speed. The Shamir Secure Sharing Schema can split a private key into n pieces while k of n pieces can rebuild the private key. The k of n threshold makes protection robust while remaining secure.
In our p2p communication protocol, TEA nodes only talk to other verified TEA nodes. If an attacker wants to run a Sybil attack, he needs to own or control a number of verified TEA nodes and run a modified version of the software inside those nodes. When a TEA node( a testee) trying to handshake with another TEA node (a tester), the tester will ask the testee to send TPM stored PCR hashes for verification. Because selecting verifiers is a verifiable random process, attackers have to control over 2/3 nodes to collude. As long as we can maintain the birth rate (http://teaproject.org/#/doc_list/%2FBusiness_model%2FBirth_control.md) at a healthy level, we could keep a reasonable high cost to prevent Sybil attacks. BTW, I am pleased to answer your questions. By doing this, not only us but other community members to understand Gluon and TEA Project better. Also, welcome @Lederstumpf to join our conversation. Please leave your concerns, and I am happy to answer too. |
|
See Vitalik is talking about the crypto wallet too. The same idea as Gluon |
|
Are there any more changes requested? |
|
Thanks again for the update. Why did you increase the BTC price? Could you share some previous work regarding zkps? I will share your application with the rest of the team, but I personally still have a lot of concerns about your project. The recovery pallet has the great advantage that you don’t need to share a private key in the first place (something ethereum doesn’t have). |
Noc2
added
ready for review
When I submitted the application, the BTC price was about 40k that day. but after a few days when I commit the first update, the BTC price dropped to about 30k. That's the reason I adjust the cost.
Because we use the hardware root of trust, we do not need traditional zero-knowledge proof, but zero-knowledge protection. zero-knowledge proof doesn't require a secured enclave to protect. We can just use regular cryptography inside a secure enclave to protect the security so that it is zero-knowledge to the outside world. I have a few examples(;
Both algorithms are just regular SR 25519 and SHA256 not some complex ZKSNARK like algorithm. It is inside some commonly use rust crates. Once the hardware root of trust is in use, a lot of complex algorithms become super simple.
Please feel free to share your concern and I am happy to answer all of them. We will use a social recovery pellet in our Gluon. We design the same feature long before I heard Polkadot has such a pellet. However, having such a social recovery pellet doesn't replace our design to generate and reconstruct private keys inside a secret enclave. The reasons are:
I do not quite understand the sentence "something there doesn’t have" in your question. Do you mean there doesn't have social recovery? Ethereum does have one. It is called the Argent wallet. Or, do you mean something else, please clarify. Again, I am very happy to answer your question and resolve concerns from you and other team members. I totally understand TEA is a complex project that needs a lot of different kinds of background to understand. It sounds very scary too. We choose TEA not because it is easy, but because it is hard but valuable. |
|
@kevingzhang Thanks for the application & detailed explanations. Your demo is great, I really enjoyed watching it. That said, it would go against innovation to only support solutions using verified devices (e.g. SGX), though my expertise on the topic of TEE is limited. I would love to see, for example, more development of the trust-less code execution platform as seen in your demo. In that use case (image recognition) neither the code nor data carry such concerns as wallets and might be a first step to test this type of a solution and convince the users. That's just my opinion, let's see what other members have to add. |
|
Hi @mmagician , I totally understand your concern and willing to share my experiences with you. Let's assume Satoshi did not choose Bitcoin but a twitter-like microblogging application to demonstrate what kind of trust blockchain can provide, I bet most of us wouldn't hear the term Blockchain today. Microblogging can also demonstrate most features of blockchain, but it cannot approve the trust value of blockchain. There is a $720,533,316,011 value stored in Bitcoin today, it was started from 20k BTC per pizza a few years ago. It takes some time to approve the value, and it will approve eventually. We had our first demo application in Nov 2020. It is about the Tensorflow image recognization story. That is the one you tried. It is a good demo. It shows the full potential of the TEA project. However, it is similar to microblogging on blockchain fiction I mentioned above. If we need to approve TEA is trustable, it has to store value as BTC did. If some years later, there are thousands of users who store billions worth of digital assets on Gluon of TEA project, I do not have to convince others. Of course, we have to go step by step. There is a Toyota Prius prior to Tesla, so we have already prepared our hybrid solutions. Let me show you what we hide: Since the first day, TEA supports both TPM and Intel SGX ( or other TEE such as Trustzone). See our online document link http://teaproject.org/#/doc_list/%2FWhat_is_TEA%3F%2FTEA_vs_Trusted_computing.md, please scroll to the end. The section called "When to use TPM, when to use TEE". It was there hidden somewhere in the TEA project for a while. It is called a "capability" in our system. If you remember the Tensorflow image recognization demo, the Tensorflow component is a capability. It could be a capability to have 4 TPU installed in your TEA node, or an SGX supported Intel CPU on board. For mission-critical tasks such as generation, reconstruction, decryption private keys, the user can add one line in the JSON file. { capability: { execute_in_sgx: true } }. When this task is executed, only those who have Intel SGX capability can take over this task. Because Intel SGX is a centralized service, the final Root_of_trust is Intel not TEA. TEA will just verify Intel's evidence and attach it to PoT(Proof of trust) without additional verification. In this case, the clear text of private keys only exists inside the SGX secure enclave. You do not need to worry about TEA. As long as you trust Intel, you got peace of mind while still enjoy all other features Gluon provides. This is a hybrid solution. Uses can choose to use Intel SGX or TEA. There will be price differences between those two kinds of services. No doubt, Intel x86 will be expensive than ARM, so is the service charge. Peace of mind does come with a cost. If this is a deal-breaker, we certainly can turn on this option by default to users. so that private keys are processed inside a secure enclave by Intel SGX. Please let me know if you agree. I am very happy to face all kinds of challenges. Only challenges can make TEA stronger. |
|
BTW, I have element ID: kevingz, I live in Pacific time zone (San Jose, CA). Feel free to element me if you have any quick question. I'd like to talk with you as long as I am awake. @mmagician and @Noc2 and others. |
|
Design changes. Using Schnorr Multisig to eliminate the concerns from @Noc2 and @mmagician. We got a reply from this GitHub issue: paritytech/polkadot#2270 (comment) We happened to know that @burdges is going to implement multisig features of sr25519 "soon-ish". Let's assume Polakadot will support the sr25519 multisig. We can make the following changes in our design. We will not "host" any private keys from our client in our "hard_to_convince" hardware security module. Both @Noc2 and @mmagician's concerns are gone. Here comes the detail: We can see significant advantages over the previous design. Another good news is that Bitcoin is going to use Schnorr multisig in the upcoming upgrade. When it is done (hopefully in one year), we can use the same technologies for Polkadot, Bitcoin, and any other blockchains supporting Schnorr multisig. Since the Polkadot has not supported SR25519 multisig yet, we will test in our test chain for now. Once the Polkadot completes the upgrade, our Gluon is probably ready to serve. It may take a few months depends on how soon Polkadot will upgrade to multisig SR25519. What do you think about this design change. I have not updated the application yet. I hope to hear your opinion first. Thanks |
|
Hi @kevingzhang, thanks for your particularly detailed application! With respect to your latest update, when the 2-of-3 multisig is signed by I think it would be fruitful to have a call to discuss your grant and other directions we could branch your TPM usage into - I'm personally not fully convinced by the |
|
@Lederstrumpf thank you for your comment. Yes, we have similar punishment designs not only for recovery but also for many other cases. By using such logic can discourage attackers. |
|
I have not read this thread, but.. I'll mention that kobigurk/aggregatable-dkg#1 might enable interesting wallet recovery designs. At present, we've no plans to adopt even its much nicer threshold DKGs for validators, and nobody has designed a key handoff protocol for it, so doing anything like this sounds unlikely short term. It's possibly helpful for individual wallets somehow though, like by using its VRF as an OPRF. I doubt this however. We considered Anastasis previously in w3f/General-Grants-Program#226 which was designed to fit recovery requirements specified by some E.U. regulatory frameworks. Anastasis would presumably be required by some stable coin designs. |
|
Hi @kevingzhang, As mentioned via DM, I think we're ready to proceed with your msig recovery/backup grant in lieu of moving to an SMPC-equivalent alternative. To the extent that these changes influence the milestone structure, it would be best to delay any deliverables that depend on schnorrkel off-chain multisig support to the end, where possible. With respect to your proposal to switch to an SMPC-equivalent deliverable instead if schnorrkel off-chain multisig has significant delays, what would you consider to be a significant delay? |
|
updated the application based on our discussion last week.
As long as Polkadot can update to Schnorr Threshold Signature before Jun 2021, our project won't get affected. |
|
I have updated the PR couple of days ago. Have you got a minute to review
it? If you have any further questions, just drop a line or two. thanks
…On Thu, Feb 4, 2021 at 2:02 PM Robert Hambrock ***@***.***> wrote:
Hi @kevingzhang <https://github.com/kevingzhang>,
As mentioned via DM, I think we're ready to proceed with your msig
recovery/backup grant in lieu of moving to an SMPC-equivalent alternative.
Could you still update your proposal with the design change you outlined
in the following comment?
#182 (comment)
<#182 (comment)>
To the extent that these changes influence the milestone structure, it
would be best to delay any deliverables that depend on schnorrkel off-chain
multisig support to the end, where possible.
With respect to your proposal to switch to an SMPC-equivalent deliverable
instead if schnorrkel off-chain multisig has significant delays, what would
you consider to be a significant delay?
Might be sensible to make the SMPC-equivalent a separate grant proposal
instead: looking at your current milestone structure proposal, I don't see
where this and the msig software would overlap materially in software
deliverables.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANOEEOCBRSUIZZ3EOOQMO3S5MKOBANCNFSM4VULP7WA>
.
--
╭︿︿︿╮
{/ o o /}
( (oo) ) Kevin G. Zhang :)
︶ ︶︶
|
|
|
||
|  | ||
|
|
||
| By default, Gluon generates 2 out of 3 MultiSig addresses on Polkadot on behalf of users. The three private keys (secret) are P1, P2, and P3. |
There was a problem hiding this comment.
This is a 2-of-3 MultiSig from the MultiSig pallet, yes? Is there a reason to do this if, as this grant's completion requires, we'll already have native Schnorrkel multisig?
There was a problem hiding this comment.
They do not have to be keys from MultiSig pallet. If the native Schnorrkel multisig is merged into the master, we are happy to use native implementation. This is a replaceable module that can switch to native multisig when it is done, or use the pallet if it is not ready. But looks like the review process is delayed so that we can catch up with the native multisig implementation then. Do you want me to change it in the application to native Schnorrkel multisig?
There was a problem hiding this comment.
yes please - I think that makes more sense given the grant's current requirements.
There was a problem hiding this comment.
If schnorrkel is not ready and the project is left stalling, we can revert to MultiSig pallet.
There was a problem hiding this comment.
Done. I have updated the algorithm to use Schnorrkel.
Thanks
There was a problem hiding this comment.
Appreciate the effort that went into this. I have nothing to add from a technical perspective, my only suggestion is that you hire an experienced copywriter and/or technical writer at some point during this grant so that your technology is clear to potential users, given the novelty of your approach. Also since you mention that you will start looking for investors now: note that you may only disclose the grant publicly once your first milestone has been accepted. Good luck with the project.
|
Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project. |
* resource viewer * changed milestone 3 * quadratic-funding (w3f#227) * quadratic-funding * add license, unit test and a standalone minimalistic frontend to spec * add SEOR code-less smart contract platform application (w3f#205) * add SEOR code-less smart contract platform application * update deliverable & add future plans * add multi-chain support in Milestone 2 & 3's deliverable * formart the subtitles of 'Project Details' segment * Polkastarter Grant Application (w3f#204) * Make Polkastarter Grant Application * Added screenshots * Added testing guides Co-authored-by: Tiago Martins <[email protected]> * Added curve market maker (w3f#225) * Added Zondax maintenance+recovery extensions+support (w3f#234) * Create polkakeeper.md (w3f#200) * Create polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md Added UI User stories, and more detail on the milestones * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md * Update polkakeeper.md Co-authored-by: Caspar Oostendorp <[email protected]> * Readmefixing (w3f#241) * upgrade readme * fix icons * smaller icons * correct icons * Update README.md Updated Evaluators * Update welcome.yml (w3f#242) * Update welcome.yml Update Welcome message * Update welcome.yml updated * Create proposal of stone index on substrate * Updated the BTC payment address * draft of pallet design * Added more details of public functions * Added back the mandatory deliverables * Added desc for public exposed methods * Adjusted the budget * Revised the deliverables 1. Merge the token module into indexed basket management module 2. Made it more clear for DEX integration 3. Update the sequence of deliverables * Create AlgoCash.md * Update AlgoCash.md * Update AlgoCash.md * Update AlgoCash.md * Update AlgoCash.md * Update AlgoCash.md Update the approach of further 500,000 share token distribution * Update AlgoCash.md Add contract specification * Update AlgoCash.md * Update README.md (w3f#250) As discussed on Element, David, I've added Edgeware Grants and Bounties under the other grant programs header. * Update welcome.yml fix html </b> * Create php-scale-lib.md * Payment change * Upgradeability * Add missing milestone title * Reduce scope by removing milestone 2 Milestone 2 was deemed too uncertain to be part of the initial grant. Depending on the results of the first milestone, we will consider submitting another proposal with more concrete steps. * Update pull_request_template.md * Denominating in usd (w3f#253) * Update application-template.md denominating in USD * Update README.md * Create starry_network.md * Rename starry_network.md to Starry_Network.md * Update Starry_Network.md * update Ecosystem Fit * update overview * update architecture * remove ecosystem fit and add additional Information * update overview * Update Starry_Network.md * add nft dao architecture image and reduce price * Added user story about NFT DAO, update demo link * reduce from 12000 DAI to 10000 DAI * Update pull_request_template.md (w3f#261) * Update kylin_network.md (w3f#259) Update the original contract based on grant evaluation comments. [Here](w3f/Grant-Milestone-Delivery#98) Co-authored-by: wannam2049 <[email protected]> * Unified TOC and language with general grants (w3f#264) * Update sensio_network.md Second milestone of senseo will no longer be delivered * Remove forum link (w3f#269) * NewOmega Application (w3f#243) * Add newomega application newomega: Fix alignment newomega: More details newomega: Improve formatting * newomega: Include github link to solidity contracts in deliverables * newomega: Update deliverables to reflect file rename * newomega: Update deliverableremove third milestone, tweak price * newomega: more precision in milestone 2 definition * dotmog application * Create bright_treasury.md * Update currency to DAI, add DoD * Update README.md Updated Committee * Update .gitignore (w3f#279) Co-authored-by: Aleixo Sánchez <[email protected]> * Delete .DS_Store * StandardProtocol application (w3f#244) * Add Standard Protocol Application * Update Standard_Protocol.md * Update Standard_Protocol.md * Update Standard_Protocol.md * Update Standard_Protocol.md * Update Standard_Protocol.md * Update Standard_Protocol.md * Update Standard_Protocol.md * Update Standard_Protocol.md * Update Standard_Protocol.md * Create application-template.md (w3f#276) * Create application-template.md - Some clarifications and highlighting based on past issues, - mention licensing, - more emojis ✊, - ask for - short and long term plans, - community & contributors, - status of project before grant, - previous grant applications, - work done. * Apply suggestions from code review Co-authored-by: Aleixo Sánchez <[email protected]> * Update applications/application-template.md Co-authored-by: Aleixo Sánchez <[email protected]> Co-authored-by: David Hawig <[email protected]> Co-authored-by: Aleixo Sánchez <[email protected]> * Ask for follow-up grant info (w3f#280) * Update README.md * fix headings (w3f#285) * SkyePass application (w3f#212) * add application for skyepass * update porposal * update: identity solution spec * updates on milestone desc * update milestone descp * update milestones * update total cost * update milestone spec * delete status col * Polkadot UI Web Identicon + Angular Identicon (w3f#252) * Submission of the project grant template * Adding repositories for Angular and Web Identicon projects * Deliverable + future plans update * Grant Amount Update * Create ZeroPool.md (w3f#208) * add ZeroPool.md * remove the last milestone * fix typo * Update ZeroPool.md * Quadratic Funding Module and Dapp Application (w3f#268) * Quadratic Funding Module and Dapp Application (#2) * Added quardratic funding proposal * Finalized quadratic funding open grant proposal * Added web app wireframe link and description to project details * 1. Added finalize function to M1 delivery 2. Adjusted BTC amount to make sure the total funding is within limit * 1. Move user study out of M2 to future plans due to tightness 2. Fix the paragraph spacing of last commit * 1. Added UI examples to team's experience section 2. Update the cost denomination to DAI instead of BTC * 1. Changed BTC address to ERC20 DAI address 2. Added Sybil resistance to future plans * Added identity module interaction requirement to M1 delivery * Added project and proposal concepts to UML chart * Webb Mixer (w3f#216) * Create MIXER.md * Update MIXER.md * Update MIXER.md * Update MIXER.md * Update MIXER.md * Update MIXER.md * Update README.md (w3f#288) * Update README.md * Update application-template.md (w3f#289) - target audience - limitations - `the project` -> `your project` * Action to automatically label by approvals remaining (w3f#291) * Github action to label based on approvals (missing) * Revert "Github action to label based on approvals (missing)" This reverts commit f6a6b70. * Github action to label based on approvals * Create Gluon_decentralized_hardware_crypto_wallet_services.md (w3f#182) * Create Gluon_decentralized_hardware_crypto_wallet_services.md * Merge branch 'master' of https://github.com/tearust/Open-Grants-Program * update btc to dot * add light node to communicate with DOT. adjust cost based on BTC price change * update based on discussion. using schnorr and social recovery pellet * update milestones * add prerequisites to Schnorr threshold sign * update using Schnorrkel algorithm * update to USD * Update google_sheet_update.yml * EverlastingCash Web3 Grant Application (w3f#277) * Create EverlastingCash.md ELC - An algorithmic stablecoin with reserves * Update EverlastingCash.md * Update EverlastingCash.md * Update EverlastingCash.md * Update EverlastingCash.md * Update Linkedin Co-authored-by: steven <[email protected]> * approval labeler rewrite (w3f#292) * Github action to label based on approvals (missing) * Revert "Github action to label based on approvals (missing)" This reverts commit f6a6b70. * Github action to label based on approvals * approval labeler rewrite * substrate identity directory (w3f#255) * substrate identity directory * substrate identity directory * added 0a to 0d deliveries to milestone 1 * price changed Co-authored-by: dark64 <[email protected]> * A comma (w3f#298) * Update README as in General Grants repo (w3f#303) * Update README as in General Grants repo * Update README.md Co-authored-by: Aleixo Sánchez <[email protected]> Co-authored-by: David Hawig <[email protected]> * Update README.md Fixing links * Update README.md fix rfp link * Update README.md fix milestone-deliverables-guidelines link * Update README.md Update tech stack/accepted links * Fix broken links (w3f#307) * Update MAP-Bridge.md Termination, see [comment](w3f/Grant-Milestone-Delivery#89 (comment)) * Update MAP-Bridge.md Added payment address again, just in case * Update clover_network.md (w3f#310) * Update shadows-network.md (w3f#309) * Update README.md * Update README.md * Update README.md * Open Grants Program application for project Delmonicos (w3f#283) * Update delmonicos.md + Application update after questions from Noc2 * Update to address demand from gautamdhameja * Changed repo url Repo moved to the newly created Delmonicos organisation * Update polkadex.md * Add Treasureland Grant (w3f#218) * Create Treasureland.md * Update Treasureland.md * Update Treasureland.md * Update Treasureland.md * Update Treasureland.md * Update Treasureland.md * Update Treasureland.md * Update Treasureland.md * Update Treasureland.md * ChainJS Grant application (w3f#228) * Create chainjs.md Adding template for grant proposal * Update chainjs.md Adding ChainJS for Polkadot draft proposal * Update chainjs.md Corrected title * Update chainjs.md formatting * Update chainjs.md added ecosystem fit section * Update chainjs.md * Update chainjs.md Removed instructions * Update chainjs.md removed instructions * Update chainjs.md Added more narrative to future plans * Update chainjs.md * Update chainjs.md Added Kusama support into the grant application, and added more description of the difference between ChainJS and Polkadot.js * Update chainjs.md Updated pricing * Update chainjs.md Lowering price * PolkaJ Android Support proposal (w3f#301) * PolkaJ Android Support proposal * Update BTC to DAI * Adjust price based on feedback * Remove undelivered milestone (w3f#318) * xtoken - XCM Implementation for Fungible Assets (w3f#316) * xtoken * update description * update * update payment denomination, and milestone 1 deliverables * file name change, milestone cost updated Co-authored-by: Bryan Chen <[email protected]> * stable-asset.md (w3f#286) * stable-asset.md * Update stable-asset.md * Update stable-asset.md * Update stable-asset.md Co-authored-by: Shengda Ding <[email protected]> * move the application file into its proper folder (w3f#320) * discount based on hackathon participation (w3f#325) * Update EVANESCO Legal Structure (w3f#326) * pallet-maci (Minimal Anti Collusion Infrastructure) (w3f#232) * Create pallet_maci.md * Update pallet_maci.md * Update pallet_maci.md * Update pallet_maci.md * discount Apron Network for ParityAsia hackathon award (w3f#323) * changed the bitcoin address (w3f#330) * discount deeper network due to hackathon participation (w3f#324) * Create XPredictMarket.md (w3f#313) * update the gsheet workflow * re-estimate the price of milestone (w3f#331) * Update Apron_Network.md Remove SDK from milestone and reduce the price * Update Apron_Network.md Reduce the price * Bit.Country Milestone 2 (w3f#305) * Create bit_country_m2.md initial draft for m2. * Update bit_country_m2.md Finalised the tasks in the milestone. * Update bit_country_m2.md minor milestone text update * Update bit_country_m2.md update team member * Update bit_country_m2.md update image. * Update bit_country_m2.md Change the amount to be USD as required. * Update bit_country_m2.md Add bootstrap tasks for launching testnet. * Update grant application. (#1) Restructure and update wording to improve clarity of deliverables. Add summary and considerations sections. * Tech stack and changing NFT native to support NFT Tech stack and changing NFT native to support NFT * update Duration update Duration * fix typo Co-authored-by: Shannon Christie <[email protected]> * removed "Adopt storage", reduced costs (w3f#339) * Create vera_defi.md (w3f#281) * Create vera_defi.md Initial grant application * Update grant application * Replace https with http to fix images link. * Add more details to the milestone * Update vera_defi.md Update bio * Update vera_defi.md * Clarification on NFT Lending * Update vera_defi.md NFT Token development clarification * Update vera_defi.md Fix style * Update vera_defi.md Fix style * Update vera_defi.md Update scope to focus on AssetManager. Use existing NFT implementation instead of building our own. * Update vera_defi.md Update cost Co-authored-by: arbach <[email protected]> Co-authored-by: Denis <[email protected]> * Create Parallel.md (w3f#329) * Auto-merge action (w3f#349) * NFT Collectibles Wallet (w3f#341) * NFT Collectibles Wallet * updating project scope and adjusting cost * updating estimated duration * reordering milestone numbers Co-authored-by: Michael Huntington <[email protected]> * Clean & fix actions (w3f#359) * Delete label_approval_count.yml * Update auto_merge.yml (w3f#360) * remove m2 (w3f#355) * Update README.md * cosmetic fixes * Subspace (w3f#357) * first draft * second draft * minor edits * finial revisions * Rename subspace.md to spartan_poc_consensus_module.md * adjust license and cost * adjust license and cost * no parallel funding from multiple sources * Update dorahacks-quadratic-funding.md * Update README + other minor changes (w3f#367) * Add more info to README * Track team provenance + minor updates to template * Update PR template * Update dorahacks-quadratic-funding.md (w3f#370) We completed frontend integration with HackerLink. However due to tight schedules we didn't create a demo page based on the substrate-frontend-template (task #2 of Milestone-2). Another reason why we didn't create the simple page is that HackerLink has a complete infrastructure for user registration, project upload / display, etc. The HackerLink code base is not open source. We would like to provide a complete demo of how quadratic funding grant is functioning on a parachain or potentially on Polkadot / Kusama relaychains in the future. Therefore we would like to still submit a milestone. Given that our frontend is not open source and we are only providing a demonstration site that uses our milestone-1 code to provide a service for quadratic funding grant, we are reducing the price to 0 accordingly. * Delete application-template-cn.md (w3f#372) Co-authored-by: borispovod <[email protected]> Co-authored-by: Jiannan Zhang <[email protected]> Co-authored-by: AKACoder <[email protected]> Co-authored-by: Polkastarter <[email protected]> Co-authored-by: Tiago Martins <[email protected]> Co-authored-by: mikolajsobolewski <[email protected]> Co-authored-by: Juan Leni <[email protected]> Co-authored-by: RAMPDEFITEAM <[email protected]> Co-authored-by: Caspar Oostendorp <[email protected]> Co-authored-by: semuelle <[email protected]> Co-authored-by: David Hawig <[email protected]> Co-authored-by: calvinzhou-rockx <[email protected]> Co-authored-by: Dohkooo <[email protected]> Co-authored-by: Junte <[email protected]> Co-authored-by: gmajor <[email protected]> Co-authored-by: Hugo Peixoto <[email protected]> Co-authored-by: Fuling <[email protected]> Co-authored-by: Aleixo Sánchez <[email protected]> Co-authored-by: kylin <[email protected]> Co-authored-by: wannam2049 <[email protected]> Co-authored-by: celrisen <[email protected]> Co-authored-by: darkfriend77 <[email protected]> Co-authored-by: Agnieszka Olszewska <[email protected]> Co-authored-by: Kasia Łukasiewicz <[email protected]> Co-authored-by: Aleixo Sánchez <[email protected]> Co-authored-by: Hyungsuk Kang <[email protected]> Co-authored-by: Song Zhou <[email protected]> Co-authored-by: Mor GUEYE <[email protected]> Co-authored-by: Igor Gulamov <[email protected]> Co-authored-by: Drew Stone <[email protected]> Co-authored-by: Kevin Zhang <[email protected]> Co-authored-by: steve <[email protected]> Co-authored-by: steven <[email protected]> Co-authored-by: Ana Milić-Štrkalj <[email protected]> Co-authored-by: dark64 <[email protected]> Co-authored-by: Lumena <[email protected]> Co-authored-by: dego-team <[email protected]> Co-authored-by: Marc Blinder <[email protected]> Co-authored-by: Nathan Schwermann <[email protected]> Co-authored-by: Bette <[email protected]> Co-authored-by: Bryan Chen <[email protected]> Co-authored-by: Frank Yin <[email protected]> Co-authored-by: Shengda Ding <[email protected]> Co-authored-by: Marcin <[email protected]> Co-authored-by: eva-networks <[email protected]> Co-authored-by: Filip Pajic <[email protected]> Co-authored-by: Sota Watanabe <[email protected]> Co-authored-by: XPredictMarket <[email protected]> Co-authored-by: Toney <[email protected]> Co-authored-by: Ray Lu <[email protected]> Co-authored-by: Shannon Christie <[email protected]> Co-authored-by: arbach <[email protected]> Co-authored-by: arbach <[email protected]> Co-authored-by: Denis <[email protected]> Co-authored-by: yubo-ruan <[email protected]> Co-authored-by: Michael (GP) <[email protected]> Co-authored-by: Michael Huntington <[email protected]> Co-authored-by: J Wagstaff <[email protected]>
* Create Gluon_decentralized_hardware_crypto_wallet_services.md * Merge branch 'master' of https://github.com/tearust/Open-Grants-Program * update btc to dot * add light node to communicate with DOT. adjust cost based on BTC price change * update based on discussion. using schnorr and social recovery pellet * update milestones * add prerequisites to Schnorr threshold sign * update using Schnorrkel algorithm * update to USD
|
@kevingzhang we may be able to implement w3f/schnorrkel#11 so you can get started with milestone 3. Could you reach out to |
|
@kevingzhang sorry that didn't work out. Is there any way for you to work around this? This grant has been open for quite a long time now and, without a clear timeline for the next milestones, we should either amend it so that you can work on it now or cancel the rest of the milestones and you apply again when you can start. |
|
I am discussing this with Santiago. He is trying to have it done before Lederstrumpf leaves. Let's see how it goes. |
Hi @kevingzhang. Are there any updates regarding the grant or the Schnorrkel issue? |
|
Hi Sebastian,
Nice to hear from you again. Actually there has not been any update since
our last conversation. Since we cannot be stuck there waiting for three
years, we have moved on to the ETH as our layer1 since 2022. Our TEA
Project is currently running on top of ETH as our first layer1 chain. But
our technology doesn't rely on any specific chain, so we would be happy to
add additional layer 1 chains, of course, Polkadot is the best choice.
I had an email conversation with Coleman Maher in another email thread. He
asked me the same thing, but it sounds like he is not a technical person.
I've told him what we need and why we are stuck about three years ago.
If there are any updates, I would be happy to know. Considering it is
crypto winter, all of us (especially for us, a small startup ) need to be
very flexible and creative to survive.
BTW, the TEA Project is pretty much done as the first phase of the project.
We are preparing for the alpha launch at any time. Since it has been years,
if you need any update from the TEA Project, and the value that TEA can
bring to DOT, I am very happy to talk to you.
Kevin Z
…On Fri, May 19, 2023 at 5:49 AM Sebastian Müller ***@***.***> wrote:
I am discussing this with Santiago. He is trying to have it done before
Lederstrumpf leaves. Let's see how it goes.
Hi @kevingzhang <https://github.com/kevingzhang>. Are there any updates
regarding the grant or the Schnorrkel issue?
—
Reply to this email directly, view it on GitHub
<#182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANOEELYOTUFLX4S623EXE3XG5T6VANCNFSM4VULP7WA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks for the update, @kevingzhang. It's very understandable that you moved on and I'm sorry it hasn't worked out so far. In this case, I am going to close the grant formally. If anything changes with regard to the underlying issues, it should be pretty easy to sign another grant to complete the implementation. Best of luck going forward! |
|
yes, you can close the case. when the block is removed we can continue on a
new grant. thanks
…On Thu, Jun 1, 2023 at 4:38 AM Sebastian Müller ***@***.***> wrote:
Thanks for the update, @kevingzhang <https://github.com/kevingzhang>.
It's very understandable that you moved on and I'm sorry it hasn't worked
out so far. In this case, I am going to close the grant formally. If
anything changes with regard to the underlying issues, it should be pretty
easy to sign another grant to complete the implementation.
Best of luck going forward!
—
Reply to this email directly, view it on GitHub
<#182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANOEEK7B4AFIGFEZDSQYOTXJB5JTANCNFSM4VULP7WA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Grant Application Checklist