shilch

Here you go: https://shilch.me/bitcoin-turing-complete/

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

> because bitcoin script is not turing-complete

This is not what the article claims to show. It shows that the system bitcoin is turing complete.

Added to this, having an "external driver" and the system being turing-complete are not mutually exclusive.

The proof in the article is not about unrolling.

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.

Like computer scientist, they think binary: Either it's secure, or it's not. In reality there's a spectrum where you also have "good enough".

Clang also does some crazy-good SIMD optimizations if you set -march=native. But I think the Rust compiler is based on LLVM as well, right?

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

[1] https://bitco.in/bitcoin.pdf

[2] https://nakamotostudies.org/literature/ecash/

[3] https://nchain.com/en/blog/bitcoin-network-topology-small-wo...

I'm not all too familiar with the history of IP and TCP but my point still stands. Protocols aren't build because the underlying protocol doesn't scale in term of throughput, it's for the opposite reason that they scale very well. I could also have used HTTP and TCP.

TCP wasn't build on IP because it wasn't scalable. It was build on it because it was. But that aside, calling Lightning on BTC a second-layer is a bit misleading: Lightning data is not encapsulated in BTC data, more like the other way around; so Lightning is more like layer 0 and BTC layer 1 in that model. (That's also not entirely correct either but much closer)

> Do you mean "the GUI shows 0-conf transactions as pending?

It's not just GUI but also a miner policy which can break the use of BTC as cash - as it was originally intended.

> And why does adding Segwit make it "not bitcoin anymore"?

It's an ugly addition to the original protocol that among others breaks the definition of a coin as a chain of digital signatures. This might lead to legal issues as some people (including lawyers) pointed out.

BTC hard forked twice (or thrice if you count the one accidental hard fork) and soft forked a dozens of times. Claiming that BTC is the "main chain" is misleading. The main chain is dead for years; run the original bitcoin client, it won't sync up.

It uses the Bitcoin protocol and operates on the Bitcoin SV network (notice the space) by default.

It uses "Bitcoin" to refer to the protocol, not the BTC network. People fought about the name "Bitcoin" for ages and everybody has their own opinion about this topic. The network that you refer to as Bitcoin has forked several times as well and least resembles the original protocol and idea when compared to BCH or BSV. OTOH the market values it the highest.

> Someone created a block chain and network for mass data storage.

I don't like the phrase of storing data on the chain. The blockchain is not a storage medium but a network that incentivised connectivity and data propagation.

In theory it could work on BTC or BCH. Bottle relies on large OP_RETURN which is a miner-adjustable limit, not consensus. But in practice you (1) would need to find a miner to do this. (2) could only put in 1MB of data on BTC. (3) would have to pay a lot of satoshis (as you pointed out).

It's all about the incentives. What is the incentive in IPFS to keep data? If offering it to clients earns you money, what is the incentive to distribute it to competing peers? The blockchain is the solution: A miner must distribute the data in order to claim the block reward (subsidy + fees). Nodes can prune/drop any data they don't care about. You'll end up with specialised and competing nodes where each node only stores a subset of the data - some data might even be completely deleted or only available in archives if it has too little value.

Good summary.

> Bitcoin developers later introduced opcode "OP_RETURN", which is seen as a standard and less-evil way to post data.

This is not true and an error in the Mastering Bitcoin book. OP_RETURN was introduced by Satoshi in the very first version of bitcoin.

> Typically, nobody can afford to store more than a few hundred bytes.

This depends on the artificial constraints put on the network. Bottle operates on top of BSV which comes without a cap on supply and offers cheaper fees when compared to BTC.

I guess the word "Bitcoin" used here refers to the protocol that the browser builds on, and not the chain commonly known as Bitcoin which has BTC as base asset. Bottle is not limited to BSV but could as well be run on other chains implementing the Bitcoin core protocol such as BTC, BCH, LTC and Doge.