Version 0.3.18
Quote from: Hal on December 05, 2010, 02:22:21 AM
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.
Quote from: Hal on December 05, 2010, 11:43:56 PM
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 ”
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/
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.
Quote from: nanotube on December 09, 2010, 06:19:05 AM
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”
Quote from: da2ce7 on December 09, 2010, 10:07:38 AM
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:
Quote from: Hal on December 05, 2010, 11:43:56 PM
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.
Quote from: chaord on December 09, 2010, 07:17:12 AM
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.
Quote from: nanotube on December 09, 2010, 06:19:05 AM
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.
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.