<p>This is an imperfect answer but in the absence of anything else here are a couple of resources.</p>
<p>I'm not sure if this is what you are looking for but there is a 2013 <a href="https://github.com/ephsec/svforth/blob/master/doc/svforth.md" rel="nofollow noreferrer">research paper</a> &quot;SVFORTH - A Forth for Security Analysis and Visualization&quot; (Wes Brown). It discusses a Forth language environment written in JavaScript with primitives and functions that make it useful for security visualization and analysis work.</p>
<p>On the influence of Forth on Bitcoin Script, Andrew Poelstra discussed this during his <a href="https://btctranscripts.com/london-bitcoin-devs/2020-02-04-andrew-poelstra-miniscript/#miniscript" rel="nofollow noreferrer">talk</a> on Miniscript at London Bitcoin Devs in February 2020.</p>
<blockquote>
<p>Q - Last question on script. It is very hard to judge Satoshi ten
years on. There’s a lot of subtle complexity here. Do you honestly
think back in Satoshi’s time, 2009 that you’d have had the perspective
to design a better language?</p>
<p>A - The question is in 2009 could I have done better? Or could we have
expected Satoshi to have done better? Essentially no. There are a
couple of minor things that I think could’ve have been done better
with a bit of forethought. For some historical context the original
Bitcoin script was never used. It was this idea for this smart
contracting system and smart contracting was something in blog posts
by Wei Dai, Nick Szabo and Hal and a few other people. It was this
vague idea that you could have programmable money. Script was created
with the intention that you be able to do that. Basically it was a
copy of Forth, it actually had way more of the Forth language than we
have today. We had all the mathematical opcodes and we had a bunch of
other weird stuff. There was also this half baked idea for delegation
where the idea was that your script is a script you execute but also
the witness is a script that you execute. The way that you verify is
you run both scripts in a row and if the final result is true you’re
good, if the final result is false…. The idea is that your
scriptPubKey which is committed to the coins should check that the
earlier script didn’t do anything bad. There were a couple of serious
issues with these, two that I will highlight. One was there was an
opcode called OP_VER, OP version. I can see some grimaces. It would
push the client version onto the stack. This meant that when you
upgraded Bitcoin say from 0.1 to 0.2, that’s a hard fork. Now script
will execute OP_VER and push 0.1 onto the stack for some people and
0.2 onto the stack for other people. You’ve forked your chain. Fortunately nobody ever used this opcode which is good. Another issue
was the original OP_RETURN. Rather than failing the script like it
does now it would pass the script. Because we had this two script
execution model you could stick an OP_RETURN in what’s called your
script signature. It would run and you wouldn’t even get to the
scriptPubKey. It would just immediately pass. You could take any coins
whatsoever just by sticking an OP_RETURN into your scriptSig. Bitcoin
was launched in the beginning of 2009. This was reported privately to
Satoshi and Gavin in the summer of 2010. This was 18 months of you
being able to take every single coin from Bitcoin. In a sketchy commit
that was labelled as being like a Makefile cleanup or something,
Satoshi completely overhauled the script system. He did a couple of
interesting things here. One was he fixed the OP_RETURN bug. I think
he got rid of OP_VER a little bit earlier than that. Another was he
added all the NO_OP opcodes. Around this time if you guys are
BitcoinTalk archivists you’ll notice that talk of soft forks and hard
forks first appeared around this time. It would appear forensically
that around this script update, the one that fixed OP_RETURN was the
first time that people really thought in terms of what changes would
cause the network to fork. Before that nobody was really thinking
about this as an attack vector, the idea that different client
versions might fork off each other. Either explicitly or because there
is different script behavior. And so the NOP opcodes or the NO_OPs
were added as a way to add updates later in the form of a soft fork.
The fact that this happened at the same time as the OP_RETURN fix is I
think historically very interesting. I think it reflects a big leap
forward in our understanding of how to develop consensus systems.
Knowing that historic context the original question was in 2009 could
we have done better? The answer is no basically. Our ideas about what
script systems should look like and what blockchains should look like
and the difficulty of consensus systems, nobody had any comprehension
of this whatsoever. The fact that there were bugs that let you steal
all the coins for over a year tells you that no one was even using
this, no one was even experimenting. It was just weird, obscure thing
that Satoshi put in there based on some Nick Szabo blog posts and
nobody had really tried to see if it would fulfill that vision or not.</p>
<p>Q - Did he literally copy something from Forth or did he reproduce it
selectively or precisely from a manual?</p>
<p>A - The question is did he literally copy from Forth. Or did he use a
manual? I don’t believe there is any actual code copying from any
Forth compiler or something like that. The reason I say that
everything is copied from Forth is a couple of specific things. The
specific things are the stack manipulation opcodes like the SWAP and
OP_ROTATE which rotates in a specific direction that isn’t useful for
Bitcoin but is probably useful in Forth. All of the stack manipulation
semantics seem to have come from Forth. These are just Forth opcodes
just reinterpreted in a Bitcoin context. Beyond that I don’t know
Forth well enough to say. There are a couple of specific things that
are really coincidental that suggest that he was using the Forth
language as a blueprint.</p>
<p>Q - He either copied something or he made something up. In the latter
case he must have thought about it?</p>
<p>A - The statement is either he copied something or made something up.
If he made something up he must have thought about it. I don’t think
that’s true. I think he made up a lot of stuff without thinking about
it.</p>
<p>Q - It accidentally worked?</p>
<p>A - That’s a very good point. Someone said it accidentally worked.
There are a lot of things in Bitcoin that accidentally work. There’s
pretty strong evidence that some amount of thought went into all of
this weird stuff. There are a lot of accidentally works here. There
are a lot of subtle bugs that turned out not to be serious but by all
rights they should’ve been. I don’t know what evidence to draw from
that. One idea is that Bitcoin was designed by a number of people
bouncing ideas off each other but the code has a pretty consistent
style or lack of style. It is all lost to time now.</p>
</blockquote>

CC BY-SA 4.0
2023-06-20T09:58:47.180Z
2023-06-20T09:58:47.180Z
Michael Folkson
<p>The <a href="https://en.bitcoin.it/wiki/Script" rel="noreferrer">&quot;Script&quot; system used by Bitcoin transactions</a> is commonly described as a <a href="https://en.wikipedia.org/wiki/Forth_(programming_language)" rel="noreferrer">Forth</a>-like, stack-based language.</p>
<p><strong>What prior work influenced the design and layout of the Script instruction set?</strong></p>
<p>There <a href="https://bitcoin.stackexchange.com/a/105781/5841">may have been a research paper or essay about a &quot;Security Forth&quot;</a> published in the early 2000s which shared unusual similarities with the Bitcoin instruction set. Though in recent years, <a href="https://bitcoin.stackexchange.com/questions/105778/why-were-op-reserved-op-reserved1-and-op-reserved2-originally-reserved#comment120158_105781">no one has been able to locate a copy of this work</a>.</p>
<p>What was the title of that work? Where was it published? Can anyone find a copy?</p>

<script><history><satoshi-nakamoto><academic-research><architecture>
What prior work influenced the design of the Bitcoin instruction set?
Jason Dreyzehner
# What prior work influenced the design of the Bitcoin instruction set?

(Asked by: username_0 on 2021-04-27)

The ["Script" system used by Bitcoin transactions](https://en.bitcoin.it/wiki/Script) is commonly described as a [Forth](https://en.wikipedia.org/wiki/Forth_(programming_language))-like, stack-based language.

**What prior work influenced the design and layout of the Script instruction set?**

There [may have been a research paper or essay about a "Security Forth"](https://bitcoin.stackexchange.com/a/105781/5841) published in the early 2000s which shared unusual similarities with the Bitcoin instruction set. Though in recent years, [no one has been able to locate a copy of this work](https://bitcoin.stackexchange.com/questions/105778/why-were-op-reserved-op-reserved1-and-op-reserved2-originally-reserved#comment120158_105781).

What was the title of that work? Where was it published? Can anyone find a copy?

**Tags:** script, history, satoshi-nakamoto, academic-research, architecture


---

## 1 answers

### Answer by username_1 on 2023-06-20. Score: 2 | Accepted answer

This is an imperfect answer but in the absence of anything else here are a couple of resources.

I'm not sure if this is what you are looking for but there is a 2013 [research paper](https://github.com/ephsec/svforth/blob/master/doc/svforth.md) "SVFORTH - A Forth for Security Analysis and Visualization" (Wes Brown). It discusses a Forth language environment written in JavaScript with primitives and functions that make it useful for security visualization and analysis work.

On the influence of Forth on Bitcoin Script, Andrew Poelstra discussed this during his [talk](https://btctranscripts.com/london-bitcoin-devs/2020-02-04-andrew-poelstra-miniscript/#miniscript) on Miniscript at London Bitcoin Devs in February 2020.

> Q - Last question on script. It is very hard to judge Satoshi ten
> years on. There’s a lot of subtle complexity here. Do you honestly
> think back in Satoshi’s time, 2009 that you’d have had the perspective
> to design a better language?
>
> A - The question is in 2009 could I have done better? Or could we have
> expected Satoshi to have done better? Essentially no. There are a
> couple of minor things that I think could’ve have been done better
> with a bit of forethought. For some historical context the original
> Bitcoin script was never used. It was this idea for this smart
> contracting system and smart contracting was something in blog posts
> by Wei Dai, Nick Szabo and Hal and a few other people. It was this
> vague idea that you could have programmable money. Script was created
> with the intention that you be able to do that. Basically it was a
> copy of Forth, it actually had way more of the Forth language than we
> have today. We had all the mathematical opcodes and we had a bunch of
> other weird stuff. There was also this half baked idea for delegation
> where the idea was that your script is a script you execute but also
> the witness is a script that you execute. The way that you verify is
> you run both scripts in a row and if the final result is true you’re
> good, if the final result is false…. The idea is that your
> scriptPubKey which is committed to the coins should check that the
> earlier script didn’t do anything bad. There were a couple of serious
> issues with these, two that I will highlight. One was there was an
> opcode called OP\_VER, OP version. I can see some grimaces. It would
> push the client version onto the stack. This meant that when you
> upgraded Bitcoin say from 0.1 to 0.2, that’s a hard fork. Now script
> will execute OP\_VER and push 0.1 onto the stack for some people and
> 0.2 onto the stack for other people. You’ve forked your chain. Fortunately nobody ever used this opcode which is good. Another issue
> was the original OP\_RETURN. Rather than failing the script like it
> does now it would pass the script. Because we had this two script
> execution model you could stick an OP\_RETURN in what’s called your
> script signature. It would run and you wouldn’t even get to the
> scriptPubKey. It would just immediately pass. You could take any coins
> whatsoever just by sticking an OP\_RETURN into your scriptSig. Bitcoin
> was launched in the beginning of 2009. This was reported privately to
> Satoshi and Gavin in the summer of 2010. This was 18 months of you
> being able to take every single coin from Bitcoin. In a sketchy commit
> that was labelled as being like a Makefile cleanup or something,
> Satoshi completely overhauled the script system. He did a couple of
> interesting things here. One was he fixed the OP\_RETURN bug. I think
> he got rid of OP\_VER a little bit earlier than that. Another was he
> added all the NO\_OP opcodes. Around this time if you guys are
> BitcoinTalk archivists you’ll notice that talk of soft forks and hard
> forks first appeared around this time. It would appear forensically
> that around this script update, the one that fixed OP\_RETURN was the
> first time that people really thought in terms of what changes would
> cause the network to fork. Before that nobody was really thinking
> about this as an attack vector, the idea that different client
> versions might fork off each other. Either explicitly or because there
> is different script behavior. And so the NOP opcodes or the NO\_OPs
> were added as a way to add updates later in the form of a soft fork.
> The fact that this happened at the same time as the OP\_RETURN fix is I
> think historically very interesting. I think it reflects a big leap
> forward in our understanding of how to develop consensus systems.
> Knowing that historic context the original question was in 2009 could
> we have done better? The answer is no basically. Our ideas about what
> script systems should look like and what blockchains should look like
> and the difficulty of consensus systems, nobody had any comprehension
> of this whatsoever. The fact that there were bugs that let you steal
> all the coins for over a year tells you that no one was even using
> this, no one was even experimenting. It was just weird, obscure thing
> that Satoshi put in there based on some Nick Szabo blog posts and
> nobody had really tried to see if it would fulfill that vision or not.
>
> Q - Did he literally copy something from Forth or did he reproduce it
> selectively or precisely from a manual?
>
> A - The question is did he literally copy from Forth. Or did he use a
> manual? I don’t believe there is any actual code copying from any
> Forth compiler or something like that. The reason I say that
> everything is copied from Forth is a couple of specific things. The
> specific things are the stack manipulation opcodes like the SWAP and
> OP\_ROTATE which rotates in a specific direction that isn’t useful for
> Bitcoin but is probably useful in Forth. All of the stack manipulation
> semantics seem to have come from Forth. These are just Forth opcodes
> just reinterpreted in a Bitcoin context. Beyond that I don’t know
> Forth well enough to say. There are a couple of specific things that
> are really coincidental that suggest that he was using the Forth
> language as a blueprint.
>
> Q - He either copied something or he made something up. In the latter
> case he must have thought about it?
>
> A - The statement is either he copied something or made something up.
> If he made something up he must have thought about it. I don’t think
> that’s true. I think he made up a lot of stuff without thinking about
> it.
>
> Q - It accidentally worked?
>
> A - That’s a very good point. Someone said it accidentally worked.
> There are a lot of things in Bitcoin that accidentally work. There’s
> pretty strong evidence that some amount of thought went into all of
> this weird stuff. There are a lot of accidentally works here. There
> are a lot of subtle bugs that turned out not to be serious but by all
> rights they should’ve been. I don’t know what evidence to draw from
> that. One idea is that Bitcoin was designed by a number of people
> bouncing ideas off each other but the code has a pretty consistent
> style or lack of style. It is all lost to time now.


---

