Subnostr

#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....

Reply to this note

Please Login to reply.

Discussion

David A. Harding 1y ago

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?

Rusty Russell 1y ago

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.

sudocarlos 1y ago

Did you publish your findings? Note: I'm a newb who doesn't read the mailing list, just wait for nostr:npub1hkuk45c6c6h3y0rks0z4wa0wyyud5ru0qy0rn9x4dgnjwrnfy46s5a432p

Gustavo 1y ago

Thank you for all your work. BTW, I use your "stats" helper tool a lot at work, that is a gem.