DASH Business Development Strategy Update - FEB 2017

[Minotaur]

Climbing the Blockchain Adoption Ladder

Dear Dash investor,

We are in the process of securing one of our most important partnerships to date from an adoption and business development perspective and we need your support to complete it.

Background

In order to understand the significance we must provide some background on the industry as a whole. Dash’s business development team spends considerable time understanding the business needs of industry participants and building an understanding of the structure of the industry. Through our engagement with both existing partners and prospects, we’ve developed a deep organization-wide understanding of the drivers for business development in the industry. To illustrate our perspective we developed a concept we are calling the “Blockchain Industry Adoption Ladder”:

Level 1 – Core Development / Blockchain Payment Network


All new cryptocurrency advancements are born at level 1, the core development level, and thus we focus a large amount of Dash resources here. Without creating new value for the industry, merchants, and users, there is little sense in building and promoting a new digital currency network.

We create features like InstantSend, PrivateSend, Masternodes, and Evolution to differentiate our network and deliver functionality to address market needs. While these features are innovative and exciting for the future of Dash and the industry, they can’t really reach end-user adoption without climbing the adoption ladder first.

In Dash, we are experimenting at the protocol level in innovative ways but we are also defining a clear path for adoption of our network and its features that should help us climb the blockchain industry ladder as described above in figure 1.

We are also making sure we align our technical developments with the business needs of the market by creating tools and services that are necessary for real commercial adoption of Dash in the blockchain start-up environment.


Level 2 - Blockchain Interfacing Tools


The next step up the adoption ladder is creating appropriate blockchain interfacing tools so that industry actors can plug into the Dash blockchain more easily. Dash decided to build a network that was compatible with the currently dominating protocol (BTC) so that it could benefit from the network effects we are all creating as an industry. We avoid going into protocol development directions that would make Dash incompatible with the more popular blockchain interfacing tools available and decided to build towards the current blockchain industry instead of away from it. Most of the differences with our protocol such as InstantSend are simply additional features with incremental tools.

Last year there was a strong focus on this by porting all important tools and libraries that make integration into the Dash network easier. Including bringing some of Dash’s unique features like Instant Send to this level. We now have libraries and tools updated for Dash that make life easier for services that want to interact with the DASH blockchain e.g. multicoin wallets, mobile wallets, multisig and spv based services.


As an example,

Insight API (along with the rest of the Bitcore platform) has been ported to Dash:

https://github.com/dashpay/bitcore-dash

https://github.com/dashpay/insight-api-dash

https://github.com/TradeGuild/trade-manager

https://github.com/WalletGuild/desw


InstantSend is fully supported by Insight API / Bitcore:


● InstantSend Whitepaper

● Insight API Integration


Without this layer, it would be much more difficult and costly for businesses like multi-blockchain wallets to integrate with the blockchain protocol layer. Also, added value user features like InstantSend that are born at the protocol level need to climb the adoption ladder in order to really become available for end users.


The “blockchain interfacing tools” level is where Dash has operated until now. Even at this level, integration with new services is not a trivial exercise for many businesses, especially those that are outside the cryptocurrecy industry and lack associated expertise. For example, these integrations typically require hosting full nodes and other associated infrastructure with which these businesses lack expertise. Several well-intentioned partnerships have been delayed due to these implementation challenges.


Level 3 - BLOCKCHAIN B2B API WEB SERVICES


The blockchain industry is rapidly evolving from a business perspective and it is very important for the future of Dash to stay aware of how blockchain start-ups and B2B services are interacting with each other and the interdependencies they have to produce user-oriented services that will lead digital currencies to the mainstream. B2B services are frequently a gateway to accessing these user-oriented services.

Through the years we have been focusing more and more in our business development efforts. This fall, we surveyed the entire landscape of the existing ecosystem and developed a targeted strategy for buildout of Dash’s integrations. This will shift Dash from reacting to opportunities to proactively driving adoption in an intentional and prioritized manner. Recently, we began aggressively approaching end user service providers with our unique value proposition, and asking them to start accepting Dash for their service. This has included exchanges, gift card selling services, cell phone top up services, US based debit cards, crypto-gold exchanges, brokers, etc.

The reaction has been very positive. We are quite successful in getting many of these user services to say “yes” to Dash. Once they agree from a business perspective to integrate Dash, we next need to evaluate the mechanics of integration. That is where challenges frequently arise, because up until now we have had no blockchain API web services available. There is an important reason why this is an issue: most of the crypto user oriented services are not running their own bitcoind or Bitcoin Core. Almost all are using 3rd party API web services to handle all the interaction with the Bitcoin blockchain, to a higher or lower degree, depending on the nature of their service. This includes most of the brand name start-ups in the industry.

This constitutes a glass ceiling for altcoin projects other than Bitcoin and Ethereum. The only services that altcoins can aspire to without this 3rd party Blockchain web service providers are those that by the nature of their business benefit from adding multiple currencies. This is only exchanges and multi-coin wallets. No other mainstream user oriented service is going to go through the hassle of running altcoin infrastructure when they are not even doing it for Bitcoin and most lack the internal resources and expertise to do so.


Who are the 3rd party Blockchain web services infrastructure providers that are servicing the whole industry?


There are two companies that constitute the vast majority of the market share for these API services. They are both VC funded, larger type start-ups out of California: Bitgo.com and Blockcypher.com


SOLUTION

We have been looking for a solution to this issue in depth for the past few weeks. It has been part of many of our conversations in our weekly team calls. We have evaluated many options to address this need, including the existing service providers, or even running our own service.


Running an internal service carries many risks. It would expose Dash’s network to reputational risk should any downtime to service level issues be encountered by our API service. It would distract the team from focusing on development of our payment network itself.


We have contacted both Bitgo and Blockcypher and we are actively negotiating a mutually beneficial arrangement. We believe that an integration with an existing provider offers many benefits beyond the availability of the service itself in the form of (i) reputational gains of joining Bitcoin and Ethereum as the only networks integrated with one of these brand-name services, (ii) potential to integrate Dash into existing customers (e.g., cross-selling) without changing technical architecture, (iii) faster time to market with an API solution, (iv) service provider preference to work with a single established API vendor, and (v) offering market-leading expertise compared with building our own solution from scratch.


At this time, we are nearing an agreement with BlockCypher and should be able to announce the details soon.


Who is using Blockcypher?


Just to give you an idea of how important these 3rd party API Web services providers, here are some of Blockcypher’s clients: Purse.io, Xapo, Coinbase, Verse, Bitrefill, Sfox, Shocard, KeepKey, Meco, Shapeshift, Fold, Blinktrade, Joystream, Coinify, Coinhako, Netki, Coinprism, Vaultoro, Bitkassa, Abra, Bitquick, Deloitte, Bitpagos, Quid, Volabit, Mexbt, BTCfacil, Bitwage, Coineza, Coinjar, Paxful, OKCoin, Paystand and many more.

Those are only some of the ones publicly displayed on their website, there are actually a lot more that are not featured and others that work with Bitgo.


What would Blockcypher start offering for Dash accepting services?


BlockCypher will integrate with the Dash Payment Network and provide the following web services:


● Asset API - issue & handle assets on the blockchain

● Data Endpoint - place data or a hash on a blockchain

● Multiple Address Wallet API - multiple addresses under single wallet name

● Multisignature API - multiple signature key management

● Payment Forwarding API - forward, consolidate, add commissions to payments

● Transaction API - build transactions easily

● WebHooks and WebSockets - monitoring & notifications on blockchain events


BlockCypher will support the current fork of Bitcoin 12.0 for Dash v. 0.12.1. Additional support for Masternodes (and InstantSend) are not part of this proposal and will be considered at a later time and will be driven based on BlockCypher’s business customer demand.


What else is part of the partnership?


Part of the requirements for this to happen go beyond just covering the integrations costs. We would be going into a more in-depth partnership where our bizdev team would be selling together with the BlockCypher team in all the opportunities that we have accumulated that were missing an API Blockchain Web service provider. So a lot of our focus going forward from a sales perspective would be bringing the BlockCypher team to help implement once a new potential user service says yes to Dash. This should also help offload some of our internal resources, so the business team needs less direct support from Evolution developers.


The second part of the strategy is for us to approach BlockCypher’s existing clients so they can start accepting Dash. Accepting Dash would become a much easier process for the clients since it would just be extending the setup they already have for Bitcoin. We believe this is a superior strategy than expecting the brand name start-ups to go out of their way to start running Dash-specific infrastructure they are simply not running for Bitcoin directly.


Finally, BlockCypher is also requesting a commitment from Dash to participate in conferences and events together. For now a tentative calendar could be:


Attendance (with session) and booth at the following conferences, providing BlockCypher with a pass:

○ Blockchain 360, Santa Clara, May 16-18

○ Consensus, New York, May 22-24

○ Money 2020, Las Vegas, October 22-25


What are the costs of the investment?

Our director of finance will be putting a proposal out soon as part of the normal budget cycle with all the details of the funding requirements to finance the integrations costs and making this service available to the Dash ecosystem. Costs will be comparable to other significant integration efforts we’ve funded in the past.


What do we need from the Dash community?

What we need from you is mainly committing the time to learn about the industry’s underlying structure (which by reading this post you can fulfill), and of course providing your buy-in and support for the associated proposal. Also, please check out the Blockcypher.com website and get a bit familiar with what they do and the clients they serve.

Finally, I would strongly recommend listening to this interview with Catheryne Nicholson, CEO of Blockcypher. The interview is from March 2015 but if you listen for 15 mins it will give you a much better understanding of why this is important for us.

LEVEL 4 - BLOCKCHAIN END-USER SERVICES

We already have a number of end-user services that have agreed to add Dash, and once we have resolved the absence of a level 3 service through our Blockcypher partnership, we will focus first on initiating and completing the backlog of integrations where this was a road block.

Immediately after this we will start approaching new opportunities, but now with a complete solution that should allow any interested service that we encounter to complete a Dash integration in a easy, seamless, and cost effective manner.



NEW DASH TEAM MEMBER

Our project keeps growing and we would like to welcome Matthew Meek to the business development team. Matthew is working closely with me and has greatly expanded our business development capacity.

Matt (AKA itscrazybro) is a entrepreneur with a flare for business, marketing and sales. He co-founded an advertising agency that now services over 200 local businesses in his area. He has multiple years experience in sales, business development and product management.


[email protected]

 

[bhkien]

Very exciting!

Thanks a lot for your efforts.

 

[oaxaca]

Background - In my opinion, Dash's killer feature is Instantsend. The above description of the proposed Blockcypher Integration states: "Additional support for Masternodes (and InstantSend) are not part of this proposal and will be considered at a later time and will be driven based on BlockCypher’s business customer demand." Blockcypher offers a competing technology for Instantsend which they call "Microtransaction API" which is based on their witchcraft based tech called "confidence factor" https://www.blockcypher.com/dev/bitcoin/#confidence-factor .

Question - Why would Blockcypher even mention, let alone push Instantsend to their customer base when it would crush one of their cornerstone products?

 

[Solarminer]

This just shows how out of touch these proposals are. You have got to be kidding! (Don't forget this is the same creator of the proposal with software for non-Lamassu machines that went nowhere)

Additional support for Masternodes (and InstantSend) are not part of this proposal and will be considered at a later time and will be driven based on BlockCypher’s business customer demand.​

What is the point of any business switching to Dash if there is no InstantSend support? Right, zero. They would be much better off accepting Litecoin since they have an Apple approved wallet. And there will be Zero demand for Dash in the future without InstantSend support.

Any guesses how much this will cost? I'll guess 3 months of 3000 Dash?

Instead of focusing on this imaginary business to business need. Dash only has a few hundred transactions a day - about the same as one person mixing per day. What business will give it a second look? Instead build some great mobile wallets that can actually be used by users. Get one on the app store, get the InstantSend fixed on the android wallet and make Dash useful.

Edit: BTW, I didn't see Oaxaca's post before writing this. Oaxaca has a good point too.

 

[Walter]

Background - In my opinion, Dash's killer feature is Instantsend. The above description of the proposed Blockcypher Integration states: "Additional support for Masternodes (and InstantSend) are not part of this proposal and will be considered at a later time and will be driven based on BlockCypher’s business customer demand." Blockcypher offers a competing technology for Instantsend which they call "Microtransaction API" which is based on their witchcraft based tech called "confidence factor"
Question - Why would Blockcypher even mention, let alone push Instantsend to their customer base when it would crush one of their cornerstone products?

That's a legitimate question to be fair.. There will be no incentive at all for Blockcypher to embrace instantsend if they're making money from their own proprietary tech?

Having said that, they do make the following disclaimer clear on their website:

"While we stand by our work behind our confidence research, please note that these measures are ultimately mitigation strategies if you need fast transaction confirmations. There’s always an appreciable risk when accepting unconfirmed transactions, and there’s no truly bulletproof way to secure unconfirmed transactions. Double spending attacks, while extremely unlikely, can still occur. Blockchain confirmations ultimately provide the highest level of security, especially when dealing with higher value addresses."

Sounds to me like they don't have anything that can truly compete with Instantsend, so I'm not sure how much of a threat this will be.. In any case, it's much easier to push through more advanced features once you have a 'foot in the door' of a lot of these organisations.

From my own experience in business, it makes complete sense to take things slowly in any partnership, and this is no different. Be careful who you get into bed with is the motto that comes to mind! Once the relationship develops and trust is established then tighter integration and further developments will come naturally. It won't happen at all though if you don't open the door in the first place.


Walter

 

[David]

This just shows how out of touch these proposals are. You have got to be kidding! (Don't forget this is the same creator of the proposal with software for non-Lamassu machines that went nowhere)

Additional support for Masternodes (and InstantSend) are not part of this proposal and will be considered at a later time and will be driven based on BlockCypher’s business customer demand.​

What is the point of any business switching to Dash if there is no InstantSend support? Right, zero. They would be much better off accepting Litecoin since they have an Apple approved wallet. And there will be Zero demand for Dash in the future without InstantSend support.

Any guesses how much this will cost? I'll guess 3 months of 3000 Dash?

Instead of focusing on this imaginary business to business need. Dash only has a few hundred transactions a day - about the same as one person mixing per day. What business will give it a second look? Instead build some great mobile wallets that can actually be used by users. Get one on the app store, get the InstantSend fixed on the android wallet and make Dash useful.

Edit: BTW, I didn't see Oaxaca's post before writing this. Oaxaca has a good point too.

As usual, you are absolutely right -- we definitely shouldn't make any effort to reach out to businesses unless they immediately support ALL of our features. Forget incremental growth--it's all or nothing, baby!

P.S. Did you ever get around to refunding the network all that money that we paid you to create the Dash Slack channel that you later rebranded and refused to relinquish control over?

 

[Solarminer]

As usual, you are absolutely right -- we definitely shouldn't make any effort to reach out to businesses unless they immediately support ALL of our features. Forget incremental growth--it's all or nothing, baby!

P.S. Did you ever get around to refunding the network all that money that we paid you to create the Dash Slack channel that you later rebranded and refused to relinquish control over?

Yeah, this is a pretty telling part of a partnership if InstantSend isn't even part of the deal. It would be like saying we can help you with those instant payments - but lets add that part in 10 years when someone else will do it better. The time is now. Otherwise, the entire proposal is just for these guys to accept a bitclone with a few hours of work and make some money doing it. There is no advantage to Dash to work like this. The advantage is when Dash can show how InstantSend is actually useful! You get free marketing when a company like this is using InstantSend.

David, How about you refund your portion of the core payments to the masternodes because you are wasting your time on stupid comments like this. I don't even own the slack anymore. Do you return a rental car or claim it is yours because you paid a portion of maintenance? A few people were part of the Dash 8% instamine in a few days, are you one of them? If not, then you should be careful. Yidakee was fired last year after harassing people on the forum....watch yourself.

 

[Solarminer]

Yeah, this is a pretty telling part of a partnership if InstantSend isn't even part of the deal. It would be like saying we can help you with those instant payments - but lets add that part in 10 years when someone else will do it better. The time is now. Otherwise, the entire proposal is just for these guys to accept a bitclone with a few hours of work and make some money doing it. There is no advantage to Dash to work like this. The advantage is when Dash can show how InstantSend is actually useful! You get free marketing when a company like this is using InstantSend.

Maybe you guys don't understand Trolling. A critical comment about a project or about Dash is not Trolling. And being one of the 5 concern trolls or 5 guys is not trolling either.

Here is the definition of trolling:
"Someone who posts inflammatory, extraneous, or off-topic messages in an online community, such as a forum, chat room, or blog, with the primary intent of provoking readers into an emotional response or of otherwise disrupting normal on-topic discussion.”

 

[Solarminer]

David, How about you refund your portion of the core payments to the masternodes because you are wasting your time on stupid comments like this. I don't even own the slack anymore. Do you return a rental car or claim it is yours because you paid a portion of maintenance? A few people were part of the Dash 8% instamine in a few days, are you one of them? If not, then you should be careful. Yidakee was fired last year after harassing people on the forum....watch yourself.

This part....ok maybe that was trolling. So feel free to mark this trolling again.

 

[slamdunk]

Isn't there an important distinction between InstantSend, which is part of the DASH protocol, and BitCypher's confidence factor, which seems to me not only more subjective, but also requiring an additional layer? If that distinction were valid and InstantSend were superior, couldn't partnering with BlockCypher be almost a "Trojan Horse" for getting InstantSend into play?

Just thinking out loud...

 

[TroyDASH]

Yeah, this is a pretty telling part of a partnership if InstantSend isn't even part of the deal. It would be like saying we can help you with those instant payments - but lets add that part in 10 years when someone else will do it better. The time is now. Otherwise, the entire proposal is just for these guys to accept a bitclone with a few hours of work and make some money doing it. There is no advantage to Dash to work like this. The advantage is when Dash can show how InstantSend is actually useful! You get free marketing when a company like this is using InstantSend.

The fact that InstantSend is not part of the deal is "telling"? Be direct. What does it tell?
Then we can make an informed assessment about whether you're trolling or giving constructive feedback

 

[Solarminer]

The fact that InstantSend is not part of the deal is "telling"? Be direct. What does it tell?
Then we can make an informed assessment about whether you're trolling or giving constructive feedback

Really, you don't see any benefit to pushing InstantSend? It is the only user feature that sets Dash apart from the Bitclones.

The non-Lamassu ATM proposal could have had easy advertising with InstantSend, but instead that opportunity was wasted because InstantSend was forgot about. The dashvend code is already done and there is really no excuse not to include it.

 

[TroyDASH]

Really, you don't see any benefit to pushing InstantSend? It is the only user feature that sets Dash apart from the Bitclones.

The non-Lamassu ATM proposal could have had easy advertising with InstantSend, but instead that opportunity was wasted because InstantSend was forgot about. The dashvend code is already done and there is really no excuse not to include it.

If the company says "We're not ready to put resources into this yet, but we'll gladly begin a business relationship with you by starting with your more standard features, otherwise no deal" -- that would be a reason not to include it. If you can find another company with a comparable impact to Blockcypher, who IS willing to do everything Blockcypher is offering *plus* a commitment to InstantSend right off the bat, I would be all ears.

 

[TanteStefana]

Background - In my opinion, Dash's killer feature is Instantsend. The above description of the proposed Blockcypher Integration states: "Additional support for Masternodes (and InstantSend) are not part of this proposal and will be considered at a later time and will be driven based on BlockCypher’s business customer demand." Blockcypher offers a competing technology for Instantsend which they call "Microtransaction API" which is based on their witchcraft based tech called "confidence factor" https://www.blockcypher.com/dev/bitcoin/#confidence-factor .

Question - Why would Blockcypher even mention, let alone push Instantsend to their customer base when it would crush one of their cornerstone products?

True this looks like a conflict of interest however instant send requires no risk. Regardless we need services like this to expand the use of Dash. As long as this is not the only company that we work with, I don't see a problem. However I am right there with you and thinking that instant send is woefully underutilized. the question here is; should it stop us from working with these people? I think that we really need to push our expansion and this think we need to start working with other people even when it's not entirely on our terms.

 

[oaxaca]

I'm not saying don't do the deal. It sounds like a winner, and I'll probably vote for it. That's not my point. How many times do we have to hear "InstantSend will come later, just let us get this (fill in the blank) done first". It's the killer app for all of crypto adoption.

 

[TanteStefana]

@oaxaca I agree. I think maybe people are afraid it's not secure? We need to get Dash fully vetted on all grounds if possible.

One question I have regarding this type of partnership is, wasn't this supposed to be what the DAPI is supposed to do for projects? Not that I'm against getting things started earlier, but if this is the type of service that our DAPI was supposed to provide, I do hope we will not give up on it because we're going with a centralized service.?. Like I said, our DAPI is going to be a while, so partnering up with other services is fine with me. I just would like to know if this is what is happening.

IMO, we have to push for volume and price to become a viable payment system. Using all means available to us, even if they're duplicates of our plans is not a problem for me as long as we don't promise never to compete with our partner's services. And I can see a partnership like this still growing after the DAPI is in full working condition, as there are tons of services they can still provide using our dapi. But I do not want to see the DAPI put on a back burner.

Can we get clarification on this?

 

[camosoul]

IX is backwards and they refuse to fix it until someone beats them to market... Someone they probably baghold.

Fixing IX is trivial. They simply refuse.

Fix IX, and the world will come to you.

But that would require balls enough not to fear winning...

 

[David]

If the company says "We're not ready to put resources into this yet, but we'll gladly begin a business relationship with you by starting with your more standard features, otherwise no deal" -- that would be a reason not to include it. If you can find another company with a comparable impact to Blockcypher, who IS willing to do everything Blockcypher is offering *plus* a commitment to InstantSend right off the bat, I would be all ears.

Agreed. It's like the "major exchange" proposal: we could sit around and w

I'm not saying don't do the deal. It sounds like a winner, and I'll probably vote for it. That's not my point. How many times do we have to hear "InstantSend will come later, just let us get this (fill in the blank) done first". It's the killer app for all of crypto adoption.

I think we do things this way to get our foot in the door, then once our basic functionality is integrated, we start trying to convince partners to integrate InstantSend as well. I definitely agree with you--we can't forget to follow up!

 

[UdjinM6]

IX is backwards and they refuse to fix ...

Fixing IX is trivial. ...
...

It's not:
1. this would require someone to pay the IS fee in some tx2 locking tx1 (how do you know which one?)
2. network should reprocess the tx1 like if it was an IS, even though it wasn't (this is also not as simple as it sounds)
3. you need to make sure both ways work without conflicting with each other or anything else somehow (depends on the way (1) is implemented)

You have to keep in mind that IS code was a mess with many moving parts in 12.0 even though it was working It was hugely refactored at least 2 times during 12.0->12.1 transition. And even then (or rather as a result of that), it was basically overhauled in the end https://github.com/dashpay/dash/pull/1288. Imo trying to implement suggested changes before doing that was simply way too dangerous.

PS. I have this post https://www.dash.org/forum/threads/12-1-testnet-testing-phase-two-ignition.10818/page-10#post-109884 bookmarked btw, so don't think that no one cares if you see no vocal response

PPS. aaand... we are off topic slightly

 

[Icebucket]

@Minotaur I applaud this development and want to congratulate you Daniel on this achievement.

That being said there is a question I have for you, this question comes from reading your previous posts and seeing the distrust being posted towards you by numerous people with long history here on this forum.
Im not trying to be a concerned troll here, but I want to ask you about your previous experience as a business developer, I did try to find out but did not find any information on your past prior to working on Dash.
tryed asking on Slack and nobody really knew anything about you or your background.

Could you tell me what makes you qualified to hold this position within dash ?
And have you thought about stepping aside to let a more experienced individual in business development take the charge ? with you maybe in advisory position.

But other than the obvious hickup (lamassu) Im happy with your work so far. And think you are doing everything in your power to establish Dash as a force to be recon with.

PS. Mean no disrespect by this post, it just seems like you are the only one on the core team that lacks experience in its field. But that is a assumption im making in light of lack of background info on your past.

 

[camosoul]

You have to keep in mind that IS code was a mess with many moving parts in 12.0 even though it was working It was hugely refactored at least 2 times during 12.0->12.1 transition. And even then (or rather as a result of that), it was basically overhauled in the end https://github.com/dashpay/dash/pull/1288. Imo trying to implement suggested changes before doing that was simply way too dangerous.

PS. I have this post https://www.dash.org/forum/threads/12-1-testnet-testing-phase-two-ignition.10818/page-10#post-109884 bookmarked btw, so don't think that no one cares if you see no vocal response

I'm glad someone with a brain is paying attention.

It was easy to say "we're not in it for the marketcap" back when the marketcap was crap... Too many people are losing their heads and getting stars in their eyes.

They forget that they're only attracting other cryptotards, and not generating adoption in the real world.

Which is why this is not at all off topic.

The proposer simply doesn't seem to grasp what real world business needs, and it's properly functioning IX. This should be THE priority. It should have been for almost 2 years now. But we keep dicking about with silly snowflake crap that seems like nice window dressing, but doesn't actually do anything.

I get the facebook-of-crypto features. I do. But realize the time suck of inventing a waterproof hair dryer for people who can't read the warning labels... You're paying way, way, way too much attention to one end of the equation, while completely ignoring the other. It won't matter how many snowflakes you reach down to if there is still nowhere willing to accept it as payment. They still can't use it anywhere.

@Minotaur, please wake up and pay attention to reality!

 

[quakepl]

hello, if you can still buy licencija DSAHCOIN?

 

[Mira]

In my opinion, I don't think Dash should compromise on "instantsend" and "masternode." Dash is Dash. I like what Dash has been doing so far and it should continue that way. Please just hire good marketers and sales to promote Dash and strive to develop the software that fits its traits. Don't lower Dash's standards.

 

[camosoul]

However I am right there with you and thinking that instant send is woefully underutilized.

Because it's backwards. It's sender-initiated. Because of the fallback to bitclone blockchain dependence, not using IX is incenitivised:

1) potential double-spend
2) competitors can monkey-wrench retail checkout lines by simply not using it and make DASH look like a pain

These are just two points by which the current defective implementation of IX can be abused by grey/black hats.

@UdjinM6 seems to be paying attention to this, but whether he has permission to do anything about it or not seems to be the problem... The whole point of IX is to assure the RECIPIENT, so if there is a fee, the recipient should be charged it, because the SENDER should not be party to the decision.

The issues that @UdjinM6 raise about difficulty of implementing a change seem to revolve around addressing the fee, and I must say, why must there be a fee for IX?

Get rid of the fee. MNs are already being paid to facilitate this. It's what they do. It's why they're paid.

The client should have a check box "broadcast TX locks for received payments."

I find it disturbing that the leadership is already trying to downplay PS by teaming up with organizations who's plan is to nullify it... And now we're teaming up with an organization who's reason for existing is a half-assed effort to nullify IS as well... Why are you trying to destroy the two most important features DASH has? Do you really expect these entities to come out and say "Well, heck, there's no reason for us to exist!" Do yo really think they're going to out themselves and just go away; "DASH fixed the problems we were half-assing for bitclones."

 

[Solarminer]

Well, to ensure IS TXs never get bumped, Dash should implement a variable block size. And adding the capability of the sender or receiver to initiate a lock would fix the "woops I forgot to check IS".

These are not impossible. Vcash has variable blocks and their Zerotime can be locked by either sender or receiver. Oh and Vcash was planning to have Zero fee transactions.

 

[UdjinM6]

...

The issues that @UdjinM6 raise about difficulty of implementing a change seem to revolve around addressing the fee, and I must say, why must there be a fee for IX?

Get rid of the fee. MNs are already being paid to facilitate this. It's what they do. It's why they're paid.
...

The fee is there because IX uses much more network resources than normal tx would - not only mns have to vote, but every node has to store results for at least 24 blocks while normal txes can be removed from mempool right after the moment they were mined in some block. The fee doesn't go to any mn directly. Just like any other fees it becomes a part of block reward which imo aligns perfectly with the future transition of block reward from supply to fees. Now you just need to find a way for receiver to pay the fee, not the sender. This can be done in multiple ways:
1) another special tx with op_return encoding the original txid sent by the receiver;
2) child-pay-for-parent-like scheme i.e. you try to spend tx right after you received it paying additional fees which will not just lock your tx but also the original tx.

(1) looks a bit too much, but relatively easy (though it's another proto-bump and can introduce some incompatibility if same op_return data code is used in bitcoin later etc), for (2) we need to revise "6 conf" limitation first and all relative risks.

Well, to ensure IS TXs never get bumped, Dash should implement a variable block size. And adding the capability of the sender or receiver to initiate a lock would fix the "woops I forgot to check IS".

These are not impossible. Vcash has variable blocks and their Zerotime can be locked by either sender or receiver. Oh and Vcash was planning to have Zero fee transactions.

Block size issue is perpendicular imo, locks are kept 24 blocks _since corresponding tx was mined_ now, so if it wasn't mined this window simply extends further.
I had a look at vcash in the past, I'm not sure their solution was robust enough tbh - it suffered from the same Lock Race issue as we did and which I believe we solved in 12.1.

 

[camosoul]

The fee is there because IX uses much more network resources than normal tx would

MNs get paid enough to cover this. I don't believe it's a valid objection. It' a true statement, but it's not a problem.

It's true that it costs me more to drive my car 200 miles than it does to walk that distance. Until you consider the time difference, and the expenses that go into that extra time...

Since when is DASH worried about adding a minor burden to the MNs, whose very purpose is to do things not otherwise possible...

I've had similar "robust" concerns for other coins bragging similar or better features.

XVC had what looked like a good plan on paper, but then there was the spaz...

This isn't really an argument about Coin A or Coin B. The point is that this needs to be done. Its hard to have a reasonable conversation about it because it just degenerates to cryptotard fanboys hyping/trolling.

The bottom line is the same as it always has been.

Instantly secured TXes is the primary reason that bitclones cannot satisfy the real world. Bitcoin brags that is has a community of upstarts surrounding it. They call it an Organic Ecosystem. Reality is that these are bunch of incentivised band-aids to a fundamentally defective system. A bunch more middle men. It's worse than dealing with Visa.

They're right, it's an organic ecosystem; just like an infection growing in an open wound... It's an organic ecosystem alright. But, not a good one.

Maybe DASH should consider breaking with the BTC marriage?

My core interest is to see Cryptocurrency make good on the promises Satoshi made by learning from BTC; a self-titled EXPERIMENT. I don't care what the name off of that Cryptocurrency is. DASH looked like the best suited project for this 18 months ago, but I'm starting to wonder.

Anyone can pay a fee to the network. I think this might be getting overcomplicated. I don't see why the sender even needs to be involved. If someone wants TXID 8784756467837i7jh868bj6jbr68k6j6j46j46k7n56j568k6ujtu to be locked, he pays a fee and makes a lock request to the MNs. It could even be done by a 3rd party not involved in the TX in question. If you wanted to add a requirement that it be signed by the privkey of either the sender or the receiver, that could be added...

I don't see how that is fundamentally different from the sender making the lock request. Anyone can just raise their hand and say "Hey, lock that TX." Filtering it to involved parties only, by requiring an involved sig could be optional. Leaving that off could introduce the possibility of non-involved parties requesting locks, which may not be a bad thing. A multi-client operator could request locks from a seeming uninvolved source. From a 3rd party observer perspective, this seems deducible, but also muddies the water at the same time. Isn't that what privacy is about? Making it less easy to determine what's going on?

Explain to me why we can't back the plan up a little bit and make IX more generic, thus turning this into a non-problem.

 

[UdjinM6]

...
I don't see how that is fundamentally different from the sender making the lock request. Anyone can just raise their hand and say "Hey, lock that TX." Filtering it to involved parties only, by requiring an involved sig could be optional. Leaving that off could introduce the possibility of non-involved parties requesting locks, which may not be a bad thing. A multi-client operator could request locks from a seeming uninvolved source. From a 3rd party observer perspective, this seems deducible, but also muddies the water at the same time. Isn't that what privacy is about? Making it less easy to determine what's going on?

Explain to me why we can't back the plan up a little bit and make IX more generic, thus turning this into a non-problem.

3rd party requesting a lock for some random txid is what can be done via (1) only, since 3rd party can't spend original tx like (2) is suggesting.
This has both pros and cons, at least the ones I wrote above, but maybe some more, I had no time to deeply think about it yet - IS overhaul was done less than a month ago, before that there was no reason to even think about it, it wouldn't work due to easy cancellation. And now we are busy monitoring/fixing 12.1 and making sure it can preserve stable state. I'll get back to digging more about "lock by receiver" idea once things calm down.

 

[TanteStefana]

@camosoul @UdjinM6 I think this problem would best be resolved by making all transactions instant send transactions and even thought that was the idea when Evan originally proposed Evolution. I thought the only reason we haven't done that yet is because we wanted to vet it through use, see if it failed or had a weakness?

 

[camosoul]

I'll get back to digging more about "lock by receiver" idea once things calm down.

Busy on 0.12.1.1, understood.

Simplify it. I don't think it needs to be this hard.

It might be easier to think of this more open-ended.

"Lock by whoever feels like paying the fee."

If you observe a TX in the memory pool and you feel like locking it, pay the fee and do it. Instead of all this back and forth comms, just submit a lock request for TXID ybrjve7jbr6jr6vjhdt7j6r778k7t8j6ve67j6k6jve6rj6j6jwx4g568l. That's it.

If you feel like looking at the TXID, finding the inputs and outputs, and requiring a sig from one or the other in order to accept a lock request, whatever. Its optional.

I think IX would work open-ended, it's just got the wrong end open right now...

Some might say that locking someone else's VINs is rude...

1) setting up vendors for theft is far more rude. I understand that being able to steal from vendors is a "feature" that snowflakes love having, but this is not acceptable to the people being stolen from... This is a problem of bitclones. This is a feature request that you need to ignore. "Bitclones let us steal free stuff, so DASH better help us do that, too, or we won't use it." DASH needs to stop catering to these people if it expects to be taken seriously by everyone else. This is why I harp on the constant catering to cryptotard snowflakes, without thinking about the rest of the world full of sane people. They're mutually exclusive. The problem bitclones already have is that they cater to cryptotard snowflakes, which means nobody else wants them. The more you cater to idiots, the les interested grown-ups will be. Forcing vendors to give away free stuff seems a poor way to gain their interest....

2) if you use PS, you've got so many VINs you'll never notice if a few get temporarily locked.

3) you've been sitting on this for a long time... The simplified implementation I described above could be implemented by any bitclone in a strictly peer-to-peer manner. If they beat you to it, DASH is dead. The only reason DASH has survived this long is because ot the monumental incompetence and stupidity of the rest of the cryptosphere. Which also represents the stigma needing be overcome... DASH is becoming Black Bloc. Only fellow jackasses want to get involved. Sane people want to kill it, not get in bed with it.