Proposal “estonian-development-team“ (Closed)Back

Title:Start of an independent Dash development team in Estonia
Owner:mart
Monthly amount: 91 DASH (3518 USD)
Completed payments: no payments occurred yet (2 month remaining)
Payment start/end: 2020-04-18 / 2020-06-13 (added on 2020-04-18)
Votes: 798 Yes / 225 No / 67 Abstain
External information: app.dashnexus.org/proposals/estonian-development-team/overview

Proposal description

Proposal in DashNexus has better format

TL;DR

A software developer with team building skills and background aims to start an independent Dash development team in Estonia, Tallinn. The plan is to start small with few people and slowly grow over time to form a team of 5-10 people. We would start with a project that makes it possible to send Dash transactions offline by using smart-card technology.

Introduction/background
Hello all,
my name is Mart Mangus and for years I have shared the vision about how the development of Dash should be decentralized into multiple independent development teams. I believe that in a long run it will have a positive impact on the whole Dash platform. For example:
  • There will be more developers and more useful and diverse software will be created
  • There will be a healthy competition in the network
  • There will be options for fallback if one team fails
There is nothing wrong with the current development by the Dash Core Group, they are actually doing a great job. However, I think that diversifying development into more cooperative teams would make the network stronger and healthier.

Development plan
Offline smart-card for Dash payments

We would like to take up a project that will be useful for Dash and which we can deliver with our team. In short, our plan is to develop a smart-card based solution which would allow to do Dash transactions while payer has no internet access. The inspiration for this actually came from a recent solution made for Bitcoin Cash (https://be.cash) and we think that would be a great addition for Dash as well and definitely necessary for its adoption. For example, you can use Dash when you have no internet access (e.g. traveling, remote locations), when your phone's battery runs out or even if you have no phone. It would be great option for people living in poverty as smart cards are cheap alternative and we are also used to its form factor. You could also give them as gifts to your friends or family and they can use in a convenient way. Payments with the card can be fast (a tap took less than a second on be.cash demo).

Development plan
We will start by creating a DIP that includes all changes required for enabling this solution. Since the whole process, including discussions with the Dash Core Group and comprehensive testing will take time, we'll be investigating alternative options meanwhile as well (such as using the Dash Platform Evonet instead).

We'll work in cooperation with Ash Francis (Dash Retail) and Tobias Ruck (the author of be.cash) to find the best solution.

Technical details
The be.cash solution uses opcodes that are not implemented in Dash. Namely OP_NUM2BIN, OP_BIN2NUM, OP_CAT, OP_SPLIT, OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY.

By the end of the second month we aim to have the following:
  • DIP for enabling offline smart card payments
  • Code supporting the DIP
  • Draft of an alternative solution using Evonet
  • Offline smart cards specification
Future developments
After we have successfully delivered the smart-card solution, we would propose to move on and work on any of the following topics:
  • Building DApps
  • Performance/load testing of Evonet
  • Security testing of Evonet
  • Independent privacy checks of Evonet
  • Experiments with Evonet data by using machine learning (such as monitoring network health, predicting attacks, etc.)
Our team
We have many talented technical people around here who would like to have the opportunity to work for Dash. I have around 20 years of programming experiences under my belt: started with BASIC, moved on to Visual Basic then to PHP, C/C++, Java, Python,
Elixir and ended up doing machine learning. I have graduated Estonian IT-College and worked there as a lecturer. I have also co-founded a few companies/startups:
  • Digital Cash Ltd -- programmed an end user solution with hardware wallet for crypto buying-holding-selling
  • CoinBakery -- we did crypto and blockchain related projects
  • random forest Ltd -- a team of ~10 people that is developing custom-made software
However, at the moment I am not actively involved in these projects anymore and therefore I can focus solely on this proposed project and finding the right people to do that.

Budget
I will keep the accounting public and transparent, and also share a summary of every month we worked.
In case the value of Dash rises before we have paid our salaries then we will use the extra money to cover the costs of the following months.

Salaries3 000 € / month
Estonian taxes added on salaries2 205 € / month
Office expenses
500 € / month
Proposal fee
5 Dash
Total @ 65€ / Dash
 91.35 Dash / month

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
 
0 points,3 years ago
Little update: https://github.com/Dash-Dev-EE/DIP-draft/wiki/Progress-report-24.06.2020
Reply
0 points,3 years ago
What will you do Mart if DCG for whatever reason decides that it's not in the best interest of Dash to approve your DIP. For example, DCG could decide the following:

- Merging and testing the code would needlessly delay the current roadmap for something non-essential.
- The DIP creates a probable security risk,
- The DIP jeopardizes Dash's status as a non-security*.


* see https://www.cryptoratingcouncil.com/asset-ratings -- Dash has a perfect score while BCH is not even listed.
Reply
1 point,3 years ago
Our goal right now is to have trustless offline smart cards for Dash.

If the community and DCG do not approve our DIP, then we can use a different (a bit worse) technology. Like cards that work in a way that they store the UTXOs on the card, and when a payment is made, they take a couple of these UTXOs, build a transaction, and sign it. Then, they update the UTXO set. For example the blochstech.com cards work that way. These cards can work with current Dash Core, but there are a couple of problems with this approach (search for "blochstech.com" in comments and see my reply).

But I think/hope we are smart enough to pick the better technology/way for this solution and that is be.cash like cards that need few more opcodes in Dash Core. And we are actively working on that DIP.
Reply
1 point,3 years ago
I am willing to be in support of this based primarily on your intention to conduct "independent privacy checks of Evonet."

As you likely know, the development of Dash's privacy feature has fallen woefully behind the rest of its offerings. We have cutting-edge protection against 51% attacks, instantly re-spendable transactions, industry-leading governance... and yet, our privacy offering only really works on a storage-heavy, ugly-ass QT wallet circa 2014.

It is clear at this point that for whatever reason(s), DCG intends to steer clear of meaningfully developing Dash's privacy offering, at least for the foreseeable future.

Would you agree to make developing Dash's privacy capabilities a priority after you finish your card project?
Reply
0 points,3 years ago
Significant improvements to PrivateSend coming in V.0.16.0 now on Testnet.

https://github.com/dashpay/dash/pull/3479

Most relevant part:

"In the old system, receiving lots of small transactions basically clogged your wallet up with tiny inputs, resulting in high fees and other problems (including potential privacy attacks, due to user more inputs than necessary). Under this system, that will still happen in the case of receiving LOTS of tiny transactions, but it will be to a much lesser degree.

This is due to the fact that in the old system, 11 smallest denoms were created first, no matter what, under this system, assuming you have privatesenddenoms (50) of the smallest denom, then the wallet will only create as many smallest inputs as it needs to to mix all the funds. As an example, receiving 1.584 Dash in my test (at privatesenddenoms) resulted in only 4 new 0.001 denoms."

The takeaway if you just want the cliff-notes:

In this new system, ALL funds, up until the privatesend max_amount will get mixed.
Reply
1 point,3 years ago
I don't think this comment accurately reflects the current state of Dash's privacy offering. For example, to your contention that PrivateSend has "fallen woefully behind the rest of [Dash's] offerings", I would counter with this section of a recent blog post (Feb 19, 2020) related to v0.15.0 updates (so the most recent version of the protocol):

"PrivateSend Improvements

It has been possible to run a node without storing the entire blockchain, although many Dash specific features were disabled. This “Lite Mode” prevented popular features such as PrivateSend. This release decouples client-side mixing from “Lite Mode,” making it possible to mix on a pruned node. Please see the release notes for specific instructions on PrivateSend mixing going forward.

In addition, the “Liquidity Provider” mode (designed to support high mixing volume) was removed, as it is no longer needed with the introduction of the new InstantSend system which sped up mixing significantly."

So that's two major things in the most recent update that show that DashCore is still carefully watching and tweaking privateSend. The first is a pretty significant contribution as I'm sure you'll agree, mixing on pruned nodes makes it that much easier for everyday users to use it. But the second one I think most succinctly makes the point: all of Dash's updates on the path to evolution have either directly or indirectly benefited privateSend.

For example, in this (actually not bad) article from Joel Valenzuela that details then-recent updates and protocol additions, the massive implications and improvements to privateSend were clearly deliniated:

https://dashnews.org/dash-releases-historic-0-13-update-with-default-instantsend-privacy-improvements-masternode-overhaul/

Without making the comment too long, suffice to say instantSend-by-default, lower denominations, and increasing the max rounds from 8 to 16 were all major privacy protocol upgrades that significantly changed and improved both the UX of PrivateSend, as well as the actual privacy provided.

I think that the mistaken sentiment you expressed here is a result of a lack of understanding of how the privacy works in Dash in general. Many times people will say online that Dash's coinjoin is ineffective, and even you seem to imply that our privacy is less than effective or "somehow hard to use". But in reality what are you comparing it to? Dash is the only POW coin with decentralized, trustless coinJoin, so BTC, BCH and ETH are AUTOMATICALLY, OFF THE BAT inferior in terms of their ux.

Have you ever tried to use a BTC mixer? I have, its not fun. Its expensive. Its very slow. BTC, BCH and ETH don't have instant transactions, they don't have multiple mixing rounds and for years they didn't have trustless coinjoin. So again I ask, who are you comparing Dash to when you make these claims about our privacy?

Is it Monero? Monero's privacy has been proven to not work. IT didn't work for 3 years and as former monero developer fireice_uk demonstratively proved, it *still* doesn't work. What's more, monero's UX is somehow even worse than BTC's. Expensive, slow (20 min to be able to use your funds again), dodgy privacy premises and a low-anonymity set.

Or are you comparing us to ZCash? The coin whose supply you can't audit, like Monero's as well? The coin whose privacy is hard to use, requires special addresses and generally seems to be a hack-on? Or are you talking about PIVX, whose privacy was and remains shutoff for over a year due to a game-ending bug that also was found in ZCoin (IIRC) and ZCash? I'm just curious, who is it that has a better privacy experience than Dash?

You literally just have to click a button in the core wallet. If you don't want to use core wallet, you can use Electrum (only recently, so this is not such a good argument I know), or you could've used MyDashWallet for over a year now as I often do. So what's so hard about it? I mean, its not any harder than sending or receiving a transaction in Dash, at least to me. Monero is much harder. Doing everything that Dash does is much harder in other coins. I think we need to take a step back for a second and survey the landscape.

Dash's privacy feature has the second largest anonymity set right behind ZCash, and we got that by a simple protocol upgrade, basically changing a constant. ZCash spent years developing their new tech. We upgraded in a flash and went frmo an anonymity set of ~6000 to ~14,000,000. Which means its really, really hard to deanonymize a privateSend transaction already. That's on top of how hard it is to deanonymize a Bitcoin transaction.

Most people don't seem to know this, but unless you have an exchange or KYC-account associated with that BTC address, BTC is incredibly difficult to track. Incredibly so. After 2 hops its basically looking for a needle in a haystack. So again where does the conclusion that our privacy has taken a back seat come from? I think that its premature to conclude that this sentiment is correct. Its fine to start a dialog on it, I agree. But the conclusion I think is premature.

I mean, I think a better question is, keeping in mind the sprint towards our MVP, what would you like or have liked to see Core do differently?
Reply
1 point,3 years ago
I'm not comparing Dash to any other cryptos with my claim, actually.

I'm comparing where Dash's privacy offering is, versus where I'd like it to be. We've spoken about Evolution for years as a product we intend for mothers or grandmothers. Why is PrivateSend not included in any of the Dashpay demos?

"Sorry, Mom, the Venmo-like experience we've been bragging about creating doesn't actually extend to one of Dash's core offerings. You'll have to use a pruned node for that. You know what a pruned node is, right, Mom?"

I want to see PrivateSend treated as an end-consumer feature, just like InstantSend, ChainLocks, etc.
Reply
0 points,3 years ago
Ok, so your issue with privateSend is not due to believing that it offers an inferior UX to other coins; rather, you believe that privateSend has not been accurately represented to end-users/consumers and you basically feel that PrivateSend has not been treated as a "first-class citizen" as it were.

I think there may be room for that complaint. However, where I disagree I think is in the fact that I don't think there was or is any other way. From my perspective, PrivateSend works great, its easy to use and I don't even think about it. As a MNO for example, I mix every payment and I always use 12-16 rounds. Its always fast in the background, my PC doesn't go cpu-crazy, etc.

Honestly, I can't really fault your above post much as PrivateSend has not been given the rockstar treatment that instantSend, governance and decentralized funding has been, whether in terms of just recognition from Core, or in terms of the focus of Core's productions (like Q'ly calls, etc.) So in that aspect I actually agree. PrivateSend *should be* better marketed and it should be treated as a first-class citizen.

I disagree with the idea, however, that the issue warrants or would even be solved by a second team. From my perspective, and feel free to enlighten me if you disagree, DCG's treatment of privateSend was and remains a necessary tight-rope walk between regulators looking for any reason to shut down cryptocurrency (notice how its basically impossible to buy any without KYC - not a coincidence imo), and developing and maintaining a robust privacy solution.

As I've said, I believe that Dash has the second largest anonymity set of all the privacy coins, with a UX and UI that is superior to ALL OTHER options. So in this I admit to being "complacent".

However, I believe that once Evolution is completed, privateSend's place within the ecosystem will be allowed to shine regardless of how many other teams we have working. Don't get me wrong, I support this proposal, decentralizing the dev teams (although too many cooks in the kitchen is definitely a real concern for me - see current BCH node drama for the last 6 months).

Concretely, I believe that PS will take center stage in various forms thanks to DAPI and other improvements that have, heretofore hampered real efforts at other PS developments. Why change how PS functions now if there's going to be another major update within the next fiscal year? e.g.

Would this scenario coming to fruition satisfy your concerns with DCG's commitment to privateSend and user privacy?
Reply
2 points,3 years ago
Thanks for your thorough response.

To answer your final question, I'd likely need a technical debriefing from you. What is it about DAPI going to mainnet that would allow PS "to shine"? Why has PS development been "hampered" thus far absent DAPI on mainnet?

My guess is that you predict that non-DCG developers will take DAPI and that at least one of them will create a DAP that makes PS easy and wonderful to use on mobile. Which leaves DCG in the clear regarding their political goals, given that they weren't the development team to do it.

Do I understand you accurately?
Reply
2 points,3 years ago
I wrote a TL;DR near the bottom, Press F3 and enter

"***********************TL;DR HERE***********************"

to go to and read it if you wish to skip the technical review portion of this comment, which is rather long.

Thank you for the discussion. It is always a pleasure to profundize into ways to improve Dash as a community, and bringing PS to the mainstream is definitely a glaring hole in our strategy indeed, so I also appreciate you voicing these concerns here. Hammering out their solution is also very beneficial for us as a network so these criticisms are in the right place and to me, come from genuine concern for the network.

To respond to your request for a technical debrief as far as I am able, I would submit that your guess is correct in its conclusion. To further, fulfill this commitment to respond to your request I will elucidate what are the premises that I'm using to justify that conclusion.

Mainly, as you state, because DAPI will be open to non-DCG developers allowing for stateful data storage to be leveraged by these developers, PS should be seemlessly integratable into any of these DAPPS without sacrificing any decentralization (which previous solutions would've required). I leave it up to any perusing core developers to correct any mistakes I make here, as I admit to not having deeply read the Dash code (like at all), and having only gone over the Evolution design documents and API publications.

With that being said, the premise that I believe supports the conclusion that your guess correctly points to is simply that, and correct me if I'm wrong, the two very legitimate problems/criticisms that you mentioned in your OP, namely ugly-ass and storage-heavy UI, were a necessary evil due to the limited nature of the previous (still current) Dash network. I misunderstood you originally and went into an anon-set schpeel, but I can see now I was mistaken and your concerns are more legitimate than I gave them credit for initially, were not a misunderstanding as I thought, and do need to be addressed.

As I'm sure you're aware, in order to fully fulfill the obligations and promises of DashEvolution promised to us by Evan's 2015 vision, DCG undertook a MASSIVE overhaul of the protocol. I referenced this a bit in my reply to @DeepBlue in the Dach-marketing-proposal here:

https://www.dashcentral.org/p/DACH_MARKETINGSTRATEGY_BIZDEV_Q2_20

Basically, I posited that the delays that we've seen with Evolution were actually *a good thing* resulting from a "software refactoring". As a Software Developer by profession and Computer Scientist by training, I pointed out that I am personally familiar with the reason that refactoring considerably slows development and thus release of MVPs, in many projects, not just Dash.

The reason being mostly the increase in man-hours for development, debugging, *refactoring (i.e. changing fundamental design parameters) to support these new features* and testing of all of this both individually and together via integration testing, adds considerably to the man-hours and total cost of projects. This itself is because refactors usually portend new, expansive capabilities and functionalities that were not (fully) supportable or implementable under the previous network architecture.

For example, I used both Bitcoin Cash's inability to effectively mimic privateSend due to their lacking decentralized masternode infrastructure **and the fact** that this forces them to rely on centralized mixing servers to accomplish a fraction of the same result instead, to point out the limitations in their version of coinJoin's effectiveness. These limitations make denominations, multiple rounds and everything else that Dash already does cheaply, quickly and efficiently with the click of a button very difficult to impossible to implement on their chain.

So not only can they only offer an inferior, less effective, slower (no instantSend on BCH) privacy "solution" compared to Dash's version, they also are **completely unable** to offer other things that Dash easily offers due to these protocol limitations inherited from the non-payment and-other-space nature of the original bitcoin protocol.

Things like decentralized funding and governance, and soon decentralized application calls to store data on their blockchain trustlessly and statefully. I.e. without requiring a chain-bloating update of the same data every block. Instead, they will only need to leverage the MNs to store data while still leveraging POW s.t. there are only updates when a state-change or data change is enacted.

This makes Dash's "data-contracts" stronger and more efficient than Ethereum's "smart-contracts" because Eth is focused on the wrong end of the problem developers need a solution to. While Eth is focused on providing decentralized computing power, as one of the core devs made clear in a recent blog post, what developers really need is *Decentralized Data Storage* (DSS).

The truth is, developers already have access to very cheap computers and thus vast computing power. Therefore there is little need for the "decentralized compute" that Eth provides, although it is definitely seeing use solving use-cases that couldn't be solved before for reasons that are tangential to this technical review.

Rather, developers (such as myself especially) are actually itching for something that smart-contracts almost touch but miss the mark of due to these aforementioned inefficiencies. I.e. those inefficiences that come with requiring the whole network to run a computation on the its computing infrastructure at the same time.

That as well as the propagation and validation of the results of this computation through the entire network, along with debugging and verifying the security of these computations etc.

The last one being a VERY big and crucial topic on ETH as many high profile DAPPS suffer from security and literal game-ending bugs, like the DAO in 2016 and also recently with tBTC (IIRC) having to shut down. This won't be a problem for Dash either btw because developers will be able to leverage whatever language they're comfortable with (that have API bindings, which are explained below) with all the error-checking, input and logic validation, and testing and debugging that comes with that language support.

Thus allowing developers to not only write more efficient but more secure data-contracts while still having the same or better capabilities as smart contracts.

That is the "something" I mentioned above that developers are itching for: Decentralized Data storage. I.e. the ability to cheaply, quickly and efficiently store your applications data without having to rely on centralized databases for the same.

You'll be able to write a social network application/website/whatever, for example, and instead of storing user profiles, passwords, posts, personal info, the works in a centralized database on a server you control and have to set-up and curate, **YOU AS A DEVELOPER** will be able to leverage the Masternodes and store your user data trustlessly, decentralized and cheaply on the Dash network and access it at any time privately and securely without having to manage anything else about it. **THAT IS THE GAME CHANGER THAT MAKES DASH A BLOCKCHAIN 5.0 COIN!** [1]

[1] I list the reasons why and the levels of blockchain coin development in a separate comment in a reply to this one

The point of bringing all that up, in summary, is to point out the stark contrast in capabilities between protocols that are properly developed and refactored, and those which are built on an ad-hoc basis without proper forethought for long-term incentives and countervailing network design parameters and incentives (like user incentives vs. stakeholder incentives vs miner incentives and properly balancing them).

The point of bringing *all that* up, besides fulfilling the technical review portion of your request, was to show that the refactoring necessary to make evolution scalable, totally decentralized and *solid for the long-haul*, not just for a price pump and dump, **WAS ALSO NECESSARY TO SOLVE THE PROBLEMS YOU RIGHTLY POINTED OUT IN YOUR OP**.

***********************TL;DR HERE***********************

So, in summary of the summary and to finally answer your original complaint properly, I contend that with the completion of Evolution, the problems that you mentioned, namely the requirement to download the whole blockchain and use an ugly-ass UI just to have decentralized, secure, trustless privacy, will be solved by the DAPI being leveraged by front-end devs (note not necessarily core devs) upon Evolutions mainnet release.

This is because it should make decentralized PS available to end-user-friendly Apps that even grandma can use. This is due to the fact that they will be able to easily leverage DAPI to intiate PS API calls and therefore integrate PS functionality into their much-more-user-friendly Dapps.

This is my understanding of how DAPI will function from a technical POV, and again, I'm actively calling for core team correction as far as they are allowed to discuss about this information. If it is not correct, I suspect and presume for this argument that it may take (at most) a bit of dev leg work, but it shouldn't be an insurmountable challenge, especially after reviewing the progress on language API bindings

-- which are the openly-accessible over-the-web function calls exposed to specific computer programming languages that allows developers to write APPS that connect/store data in a decentralized form since the data is stored on the blockchain via MNs(DAPPS) --

in Andy Freer's "Dash Platform Incubator" dashboard. This presumption may prove to be naive and incorrect pending core dev review, but I'm pretty certain that it works something along these lines. Which means that it should be trivial for you to:

***Continued below***
Reply
-2 points,3 years ago
1. Have PS functionality in *any* end user wallet, but more importantly on mobile and non-full node wallets easily.

2. Have PS functionality not just in "wallets" but also in any APPS period. Any app that can connect to the internet can connect to DAPI and leverage the power of 4600 masternodes should be able to enlist them for PS mixing of any including user funds. I'm presuming that this evolution mainnet release will include the ability to perform privateSend functionality. **If this is a possibility but not necessarily available or a priority upon release, I would then support your call for multiple teams to solve the issue.**

This is obviously because your concerns would then have proven to be correct and DCG would probably be overburdened by the considerable challenge fully fleshing out the Dash Network's protocol has become now that they have so broadly extended its functionality. Its a good problem to have and you are correct that multiple, strong teams is the obvious solution to it, just like parallelization

-- which is separating a single programming task into multiple subtasks to be split between multiple computer CPUs working on each separate problem at the same time. This allows for a faster and thus more efficient computation of the result, very relevant to your concerns here --

is an obvious solution to certain programming problems *but not others*.

Some problems are not sped up or are actually made worse by being parallelized. Its a tool not a panacea, like everything I guess. But, if this generally available PS functionality were a difficult thing to achieve, requiring further core development with additional DIPS to be submitted, approved and coded then yes I would concur that your initial OP's conclusion was correct. "Parallelization" or multiple dev teams fleshing out the protocol would be the ideal solution in that scenario.

And with that I conclude my reply. Yes your understanding of my response was spot on. Thank you for the discussion, thank you for your patience up until this point (I know it took a while to get here, phew!) and for the constructive dialog. I learned a thing or two just from participating.
Reply
2 points,3 years ago
The above post is out of order . I hit the comment limit below. Read the longer post below this one first and then part II is above. Thanks!

[1]**********Blockchain development levels according to me**********

1. Blockchain 1.0 - any POW chain like BTC, BCH, XMR, DGB and the like which lack the features listed in 2-5.

2. Blockchain 2.0 - any POW chain with the features of blockchain 1.0 coins, but with the additional features of decentralized governance and funding. These two features are crucial to consistent, self-determined growth. Without which your coin is very vulnerable to corporate capture or stagnation and eventual death from lack of investment. Only Dash, its forks, I think Zen and Zcoin IIRC, and Decred have this functionality that I'm aware of.

3. Blockchain 3.0 - any coin with #1 and #2, as well as support for instant on-chain transactions and privacy. With these two features, leveraged from level 2 features, Dash is true digital POW cash.

4. Blockchain 4.0 - Any blockchain that is able to trustlessly, cheaply and efficiently store data in an easily accessible format for front-end and back-end developers to leverage in the deployment of their apps in a decentralized and permissionless manner.

5. Blockchain 5.0 - Any blockchain that leverages #4 to solve the end-user facing UI and UX issues, or the "grandma problem". This includes having decentralized user names, and contacts lists with passwords and the like to provide end-users who are unfamiliar with blockchain technology all of its benefits without requiring a technical course. I.e. Dash Evolution.

This is the holy grail of cryptocurrency development because it means widespread, scalable, easily accessible and usable solutions for non-technical users. This is obviously a massive advantage which will assure our spot near or at the top for a long time to come.

This is the "List of Blockchain Development Levels" as I currently see them. I welcome all comments and especially all criticisms and critiques. Thanks for reading!
Reply
2 points,3 years ago
I upvoted and downvote your posts in kind to position them in the correct order. Really fantastic insight and I appreciate a lot of what you're saying, perhaps might be good for longevity for a version of it to be posted to reddit or the Dash forums.
Reply
1 point,3 years ago
Thank you for the assist. Yes, I would love to make a post on r/dashpay but I'm permanently banned there. Perhaps I'll post to dashuncensored instead, thank you so much for reading as I know it was a long read!
Reply
1 point,3 years ago
I'd like to speak with you further about the implications of Platform, @therealDashman21. Would you kindly reach out to me on Discord or Reddit? I'm @Amanda_B_Johnson#2262 on Discord and /u/Amanda_B_Johnson on Reddit.

Hope to hear from you soon.
Reply
0 points,3 years ago
I will be available to reach out to you shortly. However, I'm compelled to remind you that while my technical literacy is high, I have not delved deeply into the technical foundations of Evolution (busy with another project) and may not be able to provide any information that is greater than what is written here. Just so you're aware.
Reply
-1 point,3 years ago
Thanks for the feedback!

I agree, that there are multiple fields where Dash lags behind and privacy is one of those.
I think more independent (rather small) teams could really make a difference here.
And we already have a working budget system to support these teams!

> Would you agree to make developing Dash's privacy capabilities a priority after you finish your card project?

I think we'll make some kind of voting on what will be the team's next project. I would like to work on upgrading Dash in terms of privacy.
Reply
-2 points,3 years ago
If this is such a compelling use case, why hasn't Roger Ver funded the development of trustless smart-cards on a BCH wallet? I would like to see this working on BCH before we commit scarce treasury funds to this idea. I saw the demo and frankly I don't believe this can be implemented so grandma can use it.

We need to keep the devs focussed on optimizing the network, SoV changes, and Platform apps. Of course if Dash were a thousand dollars I would upvote this.
Reply
0 points,3 years ago
> why hasn't Roger Ver funded the development of trustless smart-cards on a BCH wallet?

Maybe he has. The be.cash solution has a lot of potential.

> I don't believe this can be implemented so grandma can use it.

Why do you think so? Grandma can use the regular bank contactless card. And that is card is much slower then the one we plan to implement.
Reply
0 points,3 years ago
https://www.reddit.com/r/btc/comments/dutb4f/pay_with_bitcoin_cash_using_smart_cardsto_a_cheap/f78odoo/

"The issue is that, without a screen, there is no way for the payer to truly know the amount (or payee address) they are signing...This is actually kind of a big deal. For now, Payer has to trust the app of Payee. They also have to trust Payee deletes the PIN after entered. So, face-to-face, there‘s still some trust...If Payer doesn‘t trust the app Payee uses (which we cannot ensure is reliable), we can add a somewhat trusted third party that verifies Payee...If Payee then steals money from Payer, the third party has plausible proof; and since Payee is usually a business, they don‘t wanna get sued."

IMHO the reason this does not exist on BCH is because although this SOUNDS like a good idea IT IS NOT A GOOD IDEA. It's not trustless and it's not easy to use.
Reply
1 point,3 years ago
Good points, I think there are definitely considerations here.

Some of the issues raised are mitigated by only allowing the merchant to do one transaction and having a limit on the size of that transaction to remove any incentive for the merchant to defraud the customer.

I don't see this solution as suitable for holding large amounts of Dash in, it's for smaller day-to-day hot wallet equivalent use. However as a new standard this wouldn't be limited to basic physical cards either, it can also work with offline mobile wallets and cards with screens (around $10 each), which would be completely trustless.
Reply
-1 point,3 years ago
In that case it would be easier to simply put an actual private key on a little piece of paper or a smart-card. The merchant can sweep the funds from the associated wallet and give the customer change in the local currency.

Another benefit of the above approach is that it does not require any Estonians.
Reply
1 point,3 years ago
We can use a card with a little screen that displays the amount and one button to confirm the transaction.
We are not going to to this at first, but there are multiple ways to make this more secure and reliable.
Reply
0 points,3 years ago
So you've got all the drawbacks of credit cards (i.e., "Here is my info mister merchant please don't steal from me.") and none of the benefits of a credit card. At least with the credit card you can call them up and cancel a fraudulent transaction.
Reply
1 point,3 years ago
The easiest way is to have reasonable limits on the card. So the merchant has no incentive to get a really negative review with a blockchain proof for few dollars.
Reply
2 points,3 years ago
Congratulations! I look forward to seeing your improved cards proliferate throughout the ecosystem. Good luck!
Reply
1 point,3 years ago
Thanks! :)
Reply
-1 point,3 years ago
Well deserved.
Reply
2 points,3 years ago
Don't give up. If you are sure in your project, then create a new proposal. I believe I like your project.
Reply
2 points,3 years ago
Agree, I really hope the DAO's prickly edges don't keep talent like mart and his team from joining the developer community
Reply
1 point,3 years ago
Thanks for your support!

There is a lot of backing, even Dash CTO wrote to me "We appreciate your vision in implementing this solution for Dash and look forward to further definition."

But it's hard to keep the team without funding, so we may need take a side project meanwhile.
Reply
0 points,3 years ago
I believe you will pass. Good luck.
Reply
1 point,3 years ago
How persons Ash Francis (Dash Retail) and Tobias Ruck can confirm that you are working in cooperation?
Reply
0 points,3 years ago
Ash already wrote here;
you can ask Tobias: /u/eyeofpython (reddit) or https://twitter.com/TobiasRuck.
Reply
2 points,3 years ago
I can confirm, it's unfortunate this isn't passing but I understand the DAOs hesitation. This team are capable though and there is a good demand for dash cards, making them trustless just makes sense.

From my perspective, we can prove this use case with custodial dash cards first and then circle back round to the trustless ones, though it would have been nice to use trustless cards out the gate.

If anyone has any particular hesitation points I'm happy to discuss them as I do think the cards would offer significant benefit to Dash users and make Dash more accessible.
Reply
0 points,3 years ago
How long you are working in crypto?
Reply
0 points,3 years ago
I have created solutions based on cryptocurrencies since 2011.
From 2017 I started to play more with cryptos themselves -- like cloning, modifying and such.
Reply
1 point,3 years ago
I would like to have more background details on this team. We don't know much about them at the moment and I think it would be unreasonable to vote in a team without having this background information -especially when it comes to coding for the network. A video introduction would also be helpful to get some idea who the team and are what they are about.

I definitely feel that TrustLess NFC cards are required and would be a very valuable asset for the network. Currently the DASH retail cards are not trustless ie. the card holder still needs to trust Dash Retail. A lot of development work would be required to create trustless cards i.e. when the person holding the card has complete control and ownership of their funds. It would new DIPs to be written to enable this functionality something an independent team could develop.
Reply
1 point,3 years ago
How does this offering compare with the cards already developed by Dash Retail and Dash Mall and Parking in Venezuela?
Reply
1 point,3 years ago
Those cards (Dash Retail and Dash Mall and Parking in Venezuela) do not contain your Dash private keys. They are just used for authentication and always need a special intermediary. The cards used by be.cash store the private keys and the card signs the transaction during the NFC payment. So the merchant only needs to broadcast this transaction. This is fundamentally better.
Reply
3 points,3 years ago
Guys cmon, this is a realization of the promises that our unique funding model allows. It would be an absolute tragedy if this were to not receive funding
Reply
2 points,3 years ago
If DCG is not going to put in more than a 60% ask of funds, I am onboard with other teams picking up some of the work on the protocol, if it provides value to the network. Ash makes a strong point about smart cards, this is a yes for me.
Reply
0 points,3 years ago
After talking with Yoanna via DM, she reached out to me, she has responded to my question regarding revenue models and reinvestment plan and am now in favor of keeping funding going. This is what I look for.
Reply
0 points,3 years ago
sorry, wrong PO
Reply
1 point,3 years ago
For a smartcard offline solution check out blochstech.com. The guy made the whole thing open source.
Reply
3 points,3 years ago
Thanks for that link.
We think our solution is technologically better.

The way these (blochstech.com) cards work is that they stores the UTXOs on the card, and when a payment is made, they take a couple of these UTXOs, build a transaction, and sign it. Then, they update the UTXO set.

There are a couple of problems with this approach, the first one is that you cannot pair the card with a phone wallet, and they have to remain separate. This is because the card always has to know the UTXOs, and a phone wallet would create UTXOs the cards couldn’t possibly know of. We believe that this is unacceptable UX.

The second problem is that the card has to be synchronized with the Internet again if the merchant fails to broadcast the transaction signed by the card. This can be mitigated somewhat with technical solutions, but it can happen that the card would be bricked temporarily if the merchant fails to broadcast the transaction, if not mitigated properly. Again, we believe that this is unacceptable UX.

The solution we try to implement does not have these issues. It does not store the UTXOs but uses a smart contract to allow redeeming of the money by the merchant. Multiple devices can sign payments for one UTXO without interfering with each other. Also, if the merchant fails to broadcast the transaction they will lose money, but the card will remain fully functional.

The blochstech.com cards are also slower.
Reply
3 points,3 years ago
@mart could you clarify a few points:

1. you mention "Salaries" at 3000 euro / month. How many people will be working for this salary? How many hours / month per person will be working for this per month.

2. Estonian Taxes added to salaries - 2205 . Are you saying therefore Salaries (including Tax) would be 5202 per month?

3. What previous contacts / association have you and your team members have you had with the DASH project - could you list them out.

4. Why Dash and not another coin?

5. How do you know Ash Frances? Could Ash Frances post something here about what you're thoughts are about this team working on your POS cards.

6. Ash Frances has agreed to sign over a license of IP rights to DCG for his software and hardware devices. Will your team also ensure to have a license agreement to ensure the software you develop may be used by DCG and the DAO.
Reply
3 points,3 years ago
Thanks for meaningful questions!

> 1. you mention "Salaries" at 3000 euro / month. How many people will be working for this salary? How many hours / month per person will be working for this per month.

This project is my main focus. I'll work 20-30 hours / week.
My coworker does PhD studies at the same time and works with this 10-15 hours / week.
Plus a professional C/C++ guy doing how much we need him: maybe 5-10 hours / week.
I will publish the exact working hours and payments in the end of every month.

> 2. Estonian Taxes added to salaries - 2205 . Are you saying therefore Salaries (including Tax) would be 5202 per month?

Yes. The taxes on salaries are quite high in here. Could do without and just cash out without taxes, but I want to keep it official and transparent.
I think in longer term it's much better to play fair with the country you do business in.

> 3. What previous contacts / association have you and your team members have you had with the DASH project - could you list them out.

We have been following Dash for years -- played with the code; cloning; testnet; mining etc.
But despite our interest in Dash we didn't find a good way to contribute so far. This proposal is our first try :)

> 4. Why Dash and not another coin?

I started with Bitcoin in around 2010. Somewhere 2016 I realized the project has drifted far from the original ideas. So I was looking for the project that still carries these original Bitcoin ideas and that's how I ended up in Dash.

> 5. How do you know Ash Frances? Could Ash Frances post something here about what you're thoughts are about this team working on your POS cards.

Actually I saw him in Dash Convention that took place in Zurich last year. But we started to cooperate recently as Ash also described in comments here.

> 6. Ash Frances has agreed to sign over a license of IP rights to DCG for his software and hardware devices. Will your team also ensure to have a license agreement to ensure the software you develop may be used by DCG and the DAO.

We would like to open source the software and hardware we do. If DCG would like something different then we're ready to negotiate.
Reply
1 point,3 years ago
How many weeks do you expect would be required to create the functionality for the trust-less DASH cards? And how would we be able to monitor your progress? Bear in mind you are a new team with no track record yet with DASH.

My view is we need these DASH trust-less cards for Dash Mall and Parking project but also for all other projects that need the trust-less DASH cards. They would be like a debit card for DASH making it accessible to millions of people who are afraid of the tech. This would make DASH truly accessible to millions of people - true digital cash.

I would like to see more teams like this that can build out DIPs that would boost DASH business Dev, not just the core protocol. DCG can get on with the protocol and teams like this could build essential functions to make DASH more useful for users and businesses. I would also like to see a true DASH stable coin which I discuss here: This DASH twin coin would be more stable than USD and Euro and would result in the Dash transaction coin (our current coin) going up in value because to create Dash stable businesses would need o stake Dash Transaction coin. Businesses need stability and this new coin could provide that for merchants. But not only that for pension funds that need to maintain the value over many decades. That would not be possible with USD or Euro but would be possible with Dash Stable because it would be locked against the price of 76,000 items used in everyday life.

https://www.dash.org/forum/threads/what-dash-needs-to-set-it-above-all-other-cryptos.43036/
Reply
1 point,3 years ago
> How many weeks do you expect would be required to create the functionality for the trust-less DASH cards?

We want to have a specification and working prototype by the end of second month. Is is hard to estimate exactly.

> And how would we be able to monitor your progress? Bear in mind you are a new team with no track record yet with DASH.

I'll start a blog about our progress. I'll also publish a development summary once a month.

> My view is we need these DASH trust-less cards for Dash Mall and Parking project but also for all other projects that need the trust-less DASH cards.

I totally agree. We try to design the solution so that it would be very easy to add to existing projects.

> https://www.dash.org/forum/threads/what-dash-needs-to-set-it-above-all-other-cryptos.43036/

Very interesting idea. Being integrated with current Dash and wallets could make it very useful.
Reply
4 points,3 years ago
Thanks for the mention, as soon as I saw the concept for this proposal on Nexus I reached out to Mart and we've spoken several times since. I'm very supportive; they have a really strong understanding of why we need trustless cards and how to get there along with the technical capability to make that a reality.

It's my understanding that this will be first proposed as a DIP and all work on it will be open source (as it's a trustless solution it has to be!). A large portion of the work involved in this is actually improving the protocol to support it, as such a lot of their work will be on the core protocol itself rather than on the smart cards.

Some keys bits I would want to make clear to the DAO:

- This team is complimentary to DCG; they are not in competition as DCG has the 60% cap.

- Their costs are very reasonable for the talent and this project gives them a great foundation to demonstrate a huge amount of value.

- As this will be open source (DIPs + improvements to core protocol + reference card library & card 'standard' creation), other developers can contribute to and help refine this and the DAO is not kept over a barrel as another team could take over the work if they failed in their responsibilities.

For whatever it's worth, I've personally offered to pay (from my savings, NOT treasury funds) for them to do some of the research into the scope and write a more detailed project specification if this doesn't get funded so that they can return to the DAO with more informed timelines / milestones. This is an essential project in my view and whether this team or another team does it; it has to be done. I could harp on about how important trustless Dash cards can be for Dash but some top-level points:

- For ~$0.05 we can bank someone who is unbanked (which is a large portion of the world population).
- They don't have to have a phone or even a smartphone.
- Absolutely anyone, anywhere can tap a piece of plastic against a reader (crypto for your grandma).
- They work completely offline (merchant needs somewhat regular internet though)
- They can be extended in a ton of ways (pin protection, daily / known recipient based spend limits, username based payment, approved merchants, p2p payments through smart phones / devices, 2FA, zero knowledge proofs, age verification, etc.)

Dash is also absolutely perfect for smart card use:
- It's instant, so merchant has absolute confidence in payment received making this great for loads of industries (far better than CC)
- We have platform which will extend the capabilities of these cards hugely
- It's bitcoin based (to an extent) which means porting over the already functioning trustless NFC from BCH will be significantly easier
- We're focused on payments, which cards are perfect for.

There are definitely limitations of trustless Dash tap cards, but there is a huge use case and I'm really keen to see them become a reality and I believe this team is capable of making that happen.
Reply
4 points,3 years ago
Extremely excited by this proposal, having more than one development team has been a pipe dream of mine since the beginning of the DAO, very happy to vote yes on this
Reply
2 points,3 years ago
Yeah! I'm in the exact same boat.
Reply
1 point,3 years ago
Would this team be interested to build an in-wallet hedging button based on the DEBNK whitepaper?
Reply
1 point,3 years ago
We are open to all kinds of ideas. But we start with the offline smart-card solution first.
Reply
-1 point,3 years ago
This group lists "forking Dash" as one of their services, and they may intend to use any funds we give them to create a fork of our coin...

https://www.dash.org/forum/threads/proposal-start-of-an-independent-dash-development-team-in-estonia.49939/

I strongly advise against funding this proposal. We may be looking at a trojan horse.
Reply
0 points,3 years ago
The project "CoinBakery" (https://coinbakery.io/) has finished about a year ago.
I listed that just to prove that we been in the field and know the technology.
I'll also take down that site in few months.
Reply
0 points,3 years ago
It's sad you receive downvotes while proposals without concrete deliverables by deranged farmers are doing better.
Reply
4 points,3 years ago
Voting yes, independent teams doesn't mean contrary teams. I'm certain Mangus and his team will add a lot to the ecosystem and fresh ideas. He is correct, we should have as many developers using the Dash ecosystem as possible. I also like the concept of his first project. It will make Dash more portable where there is no internet, there is no problem. Of course, the merchant will need to be connected, but not the customer. This would be super usefull for impoverished locations, or even as a backup say, if you lost your phone. Don't tell me that never happens!!
Reply
3 points,3 years ago
I don't think this is the right time to start funding other development teams, when we can't even fully fund our current development team. We currently have developers working who voluntarily agreed on cuts on their pay or who are basically working for free.

Feels weird to start funding other development teams then, taking into account this situation.

Lets first make sure all our current development team members are getting the full pay they deserve, before contracting additional development teams.
Reply
9 points,3 years ago
As a dev who takes a paycut when the price of Dash is under our run rate I really prefer having a thriving ecosystem than my full salary. On a further note Dash Core has a max percentage of the budget that we ask for, so this passing or not passing won't have any impact on the amount of capital that will go to pay devs in Core.

Another tech lead who's name I'll keep anonymous highlighted a negative aspect of our governance system last year to me. Since we have a governance system devs are expected to use it for funding (as I do think it should be used), but it's pretty daunting to do so, so many just have a barrier getting in. And I must say since last year most dev proposals have not been passing and devs don't know how to contribute. I really hope we reverse this trend so we can fuel people who are excited to come innovate on our project.
Reply
-1 point,3 years ago
This might sound like a strange question, but here goes...

Can you tell us if Saava Kerdemelidis or Andreiko Kerdemelidis is involved with your project in any way Mart?
Reply
0 points,3 years ago
No. I don't even know these people.
Reply
6 points,3 years ago
Voting a strong yes, more devs that want to write DIPS are a great thing.
Reply
1 point,3 years ago
Yeah, thanks! :)
Reply
1 point,3 years ago
https://www.youtube.com/watch?v=Vhh_GeBPOhs
Yes!
Reply
2 points,3 years ago
:D
Reply
-1 point,3 years ago
I'm going to say no. The protocol is Dash's crown jewels and we already have a roadmap. This effort would need to be coordinated with and approved by DCG CTO.

Do you folks have resumes we could look at? Linked in accounts?
Reply
0 points,3 years ago
> This effort would need to be coordinated with and approved by DCG CTO.

Bob Carroll (Dash CTO) wrote to me in an e-mail:

> We appreciate your vision in implementing this solution for Dash and look forward to further definition.
Reply
7 points,3 years ago
Just because they do work, doesn't mean it will be merged in, Bitcoin has something like 100 small teams, some with successes but not all. Open source is not about 1 team and 1 vision, it's about being open to new ideas. More good devs will help us 100 times more than any other investments at this point.
Reply
3 points,3 years ago
> The protocol is Dash's crown jewels and we already have a roadmap.
Could you please link that roadmap?
We will investigate an alternative solution with Evonet also.
Reply
1 point,3 years ago
https://www.dash.org/roadmap/
Reply
2 points,3 years ago
So we have coming "2020: Bitcoin v0.16 backports" where we change the core anyway. Those new opcodes would perfectly fit with that update.

Sure we need to have discussions about those before.
Reply
3 points,3 years ago
> This effort would need to be coordinated with and approved by DCG CTO.
Sure we will sync our work with DCG. The discussions around the DIP would be a good ground for better software.

> Do you folks have resumes we could look at?
I listed recent and meaningful doings in the proposal under "Our team"

> Linked in accounts?
Sorry, been quite antisocial in internet.
Reply
-1 point,3 years ago
Your website says the following:

"Soon we will be launching a coin with an innovative vision to unite people and create a community across the world. Stay tuned for more info."

Can you tell us about this? This sounds like quite an endeavor. How do we know you won't take our money and simply use it on your own project?
Reply
0 points,3 years ago
> Can you tell us about this?
Sure. We launched a coin for advertising our company. It was called GhettoCoin. It's discontinued now.

> How do we know you won't take our money and simply use it on your own project?
If you think I would like to ruin my reputation and name in Dash community for around 6000€ then you have simply misunderstood this effort.
Reply