Author

Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 1501. (Read 9723849 times)

legendary
Activity: 1176
Merit: 1036
Dash Developer
We're working on the prototype design... feel free to give input

https://docs.google.com/document/d/1xD0ACmiTEQ1KEMNC6FWrWi1Rh_ipmPMn8L3zvR11GA4/edit?usp=sharing


I just allowed public commenting on the document in the settings, feel free!
legendary
Activity: 1092
Merit: 1000
Am I the only one who gets a little bit uneasy about the fungibility part lately? How is the priority currently beside all the other features? The sooner we get rid of this long darksend times, the better. When do you think the "separate paper" about Privacy & Fungibility is ready Evan? Thank you.

I'm currently looking at doing single layer DS through the DAPI implementation, which would also be blinded by network relay. DS is impenetrable at a single layer if it's blinded by the network. This would bring down mix times per 0 to 1000 dash to a few seconds on the network.  Also, it doesn't cause as much bloat of the network to keep the privacy and fungibility. I think it'll work well.

This is out of scope for the next prototype though, we want to create something super simple.

I was hoping you might have been looking to implement zk-SNARKs/zerocash as it looks very private and very fast.

I think there is one very important thing in my opinion, I think we should keep fungibility without recourse to obscurity.  I think this is one of the main differentiators in Dash, that we preserve the public blockchain for public audit while giving the users an option for privacy.  After speaking with many people from the industry during the show in Mexico I think this is a really good model. In crypto there are no counter parties so the fact that any user can verify the public ledger to see it is working correctly is really powerful and accomplishing user privacy while preserving this property is ideal in my opinion.

Improving all these aspects while staying compatible with Bitcoin gives everyone a sense of security and it will show more and more in terms of adoption as time goes by.
legendary
Activity: 2548
Merit: 1245
I'm sure this question has been asked but can't really find anything...

What is the current 'range' of annual ROI? [projected annual ROI]


TIA
[thx in advance]

https://dashpay.atlassian.net/wiki/questions/12910621/how-much-is-the-roi-of-a-masternode

you can use moocowmoo's sheet to calculate it..
legendary
Activity: 1176
Merit: 1036
Dash Developer
sr. member
Activity: 426
Merit: 250
We're working on the prototype design... feel free to give input

https://docs.google.com/document/d/1xD0ACmiTEQ1KEMNC6FWrWi1Rh_ipmPMn8L3zvR11GA4/edit?usp=sharing


Am I actually watching you update this as I'm reading it?   Very neeto.
sr. member
Activity: 436
Merit: 250
I'm sure this question has been asked but can't really find anything...

What is the current 'range' of annual ROI? [projected annual ROI]


TIA
[thx in advance]

You mean for masternodes? About 14% p.a.
legendary
Activity: 1176
Merit: 1036
Dash Developer
sr. member
Activity: 460
Merit: 250
Am I the only one who gets a little bit uneasy about the fungibility part lately? How is the priority currently beside all the other features? The sooner we get rid of this long darksend times, the better. When do you think the "separate paper" about Privacy & Fungibility is ready Evan? Thank you.

I'm currently looking at doing single layer DS through the DAPI implementation, which would also be blinded by network relay. DS is impenetrable at a single layer if it's blinded by the network. This would bring down mix times per 0 to 1000 dash to a few seconds on the network.  Also, it doesn't cause as much bloat of the network to keep the privacy and fungibility. I think it'll work well.

This is out of scope for the next prototype though, we want to create something super simple.

I was hoping you might have been looking to implement zk-SNARKs/zerocash as it looks very private and very fast.
legendary
Activity: 1176
Merit: 1036
Dash Developer
Am I the only one who gets a little bit uneasy about the fungibility part lately? How is the priority currently beside all the other features? The sooner we get rid of this long darksend times, the better. When do you think the "separate paper" about Privacy & Fungibility is ready Evan? Thank you.

I'm currently looking at doing single layer DS through the DAPI implementation, which would also be blinded by network relay. DS is impenetrable at a single layer if it's blinded by the network. This would bring down mix times per 0 to 1000 dash to a few seconds on the network.  Also, it doesn't cause as much bloat of the network to keep the privacy and fungibility. I think it'll work well.

This is out of scope for the next prototype though, we want to create something super simple.
legendary
Activity: 2156
Merit: 1014
Dash Nation Founder | CATV Host
Different topic : Twitter

[SOCIAL MEDIA] - Who is the CryptoCurrency on Twitter Top 25?
https://bitcointalksearch.org/topic/social-media-who-is-the-cryptocurrency-on-twitter-top-25-1279685

Quote
I've been assigned to administer the Goldcoin Twitter feed @GoldCoin and would like to get some ideas about who to follow.

So based on the replies here I will build the "Twitter Crypto Top 25"!


* Please note this list is dynamic and will change based on your replies.
** New 10K follower minimum to be added.


1.) @okcashcrypto (170K)
2.) @dogecoin (152K)
3.) @bitcoin (99.6K)
4.) @coindesk (73.7K)
5.) @coinbase (62.7K)
6.) @bitcoinmagazine (42.9K)
7.) @cryptsy (21.8K)
8.) @ethereumproject (20.5K)
9.) @altcointoday (19.1K)
10.) @litecoin (18.2K)
11.) @VitalikButerin (14K)
12.) @BitcoinzMan (12.6)
13.) @BitcoinzWoman (12.2K)
14.) @StartJOIN (11.3K)
15.) @BitcoinzMachine (10.3K)


@Dashpay : 5.896 followers
@TaoOfSatoshi  : 4.196 followers

Any thoughts on this subject ? Any chance on strenghtening our Twitter effort so we can make it to that list ? (10K followers requirement)
Can we use a budget proposal to strenghten our Twitter initiative somehow  ?
My goal is to get to 10K followers by the end of 2016, then he can put me on the list. I'm sure Dashpay will get there before me...  Grin
sr. member
Activity: 436
Merit: 250
Am I the only one who gets a little bit uneasy about the fungibility part lately? How is the priority currently beside all the other features? The sooner we get rid of this long darksend times, the better. When do you think the "separate paper" about Privacy & Fungibility is ready Evan? Thank you.
legendary
Activity: 2548
Merit: 1245
Oh, and regarding "chat" (or I prefer messaging), I can see it being used, especially in partner situations, for discussing and coordinating payments among other things, and if it can be a tunneled, encrypted connection that is never recorded by a 3rd party, it could be a great tool, only face to face would be better!

I was more thinking we should support encrypted JSON blobs being sent to your friends within the network. This allows the clients to actually talk to each other directly and decide what they implement on the client side.

Something like this:

encrypted
{'type' : 'message', 'data-from' : '@user2', 'text' : 'hello'}

The first use of this I see is allowing you, as a client on the network to send your friends messages like:

{'type' : 'next-use-pubkey', 'data-from' : '@user2', 'pubkey' : 'Xaddr3'}

This would tell your friend, "use this address for the next payment". So you can imagine all of the things we can do with a system like that, we could have different wallets that support various advanced functionality.

For example, private chatting and group chatting become really easy. Or how about a command to implementing a whole new window in the wallet? I can think of a million things we could do with it

- Negotiating multi-sig transactions, through the network!
- Creating a fiat/dash "local bitcoins" market within the currency itself
- Negotiating an arbitrated transaction between parties
- Sending a "friend" deliverables for a contract

All of these things can simply occupy new command "types" within this transport layer.



goodbye usage of exchanges that are vulnurable to exploit
hello secure private and group chatting within our network
hello internal document delivery system
hello strenghtened transaction security    

Needless to say i like it  Grin


legendary
Activity: 1176
Merit: 1036
Dash Developer
Oh, and regarding "chat" (or I prefer messaging), I can see it being used, especially in partner situations, for discussing and coordinating payments among other things, and if it can be a tunneled, encrypted connection that is never recorded by a 3rd party, it could be a great tool, only face to face would be better!

I was more thinking we should support encrypted JSON blobs being sent to your friends within the network. This allows the clients to actually talk to each other directly and decide what they implement on the client side.

Something like this:

encrypted
{'type' : 'message', 'data-from' : '@user2', 'text' : 'hello'}

The first use of this I see is allowing you, as a client on the network to send your friends messages like:

{'type' : 'next-use-pubkey', 'data-from' : '@user2', 'pubkey' : 'Xaddr3'}

This would tell your friend, "use this address for the next payment". So you can imagine all of the things we can do with a system like that, we could have different wallets that support various advanced functionality.

For example, private chatting and group chatting become really easy. Or how about a command to implementing a whole new window in the wallet? I can think of a million things we could do with it

- Negotiating multi-sig transactions, through the network!
- Creating a fiat/dash "local bitcoins" market within the currency itself
- Negotiating an arbitrated transaction between parties
- Sending a "friend" deliverables for a contract

All of these things can simply occupy new command "types" within this transport layer.
newbie
Activity: 49
Merit: 0
The DAPI is going to be required for this DarkWallet web interface to be able to access your wallet and therefore initiate a Dash transaction to the blockchain, correct? Or is there currently a means of doing this that I don't know about?
legendary
Activity: 3066
Merit: 1188

Oh, and regarding "chat" (or I prefer messaging), I can see it being used, especially in partner situations, for discussing and coordinating payments among other things, and if it can be a tunneled, encrypted connection that is never recorded by a 3rd party, it could be a great tool, only face to face would be better!

I agree that verbal communication is sometimes important when co-ordinating payments, but please folks, stop. And think.

There is a trap that is one of the first pitfalls in software design, and that is loosing sight of your product's priority in favour of all the supporting ones that are not a priority. We live in a technology eco-system. The trick is to understand how that ecosystem sees you - not how you see it since it has options, you don't.

There's a tendency when developing product ideas to adopt an asymmetric, product centric view whereby the product 'becomes' the market instead of a market player.

As a great example of this, I knew a guy who built an online retailing service in the far east. His little company bought stuff (clothes, souvenirs) in little markets and shipped it around the world - acting as a proxy for people perusing the market themselves. (At that time you could only get mainstream, Amazon type stuff online). He got very excited about this business model and wanted to extend it to "any type of product from anywhere". In that vein he started buying up domain names around the theme of "shipdirect2U" and "worldDirect2U".

I tried to advise him that what he was seeing in his mind was the eco-system projected onto a product, not a product that would become the eco-system but he couldn't see it. 15 years later his vision has manifested - except it's called Google Shopping Feed and is contributed to by thousands of businesses all over the world.

What we need to do is ditch our product-centric view and switch to seeing how the world views the product. How and why will it pick it out amongst the myriad of other options it has ?



Form the "world's" perspective, Dash as a product does three things very well and three things only IMO:

[1] - being a public blockchain asset

[2] - fulfilling the monetary requirements of cash, being that it fully addresses bitcoin's fungibility and transaction time shortfalls

[3] - does the above with a technology stack thats largely compatible with bitcoin's

In fact it does those things so well that it's in a class of its own with regard to those three properties in combination.

There are of course other things that set it apart - like the articulated protocol etc - but they aren't things that "world" is going to care about to the extent that it can pick Dash out amongst the mass of options. They are not 'visible' to the market, they only support the 'visible' properties that I listed above.

Dash doesn't do chat, doesn't do online storage (other than blockchain), doesn't do social media and I don't think it should try to do any of those. However it can make itself "digestible" by social media applications which is the right way around for things IMO.

Re. Bells & Whistles
What do people do when they need to co-ordinate payments right now ? They pick up the phone. What do they do when they need internet voice-comms ? Get onto Skype. If you happen to be one of the miniscule percentage of people who require encrypted comms while they are making payments then there's always...

I use Team-viewer a lot which now has a built in chat feature, but I never use it because my 'perception' of Teamviewer is as a screensharing tool and Skype as a chat tool.

In summary - ok, lets have a brainstorm about everything - but I think any feature that isn't directly (or at least indirectly) supporting one of Dash's primary objectives as a highly fungible, anonymous, sustainably developed electronic currency asset needs to be regarded as 'excess baggage' by default. Those that are thought to be supporting Dash's primary market objectives need to have their roles well defined and in the appropriate context.

For example, the Facebook API example is a social media tool but which DOES have a definite role in supporting the currency since people already use Facebook but cannot spend Dash on their Facebook page. Adding social media features to a Dash wallet reverses this logic: the target market does NOT use Dash wallets and they CAN currently do social media, ergo: fail. (Dare I say...#R3.. ? LOL ! )

IMO, what Evan drew in that mockup posted earlier is similar to my mate from the Far East's 1999 view of the market - i.e. it is a symbolic illustration of how Dash will eventually integrate with the eco-system but not a realistic component of that ecosystem.


sr. member
Activity: 317
Merit: 1012
I think you're right about the facebook terminology though.  Instead of "friends" maybe we should use "contacts" or "connections" or some such

The correct term is "payees".

They are neither contacts nor friends. Unless the wallet is trying to re-invent itself as a social media tool (which is what I'm saying is the huge banana skin to be avoided) then that list represents aliases for payment addresses. They might be anyone from enemies to gas companies to retailers or charities but 'Payees' describes the common role that that entity has in the tool. Anything else pre-supposes the nature of the relationship and is ambiguous.

A CRM tool would use terminology such as "contacts" because that is unambiguously the nature of the tool. Likeways, a social media system would label them "friends". I know "Payees" sounds boring but boring is good in system design if it more correctly defines the role than anything else (which in this case it does  Wink ).

All I'm saying is that it's not the job of a currency to perform a social media function. However the reverse may be the case - i.e. social media applications may want access to spendable currencies which is why I'm saying the approach should be forget about user interfaces other than very boring and secure ones in the 'native wallet' while concentrating on:

[1] - blockchain performance

[2] - monetary fidelity

[3] - blockchain accessibility (API's)


The more business layout than social media layout approach makes more sense here too, at least for the main version. It should be possible to have both through re-skinning, maybe different versions depending on where they're downloaded from and possibly even branding if there's a lot of downloads from a particular site or service? As far as I know it's not intended to be the default means of using Dash anyway, just a convenient interface and the real power will be in sites and services using the DAPI in their own pages/apps.
sr. member
Activity: 434
Merit: 250
Quantum entangled and jump drive assisted messages
[2] - it's resilient to de-anonimisation (imagine bitcoin's blockchain linked to millions of social media accounts and the rubbing of salt in the wounds of its fungibility problems)
True, if the social media accounts are held encrypted on the masternode storage, this is the first form of defence from attack, even better if the shards were splintered somehow, so if 1 was compromised, it wouldn't matter because the data set is incomplete, only having half the data making the puzzle unsolvable kind of thing.
sr. member
Activity: 447
Merit: 250

I think you're right about the facebook terminology though.  Instead of "friends" maybe we should use "contacts" or "connections" or some such

The correct term is "payees".

They are neither contacts nor friends. Unless the wallet is trying to re-invent itself as a social media tool (which is what I'm saying is the huge banana skin to be avoided) then that list represents aliases for payment addresses. They might be anyone from enemies to gas companies to retailers or charities but 'Payees' describes the common role that that entity has in the tool. Anything else pre-supposes the nature of the relationship and is ambiguous.

A CRM tool would use terminology such as "contacts" because that is unambiguously the nature of the tool. Likeways, a social media system would label them "friends". I know "Payees" sounds boring but boring is good in system design if it more correctly defines the role than anything else (which in this case it does  Wink ).


Well, they could be payers as well, LOL.


Oh, and regarding "chat" (or I prefer messaging), I can see it being used, especially in partner situations, for discussing and coordinating payments among other things, and if it can be a tunneled, encrypted connection that is never recorded by a 3rd party, it could be a great tool, only face to face would be better!

I prefer "messaging" too. A chat client can be particularly useful if the network of users is significant but I can't see it becoming the latest and greatest chat client (nor should it try to), however, the ability to shoot off a quick message related to a payment I think could be beneficial.

I'm not too keen on the "friends" label, unless maybe it were possible to split the contacts into groups of "friends", "family", "colleagues" etc, but that would potentially begin to clutter the interface fairly quickly. I don't think using "contacts" instead of "friends" on the tab would be so bad. I'm sure most people have some "contacts" on their phone that are not really contacts in the traditional sense. My mobile network provides a few numbers for me on their sim card, and despite the fact that Suzy from customer service is no contact of mine she appears in the contacts list without causing too much offence.

It would be nice to have a search bar to type in the first few letters of a name and for the names to be filtered accordingly.
legendary
Activity: 2548
Merit: 1245
Different topic : Twitter

[SOCIAL MEDIA] - Who is the CryptoCurrency on Twitter Top 25?
https://bitcointalksearch.org/topic/social-media-who-is-the-cryptocurrency-on-twitter-top-25-1279685

Quote
I've been assigned to administer the Goldcoin Twitter feed @GoldCoin and would like to get some ideas about who to follow.

So based on the replies here I will build the "Twitter Crypto Top 25"!


* Please note this list is dynamic and will change based on your replies.
** New 10K follower minimum to be added.


1.) @okcashcrypto (170K)
2.) @dogecoin (152K)
3.) @bitcoin (99.6K)
4.) @coindesk (73.7K)
5.) @coinbase (62.7K)
6.) @bitcoinmagazine (42.9K)
7.) @cryptsy (21.8K)
8.) @ethereumproject (20.5K)
9.) @altcointoday (19.1K)
10.) @litecoin (18.2K)
11.) @VitalikButerin (14K)
12.) @BitcoinzMan (12.6)
13.) @BitcoinzWoman (12.2K)
14.) @StartJOIN (11.3K)
15.) @BitcoinzMachine (10.3K)


@Dashpay : 5.896 followers
@TaoOfSatoshi  : 4.196 followers

Any thoughts on this subject ? Any chance on strenghtening our Twitter effort so we can make it to that list ? (10K followers requirement)
Can we use a budget proposal to strenghten our Twitter initiative somehow  ?
legendary
Activity: 1260
Merit: 1001

I think you're right about the facebook terminology though.  Instead of "friends" maybe we should use "contacts" or "connections" or some such

The correct term is "payees".

They are neither contacts nor friends. Unless the wallet is trying to re-invent itself as a social media tool (which is what I'm saying is the huge banana skin to be avoided) then that list represents aliases for payment addresses. They might be anyone from enemies to gas companies to retailers or charities but 'Payees' describes the common role that that entity has in the tool. Anything else pre-supposes the nature of the relationship and is ambiguous.

A CRM tool would use terminology such as "contacts" because that is unambiguously the nature of the tool. Likeways, a social media system would label them "friends". I know "Payees" sounds boring but boring is good in system design if it more correctly defines the role than anything else (which in this case it does  Wink ).


Well, they could be payers as well, LOL.


Oh, and regarding "chat" (or I prefer messaging), I can see it being used, especially in partner situations, for discussing and coordinating payments among other things, and if it can be a tunneled, encrypted connection that is never recorded by a 3rd party, it could be a great tool, only face to face would be better!
Jump to: