Replying to Avatar Rusty Russell

#Bitcoin #dev #GSR

At https://btcplusplus.dev/ in Austin I presented my work on restoring Bitcoin Script. Script had an emergency amputation in 2010 as there were no limits on resource consumption; restoring it means solving this problem.

My proposal is a runtime limit, similar to Taproot's runtime sigops limit, called "varops". How much you get depends on your transaction size (ie how much you paid), similar to sigops.

But how much should operations cost? I had a cost model based on "worst-case bytes touched" for each operation. I've spent the last few weeks doing increasingly precise micro-benchmarks on my laptop, my build machine, and various Raspberry Pi.

There's bad news, and good news....

How will vbytes and varops interact? There were a lot of problems when we had both bytes and sigops, e.g. invalid block templates. Now, in taproot, we size transactions as max(vbytes, sigops*50 - 50). Which model will varops use?

Reply to this note

Please Login to reply.

Discussion

The lesson of sigops was exactly that limits should be based on weight, so you don't need to optimize for two different constraints on block construction.

Same deal here: more vbytes, more varops budget.