3 ms·

Definitely opens the possibility of a Bitcoin-on-Bitcoin implementation.

thelastparadise 3y ago
What would be the point of that? With bitcoin blocks as slow and small as they are, which is a good thing for security and decentralization, implementing bitcoin on top of the bitcoin chain would just slow this down even more. Perhaps lightning is what you're thinking of.
- dartos 3y ago
  Why build anything-in-anything? It’s like a true classic computer science meme
pcdoodle 3y ago
As funny as this comment is, I really think the bitcoin blockchain is an implementation of a truth engine. It's currently a ledger for most people but you can be pretty damn sure what has been written 1 hour ago, is the absolute truth.
- MuffinFlavored 3y ago
  “you can be pretty damn sure that some JSON got POSTed with appropriate signatures/a hash reward attached to it to some nodes listening on a peer-to-peer network and propagated around”
  - dartos 3y ago
    The effect of which is, you can be preset damn sure that the JSON is the same as the last time it was looked at and the time after that etc… Not “truth” in the colloquial sense, which OP seemed to be implying, but not useless.
    - Y_Y 3y ago
      When old chips shall hash generation waste, Thou SHAlt remain, in midst of other woe Than ours, a friend to ape, to whom thou POST'st, "JSON is truth, truth JSON,"—that is all Ye know on chain, and all ye need to know.
treyd 3y ago
This is only true in a very loose and rather useless sense. This isn't because of some weakness of the BitVM construction, these are products of limitations of Bitcoin itself. As far as I understand, all possible settlement pathways have to be predetermined. They can't be chosen/constructed on the fly according to the circuit. It also has a pretty restrictive prover-verifier relationship. If the prover lies then the verifier can force a recovery pathway, but if the verifier fails to perform their duties then the prover can choose the settle the construction in any of the predetermined settlement pathways. The only ways that that would work would require some trusted third party to sign off on the other outcomes. They can also, of course, collude to settle the contract in any arbitrary way, meaning that the verifier has to be trusted by third parties. There's also no obvious way to chain instances of this construction in an arbitrary data-dependent way. There's also large communication costs, where two hashes have to be exchanged for each wire in the circuit, which adds up a lot when you'd want to do nontrivial circuits. Although I can imagine someone could invent some clever construction to deterministically generate wire commitments in a way that each party could agree on, but I'm not sure what it would look like though given the constraints Bitcoin has. So it's only possible to build a "Bitcoin-on-Bitcoin" with it if you don't care about moving funds between it and the host Bitcoin ledger or being able to be trusted by anyone other than the parties actively involved in executing the construction (like you could do with a rollup), which means it's useless as a thing to improve throughput. It states in the paper that a more practical construction should be used in a real use-case. I'm still a little bit fuzzy on the details so I might be slightly off here. It's a very cool construction, and it's pretty neat that it's doable on Bitcoin today without modifications to the core protocol. Bitcoin only needs a couple of very minor modifications in order to enable basically anything-on-Bitcoin, which I sketched out [1] a while back that got some attention and further work [2]. [1] https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html [2] https://bitcoinrollups.org/ https://bitcoinrollups.org/

What would be the point of that? With bitcoin blocks as slow and small as they are, which is a good thing for security and decentralization, implementing bitcoin on top of the bitcoin chain would just slow this down even more. Perhaps lightning is what you're thinking of.

dartos 3y ago
Why build anything-in-anything? It’s like a true classic computer science meme

pcdoodle 3y ago

As funny as this comment is, I really think the bitcoin blockchain is an implementation of a truth engine. It's currently a ledger for most people but you can be pretty damn sure what has been written 1 hour ago, is the absolute truth.

MuffinFlavored 3y ago
“you can be pretty damn sure that some JSON got POSTed with appropriate signatures/a hash reward attached to it to some nodes listening on a peer-to-peer network and propagated around”
- dartos 3y ago
  The effect of which is, you can be preset damn sure that the JSON is the same as the last time it was looked at and the time after that etc… Not “truth” in the colloquial sense, which OP seemed to be implying, but not useless.
  - Y_Y 3y ago
    When old chips shall hash generation waste, Thou SHAlt remain, in midst of other woe Than ours, a friend to ape, to whom thou POST'st, "JSON is truth, truth JSON,"—that is all Ye know on chain, and all ye need to know.

treyd 3y ago

This is only true in a very loose and rather useless sense. This isn't because of some weakness of the BitVM construction, these are products of limitations of Bitcoin itself. As far as I understand, all possible settlement pathways have to be predetermined. They can't be chosen/constructed on the fly according to the circuit. It also has a pretty restrictive prover-verifier relationship. If the prover lies then the verifier can force a recovery pathway, but if the verifier fails to perform their duties then the prover can choose the settle the construction in any of the predetermined settlement pathways. The only ways that that would work would require some trusted third party to sign off on the other outcomes. They can also, of course, collude to settle the contract in any arbitrary way, meaning that the verifier has to be trusted by third parties. There's also no obvious way to chain instances of this construction in an arbitrary data-dependent way. There's also large communication costs, where two hashes have to be exchanged for each wire in the circuit, which adds up a lot when you'd want to do nontrivial circuits. Although I can imagine someone could invent some clever construction to deterministically generate wire commitments in a way that each party could agree on, but I'm not sure what it would look like though given the constraints Bitcoin has. So it's only possible to build a "Bitcoin-on-Bitcoin" with it if you don't care about moving funds between it and the host Bitcoin ledger or being able to be trusted by anyone other than the parties actively involved in executing the construction (like you could do with a rollup), which means it's useless as a thing to improve throughput. It states in the paper that a more practical construction should be used in a real use-case. I'm still a little bit fuzzy on the details so I might be slightly off here. It's a very cool construction, and it's pretty neat that it's doable on Bitcoin today without modifications to the core protocol. Bitcoin only needs a couple of very minor modifications in order to enable basically anything-on-Bitcoin, which I sketched out [1] a while back that got some attention and further work [2]. [1] https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html [2] https://bitcoinrollups.org/ https://bitcoinrollups.org/