EB117 – Eric Lombrozo: Upgrading Bitcoin With Segregated Witness

Transcript

this episode of epicenter bitcoin is brought you by ledger now accepting pre-orders for the all-new ledger blue developer edition a Bluetooth and NFC touchscreen hardware signing device learn more about the ledger blue at ledger wall calm and use the discount code epicenter to get ten percent off your first order hi welcome to epicenter Bitcoin the show which talks about the technologies projects and people driving decentralization and the global cryptocurrency revolution my name is Sebastian future and my name is Brian Fabian crane we're here today with Eric that lombroso he's the founder and CEO of Cyprus and it's kind of a long long time long-standing epic on user become developer and also become

entrepreneurial the convo developer and we have mon today to talk about segregated witness now recently i was listening to a whole bunch of bitcoin podcast and I also listened to learn a bit about segregated witness and I was like oh I'm a little bit out of the loop with Bitcoin which I felt was a bit embarrassing but also this is really exciting super exciting development and project I'm glad we have a chance today to dive into segregated witness with Eric who is also running incidentally the segregated witness at test Network so thanks so much for coming on today Eric thank you thank you very much so to get started it can you tell us a bit

about how you got into Bitcoin and was your involvement the spaces looked like yeah so my guess it was around 2011 um I was at a party and some friends started telling me about Bitcoin and had some ideas for some games and I started you know tinkering with it and I pretty much got hooked on it right away and then that's basically what I've been doing ever since so I started building uh you know some some apps first and then I realized that there were some you know things that I would like to have as far as libraries or other kinds of tools and I started building that and and from that came cypher x I don't know what kind of party to go to her people are talking about Bitcoin but

that was definitely a good it could try to be at and that says so how long is the have you been well how long ago have you found at the ciphers suckers sighs Rick Scott started I mean it was based on work that I've been doing since since I first got into Bitcoin but the company itself was created in 2014 and we incorporated last year and so we can talk a little bit more about psychics later now besides I fix have you also been contributed to a fake bake encore right and done a variety of work so how did he end up getting involved with the segregated witness work well I mean I've been working with Peter really quite a

bit he he was one of the first people that I really worked with on on you know when I first started contributing a Bitcoin core and he he'd been working on on this you know segregated witness idea for for the you know sidechain stuff that he'd been doing with with block stream and that was with um you know the the elements alpha project but it turned out that it was possible to deploy this on the Bitcoin main net with with a with a nice trick that was discovered not too long ago this this was a figure it out you know just a few months ago and I you know started talking to him more about how we could actually deploy this and you know whether it was actually practical to do so and it really started

to look very promising so after you know there was the the Hong Kong scaling Bitcoin conference where this you know I deal was kind of you know presented for the first time completely and you know he already been working out some code and I started grabbing the code and running it and figuring out how how we could start um you know building this test nests we could deploy quickly and we could start building apps and I quickly started working on on you know my own my own applications i have my wallet I'm cigna and I started trying to just you know play around with that and hook it up to that and and yeah so so so here we are and so when in Hong Kong how was it received this this

proposal hey I mean it seems like everyone liked it I mean it was it was definitely a hit it seems like there's there's very few people that think there's any kind of downside to it really I mean it is just kind of like the best of all worlds it's all so many problems that we've been trying to fix with the protocol it really enables a lot of a lot of things that that were really difficult to do before if not impossible and it gives us a whole new mechanism for being able to really upgrade the protocol and deploy new stuff um you know it this whole extensibility framework which is really exciting because because you know it's really hard to change consensus rules and this gives us an opportunity to really be able to you know set up the the to set up the system so that we can

actually deploy things in the future in a way that's much more much more systematic so if that in mind what is the second grader witness proposal so transactions have basically two components one part is the part that actually removes the coins so it says you know coins that are in this part of the block chain are not going to be in this part of the block chain right here and then there's the other part which authorizes a transaction this contains the script and the signatures the script and the signatures are only used to validate the transaction to make sure that the transaction is actually valid it's properly signed once the coins have moved all the programs really care about is where the coins are and how much point how many coins are there so by separating this out it allows us to

optimize a lot of things about the you know the consensus layer and the protocol is so so that we can do much more sophisticated kind of scripting we can do much more intricate you know chaining of transactions it solves the malleability issue we could do much better you know validation cost metric kind of stuff where it gives us much more freedom to extend the structure and it allows us to do a lot of these stuff that was soft Forks so this is a really great thing because before it was thought that a lot of these things that would require basically an incompatible change to the software we're now we can actually deploy these things in a fully a backwards compatible way so do understand that correctly right so let's say you look at tranzact

that happened you know a a year ago something like that so you see in the blockchain you know it went from these inputs to those outputs and you also see in the blockchain you know the signature but of course you could say that well it's actually enough to just see that you know the inputs and outputs back then because a minor validated it back then and so everybody has built on that so you know we be trust all all the history hence we actually don't need that signature from back then anymore right so that's one thing we can do is though you know we can we can do a lot of pruning so ancient history can be pruned up thing no there's a certain

reduction of security but but it's you know if you go back a year it's going to be really really difficult for someone to you know to reorg the the block chain that far so you could pretty much safely throw away a lot of this stuff but it's really old I'm also you might only be interested for you know for some transactions to store this data so you could do selective pruning so there's a lot of it you know interesting optimizations you can do with that yes so what are some of the cases where you would want to save that data rather than discard it after certain period of time or effort that's been validated by miners well if you want to be able to fully validate the blockchain you're going to have to have this data so someone on the network is going to want

to store this data just so that you can do full validation if you don't want to have to do checkpointing so so there is an incentive to keep this around for for a long time but you don't actually need this data to be able to construct transactions to spend the outputs from these other transactions so it doesn't affect any of the future logic once the transactions in the blockchain it's you know it's confirmed basically this data is no longer needed unless you wanted to to validate for yourself so there's been a lot of work i think on on pruning the blockchain already why is this different and why's this interesting well to be honest the pruning part of it is

interesting but that's that's actually not the coolest feature of this there's a lot of other stuff that we can do with this that's that's much more interesting is just a something that it's nice to have it's nice to know that we can throw this data way but but but I'd rather get more into to the other features which I think are what more people are really excited about what's argued a witness well please go ahead tell us what those features are so the first feature that you know that one of the main motivations for it was was fixing the malleability issue right so transaction value ability is caused by the fact that the transaction ID the the you know the TX ID is a hash of the transaction and the way that the system was originally designed the hash included the signatures which means that

if you change the signature it would change the transaction ID and the way that the signature system works you can have different signatures that sign the same transaction seems different signatures could be valid for the same transaction so this makes it simple for someone to be able to maleate the transaction and change the transaction ID without actually changing the inputs and outputs so the transaction does the exact same thing but it has a different ID and and this is a serious problem especially if we want to go into off chain protocols where we want to be able to change transactions right now if you want if you want to change transactions you have to wait for one transaction to be signed before you can create the next transaction that spends that one because until you know the actual transaction ID

you cannot you cannot sign the next transaction you cannot refer back to the to the transaction that was a year that you're spending when you when you take this out when you take the signatures out of the transaction ID this means you can actually sign transactions out of order you can create a whole sequence of transactions and sign them in whatever order you want and of course unless the previous transactions are signed the dependencies you're not going to be able to confirm the later ones in the block chain either but this allows us to construct much more sophisticated logic where you can have transactions that have contingency conditions aware you know depending on what happened before you know whether certain transactions in the past get approved you know you can have certain a certain you know ways of a certain the scenarios you can make

happen after that and then this is very critical for certain things like the lightning network in off chain protocol transactions bi-directional payment channels where you want to be able to to be doing most of the this smart contract negotiation off chain you don't want to be going on chain every single time and you want to make sure that you can share transactions that are going to be spending on the blockchain without necessarily signing them yet so people can be holding on to these transactions ready to send you know to broadcast on the network if necessary but it's just you know most of them will actually never actually get on the blockchain it's just you have that option to get them on the block chain this allows us to have much more flexibility in the logic that we can create with these

smart contracts okay so you can okay I hadn't thought of that so you could have a just a bunch of transactions that are chained well chain that that are dependent of each other so for example you could have one address sending money to another and that address any money to another and that address any money to another and not sign them until you until they need to be broadcast to the network and the fact that there isn't that ability to change the transaction ID makes that possible correct mm-hmm exactly so taking a step back can you run us through exactly how segregated witness work so we've talked about you

know separating the transactions from the signature look how does that then play out what is done with 50 signatures what is done with two transactions so right now transactions have scripts on both the inputs and the outputs the the input script is the one that usually contains the signatures the output script is the one that contains the address it's the it's what you're sending uh you know coins to and it indicates a you know where you're going to be sending the points to that one usually doesn't have the signatures so with with segregated witness what we're doing is we're basically clearing the input script so the input scripts are no longer going to be used as you know that

we're moving all that data off to a different structure which is which is which can be set together with the transaction when it's real late when it's when it's broadcast on the network it all goes together but on the block itself it's it's committed separately so you have the the main merkel tree for the transactions which is which is the other route is stored in the block header the same way that it's working right now and you have this other commitment and this other commitment is just for the witness data and this witness data commitment is is a is something that we can extend further later on so so even though there's a block size limit with with the block merkel tree we can still add additional data to this other structure that's committed separately which which which allows us the flexibility to increase

you know certain things that that otherwise would have required a hard fork so we can actually do this with a soft pork so you said you know the data is sent together does a so for example let's say a record bitcoin note would that mean i can choose as a note whether i want to look at them at the signature data and validate that or i could say i'm just going to ignore that do you have for example that choice right so if you're running a full node you would want to validate everything so you'd want to be receiving the whole thing but you only need to receive the transaction data itself and not the signatures if you want to know the state of the block

chain if you're not doing any validation so for instance for SPV nodes of they might not be you know requesting all the signature I mean all the other witness data which contains the signatures that would be enough to know that they received they receive bitcoins and then they would be able to look at their entire transaction history if you want to validate then you do need this data but but the key thing here is is that it is that even though it can be relayed together it's committed separately so instead of committing all the transaction data into the same merkel tree you have two separate trees in the block and and this data can be committed in two separate the way into two separate places which makes them independent this allows us to to update the the witness data independently of

the transaction data and such as briefly when you say you know they're both you have two different merkel trees in the block what do you mean is that you know this merkel tree then determinist good links to all the witness data so that you know it's always clear what block and and what witness data go together sure sure yes and where's that put in develop chang so initially we were putting it in I mean it has to go in the coinbase transaction this is an unfortunate way that the weight Bitcoin was designed the block headers don't have any more fields where we can stick stuff in so the only place that really we can freely stick stuff in is the coinbase transaction the first

transaction where the minor actually gets the block reward so the input of the coin base is where a lot of stuff used to be put in transactions and in that you know that that's something that's been used for for several things like like identifying the the mining pool sometimes puts their own you know identifiers in there the block height is stored in there etc but it turned out that the that some miners some mining hardware had already been designed that made it hard to stick this data in there and so we went for putting it into the into one of the outputs so there's actually an opera turn out put in the coinbase transaction and this is where

the commitment for the for the Merkel root for the witnesses is stored so so basically it's like an additional data field in the coinbase transactions so that means you know if you if you talk about minors now so if I'm mining a block and you know I'm just not going to do that data means that what does that exactly mean is it possible to for example you know mine a block but with transactions but I don't put the Merkel route to the segregated witness signatures in there well once the soft for activates you all miners have to include the the Merkel route that that's

a that's what makes it a soft fork you know blocks before it didn't have to have this and now it needs to have this if it doesn't have this it's not a valid block anymore so so as a minor you would have to put the Merkel root for the witnesses in the in the coinbase transaction for the block to be valid so it would still be a ballot block according to their you know current rules right it wouldn't be a valid block anymore to the updated clients correct yes if it doesn't have the the Merkel root for the witness data hmm so what are some of the other advantages of this approach or things that we can do with through second grade witness that we couldn't do before well another really really neat thing is that

since we're moving the script data also into the witness of this allows us to have an upgrade mechanism for the script we can basically replace the entire script with a new script before it was thought that what this was very very difficult to do without without requiring a hard floor this was because you would have to have new opcodes that they could do other stuff with the stack rather than just you know either you know succeed or fail that this means that we can have the opcodes that can add new new functionality that was very very difficult if not impossible to do before we can basically replace the entire scripting language with with

anything we want okay it can you explain how this is possible how does the signature relate to what type of scripts you can write right so as I said before the script is stored in the input right now it's part of the the input of the transaction but we're moving it out into the witness so now the input is clear at two old nodes it looks like like an anyone can spend transaction right this is the same mechanism that was used for 4-bit 16 when multi sig was rolled out um so since since it's an anyone can spend transaction for old nodes the new nodes can use whatever rules they want to it to validate the transaction so so we've it's a nice little way to get around this this limitation it allows us

to a to create any kind of script the old nodes are going to basically just ignore that script they're not going to look at it and they're going to consider it valid of the the new nodes are going to be able to you know look at the script and run the script and and we could put whatever we want there now so the first version of this is just going to be the the script that we have now the scripting language that we have now but in the future we're looking at adding other kinds of op codes or other kinds of scripts you know some of the opcodes it that we're looking at adding our new kinds of signature types you know we're looking at the snore signatures and other kinds of you know interesting interesting things that we can do with a another thing that we can

do is op codes like they can manipulate the stack in ways that we can do right now right now we have all these new op codes that were added that are all just verify you know check lock time verify these these off codes can you know basically are either no ops or or they exit you know with with an error they basically exit false with with a way with segue it we can move it we since we can create new op codes that that don't need to be executed by the by the old clients this gives us a full flexibility to be able to create op codes that do whatever we want so so this is a really really neat thing I mean it's just one of those things where it's like what can we do with it will pretty much anything I mean it's it's it's a whole new dimension of

the you know of a you know of ideas that we can really explore here so by taking the script moving it out of the block and into this this witness part what you're essentially doing is you're allowing knows to choose to create new codes that would be that would be run sort of as a soft fork is is that I got ya hi exactly yes so we want to add a new when we want to deploy a new scripting language or a new opcode it would be done as a soft fork and so the script has a version bite which which tells you what you know which which version it is and so every single time we want to deploy new when we just bump

that version up and now we can have a completely different you know different scripting language with different op codes and you know do whatever we want without ok so then notes that would understand knows that choose to run this new scripting language could and others would simply ignore it yeah they were just ignore it and just return true okay so could you give us an example of how this would work and by that I mean so if some group wanted to try new functionalities and implement new op codes what would they have to do how like they don't have to update their clients I suppose right so for this to be deployed it would have to be deployed as a soft fork which means that you

would have to propose it implement the code put it out there and and then use an activation mechanism so right now we use a ninety-five percent 444 activation so as soon as a ninety-five percent of miners signal that they support this new feature that triggers the change and it locks it in so after that point uh you need to you need to also validate that if you want to make sure that the block is valid let's take a short break so we can go to Paris I stopped in to la maison to Bitcoin the house of Bitcoin at the larger offices and I met with ledger CEO erica Kovac so he could tell me all about the ledger wallet chrome app the ledger when it chrome app is a perfect companion app for your ledger hw1 or nano we are very

powerful and cool feature you can use multi accounts for instance personal accounts business accounts this is very useful also when you want to make a transaction we use a second factor verification you can either use a physical security key or cryptographic and securely pair your Android or iOS smartphone to your nano this way when you issue a transaction of payment the transaction will pop up on your Android or iOS phone and you will be able to verify the amount and destination address finally the ledger chrome app has an API with which you can easily integrate third-party applications for instance if you want to create a multi

signature account with joint guide or copy it will be done using the ledger wallet Chrome App ledger is making hardware wallets easy and convenient without compromising on security if you want to get a secure setup for storing your big points go to ledger wall calm and use the code epicenter to get ten percent off your order we'd like to thank ledger for their support of epicenter Bitcoin so you mentioned bib 16 and how does that compare with big city so big sixteen was was also a soft pork yes right so so the difference here is that well if they succeed there wasn't a version bit right so there's no like different things and also how else

does it compared to how a multi sig was implemented yes so the multi cigar codes actual already existed so Toshi put them in there from the beginning but there was no simple way to use it we have this you know this bib 16 basically uh was was paid a script cash it allowed us to instead of paying to a Bitcoin address which is a hash of a public key it allows us to pay to a hash of a script and the script can be anything so this this gives us much more generality so so um it was also a soft work because because the two old nodes it looks like anyone can spend spacek alee these transactions yielding the the whole script that is hashed is not actually

executed by the old notes the new notes do have to execute that and they check to make sure that it does return true but with seg wit it's not just that the script executes so you can actually define different kinds of scripts you can add a new kind of script and and to the old nodes it would just be like you know then it's it's a they would ignore it like you said they wouldn't they would know how to evaluate it so they would just ignore it and return true but the new nodes can can can interpret it using the new the new semantics right but so you could really have used to say mechanism back when you know pay the script cash was implemented do you know some other things that are more

complicated maybe some of the things we're talking about now with with segregated witness yeah actually that's true um there there was an opportunity there to maybe do some stuff unfortunately at the time it wasn't really you know people were not thinking that far ahead as far as a you know these kinds of deployment mechanisms it was really for the you know the main the main objective there was with the multi6 stuff you know to be able to use that and to be able to deploy to use other kinds of scripts that used to be non-standard to make them standard by being able to use a pedo SH paint a script has to be able to have these

transactions relayed so so I don't think back then really people were thinking about the thing but you're right i mean in principle the this kind of mechanism could be used for something like that it's very it's very similar I mean it's like what uses a very very similar mechanism right very interesting so I saw some I mentioned that you know this could be used for Bitcoin to implement like a theorem like script what could it look like and you have like a sort of full-blown smart contract language there oh yeah I mean in principle you could do a you know a lot of things if the etherium scripting language has much more state space you know it's much more stateful it has a it's it's it's got an

execution environment that's much more complex than than Bitcoin you know it's got this whole random access no model that that makes it too much much more complex to optimize and to make it actually you know run fast and scale and all that so i think that with bitcoin really the the focus is on trying to to use the scripts mostly for the cryptographic stuff there's there's other stuff that's also included in the scripts that you know there's a there's time locks and hash locks and stuff like that but the idea is I mean in principle you could have much more sophisticated script but we're really trying to find ways to not extend it to the point where

it's really really you know to to resources intensive and it makes it really really hard to scale this you will still have to the 10 minute block them right or could you have some sort of like you know sub-blocks so that you know maybe are more frequent only in that segregated part but only you know this kind of the money movement remains at the regular Bitcoin block interval but something at that be possible uh well I mean I I don't think that with this proposal right now you know we're really looking to do something like that in principle I mean there's been several proposals for for those kinds of a you know um you know side blocks are you

know ghosts or other kinds of schemes i I don't I I I think that you know most likely we're not going to be looking to do anything like that in the very near future so we identified a list of things here that are made possible by this and some of the other improvements that it can offer is is something called fraud proofs for SPV clients can you talk about what that is yeah sure so in the original Satoshi white paper it was mentioned that SPV clients um if there was a way to have fraud proofs it would

improve the security because it would only require one whistleblower on the entire network to notice that a block is is invalid and then all SPD nodes could note ignore that block so right now if you're running an SPV client you you get a block that confirms a transaction and unless you are able to validate the block and you just exciting you accept the transactions confirmation because the rest of the network seems to think it's okay but of course miners might not be you know they could be cheating or you know they could be running buggy software this has actually happened before where miners are not validating correctly and then SPV clients are going to see confirmations that are not actually real so this is this is an issue which which Satoshi considered

fixing you know a potential fix would be if it was possible to make it so that you know even if proving that the block is valid is expensive it still requires downloading the whole block and checking it may be making it so that proving that the block is invalid could be made cheap so you could have a very short proof that it demonstrates that the block is invalid and if you could create this that means that it will only take one note on the entire network to you know to construct this proof and propagate it and then all the nodes would know immediately to to ignore this but there's there's a significant problem with this which is that it requires extreme censorship resistance like for instance if you're connected through your ISP and your ISP decides to block these messages that there could be

potential attacks there it'sa so requires a you know it requires more security assumptions but on the other hand it does mean that you know the incentives model shifts more towards you know people actually wanting to validate because it's more likely you know a validating correctly because it's easier for someone to it's harder for someone to get away with it so just the knowledge that if you try to do this you'd be harder for you to get away with it could make it so that people are less inclined to try it so so so so fraud proofs are a really interesting thing they still have a lot of problems in principle and I think that you know some of these things could potentially be fixed of with with the original way that

the Bitcoin was implemented this was something that seemed very very difficult to do because if you want to check whether a block is invalid you need to have partial proofs for different things you need to be able to check for instance that the the coinbase transaction that doesn't doesn't pay the minor too much that the fees are correct in all the transactions that all the transactions to spend coins that actually exist etc you know that the signatures are valid so if you can separate all these different checks and make it so that you know you can prove that any particular one of them failed but that would be enough for a fraud proof so for instance if you can just prove that one of the signatures in the transactions is invalid and it's necessary that's enough to show that the whole entire block isn't valid or if you

can prove that the minor paid paid himself to watching fees that also is able to prove right away that the block is invalid so with will segue we can we can do this because now that we have this extensible commitment structure the second merkel tree we can insert their additional data about the transaction about the transaction inputs in particular that allows us to to do back references where we can actually see where the coins came from and use that to to prove to construct short proofs that for instance a particular coin that was spent doesn't actually exist you can actually go back in the block chain and look in that location and if the coin that's supposed to be there is not there then you know that that block is invalid

so so this is how this is how it lets us do these kinds of things but but I should note that for the first release of segue we won't be doing fraud proofs right away this is this is something that's for some potentially some later release one of the nice things is with this with some extensible structure it allows us to do incremental deployments we don't need to put all the features and pack them in right away and we can we can you know the put the features in later on as we have already tested the whole system and you know that we've done more research and figure it out what how we can actually do this so just just a little bit more on the frog proof question how exactly what that works oh hmm not now I'm a minor I'm a mining a

block and you know I'm also this also this extended segregated witness data with all the the signatures where would I include the full proof in there that relates to to who or how exactly would that work so what happened with the with the fraud proof is that you need to have a commitment structure that can track the stuff necessary for someone to construct the the fraud proof the the commitment itself would not have the fraud proofing in a valid block you don't have a fraud poop because there's no fraud right the fraud proof is constructed when a block is created and propagated on the network that is invalid so someone would look at the

block and and and and see and then run all the tests to make to validate the block and if any of those tests fail they would be able to point to exactly what failed and how it failed by by by using that commitment structure for instance if the commitment structure stores of the input values right so it knows exactly how much that you know each each particular input spent and it knows the output values then you could calculate the fees from that you can see that the fees actually add up correctly and the minor is not paying him or herself too much in fees right okay so so so do I earnest and I corrector basically right today with a block like I can validate it I may see that there is something invalid about that block

but the problem is I can't like proof to someone else but like very easily that it's something invalid because of the way become blocks are constructed but now I've segregated witness we can think ahead and you can say okay let's construct the circulator witness data in a way that makes it really easy to prove if something is invalid so I can submit that exactly exactly okay that's it very neat so let's talk about one of the other advantages of moving to segregated witness and and that is addressing in part the scalability issue now it addresses it by allowing us to add more transactions into a block because essentially as we remove the signature part and we move it

to some other data structure those those transactions are much smaller in terms of the data footprint and and essentially we can fit more transactions into a one megabyte block now you mentioned that that wasn't the biggest advantage although to some it may seem like such a huge thing because we've been talking about block size for so long and trying to sure to come up with solutions on how to put more transactions into a block without affecting decentralization without affecting like having too much bandwidth go through to two minors can describe just broadly what what sekirei witness brings in terms of scaling Bitcoin have

more transactions in the block and what are some of the pros and cons of that solution sure so I mean short term yeah I mean growing the block size can provide more throughput you can stick more transactions in the block but long-term that's not going to be a viable scaling solution because if you want to you know scale this to global size we're talking you know several orders of magnitude it's not just going to be two times or four times or 20 times we have to scale this up a thousand times to compete with you know the large payment networks right now or more right so to be able to reach these kinds of numbers the block size alone is probably not going to be able to get us there but at least in the short term it does provide a bump and I know that a

lot of people in the industry have been kind of craving this bump because a you know allows them to to at least you know hold on you know a bit longer until we have better technology but I think that I'm you know the neat thing about doing this was with seg wit is that you know the compatibility aspect it doesn't require people everyone to upgrade r at the same time it's not going to fork the blockchain it converges you still have a single block chain and it allows people to upgrade incrementally and it'sit's backwards compatible so so these things mean that it's it's much much safer to deploy this than in to deploy hard for the block sides increase if we just

increase the block size you know by by changing a constant in the code yes it's it's easier from the perspective of you know fewer lines of code that need to be changed but it's much more of a hassle in terms of the the network stability it actually causes some very very severe problems in networks ability both on the technical and the political levels as we've been seeing recently and this is a direct result of changing something that makes it not not backwards compatible so so the backwards compatibility aspect is is huge this means that you know it gives us a much much much bigger safety you know safety margin and and it's something very similar to we've already done before like we saw with VIP 16 with the multi6 stuff and then that was deployed very very safely you know no incidents there the multi sig is super

secure everything's working fine this is a you know something where were we discovered that we can actually get you know an effective block size increase without breaking old clients and this is huge this is something that that means that it gives us a road map that can lead us to a to having a short term bump and also it gives us the other features that i talked about particularly the malleability stuff if you fix the malleability issue this allows the development of second layer networks so so like lightning network and off jean protocols and once you start the innovation there you can have a lot more uh you know several orders of magnitude scaling in the sense that no longer does everything to be propagated on the

Bitcoin network good you know for throughout all the peers not all the peers need to know of all transactions you can actually have you know smart contracts negotiated directly point-to-point between different peers and and they only need to commit you know the only to settle at the end of the you know once everything happens so if a whole bunch of transactions happen on the network and the net you know they need a all night out 20 nothing needs to happen on the blockchain um you know the only whatever is net out from that needs to be committed to the blockchain so the malleability fix allows us to really you know start looking at other kinds of approaches that I think are really what people are much more excited about than just the block size increase of course people want block size

increases we've been talking about it forever and we still get that we're still going to get I mean it's not it's not just the virtual blocks isn't because it's a real block size increase it's just that we're not increasing the block just you know the same portion of the block all together we're we're separating out a part of it which is which is being counted differently and which which makes it bat which allows us to make it backwards compatible right so if you think about scaling cuz cuz the thing people have always been worried about when it comes to increasing the block size and nothing the most convincing argument was always that this actually creates a centralization pressure for minors because bandwidth you know plays a big role so if they you know blocks propagate more slowly it

helps big miners now here that doesn't really change anything right so if you had like a three mega byte block that you know the core block plus a segue a witness part you know that's really equivalent form a sort of desensitization perspective as if it was you know just a three megawatt block is that right right yeah right i mean that's that's true and so basically we have a choice now we can either do this segment thing which is going to have the same bandwidth implications or we could try to to actually you know do a hard fork but the the the you know the hard fork is just gonna be a bump in the immediate bump it's not going to give us any of the other scaling benefits and it has all the destabilization issues you know with especially with the political

stuff and the potential for for future attacks you know contentious hard Forks people in the future deciding that they want to try to control the consensus rules and you know jumping in with with you know trying to trying to get all miners to do something and basically forcing people to move to a different network so so so so so we're really trying to avoid situations that are conducive to that kind of dynamic because you know if you really think about the implications of that it doesn't bode very well for the network for the for the long-term stability of the network so I honestly never really understood that argument because it seems to me that you know if we looked at like big one

one or something is that right you had that mechanism that you had to have a large majority of minors you know agree to it and then you had like a fairly long a period where you know they had agreed it was clear what's going to happen but it wasn't happening yet so it essentially give you know people on a network a long time to up create their clients now why is that such a risk well it's a risk because you know what if it what if it doesn't reach the ninety-five percent what if it stays like a fifty percent for a while you know sixty percent or seventy percent you know it's a lot of uncertainty and and once it

breaks one way or the other you're talking about two incompatible Ledger's basically uh people that did not want to change into the new rules are going to be forced to either change to the new rules or are going to be thrown off the network with a soft Fork of you you you you you need you have better security if you upgrade but you're only adding more rules you're not changing your not eliminating any of the old rules that you had before and and it's the dynamics make it much harder for any single entity to come in the most important factor here is it it will always converge you always have convergence

with a soft for as long as there's a there's you know a super majority of miners one of the change is always going to be the definite the main chain in the case of the hard fork even if there's only this five percent that kind of like you know don't change the people the users of that network might not necessarily even know that that there was a fork and they might see just like the house rate suddenly drop right and it could be much more easily attacked so I think you know we're seeing right now is the situation where people people can can do a lot of posturing and and and you know kind of like give the impression that there's going to be a majority of you know of hash power on our particular fork but but maybe

they'll play a different way you know people don't have to tell the truth they did it you know when you're when you're signaling that you're going to be forking miners don't necessarily need to indicate which fork they're going to do and there's a lot of loopholes there and in potential attack vectors that happen there because it once you have these two different two forks it did they coexist you know you can double spend one of them and you know without risking losing the coins and the other so you can have like these kinds of situations where the two chains we know if you can kind of be you know fighting against each other or you might even have you no more than two parties more than two different sets of consents and rules that are being to put on the network and it just it doesn't seem like

it's a very stable you know it doesn't lead to stability okay so it you know this all seems really great I mean all these things you can do it segregated witness seem like pretty pretty like a big breakthrough right what are some of the security implications are there any downsides to doing this um well it does increase the bandwidth requirements and and and you know it since it's a sense it's a more dynamic kind of limit it depends on on the sum of both the the non witness part and the witness part of the transaction there could be

situations where you could get blocks that are a little bit bigger in attack scenarios but I think that that's that's something that it's still very costly to pull off it's considered to be you know kind of like those cases where we're just you know the the cost of the attack is substantial which which which greatly it dis incentivizes it but I i think you know some people might be concerned with with things like that you know the degradation of security of other nodes I'm and I would just say that you know in any kind of consensus rule change there's always an inherent risk and this has happen every single time that we've deployed soft forks and we've already done it you know several times and actually now we've actually gotten soft

folks down to a science so something that I think we've gotten it pretty much about as safe as we can possibly get it get any kind of the consensus rule the deployment and I think that I mean obviously with any new thing that we're doing there's always possibilities that there could some issues but we're running tests you know we would wear of making sure to a to run a barrage of tests to try to you know make sure that that everything works as intended so regarding Tess you you've set up a test net howdy how many how many notes you have how many people are running tests on the set on this new test net um I believe hmm I i believe

it's like you know maybe 10 to 20 nodes on i have i have to check right now i actually don't have the exact number it's been a couple days and a lot more people have been joining so I I don't know the exact number but it's been growing it's been growing a lot and I think that um you know I mean it's still small it's still mostly for developers so we've gotten a lot of the wallet developers and a lot of the library developers to start tinkering with it and you know they did seem to be enjoying it and so I think um you know there's also um there's um you know there's also the need to do more stress testing and see exactly like cutting oh if we can push the limits to see like if anything is uh you know if there's any

issues with with a with the other aspects of the system that they could possibly break potentially break but but everything has been running really smoothly until now I mean there hasn't been any issue so we're very optimistic that we'll be able to roll this out on to mean that they're you know pretty shortly today's magic word is witness WI T and USS head over to let's talk bitcoin calm to sign in enter the magic word and claim your part of the listen reward you mentioned a volatile pursuit you're volatile for yourself what does that mean for you know let's say wallah Tavella burst I wanna use sex i grated

witness transactions this is a big change it's actually not that big of a change the wallet developers that we've worked with you know we're able to implement it within a couple days you know less than a week it's something that it's not very very difficult at all it does require some changes it's it's it's something which some of the some people in the space of kind of you know we're hoping that they wouldn't have to change anything but I think that as far as changes go this is a very very minor change it does require having to recognize this this witness data and and look at the signatures in there but this also makes it much simpler to develop a lot of the you know better applications and especially like the multi cig space

multisync transactions with side wit are much cleaner in a lot of ways it allows us to stick the signatures into the structure in a way which a which witch is which is much much cleaner than the way we're doing it right now so i think that the benefits fur fur and also with the with with multi sick transactions the the throughput increases is greater than with a with the non multisub transactions so once we i think that there's a lot of a III don't think that it's something it was really really that complicated to do it took me as i said in your most wallet and library developers have been able to integrate

most of the stuff in a couple days okay is really interesting so what does it look like it's it seems like there's a kind of universal support for this or you know very strong support which is extremely rare thing in bitcoin land no it is generally people disagree on most things so what's what's what's the plan now what's the roadmap and when can we expect this to be integrated well i mean a lot of the the libraries are already you know it's a pretty advanced state of integration once these libraries are you have these uh are integrated then

applications that use these libraries can start integration and so the whole legal system can can can can upgrade that way we think that we are probably going to be able to deploy something on two main that you know we're hoping by by April to have something something deployable at least oh yeah so at this point there would just be the code that that's mean that's necessary to activate it it wouldn't actually activate until there's a minor supermajority ninety-five percent which can happen anywhere from a few weeks to a couple months down the line from that we're hoping that you know the will see very quick adoption and we're hoping that people can immediately start making use of the new features of this and we're really excited about the you know the

new kinds of stuff that we can start building especially the second layer stuff that's going to be really really exciting because that that really you know once we start getting into the second layer protocol stuff we really remove a lot of the innovation out of the consensus layer which means that a lot of the politics go away we don't have to deal so much about arguing about you know how we're going to change the consensus rules and forks and all this stuff there can be competing networks that can be exploring different ideas without breaking everything for everyone and you can have two different lightning networks they use completely different structure types or whatever as long as the consensus layer is the same a no problem i mean the you know we obviously want to standardize these things for the whole network at some point but it

allows us to really experiment with these things without breaking the network and so what it's your so we were talking about this earlier and it once once miners agree to to implement Syria witness and we start having wallets and libraries implementing this it is the is the ambition for everybody at one point at some point to start using segregated witness transactions to move this aggregate which this transactions or you think part of the network will use the old type transaction and part of network will use seg witness well for a while there's going to be both I mean not all

the wallets are going to upgrade right away old wallets are going to work fine they're not going to need to do anything to be able to send and receive transactions you can send transactions from the segway wallet to a non sequitur aulet and without a problem and vice versa you want to upgrade to seg wait for for all the features that it offers though so i think that there's a lot of economic incentives just built into this already now people are going to want to do it because it's just you know makes the it makes it possible for them to to give better products to their users so this in itself provides the incentive for people to you know be to be doing this I think that once once we have enough people really using this you know it's everyone's going to want to use it at

some point how long that'll take i don't know i mean at pedo sh when we when we first deployed out up being paid a script out it took a while until people started to you know adapt to the new address types here you actually don't need to have new address type so everything is fully a pedo SH address compatible with which are the addresses to start with three in Bitcoin so so any wallet that can send to those addresses consent to a sublet wallet without any modification right now and so we're gonna probably see a time period where where you know there's gonna be there's gonna be a mix there's gonna be a hybrid not everyone's going to upgrade but I think as soon as people really start to see the benefits they're all going to want to migrate to this and hopefully it won't take that long I mean hopefully

it'll take me it'll be much quicker than the migration that you know to multi cig in and paint a script apps that we've been taking a while and there's also an incentive in terms of transaction fees right because as sure as we mentioned earlier transactions will be small you can fit more transactions into a block which implies that transaction fees should be less tell us a bit more about how this mechanic yeah correct correct I mean in principle you know that this means that you know the transaction footprint itself in the block is going to be smaller miners can fit more of these transactions in a block so so yes this means that the fees in principle lower so this this could be another advantage right now if these are still a very a small part of the minor you know

the minor rewards is you know the subsidy is still them the vast majority of the minor reward so if we start to see more you know competition for fees you know and prioritization of transactions based on fee we could expect this to definitely be a significant economic incentive by I think that the amid the initial incentives are probably anymore just the fact that wallets that support this can offer much cooler stuff for their users but definitely yes i mean the the fees are definitely going to be going to be lower say i have another question that right now one of the challenges that I see right so if you have different clients so one of the problems with

Bitcoin you know my view is that there's this kind of one client and it's really hard to make like have a variety of clients because there's a you know this risk there's some sort of consensus bug and then you know they'll build a bridge and so you have a strong incentive as it used to be sort of on the main client is it possible that segregated witness would help there to have it more possible to have you know different implementations of Bitcoin at the same time well for that to happen I think we really need to separate out the consensus code itself we're working on on a consensus library segue could potentially help modular I some aspects of it perhaps modularization here would be key if you can modular eyes these

things and and have libraries that implement these different consensus rules you can have different applications you reuse the same code which is going to you know in principle behave the same way and so yeah one of the issues with consensus code right is it you have to replicate even the same bugs so so if two different programs have any any kind of divergence of behavior it's not which one is correct in the strict sense it's you know which one is a you know whether they agree or not and if in and you know this happened in the in the fork and one was at the 2013 was it where the rule the official consensus rules were actually not adhere to because it turned out that the majority of the economic you know the

economically important notes we're still using an older version that broke with the new rules so so so this is kind of an interesting situation where you you really cannot just expect to have all these implementations to to you know to work side by side unless they can be rigorously tested against each other this is a very very major issue i think that segregated witness is probably not going to solve this in and of itself i'm hoping that it encourages more modular ization in general somehow I'm i think that when you're breaking out the consensus layer and really working on on developing a solid implementation for that and letting other applications that we use that would probably be the way to

go okay very interesting answer now this sort of ties into the larger block sighs debate at least partially I get that there's a lot of other things going on here what is your view and dad I take it you're have a lot of concerns about haart forks right and so with favor an approach like this is that right yeah I mean I think that unfortunately the the whole block size thing got conflated with with me a lot of different issues and I think there was a lot of misunderstanding I think that a lot of the the non-technical community and and in the public were not really witnessing exactly the whole you know development

and then as far as with the developers were worth doing um you know way back in May we were already talking about you know considering these ideas when it was first to propose to the mailing list and people were actually really you know trying to pick this apart and figure out all the things that could possibly go wrong and it quickly became apparent that hard Forks have very very significant stability issues and and significant you know they can potentially open up attack vectors you know and and things that they could be very dangerous for the network so so I am very concerned about hard folks that's not to say that it's impossible to do a hard for you no more safely I think that the only way that that's viable is if there isn't this kind of you know contentiousness if you don't

have you know a lot of polarization and and people kind of you know fighting with different things if it was most of the network agrees on something if something's pretty you know much uncontroversial that's fine as far as the block set itself I don't really think that there was much issue with with with bigger blocks I don't think that you know many of the court dad's actually said now we we should never have bigger blocks I mean I think for the most part that the you know the idea of having bigger blocks is something that it was appealing we should find a way to be able to have bigger blocks we all want to have bigger blocks but just increasing the blocks by by changing a constant in the code presents a lot of very very serious problems so it turns out that if we want to do this and do it

safely we probably have to retrofit some stuff and do a lot more risk mitigation which is what we're trying to do with this I think that there was Segway we kind of get you know the best of both worlds i mean yeah it's not a single constant change in the code it does actually require a little bit of modification of applications but it's not a very significant modification and it's much safer from all the other aspects of it you know it really it does not cause all the stability issues that just you know changing this constant does so I you know I think that to get back to the whole block size thing block size was never really the issue that was never really what people were arguing about it was much more about this hard fork thing you know whether we should do a hard fork or not and now that we have

a soft fork way to do it it's almost like a no-brainer it's like well of course you should do it with a soft work now because it's you know it's just got all these other benefits right so I mean I you know I agree right it sounds like a no-brainer to me to do sec witness but that being said but it only lift the total amount for transactions pie you know a little bit or you know like doubles or triples it but you know it's still a fairly minor increase so you know I taken you will need a hard anyway so why not just do it now and like what a what is the benefits to delaying it well right now the network

probably cannot take much more than two mega byte blocks this is just like you know basic you know tests that have been done the general consensus among the the core developers is that going beyond two megabytes is probably not too much right now so if we're going to go to two megabytes you know we can either deal with a soft work with a hard floor if we do with the soft work and we get you know we would seg wit you get all these other benefits that I talked about you know in addition to just the blocks bump and also it allows us to optimize for a lot of things like for instance the UT exocet you know the unspent transactions right now with with the current cost metrics with just the block size it doesn't provide enough incentive for people to clean that you know which

which is basically stuff that needs to be stored on all the validator nodes it's just extra data that gets stuck there and with seg wit this adds an incentive to do that because this part of the block is more expensive so people want to clean this up by spending these and you know that the witness part is a cheaper part of the block so so the witness part consumes that the unspent transactions so so that that creates an incentive for the for the unspent transactions to actually spin transaction outputs to actually decrease so there's a lot of benefits that we can get from this besides just a block Club and if we do a hard fork now ignoring all the political and you know the destabilization issues assuming that we could do it safely assuming that we could actually deploy a hard fork safely right now now we're stuck with the same

cost metrics as before we cannot optimize this and we're not going to be able to do seg wit now without having to go maybe to four mags or eight Meg's which which is something we're not ready for we need to we need to build up a lot more infrastructure and you know better relay mechanisms to be able to support those kinds of things so this would seriously delay the you know seg wit which would be a you know a very very major setback I think that it would really set back development especially on like the second layer protocol stuff which which would be very very unfortunate yeah and of course I mean anytime you I'm a strong proponent of just optimizing technology as much as you can if there's ways that you can optimize that and it's low-hanging fruit you should just definitely put that in

place and it seems that there's been sort of consensus around implementing segregated witness is one of these sort of things that we should just do because it's easy in it and it solves a little problems but I above and beyond the black sighs debate I mean as we mentioned it allows for so much more in an innovation and perhaps you know trying new solutions that we haven't thought of yet that would allow us to do more transactions or higher volumes at let in cheaper cost so so yeah I mean it's like there's really no no reason why we should do this no I agree I I kept agree with that so let's before we wrap up

here let's talk about Cyprus sorry sigh prix key tell us about your company yeah so as I said in the beginning I started working on on tools and libraries because I was writing applications for Bitcoin and there really wasn't anything out there that existed at the time that allow me to do kinds of things that I wanted and and right around the time that the the multi6 stuff started happening with with you know with it with Peter script hash I started thinking about ways that we could combine that with 32 which is the hierarchical deterministic key chains and create a platform so you could do you know enterprise-wide security policy configurations for Bitcoin account management so you can have accounts or you can create you know Bitcoin

addresses that have a security policy that that's based on on all these different designers you can have it you know in your organization or it could just be you know different machines that you have yourself right you use your cell phone you can use your laptop you can use your desktop machine whatever you can have a machine at work and have a server that has a signature so they're just having a really flexible infrastructure for that so so that was kind of the the you know the killer app if you want to say that the kind of you know yeah while I was looking for in the beginning but but really in the end we're looking to you know the we're looking at all these different ideas that are coming out right now and I think that you know the kinds of tools and you know the things for instance for

smart contract to design and you know smart smart contract authoring tools and you know script templates and other kinds of you know and more generalized mechanisms for being able to a 22 to you know to develop on top of this in Sicily these these kinds of things I think are looking very very promising and with the whole you know second layer network stuff off Java chain transactions lightning or there's they think there's a lot of the really really interesting things that are happening that I'm really looking forward to so right now we're really just exploring the whole space and we're really looking to see how we can collaborate with with other industry partners and you know try to try to really build a whole industry because

that's really what we're doing here you know we're trying to create a whole industry and no single company can do it by itself I think that that you know where we're pretty well positioned to do this just you know given all the you know kind of the overview that we have with with you know the we would with the development star that app are having right now and right now we're we're looking at really looking at it more of like an infrastructure kind of platform based you know solutions rather than just you know like we started with a wallet we do have a wallet dem cigna but you know seiffert is really about the whole we know infrastructure and platform cool well um Eric thanks so much for coming on that was super

interesting and you know I'm I can I can join the consensus I think this sounds like an amazing idea in an amazing innovation and I have to say like you know sometimes I was thinking like well you know with Bitcoin the sort of development has slowed a bit you know this people don't agree on anything on how to sort of take the technology forward and this really does seem it has the potential to just open up a whole new wave of innovation in Bitcoin I think that's something that's extremely needed at this point it's absolutely really excited about this yeah absolutely yeah it we're super excited to see you know new a new ideas stem

from this and we really want to get past this whole community division we think it's silly for for Bitcoin you know people to be against other Bitcoin people it's like we need to be united as a community because we already have enough threats from the outside and if we don't stick together and and do this thing you know together I think we're gonna we're gonna find that we're not going to it's not going to be viable so I really hope that the big community can come back together soon and you know we can really work on this together because I think there's a lot of amazing stuff we can do and NM and I'm optimistic on the future i think that there's a lot of really great stuff coming yeah no absolutely there's that thanks so much Eric thank you thank you guys yeah also

thanks so much for our listener for listening as we were part of that lets or pick on network ltb network so you can find lots of other great shows on lights or pecan calm and yeah we put out new episodes every Monday you can get it on all your podcast player and you can watch videos and youtube com / episode and Bitcoin and yeah if you're a loyal listener you also what you can do is you can leave us an iTunes review or reuse somewhere else send us an email show episode of be calm calm and then you know we'll see send you one of those t-shirts so thanks so much for those who have already done that and yeah thanks so much and we look forward to being back next week