This is a brief history of bitcoin script evolution. Since bitcoin was active in 2009, there was a lot of emergency fixes for the first 2 years done by Satoshi. He found that people could skpi the signature check using OP_RETURN and malformed scriptSigs. So those functions were removed. OP_VER and OP_VERIF were intended for script upgrades but it was found that after every release of bitcoin, it would become a hard-fork because of the design. So those were also removed. Also, many opcodes were removed due to potential denial-of-service attacks: CAT, SUBSTR, LEFT RIGHT, INVERT, AND, OR, XOR, 2MUL, 2DIV, MUL, DIV, MOD, LSHIFT, RSHIFT.

The first new function introduced was p2sh (bip16) which allowed people to use a single address to pay for any compact script. It doesn't introduce any new functions, it just makes the..... And later there was a fix, with bip66, which was related to script due to strict DER signature format. Consensus bug due to inconsistencies in signature handling in OpenSSL.

There were other upgraded opcodes-- OP_CHECKLOCKTIMEVERIFY (bip65) and OP_CHECKSEQUENCEVERIFY (bip112). These are very useful in smart contracts. And finally, we just had a major malleability fix with segwit (bip141).

There is still a number of shortcomings in bitcoin script. The original solution for OP_VER and OP_RETURN -- these solutions were meant to help upgrade the bitcoin network but they were disabled. We currently have OP_NOP1 to OP_NOP10 and they only allow pass-fail like CLTV or CSV. But they wont allow for things like CAT. It is also not possible to redefine system operations.

In segwit, actually, we introduced a witness version and therefore it allows introduction of new script system in a forward compatible way. We can't combine strings or examine parts of a string. But these opcodes are very useful, such as in for example with CAT you can do tree signatures even if you have a very complicated multisig design using CAT you could reduce that size to log(n) size. It would be much more compact. Or with XOR we could do some kind of deterministic random number generator by combining secret values from different parties so that nobody could cheat. They could combine and generate a new random number. If people think-- ... we could use LEFT to make weaker hash. These opcodes were re-enabled in sidechain elements project. It's a sidechain from Bitcoin Core. We can reintroduce these functions to bitcoin.

The other problem are the ... numeric operations which were disabled by Satoshi. There's another problem. Which is that the range of values accepted by script is limited and confused because the CScript.. is processed at ..... bit integers internally. But to these opcodes it's only 32 bits at most. So it's quite confusing. The other problem is that we have this.. it requires 2^51 encode or calculate or manipulate this number. So we need at least 52 bits. But right now it is only 32 bits. So the proposal is to expand the valid input range to 7 bytes which would allow 56 bits. And it limits the maximum size to 7 bytes so we could have the same size for inputs and outputs. For these operations, we could re-enable them within these safe limits. It would be safe for us to have these functions again.

The other problem is that we currently cannot commit to additional scripts. In the original design of bitcoin, we could have script operations inside of the signature. But the problem is that the signature is not covered by the signature itself. So any script in the scriptSig is modifiable by any third party in the network. For example, if we tried to do a CHECKSIG operation in the signature, people could simply replace it with an OP_0 and invalidate the transaction. This is a bypass of the.. signature check in the scriptSig. But actually this function is really useful, for example, we can do... delegation, people could add additional scripts to a new UTXO without first spending it. So people could do something like let's say to let their son spend their coin within a year if it is not first spent otherwise.. and also, people, talk about replay protection. So we have some ohter new opcode like pushing the blockhash to the stack, with this function we could have replay protection to make sure the transaction is valid only in a specified blockchain.

So the proposal is that in the future the CHECKSIG should have the ability to sign additional script and to execute these scripts. And finally the other problem is that the script has limited access to different parts of the transaction. There is only one type of operation that allowed to investigate different parts of the transaction, which is CHECKSIG and CHECKMULTISIG. But it is very limited. There are sighash limitations here... there are only 6 types of sighash. The advantage of doing this is that it's very compact and could use only one byte to indicate which component to sign. But the problem is that it's inflexible. The meaning of this sighash is set at the beginning and you can't change it. You need a new witness version to have another checksig. And the other problem is that the sighash can be complex and people might make mistakes so Satoshi made this mistake in the sighash design such as the well-known bug in validation time and also the SIGHASH_SINGLE bug. It's not easy to prevent.

The proposal is that we might have the next generation of sighash (sighashv2) to expand to two bytes, allow it to cover different parts of the transaction and allow people to choose which components they would like to sign. This would allow more flexibility and hopefully not overly complicated. But still this is probably not enough for more flexible design.

Another proposal is OP_PUSHTXDATA which pushes the value of different components of a transaction to the stack. It's easy to implement, for example, we could just push the scriptpubkey of the second output to the stack, okay. So it is actually easier to implement. We could do something more than just... because we have sighash, we could check where something is equal to the specified value. But if we could push the value, like the value of an output to the stack, then we could use other operations like more than or less than and then we could do something like checking whether the value of output x must be at least y bitcoin, which is a fixed value.

There are some other useful functions like MAST which would allow for more compact scripts by hiding the other unexecuted branches. There's also aggregation that would allow n-of-n multisig to be reduced to a single signature and so on. In the elements project, they implemented CHECKSIGFROMSTACK where they don't check the transaction structure but instead they verify a message on the stack. So it could be some message like not bitcoin maybe, perhaps cross-chain swap, or another bitcoin UTXO. And also we might have some elliptic curve point addition and operations which are also useful in lightning network design.

Here are some related works in progress. If you are interested in this topic, I would like to encourage you to join our discussions because it's a very active topic. jl2012 bip114 MAST, maaku's MBV, luke-jr or version-1 witness program, Simplicity, etc.

so you have your script template the amount value and there is a block impactor beause we have the sha chain whih allows you to hae the hashes.. we can hae that errortate constant beause you need the HTLC chashes, to properly reoke the prior states and if you an't do that then you can't onstruct the redeem script. Right now it ineeds a signature for eery state, you need all the HTLCs, it needs the netowrk erification state, and there's another cool thing you can do with which is like trap door erification and you can include it in the transaction itself and there can be a alsue where there is some margin for it.. Which make sit powerful, and then you can make it more private with these constructs. We only have a few minutes left, we can cover this.

One furthe rthing is that in the transformation, we have privacy issue because we need to keep going forward, we need to have hte private state, so there's a history of this in the ages in the past, the current one used replications, which was one of the cool things about lightning. We used to have deckman signatures we had a sequence value of like 30 days, we did an update, we had to switch sides then we make it 29 then 27 etc. You can only broadcast the most recent state because otherwise the other party can transact the other transaction. If you start with 30 days then you can only do about 30 bidirectiona lswitches. Then there was cdecker's payment channels where you have a root tree and every time you need to- you had two payment channels, you had to rebalance htem and then it's on your part of the channel you can reset the channel state. You can do 30 this way, you have another tree, you can do it that way, and then there's a new version of it in the indefinite lifetime... by keeping the transaction in CSV, the drawback on that paproahc because you have al arge validation tree, in the worst cas eyou have 8 or 10 on the tree, and then you nee dfor the prior state and then you do the 12 per day, and every time you have to make a state, you have to revoke the preimage from the prior state, this is cool because if they ever broadcast the entire state, eahc one has the caluse so that you can draw the entire money in the event o f a violation. There are some limitations for doing more complex verifications and you have this log(n) state that you have to deal with ehen you deal with that.

We're going to do the key power on the stack to limit key verifications on this main contract. this is all composable. You can do discreet log contracts. You can now check signtures on arbitrary messages. You can sign a message nad then we can enforce structure on the messages themselves. Right now you need to have sequene numbers. So each state we are going to increment the sequence numbers. So you give me a siequence number on that state. On the touputs we have a commitment ot the sequence number and the value r. So people on chain will know that how many places we did in that itself. The ool part about this is that because we have a seq number then I have the one if it's highest neough. Then I am opening that commitment to say this is state 5 and I present to you a new signed ommitment and open that as well, that's in a validation state. The cool things is that you only need one of those m. So we have to some auxiliary state, and each time I have a new state I an drop the old state. I have a signed commitment to revoke the prior state. This is a ibg deal beause the state is much smaller. Currently we require you to fwe use a state mahcine on state 2, and it also has implications for verifications and watch tower

So on lightning, there's this technique itself- it's timelocks CSV value and if you can't react within that value then you can't go to court and enforce judgement on this attacker. So the watchtower is a requirement, you delegate the state watching to the watchtower. They know which channels you're watching. You send some initial points, like a script template. For every one you send the signautre and the verification state. They can use the verification stat ethat collapses into a log(n) tree, you can basically use state where you send half the txids, you can decrypt this in... some time.

We are going to reuse the sequence number commiment for outsourcing. For every single one you need new signature for each state, you need this key structure as well, it's log(n) but it can get large, so 100k people on a watchtower it's maybe a million states. So you're going to reuse this sequencen umber validation state, give them a new seq number every single time. So you can have constant storage for the wwatch tower, tif can be a billion and it will be fine.

Anothe rthing we can do is that we can.. covenants... we can delegate the outsourcing. If I was to do this in just the seq number, anyone can take it. if I wanted to.. for each new state, still what we do is integrate them into the contract and we sign their public key. We say here is my public key, if I can do it, okay. If.. now blessed, take hte ohter clause in the contract. They only need one signal signature and one constant sized commitment beause they are going to make the signature as part of the time itself. So now you have to involve the watchtower in the contract. Here's a merkle tree of 10 watchtoewers and any of them cna do it. So what about a trapdoor mechanism where you broadcast a new opening commitment, the contract an be modified to have a caluse with a CSV of like 10 days, at 8 day mark, maybe anyone can revoke this. So this makes a gauraneteed revocation on a contract with the watchtower, maybe I gave him 10% and he took the money but he's slakcing on his job then anyone can take the money and people could be watching these on the chain, and you lose some privacy because it's globally, but anyone can do anything they want because they can sweep. So it's basically your backup for watchtowers.

Another thing right now in the ... somethig called HTLCs... HTLCs value. and if you wanted to make a long delay, time to act, you have to use the CLTV value, and as a result you had to have very large HTLC values. But we got around this by using a second level HTLC contract. We now have a two step process. You broadcast, delayed, then you swee pit. You need a signature for every HTLC there. So that's a single state, I need a state for both sides, this can be better with schnorr but you still have the storage requirement. So if you lose the signature, you sweep it, you use regular covenants maybe, we can say here's the transaction can only be spent in this way, now you don't need to do pre-signing ahead of time because you know it can only be used in this HTLC situation.

We an make it more private, because rihgt now the channels on chain use... so we can use this with single sig. You can coinjontly generate the signature of a shared key. There's a way to do this with schnorr and delinearization fits into it. There's a way to do it with ECDSA but it's complex. You can do this with a zero-knowledge preface. There are channel openings and closings which look like regular transactions so that's nice. You can't cnesor all the transactions of cours.e And finally we can modify HTLCs where we use sphinx to... you can re-randomize the HTLCs every single time you can do this in lightning right now where- you can use this operation if we have the ability to do these additions and multiplication operations and the HTLC is perfectly randomized which you can't really get around unless you say 5 bitcoin pyaments and that's it.

And that's it.