Simple, default, "hello world" smart contract for an auction? (winner wins, all the rest gets refunded) I recently read an article: https://medium.com/@jimmysong/the-truth-about-smart-contracts-ae825271811f


  Because of a lot of centralized marketing from Ethereum, there’s a mistaken belief that Smart Contracts only exist in Ethereum. This is not true. Bitcoin has had, from the very beginning in 2009, a pretty extensive smart contract language called Script.




If Bitcoin has smart contracts, I would like to see how to create a simple "hello world" auction - winner wins, those who didn't win get refunded.

(I've heard that RSK is EVM-compatible but that's more involved)
If Bitcoin has smart contracts, I would like to see how to create a simple "hello world" auction - winner wins, those who didn't win get refunded.


Your question isn't clear about the details of how you would expect this to work, so I'll start with some assumptions:


The seller has put something up for auction. There are two possibilities: the item being sold is a digital asset native to the Bitcoin chain, or it is not. 
The bidders are placing bids (assumedly using BTC, but any on-chain asset will do I suppose)
The 'auctioneer' that orchestrates all of this is some sort of 'smart contract', that sends the winning bid to the seller, the item sold to the winning bidder, and returns all other bids to the non-winning bidders, if necessary. 


So the 'auctioneer' must be some bitcoin script, that is capable of determining the result of the auction. Here we encounter a problem: Bitcoin script does not allow us to create a transaction which considers the status of other transactions in order to determine how the transaction being created can be spent. In other words, you can't use Bitcoin script to create some logic that says "after some time, forward the largest payment sent to auction_address on to seller_address, and return all other payments to back to the non-winning bidders".

The 'smart-contracting' capabilities of Bitcoin Script are intentionally limited, to quote the article you referenced: 


  Bitcoin’s solution to this problem is to simply not have Turing-completeness. This makes the contracts easier to analyze as the possible states of the program are easier to enumerate and examine.


All of that said, if we do not expect the entire logic of the auction to fit neatly into a single transaction's script, then we can perhaps use some more 'simple' constructions and protocols to accomplish our goal. For example, see this clever answer by Luke-jr. In this case there is no fancy smart-contract used, just financial incentives (to take the highest bid), coupled with consensus rules (a coin cannot be double-spent). This answer elaborates further on this type of construction.

More broadly, and as mentioned in the article you referenced, the oracle problem is a critical consideration: in order to participate in this auction, do you need to trust any third party? If the answer is yes, then it is prudent to consider if using a smart contract is a reasonable approach to solving your problem. For example, if the item up for auction is not a native digital asset, but is instead physically deliverable, then you need to trust the seller to deliver in any case! 



All this isn't to say that Bitcoin script can't be utilized to create a 'better auction experience'. For example, by using a multi-sig constructions, bidders and auction-houses could enjoy a more trust-minimized set up of certifying and transferring funds to be used in the auction. But 'smart contracts' don't just magically enable us to 'make everything trustless', and indeed in many cases such a thing isn't possible anyways. 

Additionally, it is possible to create a protocol that includes a Turing-complete language that runs on top of Bitcoin (eg the RSK EVM you mentioned), but this seems to be outside the scope of the question.