<blockquote>
<p><strong>why is there a possibility to ask for &quot;no keys at all&quot;?</strong></p>
</blockquote>
<p>The statement you quoted is about &quot;requiring no keys&quot; in the sense of not explicitly requiring the use of keys. The statement you quoted isn't about <em>asking</em> for keys. requiring and asking are different.</p>
<p>I suspect it isn't simple to specify a scripting language that allows for key based security but which prohibits scripts omitting any kind of key based security. The designer of the system used a scripting language to create flexibility for future innovation, not to suppress it.</p>
<p>Here's an extract from an early conversation between Gavin Andresen and Satoshi Nakamoto, the creator of Bitcoin and its initial scripting system.</p>
<p>Gavin Andresen June 17, 2010, 11:38:31 AM</p>
<blockquote>
<p>... First: it make me a little nervous that bitcoin has a scripting
language in it, even though it is a really simple scripting language
(no loops, no pointers, nothing but math and crypto). It makes me
nervous because it is more complicated, and complication is the enemy
of security. ...</p>
</blockquote>
<p>Satoshi Nakamoto replied</p>
<blockquote>
<p>The nature of Bitcoin is such that once version 0.1 was released, the
core design was set in stone for the rest of its lifetime. Because of
that, I wanted to design it to support every possible transaction type
I could think of. The problem was, each thing required special support
code and data fields whether it was used or not, and only covered one
special case at a time. It would have been an explosion of special
cases. The solution was script, which generalizes the problem so
transacting parties can describe their transaction as a predicate that
the node network evaluates. The nodes only need to understand the
transaction to the extent of evaluating whether the sender’s
conditions are met.</p>
<p>The script is actually a predicate. It’s just an equation that
evaluates to true or false. Predicate is a long and unfamiliar word so
I called it script.</p>
<p>The receiver of a payment does a template match on the script.
Currently, receivers only accept two templates: direct payment and
bitcoin address. Future versions can add templates for more
transaction types and nodes running that version or higher will be
able to receive them. All versions of nodes in the network can verify
and process any new transactions into blocks, even though they may not
know how to read them. The design supports a tremendous variety of
possible transaction types that I designed years ago. Escrow
transactions, bonded contracts, third party arbitration, multi-party
signature, etc. If Bitcoin catches on in a big way, these are things
we’ll want to explore in the future, but they all had to be designed
at the beginning to make sure they would be possible later.</p>
</blockquote>

CC BY-SA 4.0
2024-08-28T09:17:58.943Z
2024-08-28T09:29:07.963Z
2024-08-28T09:29:07.963Z
RedGrittyBrick
<p>From <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Script</a> :
&quot;Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several keys, or even no keys at all.&quot;</p>
<p>I'm wondering if there is a &quot;good&quot; reason to provide that &quot;flexibility&quot;. Foremost why is there a possibility to ask for &quot;no keys at all&quot;?</p>
<p>I want to apologize if I'm misunderstanding something here or if I'm unaware or naive or &quot;sounding&quot; cryptic and for my bad english.</p>

<transactions><security><private-key><script>
Is there a good intend behind the scripting system bitcoin uses for transactions?
Marstechnisch
# Is there a good intend behind the scripting system bitcoin uses for transactions?

(Asked by: username_0 on 2024-08-26)

From <https://en.bitcoin.it/wiki/Script> :
"Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several keys, or even no keys at all."

I'm wondering if there is a "good" reason to provide that "flexibility". Foremost why is there a possibility to ask for "no keys at all"?

I want to apologize if I'm misunderstanding something here or if I'm unaware or naive or "sounding" cryptic and for my bad english.

**Tags:** transactions, security, private-key, script


---

## 1 answers

### Answer by username_1 on 2024-08-28. Score: 3

> **why is there a possibility to ask for "no keys at all"?**

The statement you quoted is about "requiring no keys" in the sense of not explicitly requiring the use of keys. The statement you quoted isn't about *asking* for keys. requiring and asking are different.

I suspect it isn't simple to specify a scripting language that allows for key based security but which prohibits scripts omitting any kind of key based security. The designer of the system used a scripting language to create flexibility for future innovation, not to suppress it.

Here's an extract from an early conversation between Gavin Andresen and Satoshi Nakamoto, the creator of Bitcoin and its initial scripting system.

Gavin Andresen June 17, 2010, 11:38:31 AM

> ... First: it make me a little nervous that bitcoin has a scripting
> language in it, even though it is a really simple scripting language
> (no loops, no pointers, nothing but math and crypto). It makes me
> nervous because it is more complicated, and complication is the enemy
> of security. ...

Satoshi Nakamoto replied

> The nature of Bitcoin is such that once version 0.1 was released, the
> core design was set in stone for the rest of its lifetime. Because of
> that, I wanted to design it to support every possible transaction type
> I could think of. The problem was, each thing required special support
> code and data fields whether it was used or not, and only covered one
> special case at a time. It would have been an explosion of special
> cases. The solution was script, which generalizes the problem so
> transacting parties can describe their transaction as a predicate that
> the node network evaluates. The nodes only need to understand the
> transaction to the extent of evaluating whether the sender’s
> conditions are met.
>
> The script is actually a predicate. It’s just an equation that
> evaluates to true or false. Predicate is a long and unfamiliar word so
> I called it script.
>
> The receiver of a payment does a template match on the script.
> Currently, receivers only accept two templates: direct payment and
> bitcoin address. Future versions can add templates for more
> transaction types and nodes running that version or higher will be
> able to receive them. All versions of nodes in the network can verify
> and process any new transactions into blocks, even though they may not
> know how to read them. The design supports a tremendous variety of
> possible transaction types that I designed years ago. Escrow
> transactions, bonded contracts, third party arbitration, multi-party
> signature, etc. If Bitcoin catches on in a big way, these are things
> we’ll want to explore in the future, but they all had to be designed
> at the beginning to make sure they would be possible later.


---

