Is a soft or hard fork the only way to upgrade a cryptocurrency network? Evan Duffield discusses why Dash invented a new way – called “Sporking” – along with Spork risks, benefits, and unexpected future plans. Not very technical yourself? Stumble through with Amanda B. Johnson.
English Text of Video
(for other languages click the sprocket icon then select “Subtitles/CC” on the bottom-right of the above video)
Hi, I’m Amanda B. Johnson and you’re watching DASH: Detailed.
Once in a while there comes a time to delve deep into a highly-technical aspect of the Dash protocol. Especially if it’s particularly important or unique to Dash. In this case, Sporks are both.
Now when I first started researching Sporks, I came to learn that they are a pseudo-centralized aspect of Dash. And that of course got my gears grinding.
So to find out what exactly it is that a Spork does, how its benefit could possibly outweigh the risk of its pseudo-centralized nature, and whether there are any plans to phase Sporks out, I called founder and lead developer of Dash, Evan Duffiled. And here he is.
AMANDA B. JOHNSON: Well Evan, thanks for joining me. And how are you today?
EVAN DUFFIELD: I’m doing very well thank you.
AMANDA B. JOHNSON: Nice I see you have some nice shrubbery or a tree there in the background. That’s nice. Excellent.
EVAN DUFFIELD: Yeah I have a green thumb. I’m working on it.
AMANDA B. JOHNSON: Oh I didn’t know that. I’m sure that that is a neat tidbit for anyone else who didn’t know that. So Evan, as you know, today I wanted to ask you about Sporks because I believe that the first time I ever heard that word used in relation to a cryptocurrency, and not like say, KFC takeout, was in relation to Dash. So is there anything I need to know about first before we get into Sporks?
EVAN DUFFIELD: Ok, so Sporks are built on the foundation that Bitcoin left us. And basically what it uses to – to control the network…
AMANDA B. JOHNSON: What a Spork uses or what Bitcoin uses? You know, before we do the foundation will you just tell me like in layman’s terms like, what is a Spork? Like if it’s not a plastic spoon/fork, what is a Spork?
EVAN DUFFIELD: A Spork is somewhere in between a hard fork and a soft work.
AMANDA B. JOHNSON: Okay.
EVAN DUFFIELD: And they’re – they’re controlled by the the network itself. You can think of them kind of like global variables on our network.
AMANDA B. JOHNSON: That sounds, that sounds like a lot of programming talk to me. So before we get into that – I know you can’t help it – like, when you’re thinking up in this level and I’m thinking like down in this level, you’re like, what words can I possibly use to make you understand?
So before we get to that, let’s first lay down some definitions of a hard fork and a soft fork. If I recall correctly one of them like, makes it a rule within the protocol, like no longer applied for all former blocks, whereas the other one says
hey, there’s a new rule but it’s only for all blocks going forward. Is that the
difference between a hard fork and soft fork?
EVAN DUFFIELD: Pretty close. So hard forks change the rules and – at a future time. Where like, if it – let’s say, you want to change the way blocks are accepted on the network and it’s going to invalidate existing good blocks. Well you can’t do that unless you do it in the future and then you get up a large majority of the network to update before that’s triggered.
AMANDA B. JOHNSON: Ok. So a hard fork – in order to change the rules you have to get a majority to update otherwise, what? Like chaos or something?
EVAN DUFFIELD: Yeah. They use supermajorities to – to do it. And the the Bitcoin code, which basically means that you start counting the blocks that are coming out of – of the different implementations. And then once you get a threshold then you move from these like, softer rules to these hard rules. And then you start rejecting the – the blocks that don’t meet the criteria.
AMANDA B. JOHNSON: Ok, so a hard fork changes the rules at some point in the future and hopefully everyone agrees on them and now then, what’s this soft fork?
EVAN DUFFIELD: So soft fork just reduces the the amount of blocks that – that will be accepted. They – they tighten the rules. But not in a way that will invalidate blocks. Instead what they do is they rely on the longest chain. And so they can change rules around a little bit with without causing the the network have to update in this very precise way with – with the hard work. So there’s a little bit more flexibility.
AMANDA B. JOHNSON: So if – if it’s soft fork in Bitcoin were to be pushed out for example, if people don’t have to update to it, what like, if it doesn’t make nodes which don’t update to it, like relaying invalid stuff, what would be the reason to update at all to it?
EVAN DUFFIELD: You know there’s – there’s not a whole lot of incentive other than supporting the network.
AMANDA B. JOHNSON: Ah, supporting the network. Okay.
EVAN DUFFIELD: Yeah, and we’re back to that again. It – it’s like herding cats. Once you have thousands of servers and a bunch of implementations running all – all together in parallel, it’s really difficult to figure out which one should we be running and and trying to keep all of these things updated. So you know, there’s – there’s no really good way of doing that without some of the – the Dash technology which addresses those issues directly.
AMANDA B. JOHNSON: Ok. So do any other networks use Sporks or is this a Dash-specific thing?
EVAN DUFFIELD: It was invented by Dash. I’m, I’m – I don’t know if anyone else has adopted them to my knowledge they’re – they’re not used anywhere else.
AMANDA B. JOHNSON: Ok, so with that foundational knowledge behind us, what then is a Spork in Dash?
EVAN DUFFIELD: Ok, so the – the Sporks in their current implementation, it’s – it’s basically where the developers have a way of switching a variable on and off remotely. And so they can say, let’s watch the network and rather than relying on counting blocks and in doing these – these other more complicated things, we’ll just be administrators, and when we see the threshold reached to safely update the network, we press a button and then the – the network says, oh the developers say, it’s okay, let’s switch from A to B.
AMANDA B. JOHNSON: Ok.
EVAN DUFFIELD: And so, it can be switched off as well which, with – with these other types of forks they’re – they’re simply once turned on they – they can’t be turned off without another update. And…
AMANDA B. JOHNSON: So is this fork then a message? Like it’s a message that’s sent out from the network from developers or what is it?
EVAN DUFFIELD: Yeah, it’s a signed message where we sign a specific key – very similar to the alert key – and it says, I want to change this specific variable. There’s – there’s like, 12 or 13 Spork variables for different – different updates that we’ve done in the past. And you can switch those on and off with that key.
AMANDA B. JOHNSON: So what kind of variables are we talking about? Are we talking about variables that exists in the client implementation that the – the person was already running? Or is this a variable within the new version that they are running if they chose to run it at all? Assuming that we’re talking about these things happening in the case of a new version of Dash being pushed out.
EVAN DUFFIELD: So it would be a new variable if it’s a new Spork. If it’s – if it’s an older feature we – we carry those variables forever so you can continually update them. But – but we’re in the same situation where we need people to update to the newest software so that they – they have the messages to understand what the Sporks do and what they mean. And in all of that.
AMANDA B. JOHNSON: So then are Sporks sometimes used not in the case of like, hey we’re in the process of pushing out version – the next version? Are they just sometimes used in an interim time?
EVAN DUFFIELD: They’re mainly used for triggering these – these features. Like they’re used to enforce masternode payments on the network.
AMANDA B. JOHNSON: Ok.
EVAN DUFFIELD: They’re they’re used to flag whether we would accept the the older version of the masternode software and we – we can basically do a smooth transitional update using just those two forks where we give people a time period. Like we say, between five and nine days of of time you – you have to update. After nine days we’re going to flip it no matter what. Right?
And so we we can create these – these much more complicated ways of updating. But there – there lot more simplistic for the network operators and for us to – its kind of like cheating. We figured out a way to – to do the – the hard forks and soft forks with about ten percent of the code.
AMANDA B. JOHNSON: Ok. It’s kind of like cheating. Alright. It sounds like cheating. Ok so let me – for, for the – let’s bring it down a bit. So you’re just giving me some examples of these variables, one of them being whether or not masternodes get paid. What are some of these other variables that you have a private key to turn on or off?
EVAN DUFFIELD: Ok. So there – there are many different Sporks that are supported currently. We have Sporks ranging from InstantSend – enabling it, doing block filtering, so that we if if there was a an exploit or something that came out that that would continually fork the network based off of this technology, we can trigger that at will, and it would make the network safe to to use during that period of time.
This is something you simply can’t do with a hard fork or a soft fork because it’s – it’s something that the administrators need to… to have some – some power over. The – the only issue with the Sporks is that it’s a singular key. And it’s – it is controlling a decentralized network. And so what we’re doing for that is we have a multi-sig implementation for Sporking where the – the main core DAO has multiple keys and it would take multiple of us to sign these messages to turn these things on and off.
AMANDA B. JOHNSON: Hmmm.
EVAN DUFFIELD: There’s – there’s also a another way of doing it using the Sentinel code, where the masternodes can vote on specific objects, and using their voting power, once they hit a threshold they can trigger the Spork as well. And so we get…
AMANDA B. JOHNSON: Oh. It slays me when you say, “objects” by the way. I have no idea what that means but please continue.
EVAN DUFFIELD: There’s – there’s these governance objects now. Some of them are proposals, superblocks, the user profiles. We can make them at will using Sentinel.
AMANDA B. JOHNSON: Oh.
EVAN DUFFIELD: Just by making new types and then implementing some rules here and there. And so one of one of these – these objects could be a Spork and then to enable or disable it you would, you would have the masternodes vote yes or no on it. Just like you do a proposal and then that would implement some code in Dash D, and – and then we have a perfectly decentralized Spork technology.
AMANDA B. JOHNSON: Okay, okay. So you’re telling me that in the current version of Dash these on-off switches that can basically affect the entire network, or rather, the entire network who is running the majority version of – or rather, that contains the version that contains the Sporking capability – currently the ability to flip these switches on and off resides with a few members of the core team who have the keys to a multi-sig address.
But you’re saying that it – when Sentinel is implemented and I don’t – I don’t know, 12.1 or later, you’ll telling me that in a moment I’m sure, that it will move from being like a – this is something that for example, only Holger, Evan, and Ryan in can activate – to something that is rather voted upon by all the masternotes. Is that correct?
EVAN DUFFIELD: Precisely. Current…
AMANDA B. JOHNSON: Wow. And this is what I wanted to talk to you about it, because when I heard of Sporks and when I, like I would – I asked someone in like Slack Chat one day, I was like, what are Sporks and how do they work? And when they told me, like basically what you told me, I was like, wow that… that sounds like something that like can and – not even can but should be like decentralized eventually, right? And you’re telling me that this is possible and that this is going to happen?
EVAN DUFFIELD: I mean, really what we’ve been doing over the past three years is implementing the… features that we want and need to run the network with the least amount of effort possible. Because we have limited resources we have limited volunteers we just we don’t have a lot of time and and we want the network to – to function the the way that we envision it.
And so to implement the – the way that I’m describing to you it’s at least 20 times the work. But I mean to to get there from here – we – we have a clear path now and we only expose the network to the centralized risk just for a little while, while we actually use the functionality proved that it worked before implementing the – the way, way harder version of it.
AMANDA B. JOHNSON: Ok.
EVAN DUFFIELD: And so I – I think that’s the best of both worlds really.
AMANDA B. JOHNSON: Ok. So with this, as you say, centralized risk having been implemented and in use for some time now, what are the benefits of it that have made the centralized risk acceptable?
EVAN DUFFIELD: Whenever we’ve updated the network – for example in the 12.0 release we used Sporks to do it. That – the issue with hard forks is that you have to bind them to blockchain-based variables, and we simply don’t have a blockchain for the masternode network, which leaves us in an odd position because we have to be able to enforce masternodes payments. If, if the, if we need masternodes stored in the blockchain – and that’s – that’s also going to be really difficult to to achieve in the eventual…
AMANDA B. JOHNSON: What do you mean masternodes stored in the blockchain? What does that even mean?
EVAN DUFFIELD: Oh ok. So when when you’re getting the masternode list of all of these available masternodes on the network, two peers could have different lists. And that they might be one or two off. And I mean, this is – this has been something that has, that’s happened with our network for since the the very beginning. And we’ve – we’ve flushed out most of those changes.
AMANDA B. JOHNSON: What are the lists used for? What – like why would my client compile a list of masternotes?
EVAN DUFFIELD: They’re used for payments. So that’s – that’s how we calculate the payment queue.
AMANDA B. JOHNSON: Okay.
EVAN DUFFIELD: Alright. And if there’s two lists on two different machines that are one-off, it means that payment queue is going to skip that one that’s different, depending on which machine you’re on.
AMANDA B. JOHNSON: And that’s gonna make an unhappy masternode user – owner.
EVAN DUFFIELD: It’s gonna make up fork is what it’s going to do because once – once you enforce who gets paid they have to agree all of the time.
AMANDA B. JOHNSON: Oh.
EVAN DUFFIELD: That’s – that’s how blockchain technology would fix it. Because you have an immutable record of who’s been paid and who should get paid next. But…
AMANDA B. JOHNSON: Oh. Ok. So if two different clients are making two different payments then it creates a fork because the record of past payments is now different.
EVAN DUFFIELD: Correct. But there’s – there’s a one – one little thing that – that’s a little bit off. It’s the difference in payments is caused by one of the two peers not knowing about a specific masternode.
AMANDA B. JOHNSON: Ok.
EVAN DUFFIELD: And we can get around this with a Spork. We can – we can utilize some of, some of this technology so that we can turn off the payment enforcement for a period of time to allow the network to update all of these thousands of masternodes. And then, once they’re all updated on the – the new software, we re-enable it. Payment enforcement turns back on, and then we’re golden again.
AMANDA B. JOHNSON: So the people who hold the private keys for this multi-sig address that can flick on or flick off Spork variables – I mean like, during these times when there’s like, an upgrade being pushed and there needs to be a monitoring of masternode payments or whatever, are the people who hold the keys like… like drinking espresso all through the night and watching the network 24-7? Or like, what’s the process of even monitoring these times?
EVAN DUFFIELD: Yeah. So I tend to live out of cafes when I’m when I’m working and doing the updates so yeah there’s there’s a lot of expresso going on.
AMANDA B. JOHNSON: It sounds like it.
EVAN DUFFIELD: And then once – but it’s actually a lot easier than that. There’s – there’s some commands you can use to figure out how on the same page the network is about who’s supposed to get paid. There’s – there’s a command that will show you which masternodes are being voted for to get paid and it’ll tell you if there’s two masternodes with about the same amount of support. And when you – when you see that then you you know that the network is still in a state of updating. Once it…
AMANDA B. JOHNSON: So tell me about this. Okay. These – this terminally – this terminology you just used. The masternodes getting voted for to get paid. Maybe I was under the wrong impression. I thought that masternode payments were determined by like, randomness from the hashes of miners. Is that actually not how they’re paid? Or is it masternode quorums? Paint me the picture. I think… I don’t know.
EVAN DUFFIELD: Okay. Both are – both are true actually.
AMANDA B. JOHNSON: Both! Oh, okay.
EVAN DUFFIELD: So what happens is there’s this deterministic algorithm, and it’ll go through all of the older masternode payments, it’ll calculate who should be paid next based off of the history, right? And then it’s looking at the existing masternode list. If – if it sees you know, masternode X, masternode Y, or masternode Z, hasn’t been paid in the past few thousand blocks and it looks like it’s the next one using the deterministic algorithm to get paid, then if it’s in a quorum for – for that specific block then it’ll vote on that specific masternode.
AMANDA B. JOHNSON: And what kind of quorum is this? Is this an InstantSend quorum or what kind of quorum is this?
EVAN DUFFIELD: They’re all the same really. They all use the same technology. The – the quorums are basically where you – you take the proof-of-work hash from the – from a specific block, and then you compare it to the – the masternode hashes using this algorithm to calculate the distance between the numbers. And then based off of that, you make decisions.
AMANDA B. JOHNSON: So then there are payment quorums? So if the – if the algorithm checks the current – if the other algorithm is looking through all the masternodes, identifies the ones which have not been paid for X thousand number of blocks – if that particular masternode is currently within the payment quorum of that block that’s when and why it gets paid?
EVAN DUFFIELD: Very, very close. The – the masternode that’s getting paid is outside of the quorum. So he – he’s one of four thousand masternodes that could possibly be getting paid. There’s a quorum of voters and they’re – they’re subset of the masternodes. There’s ten of them per block.
AMANDA B. JOHNSON: Ok.
EVAN DUFFIELD: And those – those 10 votes that determine who gets paid.
AMANDA B. JOHNSON: Got it.
EVAN DUFFIELD: What I was – what I was talking about earlier when I was saying that there could be differences of who gets paid on each block – what I mean is like, if there’s ten masternodes voting on a specific block and six of them say X should get paid and four of them say, Y should get paid, we haven’t reached consensus yet. And that’s when – when we reach consensus is when the Spork gets turned on.
AMANDA B. JOHNSON: Now why would you… oh you mean… Ok, got it. That – that’s when the Sporks says, ok, it’s ok to do payments now because now consensus is being reached.
EVAN DUFFIELD: Uh-huh.
AMANDA B. JOHNSON: Got it. Okay. And to be clear, I was gonna… I wanted to make a clarifying point for anyone who is perhaps on the even less-technical end than me, if that’s even possible – that when Evan says votes, he’s not meaning like masternodes votes that people do manually where they’re like, voting for treasury proposals like, yes or no, this thing should be funded. But rather these are like automatic votes that the masternode software is doing itself. Not that like a human is doing at their keyboard.
EVAN DUFFIELD: Yeah. Precisely.
AMANDA B. JOHNSON: Yeah okay. Not that – I don’t even think that any like non-technical person, or a person who doesn’t aspire to be technical, will even watch the episode this far. But just in case.
EVAN DUFFIELD: Alright so then, this decentralization of the Sporking function that you’ve mentioned in that it – it will be put into the hands of a masternode votes. What – what version is that? Is that – is that 12.1 that’s being tested now? Or is
that still down the road?
EVAN DUFFIELD: So 12.1’s that the foundation for all of this. It’s essentially the administration software for our DAO. It’s going to allow us to to build these – these systems that – that secure the network in a much more decentralized way. Like – like I was saying earlier with the objects, we can make objects that will – that do really complicated things. And – and they do it outside of the Dash D c++ and then we – we actually just use these, the Sentinel voting mechanisms to trigger things to happen in Dash D.
So we – we’ve isolated the – the business technology or I mean, the – the business flow and the – the business software from the the network software, which is Dash D. And we – we’ve moved that into a higher-level language, which is Python. And then by using – by using this Python and updating after – after 12.1 is released, we can start making features for Sporks, and for building Evolution user accounts, and in things like that.
AMANDA B. JOHNSON: Alright, so I think I have pretty much like one or two wrap up questions for you. Basically, I unfortunately, because of a timezone miscalculation as I mentioned to you earlier, I’m just crap with time zone sometimes – so I missed the Q3 core team report call in which I’m quite certain that you all gave a status update as to 12.1 and it’s testing. Since I missed that, and for anyone else who may not be caught up with that either, what is the status update?
EVAN DUFFIELD: Sure ok. So with 12.1 the – the best way to explain it – this is our pivot from basically an operation that was ran out of a garage for a while. I – I was the sole full-time developer. I wrote all of the original software. And then we got 12.0 and we basically raised about a million dollars which we’ve – we’ve gotten like a nice team.
We have a really solid programming team now of about 20 people between the Evolution team and the Dash D team. And we’ve – we’ve shifted off the – the way that we we do work to a much more classical way of – similar to how other organizations have have modeled themselves to – to operate. And we’re moving over – over to this during – during 12.1.
12.1 is also going to be what is administrating this organization. The network has literally all of the power over everything that happens still. But we – we need software to run for this process. We need – we need to be able to have milestones and we need to be able to release payments for these proposals.
Like what if we want three milestones for a project that takes a year and we say we want XYZ for each of those milestones. And then you have someone, like the project managers, voting on releasing the milestones, or in releasing the funds associated with the milestones. These are the types of things that – that were going to be utilizing based off of this technology.
The most recent thing that happened is we hired Tim and a few other people who have taken over the main development on Dash D. And they’re – they’re doing really good work. They have been working on on the test-net implementation and have found some issues with Sybil attack on test-net, fix that using a new proof-of-service implementation called Watchdog.
And these – these are the last changes before we start testing superblocks on – on 12.1 ,and that’s literally the last thing we need to launch. So we’re – we’re pretty close. We just want to make sure that we don’t damage the network in any way when – when we update. We’re – we’re not a huge hurry. We were like really well positioned and we just want to be careful with you know, a 70 million dollar network.
AMANDA B. JOHNSON: That’s a nice thing to be able to say. Like, I feel like we’re really well-positioned. Ok, so – so then – so this Watchdog thing is still sembling – sembling? – something to yet be implemented into what’s being in to – what’s being tested? Into 12.1? I guess I didn’t know that if something was being tested it could be updated like even within the testing?
EVAN DUFFIELD: Yes. So Watchdog is fully implemented, we’re running it on test-net currently. And it’s working it – it found all of the the nodes that didn’t update and has flagged them so we can, we can issue the – the command to update the network and fork off of the old clients using a Spork again. Same – same technology. And we’re – we’re testing this because this is gonna be the exact same thing that happens on main-net. The purpose of Watchdog is to prove that Sentinel is running.
Basically, Watchdog’s another object, so this is another governance object-type, and it – it allows Sentinel to vote per masternode in say, yeah I’m – I’m watching this object and I see that I need to vote on it. And if you don’t vote on it, you get flagged. If you get flagged you get removed from from the payment queues and from the masternode list. So it’s – it’s the proof that the whole thing is operational on – on the masternode.
AMANDA B. JOHNSON: And am I… Does that mean all masternodes will have to vote on everything hence forth? Or did I just totally construe something that’s not there?
EVAN DUFFIELD: Oh. So Sentinel uses automation for a lot of this. It runs in the background every couple minutes. And so the masternode software…
AMANDA B. JOHNSON: Oh.
EVAN DUFFIELD: …it like look – sees there’s a Watchdog object. Pulls it in. Looks at the rules associated within Sentinel. Sees that it needs to vote on it. Votes. And then Dash D on the other side knows how to deal with that. And will flag, and alter the list, and all of that good stuff.
AMANDA B. JOHNSON: I see. So this being again the difference between like manual human voting and like automated software voting?
EVAN DUFFIELD: Yeah. I think we need different terms or something. It’s kind of getting confusing.
AMANDA B. JOHNSON: I do too! I’m going to think on that.
EVAN DUFFIELD: Yeah.
AMANDA B. JOHNSON: Yeah. Okay. Well, as a final question…oh yes. As a final question – and actually had I made the call, has I made the core team report call instead of messing up the time of it, what I wanted to ask is, is there a shortage of testers?
EVAN DUFFIELD: Yeah. We could actually use a lot more testers. We – we’ve had the the really hardcore testers come in and those have been wonderful but I think it’s time to actually start doing some more thorough testing of just making sure all the
functionality works. So if – if anyone is interested we can throw up a link to – to that forum post.
AMANDA B. JOHNSON: Okay. Well before I’m going to do that, I’m going to ask you point-blank, where is the treasury proposal to incentivize testers?
EVAN DUFFIELD: That would be a good idea as well.
AMANDA B. JOHNSON: Yeah! That’s a good idea because I’ve gotta say Evan, like within the Dash ecosystem it seems to me that incentives are aligned properly just left, right, and center, which actually, was the first reason I started looking into Dash to begin with.
I was like, oh there are people who understand incentives which action – which is in it complete like, scarcity within the crypto sphere if you ask me. But this one particular thing, that like testers are expected to volunteer just seems like an anomaly. Like someone definitely overlooked paying testers.
EVAN DUFFIELD: Yeah, yeah. That sounds like a pretty good idea. Maybe we could give away like a few dollars worth of Dash. I don’t even think it needs to be a ton of money but I’m totally willing to pay people for their time. And I – I believe that’s actually what makes Dash successful and just different than everything else.
AMANDA B. JOHNSON: Yeah. Well think on that Evan. Just think on that a bit if I may encourage you to do so.
EVAN DUFFIELD: Will do.
AMANDA B. JOHNSON: Because I would be interested to test, if there were a bit of compensation and just a – like a a guide that someone like myself could follow to be like, oh this is what I do, then this is what I do, and then this is how I know I’m done. I would like to contribute.
EVAN DUFFIELD: That’s a good idea too. So we could make a testing guide that – that just directs you through it, shows you which buttons to click, and all of that.
AMANDA B. JOHNSON: Yeah.
EVAN DUFFIELD: Alright. Yeah that – that sounds like a great idea.
AMANDA B. JOHNSON: Okay excellent. All right. Well, with that I will thank you for your time and as always, it’s been a pleasure to talk.
EVAN DUFFIELD: Thank you. Yeah, it was fun.
AMANDA B. JOHNSON: Ok, bye Evan.
EVAN DUFFIELD: Bye.
Howdy friend, Pete here. I’m the behind-the-scenes guy at DASH: Detailed. You may know me as the “Manservant.”
I had an idea for a future episode and wanted your help. The episode is to be titled, “Ask A.B.J.” – A.B.J. being Amanda B. Johnson – and I just thought it’d be fun and interesting to hear what questions you had for her, about Dash or cryptocurrency.
So please take a moment – if you have any questions – and let me know at “TrustThyself @ riseup.net” and she’ll answer them in a future episode. So again, “TrustThyself @riseup.net”. Look forward to hearing your questions.
And until next week, take care. Peace.
Music: “We Are One” by Vexento https://www.youtube.com/watch?v=Ssvu2yncgWU
Get social & learn more:
Dash homepage: http://dash.org
Dash Twitter: http://twitter.com/dashpay
DASH: Detailed homepage: http://dashdetailed.com
DASH: Detailed Twitter: http://twitter.com/DASHdetailed
Send some Dash love to Amanda B. Johnson & the DASH: Detailed team: Xm3Fk5Yx73EW8LV1K2qstyox8bvvcqgqjd