Bitcoin Forum
December 03, 2016, 12:42:13 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Reliance upon transactions .vs. reactions to incidents  (Read 998 times)
jetmine
Jr. Member
*
Offline Offline

Activity: 53


View Profile
July 14, 2011, 05:06:18 PM
 #1

Today I've learned how the transactions are encoded, which are actually scripts in a forth-like language.  The scripts are "executed" to validate the transactions.  The lack of tight regulation of how a "standard" transaction is to be encoded, allows for many different possible encodings (or forms of expressing) one and the same transaction.

The language is described here: https://en.bitcoin.it/wiki/Script and in fact near the bottom of the page is an interesting example of how to take advantage of the language to achieve a "non-standard" transaction (to a hidden receiver address).  The universal encoding by scripts potentially allows for many other cool features to be implemented.

However, I've also stumbled across a description of past incidents that required addressing by modifications to the client software. It's at https://en.bitcoin.it/wiki/Incidents and most notable is the last paragraph talking about LSHIFT and RETURN bugs.  Apparently, some script commands have been abused to induce errors into the clients.  As reaction, the commands have been disabled (instead of merely been fixed).  Moreso, many other "currently unused" commands have been disabled as well, "for security reasons".

I understand that script engines pose a security risk.

But there are two fundamental questions that immediately form in my mind.

1) If script engines are a security risk, then why is the majority of it still enabled even after reacting to the incident?  Wouldn't it be "safer" to enforce a fixed straight-forward encoding for every single desired form of transaction and do away with the scripts alltogether?  A smooth transition can be achieved easily (I can elaborate if desired).  It would make future incidents impossible, improving security of the software.

2) If on the other hand, scripting is desireable for the purpose of enabling non-standard ways of transacting to be supported by all clients, then it is already broken!  After all, a once "legal" scripting command like OP_XOR is "forbidden" today.  If I had implemented earlier something like "send to hidden receiver address" using OP_XOR, the transaction would not verify anymore in todays client.  It would stop at the illegal instruction, and ignore all further history of the coin (although previos versions of the same software would have accepted it!).

As a programmer, I cannot rely on using ANY scripting command, because I cannot know which may become disabled tomorrow.  Except maybe those which are generated by the majority of the clients in everyday transactions.  And even those could become invalid in the future (for example if scripts are being done away with).  The precedent is here already.

Therefore I ask:  How much can I rely on scripting?  Can I trust that any command that I use in a confirmed transaction, will not be blacklisted in the future?

I also ask:  Can the receiver of my bits rely on my cleverly scripted transaction to be un-revokable?  There's a spin on this, beware!  Let me give you an example.  Bitcoin buries transactions in the blockchain, making it harder to doublespend as time passes.  If I were malicious, I could find a new bug in a script command.  I could use the command to form a harmless transaction (not triggering the bug).  It would work fine in the existing clients and make it into the blockchain.  It would give ownership of my money to somebody else, and it would be confirmed after a certain time.  The receiver of the coin would believe that I cannot undo the transaction.  But possibly I can?   I could publish an evil exploit based on the command that I used in my transaction, and encourage the developpers to disable the command just like they disabled OP_XOR.  The new (fixed) clients would not be able to parse the transaction anymore.  The coin would fall back to me RETROACTIVELY, as I am the last legitimate owner (by the now changed rules).  The validity of the chain of transactions would break at my special script, and I could start a new valid branch by spending the coin again (using valid script commands).

I am aware that this is an example taken to the extreme, but it serves to show how either decisions about scripting security can have unexpected sideeffects.

Opinions on this post?  Or maybe even comments from those involved in the decision of disabling commands?
1480725733
Hero Member
*
Offline Offline

Posts: 1480725733

View Profile Personal Message (Offline)

Ignore
1480725733
Reply with quote  #2

1480725733
Report to moderator
1480725733
Hero Member
*
Offline Offline

Posts: 1480725733

View Profile Personal Message (Offline)

Ignore
1480725733
Reply with quote  #2

1480725733
Report to moderator
1480725733
Hero Member
*
Offline Offline

Posts: 1480725733

View Profile Personal Message (Offline)

Ignore
1480725733
Reply with quote  #2

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

Activity: 2492


View Profile
July 14, 2011, 07:30:20 PM
 #2

Script will never be changed in ways that cause many blocks to become invalid. If a script op needs to be disabled in the future and past transactions use it, the transactions will need to all be whitelisted.

But probably no more script ops will be disabled if there's any chance they can be fixed. Those ops that have been disabled were disabled when there was probably less than a thousand Bitcoin users. It was safer at that time.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2016



View Profile
July 14, 2011, 07:59:25 PM
 #3

1) If script engines are a security risk, then why is the majority of it still enabled even after reacting to the incident?  Wouldn't it be "safer" to enforce a fixed straight-forward encoding for every single desired form of transaction and do away with the scripts alltogether?  A smooth transition can be achieved easily (I can elaborate if desired).  It would make future incidents impossible, improving security of the software.

Because they can be made not a security risk by the construction of a proper testing framework which can validate them. Most of the opcodes can be exhaustively tested, except for the ones that do crypto operations because the input spaces are too big, and those can be exhaustively tested by converting them to dummy versions with smaller input spaces (e.g. all even valued sig inputs validate as passing, all false fail).

If/when someone does the work to create such a testing framework and uses it to validate the opcodes, I think that would be a good argument for re-enabling them.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!