Topic: svn r197: IsStandard check for transactions - page 2. (Read 5309 times)

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.

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.

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

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

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.

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

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.

That sounds like a great idea.

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.

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.

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.

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

Let's allow transactions with a single " 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.

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.

What's a non-standard transaction?

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.