Re: Version 0.3.18

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 <script> tags in HTML entered by users to prevent cross-site-scripting hacks.  Seehttp://ha.ckers.org/xss.html 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
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.  <pubkey> OP_CHECKSIG.  <pubkey> 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.

6,898 total views, 7 views today

https://bitcointalk.org/index.php?topic=2162.msg28549#msg28549