The current network consensus is to have a maximum block size of 1 Mb. This means that 1 Mb of transactions can be stored in one block. Transactions have a data size, usually between 200 and 500 bytes and this is what takes up space in a block.

The issue that some people have with 1 Mb blocks is that at some point, there will be so many transactions that all blocks will be reaching the maximum number of transactions that they can contain. The idea is that increasing the maximum block size will allow for more transactions to be included in a block. This would then allow more transactions to confirm in one block and, in theory, keep fees low as long as there is space in blocks for transactions.

Additionally, when blocks become full, there is an idea that this will create a fee market. This essentially means that fees will increase as people have "bidding wars" with their fees to have their transactions included in a block since there would not be enough block space for all of the unconfirmed transactions. This would drive up fees and thus earn more income for miners but could potentially drive away users as the fees become too high.

Larger blocks have their drawbacks, as do smaller blocks. Larger blocks require more data to be transferred, and as blocks grow larger, the bandwidth requirement increases. There is also a verification slowdown that is caused by large blocks. The time required to verify a block grows exponentially in relation to the block size. These factors can lead to slowdowns in the propagation of blocks and therefore increase the orphan rate of miners. This additional bandwidth requirement can also make it difficult for more full nodes and miners to come online.

Smaller blocks, on the other hand, can restrict the network capacity. They can prevent many transactions from being confirmed if there are too many transactions in the pool of unconfirmed transactions. This can cause delays for transaction confirmation.

---

Increasing the maximum block size is just one of the proposed solutions for increasing the number of transactions that the Bitcoin network can process. Alternatives include the lightning network, sidechains, and segregated witness among a variety of other proposals.

---

Bitcoin Core, Bitcoin Classic, and Bitcoin XT are various clients that implement slightly different consensus rules when it comes to the block size limit, which is also why some people consider Bitcoin Classic and Bitcoin XT as altcoins since Bitcoin Core is considered the reference implementation.

Bitcoin Core proposes to use segregated witness. Segregated witness is a solution to transaction malleability which has a side effect of decreasing the size of a transaction and thus increasing the number of transactions which can be put into a block. This also solves the exponential verification time problem and makes it linear.

Bitcoin Classic is a fork of Bitcoin Core which proposes to use a hard fork to increase the maximum block size to 2 Mb.

Bitcoin XT is a fork of Bitcoin Core which proposes to use a hard fork to increase the maximum block size to 8 Mb and to constantly increase at a rate which doubles the maximum every two years until a final size of 8 Gb is reached.

---

Please note that this post is supposed to be neutral and informational. If there is anything wrong about the information, please let me know and I will fix it.

Edit: typos

Try again. I rebooted the server. It should work now.

---

ALL PREVIOUS TOKENS WILL NO LONGER WORK!!!!!

Not yet. It is on the todo list.

What you just proposed is basically sidechains, something already proposed and being worked on. Google it to find out more on how it works.

First of all, after 0.10, the bootstrap.dat will not be faster to sync.

Bitcoin core does recognize the bootstrap but it needs to index all of it so it will appear as if it is syncing from scratch.

Yes, I am working on it. I am currently unable to access my server since I am on mobile right now so it may be a few hours until it gets fixed.

The tokens no longer work since the server had to be rebooted and that cleared the tokens.

Edit: should be fixed now

I don't have that problem so I'm not sure what is wrong. Do you have JavaScript enabled?

Try clearing your browser cache.

Oh, that makes sense now. Chris! has two posts for Moved threads so that would explain the discrepancy there.

I still don't understand why a lot of people have 1 less post in the show posts than in the count though since I have seen it in many profiles.

It probably doesn't but it is still very fast.

Edit: Nope, it is definitely in real time. I refreshed my profile right after I made this post and the count went up by 1.

Not yet, just a testing release. The latest testing release is available at https://github.com/goatpig/BitcoinArmory/releases/tag/0.93.99.1

When the official release comes out, it should all be the same installation procedure.

These versions will still be compatible however you should consider upgrading. 0.94 has a new database structure which reduces the databases by a massive amount (from 60+ Gb to a 300 Mb IIRC).

The site will be going down momentarily for an update. All previous requests and tokens will be deleted.

This update will fix the problems that the site has been having with user's requests failing due to discrepancy in post counts.

Edit: Chris! it's fixed (my site, not your profile): http://www.bctalkaccountpricer.info/?token=u640fnvp. I had to write a workaround that doesn't rely on the forum providing the right profile info.

You probably have a couple of posts that ended up in the trashcan. Those posts go into the post count but don't show up in the show posts pages. It is fine to have a post count above what is in the show posts, but when it is below like with Chris!, then we have problems.

I made a thread in meta about this here: https://bitcointalk.org/index.php?topic=1397338.0

While I was looking at Chris!'s profile (https://bitcointalk.org/index.php?action=profile;u=662129) to figure out why his requests kept failing on my site, I noticed that there seem to be a few post count counting problems on this forum.

If you look at Chris!'s profile (https://bitcointalk.org/index.php?action=profile;u=662129), you will notice that the post count is reported as 187. However if you look through his show posts pages (https://bitcointalk.org/index.php?action=profile;u=662129;sa=showPosts), you will notice that the count of the posts there do not match up with the reported post count. The counts are in the upper left hand corner of each post and the last post listed (https://bitcointalk.org/index.php?action=profile;u=662129;sa=showPosts;start=180) has a count of 189, not 187.

In fact, for nearly every user that I have looked at, their post count in the profile is actually one above what the count is in the show posts page.

Why is this so and is this a bug?

Also, I understand why there would be post counts reported as above the number shown in show posts since some users have posts in hidden boards like staff boards or the trashcan. Those posts are in the post count but not in the show posts pages. What I don't understand is why there would be a post count reported as less than what is in the show posts pages.

I think your profile is messed up. Look at your profile page (https://bitcointalk.org/index.php?action=profile;u=662129). It reports your number of posts as 187. Now look at the number of the last post on https://bitcointalk.org/index.php?action=profile;u=662129;sa=showPosts;start=180. It is 189. Normally that number is one above than the post count, but yours it's two below. This I think is causing the problems since I create an array whose size is the post count reported in the profile. However that post count doesn't match up with the posts in your show posts page, which is what is screwing the site up.

It's probably a bug in the forum and you should probably open a thread in meta about it.

Edit: fixed some errors.

Your wallet might be corrupted. Try running Bitcoin Core with the -salvagewallet option.

Bitcoin Core automatically bans peers that it sees are misbehaving. If a peer connected to it misbehaves, it disconnects it and blocks it from connecting for 24 hours.

As for what misbehaving means, I'm not quite sure. I am fairly certain it has something to do with the number of transactions and blocks it is sending and whether those transactions and blocks are valid.

The address to lock the coins in is a p2sh address.

The script itself may look something like:
This would mean that the person who is spending it must own the private key for the <pubkey> and must know the secret so that when the secret is put through the SHA256 hash, you get <sha256(secret)>.

You cannot lock them until a certain transaction exists. However, what you can do is have a script can only be spent from when a certain secret is known. That secret could be published in another transaction.

You can also lock to a certain date or block height.