Computing power has nothing to do with hardforks.

Hardforks are not a great path to evolution. They're dangerous and potentially coercive. They must be undertaken with the consent of effectively _all_ users. They should be avoided unless there are no other reasonable alternatives.

Although many things have changed and advanced, it's arguable if we've ever had a hardfork or not: Very old nodes can still validate the chain, though they will non-deterministically fail because of semi-hard-forking database management bugs that have been fixed.

Fortunately, we don't have to have hardforks to evolve:  The P2P protocol is a matter between individual peers. They can negotiate whatever options they want. We have replaced the p2p protocol.  Most interesting and important changes to the blockchain validation rules can be accomplished via softforking changes. E.g. P2SH is effectively a radical change in how transaction spending rules are encoded and was accomplished without a hard fork.

In Bitcoin evolution is slow.  There are wallets which cannot be updated because they run on platforms controlled by corporations which are hostile to user-freedom (in particular, there is an i phone wallet app that produces signatures with an invalid encoding). There are multiple implementations of the Bitcoin protocol, but even with the BIP process their implementers have simply declined to implement some functionality, and its lack of universal availability makes it unusable to users. etc. But the system itself is a gigantic moving machine and failure is difficulty— even impossible— to fix, if something goes wrong so it's hard to say that slowness is a bad thing at all. Slowness helps ensures there is understanding and consent and reduces risk.

Would it be technically possible to produce a digital equivalent of Casascius-style physical bitcoins?

If yes, this would allow the use of BTC without the need to propagate a transaction through the network. In effect it would be the true equivalent of cash. The balance would be recorded on the blockchain for the public address, but transfers of the private key would remain private.

Such a system would need a transferrable digital wallet/wrapper  with the following characteristics:

1. An encrypted private key with a passcode.

2. An indication of whether the private key has ever been decrypted (the equivalent of the seal on a physical bitcoin)

3. A way of generating a new passcode when the wallet/wrapper is transferred so that the new owner can be sure that the old owners cannot decrypt the wallet once possession has changed.

Could it be done?

To me it seems like an issue with american non-metric tradition. In Europe people easily say "1.86 meters" while in US it would sound too complex. There you have "6 feet 4 inches" - all whole numbers.

On the other hand, people are simply not used to use hard appreciating currency. Normally all dollars/franks/roubles are losing value and everyone uses bigger whole amounts for the same products. If you give people a deal "your money will increase its value, but for that you'd have to deal with smaller and smaller fractional units over time", would it be considered a great deal? I think people will educate themselves very quickly about anything when their money is involved (and could be controlled by them).

当然真的，在796融资融券业务里借出比特币，由借入方将股票抵押给796作担保，然后796再给借出方作担保，所以是完全没风险的。
利率的选择范围是0.2%-4%每周，不算复利相应的年化收益达到10.6%-212%！！！

FWIW jl2012 almost described what you just described, except he didn't make it explicit that you need P2SH: https://bitcointalk.org/index.php?topic=255145.msg2756623#msg2756623

Note how to further discourage miners for modifying transactions, you could spend an output of tx1 in a fee paying transaction broadcast at the same time as tx1 is broadcast. Even better would be to pay the tx fee for tx1 via an out-of-band fee paying protocol - like the fidelity-bonded rough consensus balance ideas I've talked about before - that identified transactions solely by txid.

Finally make the protocol allow for Alice to request Bob to sign multiple transactions, spread out over time, so that Bob can't know if Alice is asking him to sign a dummy transaction or because tx1 was modified and Alice needs a new refund tx.

Note that in some cases you'll need to give Bob a SHA256 midstate so Bob knows what nLockTime/nSequence he's signing - the latter could be tricky to apply due to limitations on what information the midstate can hide - you may need an extra txin - so you're better off with a protocol where Bob learns tx-refund prior to relying on it's contents.

EDIT: nah, actually I can't see how you'd prevent Bob from figuring out what tx to mutate based on the nLockTime value, so it looks like you just have to let design the protocol so Bob learns tx-refund (any any dummy's signed) prior to relying on the non-existance of a immediately-mineable refund tx.

I had an idea that I thought would work to prevent covenants.

There exist chameleon hash functions... these are hash functions which are parametrized by a public key and are cryptographically strong collision resistant hashes to anyone who doesn't know the secret corresponding to the public key. ... but someone who knows the secret can trivially compute collisions.

My thought was that if you had the hash over the transaction outputs pass through a chameleon hash then you could tell the covenant you were using one set of outputs, but then substitute another set after obtaining your signature. But it would still be secure because no one else could make this substitution.

Unfortunately it seems like it wouldn't work: The covenant could force you to use a nothing up my sleeve number as the public key for the hash, e.g. like the txid of the coin you are spending.

2013年9月24日 有一笔1314.88 比特币的买入挂单，挂单价788.88. 此挂单人，邮件联系平台，要求提现时不扣除0.001的手续费，因为这笔订单是用于他买给自己女儿陪嫁的，数字上图个吉利。平台方面表示同意。

为啥这网站的比特币价格那么高？

Hardly. Making payments with good privacy is the whole point of Bitcoin, isn't it?

How does the payment protocol solve that?

The request message allows you to request the payment be spread over multiple outputs (which don't have to be pay-to-address type outputs at that point, they could contain any script, like multi-signature scripts). It also lets the payer submit multiple transactions as part of satisfying the same payment. When an app generates a payment request (e.g. to get your salary), it knows how much money it's requesting and it can spread the money over many outputs. They payer might still generate one mega-transaction, but it's smarter for the payer to try and match up what it's got most closely with what's requested, to maximize privacy and minimise leakage.

If you wanted to, you could run games alongside a group video chat to raise the bar for cheating a bit further (i.e. people are not actually sitting next to each other, you can see their hands+keyboard), and you could pay someone independent to randomly audit peoples computers using screen-sharing software to verify they weren't communicating.

List of top100 madmen.

One bitflip while making a transaction with these fat txouts and its $10 million in paper value down the drain.

Which is also true of storing any private key electronically (such as in your wallet/client) as well.

I am familiar with using bitaddress.org to generate addresses. I am not sure how the random numbers are generated.

If I want to use dice to tediously generate a 260 bit random number, how can I use that random number to generate a private key / public address?

I have no programming expertise. Thanks!!

You're not thinking deviously enough.

Lets suppose I define a new merkle-sum-product-christmas-tree which sums all the transaction values up and even distributes presents to the homeless; we'll call the top level digest of that tree D2, and the top level digest of the old merkle tree D1.

Now ask yourself, can a SPV node know if rather than setting hashMerkleRoot to D1 as before, we've set it to Hash(D1 | D2)? A full node certainly can - they have a full list of transactions and will immediately see that something isn't adding up - but what about a SPV node?

Also, it'd be interesting to know if any SPV clients out there would even notice if they were given two transactions, ostensibly from the same block, whose merkle paths back to the block header were of different lengths.