Bitcoin Forum
April 17, 2021, 09:43:41 PM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: New "Tier Three" Programming Language: Minsc  (Read 188 times)
fillippone
Legendary
*
Offline Offline

Activity: 1036
Merit: 5322


Merit Rascal wannabe Merit Cycler


View Profile
August 18, 2020, 04:02:08 PM
Merited by Carlton Banks (2), Luigi21 (2), d5000 (1), JayJuanGee (1), ETFbitcoin (1), HeRetiK (1), Coin-1 (1), GazetaBitcoin (1)
 #1

Bitcoin Smart Contract have been a long overseen feature of the Bitcoin Protocol.
Apparently there is a new trend in research trying to reproduce the "smart contract friendly" ecosystem built on the Ethereum blockchain also on the Bitcoin Blockchain.

Miniscript and Simplictiy have been two steps (or, rather, two proposed steps) in this direction.
Now a third building block in this direction has been unveiled: Minsc.

Quote
A Miniscript-based scripting language for Bitcoin contracts
Minsc is a high-level scripting language for expressing Bitcoin Script spending conditions. It is based on the Miniscript Policy language, with additional features and syntactic sugar sprinkled on top, including variables, functions, infix notation, and more.


A piece on Coindesk came out a few days ago.

Writing Bitcoin Smart Contracts Is About to Get Easier With New Coding Language

Quote
It builds on top of Miniscript, taking advantage of its security properties but creating a language that is even easier for developers to read and think about than Miniscript.

“Minsc’s focus is on usability and making it easier to express, comprehend and reason about scripts, using a simple and familiar syntax. It adds additional convenience features and ‘syntactic sugar,'” Ivgi told CoinDesk.

“Syntactic sugar” is a programming term for adding into a language another easier, shortcut way of executing a task that is usually harder to write.

So Minsc doesn’t add anything new to Script, it just makes it easier to use.

“It doesn’t let you do anything that Miniscript doesn’t already, similarly to Miniscript itself in relation to Bitcoin Script,” Ivgi said.


I wasn't able to find more documentation.
Do you think is a valid proposal?
Do you know more?

Official Website: https://min.sc/
Github: https://github.com/shesek/minsc

1618695821
Hero Member
*
Offline Offline

Posts: 1618695821

View Profile Personal Message (Offline)

Ignore
1618695821
Reply with quote  #2

1618695821
Report to moderator
1618695821
Hero Member
*
Offline Offline

Posts: 1618695821

View Profile Personal Message (Offline)

Ignore
1618695821
Reply with quote  #2

1618695821
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
HeRetiK
Legendary
*
Offline Offline

Activity: 1792
Merit: 1490


the forkings will continue until morale improves


View Profile
August 18, 2020, 10:14:18 PM
Merited by fillippone (2)
 #2

Looks definitely more approachable and easier to digest than Miniscript, at least from my perspective. Actually Minsc looks like I'd imagine a language called Miniscript to look like and vice versa (especially vice versa) Grin

With Minsc compiling to an end result that is logically the same to using Miniscript / Bitcoin Script I don't see any downsides either.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1834
Merit: 2741


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
August 19, 2020, 12:45:01 PM
Merited by fillippone (2)
 #3

Looks very simple, even people who only use Python like me can understood it without sweat Smiley

Unless there's bug when translating minsc to bitcoin script, i don't see any downsides. I just hope newcomers don't copy-paste minsc code without good understanding of what it does.

bob123
Legendary
*
Offline Offline

Activity: 1512
Merit: 2327



View Profile WWW
August 19, 2020, 01:09:07 PM
Merited by fillippone (2)
 #4

I just hope newcomers don't copy-paste minsc code without good understanding of what it does.

That's pretty optimistic  Grin
I wouldn't count on that. But that's the problem with everything, not just bitcoin scripts.

People visiting URLs, downloading mail attachments, activating macros.. everything happens all the time. And copy/pasting bitcoin scripts probably will happen too.
But i guess it is easier to steal coins by telling the victim to download/execute something, so this shouldn't be a big issue ?

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1834
Merit: 2741


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
August 20, 2020, 11:33:59 AM
 #5

I just hope newcomers don't copy-paste minsc code without good understanding of what it does.

That's pretty optimistic  Grin
I wouldn't count on that. But that's the problem with everything, not just bitcoin scripts.

People visiting URLs, downloading mail attachments, activating macros.. everything happens all the time. And copy/pasting bitcoin scripts probably will happen too.
But i guess it is easier to steal coins by telling the victim to download/execute something, so this shouldn't be a big issue ?

I agree it won't be big issue, but usually when hard task become easier, people are more likely to be less careful. I only can hope those newcomers use testnet bitcoin.

GazetaBitcoin
Hero Member
*****
Offline Offline

Activity: 574
Merit: 1551


Vires in numeris


View Profile WWW
August 23, 2020, 06:22:16 AM
Merited by ETFbitcoin (1), HeRetiK (1)
 #6

Bitcoin Smart Contract have been a long overseen feature of the Bitcoin Protocol.
Apparently there is a new trend in research trying to reproduce the "smart contract friendly" ecosystem built on the Ethereum blockchain also on the Bitcoin Blockchain.

[...]

Do you know more?

I don't know if you read also a topic of mine on this matter - Why Bitcoin smart contracts are not developed?, where I was wondering why these contracts are not too popular, although Satoshi told Wei Dai 11.5 years ago that they are possible.

To my surprise (and others' as well), gmaxwell himself posted in my topic, this being the first time when I had the honor to see him writing in any of my topics. And he brought more light in this subject:

Bitcoin has smart contracts-- that is what script is.

This is why lightning can exist.

This is why escrow transactions exists (which weren't just proposed by satoshi, but are used by users!)

This is why multisig exists and is extremely widely used.

Bitcoin script is only less expressive than ethereum in there respect that access to transactions and the blockchain data is limited, that a few opcodes were disabled due to dos attacks and that there is a reasonable bound on execution resources.

The reason you may have an impression otherwise is a direct result of intentional fraud perpetuated by the creators of Ethereum, breathlessly hyping some "World Computer" nonsense early on to sucker people into buying coins from their 72 million coin (17 billion dollars at current prices) pre-mine.  Many of the things they marked (replacement for Facebook!) were obvious nonsense, and much of what wasn't nonsense was already possible in Bitcoin but their hype made it sound like it wasn't.

That said: every time you create a new smart contract what you are actually doing is creating a novel bespoke cryptosystem.  That should be ringing alarm bells for you because almost always when someone-- even an expert-- cooks up a new cryptosystem the result is broken from top to freeking bottom.  Creating secure cryptosystems is among the most challenging domains of engineering.

Ethereum throws up a javascript like interface to enable maximum YOLO by the people least familiar with infrastructure engineering, they don't give a damn about the resource impact and have utterly obliterated the scalability of their system through poor design decisions (as a result the minimum hardware to keep up with Ethereum while it's doing *fewer* transactions than bitcoin, is literally orders of magnitude more-- and as a result  most businesses blindly trust consensys or another third party to give them access to a node).

But ignoring all those constraints doesn't make easier to write _SAFE_ smart contracts: experience has show that over and over again virtually all smart contracts on ethereum are absurdly vulnerable.  A smart contract to enable multisig there (functionality that bitcoin had widely deployed half a decade earlier) written by the authors of one of the most popular ethereum nodes was destroyed by someone simply sending it a command to delete itself-- instantly destroying two hundred and eighty million dollars of other people's coins.

Worse, very few "smart contracts" in ethereum have any reason to exist at all.  The vast majority of them are completely controlled by the decisions of a key holder (or sometimes a multisig of key holders).  The only purpose those smart contracts exists is decentralization theatre-- where people engage in something which is an unambiguous violation of securities law (and usually an outright fraud too) but then pretend it's okay because they falsely claim it's totally trustless and decentralized. Outside of those the next most common are trivial automated ponzi schemes and the like.

On the rare event where people want to actually do something interesting and worthwhile that doesn't just reduce to hiding a trusted third party the astronomical resource costs of doing in inside the EVM directly make it infeasible-- even in an exploration beta-test sense-- and instead they need to convince the operators of ethereum to hardfork the network to embed their critical inner-loop functionality in ethereum as a "precompiled contract".

Of course, Bitcoin can also be extended with new logic and much more simply and compatibility because it doesn't need to be hardforked:  OP_CSV, CLTV, P2SH, and Taproot are all examples of this.  (in fact, Bitcoin could provide an entirely new virtual machine in a softfork).

The issue isn't environment specific either.   It turns out that creating a centralized service is a LOT easier than creating a decentralized autonomous one, and while there is an easy way to monetize a centralized service a truly decentralized autonomous service is almost impossible to monitize-- so it's difficult to justify paying for all that extra effort. ... this makes the actual demand for real smart contracts fairly low which is why you haven't seen more done there.

I'd love to see an interesting neutral database (e.g. not created by some breathless eth pumper) that attempts to catalogue actually useful and interesting ethereum smart contracts to the limited extent that they exist.  Some of them are likely possible in Bitcoin currently, others would be possible with the addition of an opcode here or there.   A number of years ago I assigned someone working for me at blockstream to conduct such a study-- hoping to mine it for useful operations, and they mostly came up empty. I'm fairly sure that this wouldn't be the same today.

One of the things bitcoin developers have struggled with when it comes to adding opcodes is that while there is a multitude of interesting things that could be added, it is exceptionally difficult to justify sticking something in the consensus rules under a conjectural "maybe this will be useful".  There is a *lot* of functionality there which is essentially never used already. But this creates a bit of a chicken and egg situation because there probably is functionality that could be easily added, which people would use if it existed, but people don't develop the uses because it isn't there already.

So that's why you see that taproot creates a massive efficiency and privacy improvement for various multisig schemes and for some things like lightning-- which already have widespread use but it doesn't do much for other kinds of usage: it just isn't clear what that other kind of usage would need but it's clear what would benefit existing and related uses.

Another factor is that when something is sufficiently developed, you call it what it is, not the underlying technology.  People call lightning, lightning, they don't call it smart contracts just like someone calls a chess engine a chess engine (or its name like, stockfish) rather than "artificial intelligence".  The generic names are reserved for vaporware and stuff that doesn't really work but you hope it will someday. Smiley

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!