Bitcoin Forum

Why staff can manually whitelist or put some threshold earned Merit requirement for members who wish to post "Ivory tower" board. Because there are some members whose having lots of initial (airdropped) Merits, but doesn't interested to post those boards at all.

The rate of block creation has nothing to do with the reward.   This is the sort of thinking you end up with when you're thinking of mining as primarily a method of distributing the initial wealth— thats a wrongheaded way of looking at it.

The nakamoto hash chain is an attack resistant solution to a version of the byzantine generals problem (http://en.wikipedia.org/wiki/Byzantine_fault_tolerance). In our case nodes communicate over a lossy channel with unknown and sometimes high delay in the face of aggressive agents who may try to disrupt or impersonate the communications, and they want to come to some consensus about the past history which is backed by a resource which is difficult to obtain.

The hash chain allows any observer to figure out which transactions have been approved by the largest clique of communicating hash power.  If the blocks were to be generated faster than the communication between the miners,  then most of the hashing effort would go to waste as blocks are randomly orphaned. Rather than a long straight chain with knots here and there, you'd have a bush as hashing power is spent on lots of parallel dead ends. Basically, for the purpose of the algorithm nodes which can't communicate within the time between blocks aren't communicating, so they can't be part of the same largest clique, so the hash power of the network is divided.

An attacker who used a modified strategy of "always extend the near longest chain which contains most of my blocks"  would have an advantage over the rest of the network following the normal rules, and would be able to control the longest chain without having as much power.  Also, transactions near the boundary would be continually flickering in and out of blocks differently depending on where in the network you were located.

Faster blocks would also increase storage requirements for lite clients drastically, basically a 100x increase for your proposed 600 blocks an hour. Satoshi was already concerned that bitcoin's storage requirements would endanger its success. I think he considered 5 vs 10 minutes and eventually decided on 10, but I doubt he would have even considered much faster.

Then you may have some difficulty understanding some of the technical details about how bitcoin works.


At the protocol level there aren't any bitcoins or any addresses at all.  "Bitcoins" are just an abstraction that we humans use to make it easier to discuss the transfer of control of value.  "Addresses" are just a shorthand that we've created to represent a couple of very common scripts used.

At the protocol level, there are unspent transaction outputs, and these are used as inputs to transactions that create new unspent transaction outputs.  Transaction outputs are encumbered with a requirement that must be met in order to use them as inputs in a transaction.  The requirement of the unspent outputs that are being used as inputs are met by the transaction sender in the form of data (and possibly a script) in the "ScriptSig" portion of the input.  The requirements that the newly created outputs are encumbered with are created by the sender in the form of a script in the "ScriptPubKey" portion of the output.

There is an entire scripting language available for creating these scripts.  You can see the commands available here:
https://en.bitcoin.it/wiki/Script

Rather than needing to tell someone:
"Please create a transaction that has an output with a value of 100000000 and is encumbered with a script creating a requirement to supply both an ECDSA signature using the Secp256k1 curve AND the associated public key which both validates that signature AND hashes using SHA256, and then RIPEMD-160 to a hex value of 0xa7ffa0ee21557a7efd80659e7e1959454c3b03af"

(notice that the script has a requirement built on the hash of the public key, a "pubkey hash")

It is much easier for everyone to simply agree that we will create a value that we'll call an "address" that is based on that RIPEMD-160 hash, and that has a "script version" of 1 in the beginning and a checksum at the end to catch any typing errors.  Then we all agree that our wallet software will recognize this type of "address" and will create the agreed script described above using the hash extracted from the address.  The wallet software takes care of all the technical details of creating the script with the appropriate requirements and sending the transaction.  Then any software that anyone writes to look at transactions recognizes the script pattern and converts it back to an "address" when displaying it to us humans.  Then you can say the exact same thing this way:
"Please send 1 BTC to 1GKJ5Rd5ngMdMkrnxPQhVE9F46HxZ2LrMs"

Now, what if you wanted something more complex than the common script type for which everyone has agreed to an "address" type?  Since your needs would be special and not common, there wouldn't be any agreement on how to encode the necessary script as an "address".  You'd have to describe your complex requirements, and the sender would need to figure out how to create a script that would meet those needs so that they could encumber the output with the appropriate script.  This would make "smart contracts", and multi-sig transactions, difficult and complex to communicate.  You could create the script for the sender, and then give it to them, but the average transaction sender isn't going to be technically knowledgeable enough to know how to create a transaction that uses your special script.

Instead, what you could do is create the script, then create a hash of the script.  Now you have a format that can be easily standardized.  Anybody can create any script of any complexity.  Then they can hash that script, and ask the sender to:
"Please create a transaction that has an output with a value of 100000000 and is encumbered with a script creating a requirement to supply a script that both evaluates successfully AND hashes using SHA256 and then RIPEMD-160 to a hex value of 0xe8c300c87986efa84c37c0519929019ef86eb5b4"

(notice that the script has a requirement built on the hash of a script, a "script hash")

If we all agree on this new "pay to script hash" script pattern, then we can agree that we will create a value that we'll call an "address" that is based on that RIPEMD-160 hash, and that has a "script version" of 3 in the beginning and a checksum at the end to catch any typing errors. Then we all agree that our wallet software will recognize this type of "address" and will create the agreed standardized script described above using the hash extracted from the address. The wallet software takes care of all the technical details of creating the script with the appropriate requirements and sending the transaction.  Then any software that anyone writes to look at transactions recognizes the script pattern and converts it back to an "address" when displaying it to us humans.  Then you can say the exact same thing this way:
"Please send 1 BTC to 3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8".

Note that the receiver of this transaction (the one that wants the complex script in the first place) is responsible for creating the script, hashing it and then providing the sender with an "address" that has version 3, and the hash and checksum embedded.  The sender can simply send to the "address" and their wallet knows how to create the "pay to script hash" pattern in the output.  The receiver then needs to supply the actual script in the input when they eventually spend the output that has been created for them.

This simplifies the sending of bitcoins when the receiver requires a complex script, and places all the burden on the person that is requireing the complex script in the first place.

This standardization has been taken one step farther in the case of multi-sig transactions by allowing the receiver(s) of the transaction to create the pay2script hash address with their wallet software and the wallet takes care of keeping track of what script was hashed and using that script when the receiver later spends those bitcoins.

<...>