This latest discussion was recorded on February 1st with attendees:
Andrea Suisani (Bitcoin Unlimited)
Cameron Lee (Online Retailer)
Emergent Reasons (General Protocols)
Freetrader (BCHN)
John Moriarty (Host)
Josh Green (Software Verde)
Paul Wasensteiner (Bitcoin Unlimited)
Tom Zander (Flowee)
Watch the Network Discussion Here
John Moriarty: (The purpose) of this meeting is for stakeholders and the BCH ecosystem to coordinate and communicate their plans about this upgrade. Viewers on YouTube are encouraged to ask questions in the livestream chat and we'll do our best to get to them.
So some Bitcoin Cash stakeholders have already announced plans to not implement any consensus changes for this coming upgrade. So, um, Emergent Reasons, could you start us off with a description of basically what that means and what the reasoning is behind it?
Emergent Reasons: Yeah sure so I'll be speaking as a general representative of General Protocols, you know as a business operating on the Bitcoin Cash network and from our perspective there was an announcement, right? that you're talking about where a number of the full-node projects, maybe all of them, I'm not sure all of them, but many of them posted their intention to say that, um, basically that they didn't intend to do any consensus changes on the network and that there was no outstanding plans that were in any kind of condition to be upgraded in May, in any case. And, yeah, so General Protocols supports that. And we published an article as well that said although there are some things that we would really like to see improved in the protocol, right? Not huge changes but um pretty reasonable changes and focused changes. Although we would like those and we really need those, you know, it's not ready, so, you know, we wait and we wanna set up that culture and General Protocols supports that, that kind of shift toward a culture where we get ready, we communicate openly, publicly. All of these ideas get aired out and beat up and reformed and refined. And yeah we support that.
So yeah in May, no consensus changes, General Protocols supports that. But, um it did, maybe like you mentioned it does seem like some poeple are confused no consensus changes means nothing happens and I think that it's not the case. And I think that some of the people here are able to speak to that better than me. But there are, I think, some changes that people want to do that aren't related to consensus. And so, it's improvements that don't lead to any kind of split-risk or anything like that. Yeah so I think it's a great place that we're starting from, for me.
John Moriarty: Sure, so could I ask maybe someone else to elaborate just a little bit on why, so ok, if things aren't ready then obviously we shouldn't put them in, there's obviously some extra risk to any upgrade, especially if it's not been prepared enough. So maybe it would be worth elaborating just a little bit on the history of how that turned out being the case, that maybe this time we should just not do anything, or at least, that it could be that case at all. Anyone feel free to.
Tom Zander: Yeah I'll join the conversation a little bit. So for me there was an upgrade scheduled and I think it's something that we all agree, we will use it instead to help us take a breather and give our ecosystem some time to work on adoption and work on stability. So when we said that we have a no-changes goal, we now propose it's where most users do not need to upgrade their wallet or software this May and I hope that this helps us get the stable footing again. And from there to work with merchants and others in order to grow adoption. Because adoption is really the focus that I believe personally that our ecosystem should work on now and as Emergent Reasons said it's really important to get new features in but we can work on those at the same time in the background basically and then these people will have more time to get the better quality that we need.
And I think we will also work on how to do upgrades in a better way going forward because we all are very very tired of conflicts that end up being escalated to unmanageable proportions. So if instead we end up having more conversations, we can avoid any of such confrontations ending up being to big to manage.
John Moriarty: Sure, so before we move on to then non-consensus changes, would anyone else like to either ask a question or share an experience or share a perspecive on the decision on the not doing consensus-level upgrades before we move on?
Josh Green: (inaudible) how to raise my hand..
Emergent Reasons: Oh, right, we should be raising our hands.
John Moriarty: Oh, it, well, I'm not even sure, is that, well is that a thing in Zoom?
Josh Green: All right, maybe I'll just physically raise my hand next time. Um, I think it's just a matter of keeping in mind that like the upgrade in May, a lot of nodes don't have to upgrade like literally you don't have to upgrade your software if you don't want to. The exception would be BCHN because of some legacy carry-over from the previous fork. The important distinction is though, is who has to upgrade and who doesn't have to upgrade. So with a non-concensus upgrade, wallets and users don't have to upgrade their software. If you're running a node, which if you're a business or if you are a used running a node, you should probably check with your node maintainer or implementation to see if you should upgrade or if you have to upgrade. I think that's the only real miscomunication about that non-consensus means. And it's just who has to do what, when. And historically everyone's tried to have the upgrade. But basically if you're a wallet user, nothing's going to be different from your software if you don't want it to.
John Moriarty: Appreciate you adding that, Josh. So I think we can move right on then to talking a little bit about the non-consensus upgrades, or you know however you want to call them, upgrades, or changes that are going to be happening -maybe- this May. And I'm going to just open that up, maybe Tom, you could start us off talking a little bit about the state of double-spend proofs?
Tom Zander: Let me just quickly check the chats..
John Moriarty: OK, Looks like Freetrader just sent a message, would you like me to do that one first?
Tom Zander: Yeah. Do that, yeah.
John Moriarty: Sure. From Freetrader, he says
Freetrader: I want to confirm what Emergent Reasons said from the point of view of Bitcoin Cash Node. We are commited to to the joint statement of the May upgrade without consensus changes. This does, of course, not mean we are not working on non-concensus changes. We are still working on an important non-concensus change, the increase of allowable unconfirmed transaction chain lengths.
Emergent Reasons: "It doesn't mean aren't working on non-concensus changes", that, that's a pretty amazing sentence.
John Moriarty: So if no one would like to respond to that, you go ahead, Tom. Thank you.
Tom Zander: Yes, on the side of the non-concensus changes, I've been working with BCHN and others on these double spend proofs which have landed in BCHN just last week. We're also working on the follow up of that to actually go on for the next step which is to have the RPC, the interface between the node and other components. The important part here is that all the nodes basically have the same RPC interface so you still have the ability for middleware to just plug-and-play whichever node you want to run. And so BCHN has been working hard to actually implement some really good ideas there, which I'm pretty sure everybody else will just copy. And then the next step is to go up one level, which is the middleware thats gonna be the Rest API, the Fulcrum, and others, are gonna actually use all of this to provide a yes/no answer to everybody that asks, specifically wallets, are gonna be interested in that answer. So we're moving on to double-spend proofs, and that is I think the main issue, the main project that I am also working on.
John Moriarty: So just to quickly follow up from that, and I do see your hand, Emergent, we'll be right to that. Uh, could you.. uh, excuse me, sorry. I saw Emergent's hand and I lost my question. Let me take one second, let me see if i can remember..
Emergent Reasons: It might be the same question!
John Moriarty: Yeah, it very well could be, if you wanna go ahead, Emergent, I'll take a second.
Emergent Reasons: Yeah, sure, well actually I didn't have a question, I just wanted to attempt to rephrase that in terms that maybe everybody can understand. So, make sure I get this right, Tom. I think the point with the double-spend proofs is that it will help the steps that are being taken by a bunch of developers and nodes and projects are to get it built up to the level that there's infrastructure so that anybody making an app or a wallet or any kind of high-level thing using Bitcoin Cash, they'll have an easy interface to just be like, hey, a transaction happened, and then they get an automatic notification that there was double-spend, or something like that. And then they can say, Hey something's wrong, you know, be careful with that transaction. And that will further improve the security, so that we can continue to have, effectively, instant transactions, and even better security on those instant transactions.
Is that fair, Tom?
Tom Zander: Yeah, absolutely, that's a very good description, the way that we're going, especially also with the longer chain-lengths that BCHN is working on, is that we will need some more proof of zeroconf being safe. And I think that's where we're going now, and that's making really good progress.
John Moriarty: Alright, I have a message from Freetrader here, "BCHN would like to thank Tom and the BU Developers for pushing the double-spend proof initiative. We think this will be really useful for merchants in the future. From the interface's angle I'd like to drop this link here for others to review.", so here it is, "This merge request RPC interface is proposed by Calin Culianu." Thank you very much, Freetrader.
I think one thing that would be worth clarifying as quickly as we can (whoever would like to take this) is that this is something that's being worked on and i guess this is a statement, feel free to correct me, and there is not really anything that anybody but the people working on it need to do in the near future. Is that right or is there something that businesses should be thinking about?
Tom Zander: So what we will end up with if all of this is complete and all of this is working is that point of sale systems and of course wallets that are recieving information will be able to say, hey, first step I see a transaction that pays me and within a couple of seconds, if this transaction is safe, and you will get paid when the block gets mined. And so the only thing really needs to be done, is when this all is done, when all of the technology is written, that people run the wallets to actually use this information. And that's it, so basically the merchants will have a new feature in the wallet, and that's about it.
John Moriarty: Very good, thank you. So before we move on, I think, Tom, you did already mention the unconfirmed chain limit. Would anyone else like to add on to the discussion on double-spend proofs?
Paul Wasensteiner: if I can jump in, so just to point out that BU has already implemented this in their node in their client, both unconfirmed transaction chain limit to a much larger number, and the double-spend proofs, obviously thanks in huge part, to the work that Tom has done on that. So these seem to be features that all node teams are working on the get them implemented on the BCH network, so like it's been reiterated multiple times, it's not that the work has stopped. The work is absolutely still going on upgrading Bitcoin Cash. It's just the case that in the May upgrade there's no consensus changes that are happening. But there's still major upgrades that are being worked on by each of the node teams. So yeah, just wanted to point out that BU is totally on board with getting double-spend proofs and long unconfirmed transaction chains added to Bitcoin Cash.
John Moriarty: Thanks, I appreciate you clarifying that and adding it. Emergent Reasons, please go ahead.
Emergent Reasons: So the question Tom mentioned, something that's very important, which is that the double-spend work, and you also John, the double spend work is not something that necessarily has to be related to main, there's nothing that people really need to do, it's just that they're going to get a new feature. But it is important to know that the people who are building the Bitcoin Cash network are thinking very carefully about the safety of everything and making sure that zeroconf stays safe even with these much larger, unconfirmed chain limits, and things like that. And another point that I wanted to bring up that I hope the other guys here can discuss maybe not too technically, but a little bit, that although double-spend proofs is something that anyone can start using at any time the unconfirmed chain limit is something that needs to be coordinated , it has a timing limit to it, in my understanding.
And so the May upgrade although rushed, not for these but for consensus, we're doing no consensus, so, right, 6 months is very fast for consensus issues. But having that time point, that May time point is very useful, I think, in terms of having some kind of coordination point for things like the transaction chain limit which need coordination. But maybe that can shift over to the chain-limit discussion, and make sure that I'm saying the right thing here.
John Moriarty: So if anyone would like to add on, clarify, or maybe just make sure we don't talk too much about, really what it is, but more, what is it that people would need to know about it? And who are those people that need that information.
Paul Wasensteiner: If I just jump in, so, essentially it would be, like Tom pointed out, it's for, either merchants themselves or for people building the software for merchants. So, if you take a specific example, the Cash Register app that Bitcoin.com works on, you owuld expect to see a notification pop up when a double-spend has occurred. So it's essentially providing that information that the merchant needs at the time..
John Moriarty: Right. And I apologize, I actually meant to move on to the unconfirmaed chain limit, and so thats what I intended to move onto there, so that's my apologies. But for the unconfirmed chain limit, if we could move onto that, what would be in that case, the people that need to know what to change and also does anyone else want to speak on whether is May 6th currently the plan? Is that something that has been decided or is still in the works? Does anyone have a specific proposal?
Tom Zander: So maybe the background here is that we started out with a chain limit inherited from Bitcoin Core because of a feature called "child pays for parent" and that feature, when it was added, we ended up having a scaling problem. And it turns out when you have blocks that basically don't get full, and your fees are not going to shoot out of the roof, you don't really need that feature and we might add it later but basically the decision is that we can remove the feature child pays for parent and therefore have longer chains going. And this is what a lot of teams have decided and are gonna do. We don't really have any coordination about, Hey, this is the time we're going to do it. Because as Emergent said, there is some reason to actually coordinate this. I basically think that this is gonna be done when all nodes feel comfortable that their software implementations are gonna be stable enough. Then it can be done within a couple of weeks, especially since we already know that BCHN node has to be upgraded due to some legacy decisions and so when they have a longer chain it's going to be a lot easier to get this rolled out.
So I think that's the main thing with the longer chain. It's gonna be a bit of development work and then it's gonna just be coordination to roll it out. That's it, not very hard.
John Moriarty: Ok, so maybe that's something that's worth clarifying is that the coordination hasn't happened yet, and so is it the case that it may or may not be coordinated for this May 6th upgrade? And, well, I guess I'll leave it at that.
Tom Zander: Yeah, that's basically it.
Emergent Reasons: I'm guessing that Freetrader probably has a statement here.
John Moriarty: Yeah sorry about that, I'm just seeing his messages, so this is from Freetrader, "For the unconfirmed chain limits there is, as John mentioned, a coordination opportunity in May. This coordination to raise the limit from it's current value of 50 transactions would need to happen between the full nodes on the network and particularly the miners. On the BCHN side, we need to do some implementation and testing ahead of May to figure out the capacity of our software that we can safely underwrite." Thank you very much for adding that, it's valuable so everyone gets a feel for where we are in the process. He said, "I've said this in some chat channels before, but my feeling is that an increase to 500 is the low end of what we should be aiming for / be capable of." Very cool.
Emergent Reasons: Nice.
John Moriarty: And so I guess I'll open it up if anyone would like to add to or respond to what Freetrader said. I realized this has been talking about dev topics but if any business leaders who are or aren't involved in the tech, have any concernes or just would like to bring up just with current stakeholders just feel free. And then, if not that, then are there any other things that people would like to bring up about May 6th? Paul, go ahead.
Paul Wasensteiner: Yeah so I'd just like to point out why this is an issue, because I've personally experienced it myself at the first London meetup that we started over 3 years ago now. When you when to spend lots of transactions, like we were trying to give away bitcoins actually, Bitcoin Cash. When you try and make lots of transactions you would come up against this limit. And it feels very very stupid when you're trying to show people the power of this new money and your app just goes, 'No, you can't send that money.' You know, you need to remove these barriers so you can send money whenever or however you like. So the issue is we want there to be as few barriers as possible to be able to spend the money you have. No one likes the computer to say No. So this is one of the ways of doing it.
John Moriarty: Thanks Paul, go ahead, Emergent.
Emergent Reasons: Yeah, so I just wanted to mention that, yeah, absolutely you want to get rid of that type of friction and barriers that cause problems, and at the same time just try to talk about it at a high level. There's some other networks that just say, "There's no limits, do anything you want!" and in reality that just doesn't work out, right? You break your network. So I think what we're doing with Bitcoin cash is a bit of walking that tightrope of doing all the amazing things we can do and also doing it in a realistic and safe way. I think that's a great thing about Bitcoin Cash, it's one of the best things that we're the most grounded in reality and focused on actually using it. How does this look 10 years in the future when there's mass adoption and there's thousands and thousands of transactions per second, and so forth?
I love that about Bitcoin Cash, that we're both trying to make it useful for apps and developers and users, and also trying to make sure that it's gonna work in the future. It's something that doesn't exist in a lot of places in crypto.
John Moriarty: Thanks very much. Josh, please go ahead.
Josh Green: Sure. Speaking to the transaction chaining limit, regarding businesses and what businesses need to do currently for the transaction chaining limit (this is some the we encountered in Dublin as well) A lot of businesses and software has to write limits specifically, to know that they are chaining a transaction too deep. Because you kinda don't get a good amount of feedback when you hit that limit, so a lot of times if you don't cover that yourself, you'll submit a transaction and then it just won't get accepted and you won't really know why or even that it happened.
So for businesses that have already implemented that limit, they're actually in a really good position for when this does upgrade. Because what they can do is they can have network upgrade ahead of time and when they're comfortable that it's at a state that it needs to be, they can reduce their own limit.
So what can fundamentally happen, even if we do this in May or we do this sometime after May, once businesses implement this limit, they can kind of go after the network. So it doesn't have to be this coordinated effort, say in May, where all of the nodes upgrade and we reduce this chain limit, and all of the wallets, all of the businesses, we don't all have to do it together, basically. The fundamental level should do it all at the same time for those who don't manually limit themselves. Just because it kind of reduces the security of zeroconf if we're not all on the same page. But then the businesses themselves don't have to immediately upgrade, so that's something they could do at their own leisure, there isn't a stressful upgrade where if they don't do this they're going to get forked off the network or anything like that. It's like, This happened and now if it's important you can provide a better user experience for your users when you're ready.
So I think, overall it's kind of just emphasizing the low pressure and the low cost for businesses, come May.
John Moriarty: Thank you Josh, much appreciated. So I'm going to open up the floor one more time. If there's any last thoughts..
Cameron Lee: Yeah, I'd like to jump in. The people that I work with and talk to the most are people who like build on or use Bitcoin Cash, not really so much the developer side of things. So what I'm hearing is no consensus change but doublespend proofs and changing the chain transactions. But I think what the people I talk to are most curious about and most interested in is... is there going to be a split? I mean, a lot of people are really, like they've lived through the BSV, they just lived through the IFP last year. Last year was really hard for a lot of people, they've just kinda given up interest. And so, what I'm curious about is, it sounds to me like the plan you're talking about is going to not let a split happen in May. Is that true? Am I hearing this right that a split is very unlikely, come May?
Josh Green: It would be very difficult for a split to happen at this point. One of the node implementations would have to go out of their way and then they would also have to significantly increase their miner share, which for anybody other than BCHN is already very... it's an uphill battle. I think users can definitely feel confident that there is not going to be a split of any kind in May. It would be very very difficult for them to do that at this point.
John Moriarty: And maybe something that I'll add quickly in between comments here, is that when we talk about consensus changes, we're talking about things that decide whether, like, a block on the blockchain is valid. So, splits only happen when there are differences in consensus rules. and that's something that we probably should have made clear a bit earlier. You can argue that's sort of what it means.
I'm so sorry, Go ahead Emergent.
Emergent Reasons: I think Josh's answer was great to recognise the reality that, well, anybody CAN split the network but it's going to be like their own node, and that's it, right? Doing it's own thing off on the side somewhere. So that's good to reflect that reality. And then at the same time, yeah there's basically no chance of anything like that happening. There's just nobody interested in that anymore. There's nobody who wants a split. I think it summarizes down to that, there's nobody who's interested in that. We're still learning how to make things happen without a king, so to speak. I think things are fine. We have worked through to figure things out, how to figure out process, how to figure out consensus and discussion, and making sure that everybody's on the same page and that ideas get considered and get a lot of time to be looked and peer-reviewed and so forth. So, yeah, we have a lot to work out, but as far as splits go, no, there's no chance of that.
John Moriarty: Good deal, and before I get to you Paul I'm just going to read the most recent message from Freetrader, oh wait this is the same message, my apologies. Go ahead Paul
Paul Wasensteiner: Yeah, It seems to me that the goal is not just to have no splits in May, it's just to have no splits in general. Like for as long as actually possible. Which, hopefully, is many many years. This is kind of part of what these discussions are about, is bringing people to the table and getting as much buy-in from as many people in the ecosystem as possible. So that splits just simply stop occurring. So it's not just about May, it's about all of the foreseeable future of Bitcoin cash.
John Moriarty: Very good. Well that's probably a good note to leave it on, but I will leave it open one more time for just a couple seconds if there's any last minute questions anyone would like to make before we finish up.
Cameron Lee: Yeah I'd like to just throw one quick one in just based on what everyone said right now. Is there something that we're working on that's gonna make sure that after May, like Paul was just saying, that it's gonna continue? We're gonna be splitless for a while? Is that something that's a priority? Or is there plans? Like where do I learn what's going on with that?
Emergent Reasons: I'd like to say something about that. I think that there's going to be more than one answer to that question, but it's nice because there's a lot of people who are motivated to say, Yeah we're really tired of this and it makes no sense, and none of the splits we've had had any good reason for them , so yeah, let's stop doing that. And in order to do that I think there will be multiple answers and we'll just try to figure things out. one thing that I'm working on is trying to get people who have, specifically consensus changes, like you said, the consensus changes in the protocol are the ones that have a risk of causing some kind of split if there's a huge disagreement or whatever. But for anything like that, like I mentioned, by getting things out in the air and well considered, and a lot of feedback. In order to do that I'm trying to push a kind of combination of a format of proposals and process, so the chip proposal, the cash improvement proposal that Rosco Kalis has suggested. So taking that idea and making that kind of the format. If you think something needs to be changed, or that it's a good idea or it might be a good idea, we have a culture of putting ideas out there in a realitively standardized format, and that format includes all kinds of information, like the technical ideas, what's the motivation, what's the business impact, what're the costs to people on the network, the wallets and so forth? What are the benefits to wallets and apps, what are the benefits to holders and so forth?
And then in addition to that, getting feedback, like in RCF, and making sure that we publicly record 'Hey this is what these companies think about it, this is what those nodes think about it, this is what - large investors, this is their opinion on it.'
So that format I think will be very useful to have as a kind of standard, like a social standard that we say, 'Oh this new idea has appeared and it's very controversial.' It will just be ignored, right? It came out of nowhere, no one's discussed it, it has no feedback, there's no RFC, miners haven't said what they think about it, businesses haven't said what they think about it. It'd just be like, 'Get outta here, what're you talking about?"
So I think that's the kind of culture we need to set up so that we have a permissionless network, there's no reference node, there's no single person calling the shots. But we also have a kind of process in place that helps us take ideas and digest them and publicly comment on them and work on them. And then eventually they get to a point where, it's like the DAA upgrade right? It got to the point where it was just obvious, there was not really any disagreement about it, except for a notable exception, which is one of the cases that came out of nowhere. So there was so much agreement on it and so much alignment, that, it wasn't really even a discussion. It was like, 'OK, well, we're doing this thing.'
So I think we need to get to that point and hopefully the chips will help and maybe other people have other ideas, so we'll see how it goes.
John Moriarty: Sure, Josh, I'll get to you in just a second I'll go ahead and read Freetrader's real new message, "If there's no consensus change proposed then, yeah someone would need to force a split and there's nothing of that sort on the horizon at this point. And I think the point of getting stakeholders together and discussing like we do here and in various groups is to better understand eachother's needs and to make it less likely that some parties will feel the need to split. We are fortunate that we as Bitcoin Cash survived the split with ABC in November without the same extent of damage to our network as the split with SV. But we absolutely recognise the damaged potential of such splits and that we need to cooperate to perserve the network effect. That's a very significant goal."
Thank you Freetrader. Please, go ahead, Josh.
Josh Green: Sure, and kind of building on the plans for future splits and mitigations, and basically doing what we can to responsibly avoid splits in the future. I think a lot of that has, - well if we reflect on the previous fork, the ABC situation from November. The only reason that was a threat was because of this momentum with the "reference client", right? And I think we as a culture in BCH now are trying to move away from that "reference client" culture. And I think we've done a really good job with these discussions and also just with the people that we have developing and for like the social aspect of what "reference client" is, but we also have the technical component of what a reference client is.
If all miners are using the same implementation it's kind of hard to truly say we're a diverse network. And we're making a lot of good strides this year for diversifying mining in Bitcoin Cash. In January we released what we're calling the Bit Balancer, which is basically just a tool that sits in front of multiple nodes for miners so that accidental splits can't happen - well - not that they CAN'T happen, that they really shouldn't happen, it decreases the likeliness of an accidental split ever happening. And what that really does though is it gets miners the security to use multiple implementations.
But it also kind of really intangibly reduces the momentum of this concept of a reference client. And I think that even the current status quo client, BCHN, has been very supportive of this goal. Like, in order for the bitbalancer to even happen, we had to have a RPC function merged into BCHN. The original plan for us to do that was to make a pull request. So we were planning on going into their code base and actually offering up this change. They are so proactive that they did it for us! We didn't have to actually write the code to do the merge request, which was amazing. We would have never seen that, like, in historic reference clients. So I think, just again, the culture around our environment is substantially healthier.
And with the progress we are making with the adoption for bit balancer and multinode mining, I think we are really going to see a healthy future where if any changes to the network are to happen, they are coordinated and intentional. So I think the future is really bright, and there's been a lot of effort, both technologically and socially, into getting us there. I think we're going to see a lot of payoffs from that in the coming years
Emergent Reasons: That is awesome, Josh.
John Moriarty: Very good, Josh. Andrea, please go ahead.
Andrea Suisani: First of all, hi everybody. To address directly what Cameron asked for, I would say that there is no technical thing to make it so that we are going to avoid splits forever or even on a small horizon, a year, 2 years, whatever. But I guess that the key point is the cultural layer that we are embracing in BCH. We went through painful growth process that I think helped the community to become a community that could embrace culture that, at the end of the day, lead to a more cohesive resilience when it comes to avoiding a split.
Everything that has been said in the last few minutes point exactly in that direction. And then the BCHN way of merging change without even waiting for contribution. The Verde project about the BitBalancer thing. All the things that have been said are the things that we need to continue to nurture. It has to be something that never stops, it's not a goal, it's a process. We need to continue to nurture this process.
It's like freedom of speech, it's like democracy, it's a neverending process to defend what we achieve in the last few months. It is difficult but we are human and we know that when a community needs to grow all the elements of the community need to contribute to this growing process. And not saying that it's easy, but, you know, the last few months if anything taught us that we could manage to acheive this kind of behaviour that is needed to make it so that the community is cohesive.
John Moriarty: Very good, thanks. Emergent, go ahead.
Emergent Reasons: Yeah, um I don't know if we're getting close to wrapping up or not but just in case, I wanted to make sure to get in, on this topic of, you know, like SickPig said, building the culture and process and all of that, and we still have to work it out. And everybody is still working on that in a constructive way. And I hope that everyone watching this will really seriously consider getting more involved.
Right, Businesses who are working on Bitcoin Cash, reach out, start to listen and talk and maybe assign someone from your compnay to stay aware, to actually get directly involved with various channels and try to make sure they are aware. You know, communicate in that direction.
And then the Nodes and other infrastructure level projects should do the same, reach out to businesses and ask "Hey we're thinking about this thing, is this what you need?" and so forth and so I think both directions need to go. One way to do that, is we're doing the Bitcoin Cash commerce meetups, for example. So weekly I just run a meetup where anyone can come and talk about business on Bitcoin Cash. It's been pretty fun. I'd love for more people to be more engaged and more aware.
I think Josh is also doing something, and there may be others, so before we wrap up I hope anyone else here can talk about any efforts like that.
John Moriarty: Sure, Josh go ahead.
Josh Green: I think, firstly, what John just brought up is a really important part of this meeting. Which is, if you are using Bitcoin Cash for your business, like, at least, we are, we, by being Software Verde like, you can reach out to us and ask us questions. We really want to facilitate the knowldege trransfer that businesses need in order to use Bitcoin Cash in a professional and reliable way.
So in addition to the meetups that John's hosting, (which are awesome, we try to attend) you guys can just literally email us or reach out to us on Telegram. it's just anything@softwareverde.com
You can just ask us whatever you need, especially if it's business related, like, "Hey what's coming up in May?" or "How do I do this?" or anything like that. We may not be able to help you directly but if we can't then what we'll do is direct you in the right direction.
So that's an awesome topic and I really wanna emphasize the openess for communication, don't feel like you're on your own, kinda thing.
And then to John's other point, we are hosting a separate, we are hosting like a developer hangout, which is again kind of like a cultural change from what we were experiencing maybe even like a year ago. Really trying to boost morale and coordination and just friendliness of the other development groups. So if you're a Bitcoin Cash developer and you want to get to know the other devs ans have some semblence of a social relationship with them, then you can join our Discord. It's every, well, I host one every two weeks and I think John hosts one on the other week that I'm not hosting one but I'm not exactly positive.
We will post the Discord link and you can join us there, and it's again, very casual, no agenda, "Hey, what were you guys working on?", "Who wants to talk about whatever today?", like, it's anything from technical to "Oh, my dog ate, you know, whatever." You know what I mean? It's very casual, and again it's really just meant to boost the comaraderie between developers so that we don't have animosity. So that just kind helps facilitate upgrades and facilitates new ideas. When the ideas are not shrouded by this kind of animosity towards the actual developer and they can be more focused around the idea itself.
So you're welcome to join, again, we'll post the link.
Tom Zander: And no questions are stupid. That's kind of the background, right? It's not recorded, if you wanna do this and this, you can come in and say, "What do you people think about it?" and maybe we'll have some better solutions. But, we can talk about it, that's the point.
John Moriarty: Very good, thanks. Josh, did you put your hand back up, I'm not sure if it was up before..
(Josh shakes head)
John Moriarty: No, Ok, sorry. Alright, well, I think that's probably a pretty solid place for us to wrap up. So I'd like to thank everyone in the meeting for taking the time to join us for the discussion. You know, everyone's busy and it's, as people have pointed out already, it's extremely important to be able to, in a public setting, talk about these things both for the benefit of the people discussing but also so that people watching and following along can know whats going on in the Bitcoin Cash ecosystem and can feel secure about what may be an investment for them, or a tool or something valueable to their business. Either way, I think that's something valueable that you all have contributed to.
And of course thanks everyone for watching, you can subscribe to the YouTube channel and we'll see you during the next meeting. Thanks very much.
Thank yous and Goodbyes
Always informative.