3 ms·
> But that should be all that is required to be added. If you're talking about SPV inclusion on another chain, wouldn't one also need to verify cumulative diff
by tromp 3y ago
> But that should be all that is required to be added.
If you're talking about SPV inclusion on another chain, wouldn't one also need to verify cumulative diff on that other chain (if PoW based) ?
- adastra22 3y agoYou can add and compare bignums in bitcoin script.
- tromp 3y agoVerifying cumulative diff requires verifying possibly thousands of headers (all those between peg out and peg in), which is a completely impractical amount of witness data for one script.
- adastra22 3y agoCommitting headers in Merkle tree form or skip lists allow for logarithmic reduction in that number, as was worked out in the (2014?) sidechains whitepaper. 10’s of headers would be doable.
- tromp 3y agoBeyond requiring intrusive changes to Bitcoin like header commitments, and still needing dozen-KB scripts for pegs, it also limits properties of the sidechain. For instance, if the latter wants to use a memory-hard PoW like Cuckoo Cycle, I don't see how Bitcoin script (which cannot even loop) could verify a cycle in a pseudorandom graph.
- adastra22 3y agoI could argue that there’s no reason for any proof of work other than sha256 as these side chains should be merge mining, but we’re way off in a tangent thread. The point is that smart contracts actually do something other than “authorize payment”, and fancy Schnorr signing modes don’t come close to replicating those capabilities. And so long as there is a need for a programmable verification architecture, Forth-like languages are prttty ideal.