Version 0.3.18

Ah, thanks. Is this just a UI issue with display of transactions, or do the clients not recognize the transfer of value at all? If that address 179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uB goes on to spend its value (supposing its client was patched to allow it), would the transaction be accepted as valid?

The client doesn’t know how to solve the transaction’s scriptPubKey. It can evaluate a complete scriptSig+scriptPubKey, but it can’t produce a matching scriptSig for a strange scriptPubKey because it doesn’t recognize the scriptPubKey’s template. A patched client can solve the transaction. An unpatched client won’t even recognize a non-standard transaction as its own when scanning the block chain.

If a client is sending strange transactions, then the receiving client also needs to be modified to receive them. If that’s the case, then there’s no problem.

I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.

The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file’s existence.

I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.

Interesting idea. You don’t need to convert it to an address — Bitcoin deals with plain hashes internally, so you can just use the hash output. (Of course, using an address makes it possible to use existing versions of Bitcoin as a generic timestamp server.)

It might be better for the network to use OP_DROP. It is provable that ” OP_DROP” is irrelevant information, so later versions of Bitcoin might allow people to delete that part of transactions to save space.

Changes:

• Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
• IsStandard() check to only include known transaction types in blocks
• Jgarzik’s optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin’s been working on (more details at http://bitcointalk.org/index.php?topic=1886.0).  

• getaccountaddress
• sendfrom
• move
• getbalance
• listtransactions

Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/

This is the first update to Bitcion that I’m not jumping on and grabbing right away, because I think the choice of checking transaction types in blocks is not necessarily a good thing… at least while the question is undecided in the community. It does impact the network but in a subtle and political way.

At the very least I wish that Satoshi would at least express his view on what he thinks about putting extra data into transactions beyond pure financial data into transactions, and I think this is only going to start an arms race for those who want to play with scripts and those who are trying to keep scripts “pure”. All that has happened here is to simply lay the gauntlet down to get past the “IsStandard()” check and find transactions which can pass that test but still contain other data.

At the very least I wish that Satoshi would at least express his view on what he thinks about putting extra data into transactions beyond pure financial data into transactions, and I think this is only going to start an arms race for those who want to play with scripts and those who are trying to keep scripts “pure”. All that has happened here is to simply lay the gauntlet down to get past the “IsStandard()” check and find transactions which can pass that test but still contain other data.

Yeah; it’s pretty pointless. Why on Earth would any miner adopt this change, when it means that they will be getting fewer transaction fees due to the lost non-standard transactions?

ArtForz (15+% of the network), tcatm (2Ghash/s), and doublec (pool maintainer) have stated that they will not use IsStandard. Non-standard transactions will therefore still be possible.

When I have time, I will produce a patch for Bitcoin that will remove all non-network-enforced restrictions on transactions, so that other miners can easily also be configured to include these transactions.

consider also that it’s possible to encode data into the bitcoin blockchain already, merely by specially crafting the transaction. (See the ‘first’ option on http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal#Overcoming_potential_resistance_bitcoin_developers.2Fcommunity ).

alternatively, only timestamping and proof of expense (i.e., a regular transaction with a fee) may be used, pushing off the actual data storage off to external service (see ‘third’ option, ibid.)

but why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power.

but why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power.

I personally agree with nanotube’s point here, especially in light of the fact that arbitrary data can already be disguised in standard transactions if a person is motivated enough. I have not looked at the source code, but from what I understand I think that a much more pleasant (politically and technically speaking) solution would be to:

by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?

I would like to hear why the above option was thrown out by the developers.

While I agree that bitcoin transactions themselves should be the primary use of the blockchain, a good currency need not ostracize itself either.

I propose a law:

“He who makes the chain, gets to decide what it looks like”

I propose a law:

“He who makes the chain, gets to decide what it looks like”

This could work combined with: “Everyone can choose to accept a block or discard it”

I don’t want everyone to be spammed by blocks full of junk, and prefer to try to nullify it by generating a competing block without including the junk. The junk will of course make it eventually, unless the majority of miners switch on their spam filters.

Well I spport Satoshi completely in this matter.

Leaving a possibility to store data in bitcoin chain is an accident waiting to happen. Just wait until somebody encodes kiddie porn into the chain - it would stay there forever. And the governments would have a perfect propaganda possibility for fighting it. “Normal” people won’t use bitcoin at all if it is associated with perverts, mafia, and financial scams.

New transaction templates can be added as needed.  Within a few days, there will be plenty of GPU power that accepts and works on it.  Network support will be thorough long before there’ll be enough clients who understand how to receive and interpret the new transaction.

Timestamp hashes are still already possible:

txin: 0.01
txout: 0.00  <appid, hash> OP_CHECKSIG
fee: 0.01

If there’s an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.

I like Hal Finney’s idea for user-friendly timestamping.  Convert the hash of a file to a bitcoin address and send 0.01 to it:

I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.

The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file’s existence.

I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.

by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?

I would like to hear why the above option was thrown out by the developers.

Several months ago, around the time when the 0.3.9 bugs were found, I privately told Satoshi that I thought whitelisting acceptable transaction types was a better way to go, rather than blacklisting transaction types that we find out cause problems.

The danger is similar websites that try to blacklist for a nice sampling of how creative hackers can be.

I haven’t asked Satoshi if the recent discussion of BitDNS putting extra data in the block chain swayed his opinion or if he woke up in the middle of the night and realized that a creative use of OP_SOMETHING might lead to an exploit. I don’t think it matters; I’m still convinced that whitelisting acceptable transaction types is the right thing to do.

As for “the above option was thrown out by the developers” — nothing has been thrown out! Again, I haven’t talked to Satoshi, but I’m open to the idea of a third ‘standard’ transaction type that includes extra, arbitrary data. Lets have that discussion, implement it on the -testnet, poke at it, try to imagine all the possible ways it can be misused, try to estimate the benefits and costs… and if there’s general consensus that it is a good idea, roll it into production.

I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.

why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?

That’s already possible.   OP_CHECKSIG.   can be 33 to 120 bytes.

I also support a third transaction type for timestamp hash sized arbitrary data.  There’s no point not having one since you can already do it anyway.  It would tell nodes they don’t need to bother to index it.

Just wait until somebody encodes kiddie porn into the chain - it would stay there forever.

It is impossible to completely prevent that kind of abuse unfortunately.

For example, someone could encode information in the decimal figures of amount sent, or in a “vanity plate” Bitcoin address.

Probably not practical for jpeg or mpeg files, but for other low-bandwidth “illegal data” such as Blu-Ray keys, this is bound to happen sooner or later.

Even “low bandwidth kiddie porn” could create big problems for us one day. All over the world, legislation is becoming more draconian every year and in some countries even the “wrong” kind of fiction and poetry is now considered kiddie porn by the courts and thus illegal.

I also support a third transaction type for timestamp hash sized arbitrary data. There’s no point not having one since you can already do it anyway. It would tell nodes they don’t need to bother to index it.

Yes it is possible already. But it is disappointing to encourage main bitcoin chain to be used for generic data storage.

When a large amount of users are non-currency data users, currency users will face longer delays, higher costs, and decreased ability to send free transactions. Currency users will be discouraged by these factors from using bitcoin.

All these folks talking about the glory of the free market conveniently omit that there only one, monopolized market right now — the mainline chain. This implies decreased competition versus many markets (==many chains) and tragedy of the commons, as everybody shoves all their data onto the main chain.

An alternate chain that encourages data storage would better serve data users, leaving the main chain to better serve currency users.

Quote from: ShadowOfHarbringer on December 09, 2010, 1:51:20 PM UTC

Just wait until somebody encodes kiddie porn into the chain - it would stay there forever.

It is impossible to completely prevent that kind of abuse unfortunately. For example, someone could encode information in the decimal figures of amount sent, or in a “vanity plate” Bitcoin address.

Of course, but that is not my point. The point is that if would possible to store extra data in Bitcoin protocol by design, then government would have the argument like “you can store extra data (including kiddie porn) - protocol is designed that way and default client allows it”.

Taking this possibility away in the default client takes that argument away and makes Bitcoin much more resistant to kiddie-porn-propaganda-attack.

New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough long before there’ll be enough clients who understand how to receive and interpret the new transaction.

I agree with the whitelisting, this allows the generators to be more discerning in what they accept or reject. That said, as soon as the template for a good BitDNS implementation is released, I’ll be sure to add it to my generators whitelist.

Quote from: satoshi on December 09, 2010, 3:17:53 PM UTC

I also support a third transaction type for timestamp hash sized arbitrary data. There’s no point not having one since you can already do it anyway. It would tell nodes they don’t need to bother to index it.

Yes it is possible already. But it is disappointing to encourage main bitcoin chain to be used for generic data storage.

When a large amount of users are non-currency data users, currency users will face longer delays, higher costs, and decreased ability to send free transactions. Currency users will be discouraged by these factors from using bitcoin.

All these folks talking about the glory of the free market conveniently omit that there only one, monopolized market right now — the mainline chain. This implies decreased competition versus many markets (==many chains) and tragedy of the commons, as everybody shoves all their data onto the main chain.

An alternate chain that encourages data storage would better serve data users, leaving the main chain to better serve currency users.

Concerning using bitcoins as timestamps…

Right now gold can be mined and used as a currency. You can also you gold to make jewelry, build circuit boards, etc., because it has special properties. Therefore, gold has more than one purpose which increases its value. As of now most people believe that bitcoin can only be used as a currency. If people start using bitcoins to timestamp their work, then every bitcoin actually has more intrinsic value because it has more than one purpose! A bitcoin is actually not only useful as a currency but it has the ability to timestamp. If someone could use this special bitcoin property similarly to how scientists used the conductive properties of gold, then bitcoins could takeoff in a different tangent which could further increase its value. Is there a breakthough application waiting to be discovered using the timestamp property out there???