It's done by taking the amount of Ether it has already raised * the current price of Ether. See it transparently on the Ethereum blockchain: http://etherscan.io/token/TheDAO
There are several things Ethereum does currently that's better for scaling.
1) It produces blocks every 17 seconds. It can do this without neglecting security, because orphan blocks count as uncles and are included in the security of the whole network.
2) It has a scalable/dynamic blocksize. The miners can scale the gas limit up or down by a certain amount. If the current gas limit (pi million) gets hit, miners can start increasing it.
3) Tx fees purpose is primarily for DDOS protection & solving the halting problem with turing-complete scripts. It's not a fundamental element for security, because the issuance rate is constant. This means that a "fee market" doesn't need to exist as much as in Bitcoin, in order to make sure the blockchain remains alive. It has an infinite, but predictable supply, rather than finite.
4) Future scalability improvements include Casper PoS, which will decrease block time to around 1 - 4 seconds & sharding, which will remove the need for every node to process every part of the transaction space.
These additions will mean that for the current period, transactions will increase, and perhaps lead to more centralization as not many will run nodes to keep the whole state. This is a trade-off in return for running more transactions.
What block size for Ethereum's blockchain would be required to hit 56,000 tps? I'm really getting some deja vu in having to write this out for the millionth time in a 18 month period.
None of your talking points magically address the extreme costs of prerequisite physical infrastructure needed to hit 56,000 tps.
Bottom line, it's impossible to match the throughput capacity of just a single credit card company on any blockchain, be it Bitcoin or Ethereum or BBQCoin, without incurring enormous costs in terms of CPU and bandwidth. This is to say nothing of doing decentralized exchanges, order matching, and option contracts - all of which Ethereum has been advertised as doing on a blockchain. For that you'd need hundreds of thousands of tps.
Make block time 1s. Allow blocks to hold 1M transactions. Problem solved?
Granted, this doesn't deliver the physical infrastructure to process that many transactions - but that will happen over time. Visa didn't process 56k tps on day one, either.
Is that 17 seconds per block globally, or per client? If it's global, how long would the average client take to generate a block?
If it's going to take hours to generate a block, I'm worried that it's going to take forever for an app to generate enough ether to get anything done; buying the stuff using real money is a nonstarter for most applications, so generating it on demand is the only real option.
Another issue, the guide linked says to skip to step 4c if you already have bitcoin, but then step 4c tells you to use the account you created in 4a.
I think this would be a lot clearer if you split this up into three guides: "How to buy bitcoin", "How to buy ether" and "How to buy the product".
EDIT: Also, the TLS certificate for alpha.ujomusic.com does not validate in firefox for me, as the certificate chain is not correctly installed on the server.
No problem, this is very interesting and I suspect I'll buy the song just as an excuse to play with ethereum. Haven't had a chance to look at it before.
To be honest, we were frustrated that it slipped through. As in exactly as you say: it's sloppy and should've really not let this happen. Completely our fault.
I can see how you would naively assume that it's something to do with some CSS issue, but it's nothing to do with CSS. We're trying to use a brand new technology for the first time using libraries that have just been written, and newsflash not all browsers behave the same way.
The browser block is up while we figure out where the cracks are during _this prototype_.