svn r197: IsStandard check for transactions

[Gavin Andresen]

I just commited svn r197 (version 0.3.17.05); it is a "prevent possible security problems we haven't thought of" fix.

Before this change, you could compile your own version of bitcoin, create nonstandard transactions containing extra information or fancy new payment features, and all the official bitcoin clients on the network would happily include those transactions in the blocks they were generating and would relay them to their peers.

After this change, official bitcoin clients will not relay nonstandard transactions or include them in blocks that they create.  They will, however, still accept non-standard transactions that do manage to get included in a generated block.

So, what should you do if you had a fantastic scheme for doing something fabulous with bitcoin that relied on the ability to generate nonstandard transactions?

1. Implement your fantastic new features.
2. Run it on the testnet to test it out.  You can pretty easily generate blocks there, and, as said above, peers will accept your nonstandard transactions in blocks that you generate.
3. Convince the rest of us that your idea is great-- or, at least, convince a good percentage of the bitcoin-generating nodes that your idea is great.

[1713514232]

1713514232

[1713514232]

1713514232

[1713514232]

1713514232

[1713514232]

1713514232

[1713514232]

1713514232

[caveden]

What's a non-standard transaction?

[Gavin Andresen]

What's a non-standard transaction?

A transaction that is signed in a way that the standard bitcoin client doesn't understand.

For example, there's been some discussion in other threads about using OP_DROP to embed extra data in transactions; doing something like that would create non-standard transactions.

[theymos]

Let's allow transactions with a single "<constant> OP_DROP" to be included. The maximum 520 bytes that can be added with an OP_DROP is equivalent to just ~4 transactions, but it is enough to include hashes and other useful data.

[jgarzik]

Let's allow transactions with a single "<constant> OP_DROP" to be included. The maximum 520 bytes that can be added with an OP_DROP is equivalent to just ~4 transactions, but it is enough to include hashes and other useful data.

This will have the effect of raising the cost of bitcoin transactions for everyone.

[theymos]

This will have the effect of raising the cost of bitcoin transactions for everyone.

Why? If I am interested in hurting the network, I can more easily send some 0.01 transactions and never spend them.

OP_DROP transactions can be ineligible for free space in blocks.

[jgarzik]

This will have the effect of raising the cost of bitcoin transactions for everyone.

Why? If I am interested in hurting the network, I can more easily send some 0.01 transactions and never spend them.

OP_DROP transactions can be ineligible for free space in blocks.

It will raise costs because it will establish the precedent that the current bitcoin blockchain is simply a generic, pay-for-storage distributed database, where the payment (the currency) is tightly coupled with the storage.  That opens bitcoin up to a wide array of uses that seem likely to dwarf the bytes used for storing and using the bitcoin currency itself.

My strong preference is to move in the opposite direction:  drop scripts completely.  Admit that scripts are a mistake.  Sign simple transactions of in's and out's.  Rigorously standardize on a greatly simplified, basic functionality -- which is what we are doing, de facto, with changes like IsStandard.

bitcoin is not generalized distributed storage.

bitcoin is more likely to be successful if we do not try to cram all proof-of-work systems into the main block chain.

Satoshi has come up with something wonderful and useful: a distributed, cryptographically signed agreement protocol based on proof-of-work (PoW).  This excites the imagination with all the possibilities of non-currency projects that one could based on this PoW concept.

Satoshi has also spent a serious amount of time hammering out a decent first implementation of this proof-of-work system.  As a side effect, this implies that it is much easier to add Jeff Garzik's Proof Of Work Idea to the bitcoin codebase, than to create my own PoW system.

We must resist this temptation.  In order for this first, wonderful distributed currency experiment to be as successful as possible, it must not be larded down with exciting PoW ideas unrelated to digital cash.

Testnet has provided a clear example of how to start your own block chain.  So I suggest people take Linus Torvalds' advice:  forking is good.  Fork the project.  Fork your own block chain.  Call them DomainCredits.  If it's a good idea, surely there are miner "investors" who would be willing to back your new network with a few ATI HD 5970's to provide the nascent network the ability to resist early attacks.

What about a fork that permits OP_DROP style transactions of up to 64k?  You have a PoW-based distributed storage / distributed messaging network, that can pay for itself.  It sounds like a great idea to me... but it's not bitcoin, and that capability and others like it should not be shoehorned into the existing P2P network and "mainline" block chain.

[caveden]

I agree with jgarzik, the chain should not be used as storage.

If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain "dependent" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.

[davout]

I agree with jgarzik, the chain should not be used as storage.

If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain "dependent" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.

That sounds like a great idea.

[Hal]

jgarzik makes a good argument that the complexity of the scripting system is not being used and is unnecessary. Simple in/out transactions are all that are needed. I'm not convinced that there is anything that can be done with Bitcoin scripting that can't be done with a crypto layer on top of Bitcoin to share/split keys, etc.

Anyway fancy scripts won't be able to be used until everyone upgrades their clients, after this last change. All the future-proofing that the scripting was meant to enable is lost. So there's even less reason to keep it.

[zipslack]

I agree with jgarzik, the chain should not be used as storage.

Me too. But I'm not sure whether removing scripting support is a good idea.

[jgarzik]

I agree with jgarzik, the chain should not be used as storage.

Me too. But I'm not sure whether removing scripting support is a good idea.

Oh I agree that removing scripting is both a radical proposal, and probably not realistic due to backward compatibility.

Although I would support such a change, it was mainly to illustrate how little we use the script engine.  There have been so many limitations placed upon it for security / anti-spam / anti-bloat reasons in recent months that, IMO, if bitcoin were redesigned from scratch today, it might not have a script engine.

But don't let that distract from the main point:  we should avoid larding the block chain with non-currency data.

[jgarzik]

OP_DROP transactions can be ineligible for free space in blocks.

So OP_DROP transaction might require a fee....  which would elevate the priority of BitDNS transactions above normal currency transactions.  That's disappointing.

[galeru]

What's the point of a scripting engine if you're only able to have "standard" transactions?  Not really good for scripting.

[RHorning]

The only advantage I can see to having a script for authentication is mainly to allow for more complex "algorithms" to be employed for securing a transaction without having to change the protocol.  In other words, each person who is engaging in a transaction can choose their own security method (including no security at all) for conducting that transaction.  It also provides for adding new hashing algorithms which may be more secure than an SHA-256 hash (or double hash or whatever).  There are already two algorithms in the source code, and other algorithms certainly could be specified in a forward compatible manner.

If there is some reason for storing data related to Bitcion and , I think it ought to be put into the Merkle Tree hash of the block itself rather than into the transaction.  That still requires some sort of support from miners, even if the short term "proof of concept" is easiest to put the data into the transaction.

In that case, we perhaps could put into the protocol a method that would allow some "miscellaneous" data in the form of a hash that is limited in size and limited to just one of these "hashes" per transaction.  It would allow for inclusion of this information in such a way that doesn't overwhelm disc HD space or network bandwidth in terms of miners or those who want to keep this information out for the most part.  The data storage itself should not be done with Bitcoin, even if it is a hash reference to the data record.

[ribuck]

So OP_DROP transaction might require a fee...

If the wiki page is correct, data can be embedded into a transaction without using OP_DROP. A transaction is valid if "nothing in the script triggers failure, and the top stack item is true". Therefore the embedded data can just be left on the script stack. No need to drop it.

[RHorning]

So OP_DROP transaction might require a fee...

If the wiki page is correct, data can be embedded into a transaction without using OP_DROP. A transaction is valid if "nothing in the script triggers failure, and the top stack item is true". Therefore the embedded data can just be left on the script stack. No need to drop it.

You could also use OP_IF in some sort of "if block" that skips over irrelevant hash data important only to an "outside" consumer of the transaction data.  OP_DROP is merely one simple way to set this up as the notion of scripting allows for multiple ways to accomplish this task.  Furthermore, any sort of distinguishing between random "junk" data and some more complex algorithm to protect data is only going to obfuscate the junk as if it was real data.

Trying to come up with a schema that attempts to filter out random junk is only going to result in an arms race between those who want to put random data into Bitcoin transactions and those who are trying to get rid of that stuff.  At best all you can do is charge a transaction fee for long scripts... which is also already in the protocol and part of the standard Bitcoin client.  Otherwise what is needed is to get rid of the scripting entirely.... but you also lose a whole bunch of flexibility for transaction verification by doing that as well.  There are negative drawback to getting rid of the scripting system entirely.

[RHorning]

I agree with jgarzik, the chain should not be used as storage.

If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain "dependent" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.

I think I've asked this question a number of times getting the run around.  Perhaps I'll be more clear with this example as proposed by Caveden:

If you create this alternate "proof of work" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain?

If simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins.

[ribuck]

If you create this alternate "proof of work" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain?

If simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins.

I've struggled really hard to think of a way to do this too. If the work done in the alternate chain is to be paid in bitcoins, that payment must be made "outside the chain" with all the attendant bookkeeping, "old-school billing", and chasing-up that this entails.

The alternative is for the payment to be made in coins from the alternate system. Here there are two possibilities.

Either these coins won't be perceived as valuable, in which case they won't be of much use for payments. Or else, those alternate coins will gain value, and will be used for payment. In this case the risk to Bitcoin is that the alternate coins have enough added utility that they eclipse Bitcoin and become used as a general purpose digital currency.

Bitcoin is not yet entrenched enough as "first mover" to be immune from being displaced by a more economically-useful digital currency.

The final possibility seems to be to dispense with payments altogether. Everyone communally pays for the system through their generation activity, and there are no transaction fees. This might actually work for some applications that depend more on generation than on transfers.

[jgarzik]

I agree with jgarzik, the chain should not be used as storage.

If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain "dependent" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.

I think I've asked this question a number of times getting the run around.  Perhaps I'll be more clear with this example as proposed by Caveden:

If you create this alternate "proof of work" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain?

If simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins.

It becomes a parallel currency.  Hence "DomainCredits" or "GenCoins" or whatever.

Unrelated to this DNS project, you should expect many bitcoin clones to appear as time goes on, and people experiment.

We already have one parallel currency:  testcoins.