Radix AMA #1 [Full Video + Transcript]


#1

# Full Transcript

0:00 Piers: Alright. Let’s jump into the questions because we’ve got quite a few questions on our sli.do. Thank you very much everyone who has done that. We’re going to start off with the topped-rank question. We have 81 questions, the first one is:

Question #1: Usually, engineering in this space involves making tradeoffs (like the scalability trilemma). What are the biggest downsides of the Radix approach?

0:35 Dan: Downsides… well Radix is designed to hopefully not have many of those. It is interesting that the scalability trilema has been quoted in that question. It makes me think a lot about the CAP Theorem. Now CAP Theorem says you’ve got these three things: consistency, availability, and partition tolerance. And it’s another trilemma - you can only have 2 of those 3. But what a lot of people seem to make the mistake of with CAP Theorem is that you can only have 2 of those 3 at any particular moment. So you may have availability and partition tolerance, but your consistency across the network isn’t consistent. But then at a different time depending on what the network is doing you can have consistency and availability but no partition tolerance. So the approach that was taken with Radix was the same kind of approaches with CAP Theorem. OK. So you can’t have all three at any particular moment in time but you can have two of those three and you can make some small trade-offs across the one, depending on what combination you are trying to achieve. For example in Radix, when you have an exotic conflict, we trade off a little bit of the decentralization and a little bit of performance to resolve that conflict, but that doesn’t affect the entire network the way that network is structured with gossip, the mass, which nodes are selected to actually deal with those conflicts. So those three components of the scalability trilemma they’re kind of relevant for each transaction and each transaction can be affected by a combination of those three individually at different time. So that’s kind of about the best you can get. So instead of trying to make the whole network always a hundred percent decentralized and a hundred percent scalable and a hundred percent secure, you can trade off bit of decentralization and a bit of performance on some nodes per transaction, so that you can still maintain a good approach into all three across the network at any one time.

The downsides of radix honestly I still can’t think of any. It’s why it’s taken such a long time to actually build this thing because I try to maximize the upside and mitigate the downside. I’m sure there are some.

3:30 Piers: Probably the best description of the downside is the edge cases of it being probabilistic, right? It’s a probabilistic consensus or probabilistic network and so you need a minimum number of nodes in the network for you to be absolutely sure.

3:48 Dan: Yeah, so if a network is small, then, like all distributed networks, your exposure to attack is more. Yeah it’s strength in numbers, but then any kind of distributed network has that same issue if it’s small and it’s not permissioned then it’s fairly trivial to attack until it starts to get to a few thousand nodes or larger. I suppose like with Bitcoin - the way that Bitcoin operates - if you accept the way that it operates is kind of de-facto, then there aren’t really downsides as long as you accept the limitations that it has. I think that we’re still yet to discover what those limitations are with Radix because everything we try to do so far we’ve been able to do quite easily. But that’s only because we’re still kind of taking traditional use cases and traditional applications and building those first because that’s what we know. I think once we start to get into more complex, more advanced multi-user use cases on the platform I think then we may start to see what some of the downsides may be where maybe have to make some trade-offs in terms of what can and can’t be done. As of right now it’s performing as expected, I’m pleased to report.

Question #2: Do you think you will have enough time to integrate DEX, economic model, and atomic swaps before going live in Q1 2019?

5:10 Dan: Tentatively: Yes. The issue recently has been that we’ve had to make a few changes to the protocol for a number of reasons: 1) Security, 2) A bit of performance and also 3) For longevity of the platform in terms of what we can do functionally that’s easier to build now than later on. That’s taken a little bit more time than expected as these things sometimes do - but the team is growing. We’ve got some really good guys and so I’m confident that we can claw back quite a lot at that time. The R&D on the consensus, the architecture, and the ledger is now officially over. After such a long time that doesn’t immediately feel real, right now. It’s kind of like a bit surreal dream. It’s finally passed all of its tests. To give it a bit of context, I’ve had these particular test cases that I’ve been trying to get the technology that we’ve been developing for the past six years to pass. Some of them are really nasty, complicated exotic double-spends, etc that have never passed. Ever. And, over the past two weeks, it started to pass a few more of the ones that have never passed before. Then as of last week and this morning, the last portion passed every single one! So that kind of draws a line under the R&D. These kind of edge case attacks were basically like running the network with the equivalent of a 50.9999 percent attack on Bitcoin - and it held up. So that kind of proves all the theory. We’ve tried on a network. It’s all been tested and unit tested. We’ve regression tested it against the alpha network as well. So from this point forward you should be able to pick up a bit of speed because when we won’t be bottlenecked by any remaining R&D issues on the platform side of things. So now we can go full steam ahead on DEX, economics, start thinking about how to integrate Scrypto, non-fungible tokens and all these nice things that we’re currently working on. As a growing the team, then I think we can hit everything just about by Q1.

Question 3: If RadixDLT is not going to sell tokens, then how are you going to monetize your years of hard work?

7:48 Dan: Donations! [laugh] Lots and lots of donations. So we’re still kind of trying to figure out actually what our revenue models are going to be like over the long term and there’s a few obvious ones such as consultancy and obviously we’re gonna run some nodes ourselves that take part in transactions and they’ll collect fees and rewards - that kind of stuff. I think the kind of business models that you can apply with this technology, it kind of sits in the same category as the things which we’re currently trying to build on. I mean, it’s such a new tech that there are probably many novel ways to monetize this stuff over the long term but no one’s really figured out what those models are yet. We’re still trying to apply old business models to this kind of new tech. So aside from the obvious I think they will emerge as and when we start to see the developers come on board and interesting applications and maybe there’s some ideas that we have applications in the future that we can build and we can monetize to reward and monetize our years of hard work. But I think that will be an ongoing process much in the same way as it is in any emerging industry.

9:15 Piers: I think our approach here is very much first and foremost how do you ensure the success of the platform and then secondly how do we make sure that we get rewarded for that success - in a proportionate and fair way. So much of our focus to date has been on that first bit. How do you make sure the platform can be successful. How do you make sure that any barriers to entry, for anyone using it, are as low as possible – to reduce the friction for when it drops so that people can kind of use it in all of the wonderful weird and exotic ways that people have already started using DLT technology. So for us that first key piece of making sure the technology is right and making sure that that all works comes first and then the second part how do we monetize it, I think that as we go closer to implementation and as we sort of start to think more about the next level up; everything from governance to how the atom model functions with the fees, to how the DEX functions and then to how we’re going to put the Radix network live, there becomes more and more areas where we’re like okay so here is a fair way of rewarding foundation, here’s a fair way of rewarding the founders of the company. We’re not going: this is how we want to make money and then how do we shoehorn that into the platform. We’re going: how can the platform be successful and then making sure that there are revenue streams out of that to ensure the longevity of the platform and also to make sure that obviously Dan and the team are rewarded for the hard work that’s been put up in to date as well.

Question 4: Do you see any competitors to RadixDLT in terms of scalability (like Ethereum, Zilliqa, Constellation, Hedera Hashgraph, IOTA, Holochain, etc.)

11:00 Dan: Interesting question and there are some quite ingenious ideas out there on how to scale these kind of technologies and honestly I’ve been outside the camp of most of those ideas for quite some time and some of them I even tried them a few years ago and determined the amount of effort to make them succeed outweighed any benefits they would bring. I think that once we start to be able to move a bit faster on our scalability testing which has also been bottlenecked by what we’ve been working on recently and we can actually start to achieve those high numbers I think I can have a lot more confidence in saying: “no”. Hitting a million TPS is hard … really really hard. I spent five years of my life trying to figure out how to not even get to that - originally the goal was to get to Visa scale - now that was back in like 2012-2013. Then with the obvious emergence of IOT devices and all these other connected things that will be around in the future; your fridge, your toaster, your car, whatever… all connected… supply chain and all these kind of things… it became apparent that Visa scale just wasn’t enough. So looking forward I think that for any kind of DLT technology to be really viable in the next decade you’ve got to be hitting a 100K a second at least and to achieve that really is quite difficult. It’s not just a case of: Yeah, I got a blockchain and can put some side chains on it and Bob’s your uncle and everybody’s happy and you can have toasters and they can chat with each other and that kind of stuff.

12:56 Piers: I think that the type of transactions per second what is actually being done needs to be really underlined as well. In some of my talks I talk about the “decentralization ratio” which is the number of nodes that the final arbiters consensus divided by the total number of nodes on the network, or the total number of full nodes on the network. And if you look at systems that use some sort of delegated consensus algorithm or some sort of centralized authority or even like a consortium of authorities, those consortia tend to remain the same size and they can’t get larger purely because very often there is a constraint of the synchronicity of the system. Blockchain is a synchronous system so something like EOS needs to have these these coordinator nodes/validators. And so they need to actually be a small number and stay a small number because you can’t move the information fast enough between the nodes otherwise you come the same problem that you do with a sort of a standard blockchain. So if you take the total number of nodes the final arbiter of consensus divided by the total number of nodes in the network; you get this decentralization ratio and what you see with any coordinator based system is as the network grows you tend towards fragility so that numerator on the fraction doesn’t get much bigger and so it stays about the same time but the denominator ends up being getting larger and larger and larger, so you get this you you end up getting a smaller and smaller ratio and the network ends up being more and more centralized. So when we talk about centralized and decentralized and when we talk about things like side channels and stuff like that, yes you can do a million transactions per second in a side channel but you have a problem as soon as you need to get out to that side channel into another side channel you’ve got your main blockchain problem and then if you look at something like IOTA or any of the DAG based ones, again they have these coordinators or they have these constellations of economic constellations where again you have a small number of nodes that are responsible as the final arbiters of consensus of the network and it’s not really a fully decentralized system. What you really need is to move away from that because if there is ever a sense of the network you have it you have a state of fragility and as it gets bigger and becomes more important to the world it becomes more fragile. So yes there are competitors to Radix in terms of scalability just from the point of view of: are there other projects that are attacking scalability but from our point of view we don’t see any projects who are able to do full scalability and full decentralization. It’s always a hybrid of one and it comes back to the trilemma that Vitalik Buterin first put out.

16:12 Dan: So getting back to the final arbiters of consensus. The best way to think about the way Radix deals with that is that each transaction has a set of final arbiters of consensus, but that’s each transaction for each transaction that would be a different set. So even though you get a particular set of nodes that are responsible for resolving a conflict on a particular transaction the rest of the network is doing other transactions so in essence your division of arbiters versus full nodes, it doesn’t dilute quite as badly as say a vertical blockchain system or a DAG because it’s per transaction. So it’s not like a block where you’ve got a bunch of transactions in there. And because it’s per transaction as well… and each transaction has a different set, it’s very nicely load balanced around the network and so every transaction has a different set of nodes that deal with its consensus and that also makes it, of course, very difficult for an attacker to take control of that consensus algorithm as well because he needs to then have many loads and in the right places and you need to know where those nodes need to be when you’re producing the transaction and he needs to spend a lot of time, money, effort, and logistical work to put his nodes where he needs to be to take the transactions. So yes that’s the background on that interesting tidbit that he brought up.

Question 5: Has the protocol the same problems with forks as bitcoin when new/updated stuff gets implemented?

17:46 Dan: In terms of upgrades, yes you can have the same issues. So I don’t think there’s ever going to be any kind of DLT that solves that because you’re gonna have stakeholders in the network and some of those stakeholders maybe won’t like the changes that have been proposed by the main devs. So you may get a Radix classic at some point if there’s a set of node operators in the network that don’t like the changes that we proposed. I don’t think it’s quite as detrimental as it maybe first appeared way back when – when forks of Bitcoin starts happening you got Bitcoin and Ethereum classic, Bitcoin gold and Bitcoin Diamond and stuff. Because Ethereum and Bitcoin are still the granddaddies of those particular technologies and then you kind of have these niche implementations that’s still a particularly use, which is fine and I don’t think there’s a legitimate way to prevent it even if you wanted to and then you get into the morality of it all while should we prevent it? It is supposed to be an open decentralized system so if you’re forcefully preventing forks – it’s not really decentralized anymore anyway.

Question 6: Are there any circumstances under which the economics system would generate XRD and transact directly on the DEX, bypassing holders and node runners?

19:09 Dan: So there’s a lot of questions about economics in here and I don’t really want to get into too much detail because we’re still ironing out a lot of the bits and pieces. So all I will say regarding the economics and I apologize for everybody here who’s asked all the questions and I don’t want to go into too much detail before its final because then everywhere I go from that point everyone will be like; ‘you said this, you said that’. So there will be times when the DEX or the system will intervene in the economy via the DEX to buy or sell trades based on a supply and demand function algorithmically-- not decided by us. It’s completely decentralized so it undergoes the same process as anything else in the network. The nodes have to agree that this is the action that they agree that the economics has to take. All nodes that take part in that decision will have all the information available: what the DEX has been doing; what does the order book look like; what’s that the demand coming in; the supply; all this kind of stuff. So it undergoes consensus as well isn’t like a big leave that anybody can port to try and influence that because there are times of course let’s say that everybody in the network is hodling and the price is shooting up because no one is selling.If you’re a stable currency or trying to be a relatively stable currency you don’t really want that to happen so you need to have a kind of buyer and last resort that could step in and dampen those price movements, which is what the system will do through the DEX. The reason it bypasses holders and node runners is if it creates more supply and gives it to those individuals and they’re just holding any way because they’re seen the price go up then they’re still not going to put any liquidity into the market, so it’s kind of like well you guys aren’t keeping the market liquid so I’m gonna keep it liquid until you start to actually liquify some of your own assets to feed the device and sales on the market. So it kind of also incentivizes holders of node runners to actually say take profit and put some liquidity into the market but if they don’t the system will take it all instead and they won’t get it.

Question 7: What is your marketing strategy? How do you plan to attract more developers, investors, big companies?

21:40 Piers: Okay, so those are three very different questions: 1) How do you attract more developers? 2) How do you drag more investors? 3) How do you attract big companies? So on the first, on developers, that starts with documentation, how to’s, outreach, hackathons, developer events and meetups. It’s all very grassroots-ish and start small. You don’t want to have a big bang. What you want to do is - you want to identify a small group of people for whom you are addressing a set of problems for. Create great documentation around that. Create great how to’s and information frameworks. And really just make sure that the materials that you’re putting out mean that someone can come cold into Radix; realize that it solves a problem for them; and then get straight on to building something. Because, for us, it’s all about shorting that time frame from hearing about Radix to actually building something meaningful on the network. So our focus on the developer side is how do we do that and then how do we get the feedback. And the feedback comes from meetups which we’re going to be doing more of in various cities that we’re focusing on - as well as virtual hackathons and challenges that we expect to be putting out as well. So all of that flows into our developer strategy. But the most important part of that is basically putting out things that we think help people build and then getting feedback on that, to make sure that it is actually helping people build. And it’s really as simple as that - there’s nothing shiny or ostentatious about it. It’s just really trying to get directly to the people that we’re trying to help and having a real conversation with those people. 2) How do you attract investors? So that actually comes down to the economics discussion. So a lot of what we’ve been talking about in the economics is how do we make sure that people are rewarded for coming in early to the system; and giving incentives for the network to grow; and recognizing the different stages of the cryptographic platform. Again the details of that will be coming out with the economics white paper. And you know, there is a decision of a gap between pushing out the technology and pushing out the economics. Because what we don’t want to happen is the economics to end up drowning out the discussion around the technology. So we are very much delineating that. But we’ve already had 14,000 people express interest in getting tokens in Radix. There is a lot of interest in the investor community and in the grassroots or individual investors and token buyers – we don’t really have a good strategy yet for how to engage with those people. So that is still is pending. And we will be doing that once we’re sure that we’ve got the technology in the hands of the people and that they’re starting to build real things. Then we can start having that conversation about how do you create incentives for more money coming to the system as well. 3) And then big companies. Look, a corporate sales cycle is 9 to 12 months and often has a lot of different interests within a corporation’s structure to contend with. It tends to be quite slow going and can often just be, from the corporation’s point of view, a marketing thing rather than a real use case that solves a real problem. We are in the talks with it with a few different large corporations of how they could use the Radix public infrastructure. And it really is focused on making sure that Radix infrastructure is always first and foremost in our minds when we’re talking with people. Because ultimately the success of the entire Radix technology platform relies on people using the public infrastructure. But big companies are not our primary market now. For us it is looking at a new technology as a breaking point for when people start implementing new systems. And you know, if you looked at the Internet and said what does the Internet do for the companies that were around and were the big companies at the time when the Internet came about - many of them while then may look like really attractive companies to be putting DNS or TCP/IP services and servers and all that kind of stuff. Actually the big companies that ended up being the Goliaths of today were born out of small startups. They were the people who built on the revolution of this new technology and were digital natives of that technology of the Internet - and then grew their companies from there. So for us, our real focus is on the developer entrepreneurship - the startups, people who understand this technology and intrinsic point of view and are starting with a green fields installation and can actually really move quickly and start testing out building things very quickly without having a load of corporate bureaucracy and also having to deal with the load of legacy systems which can make things move incredibly slowly. So with big company sales we’re not adverse to talking to big companies. But a lot of the time you’re looking at a very large amount of resources for potentially not a huge amount of gain. So we always weigh that up in our decisions and where we allocate our resources and who we’re focusing on most.


#2

Question 8: Who is your biggest competition and how are you going to outperform them?

27:34 Dan: So we’ve kind of touched on this a little bit with the previous question which was: “do you see any competitors to RadixDLT.” I suppose a lot of people are expecting me to probably say one thing and list off all the people who were looking at scalability, stable tokens, and all that kind of stuff. Well, I don’t see them right now as being our biggest competitors. Because we know we can scale. We’ve got the stable currency stuff working out pretty well. We are efficient. The consensus is strong. So all the kind of things we need to succeed in the long term are already there. Our biggest competitor right now is actually Bitcoin and Ethereum, right? Because Bitcoin currently rules the roost in terms of - I was gonna say payments - but in terms of market cap. If we want to take number one, we’ve got to take Bitcoin. Bitcoin has a lot of infrastructure. It’s got a lot of services built around it. And then Ethereum purely because the mindshare of developers, right? Ethereum has an obscene amount of developers - really really really smart developers that are looking to build stuff on that platform. And they’re all very patient developers, as well. You’ve got Casper taking quite a long time for it to finally come out on the roadmap and stuff. So unless we can grab a lot of developer mindshare which obviously with all the developer tools, Scripto, the scalability, and everything that we can offer … we think we can - but it’s not guaranteed. The best tech doesn’t always win. The best executed tech is the one that wins. And so in terms of Bitcoin and Ethereum being the first to market for their individual niches that they do very well - I would consider them to be our competitors. Not any current upcoming development and implementations like Zilliqa, Holochain, IOTA, and those kind of guys. Because they haven’t beat those guys yet [Bitcoin/Ethereum]. It’s still Bitcoin and Ethereum at number one/two.

29:55 Piers: Like with the others, you really just have to look at what is the long term decider of success. It’s not the amount of money that you’ve raised. That’s been proven time and time again. It’s the amount of utility that you provide to the market in terms of people actually using your platform. Like what is the problem that you’re solving and how well are you solving that pain for those people. You often find that people are quite sticky on that as well unless there’s a really good reason to move then they don’t do so. So with Ethereum it’s a fantastic platform for doing proof of concepts. It’s a fantastic platform for trying things and there’s a lot of documentation - a lot of information about different… [Dan interjected:] ICOs. The ICO is debated as the killer app for Ethereum. It is very much that side of things that we look at from the point of view of competition rather than: who’s doing marginally better tech or who’s raised a load of money. Because ultimately that isn’t a long time determiner of success.

31:12 Dan: For all we know we could all be Betamaxes … other than Bitcoin or Ethereum. Just don’t know yet. Hopefully not. That would be a waste of a quarter of my life wouldn’t it?I think I might get quite depressed about that … in a bottle of Jack for a few weekends. [laughter].

Question 9: What do you think about PARSEC? That is Maidsafe.

31:29 Dan: I’ve read so many white papers I couldn’t even begin to think exactly what PARSEC did. I’m sure I probably covered it in the telegram. I must have read a million white papers by this stage. So I would probably only make mistakes in recalling what PARSEC is and what it does and how it does it. So I’d probably rather not answer that one because I’ll end up looking stupid if I got it wrong. [laughs]

Question 10: How confident is the core coding team that all obstacles were already thought of and eliminated in the current code?

31:58 Dan: That’s a trick question isn’t it? So how confident is the core coding team that all obstacles were already thought of? Very confident! How confident is the core coding team that all obstacles were eliminated in the current code? Don’t know! That’s why we’re going to test it very hard before we go live. You tend to find that theory and implementation don’t usually end in a marriage made, right? There’s issues in your implementation that you cover in the theory book. We’re human, right? We’re human beings. Until there’s a computer that says “do what I mean” and you can press the button “do what I mean”, then your implementations of code will never be perfect. And that goes for immature projects and mature projects, as well. I mean the Bitcoin core team is still cleaning up bugs and things in Bitcoin, right? Like minor ones, granted. And they’re very edge case. But they are still in there. There is no perfect code. So you just basically got to get to a point where you’ve done enough testing. You hit it with a stick and put it through hell and back in your test cases in regression testing, integration testing, and all these other things that you can do. And so your confidence level is enough for you to actually take the risk and go to market.

33:29 Piers: Everything that we talk about on our website, in what we try to communicate out is; this is what we built so far - it’s not perfect but help us find where it’s not perfect and break it. This is what building technology looks like. You can’t wait until something is perfect. You ship it out and you play around with it and you iterate. Like the first shipment of Ethereum was pretty bad - but it got better. It got better because people were trying to build on it - trying to break it. That’s so important. We’re not going from on high and saying “we have all the answers - it’s definitely going to be brilliant - and you can put a few trillion dollars on it on day one.” We don’t think that’s the case. It’s very much a question of pushing it out and letting people play with it. Letting people see it and that’s ultimately why we’re so committed to open source code long term. There is the short term worry of people coming in, forking your platform, and raising a load of money on the back of it. That ends up being a problem - that competition directly to what you spent a long time building. But long term, this is not just us. This is not about just us. This is about building a community around a protocol that’s supposed to be a core piece of global infrastructure. There shouldn’t be a central body to that. It should exist as something that is owned by everyone - that everyone can be part of making it better. That’s the only way the collective intelligence of humanity that can make something really great and can eventually eliminate all of the obstacles and problems with a platform.

35:30 Dan: I just want to touch on something you said there about Ethereum not being great from day one and iterate. A lot of people seem to get quite frustrated that we’re taking so long. Okay, fine. Yeah, you’re impatient. Okay. But I think that because there are so many other projects that come out and someone just goes: clone Ethereum; clone Bitcoin; clone this clone this, clone that. I think people lose sight about how difficult these systems are to build. And if you think about, probably nearly all of the projects out there right now. They’re all building a small something new on top of something that was already there - apart from Bitcoin, of course. So Bitcoin was the first blockchain and even Satoshi borrowed some ideas from Hashcash and all the kind of crypto stuff and things. But he was the first one to actually put it together where the majority of what he presented was new, right? But then you’ve got Ethereum that knew the blockchain worked and was tried and tested and bolted on the smart contracting stuff on top. Well Bitcoin already had a kind of a stack baseline so really halfway there. Somebody said to us the other day that Buterin was looking at building on Bitcoin first [Piers] yes, he was. [Dan] That’s right and so it’s okay Ethereum to a blockchain which was tried and tested with proof of work and import solidity on top. And then you’ve got a lot of these projects that are taking a blockchain and building a stable currency on top; or a directed acyclic graph which - has been around since the 70s. A lot of people tend to be surprised by that - they’re not new. DAGs are not new - they’ve been around for a long time. So again it’s a known mature technology being brought into this space. So nearly all projects have got something that really existed already and they’re building something on top of it. That makes the job a lot simpler whereas that’s not we’ve done. We’ve gone open new file. We’ll start typing new architecture, new consensus, new economic stability mechanisms, and new smart contract language. Everything here is new. And that takes a long time to to research and to develop and test - but also to make sure that we have the confidence in the code that it’s good enough. Because you can look at a math proof all day long and be confident your theory is good because if your math proof is right, it doesn’t lie. But you get one guy who’s up at 4:00 a.m. in the morning and fat fingers just before he goes home - there’s a bug in there that you don’t find for 6 years. So it’s not like we can say we know what to expect with this because it’s a blockchain; it’s a DAG. We’ve got to test everything because if we get it wrong then people potentially lose money and I wouldn’t like that to happen. Because that would really give me nightmares to think somebody had lost some money.

Question 11: Will the price stabilizing mechanism kick-off on day one? Can we see big price swings like on your T-shirts?

38:25 Dan: So the current model which will probably be the model - there is a period of relative instability for a period of time at the beginning until it can ramp up. Purely because there’s no data in the system from day one so it doesn’t know what it’s trying to stabilize against. It doesn’t know what it has to stabilize with, so there is a kind of maturity period. How long that maturity period is until it can start to do its job properly and really start to smooth out the peaks and the troughs? That depends on a number of factors one of which being how much volume do we get off people coming into the system. So the faster the system grows then the sooner it can stabilize so if you’re looking for a stable currency then bring in as many people as possible. If you’re speculative then turn them away, I guess [Laughs]. It depends on which camp you’re in.

Question 12: When you say "the system itself can step in and take the other side of the trade", what exactly does that mean?

39:34 Piers: Yeah, that’s gonna depend on the economic white paper. That will be completely clear. But before that can be explained, the way that our decentralized exchange functions needs to be explained first. And we also need to go through the trust network: how you essentially express external value into the system - how do you get fiat in - how do you get external crypto like Ethereum and Bitcoin. That needs to also be explained because that’s a key part of how the economics functions. Once those two things have been outlined then the economics will make very clear sense - but those two things have to be outlined clearly first. [Dan] It will just confuse people right now.

Question 13: Have you thought about acquiring Radix.com?

40:30 Dan and Piers: I have tried - no response! I think radix.com is owned by some guy in Venezuela or Brazil. I sent a few emails but if anyone can find out who radix.com is owned by and can get us in contact - that would be amazing, indeed. I’ve tried and there’s a bunch of other radix-like domains where the websites haven’t been updated since like 2002. Yes why has this been registered for so long though it’s already like year 2000 can we have our CSS back, please? The thing is that ultimately you can end up getting obsessed by domain names and they matter to an extent, but… Radix.com - I want that one. If anybody can get hold of that I’ll be very happy and we can have a conversation.

Question 14: Are you planning to open source Vamos database?

41:40 Dan: Yes, Vamos will be open sourced as well. It’s pending to be integrated at the moment - it was due to be integrated back in July I believe - but then that got held up with our latest bits of R&D on the protocol and implementation. So it’s a little behind schedule. I don’t want to open source it before it’s been implemented into the Radix core and it’s been a bit battle tested to make sure that it’s all good and it operates as expected. But once there’s some confidence with that new code as it’s pretty much brand new - open new file start from scratch. So once that’s had a few rounds of testing and stuff then that’ll be eligible for open sourcing .

Question 15: When can we run a Node on the Public Testnet?

42:31 Dan: Again, something that’s been a bit blocked from all the recent stuff about to do. So I’m actually scheduled to start some testing of the latest code branch this week with Zalan - who does alot of our DevOps. And on the back of those tests, which we imagine should take about a week or so until we’ve got some confidence, then we could start to think about the node runner download for you guys. So unless there’s any serious issues between now and the end of that testing then we’re probably looking at maybe two to three weeks out.


#3

Question 16: You are going to implement atomic swaps on your DEX. Can you shed some light on how it will work?

43:15 Piers and Dan: We’re not going to implement atomic swaps on the DEX because you can’t do atomic swaps on the DEX. Atomic swaps will be possible on radix in terms of if you want to swap for something external to something in radix, that can absolutely be done. So for example if someone had or did an Ethereum ICO and has a load of ERC 20 tokens that they need to swap into their Radix tokens they created - so that they can use the radix platform instead of the Ethereum platform to actually scale up and do their mainnet issuance of their platform, as in actually issue the working tokens on their platform. That’s absolutely possible. Yes, but atomic swap on a DEX can only be done if you could match perfectly a buyer and seller without any overlap or having to fill an order book out or anything like that. And that’s not how the DEX functions, no. No, you couldn’t do it on the HFT side either because the blockchains are too slow.

Question 17: How can you be so sure that the initial price will be $1 per token? And how many tokens do you expect to be sold at that price? By whom?

44:35 Dan and Piers: There’s been a lot of debate around the one dollar thing recently. So we need to have a conversation with the community about what is the best starting price point because even though it may seem obvious to myself that one dollar is a nice round easy thing to go for - a lot of people don’t seem to agree with me. So … the choice of the starting point is relatively arbitrary we can be absolutely certain at the starting point and where it goes from there is down to the economics and goes back to what Dan was saying in terms of it depends how quickly value comes into the system as to how long the price has a high fluctuation and then tends toward stability. But the choice of what the starting price is is arbitrary and can absolutely be set by us like that doesn’t matter. It just affects how you have the economic algorithm functions. But again it’s just changing a decimal point if you’re going from a dollar to a cent per token in how the economics functions. But it doesn’t change anything. It’s just what intellectually or intuitively the people like and a lot of people like holding a large number of crypto tokens even if it doesn’t actually mean anything. So yeah anybody ever wondered why a dollar it’s because it’s very relatable to the mass market if you go to menu and say “hey this thing’s worth a dollar” people can very easily do that calculation in their head and seeing as Radix is supposed to be mass market - that seemed like an obvious starting point. If you’re going from crypto world to real world and you’re trying to price things in the real world thing, you don’t want to say this is a hundred thousand Rads - and it’s an apple. You don’t want to say this is 0.000001 Bitcoin of - ofcourse you can use millibits or X number of Satoshis. But that doesn’t translate. Because because of the quantity theory of money the way that the economics functions and the fact that it prints extra supply as the market cap increases you don’t end up that one token will never really end up being massively more valuable. You may end up with more tokens but the token that you have is so if we start at a million Rads per dollar it’s going to still stay around a million Rads per dollar. It doesn’t really work very well - like when Italy re-based its currency and after hyperinflation they had, you could buy things for a million lira or ten million lira and it became very difficult and so they decided even though the currency was stable they decided to rebase again before obviously the euro came in. So yeah, like big numbers attractive for individuals who want to get an early in crypto and be like I own like a million of these and it’s the dollars worth but not so practical when it comes to actually using it day to day so that is where the argument lies.

Question 18: Do more people than Dan already work on the protocol core?

48:05 Dan: Yes! Finally. After so long being on my own. We have two guys: Josh, probably most of you already know about, and Martin, whos joining us from Australia. He really needs to strat saying to me every morning when I walk in: “good day”. No matter what happened the previous day - with code and frustrations - that would just cheer me up. Martin started a couple of weeks ago now. He’s doing very well. He’s climbing a learning curve. He’s already done some useful code. Retracted a few things and getting to grips with everything. We’ve got another chap who’s also starting in October. So by that point, we’ll have three protocol guys, plus myself - which we’ll probably do us for the time being. I don’t want too big of a team because there’s lots of toe-stamping will happen and, the way that Radix’s architecture is designed, is that the protocol core is quite thin, anyway. So you don’t want to have hundreds of developers in there because it will end up in Nerf gun fights all day long with each other. So you’ve got this very thin protocol layer and then you’ve got your application layer on top which is things like the DEX and messaging and transactions. They’re all their own kind of application modules that sit on top. And those teams will obviously get much bigger than the core team. Plus it’s easy to orchestrate fewer members of a core team and you can just drag everybody in front of the whiteboard. You don’t need any real kind of logistical forward thinking or doing that either. I’m not alone.

50:01 Piers: The total dev team is now I think 10 or 11. In the actual core itself it is three. Because one of the things that you need to do at low low-level code, right near the protocol, right near the consensus, right near all of the lowest level of the stack of Radix, the bit that fundamentally makes it work. Is you want as small and as efficient as possible. Generally speaking, everything touches every bit and you’ve got to have people holding the whole thing in their head and being able to work very seamlessly on lots of different bits of it. It doesn’t really work so well and - Dan can correct me if I’m wrong on this - but it doesn’t really work so well in terms of work streams and lots and lots of different teams working on lots and lots of different bits.

50:53 Dan: yeah it does kind of work that way in the core. So like at any one time ,collectively, we’re maybe touching two or three percent of the core. So it’s not like Josh is over in the networking stack, and Martin is over somewhere else, and I’m in the atom model or something. It doesn’t tend to flow like that because the networking stack is good. It’s working - been working for months, now. A large portion of the core, as far as we know right now, for my test net is all good and solid. So we’re just dividing up the work that needs to be done now into smaller chunks but there isn’t that much of it in the protocol. Well there’s a lot of it in the protocol but it’s confined. It’s not very spread out. So if you had too many people you just have a kind of merge hell because anybody coming to merge branches all the time. It just wouldn’t work out.

Question 19: How is finality achieved in tempo?

51:44 Dan: Okay, so finality depends on where you look at how you want to classify finality. So, broadly speaking, we define finality in Tempo as two times the latency required for gossip to transit the entire network. So that is basically if I had a node in Australia and you had a node in the UK, technically New Zealand and the UK, as they’re on other sides, then finality time would be the time it takes for that transaction to get to the UK and then back to New Zealand again. Within that time I have a very high certainty that there’s no conflicts … excluding kind of subnets and stuff that somebody’s put offline, so kind of natural conflicts and stuff. So that is what’s determined as been finality time. So two times the network gossip latency. So there and back and you can approximate what that is from the number of nodes, what the gossip period is between each node and this kind of stuff related to the network but generally speaking of over a network of about 10,000 nodes then your finality time is five to six seconds. If you want to get a little bit deeper into how finality works then at the most kind of extreme levels, finality can actually happen pretty much instantaneously. So if you have a node that sees a particularly event, event X, and you have some node on the opposite side of the network that sees X’ and they have some shared event they’ve both seen, then the mere fact that there’s correlation between those nodes because of a third event that intersects them ,the node that sees that event first, so X in this case that’s already got finality of this one. Doesn’t matter how many other nodes join. And in some circumstances the first node of that transaction being validated can actually mean it’s final - it can’t be taken back. If that’s not the case because you’ve got subnets and those kind of things then obviously if there is a network split or you have a malicious actor that has a subnet and he’s keeping transactions offline then you can’t really put a bound on the finality time because one network doesn’t know the complete information about another net.

54:22 Piers: But then it depends on how you define finality, as you said. If you define finality, instead of network time - we use network time because it’s easier to measure - we can say we know: given a network size, how long it takes to gossip twice across the network from the edges. So that’s something that we can just be like: oh that’s easy. Actually it’s much less than that when you take into account mass. Once its gossiped to more than 50 percent of the mass then you’ve reached finality. And then you can say that you reached finality even in the event of subnets, right?

54:57 Dan: Well it’s not necessarily 50 percent of the mass. It gets a little bit more tricky because I may have multiple conflicts that are firing off around the net. I might think: oh yeah I can subvert this. I’m a smart attacker. I’ll just fire off loads of conflicts all around the network but I’ll just pick a bunch of nodes and I’ll just fire off all these conflicts there. So your finality time is a bit more abstract: because its which one of all those conflicts achieves the most mass not a 50% but with the most mass…

55:27 Piers: Obviously people say if you can’t say exactly how long finality time or when finality is then how can you ever be sure of any transaction. What i want to make really clear here is that you can be absolutely sure of a transaction on the mainnet regardless of what the makeup of the mass is - as long as it is the mainnet and you have gone through more than 50% of the mass on that mainnet. You know its final. But when you jump into the weeds of that it can become a lot more abstract because you could have more than one conflict.

56:10 Dan: Yeah. Or if I’m a lucky enough to be in a subnet that’s off from the main network so the amount of mass moving on there is much less, than from this perspective my finality is essentially unbounded until I rejoin the mainnet - because there could be a conflict there that has more mass than the subnet that was mine. But for most use cases finality is five to six seconds. You can be pretty confident that if you haven’t heard anything about your event not being accepted (your transaction not being accepted by that point) then you can be pretty sure that it’s good.

Question 20: Can you shed some light on the economic mechanism to get short-term price stability?

56:48 Piers: Not at this stage. That will be coming but it’s not available yet.

Question 21: How many team members do you have right now? Do you have an economist working on your economic model?

57:01 Piers: So we currently have 17 team members in total. That will be raising to 20 in the next month or so. Do you have an economist working on your economic model? Yes.

57:25 Dan: Don’t we have some non full time team members there aswell?

57:27 Piers: Yes. We do. So if you add those then there’s 22. Yes, we do have an economist working on our economic model.

Question 22: Are you going to support any 3rd party dapps with investment or highlight them to gain some extra boost?

‍57:35 Piers: This is a great question. So there’s two sides this argument. The first side is, you know, applications building on your platform increase the value of your platform so you should go out and get as many applications as you can. And one easy way of doing that is to throw money at them, right? So I have a big pot of money and I’m gonna go out and I’m gonna go and pay people to come and build on my network. The problem is that that often does not work very well. So an example outside of the crypto sphere is corporate ventures and if you look at the success rate of venture capital - it’s pretty low and then if you look at the success rate of venture capital in the corporate space where a corporation has set up an arm and gone: “you know what will be great - if we go and pay startups to… so if we go and invest in startups and then make them build on our technology as well because we can have some great startups and we can have them building on our technology’’. Those corporate venture arms tend to do even worse than the average venture capital area and often those are people - large corporations with finance departments and people who have been in M&A; for a long time and like you can come in and help the investment process. Then flip over to crypto where nothing is certain and we don’t know what any of these business models are going to do and many of these are gonna fail and lots of them are going to be so bad of investments and then couple that with the fact that you’re forcing a team to choose a technology based on you paying them to do so, you end up creating a load of noise that is very difficult for you actually to find value in there. So what we absolutely want to do is provide the best tools possible to make those people as successful as possible in building the applications they need to do. So make great documentation; make great code libraries; make great frameworks; make it easy to build on Radix. We also want to highlight those people; so very happy to have conversations and like do press events and things like that where we will talk about you to our community and we will talk about how you’re building what you’re doing on Radix and support you in what you’re trying to do on that side. But what we won’t do is pay people to come and build because you mess up the incentives your technology and your platform should be good enough - should be be solving a pain point well enough for you to want to choose it because ultimately the entrepreneur should be, who is the head of the company, should be choosing the technology that helps them best serve their customers, helps them best build their business, because ultimately they’re the ones who are going to be living with it long term. They’re the ones who decided on our platform, invested in it, and then making it work for their customers. Their revenue is not coming from the platform protocol provider - the revenue is coming from their customers and who they’re actually addressing. And if you are forcing them to choose our platform or paying them to choose our platform, then short term it looks great - long term I think the returns are going to be terrible for the crypto companies who are doing it. And I think that the entrepreneurs are going to end up being in a difficult situation where they may have chosen the technology that wasn’t right for them just because of that immediate carrot that was being offered by a company and that just ends up being bad for everyone. Carrotcoin.

Question 23: How do you foresee the mass adoption of Radix, in what areas and how will you market it?

1:01:16 Dan: There’s a number of facets to that, right? I mean you’ve obviously got the developers that will play a large role. If you give them a platform that can do the things that Radix can do, then they can make more engaging applications. It would be cheaper and easier for them to do so. So they can focus more on their own roll out as opposed to battling with the technology and trying to figure out how to use the stuff in the first place. So they’ll bring a user base and all that kind of stuff. I think then from that point forward you need to stop and think a little bit more about not so much payments, but like non-fungible tokens and stuff. Games are very forward-thinking in terms of monetization of assets in the games and stuff. So I think that would be a big route forward for mass market adoption not just for us but potentially for any DLT. Then once you kind of past those kind of low hanging fruit scenarios you then start to get that actual crooksum of them, which is your payment systems. From a payment systems as you need quite a lot of infrastructure in order to get mass market on board. Because mass market generally isn’t very tech savvy or they don’t like a lot of change you know; why do I want to have this new app on my phone when I’ve got my Nokia 3310 still from 20 years ago and chip-and-pin. Asked to go to the cash point; no. You know those kind of people, but so you need infrastructure to be able to support them and so one of the things that we’ve been trying to do at Radix is actually leverage some of the existing infrastructure that is out there; the point-of-sale terminals. If you can use that infrastructure in terms of making payments through Radix debit cards and stuff and also on the phone as well if you’ve got Millennials they’ve got the Radix app they can pay with contact on your phone stuff for. Your kind of greater market is very slow and sticky with the tech they are used to. So we’ve been trying to leverage that existing infrastructure in order to reduce the amount of friction. So then we can do things like: if I was in the street and I gave a leaflet to pretty much any member of the public that wasn’t sub 30 and said, “hey why don’t you use this new kind of money there’s a leaflet go and download it onto your iPhone or your Android.” They’d be like, “what’s one of them? I’ve still got a normal normal phone with a little stool that I sit when I call people!” But if you give them a card, “oh yeah I know what this is - it’s a card to pay things with.” So you already passed that kind of adoption value barry.

1:04:10 Piers: So there are they’re sort of like two sides. One is where we trying envision the ways that we can make it easier for onboarding the mass market and that’s things like the decentralized card system that Dan was mentioning then there’s the ways to make things easier to unboard for people when you’re looking at developers. So we are not going to be able to build all of the ways that the Radix system is going to be implemented - that’s going to be down to the people who decide to build projects and companies on top of radix and so mass adoption is going to come and sneak in and it’s gonna be there and you’re not even gonna know it. You’re going to download a game one day and inside that game is going to be a crypto wallet for you to hold your non- fungibles and for you to be able to hold your game tokens and you won’t even realize it’s crypto unless you’ll like sort of dive into the game a bit more but like that’s every day. And then how we then make that even easier it’s things like the centralized exchange the decentralized exchange is there to allow people to move between these kind of assets but via an API basis like my app on my phone I downloaded for my game that’s called it “Candy Candy Eat” and then in my game I have my crypto wallet and my friend has got a different game and we can transfer them between each other and we can also exchange them. That all happens behind the scenes with the Radix DEX and with the Radix infrastructure. So you often won’t even see it. And that’s going to be the beauty of and the importance of how Radix functions. It’s an underlying technology. It’s an enabling technology for businesses to be successful and for them to reach out to the consumer. So mass adoption will come as a result of people building things that people want on top of the Radix platform. And it’s gonna come in that way…

1:06:04 Dan: I think it will come in stages, as well. So you’ll get all the kind of leveraged utility: like non-fungible tokens in games and stuff and like supply chain and maybe identity and access control. All that will come before the real mass-market payments comes along. Because there’s a lot of barriers to entry to that that we can’t get rid of. No amount of tech we’ll get rid of some of those bodies by you know regulation and that how is the SEC or the FCA and these guys going to think about large amounts of the populace holding these crypto currencies that they potentially have no way to regulate and stuff. But I think a precursor to all that is that before you can even get to that point there needs to be some stability in the markets that those mass market users are going to use right? Because most businesses have a very thin margin on top of what they make profit wise and so they don’t want to worry about volatility and it doesn’t need to be NOT volatile it just needs to be predictable so that I know as a store holder or as a user that has some salary paid to them in crypto that I’m not going to be in bed tonight, wake up tomorrow and the market has died on me. And now I’m gonna figure out how am I gonna put food on the table for the rest of the month, right? So that kind of mass market adoption cannot happen without some kind of relatively stable or stable currency. It just will not happen. And that’s why like the whole mantra of the stable currency for Radix has been on the table for so long. It’s one of the five must-haves for a…

1:07:41 Piers: What are your five? What is your list?

1:07:43 Dan: So, first and first, is scalability. Gotta be scalable. Otherwise how’d you fit seven billion people and however many devices that come along? It’s gonna be scalable. It’s gonna be efficient. At some point power is gonna hit that plateau - anything that is exponential can’t go on forever. End of story. I don’t care what anybody says. If it’s exponential it’s gotta run out of something. So it’s scalability. It’s efficiency. It’s got to be efficient. And has to be decentralized. So no master nodes or that kind of stuff. It has to be stable. And it has to have infrastructure - the infrastructure one is quite broad. So that means like developers, apps, payment systems, mobile phone applications, wallets. You’ve got to have all those things. And infrastructure - we’re doing pretty well with in terms of general crypto infrastructure, even with all the kind of friction to do with on-boarding and off-boarding and stuff. We’re not doing too badly. There’s a lot of services that surround the crypto sphere. Unfortunately a lot of them are centralized and stuff but they’re still there. You can use crypto and with a little bit of effort, but that will get better. And the other four - they’re much more the kind of technical properties as opposed to a logistical issue. They’re the “Dan’s five must-haves for a mass-market penetrated crypto.”


#4

Question 24: Dan said with the latest fixes to the core, he made the issuance of tokens easier. What does that mean exactly?

1:09:30 Dan: So the fixes for the issuance of tokens and stuff - they’re not necessarily fixes - they’re more improvements to the base protocol. So up until now we’ve been kind of running on this kind of proof of concept prototype atom model, as we call it. And the atom model is all the kind of different ways that you can build atoms. And an atom is a transaction, it’s message its an encrypted payload, it can be tokens ,all kinds of things; it can carry some Scrypto code with it, that kind of stuff. It was quite crude but it was enough to get the job done to get us to a prototype and for us to build all these other kind of things on top like build the consensus, test out economics, Scrypto things and all this kind of stuff and so that we could actually have some confidence that what we’re trying to do in theory is actually possible. But we’re at the stage now where we’re trying to transition out the codebase and the platform from a kind of prototype quality to a commercial grade quality and so some of that job has been to review all the things that we’ve already built as a prototype one being the atom model and in doing so we highlighted quite a lot of areas where it could be massively improved. Not only to make it more efficient and also add some security there, but to able to increase the kind of feature list that it can fried and the ease in which you can build against it so like developers can build in my custom behavior into their atoms that do particular things in this kind of stuff. And so one of the things that the atom models role is the issuance of tokens and assets and being able to manage them and all the properties on them and commissions and all this kind of stuff. So we kind of highlighted all of these things that were like hey listen we really cool to do when we can build this and then we can built that and if we move this around and move this and so it’s kind of like a collective of things that the refactord atom model will provide that make the kind of longevity of the feature set that it can that it can do and provide the utility moving forward and makes it very extensive and it’s practically impossible to implement those kind of improvements after a launch. Which is why we’re implementing it now and we’ve had to jiggle the roadmap around a little bit because I think some of the features that I won’t go into on this AMA but some of the features that this atom model can provide are so groundbreaking in terms of the crypto space that it basically has to be in there. Because if we didn’t do it I think we forever regret and it’s not something you just bolt on, unfortunately.

Question 25: A lot of things seem to have changed this year. What parts of the previous whitepapers are not correct anymore?

1:13:08 Dan: So most of the previous white paper is still correct. I think the main change over the course of the past year is how gossip operates and the introduction’s of mass.

Question 26: What are the steps to take for a merchant to accept Radix at a physical point-of-sale?

1:13:26 Dan: Hopefully not many. We’re still working the details out, so many of you have obviously probably seen the POS video floating around for about a year or so now and that was a prototype proof of concept. Actually going from that to an install point of sale terminal accepting Radix tokens is a different matter entirely. There’s lots of red tape, bureaucratic processes to run through in order to make that happen. There’s obviously workarounds where you can have like QR code readers, but merchants generally are very affable because that takes up valuable real estate where they can up-sell goods for your check so they must have a one on one and it’s definitely possible it’s just the figuring out how we do that with the OEM’s so that we can get the updated terminals and unfortunately it’s going to be a bit of a time-consuming process but thankfully, there is a bit of time before the actual real mass market gets wind of all this who really want to use it so it’s not urgent and on the critical path.

Question 27: What happens to nodes and node IDs caught cheating?

1:14:31 Dan: They are exposed as being liars and cheaters and the rest of the network will ignore them or you can choose to put them in your wipe list.

Question 28: Did you consider launching Radix w/o the economic adjustment algorithms? The stability idea goes against the austrian school of economics widely loved in crypto.

1:14:46 Dan and Piers: no never because of my list of five things that crypto requires.I mean a lot of people seem to sometimes miss quote that radix is pegged or that it’s forcibly stable. It’s not. It’s a free-floating economic market but it just tries to smooth out the curve a little bit and provides some predictability about where it’s going. So if it wants to go to zero it will go to zero. Let’s have a debate about that in terms of the Austrian School of Economics once the economics white paper is out like we don’t think that we are actually against the concept of competing currencies or anything like that as Dan says this is not a pegged currency, it is a free-floating currency with the aim of long term relative stability that’s based on using quantity theory of money and a couple of other things that we’re implementing rather than trying to go against the idea of competing currencies

Question 29: Have you ever convinced a Bitcoin maximalist that Tempo is superior to Blockchain? How did you do it?

1:16:00 Dan and Piers: I wouldn’t actually know because most Bitcoin maximalist don’t hang around me long enough to be able to convince them in the first place, so if I have convinced a Bitcoin maximalist, he’s probably a secret Bitcoin maximalist and therefore i don’t know if i did or not. I think that the very concept of a Bitcoin maximalist is that there is the Church of Bitcoin and you don’t question the Church of Bitcoin, but there are plenty of people who were bitcoin Maximalist you have now converted to the idea that bitcoin may not be the answer to everything and you certainly see those all the time. You know there are many people in the in the Radix community who once considered themselves to be so. In fact some of the core members of the Radix community right at the start were sort of very much pro Bitcoin maximalists. If anybody out there was a Bitcoin maximalist but now aren’t because of us, then please do let me know .

Question 30: How does Dan’s coding cave look like? Do you feed him well when he’s working there?

1:17:10 Dan: No piers doesn’t feed me well, my wife does when I’m working in there and if people really want to see how my coding cave looks like at home, i’ll show it later in this evening.

Question 31: Will there be a way to add some trusted nodes to my peer list in case I believe all neighboring nodes are trying to isolate and attack me?

1:17:26 Dan: Yes, you have a whitelist to add them to it

Question 32: How its possible to reach low finality time, when nodes gossip new events to closest neighbors? In neighborhood only border nodes can actually inform new nodes.

1:17:40 Dan: I’m not sure I understand what that question is. There are no border nodes as such, it’s a kind of p2p Network, your neighboring nodes are based on the distance from you like a Hamming distance kind of approach. Each node gossips to eight or more other nodes so if you actually do the mathematics on how finality time could be so low; if you think that I’ve got a node that gossips to eight other nodes and then those eight nodes gossip it to eight other nodes and then they gossip another eight, and very quickly that’s a massive amount of network sizes with on like six or seven pops and if each half is only half a second which is, you know, that’s kind of standard practice half a second or so then over a hops you can reach 65 thousand a hundred thousand nodes and that’s only four seconds.

Question 33: How nodes look for neighbors? Is is simple subtraction of 2 IDs or u use something like Hamming distance? Subtraction will organize nodes in line rather p2p net.

1:18:50 Dan: Yeah so it’s basically, to get technical, it’s an XOR of two IDs and then the leading number of zeros of the XOR is the distance from each other.

Question 34: Everyone is changing to ERC-20 token to join ethereum, What can Radix do to attract token projects, is a token project something Radix wants to attract or is Radix focusing on other areas?

1:19:30 Dan: I think we can’t avoid or we shouldn’t even try to avoid token projects coming over to Radix, because they have been the killer app for Ethereum and they certainly will bring a lot of benefit to us as well. I mean - having these projects have their token issuance events on Radix and then have them build on Radix aswell is a win-win. Ethereum is in the unfortunate position where it finds itself being the token provider for all of these projects but they’re not using in theory. Because it doesn’t have the performance or whatever it is these projects need. It could be different in our case because we can scale more efficiently all these things that everybody knows, so I think that actually it could provide as more benefit than it has a savior.

Question 35: How will the initial distribution of Radix be handled and will the early investors receive a fair reward per BTC invested compared to new BTC investors Q1?

1:20:39 Piers: The reason is, is because this is still pending on the economics model so like any answer that we give is subject to change obviously we want to make sure that everyone is fairly rewarded. But we also want to make sure that the long-term success and viability of the platform, you have to weigh both of those things very carefully and like if you get that wrong at the start and then it can end up causing the network never to be successful. It’s really important that you give both scopes full thought and that’s part of the process of working out how the economic system is going to function, because that’s how the people who invested bought tokens back in the day in radix and how people who buy tokens when it goes live on the DEX and how people buy tokens in ten years time, how all of those people will be rewarded and incentivized. It looks different for each of them and your your timeline is like a hundred years: how do you make sure Radix is still around in a hundred years and how do you make sure those incentives run all the way through. Not just how do you make money right now in six months and get ten times return. That can’t be the way you look at it because it just doesn’t create longevity in a platform. Right now, the returns that we see in crypto are crazy compared to any other form of business and that will go away. And there will be projects that blow up, because they haven’t thought about long term business model, because they haven’t thought about the longevity of the platform into the future and if you don’t do that properly at the start - you’re just not going to end up being around. So yeah, the reason we skipped it is because we don’t have an answer for it right now and we can’t tell you until we’ve really finished thinking through the economic model. On another note with that we are now completely 99% certain as to how the creation and destruction of money is going to be done within the system. We have an identity for that - very confident in the maths behind it. Most of the discussion now; is how you then redistribute the rewards that are created as a result of this function. So we’re very very happy with how the economics functions as a basis. Now everything is; how do you reward node operators, how do you reward balance holders, how do you reward people who come in at what stage, how do you fund the foundation. All of this stuff that sort of comes out at the back of that. So that that’s quite a long way along, but this stuff is now sort of messy stuff that could be right or could not be right and we’re gonna put out a paper that is going to be a draft essentially - just going: what you guys think of it? Doing things like this and tell us some other ways of doing it. Those conversations about the node runner balance are longer conversations. It has to be fair, otherwise it won’t be accepted by everyday.

Question 36: When will developers be able to start testing arbitrary smart contracts for their protocols/dApps on the Radix testnet network?

1:23:54 Dan and Piers: So scrypto is still ways out, its not on the roadmap up until the next year anyway right? But we are planning to have a alpha Scrypto test network up and running towards the end of this year so then developers will be able to jump on and build against the test net in preparation for Scrypto going live on the mainnet next year. There’s also sort of a wider definition that we should probably jump in here and just say; look, a lot of the things that people think they need smart contracts for, they don’t actually need smart contracts for in Radix. So a lot of the things that you would typically think about using a smart contract for can be done using our Atom model and the protocol and the api’s and the modular nature of all of that where you can build probably around 80% of what people are currently using smart contracts for just with the core without ever having to touch smart contracts in Radix, like scheduled payments, really complicate multi SIG’s. All the kind of stuff that has been reinvented time and time again, just all kinds of stuff like that. Kind of everyday tokens, non-fungible toolset that a smart contract developer will use and because in the protocol as well, at the base layer, its much more secure. You can be sure you’re not gonna have any screw-ups in your code, you know you get a recursive function or anything like that, that’s going to cause you problems later on. So you know, that kind of touches a little bit as well on on the power that this atom model refactor can provide, because you can do, as Piers says, 80% of use cases and user stories that people are currently building with smart contracts, you can just do it and be built on the base protocol.

Question 37: Will the client at launch include chat-rooms and marketplace like the old eMunie days?

1:25:46 Dan and Piers: There will definitely be chat rooms - they were so much fun. I really miss our old eMunie chat room client where we all used to write profanity to each other in a loving way it was great. So chat rooms yes, I will definitely kick Edgars to implement that and Mark and the mobile client. I mean I think we can do that. Just anyone who installs the standard radix messaging app just gets the trollbox. As for the marketplace it’s something that I would like to revive, it was pretty cool, you never saw the emunie marketplace right? This is the one where I demonstrated it and all the nice beta testers put some questionable items on in there, on this big screen behind me as I was presenting it. So we won’t be doing that again. But I would love to get the marketplace back as well atleast as a framework right? Its something that people can take and can go build against it - this is how you can build a peer-to-peer marketplace for selling like a peer to peer eBay or whatever - basically what it was. I even built some some tools to import big sways of actual eBay onto our test network so if you basically got the eBay item number and put it in. I could import various things from eBay. So the irony for that was like, if I was a big eBay seller and I just want to go pull all my stuff over to Radix i could just basically click a button and it would import all of my stuff into radix. But yeah the marketplace that was always a kind of little pet project of mine.

Piers: So that is the conclusion for everything - there are a few questions are still remaining on the AMA. What we’ll do is we’ll post those on reddit or something or some forum, depending on what Angad decides and I will post links to that on telegram community and on our discord and then the recording of this will also be on YouTube so that anyone who didn’t get a chance to see it now, or wants to recap any of it can do that but thank you so much everyone who is watching live and thank you so much everyone who’s watching in the future. It’s been really enjoyable and thank you for all your questions.

Ciao.