I might write an article that explains it (if I find the time to do so). The thread form of back and forth is fruitless since it appears that we don't have a common understanding of what makes bitcoin turing complete.
Let me know how I can reach you back if I have written such article (and you're interested).
Whatever I read regarding "covenant" requires a protocol change. Independent of who described the underlying technique first, this doesn't invalidate the proof.
The loop unrolling is an implementation detail. As I have written somewhere else: You could as well have put a large if-else there to do the transition table lookup.
In the GoL example, one generation update is performed in every transaction. Since the board size is known in advance, it totally makes sense to unroll the loop. If you want to do boards larger than that, like the 1000x1000 you mention, you run into script limits. What you can then do instead is, for example, to update the first half of the board in one transaction and then the second half in another transaction, i.e. two transactions are one generation.
Bitcoin is turing complete as shown in this article.
This is not at all what this article describes. You're making the same mistake as truth_machine does: The loop unrolling is not part of the proof but just an implementation detail for the transition lookup; it could as well have been a large if-else. The actual looping / transitioning is implemented via bitcoin transactions which is a new technique that was only recently developed.
Then you either misunderstand or (intentionally?) misrepresent the article. The `loop` construct you're talking about has nothing to do with the author's proof, and neither does it "essentially use bitcoin blockchain as a database" as you have written somewhere else in the thread. For the interested reader, I have commented on these points where they were brought up.
To explain the Game of Life contract you're linking to: The `loop`, again, is just an implementation detail to go over each field on the board in a *single* transaction. It's not part of any proof. The actual turing-complete element - letting the GoL run - happens outside: Each generation state transfer happens via a bitcoin transaction.
In Ethereum, the caller specifies the gas amount beforehand to ensure that the execution finishes. In the presented bitcoin-based solution, the caller prepares the transactions beforehand that finish the execution; it then publishes the transactions.
> At this point, what is the benefit I am getting from having this "contract" at all? I would be better off with a just serializing the state of my machine and putting it into OP_RETURN, getting a much smaller blob to store on the chain.
> Article essentially uses bitcoin blockchain as a database
This is just plain wrong and not at all what this article is about. In the article, a script is developed that enforces state transfer by the specified transition table, i.e. only a specific set of bitcoin transactions are allowed on the state, namely the ones from the transition table.
I don't know what you're up to; your account is 30min old, was created just for commenting on this post, you appear to be very aware of this project and your comments show that you didn't understand the solution presented in the article.
I already commented on the parent comment: The `loop` in sCrypt is a compile-time loop and just an implementation detail for the lookup in the transition table. The *actual looping* happens outside via bitcoin transactions whereby each transaction is a transition in the TM.
https://news.ycombinator.com/item?id=28587465
These are two separate things.
The `loop` construction / function or whatever it is called in the sCrypt language is a compile-time loop. That is, the body gets unrolled N times (8 in this example). It's just an implementation detail for the lookup in the transition table.
However, that is not part of a proof. The author is pretty clear that each transition in the TM is implemented as a bitcoin transaction.
The presented solution does *not* loop inside bitcoin script itself, as you suggest, but outside whereby bitcoin transactions perform the state transfer. The machine runs for as long as someone pays for it (or it goes into accepting state) - which makes sense because if there was a one-time-fee for unbounded or potentially infinite runtime, you could create a program that never terminates. This can be compared to Ethereum where every step in execution costs fees and the caller needs to ensure that a sufficient amount of fees (gas) is paid.
I just wrote the comment and noticed that the scripting limits on BCH are actually a network rule and are not miner-configurable. So my statement that "it could also work on BCH if some default limits were lifted" is only correct in the sense that this number needs to be increased in a network upgrade: https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/blo...
> BSV and Bitcoin (BTC) are incompatible protocols
Both implementations have a large intersection. Dogecoin, Litecoin and Dash also use the bitcoin protocol and should also work.
> Sure, it can be added to BTC
The presented solution does not require a protocol change. BSV is essentially the original bitcoin protocol (with few small exception); nothing was added to the protocol to implement the turing machine. BTC has some of the scripting opcodes disabled but they can either be implemented using other opcodes (no change) or they could be reenabled as a new SegWit deployment (requires change). However, the issue you'll run into in practice is that the reference implementation (Bitcoin Core) has very small limits set and discourages scripting. You'll have to find a miner that mines the custom scripting transactions. And, well, fees are another issue.
I was aware of xhliu's work before. It's actually a big thing because Ethereum was created with the assumption that bitcoin's scripting language does not allow for state transfers (stateful contracts) and turing-complete computations.
The advantage over account-based systems like Ethereum is scalability: Ethereum contracts are one central entity identified by their address, any access on the contracts must be serialised which leads to scaling issues with popular contracts. Bitcoin's UTXO model on the other hand is rather easy to parallelize; but scalable UTXO-based contracts also require a different design.
The solution presented in the article uses the bitcoin protocol. BSV is just one implementation of that. It could also work on BCH if some default limits were lifted, and (theoretically, not economically) possible on BTC.
MacOS doesn't have jails as FreeBSD does. But they are using some kind of isolation for Mac applications, so they can not see data of other applications.
(A port of) Visual Studio Code is available for FreeBSD (using it myself); `pkg install vscode`.
If you would like to use docker, you could run a Linux distro in a virtual machine with docker daemon and configure your host docker command to use the daemon inside the VM. That's basically how docker works on macOS.
I don't think that "Peer-to-Peer" in the whitepaper's title ("Bitcoin: A Peer-to-Peer Electronic Cash System") refers to the network structure being p2p - and that's probably also not what most people mean when they talk about bitcoin being peer-to-peer. The very first sentence makes it pretty clear that peer-to-peer means person-to-person without any intermediary:
"A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution." [1]
Furthermore, the previous title was "Electronic Cash Without a Trusted Third Party" [2]. So reading "Peer-to-Peer" as "Person-to-Person" would mean that the title hasn't changed in meaning, it just became a bit more catchy.
Also, when analysing the incentives of participants in the bitcoin network, it turns out that network nodes do not actually form the ideal-typical p2p mesh network (where all nodes are equally distributed and connect to a few other nodes) but a more densely connected network where connectivity to mining nodes is strongly incentivised. This topic has been researched and discussed by Dr. Wright (See [3] for more information).