original text with precise timestamps- https://pastebin.com/raw/J3Pb5mL7
Original source youtube subtitles, cleaned up so more readable (apologies to participants if I have mangled your meaning in the process)
John Moriarty - TimeStamp:18
Hello and welcome to the June 1st 2021 Bitcoin Cash network discussions today's topic is PMv3 a new transaction format being proposed for Bitcoin Cash.
Presenting today is Jason Dreyzehner author of PMv3 his other open source work includes Cash channels Cash Tokens Bitauth and Libauth our other participants for today's discussions are Thomasom Zander founder of Flowey, Benjamin Scherrey of Biggest Fan Productions and produce technologies, Richard Brady Bitcoin and telecoms developer and consultant and Rosco Kalis software engineer at General Protocols and creator of travel suite and Cash Script.
these discussions follow a five section format for each section the presenter will open the discussion with an overview after which we'll open up the floor to the rest of our participants for questions and comments. participants are encouraged to direct their questions primarily to the presenter and to make sure comments encourage productive responses.
section topics are as follows one the proposal's problem statement and or use case two the properties of a good solution and or implementation three the proposal itself and how well it fulfils those requirements four the cost of the proposal to the BCH ecosystem and five the relevant stakeholders and any public support so Jason please go ahead with a description of the problem statement and or use case of PMv3 when you're ready
Jason Drezehner - TimeStamp:100
PMv3 is a version 3 transaction format we call it PMv3 just to differentiate it from any other possible transaction format proposals just for now but it is a version three transaction format proposal which would allow us to use the existing smart contracting features of Bitcoin Cash to do a lot of the things you can already do on on systems like Ethereum and other global state networks in summary so decentralized finance applications
John Moriarty - TimeStamp:141
Very good so could you tell us a little bit about (without getting too much into the weeds) what specific kinds of use cases are enabled by these decentralized finance. now some people are probably already familiar with it but if you can give us just a basic overview
Jason Drezehner - TimeStamp:158
Yeah so basically the Bitcoin Cash virtual machine. inside Bitcoin Cash the way that transactions work there's a programming language that lets you specify who can spend a certain sum of money and you can specify that in this virtual machine language and that language is actually very powerful already for Bitcoin Cash.
it's actually sort of just a packaging issue with how the transactions work that prevent us from allowing contracts to sort of reference each other in a safe and scalable way.
so what PMv3 does is allows you to add a hash of the contract, the script the unlocking byte code in a section of the transaction
John Moriarty - TimeStamp:214
I am going to interrupt you even there Jason sorry to interrupt so this is getting actually into the weeds of how the implementation is but could you maybe just talk a little bit so what are like the direct applications.
so I know you've talked a little bit about prediction markets yeah and so if you could talk maybe just a tiny bit about those and maybe also I believe Tokens are also something that this makes possible
Jason Drezehner - TimeStamp:233
Yes so this would allow us to build token applications things that you do ICO's for and stuff this allows us to build prediction markets and other information markets, synthetic assets things where we kind of binary contracts and other synthetic assets that represent real World assets on chain, decentralized exchanges.
really anything that's as far as we know anything that's being built on any other cryptocurrency platform should be possible in Bitcoin Cash with this.
John Moriarty - TimeStamp:269
Very good thank you so I'll open it up to everyone else now and I realized maybe there won't be too much to say about this but would anyone like to ask any questions specifically about those use cases and the value of the use cases and specifically the problem statement that we've covered so far.
Richard Brady - TimeStamp:290
Well I'll go so it's certainly quite a big claim and it's an exciting one and I think one of the reasons I've spent so much time trying to dig into PMv3 is just to establish whether you're actually right about that or not.
so it's also a bit of a paradigm shift in terms of the the way one thinks about what smart contracts would look like in PMv3 it's not sort of a replica of the Ethereum virtual machine for example so I am very excited about all these potential applications.
at the same time it's really hard to try and imagine what they would look like using PMv3 so so having concrete examples is great and Cash Tokens is brilliant in that way so I am looking forward to seeing some more detail on that
Jason Drezehner - TimeStamp:347
Thank you yeah and Richard's review has actually been really really helpful already there's been some we made some improvements to the spec from it and as Richard was saying the the change is quite a different paradigm actually than the global state network so Ethereum and several other cryptocurrencies their transactions can actually interfere with each other and that causes some scaling issues.
what is quite different about the Bitcoin Cash strategy in general is that transactions are atomic they don't interfere with each other, other than the double spending resolution and this contracting ability does not interfere with that scaling ability.
so in one in one sense we can build all the things that you would be able to build on a global state system so far as we know but the scaling advantages of that isolation are not given up.
so from a developer's perspective it is a little bit harder as a mental model to develop an application that scales like this because each contract holds its own state basically and that makes it quite a bit more mentally taxing to develop an application but the benefit of course is that it scales very well.
John Moriarty - TimeStamp:433
Thanks and so that gets a little bit into what the properties of a good solution and implementation are the scaling properties Ben did you have a comment about just the general use case or problem statement before we move on to that
Benjamin Scherrey - TimeStamp:447
I think it was covered already
John Moriarty - TimeStamp:452
Okay great thanks so that's at least one there is that oh I am sorry Rosco go ahead
Rosco Kalis - TimeStamp:457
I am not sure if this is already the right place but like you mentioned.
the mental model for the developer is quite a bit more difficult, what kind of people will be the ones that are going to be building on top of this.
if it's implemented, is it going to be like node developers or people like regular javascript developers what's kind of skill level where you have to be to to really build something on top of this.
Jason Drezehner - TimeStamp:495
It's a little hard to envision early on.
I imagine it's kind of a crowd that is not yet super visible but a lot of the people that are already building applications on networks like Ethereum, I imagine will want to take a look at a more scalable option for certain types of applications that already exist and it's a lot like when you're developing for a company in normal internet World it's much easier to build a monolithic application it's quite a bit more complicated to build one that scales very well, scales horizontally globally and stuff so you do sort of have an upper echelon of things that kind of rise to the top of really top quality engineering work that scale very well and that those are the kinds of things that are going to be deployable on Bitcoin Cash.
Benjamin Scherrey - TimeStamp:557
If I can add to that, that's actually my main issue or my main observation for our team as we've been trying to get into this PMv3 stuff because we are a development shop and to answer Rosco's questions, so for Ethereum for example they designed solidity to be based off of Javascript in order to make it easier for programmers to get in.
I think this was a huge huge huge mistake because it made a whole bunch of people who write applications like the next Facebook killer if you get some strange thing your Facebook killer application blows up you just reload the browser but instead what we're really seeing in these systems you've got three lines of code in the DAO and if this line was up here versus here the DAO would not have exploded.
it's going to require a different level of disciplined coder to do these kind of things and specifically with what's being introduced in PMv3 the complexity of the code the expressibility of what can be done on the Bitcoin Cash ecosystem is exploding.
if you're a Bitcoin Cash developer you're used to programming mostly in kind of like the assembly language of Bitcoin and it's very clear this kind of puts that out of the realm of being reasonable.
now I am thinking Jason's examples are in Cash Script right which is a language that compiles down into the assembly language of it, I am a language designer in fact the ActorForth Group that I run is to build a language that targets this kind of stuff so we're now going to have to use languages that are extremely safe very very type safe.
require and impose a correct by construction discipline rather than what's been allowed to to run on Ethereum and other blockchains and that's a huge shift and it's also going to make I believe these smart contracts on BCH far more reliable and resilient to those kind of attacks
John Moriarty - TimeStamp:680
Very good thanks, Jason if you don't have anything to add to that then let's move on to the properties of a good solution and your implementation.
I know you have some notes here on other solutions that are currently in the works for implementing similar types of things if not in a similar way could you maybe do a bit of a comparison on how the implementation of PMv3 compares and contrasts to those SmartBCH Solidity Mitra group Tokens all those things.
Jason Dreyzehner - TimeStamp:723
So there are a few different ways we do this, there are a few different ways we can get this expanded functionality one thing that I think is very cool about the strategy in PMv3 is the the existing virtual machine is actually already very powerful and it's sort of a happenstance of how transactions are packaged up that makes it not currently capable of looking backwards in the validation so we can validate the current transaction we can validate from the future forward but validating backwards is not possible just because of kind of a packaging issue.
so with PMv3 if we solve that issue we can get quite a bit of functionality surprisingly just by adding a hash and and then the existing virtual machine works quite well.
So the differences,
so SmartBCH is a BCH side chain which runs decentralized applications that are designed for Ethereum and for the Ethereum virtual machine SmartBCH alone requires a trusted peg between the side chain and the BCH main chain.
but with PMv3 that SmartBCH peg could actually be designed to rely on a more secure BCH contract rather than the trusted peg so I wouldn't say that they're alternatives they're very complementary.
but SmartBCH is really designed for existing applications that have already been designed for that Ethereum model kind of as Ben was mentioning.
so Solidity and Mitra are both virtual machine proposals for sort of wholesale replacing the existing underlying virtual machine in Bitcoin Cash or in the case of solidity that one was proposed almost six years ago. I think now and and development is sort of ongoing and that gives you a sense for why they're alternatives but a little bit further out they require a lot more research before we would want to swap something out like that.
whereas with PMv3 the existing virtual machine is a well-known quantity it's well understood and well tested so we're not very concerned with making it slightly more powerful.
in certain ways group Tokens is a hard-coded token proposal for Bitcoin Cash which would sort of add a token space to transactions it's a little more complex than that but it would allow us to do some of these more advanced contracts also so there are certain parts of it that are all an alternative to PMv3 but then of course things where you're having contracts that interoperate where you have a contract that reads another contract and such a lot of those still would require something like PMv3.
so in a sense a lot of what can be done with group can also be done in contracts alone with PMv3 but group could make some of them more efficient so that's nice something to that additional research is required there.
I should note there's one other kind of high level alternative we could consider which isn't really being proposed but if we had introspection opcodes that allowed a transaction to look into details about its parent transaction that would also solve what we are trying to solve with this PMv3 stuff.
however that would be quite a bit worse for scaling because it would basically increase the the size of what is currently held by nodes in the UTXO set.
it would increase that massively for probably not enough gain so that's not been proposed but as kind of an explanation for why we don't want to do that that would require quite a bit higher validation costs.
so as an alternative PMv3 we are able to simply add a hash to certain transactions and then those transactions pay their own cost.
they wouldn't increase the general validation cost of the network but instead they'd be 32 bytes more expensive themselves which properly incorporates the cost to the network of doing the hash
John Moriarty - TimeStamp:1007
Very good thank you and if I May summarize a little bit because I think you touched on each of these but you have written here that a solution should one utilize as much existing infrastructure as possible and so that might be the virtual machine minimizing the implementation cost.
of course we didn't talk too much about that but that's also from reusing infrastructure and then avoiding technical debt is there anything within those three that you think you haven't covered before I open things up to everyone else
Jason Dreyzehner - TimeStamp:1034
Yeah that summarizes it well
John Moriarty - TimeStamp:1037
Very good so would anyone else like to ask any questions about that or challenge any claims or discuss
Thomas Zander - TimeStamp:1047
So my goal here in this is functioning, is looking at how Bitcoin Cash as we have been using it for a while is affected by the changes.
if there's any negative consequences for scaling, if the complexity is being increased unreasonably
and other such things so I've been looking at that a lot of time, from a lot of different angles with Jason and we've dug in a minor few stupid details.
I think we're very happy about how it really extends the vision of the original Bitcoin in that it allows you to do more with the tools you already have so it's basically removing obstacles instead of adding features and that's in my view the best way of looking at it.
it's just making a small change that removes some obstacles that allows us to do more and from that point of view.
I think this is the most sane way to go for the coin and a lot of the alternatives are...
a new VM is just a massive undertaking and that kind of options just doesn't make sense to me so that's that's my point of view here
John Moriarty - TimeStamp:1143
Appreciate the comment does anyone have a response
Benjamin Scherrey - TimeStamp:1149
I'll just echo tom's statements.
I mean it's really impressive what Jason has been able to eke out of a non Turing complete computation engine.
that's just like wow from an engineering perspective.
I am looking at this, how does this thing work holy crap that really works that's pretty cool.
although I tell you our team is still getting our heads around it we still can't follow through all the examples but we're working on it.
John Moriarty - TimeStamp:1174
Very good so Jason now maybe it would be a good time to give a high level overview of of what the the actual changes are on at least a slightly technical level and then explain just a little bit of of how that works to enable the use cases you've described.
Jason Dreyzehner - TimeStamp:1195
Let's see can you all see my screen yes okay so I don't have a powerpoint this is actually from the blog post so this will be linked in the video probably but it's the PMv3 this is a thorough detailed walkthrough so if anybody's curious I recommend you take a look at it but I am just going to show a little graphic to get a good sense of what's going on.
so what PMv3 allows is a couple of additional fields in the transaction kind of the most important one is the detached proofs so we call them detached proofs.
so what's happening is the in a 'version one' or 'version two' transaction if you're trying to inspect some element of a parent input in that transaction what you do is in your your proof information you have to push the contents of the parent transaction and then pick it apart sort of to demonstrate what's going on
in the existing transaction format that becomes an issue because here's our current transaction you'll have to include the parent transaction but the parent transaction actually includes its grandparent transaction etc.
so if you if you're trying to inspect backwards every time you you step forward again your transaction gets that much bigger and it becomes completely unreasonable after even just a few transactions.
what we do in PMv3 is instead of having to include the grandparent transaction the grandparent transaction could optionally have chosen to use a detached proof and so instead of including its own proof information here it hashes all of that so you can see the red block is just a hash now and the hash of that is the contents of all this stuff but by hashing it now the parent transaction is actually a fixed size each time we step forward in this program looking backwards requires just a fixed 32 bytes instead of an exponentially growing amount of information.
so interestingly enough inside that hash is everything that was there before and inside of that there's something with a hash with everything that was there before so in a sense like the whole history is being compressed into this hash at each step but the part that's super wasteful is abridged.
we are sort of compressing each past proof in each new step so that is a high level summary of what's going on.
if you're curious more about the the details I encourage you to check out this blog post where I step through what is a contract and what's a covenant and some of the other details even get into some of the applications on chain token sales transferable synthetic assets decentralized exchanges and prediction markets and other information markets and I've written quite a bit more about those.
and then I compare a little bit with Ethereum which is kind of a global state paradigm where transactions can interfere with each other and that is the scaling issue.
so with Bitcoin Cash we've got a stateless network with stateful covenants so instead of it being a network scaling problem to build an application.
the developer building the application has to think about their scaling a little bit more.
so it shifts the burden from the network to the developer of the application but in exchange we get Bitcoin Cash's scalability there.
so is that any questions on that
John Moriarty - TimeStamp:1433
Well maybe what i'd like to do is if I may (Richard excuse me), well we've already done the sort of use cases in the first section could you maybe spend just a minute on each of those that you just glossed over.
and explain for any of us who don't know what really basically on chain token sales what does that mean what does transfer synthetic assets mean.
Jason Dreyzehner - TimeStamp:1458
So kind of the simplest one is on-chain token sales
we can we can build a covenant that sells its own Tokens that conducts its own ipo and we can even do interesting things like conduct continuous liquidity events like continuous buyouts which could be very cool.
transferable synthetic assets so when you can hedge in the Bitcoin Cash ecosystem with an adequate oracle which might be provided by a prediction market.
you can hedge pretty much anything in the World and you can replicate any kind of portfolio just in the Bitcoin Cash World using a mix of derivatives basically, it's not simple.
but what's cool is with PMv3 is we can make those synthetic assets transferable so the things that are already happening with Any Hedge and Detoken right now we can make those transferable from different end users so that they become a lot more like synthetic assets already existing in the real World right now
decentralized exchanges we can build exchanges that trade in those synthetic assets and we can build exchanges that trade in other Tokens that are built on the Bitcoin Cash ecosystem.
what's cool about that is that these markets could enable borderless global uncapped investment in any stock commodity currency or other asset, because by nature they are on the internet they are not in a single country or they are not in a single institution
prediction markets, these are betting on the the outcomes of events.
but more interestingly combinatorial prediction markets is what they're called is where you you bet on sort of a grid,
actually of PMv3 is implemented or not so you have like imagine on the x and y axis there are there's a box with four different boxes on one side is whether or not PMv3 happens and on the top is whether or not the price of Bitcoin Cash is over 10,000 in a year and people can bet on individually each of those boxes and by looking at the sum total percentages in each of them you get a good sense of actually how variable x affects variable y
so if it's implemented and the the price is over ten thousand is like ten percent higher chance we then can assume that the the market believes that PMv3 has a 10% Chance of increasing the price beyond 10,000 within a year
that's a very simple example but you can get much more complex you can have scalar values actually so it's not just yes or no values but you can have the market actually indicate to you exactly how much it thinks it will increase or decrease the price in that time frame and there might be other time frames that are also measured.
so information markets like prediction markets I think are one of the most important, probably will be one of the most important creations in the coming hundred years.
and they've not been very possible before we've had as much computing power as we have and also consensus technology as we currently have.
so there's sort of a a convergence right now where the technology and our our knowledge of the topic have gotten to a point where I think in the next 10 15 years I expect prediction markets will become a a much bigger part of our World
I've written a whole lot more about that actually
prediction markets on Bitcoin Cash oh gosh that's not there here we go it's right here that's funny I'll fix that link so this this is a much more detailed explanation of what's going on
also a bunch of the other things prediction markets could help with health and medicine scientific theory and discovery environmental protection management of public corporations marketing and consumer protection insurance and disaster prevention software security News media transparency empowering whistleblowers breaking propaganda and reducing violence
they have a lot of promise
I write even a little bit more about why I think Bitcoin Cash should be particularly interested in making sure prediction markets work on Bitcoin Cash
because if the dollar was was crowned as the World's reserve currency for its use and basically in global trade and oil
I think there's a good a good case to be made that its successor will be crowned for its use as a reserve asset in information markets and that is what we are competing over right now.
so I think Bitcoin Cash is particularly well suited for it between low network costs and good scalability
you can read more here but reasonably good privacy Bitcoin Cash is fairly good with that and then also deflationary I think is quite important for a well-functioning prediction market
so yes I encourage you to take a look at this blog post if you are curious about the prediction market stuff but that summarizes these use cases
John Moriarty - TimeStamp:1812
Great thank you so appreciate your going through that and Richard before we get to the comment that you had I would like at least open it up to anyone to comment specifically on those use cases does anyone have any thoughts on the applicability of those use cases or whether they're likely to be valuable or possible or anything like that
Richard Brady - TimeStamp:1831
I am interested to know from Jason what you think of other prediction markets not exploding that we've seen on for example Ethereum is that because of the transaction fees
Jason Dreyzehner - TimeStamp:1846
Probably I imagine prediction markets are going to take a while to to get big
I mean in the same sort of curve as internet usage and computer usage
really the places where prediction markets get really interesting is where they start to have an effect on sort of the social fabric of the World
right now people go to the News if they want to understand, if they want a summary of some current events and I think that in the next 20 years I would be very surprised actually if people didn't look to prediction markets actually for a much better understanding of where reality actually stands
where News can be quite biased
numbers and markets are not going to lie about their about actual probabilities so where the News can actually make a mountain out of molehill and vice versa they can totally cover something up that is highly important to society.
prediction markets I think will help to allow people who are not necessarily experts in something
if you're not an expert in quantum anything but if the News says again that we've got we finally got a quantum computer you can immediately fact check the News by checking - does the prediction markets actually resolve that this is the quantum computer that breaks all of traditional cryptography and you'll find no, yet again it's no
and the News is just trying to get you to watch again
but things like that are going to I think very fundamentally change where people consume their information and those things take time they take generations so in the next 10 or 15 years we might have a big growth in prediction markets
but a hundred years from now prediction markets are going to be I think one of the World's core information sources and they'll be very good at it
so a lot of things where uncertainty destroys a lot of value in the World today I think prediction markets can save a lot and that goes back to some of those examples I was just giving,
disaster prevention and stuff, there are a lot of disasters that could be averted if people knew what information to look at and prediction markets make that very sharp because they are a number there's no beating around the bush.
if an expert believes something that the World should know more about they can help to make a new market that surrounds that belief properly or highlight a current one and they can actually become fabulously wealthy if they know something that the World doesn't and they help the World to understand it
Rosco Kalis - TimeStamp:2034
So you mentioned the transaction fees and also the inherent difference in scalability between UTXO model and the account model are there any other technical reasons why you think the prediction markets and also the other use cases that you outlined will work better on Bitcoin Cash with PMv3 rather than something like Ethereum
John Moriarty - TimeStamp:2064
Actually I'll review real quick Jason would you mind unsharing your screen because that will give us the faces back there we go there we are
Jason Dreyzehner - TimeStamp:2072
I say specifically a good example actually of where kind of the limitations of Ethereum have sort of hindered the uptake of existing prediction markets several of the existing prediction markets have actually had to change several of their algorithms to make them reasonable on Ethereum.
Now side chains so roll-ups in Ethereum as running Ethereum and a side chain would allow some of that scalability stuff to come back so I wouldn't say that the that prediction markets are impossible on Ethereum though I gave the rather prediction markets are impossible to get really big like I was describing there with roll-ups the kind of this the sky is the limit there in some ways
however there's still a lot of work to be done and a lot of the existing prediction markets have spent a lot of their development work in the past few years making it work on the Ethereum base layer and in a lot of ways they're going to have to kind of undo the work that they've done there by they've simplified their market scoring rules a couple of them don't even really use a market scoring rule anymore they just use kind of a bidding system
and there are market scoring rules which we know are better for prediction markets which are simply not implementable on Ethereum unless you do it on a layer two and part of the reason some of these prediction markets have had so much trouble there is because they have been spinning their wheels on that implementation issue just that level of implementation.
just recently there have been times when it cost several hundred dollars in 2020 us dollars to create an account or so on these prediction markets and then if you have to pay fifty dollars a trade you are pricing out a lot of your potential market and therefore potential profits
and then you have your chicken and egg problem of why would experts bother to go and set up on this market if they're just going to share their knowledge but make five bucks on it and if they pay it all on transaction fees
so there's all sorts of stuff like that where I think the flywheel has not really been spun
but and in part just because there's a lot of of implementation issues that have to be worked through so in a lot of ways those implementation issues the road is now clear however they still have a long way to go.
so I think it's actually going to be very competitive probably for new prediction market efforts to begin on Bitcoin Cash they're not very far behind what exists already on Ethereum
Rosco Kalis - TimeStamp:2249
And do you think that those same principles translate to the other use cases as well or are they specific to prediction markets
Jason Dreyzehner - TimeStamp:2258
Yeah well in specifically in the case of decentralized transferable synthetic assets.
You can make a synthetic asset with any price feed the issue is how much you trust the price feed and if you look at how that market has developed the Ethereum World is not far past even the current BCH World just with Any Hedge and Detoken right now Any Hedge and Detoken the price feed is semi trusted at least and that is basically the state of the ecosystem also in Ethereum
so maybe the design is a little bit more advanced in some places. I mean the the visual UI design but under the covers they're practically equivalent right now so the primary difference between the current BCH World there and Ethereum is that those synthetic assets are transferable in Ethereum right now just due to this being able to validate backwards thing
but it's also not really much more developed the most advanced oracles so far as I am aware actually right now are basically multi-sig contracts like if four different companies lie and the oracle still falls through right so there has been a lot of work done in Ethereum but I would not say that Bitcoin Cash is far behind even if we're starting from scratch
John Moriarty - TimeStamp:2356
Very good well if there are no other comments then let's move on to the costs and risks involved in this upgrade now
let's see excuse me I am gonna bring up the page I was just looking at but if you could walk us through what implication does this have for various participants in the Bitcoin Cash network so users and then businesses and then consensus level software what is affected by this and what will the costs and requirements be
Jason Dreyzehner - TimeStamp:2396
So this is a consensus change so all full nodes will have to update it's table stakes then this is a little bit larger of a change for the ecosystem than for example like a new opcode
because with a new opcode all you need to do is have the nodes update and and most wallets and validating software most SPV wallets and indexers things like that can usually ignore them in this case the footprint of what is going to have to be updated is quite a bit larger
I would call it a moderate where all indexing software this is stuff like block book and bit core things that are the server side software that provide API's for end wallets that stuff will need to be updated and then SPV wallets so Electron Cash, Poket.
things that are themselves validating the actual state of the chain in some ways because they also are validating they're also parsing and validating transactions those pieces of software will also need to be updated so any software which parses transactions it will have to be updated interestingly enough most wallets that most users are using themselves don't parse transactions so I would call this a moderate change.
actually just to give you an equivalence it's very similar to the difficulty algorithm adjustment change, I guess that was last May I think the the footprint of software that will need to be updated is very similar to that
it as opposed the most breaking or most difficult ecosystem change would be I would call a high change would be if the wallet software and signing software itself needs to be updated
because of how you're changing the signatures and that's only happened once in Bitcoin Cash that was the fork change that was when we applied the bip 143 the signature stuff in 2017.
but this is quite a bit less breaking than that
but still quite a bit more than opcodes
so right in the middle of ecosystem difficulty pretty much all consensus validating software will need to be updated to support this version three transaction format
fortunately it's very similar to the current transaction format
so in a lot of cases it's probably just going to be like copy and paste and then copy this section twice more for the two additional fields that are at the end of these but it still requires an update.
fortunately it doesn't necessarily require an update for wallets themselves or especially for hardware wallets for the hardware devices themselves you know there will be no firmware update there it will be only the server side API that is pre-parsing the transaction before it comes down that stuff will need to be updated
also there is a review if anybody's curious there's a review in the Bitcoin Cash research forum where I went through and broke apart a lot of the existing wallets and yes so the Bitpay wallet, Bitcoin.com, Edge, Jax, Exodus a few of the others Trezor Ledger those should only require updates on the company's servers they shouldn't require the user to update their wallet because the company server parses the transaction and sends it down either as a json or as a grpc call so then the user's wallet just asks the server for it's UTXO'S and the signing doesn't change and version one and version two transactions will continue to be possible and interchangeable.
you'll be able to send money in a version three transaction and that wallet doesn't even have to understand the version three transaction they just have to know what the UTXO is and they get it from the server and they'll be able to send that money in a version one or version two transaction
so from the user's wallet perspective they probably won't have to know anything about it
it's just that the back end that supports those wallets will have to be updated to the latest node version obviously like they have to be updated after every every change but then also if they have any indexing software that's doing parsing separately from the full nodes that will also have to be updated
so it's not an easy change definitely not an easy change but it's not insurmountable
John Moriarty - TimeStamp:2692
Very good thanks does anyone have any comments on that generally or whether they think the the trade-offs are worth it Ben go ahead
Benjamin Scherrey - TimeStamp:2703
So a little bit of clarification and also curious what Jason thinks about this
what the scope of what Jason is talking about is these are the changes that are necessary for the ecosystem in order to stay on the chain and still operate right for doing what you're doing today
but I don't believe that is sufficient for as far as changes for being able to participate and do all the cool things that PMv3 is going to do
like if I want to participate in this prediction market, my wallets are going to have to be really advanced
what have you thought as far as how this is going to evolve and like right now few wallets can even support the simple complexity of the SLP Tokens and now what you're talking about is like wow
Jason Dreyzehner - TimeStamp:2758
Yes thank you for bringing that up
so in order to use this stuff wallets would have to will have to be updated to to use it and it's actually hard to even thoroughly envision what the whole ecosystem will look like because we're talking about quite a paradigm shift in what's possible
so I've spent several months now trying to figure out what that might look like, actually some couple years now in order for wallets to participate in this stuff they will also need to be updated in a lot of ways those are the places where the Ethereum ecosystem is quite well developed already and where we've got some catching up to do
a lot of our existing libraries have basically fixed transaction construction methods that are hard coding exactly what the contract should look like and that's still fairly common across the cryptocurrency ecosystem so I imagine we're going to get kind of the first wave of wallets that have generalized transaction construction support that exists now in the Libauth library that I am working on
so there are some examples there and Cash Script Rosco's stuff also gives you gives you that ability so we are getting there but there is definitely a lot of work to get wallets where wallets can support adding a new authentication scheme
basically and even if the developers of the wallet aren't terribly familiar with how various on-chain applications work you want users to be able to import an authentication scheme that they trust and want to use and and be able to communicate with separate networks there
and there's a lot of these networks are going to be sort of separate peer-to-peer networks that are are one-to-one pegged with BCH where they they happen on a side chain where they scale independently but then their value transfers settle back to the Bitcoin Cash chain that'll probably be the most common way that the really big stuff the fanciest prediction market stuff will probably happen
there's gonna be a lot of development to do for wallets to provide those API's and things provide those nice user interfaces for synthetic assets and prediction markets and stuff there's a huge field of new development and UI work to do there but at least in the immediate near term the changes aren't immediately required of the wallets themselves it's just that those wallets want to provide those new features to users
Benjamin Scherrey - TimeStamp:2936
Do you envision something there oh sorry go ahead Tom
Thomas Zander - TimeStamp:2940
Oh thank you I just wanted to jump in and say that the whole idea of a wallet as we've been using it in Bitcoin for a couple years is extremely limited we just look at it as money and and that makes total sense because we still have a floppy disk for saving as an icon people understand it
but when we consider the fact that the only front end for the entire Bitcoin Cash concept is what we now call a wallet then we have to realize it's gonna have to do a lot more than just being a wallet you're gonna have to have an entire payment solution you're gonna have to have all of these items in there and it probably is going to be several years of development and not just the new features that we have there because just adding new features means that only developers can use them
because it's going to be the user interface that is going to be the hard part to make it's going to be the interesting part where we turn it into a product and the product is going to be ready for end users and that's going to be something that we're going to see happening in the next couple years and I think that is going to be the actual test of when we break through when when Bitcoin Cash can be seen as serious because that's gonna be when we start seeing a lot of people seeing the value outside of just the developers and the experts
Jason Dreyzehner - TimeStamp:3042
Yeah definitely
there's a lot of development to be done there but and and it's one question that I have I don't know if wallets will be sort of an all-inclusive kind of a new category of applications that's kind of the way the wallet ecosystem has developed so far in Ethereum and elsewhere is that the wallet is this kind of category of application but it's also possible that we'll continue seeing the current crop of wallets continue being kind of just a money thing just sending and receiving money
and that we get a new crop of applications that are your decentralized brokerage thing so it's like your brokerage app right now a lot of people use a different app for their banking stuff different from their stock brokerages and there might be a wallet that is focused on those transferable synthetic assets there might be an app that's focused just on prediction markets
and then there will probably be wallets that have plug-in systems that let you install the prediction market app that is developed by somebody else to work in the plugin
I'll be curious to see how that part of the ecosystem actually develops if they will be separate apps kind of like the World currently works or if these wallets will build plug-in systems and try to extend that way and I don't know we'll see
Benjamin Scherrey - TimeStamp:3137
I think to make such a thing like that possible we're going to go through the similar kind of evolution that the Ethereum did with their ERC
they got their ERC20 for fungible Tokens standard right how do you call it and interact with these you got 721 from non-fungible 1155 so you can combine them all together and make them discoverable
we're gonna have to do something like that and which is also kind of interesting because there's been some scuttlebutt on some of the BCH chat about some developers are kind of frustrated that BCH isn't moving fast enough and how am I going to innovate and get a first mover advantage on Bitcoin Cash because it's so slow to adopt
and it's like when this thing goes live brother good luck
Jason Dreyzehner - TimeStamp:3185
That brings up a good point so what really is happening
we're getting this detail about the transaction format sort of out of the way
so that developers right now in order to make something happen on Bitcoin Cash you need a proposal that will happen during one of these scheduled upgrades right now it's a yearly cycle.
once this is out most developers will not need to have a network proposal to have a new token standard, they'll just design it in the contract language that is already supported in Bitcoin Cash
so in a lot of ways this brings a lot of network level protocol development work
it makes it part of what is possible to do in user space sort of on the system in the user land what software developer can write and deploy today
so our speed of development hopefully will be quite a bit faster
and it will be driven more on the wallet side definitely than it is currently where it's driven on the what we can add to nodes and get everybody to agree on and deploy at the same time and all of that stuff so that's a good example
John Moriarty - Question from mrtest001 - TimeStamp:3272
I've got a a couple questions from the youtube chat that I think are relevant to this section so from mrtest001
He's asking are there any projects that PMv3 will make obsolete and maybe they mean within the Bitcoin Cash ecosystem but also maybe not sure
Jason Dreyzehner - TimeStamp:3285
I wouldn't drive a stake in anything right now
no I don't think so but almost everything I can see some upside outside of the PMv3 so SmartBCH allows us to run Ethereum stuff on a side chain of Bitcoin Cash that's a perfectly viable decentralized application of its own it's likely to use PMv3 here in the next few years I am sure just to be able to have a less trusted peg
there's other proposals other VM proposals are certainly good to continue working on academically there might be much better ways of doing this than Satoshi designed in the first version we're just kind of extending the thing that Satoshi already designed to work for this other stuff
group Tokens there are a few use cases where you could cut quite a few bytes from certain types of transactions if we did some sort of hard-coded solution like that so that's viable for more research and then there are lots of opcode things that are still useful even with this.
this will allow us to build pretty much anything we want
the limit is our ability as engineers to figure out how to make it happen but at least we've kind of closed the loop.
There are certain areas of development that are currently not possible at all and clearly not possible
but with this it's going to be a lot harder to to say that like, yeah that's not possible on Bitcoin Cash,
it's much more likely that no I haven't figured out how to do that on Bitcoin Cash yet is this the answer
and for anything that I've thought about for long enough I've not yet found something that I can't figure out how to do on Bitcoin Cash because it is quite powerful already so it's kind of just a matter of us getting to that development, so I wouldn't say there's any proposals that I know of that this kills / totally deprecates
John Moriarty - TimeStamp:3422
Sorry give me one second to find the next question here
Richard Brady - TimeStamp:3425
Well I'll jump in can I just add something
John Moriarty - TimeStamp:3426
Sure go ahead absolutely
Richard Brady - TimeStamp:3429
I think to the contrary there are projects I am not sure about proposals but I am sure proposition but there are a lot of projects that PMv3 will supercharge
Any Hedge comes to mind and SLP comes to mind so for example on SLP an upgrade to the SLP protocol could allow Miner enforced Tokens so I don't think SLP will become obsolete
I think SLP will evolve to leverage PMv3 and then be one of the token standards or implementations out there and that's really exciting for SLP for example so I see it as a supercharging technology rather than something that's going to obsolete other projects
Jason Dreyzehner - TimeStamp:3474
Totally thanks for the perspective and making SLP work on those decentralized exchanges for example SLP needs to be contract validatable if you want the decentralized exchange to be able to confirm that you're selling an SLP token so things like that I definitely imagine that SLP will evolve and we can find ways of migrating in a backwards compatible way sort of there's some clever ideas of like dual validating where we can have kind of an intermediate version which works with existing SLP wallets but also starts to work on the contract validatable side as well
so yeah there's lots of a lot of the existing stuff we can definitely retrofit and and upgrade to make work work better with these decentralized things
John Moriarty - Question from Emergent_Reasons - TimeStamp:3528
so from Emergent_Reasons given a shared state like a prediction market atomicity won't be a problem because of the fundamental BCH UTXO design but will there be competition for redemption of some UTXO'S
Jason Dreyzehner - TimeStamp:3542
That's a great question and yes if you design your application such that it's vulnerable to that issue
it is definitely possible to design your application where it is not
so in some cases you'll be able to sort of shard the application itself across multiple UTXO'S if you think about how the Cash Tokens demos works and you can check that out on my blog and there's a post about it
and also if you click through the Cash Token demo it includes a lot of comments so it is inline commented all the way includes a lot of kind of high level summary and then also just the details on why we need exactly this validation here
but the Cash token demo is an example of that, the Cash token demo lets you mint a new token a new Cash token which is just I've made up a token standard and I just designed it in script and I could deploy it today if PMv3 is already on chain it's actually an example of like a token system you can design with PMv3
that I didn't have to go and get support for and and get the entire network to upgrade at the same time
much more possible to get big changes and and fast innovation that way
but the Cash token demo allows you to mint a new token and then send that UTXO to someone and they can send it around and they can actually send it, it can be sent to a multi-sig wallet and sent back to another one whatever and eventually you can bring it back to the contract and you can redeem it with the contract to get your money back
so you can deposit some money get the token move it around and then redeposit the token and get your money back out and that's not a terribly useful application but it demonstrates all the primitives you need for really important things like depositing money to a prediction market then doing the prediction market stuff and getting and withdrawing your earnings or whatever
but the Cash token demo is a good example of that sharding capability because the the top-level covenant has information about all the Tokens and we mint Tokens and then people can actually move those UTXO'S around independently of the top level covenant and eventually they turn them back in and each of those have their own history and their own competition over the UTXO for that piece
but only when you turn it back in is their competition over the top level UTXO so that's where this makes it a little more complicated for developers to figure out like how the scaling actually works
but it's a problem that the developers have to figure out rather than a scaling problem for the network itself
we picked to the side of the trade-off where the network stays stable and instead developers have to work a little harder
John Moriarty - TimeStamp:3710
Could you elaborate on just what actually we mean by competition for redemption of the UTXO's
Jason Dreyzehner - TimeStamp:3717
So in this case if there's a covenant there's a public contract somewhere where there's a pot of money on the chain which is the prediction market fund and you can send money to that address and you get that money in the prediction market
you can deposit money and then you can withdraw and there's a withdrawal strategy I've described in the blog post too where you have a quarterly withdrawal set up where the shareholders so to speak of the prediction market validate these withdrawals.
but the the issue the UTXO contention issue we're talking about is there's that pot of money that exists on the network and there might be multiple people in the World at any moment in time who want to do something with that UTXO they want to like execute that mint contract or they want to redeem so in the case of the Cash Tokens demo there's contention over if I want to mint at the same time as somebody wants to redeem both of us might send a transaction.
In Bitcoin Cash whoever sends the transaction first is what will propagate across the network and then in the case of the Cash token demo that's a good example of where the contention isn't actually an issue because I'll mint my token and if you deposited a couple seconds before I wanted a mint I'll just build on top of your unconfirmed transaction because it doesn't affect either of us so that's an example of a contract where the contention isn't a problem.
The contention isn't something where we're gonna try to go get a Miner to undo his transaction so I can put mine in first and that's a contract design thing you want to design your contracts to where contention doesn't benefit any of the players in the current block
and it's actually not too difficult to design a contract where all of the contention in this block applies in the next block
so that as long as everybody gets their transaction in now before the next block we all get the same price and you can design your contract to work that way
in the case of prediction market, I think in the case of a lot of more complicated stuff things like decentralized exchanges and prediction markets I think what's ultimately going to happen is the virtual machine language is not a great language to design very fancy stuff and neither is the Ethereum virtual machine like you don't want to write your code for a lot of stuff in these blockchain consensus algorithm virtual machines you want to just write it in like Rust or C++ or whatever and you run it as a separate peer-to-peer network
and then you create the peg where you can deposit and withdraw from that network. you create that in the virtual machine language and that's a much more easy to review it's a much more tractable problem it's much easier to do it that way and your your development can be a lot faster.
and then of course you still have to figure out contention on your network but a lot of those issues, they're the same ones we've seen in Ethereum and elsewhere also but yes I think a lot of that is tractable but it is a very good question because it's something the developers have to think about you can't get around thinking about it
John Moriarty - Question from Imaginary Username - TimeStamp:3915
here's one from Imaginary_Username have you evaluated DOS or some denial of service possibilities of transactions consuming disproportionately high amounts of resources compared to their size I assume he means computational resources
Jason Dreyzehner - TimeStamp:3930
Yes and actually the best place to look for a summary on that is actually the virtual machine limits chip which is totally unrelated to this but I just released it like like a couple weeks ago or something.
I dug into that very deeply and confirmed that just to summarize the primary concern for resource usage is signature validation and hashing
practically everything else is not even a rounding error
it's actually sort of funny the operation limit and stuff doesn't really make any sense in the Bitcoin system it's clearly something that Satoshi thought about a little bit but I am sure that if he spent more time on it that is one part of the system that would be a lot more polished
the operation limit is basically useless outside of signatures and hashes so we can calculate exactly the most expensive transaction that's currently possible to broadcast on the network and that's actually in the chip it's marked under the benchmarks and if anybody has a way of optimizing that to make it more expensive please let me know I've tried to optimize it.
so I've tried to demonstrate exactly as expensive as we can make it and the the Cliff Note is that it's just not expensive anyways like it it looks these days especially computers continue to get faster so the average 2015 cpu could validate a full block 32 megabyte actually, I think 128 megabyte block of those transactions can validate in like five seconds or something and of course when we've got ten minutes to do it as if they're coming in over the time
these days just the difference between an average 2015 cpu and a 2018 cpu is now six times faster so like we're talking about by the time PMv3 happens that worst case block will be even faster to validate it's going to be sub second
what it means is that in reality what's actually limiting us is the storage space basically on the network and right now the cost of storage with the fee of one Satoshi per Byte is approximately one BCH per hundred megabytes of block space
and in an attack which tries to exhaust resources in hashing or signature validation is almost like if you were running a node you probably wouldn't even notice the attack happening it would just look like somebody is paying to fill the blocks which is possible with OP_Return
Thomas Zander - TimeStamp:4088
I can confirm the attack vector as well it's essentially the only thing that really matters when you're validating a lot of transactions is disk io
because the waiting for the data coming from disk is a million times more than the actual cpu doing the work,
we got to the point where parallel validation is relevant
parallel disks and all that kind of stuff that is much more relevant and what you said it's really not that big a deal
John Moriarty - TimeStamp:4132
Okay and then one clarification so really we did touch on this but can we just clarify so which things have to be updated in order for this transaction format to work on the network
and then which other things don't have to be updated to keep functioning but do have to be updated to use the features could you just give us a quick overview of that again
Jason Dreyzehner - TimeStamp:4159
Yeah all nodes will have to be updated and then kind of the Cliff Notes wave anything that parses transactions on the network will have to be updated usually that's going to be the back end indexer that supports a lot of wallets so blockbook and bitcore and then a few I am sure there are plenty of proprietary ones that are asking nodes for information and then sending that information down to wallets that stuff needs to be updated
what doesn't need to be updated is wallet signing code and usually wallets if the wallets are asking for UTXO'S in a pre-parsed way
so I imagine probably electrums servers it'll depend on specifically fulcrum servers and stuff it'll depend specifically on the piece of software but a good way to check is does this piece of software parse transactions, if it ever parses transactions and if it does typically it'll need to be updated
unless you test it and it doesn't break when it gets a version 3 transaction as long as it doesn't break then it's fine
but most software you're going to want to double check, we're going to need to carefully look at a lot of that stuff
but the hardware signing devices or wallets that are on offline devices offline computers and stuff those things do not need to be updated
that was the biggest hassle of 2017 and still a hassle for a lot of systems that are not even updated yet being able to sign for BCH transactions in an offline signing system that has been around since 2013
things like that we do not need to update
but the the fast way to know is does my piece of software parse network transactions and will it break if it gets one that is not valid that is not valid in the version one version two format
Richard Brady - TimeStamp:4269
Can I add to that, so and the reason why it's only software that parses transactions is that
all PMv3 does is rearrange the contents of a transaction, it just moves some things from the middle to the end and that's pretty much it.
it's like a syntax change with no semantics change. it doesn't really change anything beyond this and that's why it's called the transaction format just the format
so if you're reading raw transactions then you need to to upgrade your software
but every transaction in PMv3 still has inputs outputs the same semantics and that's what's so brilliant about PMv3 is that it's literally just a rearranging of fields in this format
and then it enables things like inductive proofs
inductive proofs are not a sort of first class component of PMv3 they are something that you can do in user land if your transactions are arranged in this way
and so I think that's what makes it such a clever hack is that it's really just moving a few things about and then all of this extra stuff becomes possible in user land
John Moriarty - Question from imaginary username - TimeStamp:4356
Are you muted john thanks very much sorry about that so from Imaginary_Username again if an indexing backend does not plan to support version three transactions, can they not upgrade?
Jason Dreyzehner - TimeStamp:4372
I think the the short answer is yes they will have to upgrade in order to stay on the network so if they don't upgrade then they will cease to be serving the network at all because the network will move on without them.
fortunately as far as I know they're all open source so it's just a matter of, the same issue of every time we have an upgrade, exchanges need to upgrade their node software and wallet back ends need to upgrade their node software and in some ways it's basically the same issue, everybody's gonna have to upgrade their back-end node software we can send pull requests to any open source indexing servers and stuff and those are gonna be fairly simple because I mean we're really just moving around some fields we're using an existing hashing algorithm that's already being used in the transaction
like in general things are very very similar but yes it wil
anyone who is who is running some back-end system that is supposed to be in consensus with the BCH network exchanges, wallets back ends and things like that, businesses that are running their own servers and they will still they will have to update for the for the May upgrade but it's something that most of them will just do exactly what they did a couple weeks ago on May 15th they'll upgrade to the next version and they'll be done
so we'll have to get some of those indexing servers. it's more complicated because the software that uses the nodes in a lot of cases will also have to be updated simply because it's not been designed to be able to upgrade the version format in the future like that's not something they were thinking about when they were building the indexer but by and large it is a simple patch for practically anything just because we're not changing much at all
John Moriarty - TimeStamp:4489
Okay and it looks like there might be some confusion as to what the intent of the question was but we wanted to clarify that it's specifically about indexers that want to ignore version three is that a possibility And if you're not sure what that means I am sure we can cover it another time
Jason Dreyzehner - TimeStamp:4512
Yeah maybe maybe I am probably not understanding the question but in general there's there's not really okay you could you could choose not to in the index or you could choose not to also index the new detached proof field but in this funny way actually there's only one field you'll index separately and then detached proofs is actually a boolean switch it's either on or off and that's kind of the only new piece of information is there except for that detached so there are a couple changes but maybe simpler than I expect you're thinking to update it
Richard Brady - TimeStamp:4554
Are there indexes that don't actually pass raw transactions that would sort of bolt on to a full node and actually receive the transaction data in a in a non-raw form I am thinking of BCHD's grpc interface
Jason Dreyzehner - TimeStamp:4572
There definitely are
I think the ones that are though are asking over the rpc interfaces generally so they're either asking for a raw format or they're asking over the rpc interfaces and in the rpc interface case as long as the node is updated so it doesn't break that API, indexers could just ignore the new fields obviously exactly yeah so sorry I that's where you're right that's where I was thinking differently
the indexers I am thinking about parse raw transactions and that's why you wouldn't be able to ignore it
but indexers that are just reading from the rpc they can just they could definitely ignore it yeah that's correct
John Moriarty - TimeStamp:4615
Very good so we are probably getting close to where we should finish this up so let's talk a little bit about stakeholders has already been covered in decent amount by who needs to change and who needs to update
but could you tell us a little bit about any efforts you've made so far reaching out to stakeholders or if you've received any public support or if you have any if you've not what your plans are to reach out to those stakeholders
Jason Dreyzehner - TimeStamp:4644
Yeah so we're still we're still kind of solidifying, we want to make sure the spec is really really right before we try to get people that commit to things we've gotten a few there is definitely a lot of those stakeholders are are excited about it but we're gonna leave it at there are no public commitments yet because there's no reason for us to start drawing battle lines.
there are a couple details actually that the the reviewers on this call have have helped to identify that we want to improve but I imagine hopefully in the next month or so we should have everything really settled and then that includes a lot of the kind of end use cases.
in some ways there's a lot to think about because we're thinking about not just what the spec itself looks like but then what we can do downstream with it and we've spent a lot of time now in the past six months actually thinking about what we can do downstream with it and making the software libraries work with this stuff and on all that stuff and so we're just making sure that all of those learnings have made their way into the spec and that's just taking a little more development and review work.
but yes I think that hopefully in the next month or so we should have we should be in a place where we're ready for people to sign on and provide endorsements and things
John Moriarty - Question from Eleanor Blanc - TimeStamp:4742
Very good and and maybe one good question sort of leave this off from Eleanor Blanc she's asking, she hears a lot of support for this new transaction format
has there been any contention that you've seen any dissident voices or people that have just not wanted it or maybe even hypothetically who might not want this someone who would not benefit specifically
Jason Dreyzehner - TimeStamp:4768
Well it's quite nice that it's just a format change in that all of the contentions so far there's been a little bit of contention over like the the details of how I proposed the original version specifically some of the number formatting stuff in order to make this stuff work we need to make numbers work in the virtual machine and but all that contention is represented on this call pretty much as far as anybody who's who's come to me and talked about it
and that's the part actually we're still figuring out that it's really like some details that aren't going to be terribly important to most the people listening on this call but we want to get really right so we want to make sure we like how we encode numbers or how we choose to solve the number and coding and compatibility that PMv3 tries to solve
so yeah it's sort of funny the only contention so far that I know of is actually specifically number formatting I imagine we're actually going to just separate out PMv3 from the number formatting part of the proposal and we will discuss that separately but those are it's application details.
it's not the high level we should allow a hash of unlocking byte code so that's good it's quite nice that it's as far as I know non-contentious
John Moriarty - TimeStamp:4861
Very good well thank you very much for taking the time to present for this network discussion thanks of course everyone else for participating and to everyone who's watching both live and then later on youtube make sure to keep up with the Bitcoin Cash network discussions by subscribing to our youtube channel follow us on twitter if you have a topic that you think should be discussed the place to go is BitcoinCashresearch.org and thanks to them for the work they do running that platform and finally thanks to all the folks behind the scenes who make these network discussions possible there's a lot of people doing a lot of work that we don't see so thanks to all of them and then once again thank you guys for coming thank you very much a lot thank you
@blockparty-sh, thank for the tip, it will be paid forward