This is the paper detailing the research behind my talk "Optimizing
fee estimation via the mempool state" (the presentation only covers
part of the paper) at Scaling Stanford (this coming Sunday). Feedback
welcome.
https://bc-2.jp/mempool.pdf
___
bitcoin
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
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
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
(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
