So you prefer google translation than a native Chinese speaker? It's up to you

tl;dr : they stopped BOTH 3rd party processor and bank deposit

CNY withdrawal as usual

BTC deposit/withdrawal as usual

你是屁民, 我等不是

Yes, that's a problem but I think this could be somehow solved this way:

1. For every input, a "sequence" field is added. It is a var_int ( https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer )

2. Sender has to sign the sequence field

3. A signature is valid only if the sequence field is exactly larger by 1 than the last sequence used by the same address (i.e., for the first time to spend money from an address, the sequence must be 0; and for the second time to spend money from the same address, the sequence must be 1, etc.)

4. The NZBA set will record the last used sequence of all addresses.

Problems:

1. Each input is 1-9 bytes bigger. In most case it'd be only 1 byte unless the address is heavily reused.

2. A bigger problem is miners have to keep the record of all used addresses in the history, even the balance is 0.

3. Another potential problem is that could cause trouble for off-line wallet and thin wallet. They need some way to know the latest sequence of an address. For off-line wallet that's similar to our current situation (e.g. Armory needs a online computer to create the un-signed transaction). For thin wallet like the Android Bitcoin Wallet, there may not be a fully trust-free way to learn the latest sequence of an address.

Any other solution?

In 2011 the low was about 0.1x of the trendline

The 2013 July low was exp(-0.31)=0.73x of the trendline

Now we are at about 0.82x

We are now 32 days behind, or at 0.82x of the trend line

Time to update:

Date:    1-Apr-2014
VWAP:    479.96
x:    1354
a:    0.00606
b:    -1.83009
Rsq:    0.88299
The day's expected price:    584.87
Predicted date for today's price:    27-Feb-2014
Days ahead:    -32.64
Daily price rank:    133
Predicted date for ATH ($1126):    23-Jul-2014
   
(See OP for explanation)   
   
   
   
https://www.wolframalpha.com/input/?i=e+%5E+%28+0.00605722960118392++%28+number+of+days+since+jul+17%2C+2010+%2Fdays+%29+-1.83009376643144+%29   

For each input address it will use 8 bytes to indicate the amount to spend, so the difference between total input and total output will be the fee

This is not completely your mistake. The name is misleading. I propose to change to a more proper name but no one is listening to me

Actually 28bytes per input is saved because the outpoint=hash+index takes 36bytes.

在做中國夢的時候 

yes exactly

Thanks to @roslinpl who demonstrates how misleading the forum name is.

Yes, I think so.

This section is for "Technical discussion about Satoshi's Bitcoin client and the Bitcoin network in general. No third-party sites/clients, bug reports that do not require much discussion (use github), or support requests."

Satoshi adopted the "output approach" in bitcoin, which means a transaction output must be fully spent, and different outputs of the same address must be spent separately. There are some known problems of this approach:

1. scriptSig malleability: Since reference to UTXO depends on the transaction hash, scriptSig malleability will break a chain of unconfirmed transactions.

2. Not optimal for micropayment. Since outputs are discrete, it is not economical to spend tiny outputs

Here I propose a different approach, the "account balance approach"

1. Only P2SH is accepted. The scriptPubKey is simply a script hash. People will send bitcoin to addresses, just like what we are doing now.

2. Instead of storing an index of UTXO, miner will store an index of non-zero-balance-address (NZBA). When an address receives a bitcoin, miner will either create a new entry in the NZBA set (if the address did not exist) or add the received amount to the corresponding address

3. To spend bitcoin, the private key holder has to provide a signature and a script, just like the current P2SH. In addition, the sender has to explicitly indicate the amount of bitcoin to spend

4. The sender will only indicate how many bitcoin is sent to a specified address. The sender doesn't care the final balance of the recipient.

5. When a miner sees a transaction, he will hash the script and look for the corresponding hash in the NZBA set. If the spent amount is not bigger than the balance of the address, the miner will verify the signature.

6. In evaluating the balance of an address, all unconfirmed transactions will be considered. Therefore, people could spend newly received bitcoin, as long as both receiving and spending transactions are included in the same block.

7. A block is valid as long as all scripts are valid and none of the address balance is negative

This is better than the current output approach because:

1. There is no reference to txid. scriptSig malleability won't invalidate a chain of unconfirmed transaction

2. It is optimal for micropayment. An address with 100,000,000 deposits of 1 satoshi will only occupy 1 entry in the NZBA set, and could be spent as 1 bitcoin with a single signature

3. Even without micropayment, it saves space because there won't be reference of txid (32bytes) in input. Instead, the transaction value is needed which takes 8bytes. So at least 24bytes are saved for each input.

4. Change output is not needed as a account balance could be spent partially.

5. If people do not want to reuse address for privacy reason, they can always completely spend the balance of an address and create a change, just like what we are doing now. (Space is still saved because txid is not used)

However, I'm not sure if the account balance approach is as computationally efficient as the output approach (in terms of memory use etc.) Also, I'm not sure with its implication to thin clients.

Any comments?

The formula is shown on the OP

As the overall volatility of the market is decreasing, I believe it will be less painful.

They update everyday and remove the data of the last day

Yes, I do not see why it should exist. With 293000 blocks so far, 293000*4=1.17MB is wasted. Not much, but I can't see why