Block hashes must start with a certain number of zeroes, and the first digits after the zeroes will also be non-random. Probably the bits at the end are random, though I would hash the hash to make sure.

Each bit of cryptographic hash output is supposed to (ideally) have an equal chance of being a 1 or a 0.

Features seem to be considered stable way too quickly. I'd like a version scheme like this:
- Add new features to 0.5.
- At some point, stop adding new features to 0.5 and call that the "unstable" release. Start adding new features to 0.6.
- 0.4 remains the "stable" release for at least 6 months, and it is recommend that newbies use this version. The unstable version is also available in binary form and can be easily used.
- Once 0.5 has been unstable for 6+ months, call that one stable.
- As many past 0.x releases as possible continue to get bugfixes for people who like to use really stable software.

I'm still using 0.3.19, and it works fine with only a few modifications. I avoided several bugs by doing this.

Once this problem is fixed, it would be a good idea to issue an alert for users of affected versions. Maybe not many users are affected, but it seems irresponsible to not notify these users when they can be notified.

Transaction hashes could be used if you have some secret data that you combine with the hash. Then the lottery manager can manipulate things, though.

Block hashes can be used for randomness pretty safely after you hash them again to remove the leading zeroes. If you have a lottery that pays out much more than the block reward you might want to combine the hashes of several consecutive blocks (and maybe also their Merkle roots), since miners could try "re-rolling" a few times.

Done. Topic starters can still lock their topics.

Auctions.

Here's PHP code I wrote to do address verification (and other things):
http://pastebin.com/vmRQC7ha

Bitcoin also has a validateaddress JSON command.

This is a good idea. I will create it later today.

I don't have a problem with alt accounts as long as they're not used to evade bans. Atlas is not banned.

This has been discussed a million times, and there are already a million different proposed URI protocols. Why is yours better?

I first found Bitcoin on 4chan, so I especially like 4chan.

You're not limited to text. You can easily include a direct link to an image, and readers can access the image with a single click. It's not a huge barrier.


With links instead of embedded images, readers will judge the worth of images before clicking on them.


Either the forum needs to check and recheck images constantly, which is expensive, or client-side code needs to be used to prevent large images, which might not work for all users. I don't find either of these solutions acceptable.


Obviously I was talking about the bandwidth of readers...


All major browsers will do something different when viewing pages with mixed content. On Firefox and recent versions of IE the URL bar changes color. On older versions of IE a dialog box popped up on every such page.


I know that my security concerns are justified.

A vote would determine only what the majority of current users want, which is not very important. It's easy for the majority to be wrong.


I like 4chan. On 4chan, every image is hosted locally, so there are no security problems, and each image is the same, small size until you click on it. I want to do the same thing here, but without the thumbnail (since this is not an imageboard and images are not the central focus).


I'm fine with that:

I'd add it now if I could figure out how to add a new user setting in a reasonable amount of time.


I'm getting rid of embedded images. Not images entirely. If you like images, you can click the image links. This works very well on IRC, 4chan, and the other sites/systems I mentioned previously.


It would be far down on my list of things to do, but I wouldn't be opposed to having the server fetch a small text file every once in a while to display in signatures/posts.


Like I said before, I think it's a better policy to assume that people don't want images. You can write a GreaseMonkey script to expand all directly-linked images in a few minutes, too.


Emoticons probably will be eliminated with the next software. Images in the layout will be reduced. The other things are used to attractively structure data and create features. Even Bitcoin Block Explorer uses CSS and JavaScript.

I find avatars to be useful in quickly identifying posters, so I'm almost never annoyed by those. You can also disable seeing them in your settings.

It is in the list, under optional features:

I'm not going to re-enable signature images again when it is planned to remove all embedded images in the future. There was only one complaint about that in the thread about forum software specifications. Why weren't you guys complaining when I posted that?

The advertising thing didn't even cross my mind as part of this decision. I don't receive any money from the forum, so I don't care that much about ad profitability...


I removed that image from gejix's signature when he had it there. He sometimes adds it to intersango-related posts, but it contains some semi-relevant text, so I usually don't want to remove it.



Ideas can be spread without annoying anyone by using text links in signatures. Or you can start a new topic about your idea.

Maybe viewing signatures as ad space explains many of the low-quality posts: people just want to put their signature "advertisements" on as many pages as possible.


My goal is to make the best Bitcoin forum possible, not to appeal to current users. I will of course consider all arguments against the policy.

These are not arguments of any kind...


SMF doesn't support this. If it did, I would definitely allow the option of showing signature images.


Then you'd still download the full image, which would waste bandwidth and still make users vulnerable to cookie stuffing attacks. The image would need to be completely removed or turned into a simple link.


Like I said, I'm sure it is possible to limit sizes technologically. That still leaves other problems.




The purpose of this forum is to provide a place where ideas can be expressed and consumed with as much freedom as possible. I have determined that the best way of facilitating this goal is to disallow embedded images.

Signature images are never useful in exchanging ideas. They never contribute anything to the discussion at hand. Maybe they help you understand the poster better, but understanding posters is not the point of most threads. Signature images are off-topic in almost every thread they appear in.

This is often also true of embedded images in general. I would estimate that half of all images posted recently are totally off-topic, and perhaps only a tenth contribute significantly to the discussion. Many images are somewhat on-topic and useful, but they take up more space than they're worth.

Text can also be off-topic (both in signatures and out), but text takes up much less space, and it's less distracting.

There are also security problems: Images can be used to execute cookie stuffing and cross-site request forgery attacks; they use a lot of bandwidth; and they prevent bitcointalk.org's HTTPS from appearing totally "kosher" to browsers. These issues could be solved by hosting all images at bitcointalk.org, but this isn't worth the trouble.

Yes, users can block images in their browsers. But it seems to me most correct to assume that users don't want something possibly unwanted than to assume they do want it. Posts are categorized so that readers have a choice in what they read. I want images to be placed, along with all other non-textual data, into a category that requires an extra choice on the part of readers.

Most of my favorite forum-like things -- NNTP, BBSes, Kareha-style text boards, Reddit, Metafilter etc. --  do not traditionally allow embedded images, and they do just fine.

I don't like embedded images. They usually clutter up the discussion without much benefit. This is especially true of signature images: they take up more screen space than a few paragraphs, but they provide almost no value.

If you replace your signature image with a short direct link to an image, it would be easy for someone to write a GreaseMonkey script that expands these images.

I recently enabled an option that collects stats constantly:
https://bitcointalk.org/index.php?action=stats

I've not yet decided how accurate these are. I may remove them later, since they are very different from the result I get when I analyze the access logs:

grep -c '05/Nov/2011' access.log: 966037
pcregrep -c '05/Nov/2011.*GET [^ ]+topic=' access.log: 124119 <- I think I'll use this number next time.

The average user won't have to worry about it. If you enable the feature where a second device is required for spending, the client will just start giving you addressversion-1 addresses. You won't notice any other change, since the client will handle everything.

Then every merchant will have to update clients whenever users want to use a new transaction type. With OP_EVAL, a merchant could keep running the same version for years (assuming there are no bugs) and still send transactions using the latest scripts.

It also improves decentralization, since there will be no need to coordinate assignment of address version numbers. (And there are only 256 address version numbers to assign -- too few to cover all scripts.)

People who request an OP_EVAL transaction will know exactly how many extra bytes it will take to redeem the transaction. They shouldn't be surprised by fees.

I know that this is not true, since the policy has always been that the entire signature area can't be much larger than 468px x 60px. Yet almost every time I view a topic I see someone with larger signature images. Usually I don't feel like dealing with it, but I've probably removed fifty or more signatures that were too large.

No.

It probably could be done, but I don't like the idea of images in signatures, anyway. The next forum software will eliminate all embedded images.