DASH Business Development Strategy Update - FEB 2017

Status
Not open for further replies.
UdjinM6 said:
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
Click to expand...
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!
 
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.
 
TanteStefana said:
However I am right there with you and thinking that instant send is woefully underutilized.
Click to expand...
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."
 
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.
 
camosoul said:
...

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.
...
Click to expand...
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.

Solarminer said:
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.
Click to expand...
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.
 
UdjinM6 said:
The fee is there because IX uses much more network resources than normal tx would
Click to expand...
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.
 
Last edited:
camosoul said:
...
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.
Click to expand...

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.
 
@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?
 
UdjinM6 said:
I'll get back to digging more about "lock by receiver" idea once things calm down.
Click to expand...
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.
 
Last edited:
I've never seen any business to business proposal produce any results actually. They all end up hanging in midair with a community mind-easer called 'we did our part, it's now up to them'.... and ow yeah, 100.000 USD dollar worth dash is (poof!) gone.

Let the businesses come to us when we have a full fletched evolution running.

No fancy schematic and super awesome explanation is gonna get me to vote yes on these kind of (expected) proposals. Especially not Daniel's. Some monero trolls actually have a valid point sometime, about non delivered products.
 
Last edited:
fuzzyduck said:
I've never seen any business to business proposal produce any results actually. They all end up hanging in midair with a community mind-easer called 'we did our part, it's now up to them'.... and ow yeah, 100.000 USD dollar worth dash is (poof!) gone.
...
No fancy schematic and super awesome explanation is gonna get me to vote yes on these kind of (expected) proposals. Especially not Daniel's.
Click to expand...
This. So much of this.

The features needed to support vendors have been left to rot on the vine for 2 years. The other business proposals fail because there is no valid support for business. DASH is no better than LTC from the vendor perspective, and they're not using LTC for the same reason they're not using BTC.

They keep running into the same brick wall, and telling me I'm a jerk for pointing it out as they pork on...

"Oh, so you think you have the secret to adoption?" they sarcastically say to me. Yes. Yes I do. And there's nothing magical or secret about it. It's basic common-sense. Which does not exist in the ponzi snowflake echo chamber of the cryptosphere. I am not special or arrogant for saying this. Damn near the entire world has been watching and wondering why no one in the cryptosphere can figure out what any 5 year old child knows...

These proposals will always fail as long as DASH refuses to fix the features that would support these proposals. It's a useless waste of time and money until IX gets fixed.

This is why I never submitted a proposal of my own; they're setting it up for failure. Simultaneously, rubber-stamping proposals that blow rainbows and sunshine up their asses aand let them feel like they're playing corporation the same way children play house. Until MNOs grow up, crap like this will keep happening, and DASH will just keep making itself look dumber and dumber. And I'll be labeled a troll for "saying mean things" that make the snowflakes triggered...
 
Last edited:
I think dash digital is doing exclusively well. Instantsend feature is the core and one thing I enjoy discussing about Dash is the features it's got...no Cryptocurrency does things great like dash..I'm Dash eusthastic
 
camosoul said:
Simultaneously, rubber-stamping proposals that blow rainbows and sunshine up their asses aand let them feel like they're playing corporation the same way children play house.
Click to expand...

I wonder if this is a fatal flaw in the MN voting system. Any person or group, with any amount of expertise, or lack thereof, and with any motivations, may operate a MN and therefore vote. I got caught up in the hype of IS and PS and didn't understand that the core team has not been adding features needed for vendors. Does anyone from the core team have a response to camosoul's points?
 
MrGold said:
I wonder if this is a fatal flaw in the MN voting system. Any person or group, with any amount of expertise, or lack thereof, and with any motivations, may operate a MN and therefore vote. I got caught up in the hype of IS and PS and didn't understand that the core team has not been adding features needed for vendors. Does anyone from the core team have a response to camosoul's points?
Click to expand...
Nope. Simply asking has had me labeled a troll for years now...

There are some good guys in core writing code, but they're muzzled, so I don't nag them.

Why?

Because I'm not looking to sow dissent or cause trouble, even though that's what I'm labeled...

Lord knows, I've done my best to provoke a response... But, there's really nothing else to do but sit on your thumbs and see if anything useful happens. Been this way for a long time, and it's really killed confidence in the project. Which is why I do the only thing I can do; try to provoke a response... Asking nicely never worked, so... It's fallen on deaf ears for so long, nobody cares anymore. You'll notice posters active 2 years ago have all disappeared. Pretty much everyone from the good old days has been run off. New blood shows up and asks the same questions, no response...
 
Status
Not open for further replies.
Back
Top