waxwing on Nostr: So I spent some time this morning reading the ColliderScript paper. A lot of very ...
So I spent some time this morning reading the ColliderScript paper. A lot of very clever ideas in there. If nothing else, understanding the concept that "Bitcoin Script" is really kind of two (both very limited) scripting languages, kind of obvious in retrospect (and yes I know BitVM people were thinking like this quite a lot already), but a really useful mental model. The core idea of ColliderScript is to bridge the gap between the two and the way proposed to do it is .. well let's just call it "audacious". The idea that: an n-way collision's difficulty scales exponentially with n, and that therefore a 3-way collision is sufficiently harder than a 2-way, that you can base the security of a system on that difference - despite the fact that it's well known that merkle-damgard type hashes do *not* have this property for chosen messages - but that you can use it here because inputs cannot be chosen (signatures can't be chosen) - is, yes, I'll repeat myself and call it audacious :)
Even more, the fact that, for very practical reasons, SHA1 (and RIPEMD) are chosen for this task despite it having been broken over the last 20 years, is also audacious ... honestly if there was one reason I would not want to use this idea, it would be that (and yes, needing some kind of hardware acceleration to actually spend a covenant also seems wildly impractical, so you could reject the idea for that reason - but I do buy the argument that these things can be dramatically improved). But using a broken hash in such an aggressive way seems a bit much.
I want to caution anyone reading this that this is only a general, fairly superficial assessment ... I doubt this will end up being used but it is very clever. Moreover it should give you a hint about the direction research is going - there is a desire to find a way to use tapscript to embed, in particular, ZKP verification inside bitcoin transactions. The STARK people in particular are pushing this afaik but plenty of other people (including me btw!) want to find a way to do that. To repeat a point I've made before: we don't want this for jpegs or random gambling stuff - we want it because it's the *most* realistic way bitcoin scales as a usable form of money to the entire planet rather than just 50M users or so.
Even more, the fact that, for very practical reasons, SHA1 (and RIPEMD) are chosen for this task despite it having been broken over the last 20 years, is also audacious ... honestly if there was one reason I would not want to use this idea, it would be that (and yes, needing some kind of hardware acceleration to actually spend a covenant also seems wildly impractical, so you could reject the idea for that reason - but I do buy the argument that these things can be dramatically improved). But using a broken hash in such an aggressive way seems a bit much.
I want to caution anyone reading this that this is only a general, fairly superficial assessment ... I doubt this will end up being used but it is very clever. Moreover it should give you a hint about the direction research is going - there is a desire to find a way to use tapscript to embed, in particular, ZKP verification inside bitcoin transactions. The STARK people in particular are pushing this afaik but plenty of other people (including me btw!) want to find a way to do that. To repeat a point I've made before: we don't want this for jpegs or random gambling stuff - we want it because it's the *most* realistic way bitcoin scales as a usable form of money to the entire planet rather than just 50M users or so.