All right, all you Liberty lovers and welcome to Fiendish and Friends.
It's episode 10, despite what's written on Twitter,
with Noel Lovisa, founder and CEO of CodeValley,
who joins us to talk about his work on emerging coding.
This is a decentralized software development paradigm,
employing a type of software component that cannot be copied or reused with
the objective of achieving both workable developer specialization,
and a practical software components market that was taken directly off of Wikipedia.
Learn what actually that all means today.
As Douglas McElroy observed way back in 1968 NATO software engineering conference,
the software industry is not industrialized.
Emergent Coding aims to change this while using
Bitcoin Cash as the backbone of their payments architecture to enable it.
Please welcome, onto the mic Noel.
Welcome to Finnish and Friends.
It's great to have you with us.
It's a pleasure to be here. Thank you for the introduction.
Thank you. I think the best way is to start right at the very top,
because I'm guessing a lot of people here won't know what
Emergent Coding is or anything that I've said so far.
In your own words,
how do you pitch Emergent Coding to those who know nothing about it,
and what solution is it offering the world?
All right, that's getting right to it.
Emergent Coding is actually the technology that
underpins a practical software components market.
A practical software components market is quite an old idea.
As you mentioned, McElroy proposed it as a solution to
the industrialization of software back in the late 60s.
The components market, a practical components market is
a formidable problem to solve and it does require
components that can't be copied or reused,
so that you're essentially forming a,
allowing a developer to specialize in this space, if you will,
and protect their intellectual property so that they can expect repeat business.
At present, if I sell you a routine or an object or a bean or a module,
I'm essentially giving away my intellectual property,
and I must rely on just goodwill on your part or some license agreement or the like,
in order for you to not reuse that component.
Emergent Coding solves that problem where now we can
deliver a component into your project with full rights.
You've got the rights to reuse it as many times as you like.
You won't be able to economically,
so that's how the protection mechanism, it works.
That ability to specialize means that you can look
forward to repeat business, you can implement improvements
to your component that you're selling, and we can look forward to,
as a community, your component being around into the future.
And that ability to protect your intellectual property,
to protect your prospects of repeat business is what underpins
this practical software components market.
So now your component lives in a classification
and competes with other components from other suppliers in the same classification.
And as you can expect, if your component is faster, lighter, stronger, cheaper,
it will gain market share at the expense of the other components in that classification.
So at a fundamental level, we're correcting the incentive structure for software
that are basically being bypassed because of our inability to specialize, if you will.
And so by correcting that specialization, we make possible a practical software components market.
And if you can imagine that level of competition that's occurring in each classification,
you're basically setting the scene for a fast path for improvement across the board,
just like in any other industry where if I can make a better widget,
I can increase my market share at the expense of other suppliers.
So a practical software components market, to answer the second part of your question,
is really aiming at producing all software for all platforms.
It is a general purpose tech for it's a new way of producing software.
Like I said, it just corrects those incentive structures.
It allows software developers for the first time to specialize.
And that specialization means that we are building software in a decentralized manner
instead of one developer building many thousands of features into a project,
a developer now builds a single feature into many thousands of projects.
So that specialization has a lot of advantages and a lot of challenges,
like one of the most formidable challenges in addition to just protecting the intellectual property
is how do you pay thousands and thousands of contributors spread across 150 countries
around the world for each project.
So this decentralized software tech, it was an absolute gift when Satoshi came up with cryptocurrency,
with the original Bitcoin, which was a peer to peer electronic cash system.
Such a decentralized payment system is absolutely, you know,
you can't get a better match for a decentralized software development system.
I often sort of say that the heavens opened and the monetization scheme descended.
That was just exactly what you could ever have hoped for
in order to implement a practical software components market that can tie together,
you know, 30 million software developers around the world into a single cohesive unit.
Yeah, that is a topic that I definitely want to explore a bit more with you, you know,
just a disclaimer there. So I know Noel, we've known each other for several years.
We've actually spent some time with each other at the BCH 2022 conference in St. Kitts and Nabas.
So aware of his passion for Bitcoin, Bitcoin Cash and the importance of this to his project.
And I really would like to delve into that a bit further.
So just going back to what you said, I think it was really, really nicely said.
And I think it explains very well what emerging coding is doing, what it offers, you know,
to sort of prescribe it to an analogy.
So if you look at a car manufacturer, whether it's a Tesla, whether it's BMW, whether it's Volvo,
the car manufacturer, like in any industrialized process, they're not making everything.
They're not making the components and not making the nuts and the bolts.
And they're not making the the tires.
They have thousands of different companies and enterprises that are working in a free market system.
And they're all specialized doing what they do really well, making that nut, making that screw,
making that gear. And they then sell that to the those components to the car manufacturing company.
And they put that all together.
And and this specialization is what allows incredibly refined and efficient and cheap parts
because the incentives are correct.
And in the end, you still end up with incredibly complicated machines.
You know, cars today are, you know, have more lines of code than most of us can write.
Very, very complicated machines with lots of electronics and lots of components.
And that's the end result. And with emerging coding, as I understand,
it's essentially looking to bring that idea and that model of industrialization to the software market
so that people can specialize on their on their particular tools, their agents,
and then allow this to be sent to the construction area, the construction sites,
where then someone else can create their car, as it were, the piece of software,
the whatever it is that they need to be running.
But in a way that protects the original creator of those products,
they can't just be their work and effort isn't immediately copied and reused.
Do you say that analogy is is that correct?
Could you could you improve upon it?
No, no, that that goes to the heart of it.
The the fundamental basis for emerging coding, that the big change that that is made in Fred Brooks
has mentioned in the that something essential has to change if we're going to fix the problems with software
and certainly to allow specialization, something essential.
And the essential thing that that we've changed is that we've actually reversed the integration responsibility.
And this has massive ramifications. It is essential, absolutely essential change that we made.
And reversing the integration responsibility.
So traditionally, I would create a component stick in a library and you would access that library
and integrate that component into your project with emerging coding.
It's the it's me, the creator of the component that is integrating my component into your project.
So it's actually reversing that integration responsibility,
because part of the information that you require to integrate my component into your project is knowledge about my component.
That's my intellectual property.
And so how is it that I can sell you a component and tell you and not tell you how to use it?
So that was like the fundamental change that had to be made.
If we reverse the integration responsibility, instead of me giving you a component, you give me a construction site.
And by reversing that integration, I get to protect my intellectual property.
You still get the benefit of the component built into your project.
And by making that reversal, I can who knows better how to integrate my component into your project than me,
the author of this particular component.
And so this this reversal really makes the it's a very big change, has huge ramifications.
This construction site thing that that I'm talking about the construction site.
When you give me the construction site and a little bit of Bitcoin cash, I can then create my component into your project.
And that construction site allows me behind the scenes to to partition that construction site,
to to subcontract other components from other suppliers.
So basically making my component as an assemblage of smaller components from other suppliers, like in any other industry.
And this allows these components to properly scale all the way up and all the way down.
So when you scale all the way down, we basically no longer need a high level language or a compiler.
That's just services incorporated into those smaller components.
And at the upper level, we can have components that are very powerful, delivering quite complex features into your project.
And essentially, this is how the industry we're seeing parts of this already.
We call them domain specific languages and the like.
So these high level components that scale up at the high at the high levels of abstraction are essentially like
domain specific components that are really not so much about designing code into your project,
but really capturing your requirements that you that you're that you want to create your application out of.
You want this this feature, this feature, this feature.
So you will choose the corresponding components to create those features into your project.
Yeah, this is a really a paradigm shifting tool.
You can see I think anyone that's listening can see its potential.
And it really goes down to seeing this in action.
How is it actually working? How easy is it to achieve the goals that is set out?
So then the stance right now, you know, actually just back up a bit just to think about the scale of this,
this effort, this undertaking, because it is it is paradigm shifting, is changing the entire paradigm of the software industry
and flipping the sort of as you say, it's like flipping it around completely about how you actually organize that software and project creation.
Code Valley dates back. So the company was founded in 2000, so 25 years ago, 25 years this year,
which first of all, that's you know, that is an incredible time for a company to exist, you know,
for before without a public product release, which I think goes to show, you know,
you must have some very committed investors. This is something that people are very interested in.
You've got some, you know, there's a lot of time there. So what was, you know, what was the bulk of that 25 years taken to do?
Like what has what has taken that time, the bulk of that time to get where we're at today?
No, that's that's that's an awesome question. And we've the way we went about solving this problem,
like just fixing specialization doesn't give you a components market, you know.
So one of the early one of the the first things that fall out of out of that reversal,
that specialization is that we these components no longer have a runtime interface.
They there is no runtime interfaces. And so the components that we created,
we can't draw upon the the the beautiful libraries and all the work that's been that's been done to date
because these components now essentially have a design time interface. We at design time,
we're contracting you for your component and your runtime interface is actually part of the design.
As you build it into my project, you know, the runtime interface is essentially seamless.
They're seamless. The component is seamlessly integrated.
So part of that big delay, part of that not delay, but part of that huge gestation period
is to to major efforts. One is we we just didn't know what these components would be like,
you know, where are the the interfaces at design time between these components?
And those sorts of questions only come about through lots and lots of experience.
But the real killer, you know, the real thing that took enormous amounts, sums of money and effort
has really been our goal to to, you know, we wanted the integrity of fielding a system that was built
with the system. So it we wouldn't have any legs to stand on if we said, all right,
we want you to build your component server with, you know, Ruby or something. We needed you to
we needed to build the entire infrastructure for this software components market with
this software components market. And so we had to tease out north of five thousand components,
build and field and test them all so that, you know, using, you know, we had the bootstrap.
So we had to use conventional programming languages initially until we had enough
components that we could then build components. And so this became the, you know, this is the
the the the big time consuming effort. We wanted the integrity of having the system built with the
system. So we perhaps could have went to market a lot sooner. But now, you know, what integrity would
we what what how would we fare in the market if, you know, we want you to build this very sophisticated
component server that can accept the payment and construction site can subcontract and and can,
you know, collaborate with peers and arrive at arrive at
when you're collaborating with peers, you know, arriving at decisions that that comply with
everybody agreements and so forth and do all that automatically. You're talking about a very, very
sophisticated piece of software. And so we actually have this mountain of components across four
levels of abstraction that can build your presence in the marketplace to so that you can supply
your components into the market. The system is completely decentralized and it's it's completely
non custodial. So, you know, your components, the only presence in the market that your customers see
is just in the catalog as a reference in the catalog. But as you understand, you're actually
designing your component into everyone's project. And so there's a fair bit of infrastructure at
your end into to support your component. And so really, it's those two factors that have really
cost enormous amount of time to to create a the essentially the first practical software
components market. And, you know, there are some huge advantages to that. You know, just that
integrity is is the most important thing that we were chasing. Yeah.
I think that's a really fair point. If you're not using your software to create the the software,
then what integrity would you have? So this is a this is the biggest challenge that you had. And
this is what I understand then this is what took the bulk of that time to to get to the stage where
you're at now. But you are now in in testing. So in 2023, you released this opens for businesses
to be to be testing on this. So we're now into the into the second year or 2025 now.
And I'd love to love to know. So, first of all, I mean, we just said actually is it's kind of
interesting because in my in my mind, what I was imagining that emerging coding would be very useful
and certainly at the start for creating highly efficient code, so highly highly efficient
binary code where memory constraints are important. But it sounds like that the scope is actually
the scope is actually already much wider than that right from the get go. Is that correct?
Yes, absolutely. As as I mentioned from the get go, you know, the tech is really
it's it's really a replacement really for the current software system. You know, it's designed
to produce all software for all platforms. And I've actually had a conversation with Doug McElroy
about this. And when he proposed it in 1968, you know, how is it that that the solution to
specialization eluded him, especially when the the incredible brains that were at that conference,
it's a NATO conference in Germany at the time, and they were tasked with finding a way to solve
solve the software crisis at the time. NATO being a military organization, the largest
software projects at the time, probably like today, are military projects. And so there there was a
lot of, you know, lot, you know, cost overruns and schedule overruns like there are with software
today. It's, you know, software is a formidable problem to big projects, fair worse. And asking
him about what, you know, why, why wasn't this reversal, you know, this solution to specialization,
why wasn't it found, you know, discovered at that time, especially with the brains in that room.
You know, I've got theories, he's got theories. And one of the theories is that
that the high level languages that were invented at the time, only were invented
in a few years earlier, 1954, with the advent of Fortran, and such a step change it was that
high level languages were were just embraced, and it was expected that any solution would
would involve high level languages. And so here, if you if you look carefully, we're reversing the
integration responsibility to create a component, essentially turning a component from a piece of
code to a service, a design service that we design that code into your project. And as a design
service, we can protect your intellectual property. As a piece of code, I've got to tell you how to
use it. I've got to embody that code that you can copy and use it in other projects. If I'm building
that that piece of code, a fragment of code into your project, then that's not readily available
for you to use, even though you have the right to in another project, you can see how how that
that reversal converts it from a piece of code into a service. And really, there, there is no
where do we we never pass through a compiler, we never pass through a, a coding stage with
emerging coding, you select high level components, which is, you know, the embodied the features that
you want your project to do, you contract them. And they essentially return you binary that you
concatenate to produce the the final executable outcome. Those fragments of code were actually
created by subcontractors to those prime contractors, well, technically, those subcontractors
also use subcontractors and so on and so forth down the levels, many levels of abstraction. So
we've got components that exist over many levels of abstraction all the way down to, you know,
a fragment of code to add two numbers together, you would think such a component would be easy
to implement. But, you know, to, to be given a construction site, you must participate in several
collaborations, you know, you'll have to participate in a collaboration for your input
variables and your output result. Because, you know, your piece of code has got to work with
the other pieces of code that are being designed into that project at the same time. So you've got
at least four collaborations, even if you wanted to design the code just to add two numbers together,
you need to participate in a collaboration on on how one of those variables is going to be
represented and where it's going to be, etc. And another variable for the two inputs, and then the
output, you need to collaborate in another, you know, participate in another collaboration,
arrive at an agreement for the output variable. And of course, you need to collaborate in the
construction site itself. So you've got to do a lot of work to arrive at those agreements before
you can render that fragment into my project via the construction site. But, yes, that
it essentially predates high level languages. And there is in discussions with McElroy,
it seems like that they were blinded at the time, just because of the incredible performance that
high level languages were able to give them in the early stages of the software industry.
And that it was just generally accepted that any solution for these reusable components things,
you know, that we wanted to create had to be cast in the form of, you know, high level languages.
And so these early attempts were like libraries of routines, you know, or, you know, objects in more
recent times, or, you know, beans or the like. And so these are even components, there are many
attempts at trying to solve this problem. But as, you know, something essential had to change, and
it's a very big change. So it does mean that there are quite a significant departure from current
methods. But it eliminates enormous levels of duplication where all these different languages
need these different libraries. You know, we suffer the same thing in Bitcoin Cash, where we're,
you know, we are beautifully decentralized with many different node suppliers, BCHN, BCHD, Flowy,
Verdi, Knuth and the like. Now, they're using different languages and different libraries and
so forth. So if we were a library, I mean, language agnostic, we could eliminate a lot of duplication.
And we still get that diversity, but not from like having different node suppliers,
from having different component suppliers, like the same component from several different suppliers,
if you know what I mean. So we still get the diversity, but it's done properly like other
industries, you know, I can buy a tire from Goodyear, and if that tire doesn't meet my
requirements, I'll go to Bridgestone or the like, you know, a different supplier. And that
competition over that one component means that we always get a premium quality outcome. So fixing
those incentive structures. So there is some big changes that it's going to ruin, but of course,
it's not because, you know, we don't have to do all this work for nothing. There are huge benefits
associated with this. Correcting this incentive structure means the whole, this whole market is
on a fast path for improvement. You build the same application with the same requirements tomorrow
with this system, you're likely to see it being more, a lot of faster, stronger, because at every
level of classification, at every level of abstraction, we have component suppliers competing
for business. And that's why, you know, that's why this building software with this technology
will converge on, you know, optimal solutions, which is really quite astonishing. You know,
if you have a library, just the act of using, you know, a routine or an object out of a library,
you know, you're conforming to a runtime interface. You're sacrificing runtime performance for
it trying to determine its runtime context. We get the runtime context. At design time, we know,
you know, when this code is going to run, what it's got to do and what it's got to work with.
And so we can, these features when they're designed into the application can be very efficient.
And, you know, that competition will drive that efficiency over time. Yeah, quite an interesting
Yeah, this is something I've heard about from developers that have taken the pilgrimage to
Townsville, and they've seen emerging coding in action, they've said, you know, some of the
some of the outputs, the creations were just mind bogglingly small. So, you know, taking, taking,
don't don't shoot me for the exact amounts, but I'm roughly in a factor of, you know, something
that would be 500 kb that was already really small down to 50, it was just so incredibly efficient,
only having because the the output only does exactly what it's been told to do. So you don't
have any libraries with that. So very interesting. What I imagine many people will have the question
is, like, just taking everything that you said, and thinking about this process of creating an
output, and taking that all at face value that, okay, this creates a really efficient process
that creates the desired output, and does so in a way that protects the intellectual process,
the intellectual property of the person creating these agents and creating these components.
And what I think is really interesting is thinking about the input, because for me personally, I can't,
I find it very challenging to imagine how that input would be made in a way that someone can
create what it is that they want to create more effectively than with code. And so on your website
that you've got a screenshot showing the IDE or the software development system. Is there, you know,
is there any videos that someone could take a look at, you know, to see how this is, how this
works in action? Or is this something that is planned for the future? Yeah, look, that's very
interesting. And a whole other field. It's quite a big question. I did allude to the, you know,
the upper levels of these new components, you know, higher levels of abstraction, really being
there to capture requirements. Remember, these components, there's no high-level language
involved. So integrating these components are not your responsibility. You're contracting somebody
else to do that. And so essentially, there's no glue code, which is what you would be faced with
when you were conventionally integrating, you know, library routines or the like. There is no glue code here.
These components will build, you know, they'll cooperate with each other and build their
features into your project. So the input is, you know, essentially the high-level features that are
domain-specific. So we call that top-level layer of components. We call it the behavior layer. And
essentially, that's the, at the present time, at least, that's where we're limiting our upper levels
of abstraction. And so you would create an application by selecting behavior-level components
and putting them together. And that example that's on the website is our studio, you know, it's a
little editor that attaches to the catalog. And so you can peruse the catalog for these, you know,
these components that are available. And there is essentially one line of syntax. It's not a
programming language. It's a contracting language. That line of syntax defines the contractor, you
know, fully qualifies the name and the requirements that that contractor requires, including the
construction site. And that document we call an expression is basically a list of those contractors
and how they are expected to, you know, the permissions for them to cooperate with one another
in order to deliver your binary executable. And each of those, each line is essentially going to
cost some money because you're going to be contracting somebody to perform that service.
And that's one of the beautiful features of building software with, you know, real components,
is that, okay, you look them up in the catalog and you, all right, this component's, you know, 20
cents or this component is $20 or whatever, you know, before you hit the build button exactly how
much this is going to cost, how long it's going to take to build, what sort of resources it's going
to use and what sort of performance you can expect, you know, those sorts of things, you know,
those sorts of things are kind of upfront, like in other industries, you know, we, you know, before
we purchase something or before we build something, if we know what the price of all the components
are, we know pretty accurately what the total cost is. And so, here, we have the same advantages
in building software. You, you know, you would create an expression and remember those high-level
components, they're there to win market share. And so, being domain specific, if you're going to build,
let's say, let's say, general protocols wanted to build the, their XO wallet, if you're going to
build a wallet, you know, there are certain components that, that would be very useful
for that specific kind of application, you know, and people could create components that target
that kind of application, being domain specific. We are seeing vestiges of like domain specific
languages in industry. And, you know, there is, there is, you know, some advantages to that.
Here, it naturally pops out at high levels of abstraction that, you know, we can create a suite
of behavior components that are targeting a specific form of application, making the expression
of that application very easy to do. And if it's not easy to do, then, you know, an enterprising
young man like yourself can see, hey, look, if I build this sort of component, I can make it even
easier to use for people to, you know, create an expression. You can see how, how, you know, any
impediment here, you just build another component and capitalize if there is, if there is an
impediment, you know, in the car industry at the, you know, hundreds of, you know, 100 years ago,
it's a formidable task to get a spark to occur inside an engine block under extreme pressure.
You know, you got to get through that engine block somehow, and, you know, with a wire that
can't be blown out from the pressure and create the spark at the right time. And, you know, an
enterprising individual come up with an idea for, hey, I'm going to create a bolt. It's going to
have a screw thread. It's making it really easy. But this bolt is going to have like an insulated
core, and we're going to call it a spark plug. And we, it can easily be added to the engine.
I'm going to solve everybody's problem overnight. This guy sold, you know, thousands of spark plugs.
And everybody switched from 30 different methods of trying to get a spark into an engine block to
just buying this guy's, you know, spark plug, which solved the problem kind of cleanly.
So the same thing here. You know, these domain specific components, we can expect to see domain
specific components pop up for every kind of application and, you know, software type that
exists. There are hundreds of thousands of different software types. So we can expect,
you know, domain specific suites of behavior agents for each of those software types to make it
effortless for somebody to come along. And, you know, they've got an idea for some software,
and they've got a checkbook or some Bitcoin cash. And they can readily create software to
realize their idea. Okay, cool. That's fantastic. And that's actually a good point to go on to the
question that I had. So just thinking about what domain specific components are already available,
because as said, this has been now in testing. So understand that several companies are using this
in the testing phase. And I'd just like to know, like, are we already seeing that? Are they also
they're creating, are they just using the components that already been built to compile what they need?
Or are they actually already starting to create these, the components themselves, as a requirement
for their projects? And also, I'd love to hear about, you know, how is that testing going? And
what's the feedback from the people that are using this? And are you happy with the results so far?
Well, you know, technically, we're still, you know, in stealth mode. But I, you know, it's a very big
project, and it's spanned decades, and tens of millions of dollars in investment. The market
itself really consists of like, two pieces of software, essentially, one piece of software is
what we call Studio, and it's really the product that we sell. Studio allows people to access the
catalog and lay up these expressions and build them, you know, so manage the build process and
return the binary executable. So Studio, it's quite a sophisticated piece of software, as you can
imagine. And the other piece of software is an agent, you referred to it earlier, an agent is what
a developer would field on their hardware, on, you know, where, and they would create the agent,
which would allow that developer to accept, you know, many contracts simultaneously. So essentially,
an agent can be thought of as a component server, even though this is, you know, it's a service
that's being provided. So as I mentioned earlier, a developer moves from building many thousands of
features into a single project to building a single feature into many thousands of projects.
You know, this is the idea of specialization. And so the practical software components market merely
consists of, you know, millions of these agents distributed around the world, and these Studio
applications to allow people to use those components that are fielded by those agents. And
that, the catalog is also distributed. So each agent, we use technology to, you know, cadamia
to distribute the catalog. So the community itself is hosting the catalog. And it's integrated into
each agent and each Studio application. And that's been, you know, that's quite, those two
applications represent the entire market. That is the entire market. So essentially, component
servers, the catalog, and Studio, which is tied together. And because the agents are hosted by
their respective owners, the developers, that's why, you know, it's completely noncustodial.
Their intellectual property of how their component works stays on their machine and is only
accessible as a service. Their wallet for payment, et cetera, is on their machine. There isn't. And
they're hosting a little bit of this international catalog where, you know, their particular
component would be listed in a particular classification at a particular abstraction,
along with all their competitors. And so that's the kind of, you know, the structure of it.
But for testing purposes, we had to create, you know, several thousand components to,
at several different levels of abstraction, to be able to build Studio, to be able to build
an agent. And so a developer wishing to participate in this components market,
they need to build an agent and run it on their software. But we have a beautiful system, which
has several thousands of components, including a suite of behavior components that are purposefully
designed to create agents. These are agents that can create agents. And this is part of that
integrity issue that we spoke about earlier. And so here, a developer wishing to create a component
and participate merely has to express the high-level requirements. And we've got domain
specific components for that. You know, the sorts of things that you would need your agent to do.
We've got components that can design those features. And so you, theoretically, you could
express the requirements for your agent, submit it to this community, and in a few minutes, you
know, receive a binary executable that would perfectly be compatible with the rest of the
community. You would then run up that agent on your hardware, make sure you test those services,
and then you would just register that agent with the catalog. And the agent has already got the
catalog built into it because it's decentralized. And so it's a matter of just participating in that
data structure, that global data structure, by publishing its design time interface, essentially.
It's like a business card for that particular component. And now it's accessible to the rest
of the world, and it can be generating income within minutes of, you know, joining the community.
So testing has really been a huge effort. We have what we call a rake. We can rebuild our entire
portfolio of components by submitting the new requirements to the existing community of agents,
and they will generate, build a new generation. So if we need a feature to be added, especially in
these early days where we're not on the market yet, if we want to add a new feature, let's say we
want to put a balance sheet and profit and loss, an income statement in the console tab of your
agent so that you can look at your financial performance of your component, we would just
create those agents and just do another rake, and now every agent has this finance tab built into
their console. So the testing has been this process of raking new revisions as we approach
the reliability and performance and the features that we desire of the starting market, if you will.
And we do have a small number of technology partners that have their own components,
that are part of this early system, and we have, as you mentioned, we, in fact, we did some
tests way back in 2016 using Bitcoin when it was still electronic cash, and back in 2016, we had a
centralized version of the components market, and we built up a capability to a point where we could
actually create individual agents, and so we then decentralized, and so now we have a fully decentralized
software components market that is created by this large group of software agents that we've had to
build, identify, build, test, deploy, and get them stable enough that we can build an application
from millions of contracts reliably. It's a formidable challenge. And the payment system,
of course, and I'd like to talk about that after I finish this question, but the payment system, too,
is a formidable challenge, but coming back to testing and in a decentralized manner with
a payment machinery, we did deploy a market internally in late 2023, and we did spend last
year adding essential features. We were using the components market prior to 2023 without payment
machinery, so these agents would work for free. It's not a form that would be practical. If you're
going to build a component, you want to get paid for it. So the payment layer is a recent development,
and it has been a formidable challenge to get the payment machinery in there to make millions of
payments, very tiny payments, international, small payments, reliably. Each agent has to have a
wallet. Each agent receives payments. Each agent must make payments. So you can imagine there's a
ton of machinery inside an agent just for the... A ton of machinery and also imagine a ton of
bandwidth. So I think just to make it clear for everyone, so Noel was using BTC, so the original
chain, Bitcoin, before any forks or before the notorious forks and the block war, was using BTC
for these payment systems. But of course, as Noel alluded to, which everyone in the community is
aware of, because of increased usage without increasing the size of the blocks, which was
always planned by the original developer, the founder of Bitcoin, Satoshi Nakamoto, this wasn't
increased, which caused a lot of problems for you, as I understand, because this was handling this
sort of bandwidth of transactions. This isn't something that Visa or MasterCard, it can do
because of the low amounts of the money that's being transferred. So Visa and MasterCard,
especially Denver, still true today, was really only sort of affordable when you're talking about
whether it's 50 cents or a buck or something much higher. And of course, then you have the problem
of exchange rates in different countries and legal liability. If you're facilitating fiat,
especially across borders, across countries, there's a lot of risk there. And with fraud and
cashbacks, as well as everything else. So a sort of a decentralized working payment system
needed to be there. That was Bitcoin. BTC didn't work out. For whatever reason, there's a whole
book written about that. And then you moved it. So of course, there was the forks that happened.
There was the Bitcoin core, it continued its way with SegWit, we had Bitcoin Cash, continuing its
way on the original strategy of P2P Cash for the world. What made you choose Bitcoin Cash? What
properties did it have that you thought, hey, this is, you know, in all of the crypto world,
with all the possibilities that have in fiat, with Visa, with MasterCard, and all these different
payment systems, what made you choose Bitcoin Cash, which you use to this day?
Yeah, look, that's, you know, that is such a good question. You know, back in the day,
there was only Bitcoin. And in 2016, Bitcoin had already been taken over, but it was still practical,
you know, you could still use it as a medium of exchange. When it did,
when it did get full blocks, and it stopped working as a medium of exchange, it's not so much that it
stopped working, they didn't want you to use it as a medium of exchange. And so here, with this tech,
we really needed that medium of exchange. So, you know, we were involved in trying to win back the,
you know, the hijacking to get rid of the hijackers. We participated in Bitcoin XT, Bitcoin
Unlimited, Bitcoin Classic. You know, these are attempts to regain control of Bitcoin. And it was
pretty bleak. We, crypto can be thought of as a solution, looking for a problem. And we genuinely
have an industrial problem that is such a good match for cryptocurrency as a medium of exchange.
We have our software development tech, and crypto is software. It's completely virtual. It's, you know,
it can be completely implemented in software. It's such a perfect match. And, you know, we have a
decentralized system, and it's a decentralized system, and it's peer-to-peer. It's such a good match.
So when, I can remember, they were very dark days, because I wasn't aware of the work being done to
split Bitcoin Cash from Bitcoin. And I can recall in mid-July, SegWit was going to be activated in a
couple of weeks. And, you know, I've got no solution for this tech. I've got no solution for this tech.
And, you know, Bitcoin Cash popped up, you know, as a project two weeks before SegWit was going to
activate. And the first I heard of it, the, I, Omri Sashay, I, he never finished the sentence,
and I was on board. Like, I needed, I needed the original Bitcoin, which is what Bitcoin Cash is
today. I need that original Bitcoin. And we've actually taken it a lot further. Not only is
Bitcoin Cash perhaps the closest humanity has come to inventing ideal money, but it's got a lot of
other properties that make it, you know, very suitable, very ideal for global money, not least
of which is its governance model, which is miles and miles ahead of like any other, any other coin.
But it also has really advanced features. And we're using some of those features, you know,
in terms of smart contracting and the like, we make extensive use of payment channels. So we're not
only using a leading coin, we're using the leading tech on that leading coin. And we're using a
leading, you know, software development tech to implement it all. It is very, very exciting space
to be in these payment channels. As you can imagine, these components are made of smaller
components. And so each business, each business of producing a component is has long term
relationships with other businesses for those smaller components that they subcontract.
And those business relationships, they would be long term. Because if I'm going to subcontract you
for a component that gets embodied in my component, you're representing my reputation.
If I'm choosing a bad component, it's not reflecting on you, it's reflecting on me. You know,
I think the Ford Motor Company back in the late 80s did a recall in North Queensland
because a Bosch relay in their car wasn't specced correctly. And you could be driving down
the outback at high speed at the middle of the night and there goes your headlights.
And, you know, Bosch created the faulty relay, but it was Ford that took the hit. You know,
they did the recall and it was their reputation that got tarnished. And so these long term
relationships are really important to establish because, you know, you want to present the most
highest quality component to your suppliers to win market share, then you must use high quality
materials like in any other industry. So it's your choice of subcontractor is very important.
If you've qualified a subcontractor, you want to stick with them, even if there is perhaps
other suppliers that can supply the same part that you are supplying me, I would still stick
with you, you're qualified, you know, and if it got to a level where, gosh, you know, they're like
half price or something, I say, look, you know, gee, fiendish, you know, we've done a lot of
business together, but, you know, your competitor here is that half price, you know, can you sharpen
your pencil for me? You know, I'd still want to work within our relationship as in any other
industry. Those reputations are important. And those reputations are perfectly matched for
payment channels. And so here we can use a payment channel where we can elevate payments that are too
small for to operate in the Bitcoin cash, you know, payment system. We can elevate them into a
into a payment that's large enough to be on chain. So we're tapping into a whole payment channels
allow us to open a whole other part of the economy to pay on chain payments, you know, so this is
very exciting. And the properties of payment channels are just extraordinary. Because you
create an escrow where both the supplier and the client have signing rights. So the supplier can
never be can never be duped, you can never make a double double spend because the supplier,
your supplier actually has a say in creating the transaction. So they would never, you know,
dupe themselves. So there is just there is just zero chance of a double spend with a payment channel.
And you can have any level of protection because the escrow can be done offline, you know, can be
done weeks before we can have 1000 confirmations on the escrow. And then we can do as a payment
to you irreversible cash as quickly as I can sign a datagram that makes each of these payment
channels each of these payment channels exceed the capacity of all the world's, you know, credit
companies combined. You know, we can do millions of transactions in a payment channel, you know,
a per second effortlessly, because it only represents two transactions on the blockchain,
one to open the channel and one to close it at the end of the day.
And actually, yeah, that's a really interesting point, just thinking about emerging coding,
when this does have a public release and its effect on the chain. So what you what you just
said, they alludes to it is the fact that actually, even though it might be millions of payments via
the payment channels, in the end, that would be two transactions are very, very scalable,
which is fantastic for your business, fantastic for people using it as very, very low cost,
which means that the developers are the creators of these components gets to keep their money,
as opposed to it to go to other things. Yeah, just thinking about that in respect to
BCH. So if everyone looks onto the BCH, and network is possible to see a number of transactions,
and we can see that that there have been some incredible spikes since 2023. So the base level
somewhere between 11,000 and 15,000 transactions per day. But then suddenly, there are these
these spikes that last for one, sometimes two days, that have taken that that base level,
and then, you know, 10 x or much more than that. And a lot of this activity is attributed to
emerging coding. So maybe, you know, just understanding what you've been saying there,
it sounds like the emerging coding wouldn't actually generate such a huge number of
transactions. So what was the cause of the spike of transactions in these times?
You know, excellent question. I did the calculations late last year, and emerging coding
coding was responsible for something north of 6% of all transactions on the Bitcoin Cash blockchain
worldwide last year. And yes, there were some huge, huge spikes. So coming back to if you can just
look at the market again, you have a you have a component supplier, he has five or 10 subcontractors.
Well, that component supplier would have a payment channel to each of its clients,
as well as payment channels to each of its suppliers. Now, when the market is operating,
we've got thousands of components in operation, you know, there's hundreds of thousands of payment
channels in operation at any given moment. Now, when we're doing testing, you know, we we bring,
we need to boot, we need to boot this components market into life. And that means we establish
large numbers of payment channels. Now, if we need to, for test purposes, we need to shut the
the market down, then we need to close a lot of these. So 150,000 payment channels, you know,
we might need to close. So what we were doing during testing, we were generating large numbers
of, of transactions, as we were creating the the, you know, bring booting the market,
and large numbers again, when we would close the market for whatever purpose, if we had a new
revision or something like that, we restart. When it's in operation, you know, it would never be
shut down. Each each component can be replaced live, you know, it might be hosting 100,000 contracts,
and it will be we have a method where we can upgrade the your version, you know, you can build
a smarter, lighter, faster, stronger version, and bring across the the contracts that are currently
in flight. So part of the testing that that it is inflated the numbers, like you said, there are,
excuse me, there were a much more larger number of actual transactions last year. But
principally, that was because we were starting and stopping the components market for whatever reason,
and as we were adding features or testing, you know, improving performance or the like. So,
That makes a lot of sense. So we're just thinking about like the, so you've got a few hundred
thousand channels, as I understand today, what, and what sort of length, when do those channels
need to close? Is this something that can stay open for a year? Or is it is it a shorter schedule?
Good question. And really, that's really up to the individual developer. As you can imagine, we have
components that exist over many levels of abstraction. And if you're having a supplier,
you know, at a certain level of abstraction, you have certain suppliers at a lower level of
abstraction, your, your income is essentially the the cost of goods. So the these, your contracts
to those suppliers, and you would add a margin, you know, so typically, we would operate with like a 20,
a developer would operate with a 20% gross margin. And so your price that you would list in the
catalog would essentially give you, you know, 20% return on any contract that you receive,
because you'll be spending 80% of that contract fee with your suppliers. And the the payment
channels, you know, you can, you can put, it's up to you how many payments you can put into a channel,
you know, you can open a channel. Yeah, there are two parameters there, the number of payments in
a channel and the length of the channel, the time that the channel operates over. And so
during testing, we might run channel lengths of only a single day, to maybe a week. But
when the market is, is operational, it's up to developers, you know, having a channel operational
for say, a month can really cut your costs. But you're you're not only when that channel closes,
does that money get freed up into your wallet. And so you can cut costs, you know, reduce costs
and reduce the fees. But you know, you don't have access to those funds until the channel actually
close. So I could probably run a channel over a three or four days. But I'm paying a higher
percentage in fees, but I get access to that money sooner from an accounting purpose, you know,
in the channel when a payment is made, the instant I send you that datagram, I can never get that
money back. Like that is irreversible. You've got the transaction. There is nothing I can do to get
that money back. So from an accounting perspective, the payment in the channel, even though it hasn't
settled on chain, is when it's considered that you're being paid. Because that's the irreversible
event, if you know what I mean.
That's really interesting. So it sounds like it might be then kind of tricky to say on public
release, when this is being in the hands of people and people can come to you and use this tool,
pay for this tool, it would be impossible to say sort of what sort of transaction level it would be.
It really depends on everyone that is using this and how often they want to open and close the
channels. But it certainly wouldn't be the spikes that we've been seeing is what I understand,
not unless you've got a lot of new updates coming out and need to restart the whole mechanisms
behind this. Is that correct?
I think I've lost you.
Can you not hear me? Okay, then I had some more questions for Noel. So I'll have to save them for
another time, unless Noel can get his mic work as his headphones working. But these are the sort of
usual issues that happen with Twitter. So Noel is also responsible for, in Townsville where
Emerging Coding and Code Valley is based, is a town with a lot of BCH adoption. And this BCH
adoption, so I see there that we've got Bitcoin Jason is one of the people listening. I don't know
if Bitcoin, if you want to get on the mic and talk a little bit about the work you've done in the past,
but Bitcoin Jason is also someone who helped with this of getting merchants on board accepting
Bitcoin Cash in the surrounding area. And the idea behind this was, if you've got this
amazing tool that's coming out and people can build their agents and people can build their
machine code using this platform, and the backbone of that is Bitcoin Cash, then there also needs to
be, it's much more valid if there's a market for Bitcoin Cash, rather than these developers,
agent builders, do cash out into fiat. And so, Code Valley spent a lot of money in creating this
market there of lots of different businesses, all accepting Bitcoin Cash with the idea of
trying to create closed markets. And this is why Townsville is now, has been known as Bitcoin Cash
City, and is sort of a pilgrimage for a lot of people that are in the community for a long time
to travel there and to experience this, being able to use Bitcoin Cash on a day to day basis,
and in the stores you go to, if you want to have your haircut or grab a Coke. So, very, very
interesting place. So, I'm going to just remove Null and then try and bring it back in, see if we
can get one word on that. Yeah, and tied in with that, so there has been a Bitcoin Cash conference
way back in Townsville, several years ago, and there was also another conference planned, oh,
Bitcoin Jason, there you go, should be able to give me the mic, there's a Bitcoin Cash conference
in Townsville planned later this year, which is the third larger Bitcoin Cash conference in Townsville,
Bitcoin Cash conference that I'm aware of that is happening this year. Hi Jason, did you,
you're free to speak. Oh, yeah, no, I love living. How's it going, man? It's going good, living the
dream. Yeah, great. There's nothing like going to work and just going through a drive-through and
paying in Bitcoin Cash. There's nothing like it. I'm a bit spoiled in a way because there's a lot
of merchants here that accept it and the recent price pump was pretty good during the holidays,
so I had a little bit of extra conversion that I can do and I got my ute fixed with it, got new
tires on the X5, so anything from mechanics to groceries, coffee, helicopter rides,
that sort of stuff, it's quite good that you can, plasterers, you got plasterers, painters,
lawn care people, all using Bitcoin Cash. It's a new cashie for the tradies. We've got a lot of
builders. Cashie for the... Yeah, no, I'm being fair dinkum. I'm being fair dinkum because
the thing about cashies, right, if you do a cashie as a trade, talking in trademen talk,
you're doing a cashie, you're doing it at a discount rate. So what the tradies do is if they do a cashie,
they prefer Bitcoin Cash because they know that whatever residual that they have in Bitcoin Cash,
they know it's going to appreciate over time. So that's why a lot of tradies love it.
For someone like myself, having something that appreciates over time, if you use a trade,
say you get your air conditioning fixed and you pay them in Bitcoin Cash, not only are you getting
a discount rate, getting their work done, but because the asset has appreciated over time,
you get it at another discount on top of that. So that was the case.
Living the dream. Yeah.
It's fine. It is. It's living the dream. And yeah, so I know I think you're back. So
what I was just talking about while you're having the technical difficulties
was just about the adoption that happened in Townsville. So there's a lot of Bitcoin Cash
adoption. I don't think you heard. So what I was saying was that this was basically,
this was done as a strategical shift so that to give it an economical loop for people that are
using emerging coding, so the financial tool, the backbone has been Bitcoin Cash. So there's,
you know, for people rather than having to cash out into fiat and go through that particular
issue of using exchanges or whatever that is, that they can just actually go and use their Bitcoin
Cash that they've earned and spend it in the garage, in the spa, for the hairdressers,
in the local shops and so on. So it basically gives even more boost to this ecosystem.
I don't know if there's anything you want to add to that or, you know, and about the
efforts you've been doing as part of Bitcoin Cash adoption around Townsville or, as I've
let everyone knows, Bitcoin Cash city. Certainly, it grew out of being a huge fan of
Bitcoin Cash or crypto. I felt a need to give back to the community because
essentially, you know, I'm getting to use the payment layer for free. Like it's an extraordinary
capability and it was just created selflessly by Satoshi and all the folks in the Bitcoin Cash
community. So I felt that, you know, as a company, as a corporate entity, we're going to use this as
a payment layer for monetization and I wanted to contribute back to the community. And gosh,
you know, we've moved on from that now to a point where it would make so much sense for Australia to
adopt Bitcoin Cash as legal tender. Just think what an efficient currency and payment system would do
for our GDP, you know, and international trade, you know, all that exchange rates and corruption.
And so it would go out the window. You know, it would make so much sense to and be quite smart if
Australia could be proactive and be one of the first nations to adopt Bitcoin Cash. There would
be huge advantages to the first nation. I wouldn't want to be the 150th nation to adopt Bitcoin Cash,
for example. Yeah, and with regard to that, so I can highly recommend the book Free to Choose
by Milton Friedman to understand just why that would be the case. So, you know, by not having
these exchange rates, which are hugely manipulated by central banks of the various countries,
which causes huge resource allocation mismatch and therefore like quite a significant decrease
in our wealth. So just having this currency, you know, a lot of people still think about coins in
their wallet, but essentially that database is just distributed everywhere. It's essentially,
you know, and it's a ledger just like beads and you're just moving beads across to different
accounts. So, you know, you don't have that. There's no borders for Bitcoin Cash. There's
no exchange rates. And the most important thing of all is there isn't a government that has can
use monetary policy that can, you know, inflate the currency and everything else to distort the
market. So, you know, it's not just all of the middlemen you're cutting out, which is a huge
boon, you know, all those banks, all those people that involved in the exchanging currencies,
which is complicated. If you look at the back end, they've been changing the Australian dollar to
the American dollar to euros. It just removes it all and allows that price information to travel
unimpeded. It's clean. It's basically the highest signal it can possibly be, which invariably leads
to a lot more wealth creations. So, yeah, as I said, free to choose is one, but there's many
out there, also Rockbar to basically delve into that concept, which is really interesting and why
a lot of people, I guess, are very interested in cryptocurrency as a whole. So, yeah, I'm not
sure if you wanted to talk at all about the conference. So, I know that, you know, that you're
organizing a Bitcoin Cash conference in Townsville later this year. Is that something you'd be
interested to sort of go into any details or is that something you'd rather save for another time?
No, no, look, I would thrilled. I think it's important to mention it. I think it would be wise.
The conference is slated for late August this year. We haven't posted the tickets yet. We didn't
want to step on any bliss toes and we did want to wait until Buenos Aires, Argentina had posted the
outcomes of their conference. So, the way is open now. So, we are proceeding to post the ticket
prices and the theme we are super excited about. As you mentioned, the Bitcoin Cash city has a very
high level of adoption and the mission of Bitcoin Cash is to become money for the world. So,
essentially, every city needs to adopt Bitcoin Cash, not just our city. And the city is at one
level in the mission. You know, the nation, becoming legal tender of a nation is also part
of the mission. Every nation has to make Bitcoin Cash legal tender if it's going to be money for
the world. So, the conference theme is this one of legal tender. And Australia does have quite a nice
enviable history of getting things right. We are one of the first nations to decimalize our currency.
We did before the UK, for example. And we were one of the first nations, as a nation, we were
created through consensus where the six states got together and said, hey, let's do this. And we
became without a war, without any kind of civil unrest, we became a nation. So, there are these
kind of points in time where Australia has kind of got it right. And we should now with the advent of
sound money, you know, history, we've never as in the history of the earth had sound money,
something this good. And so, we can, you know, force, you know, move the government as
representatives of the people by adopting Bitcoin Cash. And we have now at our disposal sound money
for the first time. And so, we would like to proactively, just like we did with decimalization
or with metrication, it would make great sense for us to show some leadership again with the,
you know, adopting legal tender in Australia. And to show other nations that it's possible.
And just how good it is for that role. It would be extraordinary if a country like Australia were to
adopt Bitcoin Cash for legal tender. You know, I would... Absolutely. I think this would be massive.
So, you know, as you know, we've talked about this is something that I think would be a game changing.
So, I know that a lot of libertarian or anarchist people within the community are very skeptical
of legal tender, because it's the idea of asking permission. And I always challenge that because
it's not about asking permission. Anyone can use Bitcoin Cash, whether there is a legal framework
for it or not. That's not... It's permissionless, right? Nothing can stop that. But the point is,
is that for your, you know, law-abiding merchant that wants to accept Bitcoin Cash, so as you,
as a Bitcoin Cash user, you want more people to accept Bitcoin Cash. And many people want to be
able to stay within the realms of the law. They don't want to go to jail. They don't want to risk
tax avoidance. So, they want to be able to pay their taxes. And that's a real pain in the ass
to be quite blunt about it today, because you accept Bitcoin Cash. All right, the price is
continuously changing. Do you sell it now? Do you sell it later? But the point eventually when you
are paid is when it's going to be taxed on, which means that the price goes down, you might end up
owing more tax than it's even worth theoretically, if something was to go really wrong, right?
So, being able to pay taxes and be able to pay your VAT or whatever it's called in your own
countries, you know, the added, the value added tax on that good or service. If there's a legal
framework for you to be able to pay for that and send that money either automatically or easy
via transfer to the government or tax collection agency, this would make it much easier for
companies to be able to accept Bitcoin Cash. It makes their financing, their accounting
infinitely easier. And I'm a great believer that the only way that Bitcoin Cash, and it's the
only way that Bitcoin Cash will become a global used currency by the world is when there's no
friction. And tax is a friction that needs to overcome whether you're pro tax or against tax.
It's irrelevant. It's completely irrelevant because many people do need to and want to,
whether willingly or not, it doesn't matter. They need to pay that tax to be able to accept Bitcoin
Cash without a lot of friction. So, I think there's a really great movement what you're pushing for
now. And yeah, I'm looking forward to being able to hear if you get any, you know, the local
politicians or mayor involved in this from Townsville, because it's the kind of initiative that
can, you know, it takes a grain of an idea, but it can easily sprout into something really meaningful
to the benefit of Australia, if you would have managed to pull that one.
Certainly, our conference in 2019 was the first cryptocurrency conference ever to walk the talk.
And we did leverage, you know, our merchant, our local merchants that, you know, our high levels of
merchant adoption, so that delegates could experience the future of money while they were here.
We've got three and a half times those, that number of merchants today, and we're expecting
to increase that number by the time of the conference. So, it's, it'll be a unique experience
where people can experience that, the future of money. And this big mission is, like, it's mind
blowing that we have sound money. And you're making a great, you're making a great point about
the local merchants and industry, but what about balance of trade? What about international trade
being, you know, in a common currency, like the EU, you know, with the euro, but now at a global level,
and with a money which doesn't favour, you know, nobody can print it, so nobody can abuse it.
One of the advantages of fiat is that, you know, it can be printed, and that has certain
advantages to the host nation. But if we're going to share it, it's like everybody using the US
dollar, but only the US can print it. You know, that's not a level. Exactly, and this is the
important thing with, like, game theory, right? It has the advantage, it has advantage to the country
that's doing it, but all countries have this possibility, so then everyone loses. And it's
also, you know, so currently it's a way, so the US dollar, if you want to buy oil, if you want to
buy gold, it has to go for the US dollar. So the US has done this amazing monopoly on the global
currency, and so they can send the dollars around so that, you know, they can use their dollars to
buy goods, because at the end of the day, money is worthless. This is the important thing. It's
only what you can buy with the money that has value. So they send paper, this, you know,
useless thing for real goods. And the idea is it's a promise of, you know, you're buying a TV from
Japan or a car from China, and it's a promise that you're going to be able to get a dollar's worth
of goods from America at a certain point. Now, of course, that might be going, you know, the Chinese
might be buying it from Europe or whatever, but essentially, at the end of the day, that dollar
will have to be transferred for something from America. But in the case of America, the Fed can
print out more dollars, meaning the purchasing power of that dollar goes down, which is how they
actually manage to export debt around the world. And it's not just America that does this. It's just
they're the largest foreign money that's used as a global currency. But all countries play in this
game, and it's actually detrimental to everyone's wealth. So, yeah, even though it's an advantage
to that one country, in the end, it disadvantages everyone. So having something like Bitcoin cash
being used as the global currency will literally make everyone wealthy. That's a good pitch.
Yeah. And it's one of the things I like about emerging coding using Bitcoin cash. It's an
industrial use case. And it's leading the way, showing other companies that they can rely on
this payment technology, this community, this governance model. And it just needs somebody
to show them, right? So, yeah, look, I'm looking forward to reporting some outcomes of emerging
coding, hopefully at the conference. And, of course, its theme of legal tender, that is a huge,
a huge theme. That's where we've got to be, right? That's where every nation has to be.
It starts at your local corner shop, your city, and your nation. Every nation has to proceed. So
let's give it a go. And someone has to start. And someone has to push for that start. And that's
you. And I'm really happy to hear that. So, Noel, of course, I know you're a very busy man. You have
a conference this summer. You mentioned already there is another conference, BCH Bliss, which is
taking place in May in the EU in Slovenia, the capital city, which is Ljubljana. And what are
the chances that we'll be seeing you or any representative from Code Valley joining us?
Because just to sort of pitch it a little bit, you mentioned some key people in the industry.
You said you're a supporter of XT. You're a supporter of Bitcoin Unlimited. And I'm sure
you're well aware Peter Ryzen is going to be at BCH Bliss, one of the founders of Bitcoin Unlimited,
very, very smart guy. And he's going to be showcasing. He's actually on the panel. He'll
be giving a speech about his hardware that he's using for scaling UTXO, which I imagine is
something you would find incredibly interesting. So what are the chances? Is there any likelihood
of seeing you or someone from Code Valley joining us this May in Ljubljana?
Yes, certainly. We are discussing it right now. If it makes sense. If we've got reportable.
Of course it makes sense. What stupid question is that?
If we've got something to report, that would be good.
This is the most awesome thing for the Bitcoin Cash community. And we've got the general
protocols that there. We've got Peter Ryzen's there. And listen, if that doesn't set it, no,
no, I'm going. Right? Yeah, no, no. Yeah, just wanted to point out one more thing.
You know, as we're coming back to emerging coding in this components market, we've built
the market with the market, if you will. So we actually have very good coverage of Bitcoin
Cash style software. There are thousands of these components that are dedicated to supporting
Bitcoin Cash software, constructing Bitcoin Cash software. As you'd imagine, each agent must accept
payments and make payments to a supplier. So it has a wallet, has these payment channels,
these smart contracting, holy smokes. So I think, you know, from the community's perspective,
there is a lot to offer, not just as a vanguard for industry using Bitcoin Cash, but one of the
very few types of software we can actually create with emerging coding is actually Bitcoin Cash type
software. So there is this advantage that we are bringing to the community, not just in its use
in its use as a payment system or putting economic activity on the blockchain. But one of the very
few types of software we can create from the get go, we need component coverage to create any
kind of software. And one day there will be millions of components for sure. But from the get go,
because of our need to build a system with the system, we have had to support Bitcoin Cash
components. And so hats off to Aptisio, our tech partner who've created thousands of Bitcoin Cash
components. And I certainly would love to see them at the Bliss Conference. That would be
fantastic to have those guys there. Yeah, and it's exactly the conference for those guys.
You know, BCH Bliss is for everyone and everyone who's interested in Bitcoin Cash is
is heartily invited and will be very welcome there. But the primary purpose of Bliss is for
the builders. It's for people showcasing what they're working on, people's ideas, and looking
at where they're going to be focusing their energy on in the future, so that we can also improve the
network, the ecosystem, the user experience for everyone that's already in the ecosystem,
and also to attract more people into it. Because to reach our goal, there's still roughly 8 billion
people who need to be adopted to this amazing currency. But Noel, it'd be fantastic if you
would be able to join us at BCH Bliss. I don't know if you've been to Slovenia. I've only been
once and it was for the conference. I mean, I can genuinely say as someone that has spent a lot of
time in some of the nicest places in Europe, it's a really beautiful city. It's like Austria,
beautiful hills, forested, very clean. And you can also spend Bitcoin Cash in quite a wide range of
shops. I'm not sure how it compares to Townsville in its adoption. It's not Bitcoin Cash only. It's
ELEPAY. So they accept a range of cryptocurrencies and many of the point of sales, which I really
appreciate your stance since you accept all cryptocurrencies as long as it's Bitcoin Cash.
But it does mean you can spend Bitcoin Cash. You can actually pay for the hotel in Bitcoin Cash.
It's a Sheraton, so it's very nice. You can pay for the beer there, even the taxi to the airport,
which I think is a critical part. You can't have a Bitcoin Cash conference anywhere,
in my opinion, in good faith, unless you can pay for at least most of the way in Bitcoin Cash,
which is possible. So I'm sure if you were looking for a little holiday with your wife,
then Slovenia is a good place to come to and spend some time.
Sounds like a plan. Fantastic.
This up, so Emergent Coding. Noel, when have we got a public release?
We're in the process of bringing up what we call the G29s. This is the version that we want to
take to market. We do have another version with some more of the roadmap features in the works,
the G30s. So our plan is to bring up this market pretty much immediately, and it just stays up.
So that's going to be the early stage of the launch. We'll invite specific developers to give
it a go, and once we are confident of its scaling and so forth, we will release the Kraken. We'll
open it for a public launch sometime. It's looking pretty good for this year, but it's a very large
project. It's taken enormous amount of effort. Like John said, I can't give you any dates, but I
would love to have something very reportable for Bliss and something even more significant for the
Bitcoin Cache City Conference later this year.
Okay. So fingers crossed for a 2025 launch of Emergent Coding. It's been a long time in the
making. I think the first time we spoke was early 2022, which was when I was first equated to this
project. So it's very exciting to see this being released. Thank you so much for joining today,
Noel. That was really fantastic, really informative. I hope the audience also enjoyed it.
For all of your listeners, please make sure to follow Noel and Code Valley on Twitter,
at levissanol and codevalley42 respectively. For all of your listeners as well, if you enjoyed the
show and want to show your appreciation, please feel free to drop some BCH or a Fiendish token
into our wallet. Cash tokens address is in the description of the Twitter profile, and there's
also a QR code in the comments. You can also find links there to codevalley.com, which I advise
for all of you who found this interesting, go and check it out and you can follow the news there.
The next episode of Fiendish in France is in two weeks. So next week, unfortunately, the guests
who we had who's going to be coming back on, we've rearranged it, but couldn't make it for
next week due to moving. So the next episode will be in two weeks at four o'clock Central European
time, and it's featuring a Bitcoin Cache rockstar developer, Jason Drazener, who was behind the cash
tokens upgrade 2023 and also responsible for a lot of the work and the chips in the Velma upgrade
this May, which we'll be celebrating at Bliss 2025. And he's coming on to talk about his work
in the ecosystem, the chips that he's already created and is working on and what's next for
Bitcoin Cash. So just make sure to pop some Fiendish tokens into the jukebox, hit play
to convert tokenized Fiendish time into 60 minutes, 120 minutes, however many minutes it takes
of the best Bitcoin Cash news and podcasts. This was Fiendish in France. I wish you a good morning,
good day and good night. Take care everyone. Bye.