This article goes off the rails for me with this statement:
> Their starting point was the observation that Ethereum "smart contract" execution is order-dependent within a block, unlike transaction execution in Bitcoin and similar systems: ...
First, Bitcoin runs smart contracts [1]. The lie to the contrary has seeped into almost every discussion of Bitcoin vs. Ethereum, and this author appears to have taken the bait.
Second, Bitcoin transactions are order-dependent within a block. The entire point of the Bitcoin network is to impose a global, unique order on all transactions and the only way to do that is if order within blocks matters.
I'm not sure about the rest of this article, but the failure on these two points does not inspire confidence to continue.
> Second, Bitcoin transactions are order-dependent within a block.
That's a little confused. Yes, bitcoin transactions are order dependent but only in the extremely narrow sense that a transactions can't double spend the same inputs and can't spend an output that hasn't been created yet.
Significant care has gone into assuring that bitcoin's script language remains a pure function of the transaction itself, so that all script validation can be performed once for a given transaction, can be performed with total parallelism with all other transactions, and isn't changed by adding/removing/reordering transactions. This means that any dependency between transactions must be explicit, by having the transactions consume outputs (which can be zero value) from the transactions they depend on.
Reordering transactions might change their validity due to input conflicts (which can be resolved very quickly using a hash table), but not due to the expensive-to-validate scripts in the transactions.
In ethereum contracts have fairly promiscuous access to shared data, including arbitrarily computed on the fly addresses. To discover a transactions dependencies you must execute it. One could imagine an implementation that executed all transactions eagerly in parallel, recorded a transcript of the data they touched, performed a union-find to cluster them, accepted one transaction from each disjoint cluster, then sequentially executed every remaining transaction (you can't execute the clusters in parallel, because their dependencies will change on re-execution with different state). ... but since dependencies are extremely common (people love to think sequentially, and the system makes that the easiest way to program) I expect that this would actually be a lot slower in practice in spite of the initial parallelism.
Aside, please don't link "bitcoinsv" -- it's a scam site setup by a conman that pretends to be Bitcoin's creator and uses billion dollar lawsuits to silence people who call out his fraud.
No, it's a mistake by me and should be changed [1]. The link I got was, strangely, the first for the search I ran. I was in a hurry and didn't double-check. BSV is a scam. It appears I can no longer edit the post. Oh well.
It's a low value Bitcoin fork from Craig Wright, a delusional dude who claims to be Satoshi, so he made a fork where he could control all the Satoshi coins. "SV" means "Satoshi's Vision".
It would be incredibly stressful for him to prove it, nay as much as he would like to be vindicated, the risk of the fame and the pressure blah blah blah.
Sorry I can't be bothered to look up the actual quotes but they're similarly incoherent. He pretends to have them but not to want to use them, even to prove his claims.
In conclusion, if he is unable to prove he is Satoshi, he therefore cannot claim to say he is Satoshi, unless he can prove otherwise; but so far he has not.
So hence the above unless proven, he is not Satoshi.
Not sure how many people share that "common definition". Most people I speak with day-to-day (who understands blockchain in the first place), would consider "programs stored on blockchain to run when conditions are met" as the most defining feature, and doesn't have to be turing complete for doing so.
Yes. I would have designed contracts as decision tables.[1] Those are not Turing-complete. They look more like spreadsheets. They have a finite number of cases and can be exhaustively tested.
Absolutely, Bitcoin smart contracts are different than Ethereum smart contracts. What's your point? Doesn't mean one has smart contracts and the other one doesn't.
Are you seriously going to grandstand whether the word "smart contract" can include non-turing-complete runtimes?
No, Bitcoin does not have smart contracts. It has a limited scripting environment that you can't do much with other than colored coins, and we've all seen how that's played out.
If they think that, they've been bamboozled by someone trying to sell them something: There is no useful smart contract that can't be expressed as statement in a total language. (as transactions that take an infinite or undecidable time to validate aren't useful)
Turing completeness is a complete red-hearing in this application space.
This is an honest question as I _really_ don't know the answer, but aren't bitcoin contracts technically white-listed? The opcodes exist, yes, but you can't just create a random contract and have it work?
They both have ridiculous issues that have made them both unsuitable for any form of serious application when scaled up to the tens of millions or even hundreds of millions. Even the very least of all use-cases: Extremely cheap, fast and scalable on-chain payment systems using a blockchain for regular users to use.
> The entire point of the Bitcoin network is to impose a global, unique order on all transactions and the only way to do that is if order within blocks matters.
Yes. The whole point of Bitcoin is to be a peer-to-peer electronic cash system using a transparent ledger where everyone can see the transactions on-chain. Not a 'store of value' or 'digital gold'.
Everyone knows on-chain payments with Bitcoin are too slow for realistically accepting payments in the real world and places like supermarkets, restaurants, etc unless you want to wait hours in the queue for it to settle or fail. Given it's even slower than VisaNet, you might as well go to the ATM and withdraw cash using card to pay; even that is quicker.
By that time, Bitcoin's volatility would already have caused the recipient to have a fluctuating price on the paid-for product, causing the sender to at worst under-pay for the value of their goods regardless. Using the Lightning Network also defeats the purpose of what Bitcoin was supposed to be as that is centralized by design and the transactions are off-chain without a trace anywhere to find it [0].
The whole point of Ethereum is to be the 'world's computer' and a smart contract platform with utility. Instead, it has turned into a digital slot machine with its problematic high fees when usage skyrockets and regular users that aren't millionaires can't use it at all, unless they'd like to spend $1000 to send $10. The network also can't even scale either so admittedly, users have to use duck-taped layer 2 systems that confuse them to even bother using them to save on fees.
Waiting years for ETH on PoS (ETH2) to launch isn't an option, as that was promised in 2016 to release by then, yet here we are 6 years later it's delayed once again. [1] No-one would tell users or even merchants to wait half a decade for a single product with years of known issues to get better in order to just use it. They will just look elsewhere instead.
The reality is, both of them have failed and deviated from their intended purpose and are not designed to scale for on-chain activities and both of them require 'layer 2' contraptions which at most are centralized themselves and highly complicate the usage for many users to even bother using it.
> Their starting point was the observation that Ethereum "smart contract" execution is order-dependent within a block, unlike transaction execution in Bitcoin and similar systems: ...
First, Bitcoin runs smart contracts [1]. The lie to the contrary has seeped into almost every discussion of Bitcoin vs. Ethereum, and this author appears to have taken the bait.
Second, Bitcoin transactions are order-dependent within a block. The entire point of the Bitcoin network is to impose a global, unique order on all transactions and the only way to do that is if order within blocks matters.
I'm not sure about the rest of this article, but the failure on these two points does not inspire confidence to continue.
[1] https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_...