Bitcoin Forum

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.

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.

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.

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.

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.

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.

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.

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

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

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.

If the wiki page (http://www.bitcoin.org/wiki/doku.php?id=script) 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.

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.

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.

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.

Their value is directly derived from the services offered on the "generalized proof-of-work (PoW)" chain.

And it is obviously quite trivial to set up a site that exchanges GenCoins for bitcoins.

In term of using the testcoins as an example of a parallel currency, about the only application I know of for using those coins would be to send and receive testcoins from the faucet.  That is useful in its own way, but other than simply for testing various kind of extreme concepts, it really isn't useful as a currency.  I would be curious what a testcoin to BTC exchange would do and what that exchange rate might be.  Then again, there might be some value in doing just that too.

The way I thought, you wouldn't be doing any real extra work to generate for the dependent chain. Your hashing is just for the main bitcoin chain. Once you generate a block there, you use that block private key to sign something that gives you the right to create a block on the dependent chain. There's no hashing for it.

You get the bitcoin reward for the block you produced in the main chain and only that, since you didn't do much more than that anyway.

Ah, I hadn't understand your question at first, now I see the problem.

Hum, you could try to make some sort of dependent transaction... Something that only gets accepted by the network after some other transaction takes place in the main chain...
Like, the generator adds a transaction, with a sort of message: only valid after bitcoin address A receives X bitcoins.... if the address never receives the money, a future block generator could add again the same transaction but asking less...

It would be better if there could be some sort of bargain between the sender of the transaction and the generator, but I can't see how.

It's not that simple. If an alternative chain provides, say, timestamping services, then there is obviously value to the users of the service. But what is the value to the generators? They earn coins, but may not themselves have any need for a timestamping service. So the proof-of-work coins that they earn are only valuable to them if they can use them more generally, like coins.

So we come to the next part of your comment:


Again, if the alternative coins have a low value, they're not much use to the person who generated them. And if they have a high value, they might replace bitcoin as the general currency. It doesn't work very well either way.

The value arises from the need of others to acquire GenCoins, in order to perform a DNS operation / publish some other data into the block chain.



Again, if the alternative coins have a low value, they're not much use to the person who generated them. And if they have a high value, they might replace bitcoin as the general currency. It doesn't work very well either way.
[/quote]

bitcoin's value proposition is simply in its fiat currency and decentralized nature.

GenCoins value would be in the data to which they are associated.

Two very different value propositions, reasons to hold them, and for that reason, two different market values.

The issue here is that these "GenCoins" would in effect have greater value as it is a superset of Bitcoin, because it can be used as the fiat currency and have value to the data itself as well.  Depending on very subtle differences and perhaps the effort put upon these "GenCoins", it may be possible that "GenCoins" would have greater value than Bitcoins, and certainly it is possible that in the long run such "GenCoins" might be able to attract more mining activity due to more sources of transaction fees, thus making these "GenCoins" a strong currency in terms of a strong block chain.

BTW, this is assuming that the "solution" here is to put all of this extra data as a fork of Bitcoins.  The reference earlier to the testcoins is not the same here as the testcoins have very limited utility and the total CPU mining effort on the testcoin chain is almost axiomatically never going to exceed that of the main Bitcoin chain.  As such they will remain substantially inferior to regular Bitcoins in value.  I can't say the same thing about these "GenCoins".

"greater", no, it would have a different value.

Keep it standard this is a currency system not something else, sure its cool when you find modifications of presidents on a 5 dollar bill, but is it worth raising the costs of sending money. Is one of the main points behind bitcoins that like cash its FREE to use and trade.

Actually, no. The home page of bitcoin.org contains these words, which are old enough that I think they were probably written by Satoshi: "Transactions are practically free..." (emphasis mine).

Transaction fees have been part of the design of Bitcoin since the beginning. Even so, regular everyday transactions are likely to remain practically free.

While you may not be aware of the costs involved, I can't think of a single monetary transaction that doesn't have some sort of costs of some sort or another, including pure cash transactions.  At the very least, a merchant has to account for "shrinkage" (typically shoplifting, but other forms of theft from the inventory too), counterfeit currency accidentally being accepted, embezzlement, and flat out theft of the cash register such as an armed robber.  A merchant makes up for all of that through expecting a higher profit margin when those costs start to mount, or they simply close up shop and leave.  Some inner city areas lack merchants precisely because the crime rate is so high they refuse to do business... and of course some silly "price gouging" legislation further mucks up the picture in those places too.  If you see a platoon of ex-marines patrolling a grocery store in order to keep the gang members from stealing things there including the cash register, expect to be paying $50 per orange or loaf of bread that you buy from that store.  That is a cash transaction fee.

Most people are completely unaware of fees that they pay with credit cards or other similar financial instruments, and in effect the "cash paying" customers are really paying a premium over those who pay with a credit card.

I am glad that the cost of a transaction is up front to everybody with Bitcoin, and I think that is a strong point to the currency.  If a "merchant" want to give a "rebate" to somebody for sending them some Bitcoins, that is their option and there might certainly be an incentive to do that in terms of paying for the transaction fees to process transactions in a timely fashion.  The amount paid for the fee would not be in dispute, and would be a part of the trust relationship between a merchant and their customer.

The one thing I'll say about Bitcoin is that its structure is such that transaction fees will always be cheaper than the major credit card agencies for a great many reasons I won't go into here.

Even cash is not free to use.  Even if your personal costs are very low with cash, as they are for most people, and you don't pay those fees to the person that you are doing business with, the costs of getting yourself to a brick-&-mortor store to buy with cash is a real cost to you.  For most people, such costs are detatched from the purchase, but if you have to take public transit to get to the store or if you have to take off work to make it before closing time, you will feel the transaction costs.

Likewise, cash in person transaction costs rise when it starts snowing.

Feel free to create your own network like bitcoin (which is the idea behind BitDNS) which allows for distributed storage.  Adding such features simply bog down the actual bitcoin network which is completely unnecessary. 

There are much better ways of achieving distributed storage than bitcoin.  There are, however, specific data that can idealy be stored in a proof-of-work system like bitcoin.  For example, DNS.  However, for the vast majority of distributed storage, please use google. 
That is a common misconception.  The price of bitcoin is loosely related to the cost of generating them, but that is in no way the only factor and currently, the price is far away from the cost most miners pay to generate them.

Again, common misconception.  There are many more factors.  Please read http://bitcointalk.org/index.php?topic=5320.0 (http://bitcointalk.org/index.php?topic=5320.0) and continue this part of the discussion there.  Also, please do not resurrect such an old thread.  Many people before you have made similar points and all of them have been considered.  If you want to have an argument about it, please start a new thread or comment on a newer thread which discusses this (there are several).  Also, please comment if you have new information instead of just rehashing old arguments.