Re: [bitcoin-dev] Simplicity: An alternative to Script

I don’t think you need to set an order of operations, just treat the jet as TRUE, but don’t stop validation. Order of operations doesn’t matter. Either way it’ll execute both branches and terminate of the understood conditions don’t hold. But maybe I’m missing something here. > On Oct 31, 201

Re: [bitcoin-dev] Simplicity: An alternative to Script

That approach is worth considering. However there is a wrinkle that Simplicity's denotational semantics doesn't imply an order of operations. For example, if one half of a pair contains a assertion failure (fail-closed), and the other half contains a unknown jet (fail-open), then does the program

Re: [bitcoin-dev] Simplicity: An alternative to Script

Nit, but if you go down that specific path I would suggest making just the jet itself fail-open. That way you are not so limited in requiring validation of the full contract -- one party can verify simply that whatever condition they care about holds on reaching that part of the contract. E.g. mayb

Re: [bitcoin-dev] Simplicity: An alternative to Script

(sorry, I forgot to reply-all earlier) The very short answer to this question is that I plan on using Luke's fail-success-on-unknown-operation in Simplicity. This is something that isn't detailed at all in the paper. The plan is that discounted jets will be explicitly labeled as jets in the comm

Re: [bitcoin-dev] Simplicity: An alternative to Script

On Mon, Oct 30, 2017 at 9:42 PM, Matt Corallo via bitcoin-dev wrote: > I admittedly haven't had a chance to read the paper in full details, but I > was curious how you propose dealing with "jets" in something like Bitcoin. > AFAIU, other similar systems are left doing hard-forks to reduce the > si

Re: [bitcoin-dev] Simplicity: An alternative to Script

OK, fair enough, just wanted to make sure we were on the same page. "Thorny issues there and there hasn't been a ton of effort put into what Bitcoin integration and maintainability looks like" is a perfectly fair response :) Matt On 10/30/17 18:32, Mark Friedenbach wrote: > I was just making a fa

Re: [bitcoin-dev] Simplicity: An alternative to Script

I was just making a factual observation/correction. This is Russell’s project and I don’t want to speak for him. Personally I don’t think the particulars of bitcoin integration design space have been thoroughly explored enough to predict the exact approach that will be used. It is possible to s

Re: [bitcoin-dev] Simplicity: An alternative to Script

Are you anticipating it will be reasonably possible to execute more complicated things in interpreted form even after "jets" are put in place? If not its just a soft-fork to add new script operations and going through the effort of making them compatible with existing code and using a full 32 byte

Re: [bitcoin-dev] Simplicity: An alternative to Script

Script versions makes this no longer a hard-fork to do. The script version would implicitly encode which jets are optimized, and what their optimized cost is. > On Oct 30, 2017, at 2:42 PM, Matt Corallo via bitcoin-dev > wrote: > > I admittedly haven't had a chance to read the paper in full d

Re: [bitcoin-dev] Simplicity: An alternative to Script

I admittedly haven't had a chance to read the paper in full details, but I was curious how you propose dealing with "jets" in something like Bitcoin. AFAIU, other similar systems are left doing hard-forks to reduce the sigops/weight/fee-cost of transactions every time they want to add useful op

Re: [bitcoin-dev] Simplicity: An alternative to Script

So enthused that this is public now! Great work. Sent from my iPhone > On Oct 30, 2017, at 8:22 AM, Russell O'Connor via bitcoin-dev > wrote: > > I've been working on the design and implementation of an alternative to > Bitcoin Script, which I call Simplicity. Today, I am presenting my desi

[bitcoin-dev] Simplicity: An alternative to Script

I've been working on the design and implementation of an alternative to Bitcoin Script, which I call Simplicity. Today, I am presenting my design at the PLAS 2017 Workshop on Programming Languages and Analysis for Security. You find a copy of my Simplicity paper