Questions from Community Members to DASH Core Team Members

DashChat

DashChat

New member
Hello. We created a new channel on slack, we call it #questions. How does it work? Community members submit question(s) in the #questions slack channel. Every 15 days a slack admin will submit the list of questions here. We know the core team is busy and because of that we do not expect to have all the questions answered, nor do we expect to have all the answers by tomorrow. If a question doesn't receive an answer we can just transfer it to the next set of questions.

I would, however like to make a quick point. The questions below are coming directly from community members. What are community members? At the moment they are many things. Evangelist, volunteers, customer service representatives. But most important; Community Members are DASH Users! We are the people using the software you are developing. We are the people who spread the word to get our friends and family members to use it. We hope that can be recognized by the core team and we would appreciate any answers provided. Thank you.

Guidelines on Providing Answers:
  • Please paste the Question your are providing an answer to in your response.
  • Unanswered Questions will be in the 'Unanswered Questions' section
  • Answered Questions will be will be in the 'Answered Questions' section
---------------------------------------------------------------​

Unanswered Questions​

Lamassu Budget Questions:
1A) Were any of the other Bitcoin ATM Companies considered for this proposal to utilize their network? Such as Skyhook, Genesis Coin, BitAccess, GeneralBytes, or BitXatm?

5A) How many Bitcoin ATM operators did 'Dash Core' contact for feedback, before submitting the "DASH-Lamassu ATM Integration" proposal? What was the feedback consensus?
General Questions:

1B) Will masternode blinding ever be a real thing?

2B) Does the law office of Marco Santori accept DASH?

3B) How much of the 2,024 DASH we paid out for the website proposal is remaining? Is it denominated in DASH or fiat? - partial Answer The majority of the website funds are remaining. That wallet address pre-dated my involvement in the finances, so I do not control the address or have an exact figure for you. I only know that very little was spent.

Tech Questions:

2C) @evan - Given Dash's volatility are there plans to use quorums to determine the current USD value of Dash and thus dynamically adjust the budget payouts instead of (mostly) overpaying many multi-month proposals

3C) How exactly (technical answer please) was the reference node removed back in the day in order for the network to work without it?

4C) When and how will the Masternode budget finalization become automatic without human intervention?

5C) Are there more details about how evolution can do millions of transactions per second - this was mentioned in Amanda's youtube interview with Dev team
---------------------------------------------------------------​

Answered Questions​
Question: Do you know how much it will cost the DASH Network to have Lamassu sell machines with the Dash software? (Instead of a 3rd party startup like TigoCTM)
Answer: it will cost the exact same as all their other machines. They are willing to flash the Dash software on the factory floor at Lamassau… there is no extra charge to the best of my knowledge

Question: Is there a good idea of when the website will be finished?
Answer: Last recent estimate by Andy was 4-8 weeks, with some room for improvement. More details here:
https://www.dash.org/forum/threads/new-website-discussion.8666/page-5#post-103616

Question: Are there any planned Peer Reviews in the pipeline?
Answer: A reputable security company was contacted, but the prices were not affordable atm. It will eventually happen, but it needs to be done by a top company and that will require a lot of funds.

Question: Do you feel it is a conflict of interest for someone at Dash core to act as a proxy for a Dash Whale?
Answer: If a person trusts another person with his votes freely I don't see a problem. I don't see why someone can perceive there is a conflict there.

Question: Who owns dash.org domain name?
Answer: It is registered to Evan, but the blockchain paid for it, so I'd argue that it is owned by the project.

Question: How will Mycelium integrate dash for the IOS app's if apple doesn't allow DASH?
Answer: Given latest developments in the AppStore (Jaxx, Shapeshift...) we can't know what will happen. @tomasz.ludek is working on that project, maybe he can expand.

LAMASSU

Question: What is tigoCTM relation to the lamassu budget proposal? Why is it linked in the proposal text? Quote & Link: "If this project is approved, Deginner will ensure it is deployed on at least one network of BTMs, starting with the one in Panama City, Panama."
Answer: Tigo is related to the Lamassau proposal because they 1) Use Lamassau ATM hardware, and 2) will support a stack of software and services to allow and Lamassau operator to run Dash… it includes things like coin inventory management, exchange interfaces, etc. They charge about 1% for that service. They also do things like help you place the ATM.

Question: Does the Lamassu Compatible ATM software accept InstantSend transactions?
Answer: Current version doesn't work with InstantSend. I have already sent an information to the vendor with short info how to implement InstantSend using dashd.

Question: Where are the details on the trading engine needed to make the Lamassu Compatible Software work on ATMS?
Answer: High level technical documentation of the software components is available in the following location:https://github.com/GitGuild/gitguild_website/wiki/Git-Guild-Technical-Overview#tapps

Question: Does the Dash software run on the Lamassu and if so, where is a video demonstration of it?
Answer:

Question: is there currently at this moment any development going on at GitGuild for the ATM software?
Answer:
a. Software exclusively dedicated for Lamassu machines is finished. However it is relatively difficult to install (last week one of the community members went through the process and (probably) can share the detials), therefore:
b. GitGuild works on the software that will not be exclusively dedicated to Lamassu machines but for other ATMs too. This is going to be easy to install and distribute
 
Last edited:
DashChat said:
General Questions:
  1. Is there a good idea of when the website will be finished?
  2. Are there any planned Peer Reviews in the pipeline?
  3. Will masternode blinding ever be a real thing?
  4. Do you feel it is a conflict of interest for someone at Dash core to act as a proxy for a Dash Whale?
  5. Does the law office of Marco Santori accept DASH?
  6. How much of the 2,024 DASH we paid out for the website proposal is remaining? Is it denominated in DASH or fiat?
  7. Who owns dash.org domain name?
  8. How will Mycelium integrate dash for the IOS app's if apple doesn't allow DASH?
Click to expand...
Minor improvement for future posts would be to number them uniquely (so in this case general ones would be 2.1, 2.2 and so on). I can't quote list items separately because it changes the number. A few answers below:

1. Last recent estimate by Andy was 4-8 weeks, with some room for improvement. More details here:
https://www.dash.org/forum/threads/new-website-discussion.8666/page-5#post-103616

2. A reputable security company was contacted, but the prices were not affordable atm. It will eventually happen, but it needs to be done by a top company and that will require a lot of funds.

4. If a person trusts another person with his votes freely I don't see a problem. I don't see why someone can perceive there is a conflict there.

7. It is registered to Evan, but the blockchain paid for it, so I'd argue that it is owned by the project.

8. Given latest developments in the AppStore (Jaxx, Shapeshift...) we can't know what will happen. @tomasz.ludek is working on that project, maybe he can expand.
 
DashChat said:
Are there more details about how evolution can do millions of transactions per second - this was mentioned in Amanda's youtube interview with Dev team
Click to expand...
I'm not any part of the core, but I have the answer. Kinda surprised nobody else has this figured out...

TL;DR - You can do millions of TXes per second in DASH because you can bloat the memory pool with no consequences.

Bloat the memory pool with any Legacy Bitclone/Crypto 1.0 Architecture, and you guarantee double spends.

DASH actually uses the bloat to it's advantage, while every other coin becomes a guaranteed double spend factory under the same conditions.

This is the fatal flaw of the Satoshi experiment. Am I still the only person who remembers when Satoshi referred to BTC as an experiment? Learn from the results.

Since DASH has separated TX Security from Ledger Security, DASH does not depend on block inclusions for "confirmation." This entire concept becomes vestigial because of IX/IS. You can send all the IX/IS TXes you want, and they just pile up in the memory pool until they can flush to the ledger. Essentially the same thing that happens to Bitclones when their blocksizes clog up, but because IX/IS transmissions are secured instantly, the detrimental effects do not occur. The memory pool just becomes a giant secure buffer awaiting flush-to-ledger. If the blocksize clogs up, so what? IX/IS is what's securing the transaction, not the blockchain, so it doesn't grind everything to a halt or open up huge windows for even more exploits.... It's the same clog, just none of the bad results because the ledger isn't being misused for tx security.

Essentially, everything just fell into place by simply NOT forcing the ledger to run double duty as both ledger and TX security, like Bitclones still do. The rest of the system can be pretty much left alone so long as you create TX security that is, appropriately, independent from the ledger security. While it looks much the same, the dynamics of it are completely different as a result of doing that one obvious thing that Bitclones don't do.

How can such an exploit as double-spends be deliberately engineered into Bitclones, and last so many years without and serious outcry? It seems so easy. Because it is. This does nothing more than shine a spotlight on how utterly technically clueless and incompetent Bitclone ponzi-head fanboys are. This is why grown-ups don't take it seriously, and why DASH needs to grab that bull by the horns if it wants to stand apart.

It doesn't seem like part of the original question, but IX and Double Spends are at the root of the answer to this question. Double Spends can be done in more ways than what was demonstrated recently by Glass Hunt. One of the worst of which happens when the blockchain clogs up and starts prioritizing TXes in blocks based on fees. When the pileup starts happening and the memory pool swells, it becomes a free-for-all guarantee that double spends will work perfectly absolutely every time. This further demonstrates exactly why IX/IS can perform millions of TXes totally independent of blocksize, rate, or "confirmaitions." IX/IS nails this because it doesn't allow the same inputs to be used more than once.

You can also automate a zero fee double spend. Fire off the same spend to 1000 addresses. 1 of them is the Vendor. 999 of them are your own addresses. Even with no fee at all, the odds are 1 in 1000 that the vendor will actually get the money. Depending on the network propagation lag, once would explicitly target slow nodes or fast nodes, to virtually guarantee in the same way. Again, IX/IS nails this because once send is all that's allowed in the first place. All subsequent sends would be rejected by the network and never part of the memory pool in the first place, thus, also, never end up in a block.

This is why you can pile up all the IX/IS you want in DASH's memory pool and nothing bad will happen. But, do it to any Bitclone, and you make double spends into a guarantee. This means DASH's TXrate handling capacity has nothing to do with it's blocksize or blockrate; a concept that is burned into the small brains of cryptotards as a fact. DASH breaks this "fact" and they can't grasp that. Therefore, millions per second if you feel like it. Waiting for blocks becomes nothing more than flushing the buffer to a secure archive (ledger, the blockchain), has nothing to do with securing the TX. The ledger is relegated to being nothing but a ledger. We don't rely on it for anything else.

Ledger security for the Ledger.

Transaction security for the Transaction.

It's such a simple, duh, concept; but I dare you to get any of the cryptotards to understand it. They have no idea how it works and cling to FUD like it's life...

Gotta keep the bags pumped! Pay no attention to the Elephant behind the Curtain. Yeah, that's the Emperor back there with the microphone, but he's got no clothes. You don't want to see the Emperor naked, do you? Best not to go looking for the truth then. Stay happy and stupid.

There is only one thing that prevent absolutely every single TX on a Legacy Crypto 1.0 network (such as Bitcoin and all of it's clones: Bitclones) from being a double spend; most of the users have no clue what's going on or how to do it. The only glue holding the Bitclone house of cards together is the extreme ignorance of it's userbase.

@amanda_b_johnson - make a video about this. Nobody will listen to me as evidenced by the fact that I've been saying it for over a year now. But, nerds always listen to the pretty girl...
 
Last edited:
camosoul said:
I'm not any part of the core, but I have the answer. Kinda surprised nobody else has this figured out...

TL;DR - You can do millions of TXes per second in DASH because you can bloat the memory pool with no consequences.

Bloat the memory pool with any Legacy Bitclone/Crypto 1.0 Architecture, and you guarantee double spends.

DASH actually uses the bloat to it's advantage, while every other coin becomes a guaranteed double spend factory under the same conditions.

This is the fatal flaw of the Satoshi experiment. Am I still the only person who remembers when Satoshi referred to BTC as an experiment? Learn from the results.

Since DASH has separated TX Security from Ledger Security, DASH does not depend on block inclusions for "confirmation." This entire concept becomes vestigial because of IX/IS. You can send all the IX/IS TXes you want, and they just pile up in the memory pool until they can flush to the ledger. Essentially the same thing that happens to Bitclones when their blocksizes clog up, but because IX/IS transmissions are secured instantly, the detrimental effects do not occur. The memory pool just becomes a giant secure buffer awaiting flush-to-ledger. If the blocksize clogs up, so what? IX/IS is what's securing the transaction, not the blockchain, so it doesn't grind everything to a halt or open up huge windows for even more exploits.... It's the same clog, just none of the bad results because the ledger isn't being misused for tx security.

Essentially, everything just fell into place by simply NOT forcing the ledger to run double duty as both ledger and TX security, like Bitclones still do. The rest of the system can be pretty much left alone so long as you create TX security that is, appropriately, independent from the ledger security. While it looks much the same, the dynamics of it are completely different as a result of doing that one obvious thing that Bitclones don't do.

How can such an exploit as double-spends be deliberately engineered into Bitclones, and last so many years without and serious outcry? It seems so easy. Because it is. This does nothing more than shine a spotlight on how utterly technically clueless and incompetent Bitclone ponzi-head fanboys are. This is why grown-ups don't take it seriously, and why DASH needs to grab that bull by the horns if it wants to stand apart.

It doesn't seem like part of the original question, but IX and Double Spends are at the root of the answer to this question. Double Spends can be done in more ways than what was demonstrated recently by Glass Hunt. One of the worst of which happens when the blockchain clogs up and starts prioritizing TXes in blocks based on fees. When the pileup starts happening and the memory pool swells, it becomes a free-for-all guarantee that double spends will work perfectly absolutely every time. This further demonstrates exactly why IX/IS can perform millions of TXes totally independent of blocksize, rate, or "confirmaitions." IX/IS nails this because it doesn't allow the same inputs to be used more than once.

You can also automate a zero fee double spend. Fire off the same spend to 1000 addresses. 1 of them is the Vendor. 999 of them are your own addresses. Even with no fee at all, the odds are 1 in 1000 that the vendor will actually get the money. Depending on the network propagation lag, once would explicitly target slow nodes or fast nodes, to virtually guarantee in the same way. Again, IX/IS nails this because once send is all that's allowed in the first place. All subsequent sends would be rejected by the network and never part of the memory pool in the first place, thus, also, never end up in a block.

This is why you can pile up all the IX/IS you want in DASH's memory pool and nothing bad will happen. But, do it to any Bitclone, and you make double spends into a guarantee. This means DASH's TXrate handling capacity has nothing to do with it's blocksize or blockrate; a concept that is burned into the small brains of cryptotards as a fact. DASH breaks this "fact" and they can't grasp that. Therefore, millions per second if you feel like it. Waiting for blocks becomes nothing more than flushing the buffer to a secure archive (ledger, the blockchain), has nothing to do with securing the TX. The ledger is relegated to being nothing but a ledger. We don't rely on it for anything else.

Ledger security for the Ledger.

Transaction security for the Transaction.

It's such a simple, duh, concept; but I dare you to get any of the cryptotards to understand it. They have no idea how it works and cling to FUD like it's life...

Gotta keep the bags pumped! Pay no attention to the Elephant behind the Curtain. Yeah, that's the Emperor back there with the microphone, but he's got no clothes. You don't want to see the Emperor naked, do you? Best not to go looking for the truth then. Stay happy and stupid.

There is only one thing that prevent absolutely every single TX on a Legacy Crypto 1.0 network (such as Bitcoin and all of it's clones: Bitclones) from being a double spend; most of the users have no clue what's going on or how to do it. The only glue holding the Bitclone house of cards together is the extreme ignorance of it's userbase.

@amanda_b_johnson - make a video about this. Nobody will listen to me as evidenced by the fact that I've been saying it for over a year now. But, nerds always listen to the pretty girl...
Click to expand...

You are absolutely right about the importance of separating the validation of the transaction from the permanent storage of it.

Just one small thing. At the moment, transaction locks expire after 60 min if they are included in a block. In 12.1 that will happen in 24 blocks. However, I guess this is to prevent the memory pool to go too big and to be able to recover funds if for some reason the transaction doesn't get picked by miners. However, if the transaction volume were big enough, I imagine it would not be a problem to increase that time. Also, we could even change the block time and size so we could flush more transactions to the blockchain. Ideally instant transactions should not be too much on the memory pool so the receiver can spend those funds as soon as possible when they are included in a block.

References to code of tx lock expiration (thanks @UdjinM6)
it’s 60 minutes in 12.0 https://github.com/dashpay/dash/blob/master/src/instantx.cpp#L242
and depends on network in 12.1 https://github.com/dashpay/dash/blob/v0.12.1.x/src/instantx.cpp#L346
mainnet - 24 blocks https://github.com/dashpay/dash/blob/v0.12.1.x/src/chainparams.cpp#L79
testnet - 6 blocks https://github.com/dashpay/dash/blob/v0.12.1.x/src/chainparams.cpp#L202
 
If I'm following the answer right, then it seems the 'millions of transactions/sec' is predicated on the use of InstantSend. Is that correct? Seems like that could be a limitation, thanks
 
The real unlimited transactions comes from the fact that masternodes can store the blockchain and be paid for storing it. You can't expect volunteers to store 100 of GBs of data with huge bandwidth for long, which is why bitcoin nodes are dropping. The plan with Evolution is to have all the blockchain data stored in masternodes, effectively eliminating the "blockchain too big" problem. Then the blocksize can be increased as needed or a variable size (like it should be) to meet the needs for the volume of transactions.

You can't add transactions with InstantSend faster than you can record in blocks forever. So eventually, even with InstantSend the fees will have to go up to limit transactions to a reasonable amount. But also agree, that InstantSend takes the burden of blocksize away and is the key for real instant transactions. We should just be calling Dash InstantSend. It is such a fundamental solution, that can't be done any other way.
 
Last edited:
spiralus said:
If I'm following the answer right, then it seems the 'millions of transactions/sec' is predicated on the use of InstantSend. Is that correct? Seems like that could be a limitation, thanks
Click to expand...

I think InstantSend will become default
 
DashChat said:
1C) Does the Lamassu Compatible ATM software accept InstantSend transactions?
Click to expand...
Current version doesn't work with InstantSend. I have already sent an information to the vendor with short info how to implement InstantSend using dashd.
 
DashChat said:
4A) is there currently at this moment any development going on at GitGuild for the ATM software?
Click to expand...
According to the information I have,
a. Software exclusively dedicated for Lamassu machines is finished. However it is relatively difficult to install (last week one of the community members went through the process and (probably) can share the detials), therefore:
b. GitGuild works on the software that will not be exclusively dedicated to Lamassu machines but for other ATMs too. This is going to be easy to install and distribute
 
Last edited:
kot said:
Current version doesn't work with InstantSend. I have already sent an information to the vendor with short info how to implement InstantSend using dashd.
Click to expand...

Obviously, there is absolutely no reason to even convert an ATM to Dash if it doesn't take InstantSend. I can shapeshift in a few minutes with Coinomi from Dash to BTC or BTC to Dash and use any BTC machine. You will still need to wait the 10+ minutes for block confirmations and get the text when your transaction is confirmed if you are using Dash with no InstantSend.

Maybe I need to spell this out. When you want to exchange your Dash to Cash, the ATM will wait 3-6 confirmations. You put your cell number in and it texts you when it is ready. So there was never a thought of maybe this is frustrating for the customer and InstantSend could do that in 1 second instead? No text, no waiting.

9 months of software development and there is no InstantSend support! Outrageous. And for the last 2+ months GitGuild has been sitting on their hands waiting for the new Lamassu software. They could have spent that time implementing InstantSend.
TigoCTM/GitGuild/Denninger/Daniel - Did any of these guys(ok maybe it is just 2 guys) even think about what the customer wants? InstantSend should have been first.
Kot - Why wasn't this a concern on your report? 100% software complete - but no InstantSend capability. Think about the intent of the project...not what the vendor is telling you to say. There is no reason to have project managers if they say yes complete without thinking about the real world application.
 
  • Like
Reactions: AjM
@Solarminer - I think you make too many assumptions in your statements.
I appreciate your dedication to review the details of the project and to share your feedback and point of view. However please remember it is your point of view and try to not generalize. You has the right to have your opinion but it does not mean it is the ultimate truth and everyone has to follow - just a food for thoughts...
About specifically
Solarminer said:
Did any of these guys(ok maybe it is just 2 guys) even think about what the customer wants? InstantSend should have been first.
Click to expand...
- I am not going to speculate what they think. I just know that nowadays majority of people don't care about the technology behind the services they use on daily basis. People have no idea how SWIFT or SEPA work, they just use it. I suppose that 99% of future users of Dash ATMs will have no idea what InstantSend is and they won't care. It should simply work, be stable and cheap.
Besides of this - have you ever heard about continuous improvement process in IT management (as a part of ITIL)?
 
kot said:
@Solarminer - I think you make too many assumptions in your statements.
....
About specifically - I am not going to speculate what they think.
.....
Besides of this - have you ever heard about continuous improvement process in IT management (as a part of ITIL)?
Click to expand...

I tried hard not to speculate here. I would have not responded that way if the response about InstantSend was, "We are working on adding InstantSend but had some trouble and are going to release phase 1 software without it." Then I would have understood. "Or alternatively, the 1 way machines won't need InstantSend, and the 2 way machines will have it with a release in about 2 months." Again, I see the plan for implementation. Oh, and why not advertise the InstantSend feature and that you don't have to wait 10+ minutes to get cash from a crypto ATM.

kot said:
@Solarminer I suppose that 99% of future users of Dash ATMs will have no idea what InstantSend is and they won't care. It should simply work, be stable and cheap.
Click to expand...

It concerns me that you wrote this statement. This is a fundamental difference of Dash vs all Bitclones. I would expect every user to know what InstantSend is and that is why they own Dash. Dash without InstantSend is just a bitclone as far as the user is concerned. Without InstantSend the user will need to wait for confirmations. Which means waiting for that text for 10+ minutes....or 1 second to Dash into Cash. Yeah, seems like a big deal to me.
 
Solarminer said:
I tried hard not to speculate here. I would have not responded that way if the response about InstantSend was, "We are working on adding InstantSend but had some trouble and are going to release phase 1 software without it." Then I would have understood. "Or alternatively, the 1 way machines won't need InstantSend, and the 2 way machines will have it with a release in about 2 months." Again, I see the plan for implementation. Oh, and why not advertise the InstantSend feature and that you don't have to wait 10+ minutes to get cash from a crypto ATM.



It concerns me that you wrote this statement. This is a fundamental difference of Dash vs all Bitclones. I would expect every user to know what InstantSend is and that is why they own Dash. Dash without InstantSend is just a bitclone as far as the user is concerned. Without InstantSend the user will need to wait for confirmations. Which means waiting for that text for 10+ minutes....or 1 second to Dash into Cash. Yeah, seems like a big deal to me.
Click to expand...
This seems to be explained in an easy to understand way. The ATM experience, along with retail, really has the potential to be revolutionized with InstantSend. It appears to people that are not involved in the inner workings, @kot, that there is no real push to have that key piece of technology integrated in this software. Is that the case? Or is it just slow coming? I agree with @Solarminer that this is a big deal, and I would like answers to this as well.
 
Guys, Are your concerns coming from the real experience with ATM and you had to wait 10+ minutes for confirmation?
 
Solarminer said:
Obviously, there is absolutely no reason to even convert an ATM to Dash if it doesn't take InstantSend. I can shapeshift in a few minutes with Coinomi from Dash to BTC or BTC to Dash and use any BTC machine. You will still need to wait the 10+ minutes for block confirmations and get the text when your transaction is confirmed if you are using Dash with no InstantSend.

Maybe I need to spell this out. When you want to exchange your Dash to Cash, the ATM will wait 3-6 confirmations. You put your cell number in and it texts you when it is ready. So there was never a thought of maybe this is frustrating for the customer and InstantSend could do that in 1 second instead? No text, no waiting.

9 months of software development and there is no InstantSend support! Outrageous. And for the last 2+ months GitGuild has been sitting on their hands waiting for the new Lamassu software. They could have spent that time implementing InstantSend.
TigoCTM/GitGuild/Denninger/Daniel - Did any of these guys(ok maybe it is just 2 guys) even think about what the customer wants? InstantSend should have been first.
Kot - Why wasn't this a concern on your report? 100% software complete - but no InstantSend capability. Think about the intent of the project...not what the vendor is telling you to say. There is no reason to have project managers if they say yes complete without thinking about the real world application.
Click to expand...
@Solarminer Thank you for your comments. I agree with one of your positions and disagree with another.

I strongly agree that InstantSend is a critical feature that should be implemented at the ATM. It really is our killer feature and provides a far superior user experience compared to Bitcoin. I think that it needs to be incorporated into one of the upcoming versions that incorporate improvements, though I suspect ease of use for the operator is a slightly higher concern at the moment. I'm not saying that both can't be worked on at the same time, but if there is a choice, I would push to make the software easier to install and maintain first. That said, I think for the time being, it needs to be optional for the operator to implement, as they may not yet feel confident enough in the technology to turn InstantSend on. I think we've made it clear that we would like to add this functionality and push for its adoption.

I completely disagree with your statement that there's no point to ATM software without InstantSend. If users wanted to convert cash (bills) into Dash, they would need to incur the ATM fees to buy Bitcoin, and THEN incur the fees to Shapeshift to Dash. It would also take a heck of a lot longer in such a multi-step process. Therefore, even without InstantSend, acquiring Dash with a Dash-enabled ATM is both cheaper and faster than the approach you suggest. This has obvious value.
 
@kot
Here is a video with the robocoin machine. They had to wait 22 minutes before their bitcoin was confirmed. (skip to the last 2 minutes)

Pretty obvious benefit to not wait that 22 minutes by using InstantSend.

@babygiraffe Thank you. I appreciate your efforts to get us on the path for InstantSend. The reduced fee is relative. TigoCTM is taking 1% for the privilege of accepting Dash. The shapeshift fee is close to that. Using Dash without InstantSend falls into the preference category. Certainly, not a need like reducing the 22 minute wait to exchange Bitcoin to Cash.
 
Last edited:
@Solarminer Yes, with Bitcoin's congested network and infrequent blocks, I think 22 minutes probably happens a lot. With our blocks 4x more frequent and no where near as congested, I think the probability of waiting that long for a Dash transaction is extremely low right now. So I don't think that same experience will apply to Dash ATM transactions even without InstantSend enabled. But your overall point is nonetheless valid... that InstantSend is better than waiting, even if with Dash it will only be one tenth as long as that video.

Concerning Shapeshift, the fees are upwards of 4.5% from time to time. 1% is kind of a best-case scenario. I think it's also important to remember that Tigo's fees are to provide services above and beyond exchange services (which is all you get with Shapeshift), so it might be unfair to compare the two directly. Tigo provides software support, compliance in some jurisdictions, inventory management, etc.
 
You must log in or register to reply here.
Back
Top